Leftover functional dependencies after Boyce Codd decomposition?

Question

This decomposition example was given in class, however the solution is confusing as it seems to leave some FD's unaddressed. Please confirm 3) below is in BCNF, or cannot be put into BCNF?

Let R be a relation schema, with schema(R) = {C,T,H,R,S,G}

set of FDs F over R :
C->T
HR->C
HT->R
CS->G
HS->R

Decomposition:

1) C T H R S G
2) C T      C H R S G
3) C T      H R C       H R S G 
end. (Not further decomposed.)

In 3) HRSG contains attributes R and G without appearing to satisfy ht->r or cs->g.

ht->r is discounted because we don't have t in HRSG cs->g is discounted because we don't have c in HRSG

Is there a rule that if the LHS of a functional dependency contains attributes not in the relation, the FD doesn't apply? Thanks

Answer 1

The FD still applies to the overall db design.

Every FD is always the expression of some business rule. All stated business rules always apply, regardless of whether they are to be enforced on a 1-table version of the database schema, or on a decomposed version thereof. However, expressing them as an FD requires that all the attributes involved in the FD appear in the same relvar (because that's how they were invented : as a way of expressing a rule that applies to a relation schema (note that it does not say "database schema" here). The logical consequence is that FD's are simply incapable of expressing rules that "span" more than just one relation schema. The logical consequence of that is that it is no more than normal that "decomposing a relation schema" will/might lead some FD's becoming inexpressible (not "inapplicable") in the new version.

(1) FD's that are still expressible after decomposition / normalization to BCNF, can be "implemented" by declaring the LHS of the FD as a key to the relation schema.

(2) FD's that have become inexpressible in a decomposed schema, will have to be reinstated in the overall database design under the form of a database constraint. This "database constraint" is very similar to the key constraints corresponding to those FD's from (1), in that these database constraints are also a "key" of a sort, they are just not a key to a relation in the database schema, instead they are a key to a "virtual" relation (aka "view") that is definable in the database schema. This view is a projection (on exactly the attributes mentioned in either side of the FD) of the JOIN(s) (thus, the "recomposition from the decomposed parts") of the involved relation schemas.

That's a lot of words and maybe hard to follow, but the procedure is (for cs->g) : join back together the decomposed relation schemas (over HR, giving us a relation HRCSG back again), project down to the attributes involved in the FD (thus, project down to CSG), and in this relation, CS must be a key.

Note that I say "key" here in the sense that it cannot be allowed for the same CS value combination to appear with different G values. Not in the sense that this is a declaration that you could make to any DBMS to enforce such a rule. If DBMS's could effectively do this, database design would be a lot easier :-) Meaning the enforcement of the rule, and seeing to it that no data will ever violate this rule, is now up to you.

Fortunately, in practice these cases are not too numerous, and most of the time you will notice that the vast majority of the FD's in your original version, end up simply as keys declared on BCNF tables.