Partial Dependency

Definition

A partial dependency exists when a non-key attribute Y is functionally dependent on only part of a composite candidate key, rather than the whole key. It is the direct opposite of a full functional dependency (21.6).

In the Running Example

The candidate key of StudentCourse is {StudentID, CourseID}. Two non-key attributes exhibit partial dependency:

• `CourseName`: does CourseID alone determine it? Yes — C1 always means "Database Systems," regardless of which student is looking at it. So CourseID -> CourseName holds even without StudentID. Since CourseID is a proper subset of the full key, CourseName's dependency on {StudentID, CourseID} is partial — StudentID is irrelevant baggage.
• `StudentName`: symmetrically, StudentID alone determines it (StudentID -> StudentName). CourseID is irrelevant to knowing Asha's name.

Contrast with EnrollmentDate from 21.6: neither StudentID nor CourseID alone determines it — only the pair does — which is why EnrollmentDate is fully dependent, not partially.

Why Partial Dependency Is a Problem

Partial dependency is exactly what causes the redundancy from 21.1. Because CourseName only actually needs CourseID to be determined, but it's stored in a table keyed by the bigger {StudentID, CourseID}, "Database Systems" ends up physically repeated once per enrolled student (three times for C1's three students) instead of once per course. The same happens to StudentName, InstructorID, InstructorName, and InstructorOffice — every non-key column here is partially dependent on the key except EnrollmentDate.

The Fix (Preview of 21.13)

2NF eliminates partial dependency by relocating each partially-dependent attribute into a relation keyed by exactly the subset it truly depends on:

• CourseName (and the instructor chain) moves into Course(CourseID, CourseName, InstructorID, InstructorName, InstructorOffice).
• StudentName moves into Student(StudentID, StudentName).
• Only the genuinely fully-dependent EnrollmentDate stays with the composite key, in Enrollment(StudentID, CourseID, EnrollmentDate).

Edge Cases

• Partial dependency is only possible when the key is composite. A table with a single-attribute primary key (e.g., a surrogate EnrollmentID) cannot have partial dependencies by definition — there's no proper non-empty subset of a one-attribute key.
• Don't confuse "partial dependency" with "partial/incomplete data" (nulls) — it is purely a statement about which subset of the key functionally determines an attribute, unrelated to missing values.
• If a relation has multiple candidate keys, partial dependency must be checked against every candidate key, not just the one chosen as primary key.

Key Takeaways / Interview Angle

• Q: Define partial dependency in one line. A non-key attribute depends on only part of a composite key, not the whole thing.
• Q: Which normal form specifically targets and removes partial dependency? 2NF (21.13) — its entire definition is "1NF, plus no partial dependency."
• Q: Name a partially-dependent attribute in the running example and its true determinant. CourseName is partially dependent on {StudentID, CourseID} — its true, minimal determinant is CourseID alone.