ITS232

Introduction To Database Management Systems

CHAPTER 5
Normalization Of Database Tables
(Part II: The Process)

Siti Nurbaya Ismail

Faculty of Computer Science & Mathematics,
Universiti Teknologi MARA (UiTM), Kedah
| [email protected] | http://www.sitinur151.wordpress.com |
| A2-3039 | ext:2561 | 012-7760562 |
Chapter 5: Normalization Of Database Tables
Part 2: Normalization Process

Objectives
• How to undertake the process of normalization.

Data Redundancies
0NF/UNF
1NF
Normalization Denormalization
2NF
3NF

2
 Chapter 5: Normalization Of Database Tables
5.3 The Normalization Process

Normalization Process Relation/table Format

1)Repeat Group (1 Table)  Have repeating group

UNF -PK not defined
2)PK is not defined

1)Remove Repeat Group (1 or 2 Tables)  No repeating group

1NF
2)Defined PK  composite PK consist of attributes -PK defined
-Test partial
Test for partial dependency dependency

If (exist)

(2 or 3 Tables)  No repeating group

(a b …. TD) 1 2NF (more then 1 table) -PK defined
(a  ……. TD) 2 -No partial dependency
(b  ….… TD) 3 -Test transitive
Test for transitive dependency
dependency
If (exist)
(a, b  x, y)  No repeating group
(a c, d) -PK defined
-No partial dependency
(b  z)
3NF (3 or 4 Tables) -No transitive
(c  d) dependency
Chapter 5: Normalization Of Database Tables
5.3 The Normalization Process: First Normal Form (1NF)

First Normal Form = A relation in which the intersection of each row 1NF
and column contains one and only one value.

A relation is in 1NF if every attribute for every tuple have a value and
domain for each attribute can not be simplified anymore.

4
Chapter 5: Normalization Of Database Tables
5.3 The Normalization Process: UNF  1NF

• Nominate an attribute or group of attributes to act as the key for the

unnormalized table.
• Identify the repeating group(s) in the unnormalized table which repeats for
the key attribute(s).

• Remove the repeating group:

– Entering appropriate data into the empty columns of rows containing the
repeating data
• Fill the blanks by duplicating the non repeating data, where
required.
• This approach is commonly referred as ”flattening table”.
• This approach will produce redundancy in a relationship, but it can
be eliminated in higher normalization process.

5
Chapter 5: Normalization Of Database Tables
5.3 The Normalization Process: UNF  2NF

6
Chapter 5: Normalization Of Database Tables
5.3 The Normalization Process: UNF  2NF

7
Chapter 5: Normalization Of Database Tables
5.3 The Normalization Process: UNF  2NF

8
Chapter 5: Normalization Of Database Tables
5.3 The Normalization Process: UNF  2NF

9
Chapter 5: Normalization Of Database Tables
5.3 The Normalization Process: UNF  3NF

10
Chapter 5: Normalization Of Database Tables
5.3 The Normalization Process: UNF  3NF

11
Chapter 5: Normalization Of Database Tables
5.3 The Normalization Process: UNF  3NF

12
Chapter 5: Normalization Of Database Tables
5.3 The Normalization Process: UNF  1NF

• Example: DreamHome Case Study

• A collection of DreamHome leases (rent) form is shown in Figure 2. The

lease on top is for a client called Rannia who is leasing a property in Skudai,
Johor, which is owned by Dollah. For this working example, we assume that
a client rents a given property only once and cannot rent more than one
property at any one time.

• Sample data is taken from two leases for two different clients called Rannia
and Ahmad and is transformed into table format with rows and columns, as
shown in Figure 3. This is an example of unnormalized table.

13
 Chapter 5: Normalization Of Database Tables
5.3 The Normalization Process: UNF  1NF

Figure 2 : Collection of Dream Home leases (rent) form

Page 2 DREAMHOUSE LEASE Date : 28/02/2007
Client Rental Information
Client Name : Ahmad Client Number : CR56

Page 1 DREAMHOUSE LEASE Date : 28/02/2007

House Alamat Mula Tamat Harga
Client Rental Information No Nama
No Rumah Sewa Sewa Sewa Pemilik Pemilik
  Client Name : Rannia Client Number : CR76
 PG04 Subang Jaya, 1/7/93 31/8/00 750 C040 Karim Fendi
  Selangor. House  
House        
House   Rent
Rent  Rent
Rent  Monthly
Monthly
 
Owner
 
Owner
  No Address
Address1/9/00 Start
Start1/9/01 Finish
Finish Rent
Rent C093 No Kasim Selamat
Name
Pasir Gudang, 850
PG16   Johor.
 
PG04 Skudai, 1/7/93 31/8/00 750 C040 Dolah
  Johor        
         
PG16 Ampang, 1/9/00 1/9/01 850 C093 Abdullah
Selangor
 
 

14
 Chapter 5: Normalization Of Database Tables
5.3 The Normalization Process: UNF  1NF

Figure 3 : CLIENTRENTAL UNF

clientNO cNAME houseNO houseADD rentSTAR rentFINIS rent ownerNO oNAME
T H

CR76 Rannia PG04 Skudai, 1/7/93 31/8/00 750 C040 Dolah

    Johor.        
 
  PG16 Ampang, 1/9/00 1/9/01 850 C093 Abdullah
Selangor

CR56 Ahmad PG04 Skudai, 20/3/90 19/6/93 750 C040 Dolah

  Johor.          
         
PG 36 Kuantan, 21/6/93 3/1/00 1000 C093 Abdullah
  Pahang.        

PG 16 Ampang, 25/1/00 30/8/00 850 C093 Abdullah

Selangor.

Key attribute: clientNO, houseNO

Repeating group in the unnormalized table as the property rented details, which repeat for each client:
Repeating Group: ( houseNO, houseADD, rentSTART, rentFINISH, rent, ownerNO, oNAME)
15
 Chapter 5: Normalization Of Database Tables
5.3 The Normalization Process: UNF  1NF

Key attribute: clientNo,houseNO

Repeating group in the unnormalized table as the
property rented details, which repeat for each client:
Repeating Group: (houseNO,houseADD,rentSTART,rentFINISH,rent,ownerNO,oNAME)

• There are multiple value at the intersection of certain rows and columns.
• e.g. there are two value for houseNo (PG4 and PG16) for the client Rannia.
• To transform an unnormalized table into 1NF, we ensure that there is a single value
at the intersection of each row and column. This is achieved by removing the
repeating group.
• With this approach, remove the repeating group (house rented details) by
entering the appropriate client data into each row.
• The resulting First Normalize Form (1NF) CLIENTRENTAL relation is shown in Figure
4.

16
 Chapter 5: Normalization Of Database Tables
5.3 The Normalization Process: UNF  1NF

Figure 4 : 1NF CLIENTRENTAL relation

clientNO houseNO cNAME houseADD rentSTAR rentFINIS rent ownerNO oNAME
T H

CR76 PG04 Rannia Skudai, 1/7/93 31/8/00 750 C040 Dolah

  Johor.        

CR76 PG16 Rannia Ampang, 1/9/00 1/9/01 850 C093 Abdullah

Selangor

CR56 PG04 Ahmad Skudai, 20/3/90 19/6/93 750 C040 Dolah

  Johor.        
           
CR56 PG 36 Ahmad Kuantan, 21/6/93 3/1/00 1000 C093 Abdullah
  Pahang.        

CR56 PG 16 Ahmad Ampang, 25/1/00 30/8/00 850 C093 Abdullah

Selangor.

CLIENTRENTAL (clientNO, houseNO, cNAME, houseADD, rentStart, rentFinish, rent,ownerNO, oNAME)

Primary Key for the ClientRent relation is a composite key that are clientNO and houseNO
ClientRent relation is in 1NF as there is a single value at the intersection of each row and columns.
17
Chapter 5: Normalization Of Database Tables
5.3 The Normalization Process: UNF  1NF

• Relationship in Figure 4 contains data that describes client, house for rent
and owner of the house, which is repeated for several times.
• As a consequences, the CLIENTRENTAL relation contains significant data
redundancy.
• If implemented, the 1NF relation would be subject to the update anomalies.
• To remove some of these, transform 1NF  2NF

18
 Chapter 5: Normalization Of Database Tables
The decomposition of the ClientRental UNF  2NF

Unnormalized Form (UNF)

CLIENTRENTAL (clientNO, houseNO, cNAME, houseAdd, rentSTART, rentFINISH, rent,
ownerNO, oNAME)

First Normal Form (1NF)

CLIENTRENTAL (clientNO, houseNO, cNAME, houseAdd, rentSTART, rentFINISH, rent,
ownerNO, oNAME) 1NF

HouseOwner

Client Rental HouseForRent Owner

19
 Chapter 5: Normalization Of Database Tables
5.3 The Normalization Process: Second Normal Form (2NF)

Second Normal Form = A relation that is in 1NF and every non-PK

2NF attribute is fully functionally depends on the PK.

• Based on the concept of partial dependency.

– Dependencies based on only a part of composite primary key

• 2NF applies to relations with composite keys, that is, relations with PK
composed of two or more attributes.

• A relation with a single-attribute PK is automatically in at least 2NF.

20
Chapter 5: Normalization Of Database Tables
5.3 The Normalization Process: 1NF  2NF

1. Identify the primary key for the 1NF relation.

2. Identify the functional dependencies in the relation.

a. Draw functional dependencies diagram
b. Write functional dependencies in relational schema

3. If partial dependencies exist on the primary key remove them by placing

them in a new relation along with a copy of their determinant.

21
 Chapter 5: Normalization Of Database Tables
5.3 The Normalization Process: 1NF  2NF

Figure 5 : Functional dependencies diagram for the CLIENTRENTAL relation

clientNO houseNO cNAME houseADD rentSTART rentFINISH rent ownerNO oNAME

fd1 (Primary Key)

fd2 (Partial dependency)

fd3
(Partial dependency)

fd4
(Transitive dependency)

22
Chapter 5: Normalization Of Database Tables
5.3 The Normalization Process: 1NF  2NF

• As shown in Figure 5, CLIENTRENTAL relation has the following functional

dependencies:

• Relational Schema
CLIENTRENTAL(clientNO, houseNO, cNAME, houseADD, rentSTART, rentFINISH, rent,
ownerNO, oNAME)

• Functional dependencies

– fd1 clientNO, houseNO  rentSTART, rentFINISH (Primary Key)

– fd2 clientNO  cNAME (Partial Dependency)
– fd3 houseNO  houseADD, rent, ownerNO, oNAME (Partial Dependency)
– fd4 ownerNO  oNAME (Transitive Dependency)

Write functional dependencies in relational schema

for the CLIENTRENTAL relation

23
Chapter 5: Normalization Of Database Tables
5.3 The Normalization Process: 1NF  2NF

• There are partial dependencies on the Primary Key (PK) in the

CLIENTRENTAL relation, so the relation are not in 2NF:
– fd2 clientNO  cNAME (Partial Dependency)
• The client attribute (cName) is partially depend on the PK
• The relation have a single-attribute PK -- automatically in 2NF

– fd3 houseNO  houseADD, rent, ownerNO, oNAME (Partial Dependency)

• The house rented attributes (houseAdd, rent, ownerNo, oName) are
partially depend on the PK
• The relation have a PK composed of two or more attributes
-- not in 2NF

• The house rented attributes:

– fd1 clientNO, houseNO  rentSTART, rentFINISH (Primary Key)
• The house rented attributes are fully depend on the whole PK

24
Chapter 5: Normalization Of Database Tables
5.3 The Normalization Process: 1NF  2NF

• To transform the CLIENTRENTAL relation into 2NF, requires the creation of

new relations, so that, the non-primary-key attributes are removed along
with a copy of the part of the PK on which they are fully functionally depend.
• This results in creation of there new relations called CLIENT, RENTAL and
HOUSEOWNER as shown in Figure 6.

25
 Chapter 5: Normalization Of Database Tables
5.3 The Normalization Process: 1NF  2NF
RENTAL Figure 6 : 2NF
clientN0 houseN0 rentSTAR rentFINIS
CR76 PG04 T
1/7/93 H31/8/00

CR76 PG16 1/9/00 1/9/01

CR56 PG04 20/3/90 19/6/93  CLIENT

    clientNO cNAME
CR56 PG36 21/6/93 3/1/00 
  CR76 Rannia
CR56 PG16 25/1/00 30/8/00
CR56 Ahmad

HOUSEOWNER
houseNO houseADD rent ownerNO oNAME
PG04  Skudai, Johor. 750  C040  Dolah
       
PG 36  Kuantan, Pahang. 1000  C093  Abdullah

PG 16 Ampang, Selangor. 850 C093 Abdullah

CLIENT(clientNO, cNAME)
RENTAL(clientNO, houseNO, rentSTART, rentFINISH)
HOUSEOWNER(houseNO, houseADD, rent, ownerNO, oNAME)

These relation are in 2NF as every non-primary-key attribute is fully functional dependent on
26
the PK of the relation.
 Chapter 5: Normalization Of Database Tables
The decomposition of the ClientRental UNF  2NF

Unnormalized Form (UNF)

CLIENTRENTAL (clientNO, houseNO, cNAME, houseAdd, rentSTART, rentFINISH, rent,
ownerNO, oNAME)

First Normal Form (1NF)

CLIENTRENTAL (clientNO, houseNO, cNAME, houseAdd, rentSTART, rentFINISH, rent,
ownerNO, oNAME) 1NF

Second Normal Form (2NF)

CLIENT (clientNO, cNAME)
RENTAL(clientNO, houseNO, rentSTART, rentFINISH)
HOUSEOWNER(houseNO, houseAdd, rent, ownerNO, oNAME)
HouseOwner

Client Rental HouseForRent Owner

27
 Chapter 5: Normalization Of Database Tables
5.3 The Normalization Process: Third Normal Form (3NF)

Third Normal Form = A relation that is in 1NF and 2NF and which
(3NF) no non-primary-key attribute is transitively
dependent on the primary key.

• 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).
• 3NF applies to relations with transitive dependency.
• A relation that have no transitive dependency are already in 3NF.

28
Chapter 5: Normalization Of Database Tables
5.3 The Normalization Process: 2NF  3NF

• Identify the primary key in the 2NF relation.

• Identify 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.

29
Chapter 5: Normalization Of Database Tables
5.3 The Normalization Process: 2NF  3NF

• Guidelines:
– Identify transitive dependencies and identify determinant that is not
primary key (PK).

– Group attributes that have transitive dependencies with its determinant

to a new relation, R3.
Group also the left over attributes, to a new relation, R4.
– For a relationship, R, with attributes, A, B and C, which A  B and
B  C, simplified the R relationship to R1 and R2, with schema:
• R1 (A, B) R (A, B, C) with transitive dependencies: A  B
• R2 (B, C) BC
Simplified R to: R1 (A, B)
R2 (B, C)

30
Chapter 5: Normalization Of Database Tables
5.3 The Normalization Process: 2NF  3NF

• The functional dependencies for the CLIENT, RENTAL and

HOUSEOWNER relations, derived from DreamHome, are as follows:

– RENTAL
fd1 clientNO, houseNO  rentSTART, rentFINISH (Primary Key)

– CLIENT
fd2 clientNO  Cname (Primary Key)

– HOUESOWNER
fd3 houseNO  houseADD, rent, ownerNO, oNAME (Primary
key) fd4 ownerNO  oNAME (Transitive
dependency)

31
Chapter 5: Normalization Of Database Tables
5.3 The Normalization Process: 2NF  3NF

• All the non-primary-key attributes within the CLIENT and RENTAL relations
are functionally dependent on their PK.
• The CLIENT and RENTAL relations have no transitive dependencies and
are therefore already in 3NF.

• All the non-primary-key attributes within the HOUSEOWNER relation are

functionally dependent on the PK,
– with the exception of oNAME, which is transitively dependent on
ownerNO.
• To transform the HOUSEOWNER relation into 3NF,
– Remove transitive dependency by creating 2 new relations called
HOUSE and OWNER as shown in Figure 7.

32
Chapter 5: Normalization Of Database Tables
5.3 The Normalization Process: 2NF  3NF

Figure 7 : 3NF relations derived from the HouseOwner relation.

HOUSE
houseNO houseADD rent ownerNO
OWNER
PG04  Skudai, Johor. 750  C040  ownerNO oNAME
     
PG 36  Kuantan, Pahang. 1000  C093  C040 Dolah

PG 16 Ampang, Selangor. 850 C093 C093 Abdullah

HOUSE(houseNO, houseADD, rent, ownerNO*)

OWNER(ownerNO, oNAME)

33
 Chapter 5: Normalization Of Database Tables
The decomposition of the ClientRental UNF  3NF

Unnormalized Form (UNF)

CLIENTRENTAL (clientNO, houseNO, cNAME, houseAdd, rentSTART, rentFINISH, rent,
ownerNO, oNAME)

First Normal Form (1NF)

CLIENTRENTAL (clientNO, houseNO, cNAME, houseAdd, rentSTART, rentFINISH, rent,
ownerNO, oNAME) 1NF

Second Normal Form (2NF)

CLIENT (clientNO, cNAME)
RENTAL(clientNO, houseNO, rentSTART, rentFINISH)
HOUSE(houseNO, houseAdd, rent, ownerNO, oNAME)
HouseOwner
Third Normal Form (3NF)
CLIENT (clientNO, cNAME)
RENTAL(clientNO, houseNO, rentSTART, rentFINISH)
HOUSE (houseNO, houseAdd, rent, ownerNO*)
OWNER(ownerNO, oNAME)
Client Rental HouseForRent Owner
34
Chapter 5: Normalization Of Database Tables
The decomposition of the ClientRental 1NF  3NF

Figure 8 : The decomposition of the ClientRental 1NF relation into 3NF relations.

CLIENTRENTAL 1NF

HOUSEOWNER
HouseOwner 2NF

Client RENTAL
Rental HOUSE
HouseForRent OWNER
Owner 3NF
35
Chapter 5: Normalization Of Database Tables
A summary of the 3NF relation derived from ClientRental relation

Figure 9 : A summary of the 3NF relation derived from the ClientRental relation.
CLIENT RENTAL
clientNO cName clientNO houseNO rentSTAR rentFINIS
CR76 PG04 T
1/7/93 H
31/8/00
CR76 Rannia

CR56 Ahmad CR76 PG16 1/9/00 1/9/01

CR56 PG04 20/3/90 19/6/93 

   
CR56 PG36 21/6/93 3/1/00 
 
CR56 PG16 25/1/00 30/8/00
HOUSE
houseNO houseADD rent ownerNO OWNER
PG04  Skudai, Johor. 750  C040  ownerNO oNAME
     
PG 36  Kuantan, Pahang. 1000  C093  C040 Dolah

PG 16 Ampang, Selangor. 850 C093 C093 Abdullah

CLIENT (clientNO, cNAME)

RENTAL (clientNO, houseNO, rentSTART, rentFINISH)
HOUSE (houseNO, houseADD, rent, ownerNO*)
OWNER (ownerNO, oNAME)

These relation are in 3NF as every non-primary-key attribute is fully functional dependent on the PK of
the relation and have no transitive dependencies.
 Chapter 5: Normalization Of Database Tables
A summary of the 3NF relation derived from ClientRental relation

Figure 10 : ERD for the 3NF relation derived from the ClientRental relation.
houseNo

1 M 1
CLIENT RENTAL HOUSE
M rent
clientNO clientNO houseNO
houseNO
rentSTART rentFINISH
cNAME have houseAD

ownerNO*

OWNER
CLIENT (clientNO, cNAME)
RENTAL (clientNO, houseNO, rentSTART, rentFINISH)
HOUSE (houseNO, houseADD, rent, ownerNO*)
OWNER (ownerNO, oNAME) ownerNO

oNAME 37
Chapter 5: Normalization Of Database Tables
General Definations of UNF, 1NF, 2NF & 3NF

• Unnormalized Form (UNF)

– A table/relation that contains one or more repeating groups.

• Second Normal Form (1NF)

– A relation that is in 1NF and every non-primary-key attribute is fully
functionally dependent on the primary key.

• Second normal form (2NF)

– A relation that is in first normal form and every non-primary-key
attribute is fully functionally dependent on any candidate key.

• Third normal form (3NF)

– A relation that is in first and second normal form and in which no non-
primary-key attribute is transitively dependent on any candidate key.

38