Som du kanskje allerede vet, bruker databaser tabeller for å organisere informasjon. (Hvis du ikke har en grunnleggende kjennskap til databasekonseptene, les Hva er en database?) Hver tabell består av en rekke rader, som hver tilsvarer en enkelt databasepost. Så, hvordan lagrer databaser alle disse postene rett? Det er gjennom bruk av nøkler.
Primærnøkler
Den første typen nøkkel vi skal diskutere er den primære nøkkelen. Hver database tabell skal ha en eller flere kolonner utpekt som primærnøkkel. Verdien denne nøkkelen inneholder, bør være unik for hver post i databasen.
For eksempel, anta at vi har et bord kalt Ansatte som inneholder personopplysninger for hver ansatt i firmaet vårt. Vi må velge en passende primærnøkkel som unikt identifiserer hver ansatt. Din første tanke kan være å bruke ansattes navn. Dette ville ikke fungere veldig bra fordi det er tenkelig at du skulle ansette to ansatte med samme navn. Et bedre valg kan være å bruke et unikt ansattes ID-nummer som du tilordner hver ansatt når de ansettes. Noen organisasjoner velger å bruke personnummer (eller lignende offentlige identifikatorer) for denne oppgaven fordi hver ansatt allerede har en og de er garantert å være unike. Imidlertid er bruken av personnummer for dette formål svært kontroversielt på grunn av personvernet. (Hvis du jobber for en offentlig organisasjon, kan bruk av et personnummer også være ulovlig i henhold til personvernloven fra 1974.) Derfor har de fleste organisasjoner flyttet til bruk av unike identifikatorer (ansattes ID, student ID osv. .) som ikke deler disse personvernproblemene.
Når du bestemmer deg for en primærnøkkel og oppretter databasen, vil databasebehandlingssystemet håndheve uniktheten til nøkkelen. Hvis du prøver å sette inn en plate i et bord med en primærnøkkel som dupliserer en eksisterende plate, vil innsatsen mislykkes.
De fleste databaser er også i stand til å generere sine egne primære nøkler. Microsoft Access, for eksempel, kan konfigureres for å bruke datatypen AutoNumber til å tildele en unik ID til hver oppføring i tabellen. Selv om det er effektivt, er dette en dårlig designpraksis fordi den gir deg en meningsløs verdi i hver post i bordet. Hvorfor ikke bruke det rommet til å lagre noe som er nyttig?
Utenlandske nøkler
Den andre typen er den utenlandske nøkkelen, som brukes til å opprette relasjoner mellom tabeller. Naturlige relasjoner eksisterer mellom tabeller i de fleste databasestrukturer. Gå tilbake til vår Ansattes database, forestill deg at vi ønsket å legge til et bord med avdelingsinformasjon til databasen. Dette nye tabellen kan kalles Avdelinger og vil inneholde mye informasjon om avdelingen som helhet. Vi vil også inkludere informasjon om de ansatte i avdelingen, men det ville være overflødig å ha samme informasjon i to tabeller (Ansatte og avdelinger). I stedet kan vi opprette et forhold mellom de to tabellene.
La oss anta at avdelingsbordet bruker kolonnen Avdelingens navn som primærnøkkel. For å opprette et forhold mellom de to tabellene legger vi til en ny kolonne i Medarbeiderbordet, kalt Avdeling. Vi fyller deretter inn navnet på avdelingen som hver ansatt tilhører. Vi informerer også databasebehandlingssystemet om at avdelingskolonnen i tabellene Ansatte er en utenlandsk nøkkel som refererer til avdelingstabellen. Databasen vil da håndheve referanseintegritet ved å sørge for at alle verdiene i kolonnen Avdelinger i Medarbeider-tabellen har tilsvarende oppføringer i Avdelingstabellen.
Vær oppmerksom på at det ikke er noe unikt begrensning for en fremmednøkkel. Vi kan (og sannsynligvis gjøre) ha mer enn en ansatt som tilhører en enkelt avdeling. På samme måte er det ikke krav om at en oppføring i avdelingstabellen har en tilsvarende oppføring i tabellene Ansatte. Det er mulig at vi har en avdeling uten ansatte.
For mer om dette emnet, les Opprett utenlandske nøkler.
