A relation R(Student, Course, Instructor) has two FDs: {Student, Course} → Instructor and Instructor → Course. This schema is in 3NF but not BCNF. Why?
ABecause it has a transitive dependency between Student and Course through Instructor
BBecause Instructor → Course violates BCNF (Instructor is not a superkey), but 3NF permits it since Course is part of a candidate key
CBecause the primary key spans three attributes rather than one
DBecause Course appears on the right side of two different functional dependencies
BCNF requires that for every non-trivial FD X → Y, X must be a superkey. Here Instructor → Course violates BCNF because Instructor alone is not a superkey. However, 3NF's 'candidate key escape clause' permits this: the right-hand side, Course, is part of the candidate key {Student, Course}. 3NF allows the violation when Y is prime (part of some candidate key); BCNF does not. This is exactly the scenario — overlapping candidate keys — where 3NF and BCNF diverge.
Question 2 Multiple Choice
A designer finds that decomposing a schema to BCNF loses some functional dependencies as enforceable single-table constraints. What is the standard practical recommendation?
AAlways use BCNF; lost dependencies can be ignored since they are captured in the data redundancy
BUse 3NF synthesis instead — it guarantees both lossless-join decomposition and dependency preservation
CFall back to 2NF to avoid the decomposition problem
DUse BCNF and recreate lost dependencies using application-layer triggers
3NF synthesis (based on a minimal cover) guarantees two properties: lossless-join decomposition (original data can be reconstructed by joining) and dependency preservation (all FDs remain enforceable as single-table constraints). BCNF eliminates more FD-based redundancy but may require cross-table joins to enforce some constraints. The standard advice is: normalize to 3NF first, then evaluate whether remaining anomalies justify the added cost of BCNF. Dependency preservation matters for practical integrity enforcement.
Question 3 True / False
Every BCNF schema is automatically in 3NF.
TTrue
FFalse
Answer: True
BCNF is strictly stronger than 3NF, so any schema satisfying BCNF trivially satisfies 3NF. BCNF requires that every non-trivial FD X → Y has X as a superkey — no exceptions. 3NF relaxes this with the candidate key escape clause. Since BCNF has no escape clause, it rules out every schema that violates 3NF and more. The inclusion chain is BCNF ⊂ 3NF ⊂ 2NF ⊂ 1NF (where ⊂ means strictly stronger condition on schemas).
Question 4 True / False
BCNF decomposition generally preserves most functional dependencies as enforceable single-table constraints.
TTrue
FFalse
Answer: False
This is a critical practical limitation of BCNF. When a relation with overlapping candidate keys is decomposed to BCNF, some FDs may span multiple tables in the result — they can only be checked by joining tables, which is expensive. The example R(Student, Course, Instructor) with Instructor → Course: after BCNF decomposition, enforcing Instructor → Course requires a join. 3NF avoids this by preserving dependencies in individual tables. This trade-off is why 3NF is often preferred despite permitting some residual anomalies.
Question 5 Short Answer
Why does the distinction between 3NF and BCNF only arise when a relation has multiple overlapping candidate keys?
Think about your answer, then reveal below.
Model answer: The only difference is 3NF's candidate key escape clause: a non-trivial FD X → Y with X not a superkey is permitted if Y is part of some candidate key (Y is 'prime'). For this escape clause to activate, there must be a non-superkey X that determines a prime attribute Y. This requires Y to be part of one candidate key but not the universal superkey — which only happens when there are multiple candidate keys that overlap. With a single candidate key, every prime attribute is part of that one key, and any X that determines it would itself be a superkey. No multiple overlapping keys ⟹ no scenario where 3NF and BCNF differ.
Concretely: if a relation has candidate keys CK1 and CK2 that share some attributes, a non-superkey X could determine an attribute that is prime in CK1 but not in CK2. The 3NF escape clause lets this pass; BCNF does not. This is exactly the structure in the Student-Course-Instructor example: {Student, Course} and {Student, Instructor} are both candidate keys, and Instructor determines Course (prime in the first key).