Förord

Denna artikel är ett komplement och en rättning av artikeln Normalisering, vad är det? Artikeln innehåller förvisso en del bra tumregler men motiveringarna till att använda dem är felaktiga. Till att börja med hävdar författaren att det finns 4 normalformer, punkt slut. Det är förvisso sant att det finns fyra (1-4NF) men det finns fler och en vanlig är Boyce-Codd NF (BCNF). Några andra är Project-Join NF (PJNF) och Domain-Key NF. Det är ett mindre viktigt fel men det finns saker som är helt uppåt väggarna.

Innehåll

  » 1NF regeln
  » 2NF regeln
  » 3NF regeln
  » Slutsats

Angående artikeln om normalisering:

Problemen börjar när författaren beskriver reglerna. Den första normaliseringsregeln (1NF) säger enligt honom att:

• Det får inte finnas några dublettkolumner, dessa ska brytas ut till egna tabeller.
  
• Varje tabell ska ha en unik nyckel som består av en/flera kolumner.
  

Det första påståendet, att man inte ska ha flera kolumner som refererar till liknande attribut som Position1 och Position2 eller lönMaj03, lön Jun03 osv, är förvisso ett bra exempel på hur man inte bör designa sin databas men det har INGENTING med 1NF att göra. Faktum är att relationer med sådana tabeller tom kan vara i BCNF men är ändå inte bra design eftersom nya kolumner måste skapas för varje ny position eller månadslön. Det andra påståendet måste gälla för ALLA relationer oavsett vilken normalform de är i annars kan man inte referera till dem.

1NF regeln

För att en relation ska vara i 1NF måste följande gälla.

• Domänerna för alla attribut (kolumner) är atomära.
  

Dvs att ingen kolumn innehåller fler än ett värde. Relationen Person (Persnr, Namn, Adress, Postnr, Ort) är inte i 1NF (och alltså i 0NF) om namn kan innehålla flera värden:


Persnr Namn Postnr Ort
-----------------------------------------------------------
770203-1112 Magnus Kalle 174 58 Storstan

Istället får man göra så här:

Persnr Namn Postnr Ort
---------------------------------------------------
770203-1112 Kalle 174 58 Storstan
770203-1112 Magnus 174 58 Storstan


Primärnyckeln kan inte vara Persnr eftersom det inte unikt bestämmer en rad utan måste nu inkludera Namn.

2NF regeln

Vad säger författaren om 2NF? Den andra normaliseringsregeln (2NF) säger att:

• Det ska inte finnas något data som upprepas på flera rader, dessa ska brytas ut och placeras i egna tabeller (med primärnyckel)
  

Detta stämmer inte heller. Data kan mycket väl upprepas på flera rader. Det som är avgörande är beroenden mellan nyckeln och de andra kolumnerna. För att en relation ska vara i 2NF måste den vara i 1NF och alla kolumner som inte är en del av nyckeln måste bestämmas av hela nyckeln. I vår relation ovan så bestäms Postnr och Ort av hela nyckeln men också av bara Persnr och relationen är INTE i 2NF. För att få det måste vi bryta ut de kolumner som bestäms av en del av nyckeln till en ny relation:


Persnr Namn
-------------------------
770203-1112 Kalle
770203-1112 Magnus

Primärnyckel är (Persnr, Namn)

Persnr Postnr Ort
---------------------------------
770203-1112 174 58 Storstan

Primärnyckel är (Persnr)


3NF regeln

Nu till den viktigare 3NF regeln. Här säger författaren följande. Den tredje normaliseringsregeln (3NF) säger att:

• En tabell ska endast innehålla data som är beroende av primärnyckeln
  

Alltså ungefär det den riktiga 2NF regeln säger men för att en relation ska vara i 3NF måste den vara i 2NF och det får inte finnas några transitiva beroenden av nyckeln hos några kolumner. Ett transitivt beroende innebär att om X bestämmer Y och Y bestämmer Z så är Z transitivt bestämt av X.
I vårt fall är ju Postnr och Ort bestämt av Persnr men Ort är ju även bestämt av Postnr så det finns ett transitivt beroende. För att komma till 3NF bryter man då ut de beroende kolumnerna till en ny relation:


Persnr Namn
-------------------------
770203-1112 Kalle
770203-1112 Magnus

Primärnyckel är (Persnr, Namn)

Persnr Postnr
---------------------
770203-1112 174 58

Primärnyckel är (Persnr)

Postnr Ort
---------------------
174 58 Storstan

Primärnyckel är (Postnr)


Relationerna är nu i 3NF. Både 4NF och BCNF är lite krångliga och jag kommer inte försöka förklara dem här.

Slutsats

Slutligen vill jag bara tillägga att den struktur jag visar nu är korrekt normaliserad men kanske inte optimal i det här fallet. Som författaren påpekar kanske det är onödigt att bryta ut postnummer och ort och man kan nöja sig med att vara i 2NF.
Man kan säga att normalisering bidrar till en god databasdesign med ett antal tumregler som om de är uppfyllda förbättrar konstruktionen. Det finns även andra viktiga tumregler men de är utanför den här artikelns omfattning.
Normalisering kan vara en god hjälp vid databasdesign men man ska aldrig lita blint på tumregler!

4 Kommentarer

1. 
   Kalle Dahlberg
   

   8 aug 2003

   Varför inte ha för och efternamn i varsin kolumn? Det är väl tillåtet?

2. 
   Per Malmén
   

   8 aug 2003

   Det är klart att man får (och bör) ha för och efternamn i varsin kolumn. Det råkade bara bli utan efternamn överhuvud taget i artikeln.

3. 
   Mattias Olgerfelt
   

   25 aug 2005

   Även om SQL Server bara stödjer upp till 4... /M

4. 
   Per Malmén
   

   29 sep 2006

   En enkel sökning på wikipedia visar att PJNF även är känd som 5NF. Det finns även förslag på vad som ska kallas 6NF men det var inte direkt det artikeln gick ut på.

Skriv en kommentar på artikeln

Ditt betyg på artikeln

UtmärktLäsvärdIntressantMindre braDålig

Kommentar: