L 4

Chapter 7
Relational Database Design by

ER- and EER-to-Relational
Mapping
Copyright © 2004 Pearson Education, Inc.

5.5
Elmasri/Navathe, Fundamentals of Database Systems, Fourth Edition Chapter 7-3

Copyright © 2004 Ramez Elmasri and Shamkant Navathe
5.6

Chapter Outline
 ER-to-Relational Mapping Algorithm

Step 1: Mapping of Regular Entity Types
Step 2: Mapping of Weak Entity Types
Step 3: Mapping of Binary 1:1 Relation Types
Step 4: Mapping of Binary 1:N Relationship Types.
Step 5: Mapping of Binary M:N Relationship Types.
Step 6: Mapping of Multivalued attributes.
Step 7: Mapping of N-ary Relationship Types.
 Mapping EER Model Constructs to Relations

Step 8: Options for Mapping Specialization or Generalization.
Step 9: Mapping of Union Types (Categories).

FIGURE 7.1
The ER
conceptual
schema
diagram for
the
COMPANY
database.

ER-to-Relational Mapping Steps
Step 1: Mapping of Regular Entity Types.
– For each regular (strong) entity type in the ER schema, create a

relation R that includes all the simple attributes of E.
– Choose one of the key attributes of E as the primary key for the
relation.
Example:
 We create the relations EMPLOYEE, DEPARTMENT, and
PROJECT in the relational schema corresponding to the regular
entities in the ER diagram.
 SSN, DNUMBER, and PNUMBER are the primary keys for the
relations EMPLOYEE, DEPARTMENT, and PROJECT as shown.

FIGURE 7.2
Result of
mapping the
COMPANY
ER schema
into a
relational
schema.

Step 2: Mapping of Weak Entity Types
– For each weak entity type W in the ER schema with owner entity type E,
create a relation R and include all attributes of the weak entity as
attributes of the new relation R.
– Then, include the primary key of the owner entity as foreign key
attributes of R.
– The primary key of R is the combination of the primary key(s) of the
owner(s) and the partial key of the weak entity type W, if any.
Example:
 Create the relation DEPENDENT in this step to correspond to the weak
entity type DEPENDENT. Include the primary key SSN of the EMPLOYEE
relation as a foreign key attribute of DEPENDENT (renamed to ESSN).
 The primary key of the DEPENDENT relation is the combination {ESSN,
DEPENDENT_NAME} because DEPENDENT_NAME is the partial key of
DEPENDENT.

Step 3: Mapping of 1:1 Relation Types
For each 1:1 relationship type identify the entities participating in the
relationship. There are two possible approaches below:
(1) Foreign Key approach:
– Choose one of the relations and include a foreign key in one relation (S) which is the primary key
of the other relation (T). It is better to choose an entity type with total participation in the
relationship in the role of S.
– Example: 1:1 relation MANAGES is mapped by choosing the participating entity type
DEPARTMENT to serve in the role of S, because its participation in the MANAGES relationship
type is total.
(2) Merged relation option:

– An alternate mapping of a 1:1 relationship type is possible by merging the two entity types and
the relationship into a single relation. This may be appropriate when both participations are total.

Step 4: Mapping of Binary 1:N Relationship Types.
– For each regular 1:N relationship type R, identify the relation S,

which is the entity on the N-side of the relationship.
– Include as foreign key in S the primary key of the relation which
is on the 1 side of the relationship.
– Include any simple attributes of the 1:N relation type as attributes
of S.
Example:
 1:N relationship types WORKS_FOR, CONTROLS, and
SUPERVISION in the figure. For WORKS_FOR we include the
primary key DNUMBER of the DEPARTMENT relation as foreign
key in the EMPLOYEE relation and call it DNO.

Step 5: Mapping of Binary M:N Relationship Types.
– For each M:N relationship type, create a new relation S to represent the
relationship.
– Include as foreign key attributes in S the primary keys of the entities on
each side of the relationship; the combination of the two primary keys will
form the primary key of S.
– Also include any simple attributes of the M:N relationship type as attributes
of S.
Example:
 The M:N relationship type WORKS_ON from the ER diagram is mapped by
creating a relation WORKS_ON in the relational database schema. The primary
keys of the PROJECT and EMPLOYEE relations are included as foreign keys in
WORKS_ON and renamed PNO and ESSN, respectively.
 Attribute HOURS in WORKS_ON represents the HOURS attribute of the relation
type. The primary key of the WORKS_ON relation is the combination of the
foreign key attributes {ESSN, PNO}.

Step 6: Mapping of Multivalued attributes.
– For each multivalued attribute A, create a new relation. This relation will
include an attribute corresponding to the multi-valued attribute, plus the
primary key attribute of the relation that has the multi-valued attribute, K.
– The primary key attribute of the relation is the foreign key representing the
relationship between the entity and the multi-valued relation.
– The primary key of R is the combination of A and K.
Example:
 The relation DEPT_LOCATIONS is created. The attribute DLOCATION
represents the multivalued attribute LOCATIONS of DEPARTMENT, while
DNUMBER-as foreign key-represents the primary key of the DEPARTMENT
relation. The primary key of R is the combination of {DNUMBER, DLOCATION}.

FIGURE 7.2
Result of
mapping the
COMPANY
ER schema
into a
relational
schema.

ER-to-Relational Mapping
Step 7: Mapping of N-ary Relationship Types.
(Non-binary relationships)
– For each n-ary relationship type R, where n>2, create a new
relation S to represent the relationship.
– Include as foreign key attributes in S the primary keys of the
relations that represent the participating entities.
– Also include any simple attributes of the n-ary relationship type as
attributes of S.
Example:
 The relationship type SUPPY in the ER on the next slide. This can be mapped
to the relation SUPPLY shown in the relational schema, whose primary key is
the combination of the three foreign keys {SNAME, PARTNO, PROJNAME}

FIGURE 4.11
Ternary relationship types. (a) The SUPPLY relationship.

FIGURE 7.3
Mapping the n-ary relationship type SUPPLY from
Figure 4.11a.

Mapping EER Model to Relations
Step8: Options for Mapping Specialization or Generalization.
Option 8A: Multiple relations, Super class and subclasses.

– Create a relation for the super class, including the super class attributes.
– Create a relation for each subclass, which includes the primary key of
the super class (which acts as the foreign key) and the attributes of the
subclass specialization.
– This works for any specialization (partial, total, disjoint, overlapping)
Option 8B: Multiple relations, Subclass relations only

– Create a relation for each subclass, with the attributes of both the super
class and the attributes of the subclass.
– This only works for total specializations, meaning that every entity in the
super class must belong to at least one subclass. Otherwise members
of the super class that don’t belong to a subclass will not be represented.

FIGURE 7.4 – Using Option 8A

FIGURE 7.4 – Using Option 8B

Option 8C: Single relation with one type attribute.
– Create a single relation, with all the attributes of the super class and all the
attributes of a subclass.
– Include a ‘Type’ attribute, which is the discriminating attribute which indicates
which subclass the row belongs to.
– This only works if the specialization is disjoint, meaning the super class entity
cannot be a member of more than one subclass.
Option 8D: Single relation with multiple type attributes.

– Create a single relation with all the attributes of the super class and all the
attributes of the subclass.
– Include a Boolean “Type” attribute for each subclass, which indicates whether the
row belongs to that subclass.
– This works with overlapping specializations, to indicate if the super class entity
belongs to more than one subclass.

FIGURE 7.4 – Using Option 8C
EngType

FIGURE 7.4 – Using Option 8D

Step 9: Mapping of Union Types (Categories).
– For mapping a category whose defining super classes have different
keys, you can specify a new key attribute, called a surrogate key, when
creating a relation to correspond to the category.
– Then create a relation for each category, which includes the attributes of
the category, and the surrogate key, which acts as the foreign key.
Example:
 We can create a relation OWNER to correspond to the OWNER
category and include any attributes of the category in this relation.
The primary key of the OWNER relation is the surrogate key, which
we called OwnerId.

FIGURE 4.8
Two categories (union
types): OWNER and
REGISTERED_VEHICLE.

FIGURE 7.6
Mapping the EER
categories (union
types) in Figure 4.7
to relations.

Mapping Exercise
Exercise 7.4.
FIGURE 7.7
An ER schema for a SHIP_TRACKING database.


L 4

Uploaded by

Copyright:

Available Formats

L 4

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

L 4

Uploaded by

Copyright:

Available Formats

Chapter 7

Relational Database Design by

Copyright © 2004 Pearson Education, Inc.

Elmasri/Navathe, Fundamentals of Database Systems, Fourth Edition Chapter 7-3

Elmasri/Navathe, Fundamentals of Database Systems, Fourth Edition Chapter 7-4

 ER-to-Relational Mapping Algorithm

 Mapping EER Model Constructs to Relations

Elmasri/Navathe, Fundamentals of Database Systems, Fourth Edition Chapter 7-5

Elmasri/Navathe, Fundamentals of Database Systems, Fourth Edition Chapter 7-6

– For each regular (strong) entity type in the ER schema, create a

Elmasri/Navathe, Fundamentals of Database Systems, Fourth Edition Chapter 7-7

Elmasri/Navathe, Fundamentals of Database Systems, Fourth Edition Chapter 7-8

Elmasri/Navathe, Fundamentals of Database Systems, Fourth Edition Chapter 7-9

(2) Merged relation option:

Elmasri/Navathe, Fundamentals of Database Systems, Fourth Edition Chapter 7-10

– For each regular 1:N relationship type R, identify the relation S,

Elmasri/Navathe, Fundamentals of Database Systems, Fourth Edition Chapter 7-11

Elmasri/Navathe, Fundamentals of Database Systems, Fourth Edition Chapter 7-12

Elmasri/Navathe, Fundamentals of Database Systems, Fourth Edition Chapter 7-13

Elmasri/Navathe, Fundamentals of Database Systems, Fourth Edition Chapter 7-14

Elmasri/Navathe, Fundamentals of Database Systems, Fourth Edition Chapter 7-15

Elmasri/Navathe, Fundamentals of Database Systems, Fourth Edition Chapter 7-16

Elmasri/Navathe, Fundamentals of Database Systems, Fourth Edition Chapter 7-17

Option 8A: Multiple relations, Super class and subclasses.

Option 8B: Multiple relations, Subclass relations only

Elmasri/Navathe, Fundamentals of Database Systems, Fourth Edition Chapter 7-18

Elmasri/Navathe, Fundamentals of Database Systems, Fourth Edition Chapter 7-19

Elmasri/Navathe, Fundamentals of Database Systems, Fourth Edition Chapter 7-20

Option 8D: Single relation with multiple type attributes.

Elmasri/Navathe, Fundamentals of Database Systems, Fourth Edition Chapter 7-21

Elmasri/Navathe, Fundamentals of Database Systems, Fourth Edition Chapter 7-22

Elmasri/Navathe, Fundamentals of Database Systems, Fourth Edition Chapter 7-23

Elmasri/Navathe, Fundamentals of Database Systems, Fourth Edition Chapter 7-24

Elmasri/Navathe, Fundamentals of Database Systems, Fourth Edition Chapter 7-25

Elmasri/Navathe, Fundamentals of Database Systems, Fourth Edition Chapter 7-26

Elmasri/Navathe, Fundamentals of Database Systems, Fourth Edition Chapter 7-27

You might also like