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.