3/8/2011

Subject: Relational Database Management Systems

Lecture #5

ER to Relational Mapping
Prepared by Mr. Shakil Ahmed
Department of Computer, SSUET
(Applicable to all sections)

Why?
• ER model is not directly supported by any
DBMS
• needs to be translated into a model that is
supported by DBMSs
• Transformation / mapping process
– Non-deterministic
• certain ER configurations can be expressed in more than
one way in the relational model
• certain aspects related to the relational model are not
specified in the ER model

1
 3/8/2011

Procedure
• To convert an Entity-Relationship design to a relational
database schema, a procedure which includes the following
steps
p mayy be followed.
– Entity Conversion
• Regular Entity Conversion
• Weak Entity Conversion
– Attribute Conversion
• Multivalued Attributes
• Composite Attributes
• Derived Attributes
– Relationship Conversion
• Binary Relationship Conversion
– 1:1
– 1:Many
– Many: Many
• Non-Binary Relationship Conversion

Representation of an Strong Entity

• Entity type E with attributes a1,a2….an
i li table
implies t bl E with
ith attribute
tt ib t a1,a2,…an.
1 2
• Entity sets of type E implies rows in table E.
• Primary key of entity set implies primary key
of table
Student
Major
CREATE TABLE Student
(Student Num CHAR(9),
StudentNum Student Name Student Name CHAR(20),
Major CHAR(20),
PRIMARY KEY (StudentNum) )

2
 3/8/2011

Strong Entity with Composite attribute

• Composite attributes are flattened out by creating a separate
attribute for each component attribute
– Example:
– Given an entity set Student with composite attribute name
with component attributes first-name and last-name
– The table corresponding to the entity set has two attributes
first-name and last-name

CREATE TABLE Student

Student Major (Student Num CHAR(9),
Major CHAR(20),
Student Num Student Name
FirstName CHAR(20),
Last Name LastName CHAR(20),
PRIMARY KEY (StudentNum))
First Name

Strong Entity with Multi-valued attribute

• A multi-valued attribute M of an entity E is
p
represented byy a separate
p table EM
– Table EM has attributes corresponding to the primary key
of E and an attribute corresponding to multi-valued
attribute M
– E.g. Multi-valued attribute dependent-names of employee is
represented by a table
employee-dependent-names( employee-id, dname)
– Each value of the multi-valued attribute maps
p to a separate
p
row of the table EM
• E.g., an employee entity with primary key John and dependents
Johnson and Johndotir maps to two rows:
(John, Johnson) and (John, Johndotir)

3
 3/8/2011

Example
Student
Major

Telephone
p Student Num Student Name

Student CREATE TABLE Student(

Student Num CHAR(9),
1 StudentNum StudentName Major Major CHAR(20),
Name CHAR(20),
PRIMARY KEY (StudentNum))

St d t T l h
Student_TelephoneNo
N CREATE TABLE
N Student-Telephone-No(
StudentNum(FK) TelephoneNo Student Num CHAR(9),
TelephoneNo CHAR(20), PRIMARY
KEY (StudentNum, TelephoneNo),
FOREIGN KEY (StudentNum)
Composite pk REFERENCES Student(StudentNum) )

Strong Entity with Derived attribute

• Derived attributes are eliminated from the table.

Student
DOB
Age Student Num Student Name

CREATE TABLE Student(

StudentNum CHAR(9),
DOB DATE,
Student NamCHAR(20),
PRIMARY KEY (StudentNum) );

4
 3/8/2011

Representing Weak Entity Sets

• A weak entity can be identified uniquely only by considering
the pprimaryy keyy of another ((owner)) entity.
y
– Owner entity set and weak entity set must participate in a
one-to-many relationship set (1 owner, many weak
entities).
– Weak entity set must have total participation in this
identifying relationship set.
– Identifying relationship depicted using a double diamond
– In this example identifying entity set for payment is loan
– Example
• Consider the entity set
Payment(payment_number, payment_date,payment_amount)

Example

CREATE TABLE loan (

loan-number CHAR (9) NOT NULL,
Amount Number(6)
Number(6), PRIMARY KEY (loan-number)
(loan number) )

CREATE TABLE Payment (

Payment-number Number(3), Payment-date DATE, payment-amount Number(6),
Loan-number CHAR (9) NOT NULL,
PRIMARY KEY (Loan-number , payment-number ),
FOREIGN KEY (Loan-number ) REFERENCES loan)
ON DELETE CASCADE)

5
 3/8/2011

Keys for Relationship Sets

• Let R be a relationship set involving entity sets E1,E2,….En
• Let PK(Ei) denote the set of attributes that forms the primary key for
entity set Ei
• Assume attribute names for all PKs are unique & each entity set
participate only once in the relationship
• If Attribute names are not unique across entity sets, the attributes are
renamed to distinguish them
– If R has no attribute associated with it, Then
PK(E1) U PK(E2) U ……….. U PK (En) describes an individual
relationship in set R.
– If R has attributes a1, a2, …..am associated with it, Then
PK(E1) U PK(E2) U ……….. U PK (En) U {a1, a2, …..am }describes
an individual relationship in set R.

• In both the above cases the combination

of primary keys of the participating
entity sets forms a super key of a
relationship set
set.
¾ (customer-id, account-number) is
the super key of depositor
¾ NOTE: this means a pair of entity
sets can have at most one
relationship in a particular
relationship set.
¾ E.g. if we wish to track all
access-dates to each account
by each customer, we cannot
assume a relationship for each
access. We
W can use a
multivalued attribute though
• A super key of an entity set is a CREATE TABLE depositor (
set of one or more attributes
whose values uniquely Account-number CHAR (9),
determine each entity. Customer-id Number(6),
Access-date DATE
PRIMARY KEY (account-number
,customer-id,))

6
 3/8/2011

Representation of Relationship Sets

and its attributes
• Suppose Relationship set is One-to-One
– PK(depositor) = PK(customer) OR PK(account)
• Suppose
S R
Relationship
l ti hi sett is
i Many-to-One
M t O
PK(depositor) = PK(customer)
• Suppose Relationship set is Many-to-Many
PK(depositor) = PK(customer) U PK(account)
• Placement of Relationship Attributes
– If Relationship is one-to-one
• Relationship attribute can be associated with either one of the participating.
– If Relationship is one-to-many
• access
access_date,
date, which specifies when the customer last accessed that account, could be
associated with the entity set account I.e. Many side of the relationship.
– If Relationship is many-to-many
• In this case the access_date must be an attribute of the depositor relationship set
rather than either one of the participating entities.

Relationship Conversion
• Mapping 1:1 Relationships
– In a 1:1 binary relationship between two entity types S and T, choose one of
them (say S) as the “base” relation.
– If either S or T has a total participation
participation, choose that one as the base.
base
– Include the primary key of the other entity type as a foreign key of the base.
– Include any relationship attributes as attributes of the base
– two partial participations → one foreign key from one base relation to another
– two total participations → as above or merge(Only appropriate if the individual
relations are not needed in other constructions.)

Secretary
Deptid EmpNo
p
Manager
Department 1 1 (EmpNo,
Managed by Manager Dept_id,
Secretary, …)

7
 3/8/2011

1:1 (Partial:Total participation)

• Every machine has exactly one employee, so
we can post the employee number into the
Machine table as a foreign key
– Emp (emp#, …….)
– Machine (machine#, emp#, hours…...).

Post BASE
1 1
Employee works on Machine

hours

1:1 (Partial: Partial participation)

• We can’t use POSTING (why not?)
• Therefore, the relationshipp must be represented
p byy a new table
– Emp (emp#, …….)
– Machine (machine#, …….., )
– Works_on (emp#, machine#, ……..)
or
Works_on (emp#, machine#, ……..) Either can be the identifier.

Table required

1 1
Employee works on Machine

8
 3/8/2011

1:1 Total : Total participation

• Every employee works on exactly one machine, and every machine is worked on
by exactly one employee
• We could post both ways!
– Emp ( emp#, emp_name,machine)
– Machine (machine#, machine_location …….., )
or
– Emp ( emp#, emp_name)
– Machine (machine#, machine_location emp# )
• This should be collapsed into one table(merge)
Emp (emp#, emp_name,….., machine#,machine_location……..)
• Basically avoid this pattern in ERDs - it usually means the two entities are really
g, and is rarelyy correct.
the same thing,

1 1
Employee works on Machine

Mapping 1:M Relationships

• For each binary 1:N relationships, identify the
relation S that represents the entity type on the N side.
• Use
U thithis as th
the bbase andd create
t a relation
l ti including
i l di the
th
key of the other entity type as a foreign key.
(Each entity type on the N side is related to at most
one entity on the 1 side).
Employee
EmpNo ((EmpNo,
p ,
D tid
Deptid
Dept_id, Ename
Ename BASE
…)
Employee WorksIn Department
M 1 Department(dept_id…)

Many side contain the information of the one side

9
 3/8/2011

1:M – many end total

• Every Machine has exactly one Employee, so we can
post the primary key of Employee into the Machine table,
th fforming
thus i a foreign
f i key:
k
Emp (emp#, …….)
Machine (machine#, emp#, ……..)
• This is the most common pattern on any ERD

Post

1 M
Employee works on Machine

1:M – Many end Partial

• We can’t use POSTING (why?) so we need a relationship table
• Put the Primary Keys from each end in the new table
– Emp (emp#, …….) Machine: (machine#, ……..)
– Works_on (machine#, emp#, ……..)
• For a 1:M relationship table the many end always provides the
Primary Key (Why? Remember the primary key determines each
attribute)
• We add a “table required” note to the diagram, but we do not add a
new entity.

t bl required
table i d
1 M
Employee works on Machine

10
 3/8/2011

M:M Relationships
• In a M:M binary relationship, it is not possible to collapse
p into any
the relationship y one of the entity
y types,
yp since the
relationship does not identify either entity type uniquely.
• A separate relation is required to complete the mapping.
• Irrespective of the participation conditions, three tables
are always produced in these relationships

M M
Employee works on Machine

Example
Mapping M:M Relationships
EmpNo RecordNo Dept id
Dept_id

Employee(E1) DeputedTo(S)
M Department(E2)
M

• The new relation S has, as foreign keys, the primary key of each of E1
and E2.
• Include primary key pairs which “match” in the relationship Rel
• Also include any attributes directly associatedwith Rel.
• The Tables would be
Employee (EmpNo, …)
Department (Dept_id, …)
DeputedTo (EmpNo, Dept_id, RecordNo, …)

11
 3/8/2011

N-ary Relationship Types

• For each n-ary
relationship type
• Include as foreign key
attributes all primary
• keys of participating entity
types
– Any attributes of the given
relationship type
– Primary key is combination
of all foreign keys
• Exception if cardinality
constraint is 1.
• E.g. one supplier for a
particular part/project
combination
• Primary Key =
{PRNO,PNO} not
{PRNO,PNO,SNO}

Example II

note that the role name of a component entity set should

be pretended to its primary key attributes, if supplied

12
 3/8/2011

Example
Conversion of Company Database into Relational Schema
• We developed the following ERD of the Company database when studying ERD lecture of the
required design
• The next slide shows the equivalent relational schema of the following obtained ERD

EMPLOYEE
Fname Minit Lname SSN Bdate Address Gender Sal Superssn DNO

DEPARTMENT
Dname Dnumber Mgrssn Mgrstartdate

DEPT_LOCATIONS
Dnumber DLocation

PROJECT
Pname Pnumber Plocation Dnum

WORKS ON
WORKS_ON
Essn Pno Hours

DEPENDENT
ESSN Dependent_name Gender Bdate Relationship

13
 3/8/2011

Explanation
• The relations (of strong entities) of Employee, Department and Project have
been shown with the Primary keys of SSN, Dnumber & Pnumber.
• The relation (of weak entity) of Dependent is shown with primary key SSN
(owner entity Employee) in combination of the partial primary key of
dependent which is dependent_name.
• To map the binary relationship (of 1:1) that is manages (here the
participation is total that is every department has a manager) therefore we
include the Primary key of the Employee relation as foreign key in the
department relation and rename it as Mgrssn
• To map the binary relationship (of 1:N) that is Works_for, Controls and
Supervision.
– For Works_for we include the Primary key Dnumber of the Department relation
as foreign key in the Employee relation and call it DNO
DNO.
– For Supervision we include the Primary key of the Employee relation as foreign
key in the employee relation itself – since the relationship is recursive- and call it
superssn
– The controls relationship is mapped to the foreign key attribute Dnum of Project,
which references the Primary key Dnumber of the Department relation

• To map the binary relationship (of M:N) that is

Works_on we create a new relation Works_on
by including the Primary keys of the Project and
Employee relation as foreign keys and rename
them as Pno and Essn respectively. Don’t forget
to include hours attribute. The PK is composite
that is {Pno, Essn}.
• To map the multivalued attribute we create a
new relation DEPT
DEPT_LOCATIONS.
LOCATIONS (for the
location attribute of department). The Primary
key is the combination of the {Dnumber,
Dlocation}

14