Normalisering

Denne introduksjonen til normalisering har som mål å vise prosessen fra universalrelasjonen til 3. normalform.
For enkelthelt skyld vil jeg bruke et eksempel som jeg har vist tidligere, nemlig pasientregisteret.
Primærnøkler er merket med grønt

Universalrelasjonen

Dette er den første samlingen av data vi har, her ligger alle dataene som trengs i kun 1 tabell.
Universalrelasjonen kan defineres som et slags halvordnet kaos som vi sakte med sikkert rydder opp i.
I universalrelasjonen er det ingen regler annet enn at man har rader og kolonner.

Eksempel på universalrelasjon

1. normalform

For at en tabell skal kunne være i 1. normalform, kan den ikke inneholde ikke-atomære verdier eller repeterende grupper.

Ikke-atomære verdier: Verdier som inneholder flere delverdier
Repeterende grupper: At det finnes mer enn en verdi i krysset mellom rad og kolonne i tabellen

I vår tabell er det følgende brudd på 1. normalform:
Ikke-atomære verdier: pasient_adr(inneholder gateadresse, postnr og poststed)
Repeterende grupper: pasient_personnr, pasient_navn, pasient_adr, pasient_tlf og pasient_yrke

NB! I noen tilfeller vil det være hensiktsmessig å dele opp i flere tabeller allerede i 1. normalform. Har man mange kolonner vil det kunne se direkte merkelig ut å ikke dele opp i undertabeller.
Et eksempel på dette er en bedrift med kunder, ansatte, varer, bestillinger, leveringsbud osv. Dette vil bli en diger universalrelasjon og en 1. normalform full av null-verdier, hvis dataene skal bli riktig, og dette er ikke hensiktsmessig. Da er det bedre å begynne å splitte litt logisk opp med det samme. Man kan da oppleve at man allerede er i 2. normalform når man er ferdige med å rydde.

Når bruddene er rettet opp, er tabellen vår i 1. normalform, og da ser det slik ut:

2. normalform

For at en tabell skal kunne være i 2. normalform, må alle verdier være fullt funksjonelt avhengig av primærnøkkelen.

Full funksjonell avhengighet: Betyr at man ikke har noen partielle avhengigheter
Partiell avhengighet: Betyr at en verdi er avhengig av kun deler av primærnøkkelen

I vår tabell er det følgende brudd på 2. normalform:
Partielle avhengigheter(p.a.a.):
 fastlege_navn er p.a.a. fastlege_id(avhengig av fastlege_id, men ikke pasient_personnummer)
 pasient_navn er p.a.a. pasient_personnr(avhengig av pasient_personnummer, men ikke fastlege_id)

Når bruddene er rettet opp, er tabellen vår i 2. normalform, og da ser det slik ut:

Fastlege

Pasient

3. normalform

For at en tabell skal kunne være i 3. normalform, kan man ikke ha noen transitive avhengigheter

Transitiv avhengighet: Betyr at en verdi er avhengig av en annen ikke-primærnøkkel-verdi

I vår tabell er det følgende brudd på 3. normalform:
Transitive avhengigheter:
 poststed er transitivt avhengig av postnr(men postnr er ikke noen primærnøkkel)

Når bruddene er rettet opp, er tabellen vår i 3. normalform, og da ser det slik ut:

Fastlege

Pasient

Poststed

Boyce-Codd normalform

For at en tabell skal kunne være i Boyse-Codd normalform, må alle determinanter være kandidatnøkler

Determinant: Attributt eller gruppe attributter som en annen attributt er fullt funksjonelt avhengig av
Supernøkkel: Et eller flerer attributter som sammen identifiserer en entitet unikt
Kandidatnøkkel: Minimalistiske supernøkler, dvs at man kan fjerne et attributt fra en supernøkkel og så er det fortsatt unikt

I vår tabell er det ingen brudd på Boyce-Codd normalform:
Determinanter: personnr(pasient); postnr(poststed); fastlege_id(fastlege)
Kandidatnøkkler: personnr(pasient); postnr(poststed); fastlege_id(fastlege)