Normalization is the process of organising the columns of a relation so that the same fact is never stored in two places, which is what kills update, insertion, and deletion anomalies. It is not decoration. A badly designed table quietly corrupts data every time someone edits it, and normalization is the formal cure.
This is one of the highest-yield topics in DBMS, and it rewards a reader who learns the rules exactly rather than by feel. Get functional dependencies right and the normal forms fall out of them mechanically. Let us build it up properly.
Functional dependencies: the foundation
A functional dependency X → Y means: if two rows agree on all the attributes in X, they must agree on Y. X determines Y. Write StudentID → StudentName and you are asserting that one StudentID can never map to two different names.
A candidate key is a minimal set of attributes that functionally determines every attribute in the relation. An attribute that belongs to some candidate key is a prime attribute; every other attribute is non-prime. These two words carry the entire 2NF and 3NF definitions, so fix them now.
A dependency is partial if a non-prime attribute depends on only part of a candidate key. It is transitive if a non-prime attribute depends on another non-prime attribute (X → Y and Y → Z, so X → Z through the middle).
First normal form (1NF): atomic values
A relation is in 1NF if every cell holds a single, atomic value, with no repeating groups or multivalued fields. Consider this table, where one enrolment row crams two courses into a cell:
StudentID | StudentName | Courses |
|---|---|---|
S1 | Asha | CS101, CS102 |
That "CS101, CS102" cell breaks 1NF. To fix it, split into atomic rows, one course per row:
StudentID | StudentName | CourseID |
|---|---|---|
S1 | Asha | CS101 |
S1 | Asha | CS102 |
Now every value is atomic. 1NF is the entry ticket, everything else builds on it.
A relation to decompose
Take one wide relation and carry it all the way to BCNF. Let R hold enrolment records:
R(StudentID, StudentName, CourseID, CourseName, InstructorID, InstructorName, Grade)
The functional dependencies are:
StudentID → StudentName
CourseID → CourseName, InstructorID
InstructorID → InstructorName
{StudentID, CourseID} → Grade
The only candidate key is {StudentID, CourseID}, because you need both to pin down a Grade. So StudentID, CourseID are prime; everything else is non-prime.
Second normal form (2NF): kill partial dependencies
A relation is in 2NF if it is in 1NF and no non-prime attribute is partially dependent on a candidate key, that is, every non-prime attribute depends on the whole key, not part of it.
In R, StudentID → StudentName means StudentName depends on only half the key. CourseID → CourseName, InstructorID is another partial dependency. Both violate 2NF. Split off each partial dependency into its own relation:
STUDENT(StudentID, StudentName)
COURSE(CourseID, CourseName, InstructorID, InstructorName)
ENROLL(StudentID, CourseID, Grade)
Now ENROLL's only non-prime attribute, Grade, depends on the full key {StudentID, CourseID}. All three are in 2NF.
Third normal form (3NF): kill transitive dependencies
A relation is in 3NF if it is in 2NF and no non-prime attribute is transitively dependent on the key. The clean test: for every non-trivial dependency X → A, either X is a superkey, or A is a prime attribute.
Look at COURSE(CourseID, CourseName, InstructorID, InstructorName). Here CourseID → InstructorID and InstructorID → InstructorName, so InstructorName depends on the key only through InstructorID. That is a transitive dependency, and it violates 3NF. Decompose:
COURSE(CourseID, CourseName, InstructorID)
INSTRUCTOR(InstructorID, InstructorName)
The full schema is now STUDENT, COURSE, INSTRUCTOR, and ENROLL. Every non-key attribute depends on its key, the whole key, and nothing but the key. That is the one-line folk statement of 3NF, and it is exactly right.
Boyce-Codd normal form (BCNF): the stricter cousin
A relation is in BCNF if for every non-trivial functional dependency X → A, X is a superkey. No exception for prime attributes. BCNF is 3NF with the "or A is prime" escape hatch removed. All four relations above are already in BCNF, because in each the only determinant is the key itself.
The difference between 3NF and BCNF
The gap shows only when a relation has overlapping candidate keys. Consider R(Student, Subject, Teacher), where each teacher teaches exactly one subject, and a student takes a subject from exactly one teacher:
{Student, Subject} → Teacher
Teacher → Subject
The candidate keys are {Student, Subject} and {Student, Teacher}, so all three attributes are prime. Now test Teacher → Subject. Teacher is not a superkey, so BCNF is violated. But 3NF survives, because Subject is a prime attribute and 3NF forgives a dependency whose right side is prime. So this relation is in 3NF and not in BCNF. That single example is the crispest statement of the difference, and examiners reuse it constantly.
Normalization questions in GATE, UGC NET and placements
GATE CS loves the mechanical questions. Given a relation and a set of dependencies, find all candidate keys, then name the highest normal form the relation satisfies. Decomposition questions and "is this decomposition lossless and dependency-preserving" appear regularly. Compute candidate keys carefully, since one missed key flips your whole answer. Our GATE CS exam category collects the full DBMS sequence around this.
UGC NET Computer Science leans on the definitions: which normal form removes partial dependency, which removes transitive dependency, and the 3NF-versus-BCNF distinction as a direct one-mark question. Precise wording wins here.
Placement and company tests ask the applied version, "what is normalization and why", spot the anomaly in a given table, and the always-popular 3NF versus BCNF. The Student-Subject-Teacher example is the answer interviewers are fishing for.
KnowledgeGate's published question bank carries over two thousand DBMS questions, and normalization is one of its densest sub-areas, so there is no shortage of drill on exactly these patterns.
Practise it, do not just read it
Normalization clicks the moment you compute candidate keys by hand and watch the anomalies disappear.
Work the full topic with solved examples on the Normalization 1NF to BCNF learn module.
For GATE-depth DBMS across the whole syllabus, GATE Guidance by Sanchit Sir sequences normalization with transactions and indexing.
The natural next topic is transactions and concurrency control, which is where a well-normalised schema gets read and written safely.
Learn the four rules exactly, compute candidate keys before you judge a normal form, and hand-decompose one relation from a wide table down to BCNF. Do that once, and normalization stops being vocabulary and becomes marks you can count on.
Ready to test yourself? Work through our solved DBMS normalization MCQs with explanations, each answered in a couple of lines, to see exactly how these ideas are examined.