Database Normalization
Database Normalization
Normalization is the process of removing redundant data from your tables in order to
improve storage efficiency, data integrity and scalability. This improvement is balanced against
an increase in complexity and potential performance losses from the joining of the normalized
tables at query-time. There are two goals of the normalization process: eliminating redundant
data (for example, storing the same data in more than one table) and ensuring data dependencies
make sense (only storing related data in a table).
• To make database structure flexible i.e. it should be possible to add new data values and rows
without reorganizing the database structure.
• Data should be consistent throughout the database i.e. it should not suffer from following
anomalies.
Redundancy means having multiple copies of same data in the database. This problem arises
when a database is not normalized. Suppose a table of student details attributes are: student Id,
student name, college name, college rank, course opted.
As it can be observed that values of attribute college name, college rank, course is being repeated
which can lead to problems. Problems caused due to redundancy are: Insertion anomaly,
Deletion anomaly, and Updation anomaly.
• Insert Anomaly – Due to lack of data i.e., all the data available for insertion such that null
values in keys should be avoided. This kind of anomaly can seriously damage a database
• Update Anomaly – It is due to data redundancy i.e. multiple occurrences of same values in a
column. This can lead to inefficiency.
• Deletion Anomaly – It leads to loss of data for rows that are not stored elsewhere. It could
result in loss of vital data.
Normalization
Second Normal Form (2NF) A relation will be in 2NF if it is in 1NF and all non-key attributes are fully
functional dependent on the primary key.
Third Normal Form (3NF) A relation will be in 3NF if it is in 2NF and no transition dependency exists.
Boyce Codd Normal Form A relation will be in 4NF if it is in Boyce Codd normal form and has no multi-
(BCNF) valued dependency.
First Normal Form (1NF)
EMPLOYEE table:
14 John 7272826385, UP
9064738238
The decomposition of the EMPLOYEE table into 1NF has been shown below:
14 John 7272826385 UP
14 John 9064738238 UP
TEACHER table
25 Chemistry 30
25 Biology 30
47 English 35
83 Math 38
83 Computer 38
To convert the given table into 2NF, we decompose it into two tables:
TEACHER_DETAIL table:
TEACHER_ID TEACHER_AGE
25 30
47 35
83 38
TEACHER_SUBJECT table:
TEACHER_ID SUBJECT
25 Chemistry
25 Biology
47 English
83 Math
83 Computer
o A relation will be in 3NF if it is in 2NF and not contain any transitive partial dependency.
o 3NF is used to reduce the data duplication. It is also used to achieve the data integrity.
o If there is no transitive dependency for non-prime attributes, then the relation must be in
third normal form.
A relation is in third normal form if it holds atleast one of the following conditions for every
non-trivial function dependency X → Y.
1. X is a super key.
2. Y is a prime attribute, i.e., each element of Y is part of some candidate key.
Example:
Non-prime attributes: In the given table, all attributes except EMP_ID are non-prime.
Here, EMP_STATE & EMP_CITY dependent on EMP_ZIP and EMP_ZIP dependent on
EMP_ID. The non-prime attributes (EMP_STATE, EMP_CITY) transitively dependent
on super key(EMP_ID). It violates the rule of third normal form.
That's why we need to move the EMP_CITY and EMP_STATE to the new
<EMPLOYEE_ZIP> table, with EMP_ZIP as a Primary key.
EMPLOYEE table:
EMPLOYEE_ZIP table:
201010 UP Noida
02228 US Boston
60007 US Chicago
06389 UK Norwich
462007 MP Bhopal
Example: Let's assume there is a company where employees work in more than one department.
EMPLOYEE table:
1. EMP_ID → EMP_COUNTRY
2. EMP_DEPT → {DEPT_TYPE, EMP_DEPT_NO}
The table is not in BCNF because neither EMP_DEPT nor EMP_ID alone are keys.
To convert the given table into BCNF, we decompose it into three tables:
EMP_COUNTRY table:
EMP_ID EMP_COUNTRY
264 India
264 India
EMP_DEPT table:
EMP_DEPT_MAPPING table:
EMP_ID EMP_DEPT
D394 283
D394 300
D283 232
D283 549
Functional dependencies:
1. EMP_ID → EMP_COUNTRY
2. EMP_DEPT → {DEPT_TYPE, EMP_DEPT_NO}
Candidate keys:
Now, this is in BCNF because left side part of both the functional dependencies is a key.
On decomposition of a relation into smaller relations with fewer attributes on normalization the
resulting relations whenever joined must result in the same relation without any extra rows. The
join operations can be performed in any order. This is known as Lossless Join decomposition.
The resulting relations (tables) obtained on normalization should possess the properties such as
each row must be identified by a unique key, no repeating groups, homogeneous columns, each
column is assigned a unique name etc.
Advantages of Normalization
• More flexible data structure i.e. we should be able to add new rows and data values easily
• Easier to maintain data structure i.e. it is easy to perform operations and complex queries can
be easily handled.
Disadvantages of Normalization
• You cannot start building the database before you know what the user needs.
• On normalizing the relations to higher normal forms i.e. 4NF, 5NF the performance degrades.
• It is very time consuming and difficult process in normalizing relations of higher degree.
• Careless decomposition may leads to bad design of database which may leads to serious
problems.