Relational Database Design by ER and EER To Relational Mapping

1
| P a g e

Chapter 5
Relational Database Design by ER
and EER to Relational Mapping
Reference: Chapter ‐9 Fundamentals of Database Systems, R. Elmasri and S.
Navathe, Pearson, 7th edition, 2016
Objectives:
 How a relational database schema can be created from a conceptual schema
developed using the ER models.
Chapter Contents
5.1 Relational Database Design Using ER‐to‐Relational Mapping
5.2 Mapping EER Model Constructs to Relations
5.3 Summary

Prof. Jaafer Al Saraireh Princess Sumaya University for Technology

2 | P a g e

– In this chapter we focus on the logical database design step of database
design, which is also known as data model mapping.
– We present the procedures to create a relational schema from an entity–
relationship (ER) or an enhanced ER (EER) schema.
– GOALS during Mapping
1. Preserve all information (that includes all attributes)
2. Maintain the constraints to the extent possible (Relational Model
cannot preserve all constraints‐ e.g., max cardinality ratio such as
1:10 in ER)
3. Minimize null values
– In this chapter will discuss the following:
1. ER‐to‐Relational Mapping Algorithm
i. Step 1: Mapping of Regular Entity Types
ii. Step 2: Mapping of Weak Entity Types
iii. Step 3: Mapping of Binary 1:1 Relation Types
iv. Step 4: Mapping of Binary 1:N Relationship Types.
v. Step 5: Mapping of Binary M:N Relationship Types.
vi. Step 6: Mapping of Multivalued attributes.
vii. Step 7: Mapping of N‐ary Relationship Types.
2. Mapping EER Model Constructs to Relations
i. Step 8: Options for Mapping Specialization or Generalization.
ii. Step 9: Mapping of Union Types (Categories).
5.1 Relational Database Design Using ER-to-Relational Mapping
5.1.1 ER-to-Relational Mapping Algorithm
– In this section, we describe the steps of an algorithm for ER‐to‐relational
mapping.
– We use the COMPANY database example to illustrate the mapping
procedure.
– The COMPANY ER schema is shown again in Figure 5.1, and the
corresponding COMPANY relational database schema is shown in Figure 5.2
to illustrate the mapping steps.
– Mapping will create tables with simple single valued attributes.


3 | P a g e


4 | P a g e

– Step 1: Mapping of Regular Entity Types.
1. For each regular (strong) entity type E in the ER schema, create a
relation R that includes all the simple attributes of E. Include only the
simple attributes of a composite attribute.
2. Choose one of the key attributes of E as the primary key for R. If the
chosen key of E is a composite, then the set of simple attributes that
form it will together form the primary key of R.
3. If multiple keys were identified for E during the conceptual design, the
information describing the attributes that form each additional key is
kept in order to specify additional (unique) keys of relation R.
Knowledge about keys is also kept for indexing purposes.
– In our example, we create the relations EMPLOYEE, DEPARTMENT, and
PROJECT in Figure 5.2 to correspond to the regular entity types EMPLOYEE,
DEPARTMENT, and PROJECT from Figure 5.1.
– The foreign key and relationship attributes, if any, are not included yet; they
will be added during subsequent steps. These include the attributes
Super_ssn and Dno of EMPLOYEE, Mgr_ssn and Mgr_start_date of
DEPARTMENT, and Dnum of PROJECT.

5 | P a g e

– In our example, we choose Ssn, Dnumber, and Pnumber as primary keys for
the relations EMPLOYEE, DEPARTMENT, and PROJECT, respectively.
– Knowledge that Dname of DEPARTMENT and Pname of PROJECT are unique
keys is kept for possible use later in the design.
– The result after this mapping step is shown in Figure 5.3(a).

– Step 2: Mapping of Weak Entity Types.
1. 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); this takes care of mapping the identifying relationship type of
W. 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.
2. If there is a weak entity type E2 whose owner is also a weak entity type
E1, then E1 should be mapped before E2 to determine its primary key
first.
– In our example, we create the relation DEPENDENT in this step to correspond
to the weak entity type DEPENDENT (see Figure 5.3(b)). We include the
primary key Ssn of the EMPLOYEE relation—which corresponds to the
owner entity type— as a foreign key attribute of DEPENDENT; we rename it
Essn.

6 | P a g e

– 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 Binary 1:1 Relationship Types.
o 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) the foreign key approach, (2)
the merged relationship approach, and (3) the crossreference or
relationship relation approach. The first approach is the most useful
and should be followed unless special conditions exist, as we discuss
below.
1. Foreign key approach: Choose one of the relations—S, say—and
include as 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. Include all
the simple attributes of the 1:1 relationship type R as attributes of S.
– In our example, we map the 1:1 relationship type MANAGES
from Figure 5.1 by choosing the participating entity type
DEPARTMENT to serve in the role of S because its participation
in the MANAGES relationship type is total (every department
has a manager). We include the primary key of the EMPLOYEE
relation as foreign key in the DEPARTMENT relation and
rename it to Mgr_ssn. We also include the simple attribute
Start_date of the MANAGES relationship type in the
DEPARTMENT relation
– Note that it is possible to include the primary key of S as a
foreign key in T instead. In our example, this amounts to having
a foreign key attribute, say Department_managed in the
EMPLOYEE relation, but it will have a NULL value for employee
tuples who do not manage a department. This would be a bad
choice, because if only 2% of employees manage a
department, then 98% of the foreign keys would be NULL in
this case.
2. Merged relation approach: An alternative mapping of a 1:1
relationship type is to merge the two entity types and the relationship
into a single relation. This is possible when both participations are
total, as this would indicate that the two tables will have the exact
same number of tuples at all times.

7 | P a g e

3. Cross‐reference or relationship relation approach: The third option
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.
The relation R is called a relationship relation (or sometimes a lookup
table), because each tuple in R represents a relationship instance that
relates one tuple from S with one tuple from T. The relation R will
include the primary key attributes of S and T as foreign keys to S and
T. The primary key of R will be one of the two foreign keys, and the
other foreign key will be a unique key of R. The drawback is having an
extra relation, and requiring extra join operations when combining
related tuples from the tables.
– Step 4: Mapping of Binary 1:N Relationship Types.
o There are two possible approaches: (1) the foreign key approach and
(2) the cross‐reference or relationship relation approach.
o The first approach is generally preferred as it reduces the number of
tables. 1.
o (1) The foreign key approach: For each regular binary 1:N relationship
type R, identify the relation S that represents 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; we do this because each entity instance on the N‐
side is related to at most one entity instance on the 1‐side of the
relationship type. Include any simple attributes (or simple
components of composite attributes) of the 1:N relationship type as
attributes of S.
o To apply this approach to our example, we map the 1:N relationship
types WORKS_FOR, CONTROLS, and SUPERVISION from Figure 5.1.
For WORKS_FOR we include the primary key Dnumber of the
DEPARTMENT relation as foreign key in the EMPLOYEE relation and
call it Dno.
o For SUPERVISION we include the primary key of the EMPLOYEE
relation as foreign key in the EMPLOYEE relation itself—because the
relationship is recursive—and call it Super_ssn.
o The CONTROLS relationship is mapped to the foreign key attribute
Dnum of PROJECT, which references the primary key Dnumber of the
DEPARTMENT relation. These foreign keys are shown in Figure 5.2.

8 | P a g e

o (2) The relationship relation approach: An alternative approach is to
use the relationship relation (cross‐reference) option. We create a
separate relation R whose attributes are the primary keys of S and T,
which will also be foreign keys to S and T. The primary key of R is the
same as the primary key of S. This option can be used if few tuples in
S participate in the relationship to avoid excessive NULL values in the
foreign key.
– Step 5: Mapping of Binary M:N Relationship Types.
o For each 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 as attributes of S.
o In our example, we map the M:N relationship type WORKS_ON from
Figure 5.1 by creating the relation WORKS_ON in Figure 5.2. We
include the primary keys of the PROJECT and EMPLOYEE relations as
foreign keys in WORKS_ON and rename them Pno and Essn,
respectively (renaming is not required; it is a design choice).
o We also include an attribute Hours in WORKS_ON to represent the
Hours attribute of the relationship type. The primary key of the
WORKS_ON relation is the combination of the foreign key attributes
{Essn, Pno}. This relationship relation is shown in Figure 5.3(c).
– Step 6: Mapping of Multivalued Attributes.
o 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 or relationship type that has A as a
multivalued attribute. The primary key of R is the combination of A
and K.
o If the multivalued attribute is composite, we include its simple
components.
o In our example, we create a relation DEPT_LOCATIONS (see Figure
5.3(d)). The attribute Dlocation represents the multivalued attribute
LOCATIONS of DEPARTMENT, whereas Dnumber—as foreign key—
represents the primary key of the DEPARTMENT relation. The primary

9 | P a g e

key of DEPT_LOCATIONS is the combination of {Dnumber, Dlocation}.
A separate tuple will exist in DEPT_LOCATIONS for each location.
– Step 7: Mapping of N‐ary Relationship Types.
o We use the relationship relation option. For each n‐ary relationship
type R, where n > 2, create a new relationship relation S to represent
R. Include as foreign key attributes in S the primary keys of the
relations that represent the participating entity types.
o Also include any simple attributes of the n‐ary relationship type (or
simple components of composite attributes) as attributes of S.
o The primary key of S is usually a combination of all the foreign keys
that reference the relations representing the participating entity
types.
o However, if the cardinality constraints on any of the entity types E
participating in R is 1, then the primary key of S should not include the
foreign key attribute that references the relation E′ corresponding to
E (see the discussion in Section 3.5.2 concerning constraints on n‐ary
relationships).
o Consider the ternary relationship type SUPPLY in Figure 3.17, which
relates a SUPPLIER s, PART p, and PROJECT j whenever s is currently
supplying p to j; this can be mapped to the relation SUPPLY shown in
Figure 5.4, whose primary key is the combination of the three foreign
keys {Sname, Part_no, Proj_name}.


10 | P a g e

– Example 1: Mapping of N‐ary Relationship Types.

Employee (employee_id, employee_name)
Branch (branch_name , branch_city, assets)
Job (title , level)
works_on (employee_id, branch_name , title)
– Example 2:

customer (cust_id, name, street_address, city)
Loan (loan_id, amount)
Borrower (cust_id, loan_id, access_date)
– Example 3:

Account (account_number, balance)
Check (account_number, check_number, check_date, recipient, amount, memo)

11 | P a g e

– Example 4:

Student (username)
Assignment (shortname, due_date, url)
Submission (username, shortname, version, submit_date, data )
5.1.2 Discussion and Summary of Mapping for ER Model Constructs
– Table 5.1 summarizes the correspondences between ER and relational model
constructs and constraints.
5.2 Mapping EER Model Constructs to Relations

– In this section, we discuss the mapping of EER model constructs to relations
by extending the ER‐to‐relational mapping algorithm that was presented in
Section 5.1.1.
5.2.1 Mapping of Specialization or Generalization
– There are several options for mapping a number of subclasses that together
form a specialization (or alternatively, that are generalized into a superclass),
such as the {SECRETARY, TECHNICIAN, ENGINEER} subclasses of EMPLOYEE
in Figure 4.4.

12 | P a g e

– The two main options are to map the whole specialization into (option 1) a
single table, or (option 2) to map it into multiple tables.
– Within each option are variations that depend on the constraints on the
specialization/generalization.
– Step8: Options for Mapping Specialization or Generalization.
o 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
– Option 8B: Multiple relations‐Subclass relations only
– Option 8C: Single relation with one type attribute
– Option 8D: Single relation with multiple type attributes
– Option 8A: Multiple relations‐Superclass and subclasses
o 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
attributesAttrs(Li) = {k} U {attributes of Si} and PK(Li)=k.
o This option works for any specialization (total or partial, disjoint or
overlapping).
– Option 8B: Multiple relations‐Subclass relations only
o 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.
o This option works well only for disjoint and total constraints.
o If not disjoint, redundant values for inherited attributes.
o If not total, entity not belonging to any sub‐class is lost.
– Option 8C: Single relation with one type attribute
o 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
o This option is for specialization whose subclasses are DISJOINT, and
T is a type attribute that indicates the subclass to which each tuple
belongs, if any. This option may generate a large number of null
values.

13 | P a g e

o Not recommended if many specific attributes are defined in subclasses
(will result in many null values!)
– Option 8D: Single relation with multiple type attributes
o 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.
o This option is for specialization whose subclasses are overlapping,
and each Ti, 1 < i < m, is a Boolean attribute indicating whether a
tuple belongs to subclass Si.
o This option could be used for disjoint subclasses too.
– Examples
o Example FIGURE 5.4 EER diagram notation for an attribute‐defined
specialization on JobType


14 | P a g e

o Mapping the EER schema in Figure 5.4 using option 8A

o Mapping the EER schema in Figure 5.4 using option 8C

o Example FIGURE 5.5 (b) Generalizing CAR and TRUCK into the
superclass VEHICLE.

o Mapping the EER schema in Figure 5.4b using option 8B.

15 | P a g e

o Example FIGURE 5.6 An overlapping (non‐disjoint) specialization.

o Mapping Figure 5.6 using option 8D with Boolean type fields Mflag
and Pflag.

– Figure 5.7 Options for mapping specialization or generalization.
o (a) Mapping the EER schema in Figure 5.4 using option 8A.
o (b) Mapping the EER schema in Figure 5.5(b) using option 8B.
o (c) Mapping the EER schema in Figure 5.4 using option 8C.
o (d) Mapping Figure 5.6 using option 8D with Boolean type fields Mflag
and Pflag.

16 | P a g e

5.2.2 Mapping of Shared Subclasses (Multiple Inheritance)
– FIGURE 5.8 illustrates specialization lattice with multiple inheritance for a
UNIVERSITY database.
– We can apply any of the options discussed in step 8 to a shared subclass,
subject to the restrictions discussed in step 8 of the mapping algorithm. In
Figure 5.9, options 8C and 8D are used for the shared subclass
STUDENT_ASSISTANT.
– Option 8C is used in the EMPLOYEE relation (Employee_type attribute) and
option 8D is used in the STUDENT relation (Student_assist_flag attribute).

17 | P a g e

– The mapping of the figure 5.8 is presented in below figure 5.9

18 | P a g e

– Step 9: Mapping of Union Types (Categories).
o 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.
o 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.

o FIGURE 5.11 Mapping the EER categories (union types) in Figure 5.10
to relations.

19 | P a g e

5.3 Summary
– In Section 5.1, we showed how a conceptual schema design in the ER model
can be mapped to a relational database schema. An algorithm for ER‐to‐
relational mapping was given and illustrated by examples from the
COMPANY database.
– Table 5.1 summarized the correspondences between the ER and relational
model constructs and constraints.
– We discussed additional steps Section 5.2 for mapping the constructs from
the EER model into the relational model.

Relational Database Design by ER and EER To Relational Mapping

Uploaded by

Copyright:

Available Formats

Relational Database Design by ER and EER To Relational Mapping

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

Relational Database Design by ER and EER To Relational Mapping

Uploaded by

Copyright:

Available Formats

1

5.2 Mapping EER Model Constructs to Relations

You might also like