Full Functional Dependency

Definition

An attribute Y is fully functionally dependent on a composite determinant X if Y depends on the entire X, but not on any proper subset of X. Formally: X -> Y holds, and for every proper subset X' of X, X' -> Y does not hold.

This concept only becomes interesting when the determinant is composite (more than one attribute) — it's about whether you truly need all of the columns in the key to pin down Y, or whether some of them are dead weight.

In the Running Example

The composite key of StudentCourse is {StudentID, CourseID}. Consider EnrollmentDate:

• Does StudentID alone determine EnrollmentDate? No — Asha (S1) has two different enrollment dates recorded conceptually depending on which course you mean (both happen to be 2026-01-10 here, but in general a student enrolls in different courses on different days). StudentID alone cannot tell you which course's enrollment date you're asking about.
• Does CourseID alone determine EnrollmentDate? No — for C1, S1 enrolled 2026-01-10, S2 enrolled 2026-01-11, and S3 enrolled 2026-01-12 — three different dates for the same course, so CourseID alone clearly doesn't fix the date.
• Does the full pair {StudentID, CourseID} determine EnrollmentDate? Yes — exactly one enrollment date exists for "Asha in Database Systems."

Since neither proper subset (StudentID alone, or CourseID alone) determines EnrollmentDate, but the full composite does, `{StudentID, CourseID} -> EnrollmentDate` is a full functional dependency.

Contrast with 21.7 (Partial Dependency)

This is the mirror image of the next topic. CourseName is determined by CourseID alone — a proper subset of the key — so {StudentID, CourseID} -> CourseName, while technically true, is not a full functional dependency; it's a partial one, because you didn't need StudentID at all to pin down CourseName. Full functional dependency is exactly the property that 2NF requires every non-key attribute to have.

Edge Cases

• Full functional dependency is only a meaningful question for composite keys. If the key were a single surrogate column (e.g., EnrollmentID), every non-key attribute is trivially "fully" dependent on it (there's no proper non-empty subset of a single-attribute key to compare against).
• Watch for accidental composite keys where one attribute is actually redundant for determining Y but is needed for uniqueness of the row itself (that's a normal, expected reason to keep both attributes in the key — full dependency is evaluated per non-key attribute, not for the key's own uniqueness requirement).

Key Takeaways / Interview Angle

• Q: What makes a dependency "full" rather than "partial"? Full dependency requires the entire composite key — dropping any single attribute from the key breaks the determination. Partial dependency means some proper subset of the key already determines the attribute.
• Q: Give a full functional dependency from the running example. {StudentID, CourseID} -> EnrollmentDate — you need both the specific student and the specific course to know the enrollment date.
• Q: Why does this matter for normalization? 2NF (21.13) is defined precisely as: every non-key attribute must be fully functionally dependent on the whole key. Attributes that are only partially dependent (like CourseName) get moved out into their own relation.