Normalization in DBMS

Department of CSE
Supreme Knowledge Foundation Group of Institutions
Definition of Normalization: Normalization is a process to decompose an unsatisfactory relation (Table) into more
than one relation (Table) without loss of any data and to avoid data redundancy, updation anomaly, insertion anomaly and
deletion anomaly.
EMPLOYEE_DEPT
E_ID E_Name E_Addr D_No D_Name D_Loc
101 Manab Malda D01 Design Delhi
102 Aritro Hooghly D02 Acc. Kolkata
103 Koyel Kolkata D03 Mkt. Mumbai
Data
104 Sonali Hooghly D03 Mkt. Mumbai redundancy

F. Key
P. Key DEPT_INFO EMP_INFO
D_No# D_Name D_Loc E_ID# E_Name E_Addr D_No
D01 Design Delhi 101 Manab Malda D01
D02 Acc. Kolkata
102 Aritro Hooghly D02
D03 Mkt. Mumbai
103 Koyel Kolkata D03
104 Sonali Hooghly D03
P. Key
 Types of Normalization and Some Important Terminologies related to Normal Forms:

Sl. No. Normal Form Important Terminology

1 1ST Normal Form (1NF) Functional Dependency
2 2ND Normal Form (2NF) Full Functional Dependency
3 3RD Normal Form (3NF) Transitive Dependency
4 Boyce Codd Normal Form(BCNF) Trivial Dependency
5 4TH Normal Form (4NF) Multivalued Dependency
6 5TH Normal Form (5NF) Join Dependency

Functional Dependency: An attribute is said to be functionally dependent on the other, if the value of one attribute
depends on or is determined by the value of other attribute of the same relation.

EMP
E_ID# E_NAME E_ADDR EMP.E_ID EMP.E_NAME E_ID E_NAME
101 Manab Kolkata EMP.E_ID EMP.E_ADDR
101 Manab
102 Sonali Hooghly
102 Sonali
(1)1ST Normal Form (1NF): A relation is in 1NF if and only if all the non-primary attributes are functionally dependent
on its primary key.
SALES_ORDER (R)
Ord_No# Date Cust_No Cust_Name Clk_No Clk_Name Item_No Item_Name Qty

405 2/2/18 C01 MANAB 102 XYZ 008 Monitor 5

005 Mouse 7
406 3/4/18 C02 KOYEL 103 PQR 006 TV 4
407 14/4/18 C05 AMITAVA 107 ABC 005 Mouse 5
007 Monitor 9
006 TV 8
SALE_INFO (R1) ORDER_ITEM_INFO (R2)
Ord_No# Date Cust_No Cust_Name Clk_No Clk_Name
Ord_No# Item_No# Item_Name Qty

405 2/2/18 C01 MANAB 102 XYZ 405 008 Monitor 5

406 3/4/18 C02 KOYEL 103 PQR 405 005 Mouse 7

406 006 TV 4
407 14/4/18 C05 AMITAVA 107 ABC
407 005 Mouse 5
407 007 Monitor 9
These two relations are in 1NF, because all non-key attributes of R1 & 407 006 TV 8
R2 are Functionally Dependent on it’s Primary Key.
Full Functional Dependency: Attribute Y is fully functionally dependent on attribute X (where X is a composite attribute) of
same relation R if and only if Y is functionally dependent on X, but not functionally dependent on any subset of X.

Exp: Consider the relation R2 ORDER_ITEM_INFO (R2)

{Ord_No, Item_No} {Qty} Ord_No# Item_No# Item_Name Qty
{Item_No} {Item_Name} 405 007 Monitor 5
405 005 Mouse 7
Here Attribute {Qty} (Non-key attribute) is 406 006 TV 4
fully functional dependent on {Ord_No, 407 005 Mouse 5
Item_No}(Primary key attribute)
407 007 Monitor 9
407 006 TV 8

(2) 2ND Normal Form (2NF): A relation is in 2NF if and only if it is in 1NF and every non-key attribute is fully
functionally dependent on its primary key.
ORDER_ITEM (R3) ITEM_INFO (R4)
Item_No# Item_Name
Ord_No# Item_No# Qty
405 007 5 005 Mouse

405 005 7 006 TV

406 006 4 007 Monitor
407 005 5
407 007 9
407 006 8 Both the relations (R3 and R4) are in 2NF
Transitive Dependency: When an indirect relationship causes functional dependency it is called Transitive Dependency.
Exp: If A B and B C, then A C is a Transitive Dependency.
A,B,C are the attributes of same relation, R
SALES_INFO (R1) In this relation:

Ord_No# Date Cust_No Cust_Name Clk_No Clk_Name { Ord_No} { Cust_No} and { Cust_No } { Cust_Name }
i.e. { Ord_No} { Cust_Name }[ Transitive Dependency]
405 2/2/18 C01 MANAB 102 XYZ
{ Ord_No} { Clk_No} and { Clk_No } { Clk_Name } i.e.
406 3/4/18 C02 KOYEL 103 PQR
{ Ord_No} { Clk_Name }[ Transitive Dependency]
408 14/4/18 C05 AMITAVA 107 ABC

(3) 3RD Normal Form (3NF): A relation, R is in 3NF if and only if it is in 2NF and every non-key attribute of R is non-
transitively dependent(i.e. directly dependent) on every primary key.

CUST_INFO (R5) CLK_INFO (R6) ORD_DATE_INFO(R7)

Cust_No# Cust_Name Clk_No# Clk_Name Ord_No# Date Cust_No Clk_No
C01 MANAB 102 XYZ 405 2/2/18 C01 102
C02 KOYEL 406 3/4/18 C02 103
103 PQR
C05 AMITAVA 408 14/4/18 C05 107
107 ABC

{ Cust_No } { Cust_Name } { Clk_No } { Clk_Name } {Ord_No} {Date, Cust_No, Clk_No}

These three relations (R5, R6 and R7) are in 3NF

Trivial Dependency: A functional dependency X Y is said to be trivial FD if and only if Y⊆X. In other words if
R.H.S of any FD is the subset of L.H.S of any FD is called Trivial Dependency.
Exp: Trivial Dependency Non Trivial Dependency

AB A AB C
AB B AB D
AB AB

(4) Boyce Codd Normal Form(BCNF)/3.5 NF: A relation is in BCNF for the following conditions:
i. It is in 3NF. R10
Roll# Name Addr
ii. For every FD, X Y and Y ⊆ X, X should be the super key. 101 Manab KOL
STUDENT 102 Sayon MAL
Roll# Reg Name Addr R11
101 R205 Manab KOL Reg# Name Addr
102 R206 Sayon MAL R205 Manab KOL
Here, the Candidate Keys are-{Roll} and {Reg} R206 Sayon MAL

R12
Roll# Reg# {Roll,Reg} {Roll}
{Roll,Reg} {Reg}
101 R205 {Roll,Reg} {Roll,Reg}
102 R206

These 3 relations (R10,R11 and R12) are in BCNF

Multi-valued dependency: When existence of one or more rows in a table implies one or more other rows in the same
table, then the Multi-valued dependencies( ) occur.
AUT_BOOK_PUB (R)
AID# Title# PID#
A01 C++ P02 Here {AID} {Title},
{PID} {Title} and
A01 JAVA P01
{AID} {PID} ,So
A02 C++ P02 this relation is not in
A03 JAVA P01 4NF

A03 DBMS P01

(5) 4TH Normal Form (4NF): A relation R, is in 4NF if and only if it satisfies the following condition:
i. It should be in BCNF.
ii. The Relation (Table) should not have any Multi-valued dependencies.
AUT_BOOK (R1) BOOK_PUB (R2) AUT_PUB (R3) These three relation are in 4NF
AID# Title# PID# Title# AID# PID#
A01 C++ P01 JAVA A01 P02
A01 JAVA P01 DBMS
A01 P01
P02 C++
A02 C++ A02 P02 NOTE: MVD( ) is a generalization
A03 JAVA of Functional Dependency
A03 P01
A03 DBMS
(6) 5TH Normal Form (5NF): A relation R, is in 5NF if and only if it satisfies the following condition:

i. πR1 (R) ⋈ πR2 (R) ⋈ …….⋈ πRn(R) = R

AUTHOR_BOOK_PUB (R) AUTHOR_BOOK (R1) BOOK_PUB(R2) AUTHOR_PUB (R3)
A_ID# Title# P_ID# A_ID# Title# Title# P_ID# P_ID# A_ID#
A01 C++ P02 A01 C++ P02 A01
C++ P02
A01 JAVA P01 A01 JAVA P01 A01
JAVA P01
A02 C++ P02 A02 C++ P02 A02

Decompose AUTHOR_BOOK_PUB into 3 relation based on some FDs R1 ⋈ R2

R1 R2
A_ID Title P_ID
A_ID# Title# Title# P_ID#
A01 C++ P02
A01 C++ ⋈ C++ P02 A01 JAVA P01
A01 JAVA
JAVA P01 A02 C++ P02
A02 C++
⋈
AUTHOR_BOOK_PUB (R) R3
A_ID# Title# P_ID# P_ID# A_ID
A01 C++ P02 P02 A01
A01 JAVA P01 P01 A01
A02 C++ P02 P02 A02
Lossy and Lossless Decomposition: BOOK (R)
BOOK (R) BOOK_PRICE (R1) BOOK_PAGE (R2) ISBN# Price Page
ISBN# Price Page ISBN# Price ISBN# Page
09 25 800
09 25 800 09 25 09 800
01 22 200
01 22 ⋈ 01 200
01 22 200
02 25 02 810 02 25 810
02 25 810

The FDs are ISBN Price and ISBN Page for Decomposition-A A is Lossless Decomposition
R3 R4
ISBN# Price Page# Price ISBN# Price Page
09 25 800 25 09 25 800
01 22
⋈ 01 22 200
200 22
02 25 810 25 02 25 800

The FDs are ISBN Price and Page Price for Decomposition-B B is Lossy Decomposition
NOTE: A decomposition will be lossless, if it satisfies the following conditions:
i. Att(R1) Ս Att(R2) = Att(R)
ii. Att(R1) Ո Att (R2) ≠ Փ
iii. Att(R1) Ո Att (R2) Att(R1) or Att(R1) Ո Att (R2) Att(R2)
Armstrong’s Axioms:
Armstrong’s Axioms are defined as the inference rules for Functional Dependencies.

1. Reflexivity rule: If B ⊆ A, then A B (Trivial dependency)

2. Augmentation rule : If A B , then AC AB
3. Transitivity rule : If A B and B C, then A C
4. Union rule : If A B and A C, then A BC
5. Decomposition rule : If A BC, then A B and A C

Closure of an attribute set:

The set of all those attributes, which can be functionally determined from an attribute set is called as the closure of that
attribute set.

Exp: Consider a relation schema R(A, B,C,D,E,F) with the FDs A BC, BC DE and D F
A+ = {A}
= {A,B,C} [A BC]
= {A,B,C,D,E} [BC DE]
= {A,B,C,D,E,F} [D F] As all the attributes of the relation R is functionally determined on attribute A,
attribute A can be called as the Candidate Key.
Canonical Cover:
Canonical cover is the process to remove redundant functional dependencies (FDs) from a relation schema. It is
implemented for a set of functional dependencies (F) to optimal the FDs and is denoted by Fc.

Algorithm to compute the canonical cover of set F:

Step-1: Use the union rule to replace any dependencies. [For uniqueness of L.H.S FDs]
Step-2: Find a functional dependency A B with an extraneous attribute either in A or B.
Step-3: If an extraneous attribute is found delete it from F (but it is to be kept in mind that F does not change).

Exp: F = {A BC, B C, A B, AB C } Given set of FDs

1. Union A BC and A B, So we remove A B from the set of FDs (F).

Now F = { A BC, B C, AB C }

2. We remove AB C (here AB is an extraneous attribute), because attribute C only depends on attribute B, so it never
depends on the composite attribute AB.
Now F = { A BC, B C }

3. C again is an extraneous attribute for A BC, because C can be determined by the attribute B. [here also A B is
logically implied by A B and B C ]
Hence, Fc. = { A B, B C } Reducible set of FDs (Canonical Cover)
Thanking You!!