Functional Dependency

Definition

A functional dependency (FD) X -> Y means: for any two rows in a valid instance of the relation, if they agree on X, they must also agree on Y. In other words, knowing the value of X always tells you the exact value of Y — X determines Y. X is called the determinant.

This is a statement about the business rule/schema, holding for every possible valid state of the data — not a coincidence that happens to be true in today's snapshot.

The FDs in the Running Example

Look again at StudentCourse(StudentID, StudentName, CourseID, CourseName, InstructorID, InstructorName, InstructorOffice, EnrollmentDate) with the sample rows (S1 Asha, S2 Ravi, S3 Kiran; C1 Database Systems/I1 Dr. Rao/Room 204; C2 Operating Systems/I2 Dr. Mehta/Room 310; C3 Computer Networks/I3 Dr. Singh/Room 118).

The genuine functional dependencies that hold here are:

1. StudentID -> StudentName — every StudentID always maps to exactly one name (S1 always means Asha).
2. CourseID -> CourseName — C1 always means Database Systems.
3. CourseID -> InstructorID — C1 is always taught by I1 (one instructor of record per course, in this simplified model).
4. InstructorID -> InstructorName — I1 always means Dr. Rao.
5. InstructorID -> InstructorOffice — I1 always means Room 204.
6. {StudentID, CourseID} -> EnrollmentDate — the date a specific student enrolled in a specific course (this needs the whole pair; see 21.6).

Notice what is not a functional dependency: StudentName -> StudentID does not hold, even if every name in today's data happens to be unique — two different students could both be named "Asha" tomorrow. An FD must hold for every valid instance, not just be an accident of the current rows.

Trivial vs. Non-Trivial

X -> Y is trivial if Y is a subset of X (e.g., {StudentID, CourseID} -> StudentID is trivially always true and tells you nothing new). All six FDs listed above are non-trivial — Y is not contained in X — which is why they carry real informational content and are the ones worth reasoning about.

Edge Cases

• FDs are declared by understanding the real-world business rule, not discovered purely by eyeballing sample data — three sample rows can never prove an FD holds in general (they can only disprove one, by showing a counter-example).
• A composite determinant like {StudentID, CourseID} is still just "X" in the X -> Y notation — the FD concept doesn't care how many attributes are on the left, only that agreement on all of them forces agreement on Y.
• If CourseID -> InstructorID didn't hold — e.g., a course could be co-taught and its "instructor" varied by section — you would need a different, more granular key design; the FD is only valid because of the (simplified) business rule "one instructor of record per course."

Key Takeaways / Interview Angle

• Q: What's the difference between a functional dependency and just noticing repeated values? Repeated values are a symptom (see 21.1). A functional dependency is the underlying rule that determines when values must repeat — normalization theory is built entirely on reasoning about these rules, not the specific data.
• Q: Give an FD from the running example and say why it holds. InstructorID -> InstructorOffice holds because, by policy, each instructor has exactly one assigned office — knowing I1 always tells you Room 204.
• Q: Why does it matter that FDs must hold for ALL valid instances, not just current data? Because schema design decisions (keys, normal forms) must be correct forever, not just for today's rows — a coincidental uniqueness in three sample rows is not a foundation for a database constraint.