6.5 Normalisering og databasedesign

Fellen med én stor tabell

Forestill deg at en skole lagrer alt i én eneste tabell, der hver rad har elevens navn, klasse, lærer, fag og karakter. Problemet ser du fort: Emmas navn og klasse gjentas for hver karakter hun har. Bytter Emma klasse, må du oppdatere flere rader – og glemmer du én, blir dataene inkonsistente. Normalisering er løsningen: en systematisk metode for å organisere tabeller slik at slike problemer unngås.

Unormaliserte tabeller skaper tre typer anomalier. En oppdateringsanomali oppstår når duplisert data endres ulikt: Emma bytter fra 10A til 10B, men hvis du bare oppdaterer to av tre rader, står det 10A i én og 10B i to. En innsettingsanomali betyr at du ikke kan lagre noe uten tilhørende data: du kan ikke registrere en ny lærer uten samtidig å ha en elev og en karakter, fordi alt er i samme tabell. Og en slettingsanomali betyr at sletting fjerner mer enn tenkt: sletter du den eneste karakteren i et fag, mister du kanskje også informasjonen om at en bestemt lærer underviser i faget.

Alle tre skyldes det samme: data som logisk hører til forskjellige ting, er blandet i én tabell. Normalisering deler dataene inn i separate, spesialiserte tabeller, etter en serie regler kalt normalformer (NF). De tre første – 1NF, 2NF og 3NF – dekker de fleste praktiske behov.

De to første normalformene

Første normalform (1NF) krever at alle kolonner inneholder atomære verdier – udelelige enkelverdier – at det ikke finnes gjentakende grupper, og at hver rad er unik. Et klassisk brudd er en fag-kolonne med verdien «Matematikk, Norsk, Naturfag» i én celle. Da kan du ikke søke med WHERE fag = 'Naturfag', fordi cellen ikke inneholder bare det. Løsningen er å dele opp i én rad per fag, slik at hver celle har én verdi. Et annet brudd er gjentakende kolonner som fag1, fag2, fag3 – hva gjør du hvis en elev tar et fjerde fag? Også her er svaret å bruke rader i stedet for kolonner.

Andre normalform (2NF) krever at tabellen er i 1NF, og at alle ikke-nøkkelkolonner avhenger av hele primærnøkkelen. Dette gjelder bare tabeller med sammensatte primærnøkler (nøkler av to eller flere kolonner). Tenk på en kursregistreringstabell med nøkkel (elevid, fagid) som også inneholder elevnavn og fagnavn. Her er problemet at elevnavn bare avhenger av elev_id, og fagnavn bare av fag_id – ikke av hele nøkkelen. Bare karakter avhenger av hele nøkkelen. Løsningen er å dele opp i tre tabeller: én for elever, én for fag og én for karakterer. Da lagres hvert navn bare én gang.

Tredje normalform og når man lar være

Tredje normalform (3NF) krever at tabellen er i 2NF, og at ingen ikke-nøkkelkolonne avhenger av en annen ikke-nøkkelkolonne. Med andre ord: alle ikke-nøkkelkolonner skal avhenge direkte av primærnøkkelen, ikke indirekte. Tenk på en elevtabell med både postnummer og poststed. Her avhenger poststed av postnummer, som avhenger av elev_id – en transitiv avhengighet (elev_id → postnummer → poststed). Konsekvensen er at «Oslo» lagres flere ganger, og bytter postnummeret navn, må mange rader oppdateres. Løsningen er å skille ut en egen poststeder-tabell, slik at hvert poststed lagres bare én gang.

En fin huskeregel for de tre normalformene er: «nøkkelen, hele nøkkelen, og ingenting annet enn nøkkelen» – 1NF handler om nøkkel, 2NF om hele nøkkelen, og 3NF om bare nøkkelen.

Men normalisering er ikke alltid svaret. Noen ganger velger man bevisst å denormalisere og tillate litt redundans. Av ytelseshensyn: en normalisert database krever mange JOIN-operasjoner, og i systemer med ekstremt mange spørringer kan det bli en flaskehals. For rapportering og analyse (datawarehouses) brukes ofte flate tabeller med litt redundans, fordi spørringene blir enklere. Og for svært enkle systemer kan full normalisering bli unødvendig komplisert. Hovedregelen er likevel: start alltid med normalisering, og denormaliser bare ved dokumenterte ytelsesproblemer – det er mye lettere å denormalisere en ryddig database enn å rydde opp i en rotete en.

Oppsummering

Én stor tabell er en felle som skaper tre anomalier: oppdaterings-, innsettings- og slettingsanomali, alle fordi ulike data er blandet sammen. Normalisering rydder opp ved å dele data i spesialiserte tabeller etter normalformene.

1NF krever atomære verdier (én verdi per celle), 2NF at ikke-nøkkelkolonner avhenger av hele den sammensatte nøkkelen, og 3NF at det ikke finnes transitive avhengigheter mellom ikke-nøkkelkolonner. Huskeregelen er «nøkkelen, hele nøkkelen, og ingenting annet enn nøkkelen». Som hovedregel normaliserer du alltid først, og denormaliserer bare bevisst ved dokumenterte ytelsesbehov.