What is DBMS Normalisation?

Normalization in a database is the process in which we organize the given data by

minimizing the redundancy present in a relation. In this, we eliminate the anomalies
present, namely - update, insertion and deletion. Normalization divides the single table
into smaller tables and links them using relationships. The different normal forms help
us minimize redundancy in the database table.
To perform normalization in the database, we decompose the table into multiple tables.
This process keeps repeating until we achieve SRP (Single Responsibility Principle).
The SRP states that one table should have one role only.

Types of DBMS Normal Form

Normalization in a database is done through a series of normal forms.

Normal Description
Form

1NF If a table has no repeated groups, it is

in 1NF.

2NF If a table is in 1NF and every non-key

attribute is fully dependent on the
primary key, then it is in 2NF.

3NF If a table is in 2NF and has no transitive

dependencies, it is in 3NF.

BCNF If a table is in 3NF and every non-prime

attribute fully dependent on the
candidate keys, then it is in BCNF.

First Normal Form (1NF)

In 1NF, every database cell or relation contains an atomic value that can’t be further
divided, i.e., the relation shouldn’t have multivalued attributes.
Example:
The following table contains two phone number values for a single attribute.
So to convert it into 1NF, we decompose the table as the following -

Here, we can notice data repetition, but 1NF doesn’t care about it.

Second Normal Form (2NF)

In 2NF, the relation present should be 1NF, and no partial dependency should exist.
Partial dependency is when the non-prime attributes depend entirely on the candidate
or primary key, even if the primary key is composite.

Example 1: (depicting partial dependency issues)

If given with a relation R(A, B, C, D) where we have {A, B} as the primary key where A
and B can’t be NULL simultaneously, but both can be NULL independently and C, D are
non-prime attributes. If B is NULL and we are given the functional dependency, say,
B → C. So can this ever hold?
As B contains NULL, it can never determine the value of C. So, as B → C is a partial
dependency, it creates a problem. Therefore, the non-prime attributes cannot be
determined by a part of the primary key. We can remove the partial dependency present
by creating two relations ( the 2NF conversion)-
Relation 1 = R1(ABD), where {A, B} is the primary key. AB determines D.
Relation 2 = R1(BC), where B is the primary key. And from this, B determines C.

Example 2:
Consider the following table. Its primary key is {StudentId, ProjectId}.
The Functional dependencies given are -
StudentId → StudentName
ProjectId → ProjectName

As it represents partial dependency, we decompose the table as follows -

Here projectId is mentioned in

both tables to set up a relationship between them.

Third Normal Form (3NF)

In 3NF, the given relation should be 2NF, and no transitivity dependency should exist,
i.e., non-prime attributes should not determine non-prime attributes.
Example:
Consider the following scenario where the functional dependencies are -
A → B and B → C, where A is the primary key.
As here, a non-prime attribute can be determined by a prime attribute, which implies
transitivity dependency exists. To remove this, we decompose this and convert it into
3NF. So, we create two relations -
R1(A, B), where A is the primary key and R2(B, C), where B is the primary key.

Boyce-Codd Normal Form(BCNF)

In BCNF, the relation should be in 3NF.If given a relation, say A → B, A should be a
super key in this. This implies that no prime attribute should be determined or derived
from any other prime or non-prime attribute.
Example:
Given the following table. Its candidate keys are {Student, Teacher} and {Student,
Subject}.
The Functional dependencies given are -
{Student, Teacher} → Subject
{Student, Subject} → Teacher
Teacher → Subject

As this table is not in BCNF form, so we decompose it into the following tables:

Here Teacher is mentioned in both tables to set up a relationship between them.

Advantages of Normalization
The following are the advantages of normalization in a database:
1. The redundancy in data is minimized, leading to a smaller size of the database.

2. It removes the data inconsistency.

3. The database becomes easy to maintain when we organize it using normal forms.

4. It becomes comparatively easier to write queries as the size of the database decreases.

5. Decreased database size further reduces the complexity of sorting and finding any value in
the database.
Disadvantages of Normalization
The following are the disadvantages of normalization in database:
 1. Decomposing the table in Normalization can lead to a poorer database design and severe
problems.

2. The process of normalization in the database is very time-consuming as we decompose

the table repeatedly into different normal forms until we reach the SRP situation.

3. It becomes tough to normalize relations that are of a higher degree.

Functional Dependency
The functional dependency is a relationship that exists between two attributes. It typically
exists between the primary key and non-key attribute within a table.

1. X → Y
The left side of FD is known as a determinant, the right side of the production is known as a
dependent.

For example:

Assume we have an employee table with attributes: Emp_Id, Emp_Name, Emp_Address.

Advertisement

Here Emp_Id attribute can uniquely identify the Emp_Name attribute of employee table
because if we know the Emp_Id, we can tell that employee name associated with it.

Functional dependency can be written as:

1. Emp_Id → Emp_Name
We can say that Emp_Name is functionally dependent on Emp_Id.

Types of Functional dependency

 1. Trivial functional dependency
o A → B has trivial functional dependency if B is a subset of A.
o The following dependencies are also trivial like: A → A, B → B
Example:

1. Consider a table with two columns Employee_Id and Employee_Name.

2. {Employee_id, Employee_Name} → Employee_Id is a trivial functional dependency
as
3. Employee_Id is a subset of {Employee_Id, Employee_Name}.
4. Also, Employee_Id → Employee_Id and Employee_Name → Employee_Name are tr
ivial dependencies too.

2. Non-trivial functional dependency

o A → B has a non-trivial functional dependency if B is not a subset of A.
o When A intersection B is NULL, then A → B is called as complete non-trivial.
Example:

1. ID → Name,
2. Name → DOB

What is Decomposition in DBMS?

When we divide a table into multiple tables or divide a relation into multiple
relations, then this process is termed Decomposition in DBMS. We perform
decomposition in DBMS when we want to process a particular data set. It is
performed in a database management system when we need to ensure
consistency and remove anomalies and duplicate data present in the
database. When we perform decomposition in DBMS, we must try to ensure
that no information or data is lost.
Decomposition in DBMS

Decomposition in DBMS

Types of Decomposition
There are two types of Decomposition:
• Lossless Decomposition
• Lossy Decomposition

Types of Decomposition
Lossless Decomposition
The process in which where we can regain the original relation R with the help
of joins from the multiple relations formed after decomposition. This process
is termed as lossless decomposition. It is used to remove the redundant data
from the database while retaining the useful information. The lossless
decomposition tries to ensure following things:
• While regaining the original relation, no information should be lost.
• If we perform join operation on the sub-divided relations, we must get the
original relation.
Example:
There is a relation called R(A, B, C)
A B C

55 16 27

48 52 89

Now we decompose this relation into two sub relations R1 and R2

R1(A, B)
A B

55 16

48 52

R2(B, C)
B C

16 27

52 89

After performing the Join operation we get the same original relation
A B C

55 16 27

48 52 89

Lossy Decomposition
As the name suggests, lossy decomposition means when we perform join
operation on the sub-relations it doesn't result to the same relation which was
decomposed. After the join operation, we always found some extraneous
tuples. These extra tuples genrates difficulty for the user to identify the original
tuples.
Example:
We have a relation R(A, B, C)
A B C

1 2 1

2 5 3

3 3 3

Now , we decompose it into sub-relations R1 and R2

R1(A, B)
A B

1 2

2 5

3 3

R2(B, C)
B C

2 1

5 3

3 3

Now After performing join operation

A B C

1 2 1

2 5 3

2 3 3
 A B C

3 5 3

3 3 3

Properties of Decomposition
• Lossless: All the decomposition that we perform in Database
management system should be lossless. All the information should not be
lost while performing the join on the sub-relation to get back the original
relation. It helps to remove the redundant data from the database.
• Dependency Preservation: Dependency Preservation is an important
technique in database management system. It ensures that the functional
dependencies between the entities is maintained while performing
decomposition. It helps to improve the database efficiency, maintain
consistency and integrity.
• Lack of Data Redundancy: Data Redundancy is generally termed as
duplicate data or repeated data. This property states that the
decomposition performed should not suffer redundant data. It will help us
to get rid of unwanted data and focus only on the useful data or
information.