Från Rilpedia

Normalformer är i samband med relationsdatabaser ett slags tumregler för hur databasen bör designas för att få så god prestanda och vara så säker mot felaktiga data som möjligt. 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.

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).

Innehåll 1 Första normalformen 2 Andra normalformen 3 Tredje normalformen 4 Boyce-Codds normalform

Första normalformen

1NF innebär att varje attribut i en databas endast får innehålla ett värde och att varje rad (post, tupel) måste vara unik jämfört med andra rader i tabellen (oftast sker detta med hjälp av ett unikt attribut, en så kallad primärnyckel, medan resten av värdena kan vara lika för flera rader).

Ett exempel:

Försäljning

Kund	Datum	Vara	Belopp	Leverantör
Peter	2008-10-13	Symaskin, Motorsåg	2 300	Singer, Black & Decker
Peter	2008-10-15	Dammsugare	1 100	Elextrolux
Sara	2008-10-15	Symaskin, Lastbil	128 600	Singer, Saab

(Lägg märke till att vi har gjort flera förenklingar här. Vi förutsätter att varje kund bara gör ett inköp per vara och dag. Dessutom utesluter vi uppgift om hur mycket av varan söm köpts, utan förutsätter att det alltid är ett exemplar.)

Den här tabellen innehåller flera värden i attributen Vara och Leverantör. För att den ska uppfylla 1NF så borde den istället vara:

Försäljning

Kund	Datum	Vara	Belopp	Leverantör
Peter	2008-10-13	Symaskin	1 100	Singer
Peter	2008-10-13	Motorsåg	1 200	Black & Decker
Peter	2008-10-15	Dammsugare	1 100	Elextrolux
Sara	2008-10-15	Symaskin	1 100	Singer
Sara	2008-10-15	Lastbil	127 500	Saab

med Kund, Datum och Vara som primärnyckel.

Andra normalformen

För att vara i andra normalformen, 2NF, 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, och att de attribut som styr beroendet är så få som de kan vara utan att beroendet upphör. Till exempel är Leverantör ovan beroende av Vara. Däremot behövs inte några andra delar av primärnyckeln (det vill säga Kund eller Datum) för att definiera beroendet.

På samma sätt är Belopp beroende av Vara.

För att undvika detta beroende skapar vi en ny tabell, Varor, och ändrar i tabellen Försäljning. Vanligtvis lägger man dessutom till en så kallad teknisk (numerisk) nyckel, som inte har något annat syfte än att vara unik och peka ut raden. På så sätt slipper man att ange ett långt nyckelbegrepp, och kan ange ett tal i stället: