Chapter 6: Entity-Relationship Model

Chapter 6: Entity-Relationship Model

Design Process Modeling Constraints E-R Diagram Design Issues Weak Entity Sets E tended E-R !eatures Design o" the #ank Data$ase Reduction to Relation Schemas Data$ase Design %M&

Modeling
' database can $e modeled as: a collection o" entities( relationship among entities) 'n entity is an o$*ect that e ists and is distinguisha$le "rom other o$*ects)

E ample: speci"ic person( company( e+ent( plant

Entities ha+e attributes E ample: people ha+e names and addresses 'n entity set is a set o" entities o" the same type that share the same properties) E ample: set o" all persons( companies( trees( holidays

Entity Sets customer and loan_ loan customer_id customer_ customer_ customer_ amount
name street city number

Relationship Sets
' relationship is an association among se+eral entities E ample: ,ayes customer entity depositor relationship set '--./ account entity

' relationship set is a mathematical relation among n / entities( each taken "rom entity sets 01e-( e/( 2 en3 4 e- E-( e/ E/( 2( en En5 6here 1e-( e/( 2( en3 is a relationship E ample: 1,ayes( '--./3 depositor

Relationship Set borrower

Relationship Sets 1Cont)3

'n attribute can also $e property o" a relationship set) !or instance( the depositor relationship set $et6een entity sets customer and account may ha+e the attri$ute access-date

Degree o" a Relationship Set

Re"ers to num$er o" entity sets that participate in a relationship set) Relationship sets that in+ol+e t6o entity sets are binary 1or degree t6o3) 7enerally( most relationship sets in a data$ase system are $inary) Relationship sets may in+ol+e more than t6o entity sets)

Example: Suppose employees of a bank may have jobs (responsibilities) at multiple branches, with different jobs at different branches. Then there is a ternary relationship set between entity sets employee, job, and branch
Relationships $et6een more than t6o entity sets are rare) Most relationships are $inary) 1More on this later)3

'ttri$utes
'n entity is represented $y a set o" attri$utes( that is descripti+e properties possessed $y all mem$ers o" an entity set)

Example:

customer = (customer_id, customer_name, customer_street, customer_city ) loan = (loan_number, amount )

Domain 8 the set o" permitted +alues "or each attri$ute 'ttri$ute types: Simple and composite attri$utes) Single-valued and multi-valued attri$utes E ample: multi+alued attri$ute: phone_numbers Derived attri$utes Can $e computed "rom other attri$utes E ample: age( gi+en date9o"9$irth

Composite 'ttri$utes

Mapping Cardinality Constraints

E press the num$er o" entities to 6hich another entity can $e associated +ia a relationship set) Most use"ul in descri$ing $inary relationship sets) !or a $inary relationship set the mapping cardinality must $e one o" the "ollo6ing types: :ne to one :ne to many Many to one Many to many

Mapping Cardinalities

One to one

One to many

Note: Some elements in A and B may not be mapped to any elements in the other set

Mapping Cardinalities

Many to one

Many to many

Note: Some elements in A and B may not be mapped to any elements in the other set

;eys
' super key o" an entity set is a set o" one or more attri$utes 6hose +alues uni<uely determine each entity) ' candidate key o" an entity set is a minimal super key Customer_id is candidate key o" customer account_number is candidate key o" account 'lthough se+eral candidate keys may e ist( one o" the candidate keys is selected to $e the primary key)

;eys "or Relationship Sets

=he com$ination o" primary keys o" the participating entity sets "orms a super key o" a relationship set) 1customer_id, account_number3 is the super key o" depositor NOTE: this means a pair o entit! sets can have at most one relationship in a particular relationship set" E ample: i" 6e 6ish to track all access9dates to each account $y each customer( 6e cannot assume a relationship "or each access) We can use a multi+alued attri$ute though Must consider the mapping cardinality o" the relationship set 6hen deciding 6hat are the candidate keys >eed to consider semantics o" relationship set in selecting the primar! #e! in case o" more than one candidate key

E-R Diagrams

Rectangles represent entity sets. Diamonds represent relationship sets. Lines link attributes to entity sets and entity sets to relationship sets. Ellipses represent attributes

Double ellipses represent multivalued attributes. Dashed ellipses denote derived attributes.

Underline indicates primary key attributes (will study later)

E-R Diagram With Composite( Multi+alued( and Deri+ed 'ttri$utes

Relationship Sets 6ith 'ttri$utes

Roles
Entity sets o" a relationship need not $e distinct =he la$els ?manager@ and ?6orker@ are called rolesA they speci"y ho6 employee entities interact +ia the 6orks9"or relationship set) Roles are indicated in E-R diagrams $y la$eling the lines that connect diamonds to rectangles) Role la$els are optional( and are used to clari"y semantics o" the relationship

Cardinality Constraints
We e press cardinality constraints $y dra6ing either a directed line 13( signi"ying ?one(@ or an undirected line 1B3( signi"ying ?many(@ $et6een the relationship set and the entity set) :ne-to-one relationship: ' customer is associated 6ith at most one loan +ia the relationship borrower ' loan is associated 6ith at most one customer +ia borrower

:ne-=o-Many Relationship
In the one-to-many relationship a loan is associated 6ith at most one customer +ia borrower( a customer is associated 6ith se+eral 1including .3 loans +ia borrower

Many-=o-:ne Relationships
In a many-to-one relationship a loan is associated 6ith se+eral 1including .3 customers +ia borrower( a customer is associated 6ith at most one loan +ia borrower

Many-=o-Many Relationship
' customer is associated 6ith se+eral 1possi$ly .3 loans +ia $orro6er ' loan is associated 6ith se+eral 1possi$ly .3 customers +ia $orro6er

Participation o" an Entity Set in a Relationship Set

Total participation (indicated by double line): every entity in the entity set

participates in at least one relationship in the relationship set

E.g. participation of loan in borrower is total

every loan must have a customer associated to it via borrower

Partial participation: some entities may not participate in any relationship in

the relationship set

Example: participation of customer in borrower is partial

'lternati+e >otation "or Cardinality &imits

Cardinality limits can also express participation constraints

E-R

Diagram 6ith a =ernary Relationship

Cardinality Constraints on =ernary Relationship

We allo6 at most one arro6 out o" a ternary 1or greater degree3 relationship to indicate a cardinality constraint E)g) an arro6 "rom wor#s_on to $ob indicates each employee 6orks on at most one *o$ at any $ranch) I" there is more than one arro6( there are t6o 6ays o" de"ining the meaning) E)g a ternary relationship % $et6een &( ' and C 6ith arro6s to ' and C could mean -) each & entity is associated 6ith a uni<ue entity "rom ' and C or /) each pair o" entities "rom 1&, '3 is associated 6ith a uni<ue C entity( and each pair 1&, C3 is associated 6ith a uni<ue ' Each alternati+e has $een used in di""erent "ormalisms =o a+oid con"usion 6e outla6 more than one arro6

Design Issues
Use of entity sets vs. attributes Choice mainly depends on the structure o" the enterprise $eing modeled( and on the semantics associated 6ith the attri$ute in <uestion) Use of entity sets vs. relationship sets Possi$le guideline is to designate a relationship set to descri$e an action that occurs $et6een entities Binary versus n-ary relationship sets 'lthough it is possi$le to replace any non$inary 1n-ary( "or n C /3 relationship set $y a num$er o" distinct $inary relationship sets( a nary relationship set sho6s more clearly that se+eral entities participate in a single relationship) Placement of relationship attributes

#inary Ds) >on-#inary Relationships

Some relationships that appear to $e non-$inary may $e $etter represented using $inary relationships E)g) ' ternary relationship parents( relating a child to hisEher "ather and mother( is $est replaced $y t6o $inary relationships( ather and mother %sing t6o $inary relationships allo6s partial in"ormation 1e)g) only mother $eing kno63 #ut there are some relationships that are naturally non-$inary E ample: wor#s_on

Con+erting >on-#inary Relationships to #inary !orm

In general( any non-$inary relationship can $e represented using $inary relationships $y creating an arti"icial entity set) Replace % $et6een entity sets '( # and C $y an entity set E( and three relationship sets: -) %&( relating E and & F) %C( relating E and C Create a special identi"ying attri$ute "or E 'dd any attri$utes o" % to E !or each relationship 1ai , bi , ci3 in %, create -) a ne6 entity ei in the entity set E F) add 1ei , bi 3 to %' /) add 1ei , ai 3 to %& G) add 1ei , ci 3 to %C /)%'( relating E and '

Con+erting >on-#inary Relationships 1Cont)3

'lso need to translate constraints =ranslating all constraints may not $e possi$le =here may $e instances in the translated schema that cannot correspond to any instance o" % E ercise: add constraints to the relationships %&, %' and %C to ensure that a ne6ly created entity corresponds to e actly one entity in each o" entity sets &, ' and C We can a+oid creating an identi"ying attri$ute $y making E a 6eak entity set 1descri$ed shortly3 identi"ied $y the three relationship sets

Mapping Cardinalities a""ect ER Design

Can make access-date an attribute of account, instead of a relationship

attribute, if each account can have only one customer

That is, the relationship from account to customer is many to one, or equivalently, customer to account is one to many

,o6 a$out doing an ER design interacti+ely on the $oardH Suggest an application to $e modeled)

Weak Entity Sets

'n entity set that does not ha+e a primary key is re"erred to as a weak entity set) =he e istence o" a 6eak entity set depends on the e istence o" a identifying entity set it must relate to the identi"ying entity set +ia a total( one-to-many relationship set "rom the identi"ying to the 6eak entity set Identi"ying relationship depicted using a dou$le diamond =he discriminator 1or partial #e!( o" a 6eak entity set is the set o" attri$utes that distinguishes among all the entities o" a 6eak entity set) =he primary key o" a 6eak entity set is "ormed $y the primary key o" the strong entity set on 6hich the 6eak entity set is e istence dependent( plus the 6eak entity setIs discriminator)

Weak Entity Sets 1Cont)3

We depict a 6eak entity set $y dou$le rectangles) We underline the discriminator o" a 6eak entity set 6ith a dashed line) payment9num$er 8 discriminator o" the pa!ment entity set Primary key "or pa!ment 8 1loan_number, pa!ment_number3

Weak Entity Sets 1Cont)3

>ote: the primary key o" the strong entity set is not e plicitly stored 6ith the 6eak entity set( since it is implicit in the identi"ying relationship) I" loan_number 6ere e plicitly stored( pa!ment could $e made a strong entity( $ut then the relationship $et6een pa!ment and loan 6ould $e duplicated $y an implicit relationship de"ined $y the attri$ute loan_number common to pa!ment and loan

More Weak Entity Set E amples

In a uni+ersity( a course is a strong entity and a course_o ering can $e modeled as a 6eak entity =he discriminator o" course_o ering 6ould $e semester 1including year3 and section_number 1i" there is more than one section3 I" 6e model course_o ering as a strong entity 6e 6ould model course_number as an attri$ute) =hen the relationship 6ith course 6ould $e implicit in the course_number attri$ute

E tended E-R !eatures: SpecialiJation

=op-do6n design processA 6e designate su$groupings 6ithin an entity set that are distincti+e "rom other entities in the set) =hese su$groupings $ecome lo6er-le+el entity sets that ha+e attri$utes or participate in relationships that do not apply to the higher-le+el entity set) Depicted $y a triangle component la$eled IS' 1E)g) customer ?is a@ person3) Attribute inheritance 8 a lo6er-le+el entity set inherits all the attri$utes and relationship participation o" the higher-le+el entity set to 6hich it is linked)

SpecialiJation E ample

E tended ER !eatures: 7eneraliJation

A bottom-up design process 8 com$ine a num$er o" entity sets that share the same "eatures into a higher-le+el entity set) SpecialiJation and generaliJation are simple in+ersions o" each otherA they are represented in an E-R diagram in the same 6ay) =he terms specialiJation and generaliJation are used interchangea$ly)

SpecialiJation and 7eneraliJation 1Cont)3

Can ha+e multiple specialiJations o" an entity set $ased on di""erent "eatures) E)g) permanent_emplo!ee +s) temporar!_emplo!ee( in addition to o icer +s) secretar! +s) teller Each particular employee 6ould $e a mem$er o" one o" permanent_emplo!ee or temporar!_emplo!ee( and also a mem$er o" one o" o icer( secretar!( or teller =he IS' relationship also re"erred to as superclass - subclass relationship

Design Constraints on a SpecialiJationE7eneraliJation

Constraint on 6hich entities can $e mem$ers o" a gi+en lo6er-le+el entity set) condition-de"ined E ample: all customers o+er 6K years are mem$ers o" seniorciti)en entity setA senior-citi)en IS' person) user-de"ined Constraint on 6hether or not entities may $elong to more than one lo6er-le+el entity set 6ithin a single generaliJation) Disjoint an entity can $elong to only one lo6er-le+el entity set >oted in E-R diagram $y 6riting dis$oint ne t to the IS' triangle verlapping an entity can $elong to more than one lo6er-le+el entity set

Design Constraints on a SpecialiJationE7eneraliJation 1Cont)3

!ompleteness constraint -- speci"ies 6hether or not an entity in the higher-le+el entity set must $elong to at least one o" the lo6er-le+el entity sets 6ithin a generaliJation) total : an entity must $elong to one o" the lo6er-le+el entity sets partial: an entity need not $elong to one o" the lo6er-le+el entity sets

'ggregation
Consider the ternary relationship works_on, which we saw earlier Suppose we want to record managers for tasks performed by an

employee at a branch

'ggregation 1Cont)3
Relationship sets wor#s_on and manages represent o+erlapping in"ormation E+ery manages relationship corresponds to a wor#s_on relationship

,o6e+er( some wor#s_on relationships may not correspond to any manages relationships So 6e canIt discard the wor#s_on relationship Eliminate this redundancy +ia aggregation =reat relationship as an a$stract entity 'llo6s relationships $et6een relationships '$straction o" relationship into ne6 entity Without introducing redundancy( the "ollo6ing diagram represents: 'n employee 6orks on a particular *o$ at a particular $ranch 'n employee( $ranch( *o$ com$ination may ha+e an associated manager

E-R Diagram With 'ggregation

E-R Design Decisions

=he use o" an attri$ute or entity set to represent an o$*ect) Whether a real-6orld concept is $est e pressed $y an entity set or a relationship set) =he use o" a ternary relationship +ersus a pair o" $inary relationships) =he use o" a strong or 6eak entity set) =he use o" specialiJationEgeneraliJation 8 contri$utes to modularity in the design) =he use o" aggregation 8 can treat the aggregate entity set as a single unit 6ithout concern "or the details o" its internal structure)

E-R Diagram "or a #anking Enterprise

,o6 a$out doing another ER design interacti+ely on the $oardH

Summary o" Sym$ols %sed in E-R >otation

Summary o" Sym$ols 1Cont)3

Schemas Corresponding to 'ggregation

To represent aggregation, create a schema containing

primary key of the aggregated relationship, the primary key of the associated entity set any descriptive attributes

Schemas Corresponding to 'ggregation 1Cont)3 For example, to represent aggregation manages between
relationship works_on and entity set manager, create a schema manages (employee_id, branch_name, title, manager_name)
Schema works_on is redundant provided we are willing to store null

values for attribute manager_name in relation on schema manages