Types of Normal Forms

Normalization — Quick Reference

1NF (First Normal Form) — Every column holds a single, atomic value; no repeating groups or lists.

❌ A student's Courses field storing "DBMS, OS" together ✅ Split into separate rows: one row for DBMS, another for OS

2NF (Second Normal Form) — Must be in 1NF, and no attribute depends on only part of a composite key.

In a table keyed on (Student_ID, Course), if Student_Name depends only on Student_ID (not on Course too), that's a partial dependency. ✅ Fix: move Student_Name into its own Student table keyed on Student_ID alone.

3NF (Third Normal Form) — Must be in 2NF, and no non-key attribute depends on another non-key attribute.

Dept_Name depends on Dept_ID, and Dept_ID isn't the primary key — so Dept_Name is one step removed from the actual key (a transitive dependency). ✅ Fix: move Dept_ID and Dept_Name into their own Department table.

BCNF (Boyce-Codd Normal Form) — A stricter 3NF: every determinant (anything that determines another attribute) must itself be a candidate key.

If Professor → Department, but Professor alone isn't a candidate key of the table, that's a BCNF violation even though the table might already satisfy 3NF. ✅ Fix: separate the table so Professor→Department lives somewhere Professor is the key.

4NF (Fourth Normal Form) — Must be in BCNF, and no multivalued dependency exists (one attribute independently determining multiple unrelated values of another).

Swati has hobbies {Reading, Painting} and languages {English, Hindi} — unrelated to each other, but stored together they force every hobby to pair with every language. ✅ Fix: split into a Student_Hobby table and a separate Student_Language table.

5NF (Fifth Normal Form / Project-Join Normal Form) — Must be in 4NF, and every join dependency is implied by the candidate keys — meaning the data can be split into smaller tables and joined back together without creating extra, incorrect rows. Rare in practice.

🧠 One-Line Summary