5.1 Relasjonsdatabaser – repetisjon og fordypning

Å tegne virkeligheten som data

I IT 1 lærte du grunnleggende om databaser og SQL. Nå skal vi fordype oss i hvordan vi designer gode databaseløsninger fra bunnen av. En veldesignet database gjør det enklere å hente ut data, unngår duplikater og sikrer at informasjonen er konsistent. Det starter ikke med kode, men med en tegning.

ER-modellering (Entity-Relationship) er en metode for å visualisere datastrukturen før vi lager databasen. Vi identifiserer tre ting. Entiteter er objektene eller «tingene» i systemet – i et biblioteksystem er det Bok, Forfatter, Medlem og Utlån – og hver entitet blir en tabell. Attributter er egenskapene til entitetene; en Bok kan ha ISBN, tittel og utgivelsesår. Relasjoner er forbindelsene mellom entitetene, og de finnes i tre typer. En en-til-mange (1:N) er for eksempel at én forfatter skriver mange bøker. En mange-til-mange (M:N) er at én bok kan ha flere forfattere, og én forfatter flere bøker. En en-til-en (1:1) er sjelden, men finnes – som at én person har ett pass.

I selve ER-diagrammet tegner vi rektangler for entiteter, ovaler for attributter, romber for relasjoner, og linjer som binder alt sammen. Slik ser vi helheten før vi skriver en eneste linje SQL.

Normalformene rydder opp

En naiv databasestruktur fører fort til rot. Normalisering er prosessen med å organisere data for å minimere redundans, sikre dataintegritet og gjøre databasen lettere å oppdatere. Vi går gjennom tre nivåer.

Første normalform (1NF) krever at alle attributter har atomiske, udelelige verdier – ingen lister i ett felt. Hvis du lagrer to telefonnumre som «98765432, 91234567» i én celle, bryter du 1NF. Løsningen er en egen Telefon-tabell med ett nummer per rad. Andre normalform (2NF) krever 1NF pluss at alle ikke-nøkkelattributter er fullstendig avhengige av hele primærnøkkelen. I en Ordre-tabell med nøkkelen (ordreID, produktID), der produktnavn bare avhenger av produktID, brytes 2NF – produktnavnet bør flyttes til en egen Produkt-tabell. Tredje normalform (3NF) krever 2NF pluss at det ikke finnes transitive avhengigheter, altså at ikke-nøkkelattributter ikke avhenger av andre ikke-nøkkelattributter. En Ansatt-tabell med både avdelingID og avdelingsnavn bryter 3NF, fordi avdelingsnavnet egentlig hører til avdelingen, ikke til den ansatte. Løsningen er en egen Avdeling-tabell.

Felles for alle tre er målet: hver opplysning skal lagres ett sted. Da slipper vi anomalier – problemer ved innsetting, oppdatering og sletting som oppstår når samme data er duplisert mange steder.

Nøklene som binder det sammen

For å knytte tabellene sammen og holde dataene pålitelige, trenger vi nøkler. En primærnøkkel er en unik identifikator for hver rad. Den kan aldri være NULL og må være unik – som forfatterID i en Forfatter-tabell. En fremmednøkkel er et attributt som refererer til primærnøkkelen i en annen tabell, og det er nettopp dette som skaper relasjoner. En Bok-tabell kan ha en forfatterID som er fremmednøkkel mot Forfatter:

CREATE TABLE Bok (
    ISBN TEXT PRIMARY KEY,
    tittel TEXT NOT NULL,
    forfatterID INTEGER,
    FOREIGN KEY (forfatterID) REFERENCES Forfatter(forfatterID)
);

Fremmednøkler gir flere gevinster. De sikrer referanseintegritet: du kan ikke referere til en rad som ikke finnes, så et forsøk på å sette inn en bok med en forfatterID som ikke eksisterer, vil feile. De forhindrer også at du sletter data andre tabeller er avhengige av – du kan for eksempel ikke slette en forfatter hvis det fortsatt finnes bøker som peker til den. Og de dokumenterer relasjonene mellom tabellene.

En liten, men viktig detalj for mange-til-mange-relasjoner: de kan ikke uttrykkes direkte. I stedet lager vi en koblingstabell med fremmednøkler til begge sider. En LærerFag-tabell med (lærerID, fagID) som sammensatt primærnøkkel lar én lærer undervise i flere fag og ett fag undervises av flere lærere. Slik blir M:N til to håndterbare 1:N-relasjoner.

Oppsummering

God databasedesign begynner med en tegning. ER-modellering identifiserer entiteter (som blir tabeller), attributter og relasjoner – en-til-mange, mange-til-mange og en-til-en. Normalisering rydder opp i tre trinn: 1NF krever atomiske verdier, 2NF at alt avhenger av hele primærnøkkelen, og 3NF at ingen ikke-nøkkelattributter avhenger av hverandre. Målet er å lagre hver opplysning ett sted og unngå anomalier.

Tabellene bindes sammen av nøkler: primærnøkkelen identifiserer hver rad unikt, og fremmednøkkelen skaper relasjoner og sikrer referanseintegritet. Mange-til-mange-relasjoner løses med en koblingstabell. Med disse verktøyene bygger du databaser som er konsistente og enkle å vedlikeholde. I neste kapittel går vi videre til avansert SQL.