1NF, 2NF, and 3NF are successive stages of database normalization. 1NF makes values atomic, 2NF removes partial dependencies, and 3NF removes transitive dependencies.
The Reasoning
Normalization organizes relational database tables to reduce data duplication and prevent insertion, update, and deletion anomalies. Each higher normal form includes all the requirements of the preceding form.
| Normal form | Requirement | Problem removed |
|---|---|---|
| 1NF | Each field contains one atomic value, and each record is uniquely identifiable. | Repeating groups or multiple values stored in one field |
| 2NF | The table is in 1NF, and every non-key attribute is fully functionally dependent on the whole candidate key. | Partial dependency on only part of a composite key |
| 3NF | The table is in 2NF, and non-key attributes do not depend on other non-key attributes. | Transitive dependency |
Consider this relation:
Enrollment(StudentID, CourseID, StudentName, CourseName, InstructorID, InstructorOffice, Grade)
Its composite primary key is (StudentID, CourseID).
For 1NF, every row represents one student-course enrollment, and fields contain single values. A field containing Math, Physics would violate 1NF.
For 2NF, attributes that depend on only part of the composite key are separated. StudentName depends only on StudentID, while CourseName and InstructorID depend only on CourseID. Suitable relations include:
Student(StudentID, StudentName)Course(CourseID, CourseName, InstructorID, InstructorOffice)Enrollment(StudentID, CourseID, Grade)
For 3NF, InstructorOffice must be removed from Course because it depends on InstructorID, not directly on CourseID. Create Instructor(InstructorID, InstructorOffice) instead.
A common misconception is that 2NF simply means “no duplicate data.” More precisely, 2NF removes partial dependencies; duplication may indicate poor design but is not itself the formal test.
Exam Technique
In an IB A3.2 Database Design response, identify the key, state the relevant functional dependency, and show the decomposed relations. Always explain why a dependency violates a normal form rather than merely naming the resulting tables.
