View
219
Download
4
Category
Tags:
Preview:
Citation preview
1Chapter 5© Prentice Hall, 2002
Chapter 5: Transforming EER Chapter 5: Transforming EER Diagrams into RelationsDiagrams into Relations
Mapping Regular Entities to Relations 1. Simple attributes: E-R attributes map directly
onto the relation
2. Composite attributes: Use only their simple, component attributes
3. Multi-valued Attribute - Becomes a separate relation with a foreign key taken from the superior entity
2Chapter 5© Prentice Hall, 2002
(a) CUSTOMER entity type with simple attributes
Figure 5-8: Mapping a regular entity
(b) CUSTOMER relation
3Chapter 5© Prentice Hall, 2002
(a) CUSTOMER entity type with composite attribute
Figure 5-9: Mapping a composite attribute
(b) CUSTOMER relation with address detail
4Chapter 5© Prentice Hall, 2002
Figure 5-10: Mapping a multivalued attribute
1 – to – many relationship between original entity and new relation
(a)
Multivalued attribute becomes a separate relation with foreign key
(b)
5Chapter 5© Prentice Hall, 2002
Transforming EER Diagrams Transforming EER Diagrams into Relationsinto Relations
Mapping Weak Entities– Becomes a separate relation with a
foreign key taken from the superior entity– Primary key composed of:
Partial identifier of weak entityPrimary key of identifying relation (strong
entity)
6Chapter 5© Prentice Hall, 2002
Figure 5-11: Example of mapping a weak entity
(a) Weak entity DEPENDENT
7Chapter 5© Prentice Hall, 2002
Figure 5-11(b) Relations resulting from weak entity
NOTE: the domain constraint for the foreign key should NOT allow null value if DEPENDENT is a weak entity
Foreign key
Composite primary key
8Chapter 5© Prentice Hall, 2002
Transforming EER Diagrams Transforming EER Diagrams into Relationsinto Relations
Mapping Binary Relationships– One-to-Many - Primary key on the one side
becomes a foreign key on the many side– One-to-One - Primary key on the mandatory
side becomes a foreign key on the optional side– Many-to-Many - Create a new relationnew relation with the
primary keys of the two entities as its primary key
9Chapter 5© Prentice Hall, 2002
NULL Values in Foreign KeysNULL Values in Foreign KeysWhether or not a Foreign Key can have
NULL values depends on the minimum cardinality of the concerned relationship
Minimum cardinality of 0 represented as NULL allowed for foreign key columns
Minimum cardinality of 1 represented as NULL disallowed for foreign key columns
10Chapter 5© Prentice Hall, 2002
Figure 5-12: Example of mapping a 1:M relationship
(a) Relationship between customers and orders
Note the mandatory one
11Chapter 5© Prentice Hall, 2002
Figure 5-12(b) Mapping the relationship
Again, no null value in the foreign key…this is because of the mandatory minimum cardinality
Foreign key
12Chapter 5© Prentice Hall, 2002
Figure 5-14: Mapping a binary 1:1 relationship
(a) Binary 1:1 relationship
13Chapter 5© Prentice Hall, 2002
Figure 5-14(b) Resulting relations
14Chapter 5© Prentice Hall, 2002
Figure 5-13: Example of mapping an M:N relationship
(a) ER diagram (M:N)
The Supplies relationship will need to become a separate relation
15Chapter 5© Prentice Hall, 2002
Figure 5-13(b) Three resulting relations
New intersection
relationForeign key
Foreign key
Composite primary key
16Chapter 5© Prentice Hall, 2002
Transforming EER Diagrams Transforming EER Diagrams into Relationsinto Relations
Mapping Associative Entities– Identifier Not Assigned
Default primary key for the association relation is composed of the primary keys of the two entities (as in M:N relationship)
– Identifier Assigned It is natural and familiar to end-usersDefault identifier may not be unique
17Chapter 5© Prentice Hall, 2002
Figure 5-15: Mapping an associative entity
(a) Associative entity
18Chapter 5© Prentice Hall, 2002
Figure 5-15(b) Three resulting relations
19Chapter 5© Prentice Hall, 2002
Transforming EER Diagrams Transforming EER Diagrams into Relationsinto Relations
Mapping Unary Relationships– One-to-Many - Recursive foreign key in the
same relation– Many-to-Many - Two relations:
One for the entity typeOne for an associative relation in which the
primary key has two attributes, both taken from the primary key of the entity
20Chapter 5© Prentice Hall, 2002
Figure 5-17: Mapping a unary 1:N relationship
(a) EMPLOYEE entity with Manages relationship
(b) EMPLOYEE relation with recursive foreign key
21Chapter 5© Prentice Hall, 2002
Figure 5-18: Mapping a unary M:N relationship
(a) Bill-of-materials relationships (M:N)
(b) ITEM and COMPONENT relations
22Chapter 5© Prentice Hall, 2002
Transforming EER Diagrams Transforming EER Diagrams into Relationsinto Relations
Mapping Ternary (and n-ary) Relationships– One relation for each entity and one
for the associative entity– Associative entity has foreign keys
to each entity in the relationship
23Chapter 5© Prentice Hall, 2002
Figure 5-19: Mapping a ternary relationship
(a) Ternary relationship with associative entity
24Chapter 5© Prentice Hall, 2002
Figure 5-19(b) Mapping the ternary relationship
Remember that the primary key MUST be
unique
25Chapter 5© Prentice Hall, 2002
Transforming EER Diagrams Transforming EER Diagrams into Relationsinto Relations
Mapping Supertype/Subtype Relationships– One relation for supertype and for each subtype– Supertype attributes (including identifier and
subtype discriminator) go into supertype relation– Subtype attributes go into each subtype; primary
key of supertype relation also becomes primary key of subtype relation
– 1:1 relationship established between supertype and each subtype, with supertype as primary table
26Chapter 5© Prentice Hall, 2002
Figure 5-20: Supertype/subtype relationships
27Chapter 5© Prentice Hall, 2002
Figure 5-21: Mapping Supertype/subtype relationships to relations
28Chapter 5© Prentice Hall, 2002
In-Class Exercise: Transform the In-Class Exercise: Transform the following ERD to a relational structurefollowing ERD to a relational structure
EMPLOYEE
DIVISION
DEPARTMENT
SSN
EMP#
FNAME LNAME SALARY
JOBCODE
MARRIED-TO
BLDGDIVNAME
DIVNAME
DEPT#
DEPTNAME
DIRECT
WORK-IN MANAGE
BELONG-TO
29Chapter 5© Prentice Hall, 2002
Example TablesExample TablesEMP# SOCSEC FNAME LNAME SEX SPOUSE SALARY JOBCODE DIVNAME DEPT#
E1 123-45-6789 JACK SPRATT M E2 12,500 CLERK FINANCE D3
E2 987-65-4321 JANE SPRATT F E1 55,000 SALES MARKETING D1
E3 NULL DICK BUTKUS M NULL 44,000 SALES MARKETING D2
E4 458-22-1513 SAM SPADE M E5 12,800 NULL LEGAL D2
E5 321-47-1698 LAUREN BACALL F E4 19,500 PROG MARKETING D1
EMPLOYEE
DIVNAME DEPT# DEPTNAME MANAGER
FINANCE D3 COMPTROLLER E1
MARKETING D1 NORTHEAST SALES E3
MARKETING D2 SOUTHWEST SALES E9
RESEARCH D3 PRODUCT TEST NULL
LEGAL D2 INVESTIGATION E11
DEPARTMENT
DIVNAME DIRECTOR BUILDING
FINANCE E8 102
MARKETING E13 1000
RESEARCH E9 87
LEGAL E4 495
DIVISION
Recommended