Normalform (databaser)
Normalformer är i samband med relationsdatabaser ett systematiskt sätt att se till att databasstrukturen är lämplig för normala frågedatabaser så att inga oönskade anomalier vid insättning, uppdatering eller borttagning kan ske, och därmed att skydda databasens integritet. De vanligaste är 1NF, 2NF, 3NF och Boyce-Codds normalform (BCNF). Inte lika ofta implementerade är 4NF, 5NF och 6NF. Dessa anger, i ökande grad av strikthet, ett antal krav på databasens utseende. 1NF räcker för skapa en databas, men vid lägre normalform ökar risken för att anomalier när data uppdateras.
För tabeller som ingår i så kallade stjärnscheman i informationslager tillämpar man dock inte normalformerna (annat än kravet på bara ett värde per rad och attribut, vilket de flesta databasmotorer kräver).
Första normalformen (1NF) redigera
Första normalformen innebär att varje cell endast innehåller ett värde.[1] Det förutsätts dessutom att raderna är unika, annars är det ingen tabell.[2]
Exempel på 1NF redigera
Följande tabell är i 1NF då varje cell bara innehåller ett värde. I tabellen är primärnyckeln persnr + avdnr. Då attributen namn och avdnamn bara är beroende av en del av primärnyckeln klarar tabellen inte 2NF.
| persnr | namn | avdnr | avdnamn |
|---|---|---|---|
| P1 | Lina | A1 | Mjällby |
| P1 | Lina | A2 | Orsa |
| P2 | Karl | A1 | Mjällby |
| P2 | Karl | A3 | Landskrona |
Exempel på normalisering redigera
Tabellen innehåller flera värden i varje cell i kolumnen telenr och är därför inte i första normalformen.
| kundnr | kundnamn | telenr |
|---|---|---|
| K001 | Lina | 111, 222 |
| K002 | Denise | 333, 444 |
| K003 | Robert | 555, 666 |
För att uppfylla 1NF kan telenr sättas i en separat tabell:
| kundnr | kundnamn |
|---|---|
| K001 | Lina |
| K002 | Denise |
| K003 | Robert |
| kundnr | telenr |
|---|---|
| K001 | 111 |
| K001 | 222 |
| K002 | 333 |
| K002 | 444 |
| K003 | 555 |
| K003 | 666 |
Nu är kundnr i tabellen KundTelefonnr en främmande nyckel som hänvisar till primärnyckeln i tabellen Kund.
Andra normalformen (2NF) redigera
För att vara i andra normalformen måste tabellen vara i första normalformen. Dessutom får det inte finnas några fullständiga funktionella beroenden mellan delar av primärnyckeln och attribut i tabellen. Ett fullständigt funktionellt beroende innebär dels att ett attribut är beroende av ett eller flera andra attribut, dels att de attribut som styr beroendet är så få som de kan vara utan att beroendet upphör.
Exempel på 2NF redigera
I tabellen nedan är regnr primärnyckel. Då det bara finns ett attribut i nyckeln kan inga attribut vara beroende av en del av nyckeln. Därför är tabellen i 2NF. Attributet bränsle är beroende av ett icke-nyckel attribut, vilket gör att tabellen inte klarar kraven för 3NF.
| regnr | motor | bränsle |
|---|---|---|
| BIL 001 | D1 | Diesel |
| BIL 002 | D1 | Diesel |
| BIL 003 | B1 | Bensin |
Exempel på normalisering redigera
Sammansatt nyckel för tabellen nedan är anstnr och certifikat. Anstnr eller anstnamn kan inte vara ensam nyckel då det kan finnas dubbletter för olika certifikat. Certifikat kan inte vara ensam nyckel då det kan finnas dubbletter när två anställda har samma certifikat. Attributet anstnamn är beroende av endast en del av den sammansatta nyckeln, nämligen anstnr, vilket gör att tabellen inte är i andra normalformen.
| anstnr | certifikat | anstnamn |
|---|---|---|
| A001 | Trafikflyg | Lena |
| A001 | Segelflyg | Lena |
| A002 | Trafikflyg | Kalle |
| A002 | Segelflyg | Kalle |
Problemen kan lösas genom att dela tabellen.
| anstnr | anstnamn |
|---|---|
| A001 | Lena |
| A002 | Kalle |
| anstnr | certifikat |
|---|---|
| A001 | Trafikflyg |
| A001 | Segelflyg |
| A002 | Trafikflyg |
| A002 | Segelflyg |
Tredje normalformen (3NF) redigera
För att vara i tredje normalformen, 3NF, måste tabellen vara i andra normalformen. Dessutom får det inte finnas några fullständiga funktionella beroenden mellan attribut utanför primärnyckeln, bara från och till primärnyckeln och delar av den.
Exempel på normalisering redigera
I exemplet nedan är regnr primärnyckel. Bränsletypen är beroende av ett annat attribut, vilken motor som används. Tabellen är därför på andra normalformen men inte i tredje normalformen.
| regnr | motor | bränsle |
|---|---|---|
| BIL 001 | D1 | Diesel |
| BIL 002 | D1 | Diesel |
| BIL 003 | B1 | Bensin |
| BIL 004 | B1 | Bensin |
Problemet kan lösas genom att dela tabellen:
| regnr | motor |
|---|---|
| BIL 001 | D1 |
| BIL 002 | D1 |
| BIL 003 | B1 |
| BIL 004 | B1 |
| motor | bränsle |
|---|---|
| D1 | Diesel |
| B1 | Bensin |
Boyce-Codds normalform redigera
Boyce-Codds normalform, BCNF, är samma som 3NF, med tillägget att det inte får finnas några beroenden från attribut utanför nyckeln in i den. Det fullständiga villkoret är alltså:
För att vara på Boyce-Codds normalform, BCNF, måste tabellen vara i andra normalformen. Dessutom får det inte finnas några fullständiga funktionella beroenden mellan attribut utanför primärnyckeln, bara från primärnyckeln (och även från delar av den).
Källor redigera
Fotnoter redigera
- ^ Connolly & Begg (2004), s 175-176
- ^ ”Database design with UML and SQL, 3rd edition - Basic structures: rows and tables”. Arkiverad från originalet den 13 september 2013. https://web.archive.org/web/20130913161429/http://www.tomjewett.com/dbdesign/dbdesign.php?page=tables.php. Läst 17 september 2013.
Litteratur redigera
- Connolly, Thomas M.; Begg Carolyn E. (2004) (på engelska). Database solutions: a step-by-step guide to building databases (2. ed.). Harlow: Addison-Wesley. Libris 9326776. ISBN 0-321-17350-3