Questions: Boyce-Codd Normal Form and Higher Normal Forms

Question 1

Consider a relation Tutoring(Student, Subject, Instructor) where each instructor teaches only one subject (Instructor → Subject) and {Student, Subject} is the primary key. This relation is in 3NF. Why does it violate BCNF?

• A. Because Subject is transitively dependent on Student through Instructor
• B. Because Instructor determines Subject but Instructor is not a superkey
• C. Because {Student, Subject} is not the only candidate key in the relation
• D. Because partial dependencies exist between Student and Instructor

Answer: (B)

BCNF requires that for every non-trivial functional dependency X → Y, X must be a superkey. Here, Instructor → Subject is a non-trivial functional dependency, but Instructor alone is not a superkey (it doesn't uniquely identify a row). The relation is in 3NF because Subject is part of the candidate key — 3NF's exception for prime attributes lets this slide. BCNF has no such exception: any determinant must be a superkey, period. The redundancy is real: if an instructor teaches 50 students, the same subject is stored 50 times.

Question 2

A database designer is normalizing a schema and has a choice between stopping at 3NF or continuing to BCNF. What is the key tradeoff?

• A. BCNF schemas have more redundancy than 3NF schemas but are faster to query
• B. 3NF guarantees both lossless-join decomposition and dependency preservation; BCNF guarantees only lossless-join and may sacrifice dependency preservation
• C. BCNF decompositions always require more joins than 3NF, making them impractical for large databases
• D. 3NF is theoretically superior but harder to implement; BCNF is the practical standard

Answer: (B)

The critical BCNF tradeoff is dependency preservation. After a BCNF decomposition, a functional dependency that existed in the original relation may now span two tables — you can no longer enforce it with a single-table constraint, only with a join. 3NF always allows a decomposition that is both lossless-join AND dependency-preserving, which is why it is sometimes the pragmatic stopping point. BCNF eliminates more redundancy but at the cost of making certain business rules harder to enforce at the database level.

Question 3

Every BCNF relation is also in 3NF.

• T. True
• F. False

Answer: True

BCNF is strictly stronger than 3NF: its requirement (every determinant must be a superkey) is a stricter condition. Any relation satisfying BCNF necessarily satisfies all the requirements of 3NF. The inclusion goes one way: BCNF ⊆ 3NF (as sets of relations). This means achieving BCNF automatically achieves 3NF — but the converse is false, as the Tutoring relation example shows.

Question 4

If a relation is in 3NF, it is expected to also be in BCNF.

• T. True
• F. False

Answer: False

3NF relations are not necessarily in BCNF. The Tutoring(Student, Subject, Instructor) example demonstrates this: it is in 3NF because the only violation of 3NF's rule (Instructor → Subject) involves a prime attribute (Subject is part of a candidate key), and 3NF exempts this case. BCNF makes no such exception — Instructor is not a superkey, so the relation violates BCNF. 3NF is necessary but not sufficient for BCNF.

Question 5

Explain why BCNF might not always be the right normalization target, even though it eliminates more redundancy than 3NF.

Model answer: BCNF decompositions may lose the ability to enforce some functional dependencies within a single table. When a dependency spans two tables after decomposition, it can only be enforced with a join — which is more complex, potentially slower, and easy to inadvertently bypass. If that functional dependency represents an important business rule, the cost of losing single-table enforcement may outweigh the benefit of eliminating redundancy. 3NF guarantees both lossless-join decomposition and dependency preservation, making it the safer stopping point when dependency enforcement matters.

The broader principle is that normalization is a tool for reducing anomalies, not an end in itself. Over-normalizing can harm query performance, complicate application logic, and make constraints harder to enforce. Good database design requires judging whether the redundancy being eliminated is actually causing problems — update anomalies, insertion anomalies, deletion anomalies — and whether the decomposition required to eliminate it creates new problems worth accepting.