See on nagu organisatsioonile juhi valimised. Oletame, et on kolm kandidaati. Üks valitakse peadirektoriks. Tema saab ametiauto ja eraldi kabineti. Ülejäänud kaks ei saa peadirektoriks, kuid saavad asedirektori tiitli ning samuti ametiauto ja eraldi kabineti.

Igas tabelis on üks või rohkem kandidaatvõtit e võtmekandidaati (candidate key). Üks nendest kuulutatakse primaarseks e esmaseks võtmeks e primaarvõtmeks. Ülejäänud on alternatiivsed võtmed e alternatiivvõtmed.

Primaarvõti deklareeritakse kasutades PRIMARY KEY kitsendust.

Alternatiivvõtmed deklareeritakse, kasutades UNIQUE + NOT NULL kitsendusi.

Näiteks oletame, et tabelis Amet on kaks kandidaatvõtit: (amet_kood) ja (nimetus)

(amet_kood) valitakse primaarseks.
Tabeli loomise lauses: CONSTRAINT pk_amet_kood PRIMARY KEY (amet_kood)

(nimetus) jääb alternatiivseks.
Tabeli loomise lauses: CONSTRAINT ak_amet_nimetus UNIQUE(nimetus)
Lisaks on veerul nimetus NOT NULL kitsendus.

Miks NOT NULL kitsendus? Primaarvõtme veerud on automaatselt kohustuslikud - primaarvõtme väärtus ei tohi üheski reas puududa. Kuna võti on võti, siis pole alternatiivvõtmed halvemad ja ka nende väärtus ei tohiks üheski tabeli reas puududa.

Seos teiste tabelitega luuakse tavaliselt primaarvõtme alusel - selleks, et tabelis Töötaja registreerida töötaja hetke amet, registreeritakse seal ameti kood, mitte ameti nimetus.