Re: Functional Dependencies > Uniqueness Constraints

From: erk <>
Date: 1 Sep 2006 08:37:02 -0700
Message-ID: <>

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!

  • erk
Received on Fri Sep 01 2006 - 17:37:02 CEST

Original text of this message