Re: Functional Dependencies > Uniqueness Constraints
From: J M Davitt <jdavitt_at_aeneas.net>
Date: Wed, 06 Sep 2006 02:35:38 GMT
Message-ID: <_tqLg.82$MD6.54_at_tornado.ohiordc.rr.com>
>>Good topic!
>>
>>Marshall wrote:
>>
>>>Geeze, it's deader than a dotcom startup in here.
>>>
>>>Okay, fine. I propose that a good relational DBMS should
>>>not have any special feature for enforcing uniqueness constraints.
>>>Instead, it should be able to record and enforce functional
>>>dependencies. (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?))
>>>
>>>Why? Because uniqueness constraints by themselves
>>>don't capture enough meaning.
>>>
>>>Example:
>>>
>>>Relation R1(a,b) with FD {a} -> {b}
>>>Relation R2(c,d) with FD {c} -> {d}
>>>
>>>Derived relation J = R1 join R2
>>>(this join is a cross product)
>>>
>>>FDs in J:
>>>{a} -> {b}
>>>{c} -> {d}
>>>
>>>What if we had just recorded uniqueness constraints in R1
>>>and R2 (on a and c respectively?) We can't express anything
>>>derived from those uniqueness constraints in J, at least not
>>>as uniqueness constaints anyway.
>>
>>Why not? Won't the candidate key in the derived relation consist of all
>>the candidate key attributes in the "source" relations? For J, wouldn't
>>it be {a, c}?
>>As for the P?=NP discussion earlier, I'm fairly ignorant, but in the
>>specific case of a cartesian join with no overlapping attributes, isn't
>>the only derivable CK just the union of the attributes of the CKs of
>>the various "source" relations?
Date: Wed, 06 Sep 2006 02:35:38 GMT
Message-ID: <_tqLg.82$MD6.54_at_tornado.ohiordc.rr.com>
Marshall wrote:
> erk wrote: >
>>Good topic!
>>
>>Marshall wrote:
>>
>>>Geeze, it's deader than a dotcom startup in here.
>>>
>>>Okay, fine. I propose that a good relational DBMS should
>>>not have any special feature for enforcing uniqueness constraints.
>>>Instead, it should be able to record and enforce functional
>>>dependencies. (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?))
>>>
>>>Why? Because uniqueness constraints by themselves
>>>don't capture enough meaning.
>>>
>>>Example:
>>>
>>>Relation R1(a,b) with FD {a} -> {b}
>>>Relation R2(c,d) with FD {c} -> {d}
>>>
>>>Derived relation J = R1 join R2
>>>(this join is a cross product)
>>>
>>>FDs in J:
>>>{a} -> {b}
>>>{c} -> {d}
>>>
>>>What if we had just recorded uniqueness constraints in R1
>>>and R2 (on a and c respectively?) We can't express anything
>>>derived from those uniqueness constraints in J, at least not
>>>as uniqueness constaints anyway.
>>
>>Why not? Won't the candidate key in the derived relation consist of all
>>the candidate key attributes in the "source" relations? For J, wouldn't
>>it be {a, c}?
>
>
> Well, uh, yes, that's right. But just knowing that {a, c} is unique
> isn't knowing the whole story, because we've "forgotten" that
> {a} -> {b} and {c} -> {d}. The system only records that
> {a, c} is unique, which is to say {a, c} -> {b, d}. Hence my
> original contention that uniqueness constraints don't capture
> enough meaning.
Heads up: there are more than two models for databases. (Sounds strange, doesn't it?)
In the peculiar -- maybe peculiar is too... something -- world of knowledge databases, functional dependencies are recorded by the system. IOW, the database needn't rely upon a "data architect" or "data modeler" to declare some sort of constraint that "enforces" or "ensures" that functional dependencies are... what? Observed?
No, instead, you just tell it '{a} -> {b}' or '{a} ->> {c}' and be done with it.
(No support for INDs, though.)
>>In any event, even if we "just" specified uniqueness constraints on
>>R1{a} and R2{c}, doesn't that imply the FDs you give above?
> > > Yes for R1 and R2, but no for J. > > >
>>As for the P?=NP discussion earlier, I'm fairly ignorant, but in the
>>specific case of a cartesian join with no overlapping attributes, isn't
>>the only derivable CK just the union of the attributes of the CKs of
>>the various "source" relations?
> > > I think that's right. > > > Marshall >Received on Wed Sep 06 2006 - 04:35:38 CEST