Types of NF
Types of NF
Definition of Normalization
“Normalization is a process of designing a consistent database by minimizing redundancy
and ensuring data integrity through decomposition which is lossless.”
Features of Normalization
Types of Normalization
Following are the types of Normalization:
1. First Normal Form
2. Second Normal Form
3. Third Normal Form
4. Fourth Normal Form
5. Fifth Normal Form
6. BCNF (Boyce – Codd Normal Form)
7. DKNF (Domain Key Normal Form)
1 ABC Sales
1 ABC Production
3 XYZ Marketing
1 ABC 38
1 ABC 38
2 PQR 38
3 XYZ 40
3 XYZ 40
The above table is in 1NF. Each attribute has atomic values. However, it is not in 2NF
because non prime attribute Employee_Age is dependent on ECode alone, which is a proper
subset of candidate key. This violates the rule for 2NF as the rule says 'No non-prime
attribute is dependent on the proper subset of any candidate key of the table'.
ECode Employee_Age
1 38
2 38
3 40
Employee2 Table
ECode Employee_Name
1 ABC
1 ABC
2 PQR
3 XYZ
3 XYZ
Now, the above tables comply with the Second Normal Form (2NF).
In the above <Employee> table, EId is a primary key but City, State depends upon Zip
code.
The dependency between Zip and other fields is called Transitive Dependency.
Therefore we apply 3NF. So, we need to move the city and state to the new
<Employee_Table2> table, with Zip as a Primary key.
<Employee_Table1> Table
<Employee_Table2> Table
The advantage of removing transitive dependency is, it reduces the amount of data
dependencies and achieves the data integrity.
In the above example, using with the 3NF, there is no redundancy of data while inserting
the new records.
The City, State and Zip code will be stored in the separate table. And therefore the updation
becomes more easier because of no data redundancy.
BCNF which stands for Boyce – Code Normal From is developed by Raymond F. Boyce and E.
F. Codd in 1974.
BCNF is a higher version of 3NF.
It deals with the certain type of anomaly which is not handled by 3NF.
A table complies with BCNF if it is in 3NF and any attribute is fully functionally dependent
that is A → B. (Attribute 'A' is determinant).
If every determinant is a candidate key, then it is said to be BCNF.
Candidate key has the ability to become a primary key. It is a column in a table.
Candidate Key:
Empid
DeptName
The above table is not in BCNF as neither Empid nor DeptName alone are keys.
We can break the table in three tables to make it comply with BCNF.
<Employee> Table
Empid EmpName
E001 ABC
E002 XYZ
<Department> Table
DeptName DeptType
Production D001
Sales D002
<Emp_Dept> Table
Empid DeptName
E001 Production
E002 Sales
Candidate Key:
<Employee> Table : Empid
<Department> Table : DeptType
<Emp_Dept> Table : Empid, DeptType
So, now both the functional dependencies left side part is a key, so it is in the BCNF.
For example : A table contains a list of three things that is 'Student', 'Teacher', 'Book'.
Teacher is in charge of Student and recommended book for each student. These three
elements (Student, Teacher and Book) are independent of one another. Changing the
student's recommended book, for instance, has no effect on the student itself. This is an
example of multivalued dependency, where an item depends on more than one value. In
this example, the student depends on both teacher and book.
Therefore, 4NF states that a table should not have more than one dependencies.
DKNF stands for Domain Key Normal Form requires the database that contains no
constraints other than domain constraints and key constraints.
In DKNF, it is easy to build a database.
It avoids general constraints in the database which are not clear domain or key constraints.
The 3NF, 4NF, 5NF and BCNF are special cases of the DKNF.
It is achieved when every constraint on the relation is a logical consequence of the
definition.