Re: Functional Dependencies > Uniqueness Constraints
Date: Wed, 30 Aug 2006 19:06:32 GMT
Message-ID: <YklJg.496784$IK3.214390_at_pd7tw1no>
Bob Badour wrote:
> paul c wrote:
>
>> Marshall wrote: >> >>> ... (And of course there must be a rule that >>> says every base table must have at least one functional >>> dependency in which the union of the determinant set >>> and the dependent set equals the set of attributes. (This >>> restriction is sufficient to ensure every base table is a >>> relation; is it necessary?)) >>> ... >> >> I would say not necessary. If a table is a representation of a >> relation, then I`d think that even if no rule is stated, by definition >> the union of the attributes is a CK, eg., if there is no stated >> determinant set, all the attributes are in the dependent set. I can`t >> think why one would want to state this, shouldn`t a dbms assume itÉ
>
> I think you have determinant and dependent reversed. The attributes of a
> candidate key are the determinant set, and the remaining attributes are
> each dependent attributes. Thus, if no other key is specified, all
> attributes are in the determinant set and the set of dependent
> attributes is empty.
>
> What Marshall stated is an invariant of every relation for every
> candidate key. In fact, it seems to me Marshall's statement is just a
> restatement of candidate keys, but there could be subtleties I miss.
Right, I did reverse them, in the course of trying to use Marshall's lingo. Still if the dependent set stood for an RVA, maybe the reversal would be true in a sort-of way.
Invariant might be the better word to start with trying to describe CK's, less confusion that way - eg., CK's are not of the same ilk as IND's at least in the sense that (I think) a conventional relational algebra (project and join) can express IND's, but not CK's, eg. I think if an IND "A join B = B" is true, the complements of both sides of the equality are also equal, but that's not the case for CK's.
(For vague and undoubtedly stupid and naive reasons that I can't explain very well, it's long bothered me that something might be missing when the usual algebras can't directly express invariants of the FD sort that are needed so pervasively in practice (ie. to enable certain inferences). I imagine a completely different underpinning, eg., different definition of headers and projection is needed to avoid introducing "unique" to a "kernel language", to put words in Marshall's mouth, although I can't demonstrate that. Perhaps it would be enough to recognize D&D-style GROUP and UNGROUP in the "kernel language", but that would seem to also need an unconventional notion of normal form that I also can't demonstrate at the moment.)
p Received on Wed Aug 30 2006 - 21:06:32 CEST