- When is BCNF not able to preserve functional dependencies?
Turns out this question is problematic in a certain way that "ok you defined 'prime number' but when is a number prime?" is, but "ok you defined 'simplest form of a fraction' but when is a fraction in simplest form?" isn't. Definition(s) say "when". But what you mean is something like, multiple conditions apply so what more simple/intuitive definition or non-brute-force algorithm characterizes this? But it has been shown that (informally) there is no non-exponential/non-exhaustive algorithm to enumerate BCNF decompositions that do/don't preserve FDs (functional dependencies).
- When is a 3NF decomposition desired instead of a BCNF decomposition [not] preserving functional dependencies?
If a 3NF design is not in BCNF then it preserves a FD that is not out of a superkey and so cannot be declaratively enforced in most SQL DBMSs. But the BCNF design, not having preserved the FD, needs a constraint enforced that is equivalent to two SQL FK (foreign key
) constraints to each other, which cannot be declaratively enforced in most SQL DBMSs. Since there's nothing special about cycles that prevents DBMSs from enforcing them and the two designs can represent each other, there isn't any reason per se why a DBMS couldn't support both.
There's a similar mental complexity for these two design forms--3NF plus FDs not out of CKs vs BCNF plus extra equality dependencies. But since the 3NF relation is the join of its BCNF components, the meaning of a 3NF tuple is the AND/conjunction of the meanings of the BCNF components. Since a user implicitly knows this and should be explicitly told it, and since constraints are not needed to query or modify a database (they're for integrity), the BCNF design is in some sense simpler. But if the user is always wanting to update both components then the 3NF design is in some sense simpler.
Thus, in case we are not able to get a dependency-preserving BCNF decomposition, it is generally preferable to opt for BCNF, since checking functional dependencies other than primary key constraints is difficult in SQL.
-- Database System Concepts 6th Edition (2011) by Silberschatz, Korth & Sudarshan
You can find an example facing this choice in most textbooks, and dozens are online in pdf. It must involve overlapping (composite) CKs (candidate keys).
The meaning of an SJT tuple (s,j,t)--simplified notation--is that student s is taught subject j by teacher t. The following constraints apply:
- For each subject, each student of that subject is taught by only one teacher
- Each teacher teaches only one subject (but each subject is taught by several teachers).
[...] From the first constraint, we have the FD {S,J} → T. From the second constraint, we have the FD T → J.
-- An Introduction to Database Systems 8th Edition (2004) by Date
(A 3NF design can suffer from further problems that could be eliminated by further decomposing the BCNF design to higher normal forms. This is why we should always decompose to 5NF then if desired explicitly denormalize. So any non-BCNF 3NF table should have come from such a denormalization.)