Re: functional dependencies

"Rohan Hathiwala" <rp_hathiwala_at_yahoo.com> wrote in message news:3ec1cded.0306152150.22547ef6_at_posting.google.com...
> Dear Marshall,
> I did not understand your example of trivial FD's. Please
> could you explain it more clearly and in tabular form if possible.

Yowsa, I thought I made it as clear as possible. Generally, I'm pretty good with examples if they're supposed to be "trivial." :-)

I'll make it even simpler.

Here's a table named "T". It has one column named Z typed integer. It has one row containing the value Z = 1. I'll draw a picture:

T:
|Z| (column names)

Okay, now we want a trivial functional dependency A -> B. A and B are sets of columns. In my trivial example, set A is the set containing exactly one column: column Z. A common way of expressing this is:

    A = {Z}

Set B is the set containing exactly one column: column Z.

    B = {Z}

Note that A and B happen to be the same set, but that is not a problem.

Here, A functionally determines B. Equivalently, B is functionally dependent on A. That is to say, given a value for the columns listed in set A, you can obtain exactly one value for each of the set of columns in B. So if I give you Z=1 as the value of the set of columns specified by A, you can uniquely identify Z=1 as being the value of the corresponding set of columns specified by B, which happens in this trivial case to be the same set of columns.

You *did* ask for trivial, right? Maybe I could have the same example, but not mention rows in any way; they're not really necessary.

In general, I find the border cases of such things interesting and informative. It's enlightening, and simultaneously amusing, to consider (for example) that every table must have at least one candidate key, and what that means about having a table with no columns, and how many rows such a table might have.

As a side bit of advice, I might suggest you de-emphasize your thinking about the concept of "primary key" since it not something that has any particular theoretical foundation; it is a thinking shortcut merely. All candidate keys have the same properties; to declare one of them "primary" is at best a syntactic convenience.

Marshall Received on Wed Jun 18 2003 - 07:43:10 CEST