10/24/2018

 ER-to-Relational Mapping Algorithm

Step 1: Mapping of Regular Entity Types
Chapter 9 Step 2: Mapping of Weak Entity Types
Step 3: Mapping of Binary 1:1 Relation Types
Mapping ER and EER Step 4: Mapping of Binary 1:N Relationship Types.
Step 5: Mapping of Binary M:N Relationship Types.
Model Constructs to Step 6: Mapping of Multivalued attributes.
Step 7: Mapping of N-ary Relationship Types.
Relations  Mapping EER Model Constructs to Relations
Step 8: Options for Mapping Specialization or Generalization.
Step 9: Mapping of Union Types (Categories).

ER-to-Relational Mapping Algorithm

 Step 1: Mapping of Regular Entity Types.
– For each regular (strong) entity type E in the ER schema, create FIGURE 7.1
a relation R that includes all the simple attributes of E. The ER
– Choose one of the key attributes of E as the primary key for R. conceptual
schema
If the chosen key of E is composite, the set of simple attributes diagram for
that form it will together form the primary key of R. the
COMPANY
database.
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.

1
 10/24/2018

5.5

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

ER-to-Relational Mapping Algorithm (cont)

 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 simple attributes (or simple
components of composite attributes) of W as attributes of R.
– In addition, include as foreign key attributes of R the primary key
attribute(s) of the relation(s) that correspond to the owner entity type(s).
– 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.

2

ER-to-Relational Mapping Algorithm (cont)
 Step 3: Mapping of Binary 1:1 Relation Types
For each binary 1:1 relationship type R in the ER schema, identify the relations S and T
that correspond to the entity types participating in R. There are three possible approaches:
(1) Foreign Key approach: Choose one of the relations-S, say-and include a foreign key
in S the primary key of T. It is better to choose an entity type with total participation in
R 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.
(3) Cross-reference or relationship relation option: The third alternative is to set up a
third relation R for the purpose of cross-referencing the primary keys of the two
relations S and T representing the entity types.
ER-to-Relational Mapping Algorithm (cont)
 Step 5: Mapping of Binary M:N Relationship Types.
– For each regular binary M:N relationship type R, create a new relation S
to represent R.
– Include as foreign key attributes in S the primary keys of the relations that
represent the participating entity types; their combination will form the
primary key of S.
– Also include any simple attributes of the M:N relationship type (or simple
components of composite attributes) 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}.
10/24/2018
ER-to-Relational Mapping Algorithm (cont)
 Step 4: Mapping of Binary 1:N Relationship Types.
– For each regular binary 1:N relationship type R, identify the relation S
that represent the participating entity type at the N-side of the
relationship type.
– Include as foreign key in S the primary key of the relation T that
represents the other entity type participating in R.
– 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.
ER-to-Relational Mapping Algorithm (cont)
 Step 6: Mapping of Multivalued attributes.
– For each multivalued attribute A, create a new relation R. This relation R
will include an attribute corresponding to A, plus the primary key
attribute K-as a foreign key in R-of the relation that represents the entity
type of relationship type that has A as an attribute.
– The primary key of R is the combination of A and K. If the multivalued
attribute is composite, we include its simple components.
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}.
3
 10/24/2018

ER-to-Relational Mapping Algorithm (cont) FIGURE 4.11

 Step 7: Mapping of N-ary Relationship Types. Ternary relationship types. (a) The SUPPLY relationship.
– For each n-ary relationship type R, where n>2, create a new relationship S
to represent R.
– Include as foreign key attributes in S the primary keys of the relations that
represent the participating entity types.
– Also include any simple attributes of the n-ary relationship type (or simple
components of composite attributes) as attributes of S.

Example: The relationship type SUPPY in the ER below. 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 7.3 Summary of Mapping constructs and constraints

Mapping the n-ary relationship type SUPPLY from Figure 4.11a.
Table 7.1 Correspondence between ER and Relational Models

ER Model Relational Model

Entity type
1:1 or 1:N relationship type
M:N relationship type
n-ary relationship type
Simple attribute
Composite attribute
Multivalued attribute
Value set
Key attribute
“Entity” relation
Foreign key (or “relationship” relation)
“Relationship” relation and two foreign keys
“Relationship” relation and n foreign keys
Attribute
Set of simple component attributes
Relation and foreign key
Domain
Primary (or secondary) key

4

Mapping EER Model Constructs to Relations
 Step8: Options for Mapping Specialization or Generalization.
Convert each specialization with m subclasses {S1, S2,….,Sm} and generalized superclass
C, where the attributes of C are {k,a1,…an} and k is the (primary) key, into relational
schemas using one of the four following options:
Option 8A: Multiple relations-Superclass and subclasses.
Create a relation L for C with attributes Attrs(L) = {k,a1,…an} and PK(L) = k. Create a
relation Li for each subclass Si, 1 < i < m, with the attributes Attrs(Li) = {k} U {attributes
of Si} and PK(Li)=k. This option works for any specialization (total or partial, disjoint
of over-lapping).
Option 8B: Multiple relations-Subclass relations only
Create a relation Li for each subclass Si, 1 < i < m, with the attributes Attr(Li) =
{attributes of Si} U {k,a1…,an} and PK(Li) = k. This option only works for a
specialization whose subclasses are total (every entity in the superclass must belong
to (at least) one of the subclasses).
10/24/2018
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.
5

• Options 8A and 8B are the multiple-relation options, whereas options 8C
and 8D are the single-relation options.
• Option 8A creates a relation L for the superclass C and its attributes, plus a
relation Li for each subclass Si; each Li includes the specific (local) attributes
of Si, plus the primary key of the superclass C, which is propagated to Li and
becomes its primary key. It also becomes a foreign key to the superclass
relation.
• An EQUIJOIN operation on the primary key between any Li and L produces
all the specific and inherited attributes of the entities in Si.
• This option is illustrated in Figure 9.5(a) for the EER schema in Figure
4.4. Option 8A works for any constraints on the specialization: disjoint or
overlapping, total or partial.
• Notice that the constraint must hold for each Li. This specifies a foreign key
from each Li to L.
FIGURE 4.4
EER diagram
notation for an
attribute-defined
specialization on
JobType.
10/24/2018
• In option 8B, the EQUIJOIN operation between each subclass
and the superclass is built into the schema and the superclass
relation L is done away with, as illustrated in Figure 9.5(b) for the
EER specialization in Figure 4.3(b).
• This option works well only when both the disjoint and total
constraints hold.
• If the specialization is not total, an entity that does not belong
to any of the subclasses Si is lost.
• If the specialization is not disjoint, an entity belonging to
more than one subclass will have its inherited attributes from
the superclass C stored redundantly in more than one table Li.
FIGURE 7.4 –
Using Option 8A
6
 10/24/2018

FIGURE 4.3
Generalization. (b) Generalizing CAR and TRUCK into the superclass VEHICLE.

FIGURE 7.4 –
Using Option 8B

Mapping EER Model Constructs to Relations (cont)

Option 8C: Single relation with one type attribute.
Create a single relation L with attributes Attrs(L) = {k,a1,…an} U
{attributes of S1} U…U {attributes of Sm} U {t} and PK(L) = k. The
attribute t is called a type (or discriminating) attribute that indicates the
subclass to which each tuple belongs

Option 8D: Single relation with multiple type attributes.

Create a single relation schema L with attributes Attrs(L) = {k,a1,…an} U
{attributes of S1} U…U {attributes of Sm} U {t1, t2,…,tm} and PK(L) = k.
Each ti, 1 < I < m, is a Boolean type attribute indicating whether a tuple
belongs to the subclass Si.

7

Mapping EER Model to Relations
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.
• Option 8C is used to handle disjoint subclasses by including a
single type (or image or discriminating) attribute t to indicate
to which of the m subclasses each tuple belongs; hence, the
domain of t could be {1, 2, … , m}.
• If the specialization is partial, t can have NULL values in
tuples that do not belong to any subclass.
• If the specialization is attribute-defined, that attribute itself
serves the purpose of t and t is not needed; this option is
illustrated in Figure 9.5(c) for the EER specialization in Figure
4.4.
10/24/2018
• Options 8C and 8D create a single relation to represent the
superclass C and all its subclasses.
• An entity that does not belong to some of the subclasses will have
NULL values for the specific (local) attributes of these subclasses.
• These options are not recommended if many specific attributes are
defined for the subclasses.
• If few local subclass attributes exist, however, these mappings are
preferable to options 8A and 8B because they do away with the
need to specify JOIN operations; therefore, they can yield a more
efficient implementation for queries.
• Option 8D is designed to handle overlapping subclasses by
including m Boolean type (or flag) fields, one for each subclass.
It can also be used for disjoint subclasses.
• Each type field ti can have a domain {yes, no}, where a value of
yes indicates that the tuple is a member of subclass Si.
• If we use this option for the EER specialization in Figure 4.4,
we would include three type attributes—Is_a_secretary,
Is_a_engineer, and Is_a_technician—instead of the Job_type
attribute in Figure 9.5(c).
• Figure 9.5(d) shows the mapping of the specialization from
Figure 4.5 using option 8D
8
 10/24/2018

EngType

FIGURE 4.4
EER diagram
notation for an
attribute- FIGURE 7.4 –
defined Using Option 8C
specialization
on JobType.

FIGURE 4.5 FIGURE 7.4

EER diagram notation for an overlapping (nondisjoint) specialization. Options for mapping specialization or generalization.
(d) Mapping Figure 4.5 using option 8D with Boolean type fields Mflag and Pflag.

9
 10/24/2018

Mapping EER Model Constructs to Relations (cont)

 Mapping of Shared Subclasses (Multiple
Inheritance)
FIGURE 4.7
A shared subclass, such as STUDENT_ASSISTANT, is a A specialization
subclass of several classes, indicating multiple inheritance. lattice with
multiple
These classes must all have the same key attribute; inheritance for a
UNIVERSITY
otherwise, the shared subclass would be modeled as a database.
category.
We can apply any of the options discussed in Step 8 to a
shared subclass, subject to the restriction discussed in Step
8 of the mapping algorithm. Below both 8C and 8D are
used for the shared class STUDENT_ASSISTANT.

FIGURE 7.5 Mapping EER Model Constructs to Relations (cont)

Mapping the EER specialization lattice in Figure 4.6 using multiple options.
Step 9: Mapping of Union Types (Categories).
– For mapping a category whose defining superclass have
different keys, it is customary to specify a new key
attribute, called a surrogate key, when creating a
relation to correspond to the category.
– In the example below 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.

10
 10/24/2018

Mapping EER Model to Relations

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
FIGURE 4.8
category. Two categories (union
– Then create a relation for each category, which includes the types): OWNER and
REGISTERED_VEHICLE
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 7.6
Mapping the
EER categories
(union types) in
Figure 4.7 to
relations.

11

• For a multilevel specialization (or generalization)
hierarchy or lattice, we do not have to follow the same
mapping option for all the specializations. Instead, we
can use one mapping option for part of the hierarchy or
lattice and other options for other parts.
• Figure 9.6 shows one possible mapping into relations for
the EER lattice in Figure 4.6.
10/24/2018
• Here we used option 8A for PERSON/{EMPLOYEE,
ALUMNUS, STUDENT},
• And option 8C for EMPLOYEE/{STAFF, FACULTY,
STUDENT_ASSISTANT} by including the type
attribute Employee_type.
• We then used the single-table option 8D for
STUDENT_ASSISTANT/{RESEARCH_ASSISTANT,
TEACHING_ASSISTANT} by including the type
attributes Ta_flag and Ra_flag in EMPLOYEE.
12
 10/24/2018

• We also used option 8D for

STUDENT/STUDENT_ASSISTANT by including the
type attributes Student_assist_flag in STUDENT,
• And for STUDENT/{GRADUATE_STUDENT,
UNDERGRADUATE_STUDENT} by including the type
attributes Grad_flag and Undergrad_flag in
STUDENT.
• In Figure 9.6, all attributes whose names end with type
or flag are type fields.

8A

8C
8A
8D

13

9.2.2 Mapping of Shared Subclasses (Multiple Inheritance)
• A shared subclass, such as ENGINEERING_MANAGER in Figure 4.6, is
a subclass of several superclasses, indicating multiple inheritance.
• These classes must all have the same key attribute; otherwise, the
shared subclass would be modeled as a category (union type)
• We can apply any of the options (step 8) to a shared subclass, subject
to the restrictions discussed in step 8 of the mapping algorithm.
• In Figure 9.6, options 8C and 8D are used for the shared subclass
STUDENT_ASSISTANT.
• Option 8C is used in the EMPLOYEE relation (Employee_type
attribute)
• Option 8D is used in the STUDENT relation (Student_assist_flag
attribute)
Step 9: Mapping of Union Types (Categories).
• For mapping a category whose defining superclasses have
different keys, it is customary to specify a new key attribute,
called a surrogate key, when creating a relation to correspond
to the union type.
• The keys of the defining classes are different, so we cannot use
any one of them exclusively to identify all entities in the
relation.
• In our example in Figure 4.8, we create a relation OWNER to
correspond to the OWNER category, as illustrated in Figure
9.7, and include any attributes of the category in this relation.
10/24/2018
9.2.3 Mapping of Categories (Union Types)
• A category (or union type) is a subclass of the union of two or
more superclasses that can have different keys because they
can be of different entity types
• An example is the OWNER category shown in Figure 4.8, which
is a subset of the union of three entity types PERSON, BANK,
and COMPANY.
• The other category in that figure, REGISTERED_VEHICLE,
has two superclasses that have the same key attribute.
• The primary key of the OWNER relation is the surrogate key,
which we called Owner_id. We also include the surrogate key
attribute Owner_id as foreign key in each relation corresponding
to a superclass of the category, to specify the correspondence in
values between the surrogate key and the original key of each
superclass.
• Notice that if a particular PERSON (or BANK or COMPANY)
entity is not a member of OWNER, it would have a NULL value
for its Owner_id attribute in its corresponding tuple in the
PERSON (or BANK or COMPANY) relation, and it would not
have a tuple in the OWNER relation.
14
 10/24/2018

• It is also recommended to add a type attribute (not shown in

Figure 9.7) to the OWNER relation to indicate the particular
entity type to which each tuple belongs (PERSON or BANK or
COMPANY).
• For a category whose superclasses have the same key, such as
VEHICLE in Figure 4.8, there is no need for a surrogate key. The
mapping of the REGISTERED_VEHICLE category, which
illustrates this case, is also shown in Figure 9.7.

9.4. Figure 9.8 shows an ER schema for a database

that can be used to keep track of transport ships and
their locations for maritime authorities. Map this
schema into a relational schema and specify all
primary keys and foreign keys.

15
 10/24/2018

9.6. Map the EER diagrams in Figures 4.9 and 4.12

into relational schemas. Justify your choice of
mapping options.

16
 10/24/2018

9.8. Consider the EER diagram in Figure 9.9 for a car

dealer. Map the EER schema into a set of relations.
For the VEHICLE to CAR/TRUCK/SUV
generalization, consider the four options presented in
Section 9.2.1 and show the relational schema design
under each of those options.

9.9. Using the attributes you provided for the EER diagram
in Exercise 4.27, map the complete schema into a set of
relations. Choose an appropriate option out of 8A thru 8D
from Section 9.2.1 in doing the mapping of generalizations
and defend your choice.

(Exercise 4.27. Consider the following EER diagram that

describes the computer systems at a company. Provide your own
attributes and key for each entity type. Supply max cardinality
constraints justifying your choice. Write a complete narrative
description of what this EER diagram represents).

17
 10/24/2018

Any Question?
Thank You!

18