Primary Key

Every tuple in a relation must be distinguishable from every other — the relational model requires at least one attribute whose values are unique and never NULL, so that each row can be picked out with certainty. A relation may well have several attributes fit for this job (its candidate keys). The primary key is the one the database designer actually chooses, out of those candidates, to serve as the official unique identifier of the tuples in the relation.

Two obligations follow directly from the job description, and they are the defining constraints on a primary key:

• Uniqueness — no two tuples of the relation may ever carry the same primary key value. If a value repeated, the key would point at two rows at once and identify neither.
• No NULL values — a primary key value can never be NULL. A row whose identifier is unknown is a row that cannot be found, referred to, or reliably updated.

In the GUARDIAN relation, both GUID and GPhone always take unique values, so both are candidate keys. The designer selects one of them — say GUID — as the primary key of the relation. From that moment, GUID is the handle by which each guardian's tuple is identified.

The candidates that are not chosen do not stop being unique. They remain in the relation as alternate keys — attributes that could have served as the primary key but were passed over. If GUID is made the primary key of GUARDIAN, then GPhone becomes an alternate key.