Re: functional dependencies

From: Larry Coon <larry_at_assist.org>
Date: Thu, 12 Jun 2003 09:16:35 -0700
Message-ID: <3EE8A763.70DB_at_assist.org>


Rohan Hathiwala wrote:

> Dear Andre and Larry,
> Larry, let me quote a few lines from your recent posting.
>
> "Yes, the primary key, by definition functionally determines
> all non-key attributes in the tuple. The same is true for
> any candidate key, not just the primary key."
>
> That is precisely what I am having trouble with. As I see it
> both functional dependencies and primary keys are seperate
> integrity constraints.

I don't like the idea of calling a FD an integrity constraint. An integrity constraint is an implementation concept -- a way of enforcing some property you assert to always be true. A FD is a property that exists in the problem domain, and is not an implementation concept.

> So if in a FD say A -> B if we make A
> a primary key the whole thing degenerates to a primary key constraint
> and according to me it does not remain a FD anymore because by
> definition of FD we can have two tuples t1 and t2 with
> t1[A] = t2[A] but if A is primary key this will never happen.

I'd blame your definition of FDs. If it was something more like: "If there exists a tuple t1 in R with attributes A and B, and a functional dependency exists A-->B, then it is not possible for tuple t2 to exist in R where t1[A] = t2[A] and t1[B] != t2[B]" then it would get around your definition not accounting for the fact that you cannot have two distinct tuples t1 and t2 where t1[A] = t2[A] and A is a candidate key. This fact, while true, is not an essential property of a FD, so it only gets in the way with your definition. (Nor is my definition complete -- it just avoids the trap that your definition falls into.)

> To make it more clear I have trouble accepting that a primary
> key functionally determines all non-key attributes.

But that's the very property that makes the concept of a primary key useful, and the very reason you choose some combination of columns as a (candidate) key.

> I would like you to give me your opinion on the following.
>
> "Aren't primary key constraints stronger and take precedence over
> FD's."

No, they are two different things, as I talked about in my first paragraph above.

> As far as the trivial FD is concerned it was not a home work
> question I was just curious about tem. I am a B.E. in
> Computer Engineering from University of Mumbai (India) and at
> present I am working for a Software firm that deals with
> Voice XML. I joined this group because I like and I am very much
> interested in databases.

No problem. It just SOUNDED like a homework problem (it was worded like one and it was the kind of question that gets asked academically but not in the real world). As such, I was suspicious. And as I'm sure you know, it's considered bad form in the comp newsgroups to do students' homework for them.

Larry Coon
University of California
larry_at_assist.org
and lmcoon_at_home.com Received on Thu Jun 12 2003 - 18:16:35 CEST

Original text of this message