Normalisering er en balancegang

Normalisering af en database, er en teknik som sikrer at rettelser i databasen, kan foretages med mindst muligt indflydelse på det oprindelige system. Målet er at minimere redundant data. Det vil sige at samme oplysning er gemt flere steder. Med normalisering bliver det lettere at foretage rettelser i databasen (så skal man kun rette det ét sted).

Problemerne med redundans kan deles op i to grundargumenter:

• Performance: Dataudtræk kan blive langsomme, da den redundante data medfører at der bliver brugt unødvendig ressourcer (IO, memory, netværk og cpu).
• Maintainability: Den samme opdatering skal foretages mange steder.

 

Man skal begrænse sin normalisering til de 3 normalformer. Der findes flere trin, men når en tabel er bragt på 3. normalform, så vil den i langt de fleste tilfælde også opfylde 4. og 5. normalform. Det er rigeligt. Der kan dog argumenteres for at man skal bruge BCNF/3.5NF istedet for 3. normalform... men det er en anden snak, man kan læse om Boyce Codd normal formen her.

Der er dog et men. Normalisering er ikke altid den hellige gral. Det er helt normalt at gå på kompromis med normalformerne netop for at øge performance for centrale forespørgsler i de applikationer, der anvender den. En fuldt normaliseret database kan medføre at selv de mest simple udtræk skal ske over mange joins, hvilket ofte vil være langsommere at eksekvere, end en tabel som ikke overholder alle normalformer, men er specifikt skræddersyet til at indeholde de relevante data.

Det er med andre ord lidt en balancegang i forhold til performance, men det skal være velovervejede designbeslutninger og ikke dovenskab der skal være styrende for om man vælger at gå på kompromis med normalformerne. Normalisering er godt i teorien, og er absolut en god tommelfingerregel.

tak til Thomas Magnussen, Kaj Neupert samt Alex Pedersen for deres input.

1. Normalform / 1NF

• Ingen kolonner må gentage en anden kolonnes værdi.
• Atomare værdier.

Hvis en tabel har ens attributter af felter inden for samme primærnøgle (vare 1, vare 2, vare 3), så skal denne gruppe af felter fjernes fra tabellen og lægges over i en ny tabel sammen med en kopi af primærnøglen. (Kig på eksemplet i bunden at artiklen).

2. Normalform / 2NF

• Tabellen skal opfylde alle krav for 1. normalform.
• Hvis en tabel har en sammensat nøgle skal alle felter, der ikke indgår i nøglen, afhænge af den samlede nøgle.
• Alle non-prime attributter skal være fuldt funktionelt afhængige af primær nøglen. (dvs. ingen partiel funktionel afhængighed).

Hvis der kun findes en enkelt primær nøgle er tabellen allerede i 2. normalform, hvis der derimod er en sammensat primærnøgle, kan den stadig bringes til 2. normalform, ved at splitte tabellen op i separate tabeller.

3. Normalform / 3NF

• Tabellen skal opfylde alle krav for 2. normalform.
• Der må ikke findes felter uden for primærnøglen, som er indbyrdes afhængige.
• Ingen transitive funktionelle afhængigheder mellem non-prime attributter.

Medlemstabellen/Kundetabellen, hvor både feltet postnummer og by indgår, er det klassiske eksempel på en tabel, som ikke er på 3. normalform. Det gælder om at splitte de attributter der ikke har en direkte tilknytning til primærnøglen i tabellen, ud i deres egne nye tabeller.

Boyce Codd Normalform / BCNF

• Tabellen skal opfylde alle krav for 1. normalform. (Hvis BCNF er opfyldt, opfylder den automatisk 2. og 3. normalform).
• I alle funktionelle afhængigheder A => B skal A være kandidat nøgle.