3NF versus BCNF and the overlapping-key gap

WHAT THIS TESTS The interviewer probes whether you understand normalization at the level of functional dependencies and candidate keys, not just memorized form definitions.

A GOOD ANSWER COVERS BCNF states that for every non-trivial functional dependency X to Y, X must be a superkey. 3NF is slightly weaker: it permits a dependency where the dependent attribute is a prime attribute, meaning part of some candidate key, even if the determinant is not a superkey. A relation can therefore satisfy 3NF yet violate BCNF, and this happens specifically when the table has multiple overlapping composite candidate keys.

COMMON WRONG ANSWERS Asserting 3NF and BCNF are equivalent; they coincide often but not when candidate keys overlap. Confusing prime and non-prime attributes. Decomposing into BCNF without noting that BCNF decomposition can sometimes fail to preserve all functional dependencies, a real trade-off.

LIKELY FOLLOW-UPS What is a prime attribute? Why can BCNF decomposition lose dependency preservation while 3NF always preserves it? Is the trade-off worth it?

ONE CONCRETE EXAMPLE Consider a table (Student, Subject, Teacher) where each teacher teaches exactly one subject, and for each subject a student is assigned one teacher. Candidate keys are (Student, Subject) and (Student, Teacher), which overlap. The dependency Teacher to Subject holds, since a teacher determines their subject, but Teacher is not a superkey. Subject is a prime attribute, so the table stays in 3NF yet breaks BCNF. The anomaly: if the only row for a teacher is deleted, you lose the fact that the teacher teaches that subject, a deletion anomaly. Decomposing into (Teacher, Subject) and (Student, Teacher) removes it.