Som du kanske redan vet använder databaser tabeller för att organisera information. (Om du inte har grundläggande kunskap om databaskoncept, läs Vad är en databas?) Varje tabell består av ett antal rader, som var och en motsvarar en enda databaspost. Så, hur håller databaser alla dessa poster raka? Det är genom att använda nycklar.
Primärtangenter
Den första typen av nyckel som vi kommer att diskutera är den primära nyckeln. Varje databastabell ska ha en eller flera kolumner som betecknas som primärnyckel. Värdet som denna nyckel innehåller bör vara unik för varje post i databasen.
Anta exempelvis att vi har ett bord som heter Medarbetare som innehåller personuppgifter för varje anställd i vårt firma. Vi skulle behöva välja en lämplig primär nyckel som skulle identifiera varje anställd unikt. Din första tanke kan vara att använda medarbetarens namn. Det skulle inte fungera bra eftersom det är tänkbart att du skulle anställa två anställda med samma namn. Ett bättre val kan vara att använda ett unikt ID-nummer för anställda som du tilldelar varje anställd när de anställs. Vissa organisationer väljer att använda sociala säkerhetsnummer (eller liknande statsidentifierare) för den här uppgiften eftersom varje anställd redan har en och de är garanterade att vara unika. Användningen av Social Security Numbers för detta ändamål är emellertid mycket kontroversiell på grund av integritetshänsyn. (Om du arbetar för en statlig organisation, kan användningen av ett personnummer även vara olagligt enligt lagen om sekretess från 1974.) Därför har de flesta organisationer skiftat till användningen av unika identifierare (anställd ID, student ID, etc .) som inte delar dessa personuppgifter.
När du väl bestämmer dig för en primär nyckel och skapar databasen, kommer databashanteringssystemet att tillämpa uniktheten hos nyckeln. Om du försöker lägga in en post i en tabell med en primär nyckel som duplicerar en befintlig post, kommer insatsen att misslyckas.
De flesta databaser kan också generera sina egna primära nycklar. Microsoft Access kan till exempel konfigureras för att använda datatypen AutoNumber för att tilldela ett unikt ID till varje post i tabellen. Medan det är effektivt är detta en dålig designpraxis eftersom det lämnar dig med meningslöst värde i varje rekord i tabellen. Varför inte använda det där utrymme för att lagra något som är användbart?
Utländska nycklar
Den andra typen är den främmande nyckeln, som används för att skapa relationer mellan tabeller. Naturliga relationer finns mellan tabeller i de flesta databasstrukturer. Återgå till vår anställdas databas, föreställ dig att vi ville lägga till en tabell som innehåller avdelningsinformation till databasen. Denna nya tabell kan kallas avdelningar och skulle innehålla en stor mängd information om avdelningen som helhet. Vi skulle också vilja inkludera information om anställda i avdelningen, men det skulle vara överflödigt att ha samma information i två tabeller (anställda och avdelningar). Istället kan vi skapa ett förhållande mellan de två tabellerna.
Låt oss anta att avdelnings tabellen använder kolumnavdelningen som primär nyckel. För att skapa ett förhållande mellan de två tabellerna lägger vi till en ny kolumn i anställningsbordet som heter Institutionen. Vi fyller i namnet på den avdelning som varje anställd tillhör. Vi informerar också databasstyrningssystemet om att avdelningskolonnen i Medarbetarbordet är en främmande nyckel som refererar till avdelnings tabellen. Databasen kommer då att tillämpa referensintegritet genom att se till att alla värden i kolumnen Avdelningar i Medarbetar-tabellen har motsvarande poster i avdelnings tabellen.
Observera att det inte finns någon unik begränsning för en utländsk nyckel. Vi kan (och sannolikt) göra mer än en anställd som tillhör en enskild avdelning. På samma sätt finns det inget krav på att en post i avdelnings tabellen har någon motsvarande post i Medarbetar tabellen. Det är möjligt att vi skulle ha en avdelning utan anställda.
För mer om detta ämne, läs Skapa externa nycklar.
