# Re: Functional Dependencies > Uniqueness Constraints

Date: 1 Sep 2006 08:37:02 -0700

Message-ID: <1157125022.765575.225170_at_i3g2000cwc.googlegroups.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}?

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?

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 have the feeling I'm missing something big here, but will prepare to be embarassed.

*> And if that doesn't get you talking, maybe the Angry Cat will.
*

*> ph3ar the Angry Cat!
**>
**> http://video.google.com/videoplay?docid=4479228649911767872
*

- erk