Sign Up to our social questions and Answers Engine to ask questions, answer people’s questions, and connect with other people.
Login to our social questions & Answers Engine to ask questions answer people’s questions & connect with other people.
Lost your password? Please enter your email address. You will receive a link and will create a new password via email.
Please briefly explain why you feel this question should be reported.
Please briefly explain why you feel this answer should be reported.
Please briefly explain why you feel this user should be reported.
In relational database design, there is a concept of database normalization or simply normalization, which is a process of organizing columns (attributes) and tables (relations) to reduce data redundancy and improve data integrity. Wikipedia
What is an explanation based on examples about what 1NF, 2NF, 3NF, and 3.5NF (Boyce-Codd BCNF) mean?
1NF is the most basic of normal forms – each cell in a table must contain only one piece of information, and there can be no duplicate rows.
2NF and 3NF are all about being dependent on the primary key. Recall that a primary key can be made up of multiple columns. As Chris said in his response:
The data depends on the key [1NF], the whole key [2NF] and nothing but the key [3NF] (so help me Codd).
2NF
Say you have a table containing courses that are taken in a certain semester, and you have the following data:
This is not in 2NF, because the fourth column does not rely upon the entire key – but only a part of it. The course name is dependent on the Course’s ID, but has nothing to do with which semester it’s taken in. Thus, as you can see, we have duplicate information – several rows telling us that IT101 is programming, and IT102 is Databases. So we fix that by moving the course name into another table, where CourseID is the ENTIRE key.
No redundancy!
3NF
Okay, so let’s say we also add the name of the teacher of the course, and some details about them, into the RDBMS:
Now hopefully it should be obvious that TeacherName is dependent on TeacherID which is not part of the primary key – so this is not in 3NF. To fix this, we do much the same as we did in 2NF – take the TeacherName field out of this table, and put it in its own, which has TeacherID as the key.
No redundancy!!
One important thing to remember is that if something is not in 1NF, it is not in 2NF or 3NF either. So each additional Normal Form requires everything that the lower normal forms had, plus some extra conditions, which must all be fulfilled.