Normalization

What is normalization
• Database Normalization is a technique of organizing the data
in the database. Normalization is a systematic approach of
decomposing tables to eliminate data redundancy and
undesirable characteristics like Insertion, Update and
Deletion anomalies. It is a multi-step process that puts data
into tabular form by removing duplicated data from the
relation tables.

Normalization is used for mainly two purpose,

• Eliminating redundant (useless) data.

• Ensuring data dependencies make sense i.e data is logically
stored.
 Problems without normalization
Without Normalization, it becomes difficult to handle and
update the database, without facing data loss. Insertion,
Updation and Deletion anamolies are very frequent if
Database is not Normalized. Lets look at Student table.

S_id S_Name S_Address Subject

101 Ravi Hyderabad Economics
102 Subbu Bangalore Maths
103 Archana Hyderabad Maths
101 Ravi Hyderabad Physics
 Problems without normalization
Updation Anamoly: To update address of a student who occurs
twice or more than twice in a table, we will have to update
S_Address column in all the rows, else data will become
inconsistent.

Insertion Anamoly: Suppose for a new admission, we have a

Student id (S_id), name and address of a student but if
student has not opted for any subjects yet then we have to
insert NULL there, leading to Insertion Anamoly.

Deletion Anamoly: If (S_id) 102 has only one subject and

temporarily he drops it, when we delete that row, entire
student record will be deleted along with it.
 Dependencies: Definitions
• Multivalued Attributes (or repeating groups): non-key
attributes or groups of non-key attributes the values of
which are not uniquely identified by (directly or
indirectly) (not functionally dependent on) the value of
the Primary Key (or its part).

STUDENT

Stud_ID Name Course_ID Units

101 Lennon MSI 250 3.00
101 Lennon MSI 415 3.00
125 Johnson MSI 331 3.00
 Dependencies: Definitions
• Partial Dependency – when an non-key attribute is
determined by a part, but not the whole, of a
COMPOSITE primary key.
Partial
CUSTOMER Dependency

Cust_ID Name Order_ID

101 AT&T 1234
101 AT&T 156
125 Cisco 1250
 Dependencies: Definitions

• Transitive Dependency – when a non-key

attribute determines another non-key
attribute. Transitive
Dependency

EMPLOYEE

Emp_ID F_Name L_Name Dept_ID Dept_Name

111 Mary Jones 1 Acct
122 Sarah Smith 2 Mktg
 Normal Forms: Review
• Unnormalized – There are multivalued attributes or
repeating groups
• 1 NF – No multivalued attributes or repeating groups
(any row must not have a column in which more than
one value is saved, like separated with commas.
Rather than that, we must separate such data into
multiple rows).
• 2 NF – 1 NF plus no partial dependencies
• 3 NF – 2 NF plus no transitive dependencies .
The advantage of removing transitive dependency is,
– Amount of data duplication is reduced.
– Data integrity is achieved.
 Example 1: Determine NF
• ISBN  Title All attributes are directly or
• ISBN  Publisher indirectly determined by the
primary key; therefore, the
• Publisher  Address relation is at least in 1 NF

BOOK

ISBN Title Publisher Address

 Example 1: Determine NF
• ISBN  Title The relation is at least in 1NF.
• ISBN  Publisher There is no COMPOSITE primary
• Publisher  Address key, therefore there can’t be
partial dependencies. Therefore,
the relation is at least in 2NF
BOOK

ISBN Title Publisher Address

 Example 1: Determine NF
• ISBN  Title Publisher is a non-key attribute, and it
• ISBN  Publisher determines Address, another non-key
attribute. Therefore, there is a
• Publisher  Address transitive dependency, which means
that the relation is NOT in 3 NF.
BOOK

ISBN Title Publisher Address

 Example 1: Determine NF
We know that the relation is at
• ISBN  Title least in 2NF, and it is not in 3 NF.
• ISBN  Publisher Therefore, we conclude that the
relation is in 2NF.
• Publisher  Address

BOOK

ISBN Title Publisher Address

 Example 1: Determine NF
• ISBN  Title In your solution you will write the following
justification:
• ISBN  Publisher 1) No M/V attributes, therefore at least
• Publisher  Address 1NF
2) No partial dependencies, therefore at
least 2NF
3) There is a transitive dependency
(Publisher  Address), therefore, not
3NF
Conclusion: The relation is in 2NF

BOOK

ISBN Title Publisher Address

 Example 2: Determine NF
• Product_ID  Description

All attributes are directly or indirectly

determined by the primary key;
therefore, the relation is at least in 1 NF
ORDER

Order_No Product_ID Description

 Example 2: Determine NF
• Product_ID  Description

The relation is at least in 1NF.

There is a COMPOSITE Primary Key (PK) (Order_No,
Product_ID), therefore there can be partial dependencies.
Product_ID, which is a part of PK, determines Description;
hence, there is a partial dependency. Therefore, the
relation is not 2NF. No sense to check for transitive
dependencies!

ORDER

Order_No Product_ID Description

 Example 2: Determine NF
• Product_ID  Description

We know that the relation is at least in

1NF, and it is not in 2 NF. Therefore, we
conclude that the relation is in 1 NF.

ORDER

Order_No Product_ID Description

 Example 2: Determine NF
• Product_ID  Description

In your solution you will write the following

justification:
1) No M/V attributes, therefore at least 1NF
2) There is a partial dependency (Product_ID 
Description), therefore not in 2NF
Conclusion: The relation is in 1NF
ORDER

Order_No Product_ID Description

 Example 3: Determine NF
• Part_ID  Description Comp_ID and No are not
• Part_ID  Price determined by the primary
key; therefore, the relation is
• Part_ID, Comp_ID  No NOT in 1 NF. No sense in
looking at partial or transitive
dependencies.

PART

Part_ID Descr Price Comp_ID No

 Example 3: Determine NF
In your solution you will write the
• Part_ID  Description following justification:
• Part_ID  Price 1) There are M/V attributes;
therefore, not 1NF
• Part_ID, Comp_ID  No Conclusion: The relation is not
normalized.

PART

Part_ID Descr Price Comp_ID No

 Bringing a Relation to 1NF

STUDENT

Stud_ID Name Course_ID Units

101 Lennon MSI 250 3.00
101 Lennon MSI 415 3.00
125 Johnson MSI 331 3.00
 Bringing a Relation to 1NF
• Option 1: Make a determinant of the
repeating group (or the multivalued
attribute) a part of the primary key.
Composite
Primary Key

STUDENT

Stud_ID Name Course_ID Units

101 Lennon MSI 250 3.00
101 Lennon MSI 415 3.00
125 Johnson MSI 331 3.00
 Bringing a Relation to 1NF
• Option 2: Remove the entire repeating group from the
relation. Create another relation which would contain all
the attributes of the repeating group, plus the primary
key from the first relation. In this new relation, the
primary key from the original relation and the
determinant of the repeating group will comprise a
primary key.
STUDENT

Stud_ID Name Course_ID Units

101 Lennon MSI 250 3.00
101 Lennon MSI 415 3.00
125 Johnson MSI 331 3.00
Bringing a Relation to 1NF
STUDENT

Stud_ID Name
101 Lennon
125 Jonson

STUDENT_COURSE

Stud_ID Course Units

101 MSI 250 3
101 MSI 415 3
125 MSI 331 3
 Bringing a Relation to 2NF

Composite
Primary Key

STUDENT

Stud_ID Name Course_ID Units

101 Lennon MSI 250 3.00
101 Lennon MSI 415 3.00
125 Johnson MSI 331 3.00
 Bringing a Relation to 2NF
• Goal: Remove Partial Dependencies
Partial
Composite Dependencies
Primary Key

STUDENT

Stud_ID Name Course_ID Units

101 Lennon MSI 250 3.00
101 Lennon MSI 415 3.00
125 Johnson MSI 331 3.00
 Bringing a Relation to 2NF
• Remove attributes that are dependent from the part but
not the whole of the primary key from the original
relation. For each partial dependency, create a new
relation, with the corresponding part of the primary key
from the original as the primary key.
STUDENT

Stud_ID Name Course_ID Units

101 Lennon MSI 250 3.00
101 Lennon MSI 415 3.00
125 Johnson MSI 331 3.00
 Bringing a Relation to 2NF
CUSTOMER
STUDENT_COURSE
Stud_ID Name Course_ID Units
101 Lennon MSI 250 3.00
101 Lennon MSI 415 3.00 Stud_ID Course_ID
125 Johnson MSI 331 3.00
101 MSI 250
101 MSI 415
125 MSI 331

STUDENT COURSE

Stud_ID Name Course_ID Units

101 Lennon MSI 250 3.00
101 Lennon MSI 415 3.00
125 Johnson MSI 331 3.00
 Bringing a Relation to 3NF

• Goal: Get rid of transitive dependencies.

Transitive
Dependency
EMPLOYEE

Emp_ID F_Name L_Name Dept_ID Dept_Name

111 Mary Jones 1 Acct
122 Sarah Smith 2 Mktg
 Bringing a Relation to 3NF
• Remove the attributes, which are dependent on a non-
key attribute, from the original relation. For each
transitive dependency, create a new relation with the
non-key attribute which is a determinant in the transitive
dependency as a primary key, and the dependent non-key
attribute as a dependent.

EMPLOYEE

Emp_ID F_Name L_Name Dept_ID Dept_Name

111 Mary Jones 1 Acct
122 Sarah Smith 2 Mktg
 Bringing a Relation to 3NF
EMPLOYEE

Emp_ID F_Name L_Name Dept_ID Dept_Name

111 Mary Jones 1 Acct
122 Sarah Smith 2 Mktg

EMPLOYEE

Emp_ID F_Name L_Name Dept_ID

111 Mary Jones 1
122 Sarah Smith 2

DEPARTMENT

Dept_ID Dept_Name
1 Acct
2 Mktg