Functional Dependencies & Determinants

The constraint that drives normalization

Normalization is built on functional dependencies. A functional dependency is a constraint between two attributes written A → B, read 'A determines B': for every value of A there is exactly one associated value of B. Crucially, an FD is not a computation — B is not calculated from A; it is uniquely associated with it. And FDs come from business rules, never from sample data — sample data can only disprove a candidate FD, never prove one.

Classic FDs:

SSN -> Name            (one SSN identifies one person's name)
VIN -> Make, Model, Color   (one vehicle ID fixes its make, model, colour)
StudentID -> Major, AdvisorID

Determinants and candidate keys

The attribute on the left of the arrow is the determinant. So in StudentID → Major, StudentID is the determinant.

The relationship the exam loves to test:

> Every candidate key is a determinant, but not every determinant is a candidate key.

A candidate key is a determinant that uniquely identifies every other attribute in the relation and is nonredundant. A plain determinant might only fix some attributes, or might be part of a larger key. Producing a normalized relation means every determinant is a candidate key (the primary key, in fact).

Worked example: reading FDs off a table

Given STUDENT(StudentID, Major, AdvisorID, AdvisorName, AdvisorPhone) and the business rules 'each student has one major and one advisor' and 'each advisor has one name and phone':

FD1:  StudentID -> Major, AdvisorID
FD2:  AdvisorID -> AdvisorName, AdvisorPhone

• StudentID is a determinant and a candidate key — it fixes every other attribute (directly or via FD2).
• AdvisorID is a determinant (it fixes AdvisorName, AdvisorPhone) but not a candidate key — knowing the advisor does not identify the student row.

That second FD — a determinant that is not the key — is exactly the seed of a transitive dependency, which the next two lessons remove.