Transforming EER Diagrams Into Relations: Mapping Regular Entities To Relations

Transforming EER Diagrams
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
Chapter 5 1
© Prentice Hall, 2002
Figure 5-8: Mapping a regular entity
(a) CUSTOMER
entity type with
simple
attributes
(b) CUSTOMER relation
Chapter 5 2
Figure 5-9: Mapping a composite attribute
(a) CUSTOMER
entity type with
composite
attribute
(b) CUSTOMER relation with address detail
Chapter 5 3
Figure 5-10: Mapping a multivalued attribute
(a)
Multivalued attribute becomes a separate relation with foreign key

(b)
1 – to – many relationship between original entity and new relation

Chapter 5 4
into 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 entity
 Primary key of identifying relation (strong
entity)
Chapter 5 5
Figure 5-11: Example of mapping a weak entity
(a) Weak entity DEPENDENT
Chapter 5 6
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
Chapter 5 7
into 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 relation with the
primary keys of the two entities as its primary
key
Chapter 5 8
NULL Values in Foreign Keys
 Whether 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
Chapter 5 9
Figure 5-12: Example of mapping a 1:M relationship
(a) Relationship between customers and orders
Note the mandatory one
Chapter 5 10
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
Chapter 5 11
Figure 5-14: Mapping a binary 1:1 relationship
(a) Binary 1:1 relationship
Chapter 5 12
Figure 5-14(b) Resulting relations
Chapter 5 13
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
Chapter 5 14
Figure 5-13(b) Three resulting relations
Composite primary key
New
Foreign key intersection
relation
Foreign key
Chapter 5 15
into 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-users
 Default identifier may not be unique
Chapter 5 16
Figure 5-15: Mapping an associative entity
(a) Associative entity
Chapter 5 17
Figure 5-15(b) Three resulting relations
Chapter 5 18
into Relations
Mapping Unary Relationships
– One-to-Many - Recursive foreign key in the
same relation
– Many-to-Many - Two relations:
 One for the entity type
 One for an associative relation in which the

primary key has two attributes, both taken
from the primary key of the entity
Chapter 5 19
Figure 5-17: Mapping a unary 1:N relationship
(a) EMPLOYEE entity with

Manages relationship
(b) EMPLOYEE
relation with
recursive foreign
key
Chapter 5 20
Figure 5-18: Mapping a unary M:N relationship
(a) Bill-of-materials
relationships (M:N)
(b) ITEM and

COMPONENT
relations
Chapter 5 21
into 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
Chapter 5 22
Figure 5-19(b) Mapping the ternary relationship
Remember that the

primary key MUST be
unique
Chapter 5 23
into 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
Chapter 5 24
Figure 5-20: Supertype/subtype relationships
Chapter 5 25
Figure 5-21:
Mapping Supertype/subtype relationships to relations
Chapter 5 26
In-Class Exercise: Transform the
following ERD to a relational structure
FNAME LNAME SALARY

SSN
JOBCODE
EMP# EMPLOYEE
MARRIED-TO
DIRECT
DIVISION WORK-IN
MANAGE
BELONG-TO DEPARTMENT
DIVNAME BLDG
DIVNAME DEPTNAME
DEPT#
Chapter 5 27
Example Tables
EMPLOYEE
EMP# 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
DEPARTMENT
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
DIVISION
DIVNAME DIRECTOR BUILDING
FINANCE E8 102
MARKETING E13 1000
RESEARCH E9 87
LEGAL E4 495
Chapter 5 28

Transforming EER Diagrams Into Relations: Mapping Regular Entities To Relations

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Transforming EER Diagrams Into Relations: Mapping Regular Entities To Relations

Uploaded by

Copyright:

Available Formats

Transforming EER Diagrams

(b) CUSTOMER relation

(b) CUSTOMER relation with address detail

Multivalued attribute becomes a separate relation with foreign key

1 – to – many relationship between original entity and new relation

(a) Weak entity DEPENDENT

NOTE: the domain constraint

Composite primary key

Note the mandatory one

Again, no null value in the

The Supplies relationship will need to become a separate relation

Composite primary key

 Default identifier may not be unique

 One for an associative relation in which the

(a) EMPLOYEE entity with

(b) ITEM and

Remember that the

FNAME LNAME SALARY

You might also like