Introduction
A relation that stores two independent facts in one row repeats one of them, and repetition causes anomalies. In STUDENT_DEPT(roll, name, dept, hod), the head of department is stored once per student: changing the head means updating many rows (update anomaly), a department with no student cannot record its head (insertion anomaly), and deleting the last student of a department loses its head (deletion anomaly).
After 1NF's atomic-domain condition, the 2NF, 3NF and BCNF conditions here are FD-based and progressively stronger, ruling out the corresponding redundancies. The definitions, a reliable test procedure, how to find the highest normal form of a relation from its FDs, and which decomposition reaches a target form are the standard facts.
Prerequisites
- Functional Dependencies, Closure and Canonical Cover: attribute closure, candidate keys and prime attributes.
Core concepts
Let have FD set . An FD is nontrivial if . An attribute is prime if it belongs to some candidate key.
| Normal form | Condition |
|---|---|
| 1NF | every attribute value is atomic (no sets, lists or nested relations) |
| 2NF | 1NF, and no non-prime attribute is functionally dependent on a proper subset of any candidate key (no partial dependency) |
| 3NF | for every nontrivial in : is a superkey or is prime |
| BCNF | for every nontrivial in : is a superkey |
Equivalent form of 3NF. is in 3NF iff no non-prime attribute is transitively dependent on a candidate key, that is, there is no chain key with not a superkey, non-prime, and (the last FD must be nontrivial).
Inclusions. BCNF 3NF 2NF 1NF, and each inclusion is strict.

How it works: finding the highest normal form
- Find all candidate keys and the prime attributes.
- BCNF: for every FD of the given (nontrivial part only), check that . If all pass, the relation is in BCNF.
- 3NF: for every FD of (split right sides) that failed step 2, check whether is prime. If every failure has a prime , the relation is in 3NF.
- 2NF: for every candidate key and every proper subset , check whether contains a non-prime attribute not in . If none does, the relation is in 2NF.
- Otherwise it is in 1NF (assuming atomic values).
Testing with instead of . For the relation itself, steps 2 and 3 may use the given : if some FD of violates BCNF or 3NF, some FD of does too. This shortcut is not valid for a sub-relation of a decomposition: there the FDs that hold are the projection of onto , which can contain FDs that appear in no member of . The next note shows an instance.
Algorithms and pseudocode
HIGHEST-NF(R, F)
K <- CANDIDATE-KEYS(R, F); P <- union of the keys // prime attributes
bcnf <- true; third <- true
for each X -> A in F with A not in X
if CLOSURE(X, F) != R then
bcnf <- false
if A not in P then third <- false
if bcnf then return "BCNF"
if third then return "3NF"
for each key k in K, for each proper subset S of k
if (CLOSURE(S, F) - S) contains an attribute not in P then return "1NF"
return "2NF"Cost is dominated by finding candidate keys, exponential in the worst case; each closure is polynomial.
Mathematical explanation
Why the inclusions hold. BCNF implies 3NF because its condition is the first disjunct of the 3NF condition. 3NF implies 2NF: a partial dependency with and non-prime is a nontrivial FD whose left side is not a superkey (a proper subset of a candidate key cannot be a superkey, by minimality) and whose right side is non-prime, so it violates 3NF.
Useful sufficient conditions. The singleton-key and two-attribute shortcuts below, including their repetitions in examples, traps and the summary, assume no nontrivial empty-determinant (constant) dependencies. Without that assumption, test the empty subset too using the general definitions.
- Assuming no nontrivial empty-determinant FDs, if every candidate key is a single attribute, the relation is in 2NF (a single attribute has no non-empty proper subset).
- If every attribute is prime, the relation is in 3NF (the second disjunct always holds).
- With no nontrivial empty-determinant FDs, every relation with exactly two attributes is in BCNF: any nontrivial FD is or , and then its left side determines both attributes.
Why 3NF exists alongside BCNF. Some relations have no BCNF decomposition that preserves all dependencies (the relation with , is the standard case), while a dependency-preserving, lossless 3NF decomposition always exists. 3NF is the compromise that tolerates a little redundancy to keep every FD checkable in one table.
Worked examples
| # | Relation and FDs | Candidate keys | Highest form | Reason |
|---|---|---|---|---|
| 1 | ; , | 1NF | is partial ( non-prime) | |
| 2 | ; , , | 2NF | single-attribute key; transitive | |
| 3 | ; , | 2NF | no partial FD; transitive | |
| 4 | ; , | , | 3NF | not a superkey but prime |
| 5 | ; , , | , , | 3NF | all attributes prime; breaks BCNF |
| 6 | ; , , , , | , , , , | 3NF | all prime; breaks BCNF |
| 7 | ; | BCNF | the only left side is a key |
Example 8: the anomaly relation. STUDENT_DEPT(roll, name, dept, hod) with roll name, dept and dept hod. Key: roll. Single-attribute key, so 2NF; dept hod has a non-superkey left side and non-prime right side, so not 3NF. Splitting into (roll, name, dept) and (dept, hod) gives two BCNF relations and removes all three anomalies.
Example 9: a partial dependency on a prime attribute is allowed in 2NF. In Example 4, has left side , a proper subset of key , but is prime, so it is not a 2NF violation (and the relation is even in 3NF).
Example 10: three overlapping keys. with , , .
- is on no right side, so it is in every key. .
- , , . So , , are keys, and every attribute is prime.
- 3NF holds because every right side is prime. BCNF fails: , so has a non-superkey left side.
- The three keys pairwise share : 3NF without BCNF happens only when candidate keys overlap.
Example 11: the chosen primary key hides a partial dependency. with , , .
- , so is a key. , and neither nor is , so is also a key. Candidate keys: , . Prime attributes: , , .
- : is a proper subset of the candidate key and is non-prime. That is a partial dependency, so the relation is not in 2NF; the highest form is 1NF.
- If only the primary key is examined, the relation looks like 2NF because has no proper subset. The 2NF test runs over every candidate key.
Important properties and observations
- Only non-prime attributes matter for 2NF and 3NF; BCNF ignores primality.
- Two-attribute relations are always in BCNF.
- A relation whose only key is all its attributes (no nontrivial FD) is in BCNF.
- Check all candidate keys, not only the primary key, when deciding primality and partial dependency.
- Test on for the whole relation; on the projection of for a sub-relation.
- Normal form is a property of the schema with its FDs, not of one instance.
Related material. Fourth normal form (4NF) uses multivalued dependencies : a relation is in 4NF if every nontrivial MVD has a superkey on the left. It removes redundancy that FDs cannot describe, such as an employee's independent sets of skills and languages stored in one table. 5NF uses join dependencies.
Common misconceptions.
- "3NF means no transitive dependency at all." Only no transitive dependency of a non-prime attribute.
- "If the primary key is a single attribute, the relation is in 3NF." Not even 2NF is guaranteed: 2NF needs every candidate key to be a single attribute (or no partial dependency on a composite one), as Example 11 shows. With no constant dependencies, every candidate key being a singleton guarantees 2NF, but not 3NF; otherwise test empty subsets too.
- "BCNF and 3NF differ only when there are composite keys." They differ when a non-superkey determines a prime attribute, which needs overlapping candidate keys.
GATE examination perspective
- Highest normal form. Keys first, then BCNF, 3NF, 2NF tests in that order.
- Prime attributes from overlapping keys. Relations where every attribute is prime are at least 3NF.
- Partial versus transitive dependency. Classify a given FD as the cause of a 2NF or 3NF violation.
- Which FD set makes the relation BCNF. Pick the option where every nontrivial FD has a superkey on its left side.
- Anomalies. Recognise which anomaly a given redundancy causes.
Summary
Sources
- A. Silberschatz, H. F. Korth, S. Sudarshan, Database System Concepts, 7th ed., McGraw-Hill, 2019 (2020 copyright), 7.1 Features of Good Relational Designs, 7.3 Normal Forms, 7.8 Atomic Domains and First Normal Form.
- R. Elmasri, S. B. Navathe, Fundamentals of Database Systems, 7th ed., Pearson, 14.1 Informal Design Guidelines for Relation Schemas; 14.3 Normal Forms Based on Primary Keys; 14.4 General Definitions of Second and Third Normal Forms; 14.5 Boyce-Codd Normal Form; 14.6 Multivalued Dependency and Fourth Normal Form.