Conversion of ER Model to Relational

Schema
• Step 1:
–For each strong entity type in the ER
diagram, create a relation that includes
all the simple attributes of the entity.
• Any composite attribute must be
represented as a basic attribute.
• Omit multi-valued/derived attributes.
• Step 2:
– For each weak entity type create a new
relation.
• Include all the attributes of the weak
entity.
• Add the primary key of the strong entity
(owner entity) as a foreign key.
• The primary key of the weak entity will
be a combination of the key attribute of
the owner entity and the partial key of the
weak entity.
 ENO TelNO DNO

Employee HAS Dependent

EName Salary Relationship

FName LName

Employee
ENO FName LName TelNO Salary
Dependent

Partial Key
ENO DNO Relationship

Primary Key
• Step 3:

– For binary 1:1 relationships select any side of the

relation (but it’s better to choose an entity type with
a total participation).

• Indicate the primary key on one relation as the

foreign key in the other relation.

• Include all simple attributes of the 1:1

relationship type as an attribute of the chosen
entity type.
ENO TelNO DNO Location

1 1
Employee Manages Department

EName Salary DName

# of Employees
FName LName
S.d
ate
Employee

ENO FName LName TelNO Salary

Department
DNO DName StartDate MemNO
• Step 4:
– For 1:M relationships select the many side of the
relation and indicate the primary key of the one
side as the foreign key of the many side.

LNO Title CNO

Name

Lecturer 1 M
Teach Course

Address CName Duration

Telephone
 Lecturer
LNO Title Name Address Telephone

Course
CNO CName Duration LNO
´ Step 5:
´ For M:N relationships create a new relation.
´ Contain the primary keys of the two relations and any attributes on the relationship
type.

´ Step 6:
´ For multi-valued attributes create a new relation containing the:

´ Multi-valued attribute and the primary key of

the entity.
´Step 7:
´ For n-ary relationship types create a new relation.

´Include attributes of the relationship type, all

primary keys of the entities participating in the n-
ary relationship.

SNO PNO
Qty

M
Supplier Supply N Project

SName

Parts PartNO
Supply

SNO PartNO PNO Qty

Primary Key
Convert the following ER Diagram to relational
model.
 Functional Dependency
´ A functional dependency is a relationship between attributes, such that an attribute
‘B’ is said to be functionally dependent on another attribute ‘A’, if the value of ‘A’ at
all times determines the value of ‘B’.
´ Functional dependency is indicated as:
´ A B {B is functionally dependent on A}

•A set of attributes X functionally determines a set of

attributes Y if the value of X determines a unique
value for Y
• X -> Y holds if whenever two tuples have the
same value for X, they must have the same value
for Y
• For any two tuples t1 and t2 in any relation
instance r(R): If t1[X]=t2[X], then t1[Y]=t2[Y]
• Written as X -> Y; can be displayed graphically on
a relation schema as in Figures. ( denoted by the
arrow: ).
• FDs are derived from the real-world constraints on
the attributes
´ Example on Student (sid, name, supervisor_id, specialization):

´{supervisor_id} ® {specialization} means

´If two student records have the same
supervisor, then their specialization (e.g.,
Databases) must be the same
´On the other hand, if the supervisors of 2
students are different, we do not care about
their specializations.
Examples of FD constraints (1)

• social security number determines employee name

SSN -> ENAME
• project number determines project name and
location
PNUMBER -> {PNAME, PLOCATION}
• employee ssn and project number determines the
hours per week that the employee works on the
project
{SSN, PNUMBER} -> HOURS
Normalization

´ It is a process of decomposing unsatisfactory relations to smaller relations.

´ Normalization helps eliminate redundancy, organizes data efficiently and reduces
potential anomalies during data operations (insertion, updating and deletion
operations).
 Assume the position determines the salary:
T1 position → salary
first_nam last_nam departmen salar
address position
e e t y
Dewi Srijaya 12a Jln Lempeng Toys clerk 2000

Izabel Leong 10 Outram Park Sports trainee 1200

John Smith 107 Clementi Rd Toys clerk 2000

Redundant storage
Axel Bayer 55 Cuscaden Rd Sports trainee 1200

Winny Lee 10 West Coast Rd Sports manager 2500

Sylvia Tok 22 East Coast Lane Toys manager 2600 Update anomaly
Eric Wei 100 Jurong drive Toys assistant 2200
manager
? ? ? ? security guard 1500

key
Potential deletion anomaly

Insertion anomaly
 EXAMPLE OF AN UPDATE
ANOMALY
Consider the relation:
EMP_PROJ ( Emp#, Proj#, Ename, Pname,
No_hours)

• Update Anomaly: Changing the name of project

number P1 from “Billing” to “Customer-
Accounting” may cause this update to be made for
all 100 employees working on project P1.
• Insert Anomaly: Cannot insert a project
unless an employee is assigned to .
Inversely - Cannot insert an employee
unless an he/she is assigned to a project.
• Delete Anomaly: When a project is
deleted, it will result in deleting all the
employees who work on that project.
Alternately, if an employee is the sole
employee on a project, deleting that
employee would result in deleting the
corresponding project.
´The main normal forms are:
´First Normal Form (1NF)
´Second Normal Form (2NF)
´Third Normal Form (3NF)
´Boyce Codd Normal Form (BCNF)
 First Normal Form (1NF)

´A domain is atomic if elements of the domain are

considered to be indivisible units. We say that a
relation schema R is in first normal form (1NF) if the
domains of all attributes of R are atomic.
´A set of names is an example of a non atomic value.
For example, if the schema of a relation employee
included an attribute children whose domain elements
are sets of names, the schema would not be in first
normal form.
´Composite attributes, such as an attribute address with
component attributes street and city, also have
nonatomic domains.
´ 1NF also disallows composite attributes that are themselves multi-valued. These are
called nested relations because each tuple can have a relation within a relation.

´ Example 1:
´ Emp _Project{ENO, EName {PNO, Hours}}

´This relation Project is an example of a nested

relation. Such relations are said to be un-normalized.
In order to represent the information in a relational
model, normalization must be carried out. This is
done by removing the repeating groups.
EMP_PROJ

ENO EName PNO Hours

100 Nimal 4 100

100 Nimal 7 40

100 Nimal 2 150

200 Sunil 2 100

200 Sunil 1 5
 EMPLOYEE
ENO EName

EMP-PROJ

ENO PNO Hours

Second Normal Form (2NF)
• Uses the concepts of FDs, primary key
Definitions:
• Prime attribute - attribute that is member of the
primary key K
• Full functional dependency - a FD Y -> Z where
removal of any attribute from Y means the FD does
not hold any more
Examples: - {SSN, PNUMBER} -> HOURS is a full
FD since neither SSN -> HOURS nor PNUMBER -
> HOURS hold
- {SSN, PNUMBER} -> ENAME is not a full FD
(it is called a partial dependency ) since SSN ->
ENAME also holds
• A relation schema R is in second normal
form (2NF) if every non-prime attribute A
in R is fully functionally dependent on the
primary key

• R can be decomposed into 2NF relations via

the process of 2NF normalization
 Example
Emp_Proj

SSN PNumber Hours EName PName

FD1

FD2
FD3
• Is in 1NF but not it 2NF.
– Reason:
• The nonprime attribute ENAME violates
2NF because of FD2, as do the nonprime
attributes PNAME and PLOCATION
because of FD3.
– The functional dependencies FD2 and FD3
make ENAME, PNAME and PLOCATION
partially dependent on the primary keys
{SSN, PNUMBER} of EMP-PROJ, thus,
violating the 2NF test.
• If a relation schema is not in 2NF, it can be
“second normalized” or “2NF normalized”
into a number of 2NF relations in which
nonprime attributes are associated only with
the part of the primary key on which they are
fully functionally dependent.
EMP_PROJ

SSN PNUMBER HOURS ENAME PNAME PLOCATION

2nd Normalization

EP1
SSN PNUMBER HOURS

EP2
SSN ENAME

EP3
PNUMBER PNAME PLOCATION
Third Normal Form (3NF)
Definition:
• Transitive functional dependency - a FD X -> Z
that can be derived from two FDs X -> Y and
Y -> Z . And Y should not be a candidate key.
Examples:
- SSN -> DMGRSSN is a transitive FD since
SSN -> DNUMBER and DNUMBER ->
DMGRSSN hold
- SSN -> ENAME is non-transitive since there is
no set of attributes X where SSN -> X and
X -> ENAME
 EMP_DEPT

ENAME SSN BDATE ADDRESS DNUMBER DNAME DMGRSSN

´ SSN DMGRSSN - Transitive Dependency

´ Reason:
´ SSN DNUMBER
´ DNUMBER DMGRSSN
´ DNUMBER is neither a key itself nor a subset of the key of EMP_DEPT.
 ´A relation R is in 3NF if it satisfies 2NF and no
nonprime attribute of R is transitively dependent on the
primary key.
EMP_DEPT
ENAME SSN BDATE ADDRESS DNUMBER DNAME DMGRSSN

3NF Normalization

SSN ENAME BDATE ADDRESS DNUMBER

DNUMBER DNAME DMGRSSN

Normal Form Test Remedy
(Normalization)

First (1NF) Relation should Form new relations

have no non atomic for each non-
attributes or nested atomic attribute or
relations. nested relation.
Normal Form Test Remedy
(Normalization)
Second (2NF) For relations Decompose and
where primary key set up a new
contains multiple relation for each
attributes, non-key partial key with its
attribute should be dependent
functionally attributes. Make
dependent on a sure to keep a
part of the PK. relation with the
original PK and
any attributes that
are fully
functionally
dependent on it.
Normal Form Test Remedy
(Normalization)
Third (3NF) Relation should Decompose and
not have a non key set up a relation
attribute that includes the
functionally non key
determined by attribute(s) that
another non key functionally
attribute (or a set determines other
of attributes) i.e. non key
there should be no attribute(s).
transitive
dependency of a
non key attribute
on the PK.
Boyce – Codd Normal Form (BCNF)

´ A relational schema R is in BCNF if whenever a functional

dependency X A holds in R then X is a super key of R.
´ Example:
´ COURSES(CIDNO, TITLE, INAME, PHONE) with the FDs
´ CIDNO TITLE,INAME,PHONE
´ INAME PHONE

is not in BCNF because the FD

“INAME PHONE”
is not implied by a key:
´ “INAME” is not a key of the entire relation.