By Piyush Wairale · GATE DA Educator & Course Instructor, IIT Madras BS Programme · Updated August 2026

Functional Dependencies: the Raw Material

X → Y means: whenever two tuples agree on X, they agree on Y — X determines Y. A dependency is trivial if Y ⊆ X (AB → A says nothing). Derivations use Armstrong’s axioms: reflexivity (Y ⊆ X ⇒ X → Y), augmentation (X → Y ⇒ XZ → YZ), transitivity (X → Y, Y → Z ⇒ X → Z) — a sound and complete set, which is itself an MCQ fact. Normalisation sits in the database section of the official GATE DA syllabus, right after the SQL & relational algebra material.

Attribute Closure, Computed Step by Step

Take R(A, B, C, D) with FDs A → B and B → C. Compute A⁺:

Start: A⁺ = {A}. Apply A → B (LHS ⊆ closure): add B → {A, B}. Apply B → C: add C → {A, B, C}. No FD adds D. A⁺ = {A, B, C} — A is not a key (D missing).

Now (AD)⁺: start {A, D}; A → B gives {A, B, D}; B → C gives {A, B, C, D} = all of R. And no proper subset works (A⁺ misses D, D⁺ = {D}). So AD is the candidate key. This loop-until-stable procedure answers every closure NAT in under a minute.

Finding Candidate Keys Fast

The shortcut GATE rewards: an attribute that never appears on the right-hand side of any FD can never be derived, so it must belong to every candidate key. In the example above, D (and A) appear on no RHS → both must be in every key → test (AD)⁺ first. Attributes appearing only on RHSs (here C) are never in any candidate key. Classify attributes this way before touching closures and most key-finding questions collapse to one or two checks. Attributes that belong to some candidate key are called prime — remember that word; 2NF and 3NF are defined with it.

1NF: Atomic Values Only

A relation is in 1NF when every cell holds a single atomic value — no lists, no repeating groups. A table storing phone = “98401, 99872” violates 1NF; fix it by one row per phone (or a separate Phone(rollno, phone) table). Relational theory assumes 1NF, so real exam questions start at 2NF — but “which of these tables is not even in 1NF?” appears as a soft opener.

2NF: No Partial Dependencies (Worked)

Take R(rollno, course, marks, sname) with FDs {rollno, course} → marks and rollno → sname. Candidate key: {rollno, course}. The FD rollno → sname hangs a non-prime attribute (sname) off part of the key — a partial dependency, so R is in 1NF but not 2NF. The symptom is redundancy: a student’s name repeats in every course row.

Decomposition: R1(rollno, sname) with key rollno, and R2(rollno, course, marks) with key {rollno, course}. Both are now in 2NF (in fact BCNF), the join on rollno reconstructs R losslessly, and each FD lives intact in one table.

3NF: No Transitive Dependencies (Worked)

Take R(rollno, dept, hod) with FDs rollno → dept and dept → hod. Key: rollno. There’s no partial dependency (the key is a single attribute — 2NF is automatic), but hod depends on the key through dept: rollno → dept → hod, a transitive dependency of a non-prime attribute. R is 2NF, not 3NF. Symptom: change a department’s HOD and you must update every student row.

Decomposition: R1(rollno, dept) and R2(dept, hod) — each FD now has its determinant as the key of its own table. Formal 3NF statement worth memorising: for every non-trivial X → A, either X is a superkey or A is prime. That italicised escape clause is exactly what BCNF removes.

BCNF: Every Determinant a Superkey (Worked)

The classic schema: R(student, subject, teacher) with FDs {student, subject} → teacher and teacher → subject (each teacher teaches exactly one subject).

Keys: {student, subject}⁺ = all → key. Also {student, teacher}⁺ = {student, teacher, subject} = all → a second candidate key. So every attribute is prime.

3NF check: teacher → subject has a non-superkey determinant, but subject is prime — the 3NF escape clause applies. R is in 3NF.

BCNF check: BCNF has no escape clause — every non-trivial determinant must be a superkey. teacher is not a superkey ⇒ R fails BCNF.

Decomposition: split on the violating FD: R1(teacher, subject) (key teacher) and R2(student, teacher) (key {student, teacher}). Both are BCNF and the join is lossless (shared attribute teacher is R1’s key). The price: the FD {student, subject} → teacher now spans both tables — it can’t be checked inside either one. BCNF here is not dependency-preserving, which is precisely why 3NF exists as the “safe harbour” normal form.

Lossless Join and Dependency Preservation

A decomposition of R into R1, R2 is lossless iff the common attributes form a superkey of at least one side — check it in one line. It is dependency-preserving if every FD can be verified without joining. The guarantees to memorise: 3NF: lossless + dependency-preserving always achievable. BCNF: lossless always, dependency preservation NOT guaranteed. That asymmetry is a perennial true/false question.

The Identification Checklist

Three GATE-Style Problems, Solved

Problem 1 (NAT). R(A, B, C, D, E) with FDs A → BC, CD → E, B → D. How many attributes are in A⁺?

Solution. Start {A}. A → BC: {A, B, C}. B → D: {A, B, C, D}. Now CD ⊆ closure, so CD → E fires: {A, B, C, D, E}. A⁺ has 5 attributes — A alone is a candidate key (this exact FD set appeared in a past GATE paper).

Problem 2 (MCQ). R(A, B, C) with FDs AB → C and C → B. Highest normal form?

Solution. Keys: (AB)⁺ = ABC → AB is a key; (AC)⁺ = ACB → AC is also a key. So A, B, C are all prime. 2NF: no non-prime attributes at all → trivially satisfied. 3NF: C → B has a non-superkey determinant, but B is prime → escape clause applies, 3NF holds. BCNF: C is not a superkey → fails. Answer: 3NF — the same structure as the student/subject/teacher example.

Problem 3 (MCQ). R(A, B, C, D) with FDs A → B, B → C, A → D, where A is the only candidate key. Highest normal form?

Solution. Single-attribute key → no partial dependencies → 2NF holds. But B → C is non-prime → non-prime, a transitive dependency → 3NF fails. Answer: 2NF. Decompose to R1(A, B, D), R2(B, C) to reach BCNF.

Common Mistakes to Avoid

Testing normal forms before finding ALL candidate keys. Prime attributes are defined by the full key set — missing the second key in Problem 2 makes you wrongly report 1NF or 2NF.

Forgetting the 3NF escape clause. X → A with prime A does NOT violate 3NF, only BCNF. This single clause separates the two forms.

Assuming BCNF decompositions preserve dependencies. Losslessness is guaranteed; dependency preservation is not (teacher–subject is the counterexample).

Calling any two-table split “lossless”. Check the rule: shared attributes must be a superkey of one side.

Declaring a partial dependency without a composite key. If the key is a single attribute, 2NF cannot be violated — jump straight to the 3NF test.

How GATE DA Asks Normalisation

Four recurring shapes: (1) NAT — size of an attribute closure, or number of candidate keys; (2) MCQ — highest normal form of R given FDs (the checklist table answers it mechanically); (3) MCQ — properties: Armstrong axioms, 3NF vs BCNF guarantees, lossless-join condition; (4) linked — normalise, then answer an SQL/algebra query on the decomposed tables. Work keys → primes → violations in that order every time, and the topic becomes two reliable marks — see the full DBMS & warehousing notes for the rest of the section.

FAQs: Normal Forms for GATE DA

Finish the database section strong: pair this with the SQL & relational algebra deep dive, review the complete DBMS notes, and track your coverage against the GATE DA 2027 syllabus. New problem-solving sessions drop regularly on my YouTube channel — subscribe so you don’t miss them.