1 Waarom een goed databaseontwerp?

Belangrijk

Je leest de versie die nog in ontwikkeling is. Dit hoofdstuk is nog een concept; er kan nog veel veranderen.

Leerdoelen

Na het bestuderen van dit hoofdstuk kun je:

uitleggen wat er misgaat als gegevens zonder ontwerp in één grote tabel worden opgeslagen;
de drie soorten anomalieën herkennen en benoemen;
de kenmerken van een goed relationeel ontwerp opsommen;
de twee ontwerpmethoden uit dit boek, ERD en normalisatie, in eigen woorden beschrijven;
beargumenteren welke methode het beste past bij een gegeven ontwerpsituatie.

1.1 Gegevens zonder ontwerp

Bijna elke organisatie begint met het bijhouden van gegevens in een spreadsheet. Dat is begrijpelijk: een Excel-werkblad is snel opgezet, iedereen kan ermee werken en zolang de hoeveelheid gegevens beperkt blijft, gaat het meestal goed. Toch loopt vrijwel elke organisatie na verloop van tijd tegen de grenzen van deze aanpak aan.

Stel dat een kleine webshop in koffie en koffieaccessoires al haar bestellingen bijhoudt in één werkblad. Elke regel beschrijft één product in één bestelling (Tabel 1.1).

Tabel 1.1: Bestellingen van de webshop in één tabel

OrderNr	Datum	KlantNr	Klantnaam	Woonplaats	ProductNr	Omschrijving	Prijs	Aantal
1001	2026-03-02	K01	Jansen	Utrecht	P10	Koffiebonen 1kg	14,95	2
1001	2026-03-02	K01	Jansen	Utrecht	P12	Filterpapier	3,49	1
1002	2026-03-03	K02	De Vries	Zwolle	P10	Koffiebonen 1kg	14,95	1
1003	2026-03-05	K01	Jansen	Amersfoort	P15	Melkopschuimer	24,95	1

Op het eerste gezicht is er niets aan de hand: alle informatie staat erin. Kijk je beter, dan zie je een aantal problemen.

Herhaling (redundantie). Naam en woonplaats van klant K01 staan drie keer in de tabel. De omschrijving en prijs van product P10 staan er twee keer in. Bij duizenden bestellingen worden dezelfde gegevens duizenden keren opgeslagen.
Tegenstrijdigheid (inconsistentie). Klant K01 woont volgens de eerste twee regels in Utrecht, maar volgens de laatste regel in Amersfoort. Is de klant verhuisd, of is er een typefout gemaakt? De tabel kan het niet vertellen.
Onduidelijkheid over feiten. Wat is de prijs van koffiebonen? Als de prijs volgende maand stijgt, staan er straks twee prijzen in de tabel. Welke geldt nu?

Deze problemen ontstaan niet door slordigheid van de gebruiker, maar door de structuur van de tabel: klantgegevens en ordergegevens horen niet in dezelfde rij thuis. Het zijn twee verschillende soorten dingen die toevallig samen in één tabel zijn gepropt. Dat is precies wat databaseontwerp oplost: het scheiden van verschillende soorten gegevens in aparte, gekoppelde tabellen.

1.1.1 Anomalieën: wat er misgaat bij wijzigen

De gevolgen van een slechte structuur worden pas echt zichtbaar wanneer je gegevens gaat toevoegen, wijzigen of verwijderen. We spreken dan van anomalieën.

Wijzigingsanomalie (update anomaly): Klant Jansen verhuist. Je moet nu alle regels van Jansen opzoeken en de woonplaats overal aanpassen. Vergeet je er één, dan is de database inconsistent, zoals in Tabel 1.1 al is gebeurd.
Invoeganomalie (insert anomaly): De webshop neemt een nieuw product op in het assortiment: een handmolen (P20). Zolang niemand dit product heeft besteld, is er geen regel waarop je het kunt vastleggen. Hetzelfde geldt voor een nieuwe klant die nog niets heeft gekocht.
Verwijderanomalie (delete anomaly): Klant De Vries annuleert bestelling 1002 en die regel wordt verwijderd. Daarmee verdwijnt ook alle informatie over klant De Vries uit de database, terwijl die klant nog steeds bestaat.

Herken je dit?

Wie ooit een groot Excel-bestand heeft beheerd waarin dezelfde gegevens op meerdere plaatsen staan, kent deze problemen uit de praktijk. Zoekfuncties als X.ZOEKEN en draaitabellen kunnen veel oplossen, maar ze nemen het onderliggende probleem niet weg: hetzelfde feit staat op meer dan één plek.

1.1.2 De gevolgen voor een organisatie

Een slecht ontwerp is geen technisch detail. Het heeft directe gevolgen voor de bedrijfsvoering.

Onbetrouwbare informatie. Rapportages over omzet per klant of per regio kloppen niet als dezelfde klant met verschillende woonplaatsen in de database staat. Managementbeslissingen worden dan genomen op basis van verkeerde cijfers.
Hogere kosten. Fouten opsporen en herstellen kost tijd. Hoe langer een gebrekkig ontwerp in gebruik is, hoe meer gegevens er zijn en hoe duurder het wordt om het ontwerp achteraf te verbeteren.
Moeilijk uit te breiden. Wil de webshop later ook leveranciers, voorraad of retouren registreren, dan is dat in één grote tabel vrijwel onmogelijk zonder alles om te gooien.
Risico’s rond privacy. Als persoonsgegevens op veel plaatsen herhaald worden, is het lastig om ze volledig te corrigeren of te verwijderen, terwijl de AVG¹ dat wel vereist.

Een goed ontwerp vooraf is daarom veel goedkoper dan een slecht ontwerp achteraf repareren.

1.2 Kenmerken van een goed ontwerp

Wat is dan een goed ontwerp? Voor een relationele database, het type database dat in dit boek centraal staat, gelden de volgende kenmerken.

Elke tabel beschrijft één onderwerp. Klanten, producten en bestellingen krijgen elk een eigen tabel.
Elk feit wordt één keer vastgelegd. De woonplaats van een klant staat op precies één plek. Wie die wijzigt, wijzigt hem overal.
Elke rij is uniek herkenbaar. Elke tabel heeft een primaire sleutel (PK = Primary Key), zoals een klantnummer of productnummer.
Tabellen zijn met elkaar verbonden via sleutels. Een bestelling verwijst naar een klant door het klantnummer op te nemen als vreemde sleutel (FK =Foreign Key). Zo blijft de samenhang bewaard zonder dat gegevens worden gekopieerd.
De database bewaakt zelf de samenhang. Een bestelling kan niet verwijzen naar een klant die niet bestaat. Dit heet referentiële integriteit.

Als we de webshop volgens deze regels ontwerpen, ontstaan vier tabellen die met elkaar verbonden zijn (Figuur 1.1). Hoe je tot zo’n ontwerp komt, is precies het onderwerp van dit boek.

erDiagram
    Klant ||--o{ Order : plaatst
    Order ||--|{ OrderRegel : bevat
    Product ||--o{ OrderRegel : "komt voor in"
    Klant {
        string KlantNr PK
        string Naam
        string Woonplaats
    }
    Order {
        int OrderNr PK
        date Datum
        string KlantNr FK
    }
    OrderRegel {
        int OrderNr PK, FK
        string ProductNr PK, FK
        int Aantal
    }
    Product {
        string ProductNr PK
        string Omschrijving
        decimal Prijs
    }

Figuur 1.1: Het ontwerp van de webshop als entity-relationship-diagram

Je hoeft dit diagram nu nog niet volledig te begrijpen. Let vooral op het resultaat: de woonplaats van Jansen staat nog maar op één plek, een nieuw product kan worden toegevoegd zonder dat iemand het heeft besteld, en het verwijderen van een bestelling laat de klant ongemoeid. Alle anomalieën uit de vorige paragraaf zijn verdwenen.

1.3 Van werkelijkheid naar database

Een database ontwerpen gebeurt meestal in drie stappen, van abstract naar concreet.

Conceptueel model: Welke dingen zijn er in de werkelijkheid waarover we informatie willen vastleggen, en hoe hangen ze samen? Bijvoorbeeld: een klant plaatst bestellingen, een bestelling bevat producten. Dit model is onafhankelijk van de software.
Logisch model: Het conceptuele model vertaald naar tabellen, kolommen, primaire sleutels en vreemde sleutels. Dit model is nog steeds onafhankelijk van een specifiek databaseprogramma.
Fysiek model: Het logische model uitgewerkt in een concreet databasesysteem, zoals Microsoft Access of SQLite, met datatypen, indexen en andere technische keuzes.

Dit boek richt zich op de eerste twee stappen: het conceptuele en het logische ontwerp. Dat is het denkwerk dat aan elke database voorafgaat, ongeacht welk programma je daarna gebruikt.

1.4 Twee methoden

Er zijn twee gangbare methoden om tot een goed logisch ontwerp te komen. Beide komen in dit boek aan bod.

1.4.1 Methode 1: ontwerpen met ERD’s

Bij deze methode begin je bij de werkelijkheid. Je stelt jezelf vragen als: over welke zaken wil de organisatie gegevens bijhouden? Welke eigenschappen hebben die zaken? Hoe hangen ze met elkaar samen? Het antwoord teken je in een entity-relationship-diagram (ERD), zoals in Figuur 1.1. Het diagram vertaal je vervolgens volgens vaste regels naar tabellen.

Deze werkwijze heet ook wel top-down: je begint met het grote geheel en werkt naar de details toe. De methode werd in 1976 geïntroduceerd door Peter Chen en is sindsdien de meest gebruikte manier om databases te ontwerpen.

1.4.2 Methode 2: normaliseren

Bij normaliseren begin je juist bij de gegevens zelf, bijvoorbeeld een bestaand werkblad zoals Tabel 1.1, een formulier of een factuur. Die gegevens breng je stap voor stap terug tot een verzameling kleinere tabellen. Bij elke stap toets je de tabellen aan een vaste regel, een normaalvorm. Een tabel die aan de derde normaalvorm voldoet, is vrij van de anomalieën die je hierboven hebt gezien.

Deze werkwijze heet ook wel bottom-up: je begint bij de losse gegevens en bouwt daaruit de structuur op. De methode is afkomstig van Edgar F. Codd, de grondlegger van het relationele model, en werd in de jaren 1970 ontwikkeld.

1.5 Waarom twee methoden?

Als beide methoden tot hetzelfde resultaat leiden, waarom zou je ze dan allebei leren? Daar zijn drie redenen voor.

Ze hebben een ander vertrekpunt. In de praktijk begint een ontwerpopdracht niet altijd op dezelfde manier. Soms moet je een nieuw systeem ontwerpen voor een proces dat nog niet bestaat; dan heb je alleen een beschrijving van de werkelijkheid en ligt een ERD voor de hand. Soms ligt er al een Excel-bestand, een formulier of een stapel facturen die je moet omzetten naar een database; dan is normaliseren de natuurlijke aanpak.

Ze controleren elkaar. Een ERD is een tekening op basis van inzicht en ervaring. Het is goed mogelijk dat je daarbij iets over het hoofd ziet. Normalisatie geeft je een objectieve toets: voldoen de tabellen die uit je ERD voortkomen aan de derde normaalvorm? Omgekeerd helpt een ERD om de tabellen die uit normalisatie voortkomen overzichtelijk weer te geven en te bespreken.

Ze geven samen meer begrip. Met ERD’s leer je denken in samenhang: welke zaken zijn er en hoe verhouden ze zich tot elkaar? Met normalisatie leer je precies te begrijpen waarom een ontwerp goed of fout is. Wie beide beheerst, kan een ontwerp niet alleen maken maar ook verdedigen.

1.6 Welke methode kies je?

Tabel 1.2 zet de belangrijkste verschillen op een rij.

Tabel 1.2: Vergelijking van de twee ontwerpmethoden

Kenmerk	ERD	Normalisatie
Vertrekpunt	Beschrijving van de werkelijkheid	Bestaande gegevens (werkblad, formulier, factuur)
Werkrichting	Top-down	Bottom-up
Karakter	Visueel, intuïtief	Stapsgewijs, systematisch
Sterk punt	Overzicht en communicatie met gebruikers	Objectieve toets op fouten in de structuur
Valkuil	Vergeten of verkeerd ingeschatte relaties	Abstract; overzicht raakt soms zoek
Geschikt voor	Nieuwe systemen, grotere ontwerpen	Omzetten van bestaande lijsten en documenten

Voor de keuze kun je de volgende vuistregels hanteren.

Ontwerp je iets nieuws op basis van een beschrijving of een gesprek met de opdrachtgever? Begin met een ERD.
Heb je al gegevens in een spreadsheet, op een formulier of in een rapport? Begin met normaliseren.
Twijfel je, of is het ontwerp belangrijk? Maak eerst een ERD en controleer de tabellen daarna op de derde normaalvorm.

Advies

De meeste studenten vinden de ERD-methode het gemakkelijkst om mee te beginnen, omdat je direct ziet wat je doet. Daarom behandelt dit boek ERD’s als eerste. Leer daarna ook normaliseren: het is het gereedschap waarmee je controleert of je ontwerp echt klopt.

1.7 Opbouw van dit boek

Het boek bestaat uit de volgende onderdelen.

Hoofdstuk 2: Ontwerpen met ERD’s. Je leert entiteiten, attributen en relaties herkennen, ze tekenen in een ERD en het diagram omzetten naar tabellen. Het hoofdstuk sluit af met oefeningen.
Hoofdstuk 3: Normaliseren. Je leert een bestaande verzameling gegevens stap voor stap omzetten naar de eerste, tweede en derde normaalvorm. Ook dit hoofdstuk sluit af met oefeningen.
Hoofdstuk 4: Opgaven. Een reeks ontwerpopdrachten waarbij je zelf kiest welke methode je gebruikt. Wie wil, kan een opgave met beide methoden uitwerken en de uitkomsten vergelijken.

In alle hoofdstukken keert de webshop uit dit hoofdstuk terug als doorlopend voorbeeld.

1.8 Kernbegrippen

Anomalie: Ongewenst effect bij het toevoegen, wijzigen of verwijderen van gegevens, veroorzaakt door een gebrekkige tabelstructuur.
Redundantie: Het meer dan één keer opslaan van hetzelfde feit.
Primaire sleutel (PK): Kolom (of combinatie van kolommen) waarmee elke rij in een tabel uniek te herkennen is.
Vreemde sleutel (FK): Kolom die verwijst naar de primaire sleutel van een andere tabel en zo een relatie legt.
Referentiële integriteit: De regel dat een vreemde sleutel alleen mag verwijzen naar een rij die werkelijk bestaat.
Entity-relationship-diagram (ERD): Tekening van de entiteiten, hun attributen en de relaties daartussen.
Normalisatie: Stapsgewijze methode om een tabelstructuur te toetsen en te verbeteren aan de hand van normaalvormen.

Algemene Verordening Persoonsgegevens (AVG)↩︎