Guide til 2NF: Anden normalform – krav, forklaring og eksempler
Lær 2NF (anden normalform): krav, forklaring og praktiske eksempler på, hvordan du normaliserer tabeller, fjerner partielle afhængigheder og sikrer dataintegritet.
Anden normalform (2NF) er en egenskab ved en relationel model, især tabeller, som er et kriterium for normalisering af databaser. 2NF hjælper med at fjerne partielle funktionelle afhængigheder mellem ikke-nøgleattributter og dele af en sammensat primærnøgle, så data undgår redundans og inkonsistens.
Det første kriterium for at være anden normalform er, at tabellen skal være første normalform (1NF): hver celle må indeholde atomare værdier, og hver række skal være unik. Oven i dette kræver 2NF, at alle ikke-nøgleattributter er fuldt funktionelt afhængige af hele primærnøglen, ikke kun af en del af den.
Kernebegreber
- Primærnøgle: En eller flere kolonner, der entydigt identificerer en række.
- Partiel afhængighed: Når en ikke-nøglekolonne afhænger kun af en del af en sammensat primærnøgle (fx afhænger A af B, hvor primærnøglen er (B,C)).
- Fuld funktionel afhængighed: En kolonne afhænger af hele primærnøglen — hvis primærnøglen er sammensat, må afhængigheden ikke kunne forklares af kun en del af den.
- Enkeltkolonne-primærnøgle: Hvis primærnøglen kun er én kolonne, findes der ingen partielle afhængigheder, så 1NF => 2NF (med mindre nøgleattributterne har indbyrdes afhængigheder af anden type).
Hvordan tester du om en tabel er i 2NF?
- Bekræft at tabellen er i 1NF (atomare værdier og unik identifikator).
- Identificer primærnøglen (er den sammensat eller enkelt?).
- For hver ikke-nøglekolonne: spørg om værdien afhænger af hele primærnøglen eller kun af en del af den.
- Hvis nogen ikke-nøglekolonner afhænger kun af en del af en sammensat primærnøgle, bryder tabellen 2NF.
Eksempel (praktisk)
Overvej en tabel OrderLines med disse kolonner:
- OrderID
- ProductID
- ProductName
- Quantity
- UnitPrice
- CustomerName
Her kunne primærnøglen være (OrderID, ProductID). ProductName afhænger kun af ProductID (ikke af hele (OrderID, ProductID)) — det er en partiel afhængighed og altså et brud på 2NF. CustomerName afhænger kun af OrderID, hvilket ligeledes er en partiel afhængighed.
For at bringe tabellen i 2NF kan vi dekomponere:
- OrderLines(OrderID, ProductID, Quantity, UnitPrice)
- Products(ProductID, ProductName)
- Orders(OrderID, CustomerName)
Eksempel på SQL-snit (for illustration):
CREATE TABLE Products ( ProductID INT PRIMARY KEY, ProductName VARCHAR(255) ); CREATE TABLE Orders ( OrderID INT PRIMARY KEY, CustomerName VARCHAR(255) ); CREATE TABLE OrderLines ( OrderID INT, ProductID INT, Quantity INT, UnitPrice DECIMAL(10,2), PRIMARY KEY (OrderID, ProductID), FOREIGN KEY (OrderID) REFERENCES Orders(OrderID), FOREIGN KEY (ProductID) REFERENCES Products(ProductID) );
Hvad 2NF ikke løser
- 2NF fjerner partielle afhængigheder, men håndterer ikke transitive afhængigheder (f.eks. A → B og B → C). Transitive afhængigheder behandles i tredie normalform (3NF).
- Normalisering kan øge antallet af tabeller og dermed kræve flere JOINs — en afvejning mellem dataintegritet og ydeevne kan nødvendiggøre bevidst denormalisering i visse systemer.
Praktiske tips
- Start altid med at identificere forretningsreglerne: hvad identificerer en række, og hvilke egenskaber tilhører hvilke entiteter?
- Brug 2NF som et trin i normaliseringsprocessen: 1NF → 2NF → 3NF (evt. BCNF) afhængigt af behov for redundansreduktion og konsistens.
- Dokumentér nøgler og afhængigheder; det gør det lettere at vurdere, om en tabelløsning overholder 2NF.
Konklusion: Anden normalform kræver, at tabellen er i 1NF og at alle ikke-nøgleattributter er fuldt afhængige af hele primærnøglen. Det eliminerer redundans forårsaget af partielle afhængigheder og er et vigtigt skridt i at sikre dataintegritet i relationelle databaser.
Søge