Som du måske allerede ved, bruger databaser tabeller til at organisere oplysninger. (Hvis du ikke har grundlæggende kendskab til databasekoncepter, skal du læse Hvad er en database?) Hver tabel består af en række rækker, der hver svarer til en enkelt databasepost. Så hvordan opbevarer databaser alle disse poster lige? Det er gennem brug af nøgler.
Primærnøgler
Den første type nøgle, vi vil diskutere, er den primære nøgle. Hver database tabel skal have en eller flere kolonner udpeget som den primære nøgle. Værdien af denne nøgle skal være unik for hver post i databasen.
Antag for eksempel, at vi har et bord kaldet Medarbejdere, der indeholder personoplysninger for hver medarbejder i vores firma. Vi skal vælge en passende primærnøgle, der identificerer hver medarbejder entydigt. Din første tanke kan være at bruge medarbejderens navn. Dette ville ikke fungere rigtig godt, fordi det er tænkeligt, at du ville ansætte to medarbejdere med samme navn. Et bedre valg kan være at bruge et unikt medarbejder ID nummer, som du tildeler hver medarbejder, når de ansættes. Nogle organisationer vælger at bruge Social Security Numbers (eller lignende statsidentifikatorer) til denne opgave, fordi hver medarbejder allerede har en, og de er garanteret at være unikke. Brug af Social Security Numbers til dette formål er imidlertid meget kontroversielt på grund af privatlivets fred. (Hvis du arbejder for en statslig organisation, kan brugen af et socialt sikkerhedsnummer endda være ulovligt i henhold til Privacy Act fra 1974.) Derfor har de fleste organisationer skiftet til brug af unikke identifikatorer (medarbejder ID, student ID osv. .), der ikke deler disse privatlivsproblemer.
Når du først har valgt en primær nøgle og opretter databasen, vil databasestyringssystemet håndhæve nøglenes unikke. Hvis du forsøger at indsætte en post i en tabel med en primærnøgle, der duplikerer en eksisterende post, vil indsætningen mislykkes.
De fleste databaser er også i stand til at generere deres egne primære nøgler. Microsoft Access kan for eksempel være konfigureret til at bruge datatypen AutoNumber til at tildele et unikt id til hver post i tabellen. Selvom det er effektivt, er dette en dårlig designpraksis, fordi den giver dig en meningsløs værdi i hver rekord i tabellen. Hvorfor ikke bruge det rum til at gemme noget nyttigt?
Udenlandske nøgler
Den anden type er den fremmede nøgle, som bruges til at oprette relationer mellem tabeller. Naturlige relationer eksisterer mellem tabeller i de fleste databasestrukturer. Gå tilbage til vores medarbejderdatabase, forestill dig, at vi ønskede at tilføje en tabel med afdelingsoplysninger til databasen. Denne nye tabel kan kaldes Afdelinger og vil indeholde en stor mængde oplysninger om afdelingen som helhed. Vi vil også gerne medtage oplysninger om medarbejderne i afdelingen, men det ville være overflødigt at have de samme oplysninger i to tabeller (medarbejdere og afdelinger). I stedet kan vi skabe et forhold mellem de to tabeller.
Lad os antage, at afdelings-tabellen bruger kolonnen Afdelingsnavn som primærnøgle. For at skabe et forhold mellem de to tabeller, tilføjer vi en ny kolonne til medarbejderbordet kaldet Department. Vi udfylder derefter navnet på den afdeling, som hver medarbejder tilhører. Vi informerer også databasestyringssystemet om, at afdelings-kolonnen i medarbejderbordet er en fremmednøgle, der refererer til afdelingsbordet. Databasen vil derefter håndhæve referentiel integritet ved at sikre, at alle værdierne i kolonnen Afdelinger i medarbejderbordet har tilsvarende poster i afdelingerne.
Bemærk, at der ikke er nogen unikke begrænsninger for en fremmed nøgle. Vi må (og højst sandsynligt) have mere end én medarbejder, der tilhører en enkelt afdeling. Tilsvarende er der ikke krav om, at en post i afdelingerne har en tilsvarende post i medarbejderbordet. Det er muligt, at vi har en afdeling uden ansatte.
For mere om dette emne, læs Opret udenlandske nøgler.
