Transformation from

ER Diagram to Relational
Database Schema
IT8 – Database Management Systems

Jeanely A. Esperanza
Instructor

10/9/20 1
Transformation
 Involves the transformation of the ER diagram
to a complete database scheme
 Entity set in the ER model become tables in a

relational database
 The relationships become the source of

foreign keys that integrate the resulting table

together
 Based on the mapping cardinalities & entity

participation of the relationship

10/9/20 2
Given
 Let:
◦ E1 and E2 be entity sets
◦ R be a relationship that associates E1 & E2
 ER Diagram:

attrR
attrE2
pkE1
pkE2
attrE1

E1 R E2

10/9/20 3
Rule 1
 many-to-many regardless of entity
participation
attrR
attrE2
pkE1
pkE2
attrE1

E1 R E2

E1(pkE1,attrE1)
E2(pkE2,attrE2)
R(pkE1,pkE2,attrR)

10/9/20 4
Rule 2
 One-to-many, mandatory on the many side
regardless of entity participation on the “1”
side
attrR
attrE2
pkE1
pkE2
attrE1

E1 R E2

E1(pkE1,attrE1,pkE2,attrR)
E2(pkE2,attrE2)

10/9/20 5
Rule 3
 One-to-many, optional on the many side
regardless of entity participation on the “1”
side
attrR
attrE2
pkE1
pkE2
attrE1

E1 R E2

E1(pkE1,attrE1)
E2(pkE2,attrE2)
R(pkE1,pkE2,attrR)

10/9/20 6
Rule 4
 One-to-one, mandatory on both sides
attrR
attrE2
pkE1
pkE2
attrE1

E1 R E2

E1(pkE1,attrE1,pkE2,attrR) E1(pkE1,attrE1)
or
E2(pkE2,attrE2) E2(pkE2,attrE2,pkE1,attrR)

10/9/20 7
Rule 5
 One-to-one, mandatory on one side
attrR
attrE2
pkE1
pkE2
attrE1

E1 R E2

E1(pkE1,attrE1,pkE2,attrR)
E2(pkE2,attrE2)

10/9/20 8
Rule 6
 Optional on both sides
attrR
attrE2
pkE1
pkE2
attrE1

E1 R E2

E1(pkE1,attrE1)
E2(pkE2,attrE2)
R(pkE1,pkE2,attrR)

10/9/20 9
Weak Entity Rule

attrR
attrE2
pkE1
pkE2
attrE1

E1 R E2

E1(pkE1,attrE1,attrR)
E2(pkE2,attrE2,pkE1)

10/9/20 10
Transform the ER Diagram into a
Relational Schema
deptid deptname

works for
DEPARTMENT
empid

name
manages
EMPLOYEE
address

bdate
projid
works on
PROJECT
projname

hours

10/9/20 11
Two entities at a time
empid

name projid
works on
EMPLOYEE PROJECT
address projname

hours
bdate

Apply Rule 1: many-to-many, regardless of entity participation

EMPLOYEE(empid,name,address,bdate)
PROJECT(projid,projname)
WORKS(empid,projid,hours)

10/9/20 12
Next
empid

deptid
name
works for
EMPLOYEE DEPARTMENT
deptname
address

bdate

Apply Rule 2: one-to-many, mandatory on the “many” side

EMPLOYEE(empid,name,address,bdate,deptid)
DEPARTMENT(deptid,deptname)

10/9/20 13
And the last…
empid

deptid
name
manages
EMPLOYEE DEPARTMENT
deptname
address

bdate

Apply Rule 5: one-to-one, mandatory on the one side

EMPLOYEE(empid,name,address,bdate)
DEPARTMENT(deptid,deptname,empid)

10/9/20 14
The Complete Relational Schema

EMPLOYEE(empid,name,address,bdate
,deptid)
PROJECT(projid,projname)
DEPARTMENT(deptid,deptname,empid)
WORKS(empid,projid,hours)

10/9/20 15
Transformation & Foreign Key Issues
 Referential integrity is a vital consideration in
designing a database.
 Whenever a tuple in a referenced relation is

deleted, the cascade rule should only be

applied to the referencing tuples if there will
be no undue loss of information

10/9/20 16
One-many: optional on both sides

EMPLOYEE works PROJECT

(empid,ename) (projid,pname,startdate)
(assigndate)
 If null values are not allowed in foreign keys:
◦ EMPLOYEE(empid,ename)
◦ PROJECT(projid,pname,startdate)
◦ WORKS(empid,projid,assigndate)
 FK: empid references EMPLOYEE DELETE restrict/cascade*
projid references PROJECT DELETE cascade/restrict

10/9/20 17
Explanation
 Due to the optionality of the relationship, the
cascade rule is possible without any loss of
important data. That is, whenever an
employee is deleted from EMPLOYEE or a
project is removed from PROJECT, the
referencing tuples in WORKS can be deleted
as well.
 NOTE: if the cascade rule is allowed, the

restrict rule is also applicable.

10/9/20 18
One-many: optional on the “many”
side, mandatory on the “one” side

EMPLOYEE works PROJECT

(empid,ename) (projid,pname,startdate)
(assigndate)

 If null values are not allowed in foreign keys:

◦ EMPLOYEE(empid,ename)
◦ PROJECT(projid,pname,startdate)
◦ WORKS(empid,projid,assigndate)
 FK: empid references EMPLOYEE DELETE cascade/restrict
projid references PROJECT DELETE cascade/restrict

10/9/20 19
Explanation
 Cascade* indicates that the cascade rule
maybe used as long as the interface for
removing an employee incorporates a
checking mechanism for determining whether
that employee is the only person working for
a particular project.
 Due to the optional participation of
EMPLOYEE in the relationship WORKS, the
cascade rule is allowed. However, the
mandatory participation of PROJECT in the
relationship requires that at least one
employee working for it.
10/9/20 20
One-many: mandatory on the “many”
side, optional on the “one” side

EMPLOYEE works PROJECT

(empid,ename) (projid,pname,startdate)
(assigndate)

 Due to mandatory participation of EMPLOYEE

and the transformation rule, null values are
absolutely not allowed in the foreign key
◦ EMPLOYEE(empid,ename,projid,assigndate)
 FK: projid references PROJECT DELETE restrict/cascade
◦ PROJECT(projid,pname,startdate)

10/9/20 21
Explanation
 Despite to the optional participation of
PROJECT in relationship WORKS, the deletion
of a project must not be cascaded in
EMPLOYEE because deletion of any
referencing tuples in EMPLOYEE result in loss
of employee information.
 If however, the application really requires that

employees are automatically removed when a

project is shelved, the cascade rule must then
be used.

10/9/20 22
One-many: mandatory on both sides

EMPLOYEE works PROJECT

(empid,ename) (projid,pname,startdate)
(assigndate)

◦ EMPLOYEE(empid,ename,projid,assigndate)
 FK: projid references PROJECT DELETE restrict/cascade
◦ PROJECT(projid,pname,startdate)
 Due to the mandatory nature of the
participation of PROJECT in the relationship
WORKS, the deletion of a tuple in EMPLOYEE
might lead to a project not having an
employee working for it.

10/9/20 23
End of Lecture
Any question?