A visual guide to database normalization — from 1NF to 5NF. See real table examples before and after each normal form.
Normalization is the process of organizing data in a database to reduce redundancy and improve integrity. It involves decomposing tables into smaller, well-structured relations that satisfy progressive normal forms.
Rule: Each column must contain atomic (indivisible) values, and each row must be uniquely identifiable. No repeating groups or arrays.
Problem: The Courses column stores multiple values (non‑atomic).
| StudentID | Name | Courses |
|---|---|---|
| 101 | Alice | Math, Physics |
| 102 | Bob | Chemistry |
| 103 | Carol | Math, Biology, CS |
Solution: Each course in its own row — atomic values.
| StudentID | Name | Course |
|---|---|---|
| 101 | Alice | Math |
| 101 | Alice | Physics |
| 102 | Bob | Chemistry |
| 103 | Carol | Math |
| 103 | Carol | Biology |
| 103 | Carol | CS |
Rule: Must be in 1NF, and all non‑key attributes must be fully functionally dependent on the entire primary key (no partial dependency).
Problem: OrderID + ProductID is the PK, but
ProductName depends only on ProductID (partial dependency).
| OrderID | ProductID | ProductName | Qty |
|---|---|---|---|
| 1001 | P01 | Laptop | 2 |
| 1001 | P02 | Mouse | 5 |
| 1002 | P01 | Laptop | 1 |
ProductName repeats for same ProductID.Solution: Split into two tables — OrderDetails and Products.
| OrderID | ProductID | Qty |
|---|---|---|
| 1001 | P01 | 2 |
| 1001 | P02 | 5 |
| 1002 | P01 | 1 |
| ProductID | ProductName |
|---|---|
| P01 | Laptop |
| P02 | Mouse |
Rule: Must be in 2NF, and no transitive dependency — non‑key attributes must not depend on other non‑key attributes.
Problem: DeptName depends on DeptID,
which is not the PK (EmpID). Transitive dependency: EmpID → DeptID → DeptName.
| EmpID | EmpName | DeptID | DeptName |
|---|---|---|---|
| E01 | John | D10 | Sales |
| E02 | Sarah | D20 | Engineering |
| E03 | Mike | D10 | Sales |
DeptName repeats for same DeptID.Solution: Separate Employees and Departments.
| EmpID | EmpName | DeptID |
|---|---|---|
| E01 | John | D10 |
| E02 | Sarah | D20 |
| E03 | Mike | D10 |
| DeptID | DeptName |
|---|---|
| D10 | Sales |
| D20 | Engineering |
Rule: A stricter version of 3NF. For every functional dependency X → Y, X must be a superkey. Eliminates anomalies caused by overlapping candidate keys.
Problem: Professor determines Course, but Professor
is not a superkey. Also, Student + Course is a candidate key, but Professor
depends on Course.
| Student | Course | Professor |
|---|---|---|
| S001 | Math 101 | Dr. Smith |
| S002 | Math 101 | Dr. Smith |
| S001 | CS 200 | Dr. Jones |
Solution: Split into Enrollments and CourseProfessors.
| Student | Course |
|---|---|
| S001 | Math 101 |
| S002 | Math 101 |
| S001 | CS 200 |
| Course | Professor |
|---|---|
| Math 101 | Dr. Smith |
| CS 200 | Dr. Jones |
These forms address multi‑valued and join dependencies. They are less common in practice but important for complex, highly normalized designs.
Rule: Must be in BCNF and have no multi‑valued dependencies. A multi‑valued dependency exists when two independent attributes depend on a third.
Rule: Must be in 4NF and have no join dependencies. Also known as Project‑Join Normal Form (PJNF).
A quick recap of the normal forms and their key requirements.
Key Takeaway
Normalization reduces redundancy and prevents update, insert, and delete anomalies. Start with 1NF, then progress to 3NF / BCNF for most real‑world applications. Higher forms (4NF, 5NF) are used when dealing with complex multi‑valued or join dependencies.