Scribd
Upload
5 views

Unit3-Part2-Normalization-Normal Forms

Uploaded by

kadsjzzzz
Copyright
© © All Rights Reserved
Available Formats
Download as PPTX, PDF, TXT or read online on Scribd
5 views

Unit3-Part2-Normalization-Normal Forms

Uploaded by

kadsjzzzz
Copyright
© © All Rights Reserved
Available Formats
Download as PPTX, PDF, TXT or read online on Scribd
You are on page 1/ 20

Normalization

Anomalies, Normal Forms


Normalization
• Normalization is the process of organizing the data and the attributes
of a database. It is performed to reduce the data redundancy in a
database and to ensure that data is stored logically.
• Data redundancy in DBMS means having the same data but at
multiple places. It is necessary to remove data redundancy because it
causes anomalies in a database which makes it very hard for a
database administrator to maintain it.
Why Do We Need Normalization?

• It provides a method to remove the following anomalies from the database and bring it to a more
consistent state:

• A database anomaly is a flaw in the database that occurs because of poor planning and redundancy.

• Insertion anomalies: This occurs when we are not able to insert data into a database because some
attributes may be missing at the time of insertion.

• Updation anomalies: This occurs when the same data items are repeated with the same values and
are not linked to each other.

• Deletion anomalies: This occurs when deleting one part of the data deletes the other necessary
information from the database.
Normal Forms
Normal Forms
• 1NF: A relation is in 1NF if all its attributes have an atomic value.

• 2NF: A relation is in 2NF if it is in 1NF and all non-key attributes are fully functional dependent
on the candidate key in DBMS.

• 3NF: A relation is in 3NF if it is in 2NF and there is no transitive dependency.

• BCNF: A relation is in BCNF if it is in 3NF and for every Functional Dependency, LHS is the
super key.

• Functional dependency is a relationship that exists between two sets of attributes of a


relational table where one set of attributes can determine the value of the other set of attributes.
• It is denoted by X -> Y, where X is called a determinant and Y is called dependent.
First Normal Form (1NF)

• A relation is in 1NF if every attribute is a single-valued attribute or it


does not contain any multi-valued or composite attribute, i.e., every
attribute is an atomic attribute.
• If there is a composite or multi-valued attribute, it violates the 1NF. To
solve this, we can create a new row for each of the values of the multi-
valued attribute to convert the table into the 1NF.
1NF
•Here, the Employee Phone
Number is a multi-valued
attribute. So, this relation is not
in 1NF.

•To convert this table into 1NF,


we make new rows with each
Employee Phone Number
1NF
Second Normal Form (2NF)

• The normalization of 1NF relations to 2NF involves the elimination of partial dependencies.
• A partial dependency in DBMS exists when any non-prime attributes, i.e., an attribute not a
part of the candidate key, is not fully functionally dependent on one of the candidate keys.

• For a relational table to be in second normal form, it must satisfy the following rules:

• The table must be in first normal form.


• It must not contain any partial dependency, i.e., all non-prime attributes are fully functionally
dependent on the primary key.
• If a partial dependency exists, we can divide the table to remove the partially dependent
attributes and move them to some other table where they fit in well.
2NF

In the above table, the prime attributes of the table are Employee Code and Project ID.
We have partial dependencies in this table because Employee Name can be determined
by Employee Code and Project Name can be determined by Project ID. Thus, the above
relational table violates the rule of 2NF.
• To remove partial dependencies from this table and normalize it into
2NF second normal form, we can decompose the
<EmployeeProjectDetail> table into the following three tables:
2NF
• Thus, we’ve converted the <EmployeeProjectDetail> table into 2NF
by decomposing it into <EmployeeDetail>, <ProjectDetail> and
<EmployeeProject> tables.
• The above tables satisfy the following two rules of 2NF as they are in
1NF and every non-prime attribute is fully dependent on the primary
key.
• The relations in 2NF are clearly less redundant than relations in 1NF.
However, the decomposed relations may still suffer from one or more
anomalies due to the transitive dependency.
• We will remove the transitive dependencies in the Third Normal Form.
Third Normal Form (3NF)

• The normalization of 2NF relations to 3NF involves the elimination of


transitive dependencies in DBMS.
• A functional dependency X -> Z is said to be transitive if the following three functional
dependencies hold:
• X -> Y
• Y does not -> X
• Y -> Z
• For a relational table to be in third normal form, it must satisfy the following rules:

1. The table must be in the second normal form.


2. No non-prime attribute is transitively dependent on the primary key.
3. For each functional dependency X -> Z at least one of the following conditions hold:
a) X is a super key of the table.
b) Z is a prime attribute of the table.
3NF
• If a transitive dependency exists, we can divide the table to remove the
transitively dependent attributes and place them to a new table along
with a copy of the determinant.
3NF

The above table is not in 3NF because it has Employee Code -> Employee
City transitive dependency because:
•Employee Code -> Employee Zipcode
•Employee Zipcode -> Employee City
Also, Employee Zipcode is not a super key and Employee City is not a
prime attribute.
3NF

• To remove transitive dependency from this table and normalize it into


the third normal form, we can decompose the <EmployeeDetail> table
into the following two tables:
BCNF
• The 2NF and 3NF impose some extra conditions on dependencies on
candidate keys and remove redundancy caused by that. However, there
may still exist some dependencies that cause redundancy in the
database.
• These redundancies are removed by a more strict normal form known
as BCNF.
BCNF
• Boyce-Codd Normal Form(BCNF) is an advanced version of 3NF as it contains
additional constraints compared to 3NF.

• For a relational table to be in Boyce-Codd normal form, it must satisfy the following
rules:

1. The table must be in the third normal form.


2. For every non-trivial functional dependency X -> Y, X is the superkey of the
table. That means X cannot be a non-prime attribute if Y is a prime attribute.
A superkey is a set of one or more attributes that can uniquely identify a row in a
database table.
BCNF

The above table satisfies all the normal forms till 3NF, but it violates the rules of
BCNF because the candidate key of the above table is
{Employee Code, Project ID}.
For the non-trivial functional dependency,
Project Leader -> Project ID, Project ID is a prime attribute, but Project Leader is a
non-prime attribute. This is not allowed in BCNF.
BCNF

Thus, we’ve converted the <EmployeeProjectLead> table into BCNF by decomposing it


into <EmployeeProject> and <ProjectLead> tables.

You might also like