Database Normalization
Database 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. To understand these anomalies let us take an example of Student table.
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) 401 has only one subject and temporarily he drops it, when
we delete that row, entire student record will be deleted along with it.
Normalization Rule
A row of data cannot contain repeating group of data i.e each column must have a unique value.
Each row of data must have a unique identifier i.e Primary key. For example consider a table
which is not in First normal form
Student Table :
You can clearly see here that student name Adam is used twice in the table and subject math is
also repeated. This violates the First Normal form. To reduce above table to First Normal
form break the table into two different tables
S_id S_Name
401 Adam
402 Alex
403 Stuart
Subject Table :
In Student table concatenation of subject_id and student_id is the Primary key. Now both the
Student table and Subject table are normalized to first normal form
Second Normal Form (2NF)
A table to be normalized to Second Normal Form should meet all the needs of First Normal
Form and there must not be any partial dependency of any column on primary key. It means that
for a table that has concatenated primary key, each column in the table that is not part of the
primary key must depend upon the entire concatenated key for its existence. If any column
depends oly on one part of the concatenated key, then the table fails Second normal form. For
example, consider a table which is not in Second normal form.
Customer Table :
In Customer table concatenation of Customer_id and Order_id is the primary key. This table is
in First Normal form but not in Second Normal form because there are partial dependencies of
columns on primary key. Customer_Name is only dependent on customer_id, Order_name is
dependent on Order_id and there is no link between sale_detail and Customer_name.
To reduce Customer table to Second Normal form break the table into following three different
tables.
Customer_Detail Table :
customer_id Customer_Name
101 Adam
102 Alex
103 Stuart
Order_Detail Table :
Order_id Order_Name
10 Order1
11 Order2
12 Order3
13 Order4
Sale_Detail Table :
Now all these three table comply with Second Normal form.
Third Normal form applies that every non-prime attribute of table must be dependent on
primary key. The transitive functional dependency should be removed from the table. The table
must be in Second Normal form. For example, consider a table with following fields.
Student_Detail Table :
In this table Student_id is Primary key, but street, city and state depends upon Zip. The
dependency between zip and other fields is called transitive dependency. Hence to apply 3NF,
we need to move the street, city and state to new table, with Zip as primary key.
Address Table :
Boyce and Codd Normal Form is a higher version of the Third Normal form. This form deals
with certain type of anamoly that is not handled by 3NF. A 3NF table which does not have
multiple overlapping candidate keys is said to be in BCNF.