Normalization of Database

Normalization of Database
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
 Normalization Rule
Normalization rule are divided into following normal form.
• First Normal Form
• Second Normal Form
• Third Normal Form
• BCNF
• Fourth Normal Form
• Fifth Normal Form

First Normal Form (1NF)

As per First Normal Form, no two Rows of data must contain repeating group of
information i.e each set of column must have a unique value, such that multiple
columns cannot be used to fetch the same row. Each table should be organized into
rows, and each row should have a primary key that distinguishes it as unique.
Another Example of 1NF in Student Table:
Student Age Subject
Adam 15 Biology, Maths
Alex 14 Maths
Stuart 17 Maths

In First Normal Form, 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
Student Table following 1NF will be:
Student Age Subject
Adam 15 Biology
Adam 15 Maths
Alex 14 Maths
Stuart 17 Maths
 Second Normal Form (2NF)

• Before we learn about the second normal form, we need to understand the following
• Prime attribute − An attribute, which is a part of the prime-key, is known as a
prime attribute.
• Non-prime attribute − An attribute, which is not a part of the prime-key, is said to
be a non-prime attribute.
If we follow second normal form, then every non-prime attribute should be fully
functionally dependent on prime key attribute. That is, if X → A holds, then there
should not be any proper subset Y of X, for which Y → A also holds true.
 Another Example 2NF

We see here in Student_Project relation that the prime key attributes are Stu_ID and Proj_ID.
According to the rule, non-key attributes, i.e. Stu_Name and Proj_Name must be dependent upon
both and not on any of the prime key attribute individually. But we find that Stu_Name can be
identified by Stu_ID and Proj_Name can be identified by Proj_ID independently. This is called
partial dependency, which is not allowed in Second Normal Form.
Third Normal Form (3NF)
For a relation to be in Third Normal Form, it must be in Second Normal form and the
following must satisfy −
• No non-prime attribute is transitively dependent on prime key attribute.
• For any non-trivial functional dependency, X → A, then either −
• X is a superkey or,
• A is prime attribute.

The advantage of removing transitive dependency is,

• Amount of data duplication is reduced.
• Data integrity achieved.
 Another Example 3NF

We find that in the above Student_detail relation, Stu_ID is the key and only
prime key attribute. We find that City can be identified by Stu_ID as well as Zip
itself. Neither Zip is a superkey nor is City a prime attribute. Additionally,
Stu_ID → Zip → City, so there exists transitive dependency.
What do you understand by Functional dependency?
Functional dependency in DBMS, as the name suggests is a relationship between attributes
of a table dependent on each other. A relation is said to be in Functional dependency when
one attribute uniquely defines another attribute.

For Example, R is a Relation, X and Y are two attributes. T1 and T2 are two tuples.
Then,T1[X]=T2[X] and T1[Y]=T2[Y] means the value of component X uniquely define the
value of component Y.
Also, X->Y means Y is functionally dependent on X.

Example
The following is an example that would make it easier to understand functional dependency:
• We have a <Department> table with two attributes: DeptId and DeptName.
The DeptId is our primary key. Here, DeptId uniquely identifies the DeptName attribute. This is because if
you want to know the department name, then at first you need to have the DeptId. Therefore, the above
functional dependency between DeptId and DeptName can be determined as DeptId is functionally dependent
on DeptName:
• DeptId -> DeptName

3 Types of Functional Dependency

• Trivial Functional Dependency
• It occurs when B is a subset of A in: A ->B
• The following is a trivial functional dependency since DeptId is a subset of DeptId and DeptName
• { DeptId, DeptName } -> Dept Id

• Non –Trivial Functional Dependency

• It occurs when B is not a subset of A in: A ->B
• DeptId -> DeptName
• The above is a non-trivial functional dependency since DeptName is a not a subset of DeptId.

• Completely Non - Trivial Functional Dependency

• It occurs when A intersection B is null in:A ->B
Student_Detail Table :
Student_id Student_name DOB Street city State Zip

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.
New Student_Detail Table :
Student_id Student_name DOB Zip

Address Table :
Zip Street city state
Boyce and Codd Normal Form (BCNF)
• Boyce-Codd Normal Form (BCNF) is an extension of Third Normal Form on
strict terms. BCNF states that −

• For any non-trivial functional dependency, X → A, X must be a super-key.

• In the above image, Stu_ID is the super-key in the relation Student_Detail and Zip
is the super-key in the relation ZipCodes. So,
• Stu_ID → Stu_Name, Zip and
• Zip → City

Which confirms that both the relations are in BCNF.

Boyce-Codd Normal Form (BCNF)
• 3NF and all tables in the database should be only one primary key.

Fourth Normal Form (4NF)

• Tables cannot have multi-valued dependencies on a Primary Key.

Fifth Normal Form (5NF)

• A composite key shouldn't have any cyclic dependencies.
Define Normalization and De-Normalization. Which one
vary is important for DBMS and why?
• Normalization is the process of removing the redundant data from the database by
splitting the table in a well-defined manner in order to maintain data integrity.
This process saves much of the storage space.
• De-Normalization is the process of adding up redundant data on the table in order
to speed up the complex queries and thus achieve better performance.

Normalization is important because it is a process of analyzing the given relation

schemas based on their Functional Dependencies (FDs) and primary key to achieve
the properties.
• Minimizing redundancy,
• Minimizing insertion, deletion and update anomalies.
Third Normal Form Comparison of BCNF and
3NF
• BCNF or 3NF?
• Relations in BCNF and 3NF
• Relations in BCNF: no repetition of information
• Relations in 3NF: problem of repetition of information
• Decomposition in BCNF and in 3NF
• It is always possible to decompose a relation into relations in 3NF and
• the decomposition is lossless
• dependencies are preserved
• It is always possible to decompose a relation into relations in BCNF and
• the decomposition is lossless
• the information is not repeated
Example: Suppose there is a company wherein employees work in more than one department. They
store the data like this:
emp_id emp_nationality emp_dept dept_type dept_no_of_emp
1001 Austrian Production and planning D001 200
1001 Austrian stores D001 250
1002 American design and technical support D134 100
1002 American Purchasing department D134 600

Functional dependencies in the table above:

• emp_id -> emp_nationality

emp_dept -> {dept_type, dept_no_of_emp}

Candidate key: {emp_id, emp_dept}

• The table is not in BCNF as neither emp_id nor emp_dept alone are keys.
• To make the table comply with BCNF we can break the table in three tables like this:
emp_nationality table:
emp_nationality table: emp_dept table:
emp_id emp_nationality emp_dept dept_type dept_no_of_emp
1001 Austrian Production and planning D001 200
1002 American stores D001 250
design and technical support D134 100
Purchasing department D134 600

emp_dept_mapping table:
Functional dependencies:
emp_id emp_dept
1001 Production and planning emp_id -> emp_nationality
emp_dept -> {dept_type, dept_no_of_emp}
1001 stores
Candidate keys:
1002 design and technical support For first table: emp_id
1002 Purchasing department For second table: emp_dept
For third table: {emp_id, emp_dept}
1NF
2NF

3NF
Final Relation with table name
END