Sig det {Author, Title, Edition} identificerer en bog unikt, så gælder følgende:
-
Det er en supernøgle -- identificerer entydigt en tupel (række).
-
Det er irreducerbart -- fjernelse af nogen af kolonnerne gør det ikke længere til en nøgle.
-
Det er en kandidatnøgle -- en irreducerbar supernøgle er en kandidatnøgle.
Lad os nu overveje ID'et (heltal)
Jeg kan begrunde, at Book tabelnøgle vil dukke op i få andre tabeller som en fremmednøgle og også i få indekser. Så det vil tage en del plads -- f.eks tre kolonner x 40 tegn (eller hvad som helst...) -- i hver af disse tabeller plus i matchende indekser.
For at gøre disse "andre" tabeller og indekser mindre, kan jeg tilføje en unik-heltal-kolonne til Book tabel, der skal bruges som en nøgle, der vil blive refereret til som en fremmednøgle. Sig noget som:
alter table Book add BookID integer not null identity;
Med BookID er (skal også være) unik, Book tabellen har nu to kandidatnøgler.
Nu kan jeg vælge BookID som en primær nøgle.
alter table Book add constraint pk_Book primary key (BookID);
Men {Author,Title,Edition} skal forbliv en nøgle (unik) for at forhindre noget som dette:
BookID Author Title Edition
-----------------------------------------------
1 C.J.Date Database Design 1
2 C.J.Date Database Design 1
For at opsummere det, tilføje BookID -- og at vælge det som det primære -- stoppede ikke {Author, Title, Edition} være en (kandidat)nøgle. Det skal stadig have sin egen unikke begrænsning og normalt det matchende indeks.
Bemærk også, at fra designpunktet blev denne beslutning taget på det "fysiske plan". Generelt, på det logiske designniveau, er dette ID eksisterer ikke -- det blev introduceret under overvejelsen af kolonnestørrelser og indekser. Så det fysiske skema blev afledt af det logiske. Afhængigt af DB-størrelsen, RDBMS og den anvendte hardware, kan ingen af disse størrelsesbegrundelser have målbar effekt -- så brug {Author, Title, Edition} som en PK kan være et perfekt design -- indtil det er bevist anderledes.