Normalisering*
Att normalisera en relationsdatabas betyder att man justerar strukturen på sin data så att den följer vissa regler. De reglerna samlas i s.k. normalformer.
Syftet med normaliseringen är att undvika extraarbete i framtiden. Man vill inte att samma data ska finnas på flera olika ställen om det inte är absolut nödvändigt, och man vill att det ska vara hyfsat enkelt att bygga ut databasen senare.
Ett vanligt knep för att komma ihåg de tre normalformerna är att varje attribut som inte är en (primär)nyckel ska hänvisa till nyckeln, hela nyckeln och ingenting annat än nyckeln. Det är såklart en referens till den amerikanska eden där man svär att säga "the truth, the whole truth, and nothing but the truth".
Man normaliserar ofta i samband med att man omvandlar ett ER-diagram till en tabell.
Första normalformen (1NF): Nyckeln
1NF säger att tabellen ska ha en primärnyckel, alltså en kolumn vars innehåll är unikt. Man kan tänka på det som att primärnyckeln ger varje rad/post en unik identitet.
1NF säger också att alla andra kolumner ska beskriva attribut som hänger ihop med nyckeln – och att varje kolumn bara ska innebära ett attributvärde.
Det finns en primärnyckel
Alla andra kolumner innehåller data som är kopplade till nyckeln
(Bara att värde per kolumn)
Andra normalformen (2NF): Hela nyckeln
2NF säger att kolumnerna som inte är del av primärnyckeln inte ska vara beroende av bara någon del av primärnyckeln, utan hela.
Det här kan alltså bara hända om man har en primärnyckel som består av flera kolumner/attribut. Håller man sig till primärnycklar som bara består av en kolumn så uppnår man 2NF automatiskt.
1NF plus…
Alla kolumner som inte ingår i primärnyckeln innehåller bara data som är kopplade till hela primärnyckeln.
Tredje normalformen (3NF): Ingenting annat än nyckeln
3NF säger att kolumnerna som inte är en del av primärnyckeln inte ska vara beroende av något annat än primärnyckeln. Ingen av kolumnerna ska alltså ha ett innehåll som beror på en annan icke-primärnyckel-kolumn.
2NF plus…
Alla kolumner som inte ingår i primärnyckeln innehåller bara data som bara är kopplade till primärnyckeln
Ett enkelt sätt att tänka på 3NF är att man ser till att varje tabell bara innehåller information om en kategori av saker. Att varje post, varje rad, innehåller information om en sak.
Om man har en tabell med meddelanden som skickats, och bara behöver spara namnen på avsändare och mottagare, så funkar det. Men om man också vill hålla reda på personernas inloggningsuppgifter så bör man ha en separat tabell för användare. Och sedan använda kolumner med främmande nycklar.
Dåliga exempel
Nedan finns exempel som bryter mot de olika normalformerna.
1NF
Den första regeln innebär att man till exempel aldrig gör tabeller som ser ut såhär:
I det fallet är ju relationen mellan en användare och en kommentar 1:N, det vill säga varje användare kan ha skrivit flera kommentarer men varje kommentar är bara skriven av en användare. Då är det enkelt att istället lagra upphovspersonens id i kommentarstabellen:
2NF
(Kommer…)
3NF
Nedanstående tabell följer inte 3NF, eftersom user_name och user_id beror på – hänger ihop med – varandra. Istället borde man ha en separat kolumn för användare.
Last updated