COIS 342 - Databases
Chapter V
ER-to-Relational Transformations
Faculty of Computing and Information Technology in Rabigh
Adapted from Elmasri & Navathe
by Dr Samir BOUCETTA
First Semester 2011/2012
Chapter 4 – ER-to-Relational transformations – Adapted from Elmasri/Navathe by Dr Samir BOUCETTA 2
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 IV
ER-to-Relational Transformations
Chapter 4 – ER-to-Relational transformations – Adapted from Elmasri/Navathe by Dr Samir BOUCETTA 3
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 4
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 5
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 6
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 7
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 8
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 9
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 10
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 11
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 12
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 13
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.
3-/ ER-to-Relational Transformation Algorithm (continued)
Chapter 4 – ER-to-Relational transformations – Adapted from Elmasri/Navathe by Dr Samir BOUCETTA 14
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.
3-/ ER-to-Relational Transformation Algorithm (continued)
Chapter 4 – ER-to-Relational transformations – Adapted from Elmasri/Navathe by Dr Samir BOUCETTA 15
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.
3-/ ER-to-Relational Transformation Algorithm (continued)
Chapter 4 – ER-to-Relational transformations – Adapted from Elmasri/Navathe by Dr Samir BOUCETTA 16
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}.
3-/ ER-to-Relational Transformation Algorithm (continued)
Chapter 4 – ER-to-Relational transformations – Adapted from Elmasri/Navathe by Dr Samir BOUCETTA 17
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.
3-/ ER-to-Relational Transformation Algorithm (continued)
Chapter 4 – ER-to-Relational transformations – Adapted from Elmasri/Navathe by Dr Samir BOUCETTA 18
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.
3-/ ER-to-Relational Transformation Algorithm (continued)
Chapter 4 – ER-to-Relational transformations – Adapted from Elmasri/Navathe by Dr Samir BOUCETTA 19
3-/ ER-to-Relational Transformation Algorithm (continued)
Chapter 4 – ER-to-Relational transformations – Adapted from Elmasri/Navathe by Dr Samir BOUCETTA 20
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 21
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 22
EER diagram
notation for an
attribute-
defined
specialization
on JobType.
Chapter 4 – ER-to-Relational transformations – Adapted from Elmasri/Navathe by Dr Samir BOUCETTA 23
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 24
Generalization.
(b) Generalizing CAR and TRUCK into the superclass VEHICLE.
Chapter 4 – ER-to-Relational transformations – Adapted from Elmasri/Navathe by Dr Samir BOUCETTA 25
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 26
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 27
EER diagram
notation for an
attribute-defined
specialization on
JobType.
Chapter 4 – ER-to-Relational transformations – Adapted from Elmasri/Navathe by Dr Samir BOUCETTA 28
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 29
EER diagram notation for an overlapping (nondisjoint)
specialization.
Chapter 4 – ER-to-Relational transformations – Adapted from Elmasri/Navathe by Dr Samir BOUCETTA 30
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 31
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 32
A specialization
lattice with multiple
inheritance for a
UNIVERSITY
database.
Chapter 4 – ER-to-Relational transformations – Adapted from Elmasri/Navathe by Dr Samir BOUCETTA 33
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 34
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 35
Two categories (union types):
OWNER and
REGISTERED_VEHICLE.
Chapter 4 – ER-to-Relational transformations – Adapted from Elmasri/Navathe by Dr Samir BOUCETTA 36
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 37
Mapping Exercise
An ER schema for a SHIP_TRACKING database.