Chapter 4

Relational Database Design -

Mapping ERD to Relational
• 4.1 Database Design-ER to Relational:
• Transforming ERD into Relations:
Transforming or (Mapping) E-R diagrams to relations
is a straightforward process with well-defined set of
rules.
• Step 1: Map Regular Entities
• Step 2: Map Weak Entities
• Step 3: Mapping of Binary 1:1 Relation Types
• Step 4: Mapping of Binary 1:N Relationship Types.
• Step 5: Mapping of Binary M:N Relationship Types.
 1. Map Regular Entities

Each regular entity type in an ERD is transformed into

a relation as follows:

Entity Relation
Entity Name Relation Name
Simple Attribute Attribute of the relation
Entity Identifier Primary key of relation
Composite Attribute Set of component attributes
Multi-valued Attribute New relation with PK
 First Name
Emp No
Mid Initials Location
NID Emp Name
Last Name Dept Name
Address
Phone
Dept No

Department
Employee

Salary Employees
Employee (Emp_No, NID, Address,
Gender
Salary, Gender, DOB,
DOB
First_Name, Mid_Initials, Last_Name)
Department(Dept_No, Dept_Name, Phone)
FK
Dept_Location(Dept_No, Location)
 2. Map Weak Entities
Each weak entity type in an ERD is transformed into a
relation.

Entity
Entity Name
Simple attribute
Owner entity identifier
Entity identifier (partial)
Composite attribute
Multi-valued attribute
Relation
Relation Name
Attribute of the relation
Foreign key attribute
Composite key together
with PK of owner as FK
Set of component attributes
New relation with PK
 Emp No
Employee

has

Dependent Depd Name

Gender
Relation DOB

Dependent( Emp_No, Depd_Name, Gender, DOB, Relation)

FK
Employee (Emp_No, ….)
 3. Map Binary Relationships
Procedure depends on both the degree of the
binary relationships and the cardinalities of
the relationships.

• Map Binary One-to-One Relationships

• Map Binary One-to-Many Relationships
• Map Binary Many-to-Many Relationships
 Map Binary One-to-One Relationships
Create a relation for the two entity types
participating in the relationships
Include PK of one of the relations as a foreign key
of the other relation.
 So for 1:1 optional relationships, take the primary
key from the `mandatory end' and add it to the
`optional end' as a foreign key.
 So, given entity types A and B, where A <->B is a
relationship where the A end it optional, the result
would be:
 
•  A (primary key,attribute,...,foreign key to B)
•  B (primary key,attribute,...)
• Include any attributes of the relationship to the same
relation.
• Example below shows the One-One relationship
mapping of Employee and Department where
Mandatory end is Department and Optional end is
Employee.
 First Name
Emp No
Mid Initials
NID Emp Name Location
Last Name
Address Dept Name
Phone
Dept No

Start d
Employee Department

Salary manage
Employees
Gender
DOB Employee (Emp_No, NID, Address,
Salary, Gender, DOB, First_Name,
Mid_Initials, Last_Name, Dept_No) FK
Department(Dept_No, Dept_Name, Phone , Manager NN
Start_D)
 Map Binary One-to-Many Relationships

Create a relation for the two entity types

participating in the relationships.

Include PK of the entity in the one-side of

the relationship as a foreign key in the
relation of the many side of the relationship

Include any attributes of the relationship to

the relation of the many side.
 Location
Dept Name
Phone
Dept No

Department(Dept_No,
Department
Dept_Name, Phone)

Employees
control
Proj No
Project (Proj_ No, Proj_Name,
Location , Dept_No) Project

FK
Location Proj Name
 Map Binary Many-to-Many Relationships

Create a relation for the two entity types

participating in the relationships.

Create new relation and include PK of each

of the two participating entity types as FK.
These attributes become the PK (composite).

Include any attributes of the relationship to

the new relation.
 First Name
Emp No
Mid Initials
NID Emp Name
Last Name
Address
Employee (Emp_No, NID, Address,
Salary, Gender, DOB, First_Name,
Mid_Initials, Last_Name, Dept_No)
Employee
Project (Proj_ No, Proj_Name,
Salary
Hours Location, Dept_No)
Gender works on FK/NN
DOB Works_On (Emp_No, Proj_No, Hours)
FK/NN FK/NN
Project

Location Proj Name Proj No

• Note:
• 1-1 Relationships:
Depending on the optionality of the relationship, the
entities are either combined or the primary key of one
entity type is placed as a foreign key in the other
relation.
• 1-M Relationships:
• The primary key from the `one side' is placed as a
foreign key in the `many side'.
• M-N Relationships:
• A new relation is created with the primary keys from
each entity forming a composite key.
4.2 Functional Dependencies

Functional dependency:
A constraint between two attributes or two sets of
attributes.
• Normalization is based on the analysis of
functional dependencies.
• The functional dependency of B on A is represented
by an arrow: A  B i.e B is dependent on A.
EX: ENO  Name, Address, Birth date (Employee)
VID  Make, Model, Colour (Vehicle)
ISBN  Title, First Author (Book)
• In the above example EMPNO is the Primary Key .
With the help of the primary key we identify the
record uniquely.
• So, EMPNO is called key attribute or determinant
attribute and rest of the attributes i.e Name, Address,
Birth date are called non-key attributes.
• So the attribute on the left hand side of the arrow is
called Key attribute and on the right hand side of
arrow are called non-key attributes.
• Therefore non-key attributes are functionally
dependent on key attribute.
• So each and every relation must have at least one key
attribute.
• 4.3 Normalization:
• E-R diagrams help use with overall design, but a good
conceptual design does not necessarily lead to a good
table structures.
• Tables are the basic building blocks of the database in
RDBMS.
• We wish to avoid data anomalies/redundancies by
controlling the table structure.
• Data redundancy :
• Storing data multiple times.
Too much data redundancy causes problems like
which value is correct?
Logical Database Design -
Normalisation
Normalisation

Is derivation of data as a set of

Non-Redundant,

Consistent and

Inter-Dependent Relations
Normalisation

• Normalisation is a set of data design

standards.
• It is a process of decomposing
unsatisfactory relations into smaller
relations.
• Like entity–relationship modelling were
developed as part of database theory.
Normalisation - Advantages

Reduction of data redundancy within tables:

- Reduce data storage space
- Reduce inconsistency of data
- Reduce update cost
- Remove many-to-many relationship
- Improve flexibility of the system
Normalisation - Disadvantages

Reduction in efficiency of certain data

retrieval as relations may be joined during
retrieval.
- Increase join
- Increase use of indexes: storage (keys)
- Increase complexity of the system
Normal Forms
A state of a relation that results from applying
simple rules regarding functional dependencies
(or relationships between attributes) to that
relation.

0NF multi-valued attributes exists

1NF any multi-valued attributes have been removed
2NF any partial functional dependencies have been
removed
3NF any transitive dependencies have been removed
Functional Dependencies and Keys

Functional dependency:A constraint between

two attributes or two sets of attributes
The functional dependency of B on A is
represented by an arrow: A  B
e.g.
NID (SSN)  Name, Address, Birth date
VID  Make, Model, Colour
ISBN  Title, First Author
Functional Dependencies and Keys

Functional dependency (definition)

For any relation R (e.g. book), attribute B (e.g.
title) is functionally dependent on attributes A
(e.g. ISBN), if for every valid instance of A (e.g.
981-235-996-6), that value of A uniquely
determines the value of B (e.g. Modern
Database Management)
Input for the Normalisation Process
Database Design process (phase 1)
data requirements and data analysis

entity types (e.g. Supplier, Order)

attributes describing each entity type with its
meaning (e.g. supplier name and part name)
attributes relationships to other attributes.
(e.g.supplier no of Supplier to supplier no of
purchase Order)
• There are ‘6’ types of Normal forms:
1. First Normal Form (1NF)
2. Second Normal Form (2NF)
3. Third Normal Form (3NF)
4. BCNF (Boyce–Codd Normal form)
5. Fourth Normal Form.
6. Fifth Normal Form.
• Most professionally designed databases uses up to
Third Normal Form (3NF).
• 1NF:
• Any Multi-valued (or repeating groups that are present)
must have been removed, so there is a single/atomic value
at the intersection of each row and column of the table.
• And there should be a unique key to identify a table
uniquely i.e done by Primary key.
• 2NF:
• Should be in 1NF and any partial functional dependencies
have been removed i.e every non-key attribute must
depend on full set of primary key attribute.
• 3NF:
• Should be in 2NF and any Transitive dependencies have
been removed.
• BCNF:
• Should be in 3NF and any anomalies or errors that
resulted from functional dependencies must be
removed.
• 4NF:
• Should be in 4NF and any multi-valued dependencies
have been removed.
• 5NF:
• Should be in 4NF and any remaining anomalies have
been removed.
First Normal Form - 1NF:

1. A relation is said to be in First Normal Form (1NF)

if ALL its attributes are ATOMIC i.e single-
valued.

2. And there are no repeating groups it is done by

eliminating duplicate columns from the same table,
and create separate tables for each group of related
data into separate tables, each with a unique row
identifier i.e (primary key) should be defined.
Purchase Order - Attribute Analysis
ATTRIBUTE TYPE LEN- DESCRIPTION
GTH
PO-NO N 3 Unique purchase order (PO) number.
Many parts can be ordered in one PO
PO-DATE D 8 DDMMYYYY date when PO written
EMP-CODE C 2 Unique code of employee who wrote
the PO
SUPP-NO N 3 Unique number assigned to supplier
SUPP-NAME C 20 Supplier name
PART-NO N 2 Unique number assigned to each part
PART-DESC C 10 Part description
PART-QTY N 2 Quantity of parts ordered in given PO
Key PO-NO
 Purchase Order Relation in 0NF
PO- PO-DATE EMP- SUPP SUPP- PART PART- PART
NO CODE -NO NAME -NO DESC -QTY
111 01012001 M2 222 AC Stores P1 Nut 10
P2 Bolt 5
P3 Nail 3
P5 Screw 6
112 01012001 S3 105 I Hardware P2 Bolt 2
P5 Screw 1
113 02012001 S1 111 BC Trading P1 Nut 3
P3 Nail 4
114 02012001 M2 150 DO Service P6 Plug 5
115 03012001 S1 222 AC Stores P7 Pin 8
116 04012001 S1 100 LM Centre P8 Fuse 2
 Normalisation Process
Apply a set of 0NF Relations
normalisation 1NF Relations
rules to all the 2NF Relations
attributes of the 3NF Relations
entity types Optimised
Relations
identified in the
data
requirement
step.
Output of the Normalisation Process
• A list of normalised entity types in at
least third normal form (3NF), such
that all non-key attributes of each
entity type fully depend on the whole
key and nothing but the key
 First Normal Form - 1NF
A relation is in First Normal Form (1NF) if
ALL its attributes are ATOMIC.
ie. If there are no repeating
groups.
If each attribute is a
primitive.
e.g. integer, real number, character
string,
but not lists or sets
non-decomposable data item
single-value
Purchase Order Relation in 0NF

PO( PO-NO, PO-DATE, EMP-CODE, SUPP-NO,

SUPP-NAME, PARTS-ORDERED{PART-
NO, PART-DESC, PART-QTY})

Within a single purchase order we could

find several part numbers, part descriptions
and part quantities. Hence, parts ordered
can be decomposed.
 Purchase Order Relation in 0NF
PO- PO-DATE EMP- SUPP SUPP- PART PART- PART
NO CODE -NO NAME -NO DESC -QTY
111 01012001 M2 222 AC Stores P1 Nut 10
P2 Bolt 5
P3 Nail 3
P5 Screw 6
112 01012001 S3 105 I Hardware P2 Bolt 2
P5 Screw 1
113 02012001 S1 111 BC Trading P1 Nut 3
P3 Nail 4
114 02012001 M2 150 DO Service P6 Plug 5
115 03012001 S1 222 AC Stores P7 Pin 8
116 04012001 S1 100 LM Centre P8 Fuse 2
 First Normal Form - 1NF
• 1NF deals with the shape of a record
type
• All occurrences of a record type must
contain the same number of fields
• A relational schema is at least in 1NF
 1NF - Actions Required
1) Examine for repeat groups of data
2) Remove repeat groups from relation
3) Create new relation(s) to include
repeated data
4) Include key of the 0NF to the new
relation(s)
5) Determine key of the new relation(s)
 Purchase Order Relations in 1NF
PO PO-PART
PO- PO- EMP- SUP SUPP- PO- PAR PART- PART
NO DATE CODE P-NO NAME NO T-NO DESC -QTY
111 01012001 M2 222 AC Stores 111 P1 Nut 10
112 01012001 S3 105 I Hardware 111 P2 Bolt 5
113 02012001 S1 111 BC Trading 111 P3 Nail 3
114 02012001 M2 150 DO Service 111 P5 Screw 6
115 03012001 S1 222 AC Stores 112 P2 Bolt 2
116 04012001 S1 100 LM Centre 112 P5 Screw 1
113 P1 Nut 3
113 P3 Nail 4
114 P6 Plug 5
115 P7 Pin 8
116 P8 Fuse 2
 Problems - 1NF
1. INSERT PROBLEM
cannot know available parts until an order is placed
(e.g. P4 is bush)

2. DELETE PROBLEM
loose information of part P7 if we cancel purchase
order 115 (i.e. Delete PO-PART for Part No P7)

3. UPDATE PROBLEM:
to change description of Part P3 we need to change
every tuple in PO-PART containing Part No P3
 Second Normal Form - 2NF
A relation is in 2NF if it is in 1NF and every
non-key attribute is dependent on the
whole key

i.e. Is not dependent on part of

the key only.
 PO-PART Relation (Parts Ordered)
in 1NF
PO-PART( PO-NO, PART-NO, PART-DESC,
PART-QTY)

Part Description is depended only on Part

No, which is part of the key of PO-PART.
Parts Ordered Relation in 1NF
PO- PART PART- PART
NO -NO DESC -QTY
111 P1 Nut 10
111 P2 Bolt 5
111 P3 Nail 3
111 P5 Screw 6
112 P2 Bolt 2
112 P5 Screw 1
113 P1 Nut 3
113 P3 Nail 4
114 P6 Plug 5
115 P7 Pin 8
116 P8 Fuse 2
 Second Normal Form - 2NF
Deals with the relationship between non-key
and key fields

A non-key field cannot be a fact about a

subset of a key

It is relevant when the key is composite, i.e.

consists of several fields
 2NF - Actions Required
If entity has a concatenated key

1) Check each attribute against the whole

key
2) Remove attribute and partial key to
new relation
3) Optimise relations
 Parts Ordered Relations in 2NF
PO-PART
PO- PART PART PART
NO -NO -QTY
111 P1 10 PART PART-
111 P2 5 -NO DESC
111 P3 3 P1 Nut
111 P5 6 P2 Bolt
112 P2 2 P3 Nail
112 P5 1 P5 Screw
113 P1 3 P6 Plug
113 P3 4 P7 Pin
114 P6 5 P8 Fuse
115 P7 8
116 P8 2
 Purchase Order Relations in 2NF
PART PAR PART-
T-NO DESC
P1 Nut PO-PART
P2 Bolt PO- PAR PART
P3 Nail NO T-NO -QTY
P5 Screw 111 P1 10
P6 Plug 111 P2 5
P7 Pin 111 P3 3
PO P8 Fuse 111 P5 6
112 P2 2
PO- PO- EMP- SUP SUPP-
112 P5 1
NO DATE CODE P-NO NAME
113 P1 3
111 01012001 M2 222 AC Stores
113 P3 4
112 01012001 S3 105 I Hardware
114 P6 5
113 02012001 S1 111 BC Trading
115 P7 8
114 02012001 M2 150 DO Service
116 P8 2
115 03012001 S1 222 AC Stores
116 04012001 S1 100 LM Centre
 Problems - 2NF
1. INSERT PROBLEM
cannot know available suppliers until an order is
placed (e.g. 200 is hardware stores)

2. DELETE PROBLEM
loose information of supplier 100 if we cancel
purchase order 116 (i.e. Delete PO for Supplier No
100)

3. UPDATE PROBLEM
to change name of Supplier 222 we need to change
every tuple in PO containing Supplier No 222
 Third Normal Form - 3NF
A relation is in 3NF if it is in 2NF and each
non-key attribute is only dependent on
the whole key, and not dependent on any
non-key attribute.

i.e. no transitive dependencies

 PO Relation in 2NF

PO( PO-NO, PO-DATE, EMP-CODE, SUPP-NO,

SUPP-NAME)

Supplier name is a non-key field depended

on another non-key field (i.e. the supplier
no) in addition to be depended on the key
purchase order no
 Third Normal Form - 3NF
Deals with the relationship between non-key
fields

A non-key field cannot be a fact about

another non-key field
 3NF - Actions Required
1) Check each non-key attribute for
dependency against other non-key fields
2) Remove attribute depended on another non-
key attribute from relation
3) Create new relation comprising the attribute
and non-key attribute which it depends on
4) Determine key of new relation
5) Optimise
PO and SUPPLIER Relations in 3NF

PO
SUPPLIER
PO- PO-DATE EMP- SUPP
NO CODE -NO SUPP SUPP-
-NO NAME
111 01012001 M2 222
112 01012001 S3 105 100 LM Centre
113 02012001 S1 111 105 I Hardware
114 02012001 M2 150 111 BC Trading
115 03012001 S1 222 150 DO Service
116 04012001 S1 100 222 AC Stores
 Purchase Order Relations in 3NF
SUPPLIER SUP SUPP-
P-NO NAME
PART PO-PART
222 AC Stores
105 I Hardware PAR PART- PO- PAR PART
111 BC Trading T-NO DESC NO T-NO -QTY
150 DO Service P1 Nut 111 P1 10
222 AC Stores P2 Bolt 111 P2 5
100 LM Centre P3 Nail 111 P3 3
PO P5 Screw 111 P5 6
PO- PO- EMP- SUP P6 Plug 112 P2 2
NO DATE CODE P-NO P7 Pin 112 P5 1
111 01012001 M2 222 P8 Fuse 113 P1 3
112 01012001 S3 105 113 P3 4
113 02012001 S1 111 114 P6 5
114 02012001 M2 150 115 P7 8
115 03012001 S1 222 116 P8 2
116 04012001 S1 100
• Advantages of Normalization:
• Normalization provides numerous benefits to a
database. Some of the major benefits include the
following:
• Greater overall database organization.
• Reduction of redundant data.
• Saves the disk space and simplify the structure of
data.
• Data consistency within the database.
• A much more flexible database design.
• A better handle on database security.
• Disadvantages of Normalization:
• Requires much more CPU, memory, and I/O
to process thus normalized data gives reduced
database performance.
• Queries run slower because of the joins.
• Poorly-written query can bring the database
down
• Maintenance overhead:
• The higher the level of normalization, the
greater the number of tables in the database.
 Further Normalization
• BCNF or Boyce–Codd Normal form
• 4th Normal form
• 5th Normal form
In a normal situation normalization up-to 3NF is quite
sufficient.Certain relations may even be de-normalized on
account of efficiency. The Normalizations which are
discussed next are not practically enforced most of the
time.
• But a relation in 3NF does not guarantee that all
anomalies have been removed, hence the additional
normalizations.
• Lossless Joins:
A relation schema ‘R’ can be decomposed into a
collection of relation schemas to eliminate some of
the anomalies contained in the original relation
schema ‘R’.
• Any such decomposition requires the information
contained in the original relation to be maintained i.e
the join of the decomposed relation should give the
same set of tuples as the original relation then such a
decomposition is called as lossless join
decomposition.
• The lossless join decomposition enables any
relation to be recovered from the
decompositions by a series of natural joins.
• Such decomposition contains the same data as
the original relation.
• Dependency Preserving Dependency:
• If R is decomposed into X, Y and Z, and we
enforce the FDs that hold on X, on Y and on
Z, then all FDs that were given to hold on R
must be hold.