Derde normaalvorm (3NF)

Wat is de derde normaalvorm (3NF)?

De derde normaalvorm is een niveau van databaseontwerp waarbij elke kolom die geen sleutel is afhangt van de primaire sleutel, de volledige sleutel en niets anders dan de sleutel. Het is het doel waar de meeste goed ontworpen operationele databases naar mikken. Elk gegeven staat op precies één plek, rechtstreeks gekoppeld aan het ding dat het beschrijft.

De uitdrukking "de sleutel, de volledige sleutel en niets dan de sleutel" is de bekende samenvatting van de eerste drie normaalvormen, toegeschreven aan Bill Kent. De derde normaalvorm is het stuk dat "niets dan de sleutel" regelt: geen enkele kolom mag een andere niet-sleutelkolom beschrijven in plaats van de sleutel zelf.

Het idee komt van Edgar F. Codd, die bij IBM het relationele model definieerde en begin jaren zeventig de eerste normaalvormen uitwerkte. 3NF bouwt voort op de tweede normaalvorm, die op haar beurt voortbouwt op de eerste.

De regel die 3NF wegwerkt: transitieve afhankelijkheid

Een transitieve afhankelijkheid is wanneer een niet-sleutelkolom afhangt van een andere niet-sleutelkolom, die dan weer afhangt van de sleutel. De afhankelijkheid bereikt de sleutel onrechtstreeks, via een omweg.

Neem een bestellingentabel met deze kolommen: bestel-id (de sleutel), klant-id, klantgemeente en klantpostcode. Het bestel-id identificeert de bestelling. Maar klantgemeente en postcode beschrijven de bestelling niet echt. Ze beschrijven de klant. De postcode hangt af van klant-id, en klant-id hangt af van bestel-id. Die omweg is de transitieve afhankelijkheid.

De oplossing is om de klantgegevens naar een klantentabel te verplaatsen en enkel het klant-id op de bestelling te laten staan. Nu beschrijft elke kolom op de bestelling de bestelling rechtstreeks. Gemeente en postcode staan één keer, bij de klant, waar ze thuishoren.

Waarom dat telt: in de niet-genormaliseerde versie betekent één klant die verhuist dat je elke bestelling moet aanpassen die hij ooit plaatste. Vergeet je één rij, dan houdt de database twee postcodes bij voor dezelfde persoon. In 3NF verander je de postcode op één plek.

De drie normaalvormen op een rij

3NF gaat ervan uit dat de twee vormen eronder al voldaan zijn.

• Eerste normaalvorm. Eén waarde per veld, geen herhalende groepen. Geen drie telefoonnummers in één cel proppen.

• Tweede normaalvorm. Heeft een tabel een samengestelde sleutel, dan hangt elke niet-sleutelkolom af van de volledige sleutel, niet van een deel ervan.

• Derde normaalvorm. Geen enkele niet-sleutelkolom hangt af van een andere niet-sleutelkolom. Elk gegeven wijst recht naar de sleutel.

Een strengere variant, de Boyce-Codd-normaalvorm, scherpt 3NF nog verder aan, maar voor de meeste bedrijfssystemen is 3NF het praktische doel.

3NF versus een gedenormaliseerd warehouse

3NF is gemaakt voor systemen die de hele dag data wegschrijven: een CRM, een ERP, een reservatiesysteem. Gegevens over meerdere tabellen verdelen betekent dat elke aanpassing één plek raakt, zodat de data consistent blijft.

Rapportering heeft de omgekeerde behoefte. Analisten lezen en tellen enorme aantallen rijen samen en schrijven zelden iets terug. Een stapel joins vertraagt die queries en maakt het model moeilijk leesbaar. Daarom breken warehouses 3NF bewust via denormalisatie. Een ster-schema kopieert beschrijvende waarden naar dimensietabellen, zodat een rapport klant, product en datum kan lezen zonder een hele reeks opzoekingen af te lopen.

Geen van beide is fout. Houd de operationele bron in 3NF om veilig te schrijven. Bouw een gedenormaliseerd model om snel te lezen. De vuistregel: normaliseer waar data geschreven wordt, denormaliseer waar data gelezen wordt.

Waar moet je op letten bij 3NF

3NF is een ontwerpdoel, geen religie. Elke kleine opzoeklijst in een eigen tabel splitsen kan simpele queries onleesbaar maken. Normaliseer streng waar waarden vaak veranderen, en blijf pragmatisch waar ze stabiel zijn.

Rechtstreeks rapporteren op een 3NF-bron doet pijn. Een grafiek die vijftien joins nodig heeft, is lastig te onderhouden en belast de operationele database. Bouw een analytische kopie zodra rapportering serieus wordt.

3NF zegt niets over wat de data betekent. Het werkt dubbele opslag weg, maar het bepaalt niet wat een actieve klant of een geannuleerde bestelling is. Voor die definities heb je nog altijd een eigenaar nodig.