Řekněme, že {Author, Title, Edition} jednoznačně identifikuje knihu, pak platí následující:
-
Je to superklíč -- jednoznačně identifikuje n-tici (řádek).
-
Je neredukovatelný – odstranění kteréhokoli sloupce z něj již neudělá klíč.
-
Je to kandidátský klíč -- neredukovatelný superklíč je kandidátský klíč.
Nyní uvažujme ID (celé číslo)
Dokážu odůvodnit, že Book klíč tabulky se zobrazí v několika dalších tabulkách jako cizí klíč a také v několika indexech. Takže to zabere docela dost místa – řekněme tři sloupce x 40 znaků (nebo cokoli jiného...) – v každé z těchto tabulek plus v odpovídajících indexech.
Aby byly tyto „ostatní“ tabulky a indexy menší, mohu do Book přidat jedinečný celočíselný sloupec tabulka, která má být použita jako klíč, na který se bude odkazovat jako na cizí klíč. Řekněte něco jako:
alter table Book add BookID integer not null identity;
S BookID Book je také (musí být) jedinečná tabulka má nyní dva kandidátní klíče.
Nyní mohu vybrat BookID jako primární klíč.
alter table Book add constraint pk_Book primary key (BookID);
Nicméně {Author,Title,Edition} musí zůstat klíčem (jedinečným), aby se zabránilo něco takového:
BookID Author Title Edition
-----------------------------------------------
1 C.J.Date Database Design 1
2 C.J.Date Database Design 1
Abych to shrnul, přidáním BookID -- a jeho výběr jako primární -- nezastavil {Author, Title, Edition} být klíčem (kandidáta). Stále musí mít své vlastní jedinečné omezení a obvykle odpovídající index.
Všimněte si také, že od návrhu bylo toto rozhodnutí učiněno na „fyzické úrovni“. Obecně, na logické úrovni návrhu, toto ID neexistuje -- byl zaveden při zvažování velikostí sloupců a indexů. Takže fyzické schéma bylo odvozeno od logického. V závislosti na velikosti databáze, RDBMS a použitém hardwaru nemusí mít žádné z těchto úvah o velikosti měřitelný účinek – takže pomocí {Author, Title, Edition} jako PK může být dokonale dobrý design - dokud se neprokáže jinak.