Kapitel 5. Relationsdatabaser

Innehållsförteckning
Relationer
Schema och innehåll
Olika sorters nycklar
Kopplingar mellan relationer

Relationsmodellen är en av flera datamodeller, det vill säga sätt att organisera data. Relationsmodellen är den helt dominerande datamodell i dagens databashanterare och går, enkelt uttryckt, ut på att man lagrar data i tabeller.

Relationer

Relationsmodellen går ut på att data lagras som relationer. En relation är samma sak som en tabell med poster (rader) och namngivna fält (kolumner). Egentligen heter posterna tupler och fälten attribut, men vi behöver inte göra det svårare än så här.

Titta på tabell 5-1, som innehåller data om medlemmarna i en förening.

Varje post innehåller data om en medlem i föreningen och varje fält anger en viss egenskap som medlemen har.

Posterna i en tabell utgör en mängd. Det betyder att posterna inte har någon speciell ordning, utan kan skrivas i vilken ordning som helst. Det kan inte heller förekomma dubletter, det vill säga poster med samma data som en annan post i alla fält.

Ibland definerar man en eller flera nycklar. En nyckel är ett fält, eller en kombination av flera fält, vars värden är unika. Om man har en nyckel i en relation så kan det inte finnas flera poster med samma värde i det fältet. Nyckeln används därför för att skapa unikhet hos posterna. I tabell 5-1 skulle vi kunna sätta fältet Medlemsnummer som nyckel eftersom att vi vet att det bara finns en medlem med ett specifikt medlemsnummer. Fälten Namn och Telefonnummer kan vi inte använda som nycklar, eftersom vi vet att namn på personer inte är unika och flera medlemmar kan bo på samma adress och ha samma telefonnummer.

Relationen innehåller bara enkla och atomära värden. Att värdena är enkla betyder att vi inte kan ha mer än ett enda värde per fält. Om en medlem i tabell 5-1 har två olika telefonnummer kan vi inte ange båda i samma post. Vi måste använda två poster för att kunna lagra båda telefonnumren (eller skriva om vårt schema). Att värdena är atomära betyder att vi bara arbetar med hela datat och inte delar av det. Att relationen har enkla och atomära värden kallas första normalformen.

Det finns också något som kallas nullvärden. Om en person inte har någon telefon, eller om vi inte vet telefonnumret, kan vi ange värdet null i det fältet. Null är inte samma sak som noll (0). Om till exempel en temperaturangivelse satts till null betyder det att det inte finns någon temperatur och det är ju inte samma sak som en temperatur på noll (0) grader.

Schema och innehåll

I databassammanhang brukar man skilja på schemat, som beskriver vad som kan finnas i databasen, och det innehåll som finns i databasen.

Därför talar man om relationens schema och relationens innehåll. I schemat ingår bland annat vilka fält som relationen har, deras domäner (vilka värden de kan innehålla), och vilka nycklar som finns.

Olika sorters nycklar

Vi börjar med att kalla ett fält, eller en kombination av fält, vars värden garanterat är unika för en supernyckel. En supernyckel kan innehålla onödigt många fält. I relationen Medlem (tabell 5-1) finns det fyra supernycklar:

En kandidatnyckel är en minimal supernyckel, det vill säga en supernyckel där man inte kan ta bort några fält om den fortfarande skall vara garanterat unik. I relationen Medlem finns bara en kandidatnyckel, nämligen fältet Medlemsnummer (men en kandidatnyckel kan vara sammansatt av flera fält, om alla behövs för att den skall bli unik).

Det finns alltid minst en supernyckel och minst en kandidatnyckel i varje relation. Samtliga fält tillsammans utgör alltid en supernyckel, för det kan inte finnas två poster med samma värden i alla fält. Alltså är kombinationen av alla fälten garanterat unik - och därför en supernyckel. Kandidatnycklarna heter kandidatnycklar eftersom att det är bland dessa kandidater som vi väljer en primärnyckel. Vi väljer alltid en primärnyckel i varje relation och det är primärnyckeln som oftast används för att identifiera poster i tabellen.

De övriga kandidatnycklarna, som inte valdes som primärnyckel, kallas alternativnycklar eller sekundärnycklar.

Kopplingar mellan relationer

Låt oss nu utöka vår databas, som än så länge bara innehåller relationen Medlem (tabell 5-1), med ytterligare två relationer. Först skapar vi relationen Sektion (tabell 5-2) som innehåller data om olika sektioner inom föreningen.

Vi antar att Sektionskod är primärnyckel, med Namn som alternativnyckel.

Fältet Ledare är en främmande nyckel, även kallad referensattribut, till relationen Medlem. En främmande nyckel refererar alltid till primärnyckeln i en annan (eller samma) relation. Vi ser till exempel att ledaren för Programmeringsektionen är medlem nummer 3. Alltså går vi till relationen Medlem, letar rätt på medlem nummer 3 och ser att det är Lennart.

Om det står att medlem nummer 3 leder en sektion, så måste det också finnas en medlem nummer 3 i medlemstabellen. Detta villkor kallas referensintegritet.

Nu skapar vi relationen Deltar (tabell 5-3), som anger vilka medlemmar som deltar i vilka sektioner.

Medlem är främmande nyckel till relationen Medlem och Sektion är främmande nyckel till relationen Sektion. Medlem och Sektion utgör tillsammans den enda kandidatnyckeln och blir därför automatiskt primärnyckel.