Faculty of Computing and Information Technology in Rabigh

COIS 342 - Databases

Chapter V
ER-to-Relational Transformations
Adapted from Elmasri & Navathe
by Dr Samir BOUCETTA

First Semester 2011/2012

 Chapter IV
ER-to-Relational Transformations

1. Relational Model Concepts

2. Relational Integrity Constraints

3. ER-to-Relational Transformation Algorithm

Step 1: Transformation of Normal Entity Types
Step 2: Transformation of Weak Entity Types
Step 3: Transformation of Binary 1:N Relationship Types.
Step 4: Transformation of Binary 1:1 Relationship Types
Step 5: Transformation of Binary M:N Relationship Types.
Step 6: Transformation of Multivalued attributes.
Step 7: Transformation of N-ary Relationship Types.

Chapter 4 – ER-to-Relational transformations – Adapted from Elmasri/Navathe by Dr Samir BOUCETTA 2

 1-/ Relational Model Concepts

 A Relation is a mathematical concept based on the

ideas of sets.

 The strength of the relational approach to data

management comes from the formal foundation

provided by the theory of relations.

 The model was first proposed by Dr Ted . Codd of IBM

company in 1970
Chapter 4 – ER-to-Relational transformations – Adapted from Elmasri/Navathe by Dr Samir BOUCETTA 3
 1-a/ INFORMAL DEFINITIONS

 RELATION: A table of values

– A relation may be considered as a set of rows.
– A relation may alternately be considered as a set of columns.
– Each row represents a fact that corresponds to a real-world
entity or relationship.
– Each row has a value of an item or set of items that uniquely
identifies that row in the table.
– Sometimes row-ids or sequential numbers are assigned to
identify the rows in the table.
– Each column typically is called by its column name or column
header or attribute name.

Chapter 4 – ER-to-Relational transformations – Adapted from Elmasri/Navathe by Dr Samir BOUCETTA 4

 1-b/ FORMAL DEFINITIONS

 The Schema of a Relation: R (A1, A2, .....An)

Relation schema R is defined over attributes A1, A2, .....An
For Example - CUSTOMER (Cust-id, Cust-name, Address, PhoneNber)
 A tuple is an ordered set of values
 Each value is derived from an appropriate domain.
 Each row in the CUSTOMER table may be referred to as a
tuple in the table and would consist of four values.
 <632895, “Ahmad Sultan", “15, Omar Ibn El-Khattab, SAKAKA", “0501234567">
is a tuple belonging to the CUSTOMER relation.
 A relation may be considered as a set of tuples (rows).
 Columns in a table are also called attributes of the relation.
Chapter 4 – ER-to-Relational transformations – Adapted from Elmasri/Navathe by Dr Samir BOUCETTA 5
 1-c/ DEFINITION SUMMARY
Informal Terms Formal Terms

Table Relation
Column Attribute/Domain
Row Tuple
Values in a column Domain
Table Definition Schema of a Relation
Populated Table Extension
Stopped Here 4/10/2011
Chapter 4 – ER-to-Relational transformations – Adapted from Elmasri/Navathe by Dr Samir BOUCETTA 6
 2-/ Relational Integrity Constraints

 Constraints are conditions that must be true on all

valid tuples. There are three main types of constraints:

1. Key constraints

2. Entity integrity constraints

3. Referential integrity constraints

Chapter 4 – ER-to-Relational transformations – Adapted from Elmasri/Navathe by Dr Samir BOUCETTA 7

 2-a/ Key Constraints

 Candidate key of R: A minimal set of attributes that

uniquely identifies each tuple in the relation.

 Primary Key of R: A candidate key that is chosen to

uniquely identify each tuple in the relation.

The primary key attributes are underlined.

Chapter 4 – ER-to-Relational transformations – Adapted from Elmasri/Navathe by Dr Samir BOUCETTA 8

 2-b/ Entity Integrity

 Relational Database Schema: A set S of relations that belong to

the same database. S is the name of the database.
S = {R1, R2, ..., Rn}
 Entity Integrity: The primary key attributes of each relation R in
S cannot have null values in any tuple of R.

 Note: Other attributes of R may be similarly constrained to

disallow null values, even though they are not members of the
primary key.
Chapter 4 – ER-to-Relational transformations – Adapted from Elmasri/Navathe by Dr Samir BOUCETTA 9
 2-c/ Referential Integrity

 A constraint involving two relations (the previous constraints involve a

single relation).

 Used to specify a relationship among tuples in two relations: the

referencing relation and the referenced relation.

 Tuples in the referencing relation R1 have attributes FK (called foreign

key attributes) that reference the primary key attributes PK of the
referenced relation R2.

A tuple t1 in R1 is said to reference a tuple t2 in R2 if t1[FK] = t2[PK].

Chapter 4 – ER-to-Relational transformations – Adapted from Elmasri/Navathe by Dr Samir BOUCETTA 10

 3-/ ER-to-Relational Transformation Algorithm

 Step 1: Transformation of Regular Entities.

For each regular (strong) entity E in the ER model, 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 R.

If the chosen key of E is composite, the set of simple attributes

that form it will together form the primary key of R.

Chapter 4 – ER-to-Relational transformations – Adapted from Elmasri/Navathe by Dr Samir BOUCETTA 11
 3-/ ER-to-Relational Transformation Algorithm
(continued)

 Step 2: Transformation of Weak Entities

For each weak entity W in the ER model with owner entity E,

create a relation R that includes all simple attributes of W.

The primary key of R is the combination of the primary key of

the owner entity E and the partial key of the weak entity W, if any.

In addition, include as a foreign key in R that correspond to the

primary key of the owner entity.

Chapter 4 – ER-to-Relational transformations – Adapted from Elmasri/Navathe by Dr Samir BOUCETTA 12

 3-/ ER-to-Relational Transformation Algorithm
(continued)

 Step 3: Mapping of Binary 1:N Relationship Types.

 There is a relation father-children
The father entity exists at the N-side of the relationship.
The child entity exists at the 1-side of the relationship.
 The child entity should have a foreign key to the father entity.
 Include any simple attributes of the relationship as attributes of
the child entity.
Example: WORKS_FOR, CONTROLS and SUPERVISION are relationship
of type 1:N. For WORKS_FOR we include the primary key DNUMBER of
the DEPARTMENT relation as foreign key in the EMPLOYEE relation and
call it DNO.
Chapter 4 – ER-to-Relational transformations – Adapted from Elmasri/Navathe by Dr Samir BOUCETTA 13
 3-/ ER-to-Relational Transformation Algorithm
(continued)

 Step 4: Transformation of Binary 1:1 Relationships

There are three cases :
Case 1- The relationship is of type (1,1) - (1,1)
 The two entities may be merged in one relation.

Case 2- The relationship is of type (0,1) - (1,1)

 There is a relation father-children, so, the child entity should
have a foreign key to the father entity.

Chapter 4 – ER-to-Relational transformations – Adapted from Elmasri/Navathe by Dr Samir BOUCETTA 14

 3-/ ER-to-Relational Transformation Algorithm
(continued)

 Step 4: Transformation of Binary 1:1 Relationships

Case 3- The relationship is of type (0,1) - (0,1)

 Merging the two entities or putting foreign keys in the entities
are left to the designer initiative.

Chapter 4 – ER-to-Relational transformations – Adapted from Elmasri/Navathe by Dr Samir BOUCETTA 15

 3-/ ER-to-Relational Transformation Algorithm
(continued)

 Step 5: Mapping of Binary M:N Relationship Types.

– Create a new relation S to represent the M:N relationship.
– Include as foreign keys in S the primary keys of the relations
that represent the participating entities; their combination
will form the primary key of S.
– Also include any simple attributes of the M:N relationship 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}.
Chapter 4 – ER-to-Relational transformations – Adapted from Elmasri/Navathe by Dr Samir BOUCETTA 16
 3-/ ER-to-Relational Transformation Algorithm
(continued)

 Step 6: Mapping of Multivalued attributes.

– Create a new relation R for each multivalued attribute A.

– The relation R will include :
an attribute corresponding to A. If the multivalued attribute
is composite, we include its simple components.
a foreign key FK corresponding to the primary key PK of
the relation that has A as an attribute.
– The primary key of R is the combination of A and FK.

Example: The department locations.

Chapter 4 – ER-to-Relational transformations – Adapted from Elmasri/Navathe by Dr Samir BOUCETTA 17

 3-/ ER-to-Relational Transformation Algorithm
(continued)

 Step 7: Mapping of N-ary Relationship Types.

– For each n-ary relationship R, where n>2, 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 entities.

– Also include any simple attributes of the n-ary relationship (or

simple components of composite attributes) as attributes of S.
Example: The relationship type SUPPY in the ER below.

Chapter 4 – ER-to-Relational transformations – Adapted from Elmasri/Navathe by Dr Samir BOUCETTA 18

 3-/ ER-to-Relational Transformation Algorithm
(continued)

Chapter 4 – ER-to-Relational transformations – Adapted from Elmasri/Navathe by Dr Samir BOUCETTA 19

 Summary of Mapping constructs and constraints

Correspondence between ER and Relational Models

ER Model Relational Model

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

Chapter 4 – ER-to-Relational transformations – Adapted from Elmasri/Navathe by Dr Samir BOUCETTA 20

 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 attributesAttrs(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).

Chapter 4 – ER-to-Relational transformations – Adapted from Elmasri/Navathe by Dr Samir BOUCETTA 21

 EER diagram
notation for an
attribute-
defined
specialization
on JobType.

Chapter 4 – ER-to-Relational transformations – Adapted from Elmasri/Navathe by Dr Samir BOUCETTA 22

 Options for mapping specialization or generalization.
(a) Mapping the EER schema (previous slide) using option 8A.

Chapter 4 – ER-to-Relational transformations – Adapted from Elmasri/Navathe by Dr Samir BOUCETTA 23

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

Chapter 4 – ER-to-Relational transformations – Adapted from Elmasri/Navathe by Dr Samir BOUCETTA 24

 Options for mapping specialization or generalization.
(b) Mapping the EER schema (in slide 22) using option 8B.

Chapter 4 – ER-to-Relational transformations – Adapted from Elmasri/Navathe by Dr Samir BOUCETTA 25

 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.

Chapter 4 – ER-to-Relational transformations – Adapted from Elmasri/Navathe by Dr Samir BOUCETTA 26

 EER diagram
notation for an
attribute-defined
specialization on
JobType.

Chapter 4 – ER-to-Relational transformations – Adapted from Elmasri/Navathe by Dr Samir BOUCETTA 27

 Options for mapping specialization or generalization.
(c) Mapping the EER schema in Figure 4.4 using option 8C.

Chapter 4 – ER-to-Relational transformations – Adapted from Elmasri/Navathe by Dr Samir BOUCETTA 28

 EER diagram notation for an overlapping (nondisjoint)
specialization.

Chapter 4 – ER-to-Relational transformations – Adapted from Elmasri/Navathe by Dr Samir BOUCETTA 29

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

Chapter 4 – ER-to-Relational transformations – Adapted from Elmasri/Navathe by Dr Samir BOUCETTA 30

 Mapping EER Model Constructs to
Relations (cont)
 Mapping of Shared Subclasses (Multiple Inheritance)
A shared subclass, such as STUDENT_ASSISTANT, is a
subclass of several classes, indicating multiple inheritance.
These classes must all have the same key attribute; otherwise,
the shared subclass would be modeled as a 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.

Chapter 4 – ER-to-Relational transformations – Adapted from Elmasri/Navathe by Dr Samir BOUCETTA 31

 A specialization
lattice with multiple
inheritance for a
UNIVERSITY
database.

Chapter 4 – ER-to-Relational transformations – Adapted from Elmasri/Navathe by Dr Samir BOUCETTA 32

 Mapping the EER specialization lattice in Figure 4.6
using multiple options.

Chapter 4 – ER-to-Relational transformations – Adapted from Elmasri/Navathe by Dr Samir BOUCETTA 33

 Mapping EER Model Constructs to
Relations (cont)
 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.

Chapter 4 – ER-to-Relational transformations – Adapted from Elmasri/Navathe by Dr Samir BOUCETTA 34

 Two categories (union types):
OWNER and
REGISTERED_VEHICLE.

Chapter 4 – ER-to-Relational transformations – Adapted from Elmasri/Navathe by Dr Samir BOUCETTA 35

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

Chapter 4 – ER-to-Relational transformations – Adapted from Elmasri/Navathe by Dr Samir BOUCETTA 36

 Mapping Exercise

An ER schema for a SHIP_TRACKING database.

Chapter 4 – ER-to-Relational transformations – Adapted from Elmasri/Navathe by Dr Samir BOUCETTA 37