Why is a functional dependency described as a “one-to-many” relationship?

Question

As far as I know, the definition of a functional dependency reads that, given the attributes X and Y, "each X value is associated with precisely one Y value". But then the author of the article that I read called this a "one-to-many" relationship. Isn't this really "one-to-one"..?

Answer 1

I think that the FD can't be described as "One-to-one" relationships. In One-to-one relationships, the X value identifies a Y value and vice-versa. In FD this doesn't happen. In fact, the Y values can be shared from different tuples with the same X value.

Think to a simple table with only cities, states and nations (And don't care about the redundancy). We know that the state identifies one and one nation, but a single nations doesn't identify a single state.

So, generally X implies Y but Y doesn't imply X.

A last observation: an one-to-one relationship need that the tables involved in the relationship must have the same number of rows, in order to associate to every a one b and to associate to every b one a. In the textbook you'll find a lot of FD in which this doesn't happen.

So we can describe a FD as an association of a Y value to many (only sometimes one) X values. So it's called an one-to-many relationship.

Answer 2

This example illustrates the concept of functional dependency. The situation modelled is that of college students visiting one or more lectures in each of which they are assigned a teaching assistant (TA). Let's further assume that every student is in some semester and is identified by a unique integer ID.

StudentID   Semester    Lecture             TA
1234        6           Numerical Methods   Azhar
1201        4           Numerical Methods   Peter
1234        6           Visual Computing    Ahmed
1201        4           Numerical Methods   Peter
1201        4           Physics II          Simone

We notice that whenever two rows in this table feature the same StudentID, they also necessarily have the same Semester values. This basic fact can be expressed by a functional dependency:

StudentID → Semester.

Other nontrivial functional dependencies can be identified, for example:

{StudentID, Lecture} → TA
{StudentID, Lecture} → {TA, Semester}

The latter expresses the fact that the set {StudentID, Lecture} is a superkey of the relation.