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?

  1. Bekræft at tabellen er i 1NF (atomare værdier og unik identifikator).
  2. Identificer primærnøglen (er den sammensat eller enkelt?).
  3. For hver ikke-nøglekolonne: spørg om værdien afhænger af hele primærnøglen eller kun af en del af den.
  4. 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.