Re: Question on functional dependency

datapro01_at_yahoo.com (G.L.) wrote in message news:<dbe53197.0409211626.2f4a00bb_at_posting.google.com>...

> I am reading the following:
>
> In a functional dependency X --> Y the value of Y is *determined* by
> the X component and the value of X uniquely determines the value of Y.
>
> Then I read:
>
> It is NOT true to say:
> "Since X functionally determines Y, if we know X we know Y."
> or
> "If X identifies Y then X identifies Y."
> (University of Virginia slide)

I guess there must be some typo here. "If A then A" is one way of saying "A implies A" which is a tautology. Ergo the sentence "If X identifies Y then X identifies Y" is a vacuous statement.

> I'm not clear on how X can uniquely determine Y but not functionally
> determine or identify Y
>
> Semantics?

Exactly.

For example, in a relation on employees, usually the functional dependency (FD) Emp# --> Dept# holds. Notice though, that we assume that this is true because of the meaning that we assign to the attributes of the relation: in the real world an employee is assigned to at most one department.

The constraint given by Mikito Harakiri in an other post (translated here to D format):

"The FD X --> Y holds for relational variable (relvar) R if for all possible relation values r of R the following expression evaluates to the empty relation:

(r {X, Y} RENAME Y AS Y2) JOIN (r {X, Y}) WHERE Y != Y2"

is a formal way of *expressing* subjective (or context dependent, if you like) FD judgments. The trick here is that the constraint talks about 'all possible values of R' which is obviously an infinite set. Saying that the FD X --> Y is true for relvar R is just an other form of asserting that "an employee is assigned to at most one department" which might or might not be true in the given setting. (There is a tacit assumption in the formal definition of FD the reveals its connection to semantics: when we talk about 'all possible values of R' we mean, of course, only those values that are semantically meaningful in the application context and definitely not the Cartesian product of the domains of R.)

Now back to your specific question:

> I'm not clear on how X can uniquely determine Y but not functionally
> determine or identify Y.

Well, in the given example all we now is that "an employee belongs to at most one department". That *does not* mean that we can come up with a function that takes an employee and returns a department. This 'function' is implied by the facts of the world that we want to capture in the database. (If we knew this function in advance then we would not need to store the Dept# attribute in the Employee relvar since it would become a derived attribute.)

In other words: based on our knowledge of the meaning of attributes in the database we *know* that X *should* uniquely determine Y (which is equivalent to saying that X functionally determines Y). The only problem is that we *do not* know the function that gives us Y given X because that function is defined by the current arrangement of the outside world.

Regards,

Josh Hewitt Received on Thu Sep 23 2004 - 18:05:40 CEST