Normalization

Week 3
National College of Ireland
Dublin, Ireland.

Lecturer: Dr. Muhammad Iqbal

Email: [email protected] 1
 Outline
• Transformation of ER Diagrams into Relations
• The purpose of normalization and how normalization can be
used when designing a relational database.
• The potential problems associated with redundant data in the
base relations.
• The concept of functional dependency, which describes the
relationship between attributes.
• The characteristics of functional dependencies used in the
normalization.
• Application of first, second and third normal forms. 2
 Transforming ER Diagrams into
Relations

• Mapping Regular Entities to Relations

– Simple Attributes: E-R attributes map directly
onto the relation

– Composite Attributes: Use only their simple,

component attributes

– Multivalued Attribute: Becomes a separate

relation with a foreign key taken from the superior
entity
3
 Mapping a Regular Entity

(a) CUSTOMER
entity type with
simple attributes

(b) CUSTOMER relation

4
 Purpose of Normalization
• When we design a database, the main objective is to create an
accurate representation of the data, relationships between the
data, and constraints.
Developed by E.F. Codd (1972).

1. Normalization is a technique for producing a set of suitable

relations that support the data requirements of an enterprise.

2. Normalization uses a series of tests (12 rules of E. F. Codd) that

identify the optimal grouping of related attributes to identify a
set of suitable relations that supports the data requirements of
the enterprise. 5
 Purpose of Normalization
• Characteristics of a suitable set of relations
include:
– the minimal number of attributes necessary to support the
data requirements of the enterprise.

– attributes with a close logical relationship are found in the

same relation.

– minimal redundancy with each attribute represented only

once with the important exception of attributes that form
all or part of foreign keys.
6
 Benefits of Normalization
• The benefits of using a database that has a suitable set of
relations
– easier for the user to access and maintain the data

– take up minimal storage space on the computer

• Normalization is a formal technique that can be used at any

stage of database design.

• Normalization can be used as a validation technique to check

the structure of relations, which may have been created using
a top-down approach such as ER modeling. 7
 Data Redundancy and Update
Anomalies
• Potential benefits for implemented database include:
– Updates to the data stored in the database are achieved with a
minimal number of operations thus reducing the opportunities
for data inconsistencies.

– Reduction in the file storage space required by the base

relations thus minimizing costs.

Problems associated with data redundancy are

illustrated by comparing the Staff and Branch
relations with the StaffBranch relation. 8
 Data Redundancy and Update
Anomalies
StaffBranch

• StaffBranch (staffNo, sName, position, salary, branchNo, bAddress)

9
 Data Redundancy and Update
Anomalies
• StaffBranch relation has redundant data; the details of a branch are
repeated for every member of a staff.

• In contrast, the branch information appears only once for each branch in the
Branch relation and only the branch number (branchNo) is repeated in the
Staff relation, to represent where each member of staff is located.
• Relations that contain redundant information may potentially
suffer from update anomalies.

• Types of update anomalies include

i. Insertion
ii. Deletion
iii. Modification 10
 Insertion Anomalies

StaffBranch

• To insert the details of new members of staff into the StaffBranch

relation, we must include the details of the branch at which the staff
are to be located.
• For example, to insert the details of new staff located at branch
number B007, we must enter the correct details of branch number
B007 so that the branch details are consistent with values for branch
11
B007 in other tuples of the StaffBranch relation.
 Insertion Anomalies

StaffBranch

• To insert details of a new branch that currently has no members of

staff into the StaffBranch relation, it is necessary to enter NULLS into
the attributes for the staff, such as staffNo.

• However, staffNo is the primary key for the StaffBranch relation,

attempting to enter nulls for staffNo violates entity integrity, and is not
12
allowed.
 Deletion Anomalies

StaffBranch

• If we delete a tuple from the StaffBranch relation that represents the

last member of staff located at a branch, the details about that branch
are also lost from the database.

• For example, if we delete the tuple for staff number SA9 (Mary Howe)
from the StaffBranch relation, the details relating to branch number
B007 are lost from the database. 13
 Modification Anomalies
StaffBranch

• If we want to change
the value of one of the
attributes of a
particular branch in
the StaffBranch
relation.

• For example, the address for branch number B003, we must update the tuples
of all staff located at that branch.

• If this modification is not carried out on all the appropriate tuples of the
StaffBranch relation, the database will become inconsistent.

• This demonstrates that while the StaffBranch relation is subject to update

anomalies, we can avoid these anomalies by decomposing the original relation
into the Staff and Branch relations. 14
 How to Avoid Anomalies

Staff Branch

The design of the relations in the above Figure avoids this problem,
because the branch tuples are stored separately from staff tuples and
only the attribute branchNo relates the two relations.

If we delete the tuple for staff number SA9 from the Staff relation, the
details on branch number B007 remain unaffected in the Branch
relation. 15
 Functional Dependency
Describes the relationship between
attributes in a relation. For example, if A
and B are attributes of a relation R.

B is functionally dependent on A (denoted A ® B), if each value of A is associated

with exactly one value of B. (A and B may each consist of one or more attributes.)

• staffNo functionally determines position,

as shown in Figure (a).

• Figure (b) illustrates that the opposite is

not true, as position does not functionally
determine staffNo.
16
 Functional Dependency
• A member of staff holds one position, but
there may be several members of staff
with the same position.

• The relationship between staffNo and sName is one-to-one (1:1): for

each staff number there is only one name.

• On the other hand, the relationship between sName and staffNo is one-
to-many (1:*): there can be several staff numbers associated with a
given name.

• However, the only functional dependency that remains true for all
possible values for the staffNo and sName attributes of the Staff relation
is: staffNo → sName 17
 Full Functional Dependency

• Exists in the Staff relation.

staffNo, sName → branchNo
• True - each value of (staffNo, sName) is associated with a single value of
branchNo.
• However, branchNo is also functionally dependent on a subset of
(staffNo, sName). Example above is a partial dependency.
18
Identifying Functional Dependencies

• Identifying all functional dependencies between

a set of attributes is relatively simple if the
meaning of each attribute and the relationships
between the attributes are well understood.

• This information should be provided by the

enterprise in the form of discussions with users
and/or documentation such as the users’
requirements specification. 19
 Set of Functional Dependencies
• Examine semantics of attributes in the StaffBranch relation (see
Slide 18). Assume that position held and branch determine a
member of staff’s salary.

• With sufficient information available, identify the functional

dependencies for the StaffBranch relation as:

1) staffNo → sName, position, salary, branchNo, bAddress

2) branchNo → bAddress
3) bAddress → branchNo
4) branchNo, position → salary
5) bAddress, position → salary 20
 Identifying Primary Key for
StaffBranch Relation
• All attributes that are not part of a candidate
key should be functionally dependent on the
key.

• The only candidate key and therefore primary

key for StaffBranch relation, is staffNo, as
all other attributes of the relation are
functionally dependent on staffNo.
21
 The Process of
Normalization
Partial dependencies:
only on a portion of the
primary key

22
 Unnormalized Form (UNF)

• A table that contains one or more repeating groups.

• To create an unnormalized table

– Transform the data from the information source (e.g. form)

into table format with columns and rows.

• Repeating group: multiple entries for a single record

• Unnormalized relation: contains a repeating group
• Table (relation) in first normal form (1NF) does not contain
repeating groups
23
 UNF to 1NF

• A collection of (simplified)
DreamHome leases is shown
in Figure 13.9.

Unnormalized
table with rows
• The lease on top is and columns
for a client called
John Kay who is
leasing a property
in Glasgow, which
is owned by Tina
24
Murphy.
 UNF to 1NF
• Next, we identify the repeating group in the unnormalized table as the
property rented details, which repeats for each client.

• The structure of the repeating group is:

Repeating Group = (propertyNo, pAddress, rentStart, rentFinish, rent,

ownerNo, oName)

• As a consequence, there are multiple values at the intersection of certain rows

and columns.

• For example, there are two values for propertyNo (PG4 and PG16) for the
client named John Kay.

• To transform an unnormalized table into 1NF, we ensure that there is a single

value at the intersection of each row and column.
25
• This is achieved by removing the repeating group.
 UNF to 1NF
UNF
• A relation is
unnormalised if it
contains one or
more repeating
groups.

1NF
• A relation in which
the intersection of
each row and
column contains one
and only one value.
26
 UNF to 1NF

Key
attribute
is the
client
number

Partial dependency

Partial dependency

Transitive dependency

27
 Second Normal Form (2NF)

• A relation that is in 1NF and every non-primary-key

attribute is fully functionally dependent on the primary
key.

• The normalization of 1NF relations to 2NF involves the

removal of partial dependencies.

• If a partial dependency exists, we remove the partially

dependent attribute(s) from the relation by placing them
in a new relation along with a copy of their determinant.
28
 1NF to 2NF

• Identify the primary key for the 1NF relation.

• Identify the functional dependencies in the

relation.

• If the partial dependencies exist on the primary

key remove them by placing them in a new
relation along with a copy of their determinant.
29
 Second Normal Form (2NF)

ClientRental

Rental

Partial dependency Client

PropertyOwner
Partial dependency

Transitive dependency

Rental Client PropertyOwner

30
 Second Normal Form (2NF)

The relations have the following form:

Client (clientNo, cName)
Rental (clientNo, propertyNo, rentStart, rentFinish)
31
PropertyOwner (propertyNo, pAddress, rent, ownerNo, oName)
 Second Normal Form (2NF)

• We note that the client attribute (cName) is partially

dependent on the primary key (clientNo) attribute
(represented as fd2).

• The property attributes (pAddress, rent, ownerNo, oName)

are partially dependent on the primary key (propertyNo)
attribute (represented as fd3).

• The property rented attributes (rentStart and rentFinish)

are fully dependent on the whole primary key (clientNo and
propertyNo) attributes (represented as fd1). 32
 Third Normal Form (3NF)
• Although 2NF relations have less
redundancy than those in 1NF,
they may still suffer from update
anomalies.
• For example, if we want to update the name of an owner, such as Tony
Shaw (ownerNo CO93), we have to update two tuples in the
PropertyOwner relation.
• If we update only one tuple and not the other, the database would be in
an inconsistent state.
• This update anomaly is caused by a transitive dependency.
• We need to remove such dependencies by progressing to Third Normal
33
Form.
 Third Normal Form (3NF)

• Based on the concept of transitive dependency.

• Transitive Dependency is a condition where

– A, B and C are attributes of a relation such that if

A → B and B → C,

– then C is transitively dependent on A through B.

(Provided that A is not functionally dependent on B or
C). 34
 Third Normal Form (3NF)
ClientRental

35
 Third Normal Form (3NF)

• A relation that is in 1NF and 2NF and in which no

non-primary-key attribute is transitively dependent
on the primary key.

• Identify the primary key in the 2NF relation.

• Identify the functional dependencies in the relation.

• If transitive dependencies exist on the primary key, remove them

by placing them in a new relation along with a copy of their
dominant. 36
 Third Normal Form (3NF)
• All the non-primary-key attributes within the PropertyOwner
relation are functionally dependent on the primary key, with the
exception of oName, which is transitively dependent on ownerNo
(represented as fd4).

• To transform the PropertyOwner relation into 3NF we must first

remove this transitive dependency by creating two new relations
called PropertyForRent and Owner, as shown in Figure 13.15.

• The new relations have the form:

• PropertyForRent (propertyNo, pAddress, rent, ownerNo)

• Owner (ownerNo, oName) 37

 Third Normal Form (3NF)
• The functional dependencies for the Client, Rental, and
PropertyOwner relations are
• Client
– fd2 clientNo (Primary key) → cName
• Rental
– fd1 clientNo, propertyNo (Primary key) → rentStart, rentFinish
– fd5 clientNo, rentStart (Candidate key) → propertyNo, rentFinish
– fd6 propertyNo, rentStart (Candidate key) → clientNo, rentFinish
• PropertyOwner
– fd3 propertyNo (Primary key) → pAddress, rent, ownerNo, oName
– fd4 ownerNo → oName (Transitive dependency) 38
 Third Normal Form (3NF)

This figure illustrates the process by which the original 1NF relation is
decomposed into the 2NF and 3NF relations.
The resulting 3NF relations have the form:
▪ Client (clientNo, cName)
▪ Rental (clientNo, propertyNo, rentStart, rentFinish)
▪ PropertyForRent (propertyNo, pAddress, rent, ownerNo)
▪ Owner (ownerNo, oName) 39
 Third Normal Form (3NF)

Thus the normalization process has decomposed the original

40
ClientRental relation using a series of relational algebra projections.
 Module Resources
Recommended Book Resources
• Thomas Connolly, Carolyn Begg 2014, Database Systems: A Practical Approach
to Design, Implementation, and Management, 6th Edition Ed., Pearson
Education [ISBN: 1292061189] [Present in our Library]
Supplementary Book Resources
• Gordon S. Linoff, Data Analysis Using SQL and Excel, Wiley [ISBN:
0470099518]
• Eric Redmond, Jim Wilson, Seven Databases in Seven Weeks, Pragmatic
Bookshelf [ISBN: 1934356921]
• Baron Schwartz, Peter Zaitsev, Vadim Tkachenko, High Performance MySQL,
O'Reilly Media [ISBN: 1449314287]
Other Resources
• Website: http://www.thearling.com
• Website: http://www.mongodb.org
41
• Website: http://www.mysql.com