How do you compute the functional dependencies for decomposition?

Question

Say R has the following attributes: {A,B,C,D,E} and has the following functional dependencies:

A -> BC
CD -> E
B -> D
E -> A

And there is a decomposition consisting of R1(A,B,C) and R2(A,D,E). How can I compute the functional dependencies of R1 and R2?

The actual question on the homework asks me if R1/R2 is in BCNF/3NF/neither but I already know how to do that part (see if the left hand side of the FD's are contained in the candidate keys).

Answer 1

The trick is to think of FD's as defining keys, not on your given schema, but on PROJECTIONS of it.

For example, in your starting schema {ABCDE}, the FD A -> BC says that A ( {A}, actually ) constitutes a key on this table, projected down to {ABC}. That is, the union of LHS and RHS of the FD, defines which projection, and the LHS defines the key on that projection.

Now turn to the decomposed version, in which you have two distinct tables (schemas) {ABC} and {ADE}.

Your first and last FD's are still expressible in those schemas. The first FD on the first schema/table and last on the latter.

But the remaining two have become inexpressible (inexpressible AS AN FD, that is) because of the decomposition. What this means, for the overall database design, is that you will have to declare/define/implement a database constraint that says and does exactly the same thing as the original FD. (The general recipe for doing this is as follows : reconstitute the original table by joining the decompositions together again, project that join down on the attributes mentioned, and enforce the key on that projection. Achieving this will not exactly be trivial for cases such as these course exercises.)

Deciding whether or not R1/R2 are in xNF, must now be done considering only those of the original FD's that are still expressible (a->BC).

I suppose you should arrive at the conclusion that R1 is in 3/BC NF, and R2 still isn't.

Examples such as these (and most course exercises are of this nature) actually illustrate how ridiculously overstressed the concept of normalization is in the field of database design. What matters is the overall picture that includes ALL the constraints that apply to the database.