Normalisatie (databases)

Wat is normalisatie?

Normalisatie is het opdelen van data in aparte tabellen, zodat elk feit maar één keer opgeslagen staat. Elke tabel beschrijft één ding: klanten, producten, bestellingen. Sleutels leggen de verbanden tussen die tabellen.

Het probleem dat het oplost herken je meteen. Stel dat je bestellingen bijhoudt in één grote lijst, met op elke bestelregel het volledige klantadres. Verhuist die klant, dan moet je dat adres in honderden rijen aanpassen. Vergeet je de helft, dan heeft dezelfde klant plots twee adressen in je systeem. Welk adres klopt? Niemand die het nog weet.

In een genormaliseerde database staat dat adres op één plek, in de klantentabel. De bestelregels verwijzen ernaar met een klantnummer. Eén wijziging, overal juist.

De basis werd gelegd door Edgar Codd, een onderzoeker bij IBM. Hij beschreef in 1970 het relationele model waar zowat elke moderne database op steunt, en werkte begin jaren zeventig de eerste normaalvormen uit.

De normaalvormen in gewone taal

De regels van normalisatie heten normaalvormen. Ze bouwen op elkaar verder: voldoet je database aan de eerste drie regels, dan staat ze in derde normaalvorm. Verder dan die derde vorm gaat bijna niemand, en voor de meeste toepassingen hoeft dat ook niet.

Eerste normaalvorm: elke kolom één waarde

Geen drie telefoonnummers in één cel, en geen kolommen Product1, Product2 en Product3 naast elkaar. Wat doe je dan bij product vier? Herhalende groepen verhuizen naar een eigen tabel, met een rij per waarde.

Tweede normaalvorm: alles hangt af van de volledige sleutel

Elke kolom moet iets zeggen over de sleutel van haar tabel. Het klantadres zegt iets over de klant, niet over de bestelregel. Dus hoort het in de klantentabel en nergens anders.

Derde normaalvorm: niets hangt af van een andere kolom

Kolommen mogen ook onderling niet van elkaar afhangen. Neem een studententabel met de studiebegeleider én het lokaalnummer van die begeleider. Dat lokaal hangt af van de begeleider, niet van de student. Verhuist de begeleider naar een ander lokaal, dan moet je elke student met die begeleider aanpassen. De oplossing is een aparte tabel voor begeleiders, met hun lokaal erbij.

Er bestaan nog strengere vormen, zoals de Boyce-Codd-normaalvorm, maar die spelen in de dagelijkse praktijk zelden een rol.

Waarom transactionele systemen genormaliseerd zijn

Je boekhoudpakket, webshop, CRM en ERP zijn transactionele systemen, in het jargon OLTP. Ze verwerken de hele dag kleine schrijfacties: een bestelling erbij, een adres gewijzigd, een factuur geboekt.

Voor dat soort werk is normalisatie goud waard. Elke wijziging raakt precies één rij, dus je data spreekt zichzelf nooit tegen. De database bewaakt bovendien dat verbanden kloppen: een bestelling voor een klantnummer dat niet bestaat, wordt gewoon geweigerd.

Dat je ook opslagruimte bespaart is mooi meegenomen. De grootste winst is betrouwbaarheid.

Normaliseren versus denormaliseren

Voor rapportage geldt de omgekeerde logica. Een analyse leest duizenden of miljoenen rijen tegelijk en schrijft niets terug. Elke join die de query moet leggen kost dan tijd, en een model met veertig tabellen is voor een rapportbouwer niet te overzien.

Daarom worden analytische modellen bewust gedenormaliseerd: je plakt gegevens terug samen en aanvaardt dat sommige waarden herhaald worden. Het ster-schema is daar het bekendste voorbeeld van. De dimensietabellen bevatten met opzet redundante kolommen, omdat rapporten daardoor sneller en eenvoudiger worden. Microsoft raadt die vorm aan als basis voor Power BI-modellen, en Databricks raadt sterk genormaliseerde modellen op een lakehouse zelfs af.

De twee werelden spreken elkaar niet tegen. Dezelfde data leeft in twee vormen: genormaliseerd in het bronsysteem waar ze ingevoerd wordt, gedenormaliseerd in de rapportagelaag waar ze gelezen wordt. Dimensioneel modelleren is de ontwerpmethode voor die tweede vorm, en een ETL-proces brengt de data van de ene vorm naar de andere.

Wanneer normaliseer je, en wanneer niet?

De vuistregel: normaliseer waar geschreven wordt, denormaliseer waar gelezen wordt.

• Wel normaliseren. Operationele systemen waar mensen data invoeren en wijzigen: klantbeheer, orderverwerking, voorraad. Alles waar een fout adres of een dubbele klant echt pijn doet.

• Niet of minder normaliseren. Rapportagemodellen, data warehouses en Power BI-datasets. Daar wint leessnelheid van schrijfcomfort.

Voor veel KMO's begint dit niet bij een database maar bij Excel. Een werkblad waar klant, product, prijs en verkoper in elke rij opnieuw staan is het klassieke niet-genormaliseerde vertrekpunt. Het werkt, tot iemand een klantnaam net iets anders spelt of een oude prijs laat staan. Vanaf dan tellen je draaitabellen dubbel of verkeerd.

De stap naar een echte database of een goed opgezet Power BI-model is in wezen een normalisatie-oefening: klanten in één lijst, producten in één lijst, en bestellingen die ernaar verwijzen.

Waar moet je op letten bij het normaliseren

Te ver doorschieten kan ook. Wie elke denkbare afhankelijkheid wegwerkt, eindigt met tientallen mini-tabellen voor gemeenten, postcodes en klantcategorieën. Query's hebben dan tien joins nodig om een simpele vraag te beantwoorden, en dat maakt ze traag en onleesbaar. Al die kleine tabellen kunnen de prestaties zelfs schaden.

Een pragmatische aanpak werkt beter: normaliseer streng wat vaak wijzigt, zoals adressen en prijzen. Voor waarden die zelden of nooit veranderen mag je soepeler zijn.

Denk ook vooraf na over waar je data gelezen wordt. Rapporteer je rechtstreeks op een sterk genormaliseerde bron, dan betaal je de joinkost bij elke rapportvernieuwing. Een aparte, gedenormaliseerde rapportagelaag lost dat op.

FAQ over normalisatie

1. Moet elke database in derde normaalvorm staan?
Voor transactionele systemen is dat een gezonde standaard. Voor rapportagemodellen juist niet: daar kies je bewust voor een gedenormaliseerd ster-schema.

2. Is een genormaliseerde database trager?
Schrijven gaat net veiliger en sneller. Lezen over veel tabellen heen kost meer joins en dus meer tijd. Daarom bouw je voor zware rapportage een aparte leeslaag.

3. Wat is denormaliseren?
Bewust redundantie toelaten om sneller te kunnen lezen. Je plakt tabellen samen tot bredere tabellen, zoals de dimensietabellen in een ster-schema.

4. Geldt dit ook voor mijn Excel-bestanden?
Het principe wel. Aparte tabbladen voor klanten en producten, met opzoekfuncties ernaartoe, voorkomen al veel tikfouten en dubbels. Groeit de lijst, dan is een database of een datamodel in Power BI de volgende stap.