Getting the same FDs you start with after BCNF decomposition?

Question

I did BCNF decomposition on a relation that has 5 functional dependencies and ended up with 5 relations. However, each new relation had the same attributes and FD as one of the original functional dependencies.

e.g. one functional dependency was AB -> C and one of the 5 relations I ended up with had attributes ABC with an AB -> C functional dependency. It was the same for the other four relations (same attributes and FD as one of the original FDs).

Does that mean I did the BCNF decomposition incorrectly?

I found this question Specific BCNF decomposition that describes a similar situation and supposedly it's correct.

Wouldn't that mean you don't have to follow the BCNF algorithm at all, and can just take the attributes from each FD and put it into a relation and then each relation will be in BCNF and thus the new schema made up by the new relations will be as well?

Answer 1

When given FDs hold, all the FDs implied by them by Armstrong's axioms also hold. We can't determine CKs (candidate keys) or NFs (normal forms) until we have a cover--a set of FDs that implies all the FDs that hold. But if we're only given some FDs that hold then in addition the FDs they imply there are in general further FDs that might or might not hold.

Sometimes all the original FDs that held hold when we join components of a decomposition back to the original. The original FDs that held don't need to all hold in the components for this; they just have to be implied by the FDs that hold in the components. This is when "FDs are preserved". If it is possible to decompose an original while preserving FDs then typically we prefer to use a decomposition that preserves FDs. (This is always possible for normalization to 3NF, and to the more stringent EKNF that the common "3NF" algorithms actually produce.) However, not every decomposition to BCNF preserves all FDs. And it is not always possible to preserve all FDs when decomposing to BCNF. The cases where it is not possible are all among those where CKs (candidate keys) overlap.

It's not clear what you mean by "just take the attributes from each FD and put it into a relation". But sometimes when we distribute the attributes of a FD among components no component has all of them, so the FD cannot hold in any component. If it isn't implied by the FDs that do have all their attributes in some component and so do hold in those components then it is not preserved. A BCNF algorithm is a BCNF algorithm because it handles all cases, and if you don't follow one then you aren't going to always get a BCNF decomposition. If you want to understand why such algorithms are designed the way they are then read an introduction to one. Eg Silberschatz, Korth & Sudarshan's Database System Concepts Chapter 7 Relational-Database Design, sections 7.6 Boyce–Codd Normal Form (7.6.2 Decomposition Algorithm and 7.6.3 Dependency Preservation) and 7.7 Third Normal Form. You can find the text and slides online.

7.6.3 Dependency Preservation

Not every BCNF decomposition is dependency preserving.

Recall that lossless join is an essential condition for a decomposition, to avoid loss of information. We are therefore forced to give up either BCNF or dependency preservation. In Section 7.7 we present an alternative normal form, called third normal form, which is a small relaxation of BCNF; the motivation for using third normal form is that there is always a dependency preserving decomposition into third normal form.

There are situations where there is more than one way to decompose a schema into BCNF. Some of these decompositions may be dependency preserving, while others may not.

In general, the database designer should therefore look at alternative decompositions, and pick a dependency preserving decomposition where possible.