Ontwerp tot de derde normaalvorm en doe dan een stap terug
Ook beschikbaar in 28 talen
English · Español · 日本語 · Português (Brasil) · Français · Deutsch · Italiano · 한국어 · 简体中文 · Português (Portugal) · 繁體中文 · Bahasa Indonesia · Türkçe · Polski · Tiếng Việt · ไทย · العربية · עברית · Українська · हिन्दी · Русский · Svenska · Dansk · Norsk bokmål · Suomi · Español (México) · Français (Canada) · Deutsch (Schweiz)
Module 5 van 6 in het hoofdstuk Data modelleren naar betekenis, hoofdstuk 2 van de cursus Data Architect. Elke module staat op zichzelf. Vorige: Zet data waar die hoort · Volgende: Zet het model om naar Salesforce
De vraag die deze module beantwoordt: Wanneer moet ik bewust afstappen van een schoon, genormaliseerd model?
In de vorige module zei ik dat je moet ontwerpen tot de derde normaalvorm.
Nu ga ik je vertellen dat je haar moet doorbreken.
Soms.
Dat is een belangrijk onderscheid. Er is een groot verschil tussen per ongeluk een rommelig datamodel bouwen en een schoon model bewust denormaliseren. Als je niet begrijpt waar de data eigenlijk hoort, is haar ergens anders heen kopiëren geen architectuur. Het is gewoon duplicatie.
Maar zodra ik het schone logische model begrijp, kan ik een bewuste beslissing nemen om de data anders vorm te geven voor de mensen en systemen die haar gebruiken.
Ontwerp waar haalbaar tot de derde normaalvorm. Doe dan een stap terug als het nodig is.
Kijk wat die zin niet zegt. Hij zegt niet dat de derde normaalvorm makkelijker te begrijpen is. Soms is ze moeilijker: een volledig genormaliseerd model kan één bedrijfsidee over vijf objecten verspreiden, en de mensen die ermee werken moeten het in hun hoofd weer in elkaar zetten. Normalisatie vertelt me waar elk feit hoort. Ze belooft niet dat dat de makkelijkste vorm is om te lezen, te gebruiken of over te rapporteren. Juist daarom is een stap terug doen een ontwerpvaardigheid en geen mislukking.
Begin met het modelleren van de waarheid. Beslis dan hoe die waarheid geleverd moet worden.
Zit, Blijf, Modelleer
Section titled “Zit, Blijf, Modelleer ”Terug naar de honden, en deze keer maken we een paar bewuste keuzes.
Ras: een keuzelijst, of een eigen tabel? Haal het door de vragen die ik je later in deze module geef. Is er meer dan één kolom informatie? Ja: in elk geval de grootte. Hoeveel waarden? Kennelclubs erkennen een paar honderd rassen (de American Kennel Club alleen al noemt er 205), ver boven mijn vuistregel van ongeveer 20. Dus Ras verdient een eigen tabel, en elke hond verwijst naar zijn ras. Dat beslecht de vraag die we sinds module 1 meedragen: Ras is een eigen vakje.
Niveau: een keuzelijst. Lerend, Goed, Expert. Drie labels, verder niets over te zeggen, en ze veranderen niet. Precies waar een keuzelijst voor is.
Hoeveel kunstjes kent elke hond? Het antwoord zit al in het model: tel de Hondkunstje-records van de hond. Maar de trainer wil dat getal op elk rapport, om erop te sorteren en te filteren, zonder een rapport over twee tabellen te bouwen. Dus doe ik een stap terug en houd ik een telling Aantal kunstjes direct op de hond bij. Dat is een kopie. De waarheid staat nog steeds in Hondkunstje; de telling is er een weergave van, en ze moet gelijk blijven lopen. Salesforce geeft ons een nette manier om precies dat te doen, en die zien we in module 6.
Nu de wending: de hondenschool gaat ook katten aannemen. Wat doen we? Eén optie: een tabel Kat naast de tabel Hond, en een Kattenkunstje naast het Hondkunstje. Alles verdubbelt: twee van elk scherm, twee van elk rapport, en op de dag dat ze konijnen aannemen, drie. De andere optie: een stap terug doen en zien dat een kat een eigenaar heeft, misschien een fokker, een ras, een geboortedatum en, met geduld, een kunstje of twee. Dezelfde feiten en dezelfde relaties als een hond. Dus we generaliseren: een Huisdier, met een Diersoort, hond of kat. Elk ras hoort ook bij een diersoort, en daar staat de diersoort echt: een labrador is een hond. Het huisdier draagt bewust een kopie, zodat elk scherm en rapport kan beginnen met “hond of kat?” zonder het ras op te zoeken. Nog een bewuste kopie, en in module 6 krijgt ze een eigen taak.
Dat is ontwerpen voor verandering, en het is een afweging. Generaliseer te vroeg en alles wordt een vaag “Ding” met een typeveld dat niemand begrijpt. Ik generaliseer als het bedrijf me echt de tweede soort brengt, en de twee bijna alles delen, zoals honden en katten hier. Als katten heel andere feiten nodig hadden, zou ik twee keer nadenken.
Nu dezelfde soort keuzes bij Steve Trucking, waar er meer op het spel staat.
Het schoonste model is niet altijd het beste systeem
Section titled “Het schoonste model is niet altijd het beste systeem ”Stel je een ploeg voor bij een stop. De levering heeft haar items. De installatie heeft een checklist. Elke stap heeft foto’s nodig. De ontvanger tekent.
Het genormaliseerde model is prachtig: Levering → Leveringsitem → Installatiechecklist → Foto, elk waar het hoort.
Dan ga ik zitten met de mensen die het echt gebruiken. Een ploeg sluit zo’n tien stops per dag af, op opritten, vaak zonder bereik. Als mijn prachtige model hen door een doolhof van schermen en related lists stuurt om één stop af te ronden, heb ik een architectuurprobleem.
Het datamodel is niet het enige wat we ontwerpen.
We ontwerpen een systeem.
Soms wint de gebruikerservaring
Section titled “Soms wint de gebruikerservaring ”Dit is een van de redenen waarom ik soms afstap van een perfect genormaliseerd model: gebruikerservaring.
Misschien kan een concept technisch een eigen entiteit zijn, maar voegt het scheiden ervan complexiteit toe die heel weinig oplevert. Misschien is een parent met meerdere niveaus children academisch schoon maar ellendig om in te voeren en te onderhouden. Misschien is het concept klein, stabiel en vooral gebruikt als keuze.
Hier stop ik met alleen vragen “Waar hoort dit feit in theorie?” en begin ik te vragen “Hoe gaat dit systeem echt gebruikt worden?”
Dat betekent niet dat elke klacht over een extra klik het model platter maakt. Het betekent dat bruikbaarheid een legitieme input voor architectuur is.
Soms wint de rapportage
Section titled “Soms wint de rapportage ”Rapportage is nog een veelvoorkomende reden.
Elke retailpartner wil een scorekaart: leveringen op tijd per regio, per maand. In het schone model kent een levering haar distributiecentrum, en kent het DC zijn regio. Technisch kunnen we dat volgen.
Maar kan de rapportagetool dat? Kunnen de mensen die hun eigen rapporten bouwen dat? Kunnen ze de vraag beantwoorden zonder een rapportagearchitectuur die ingewikkelder is dan de vraag zelf?
Dan kopieer of leid ik de regio misschien af naar de levering, dichter bij waar ze gebruikt wordt.
Nu heb ik duplicatie geïntroduceerd. Dus heb ik nog een vraag nodig: wie is eigenaar van de waarheid?
Als de bronwaarde verandert, wat gebeurt er dan met mijn kopie? Moet die mee veranderen? Of moet die bewaren wat waar was toen de levering plaatsvond? Dat zijn verschillende eisen.
Denormalisatie haalt complexiteit niet weg.
Ze verplaatst haar.
Lookup of keuzelijst?
Section titled “Lookup of keuzelijst? ”Hier is een kleiner voorbeeld waar Salesforce-admins steeds tegenaan lopen. De gebruiker moet kiezen uit een reeks waarden. Maak ik nog een entiteit en relateer ik daaraan, of gebruik ik een keuzelijst?
Neem de status van een levering: ingepland, geladen, onderweg, bijna aangekomen, afgeleverd, geïnstalleerd, uitzondering, retour. Een korte, stabiele lijst labels. Een keuzelijst is precies wat ik wil.
Neem nu het soort stop: alleen levering, levering met installatie, levering met afvoer. Dat soort draagt eigen informatie: hoe lang de stop duurt, welke vaardigheden de ploeg nodig heeft, welke installatiechecklist geldt. Het verandert onafhankelijk, en de business beheert het. Dat is een entiteit, geen label.
Als ik voor elk concept dat in theorie genormaliseerd kan worden een object maak, kan ik een technisch prachtig systeem bouwen waar niemand graag mee werkt. Als ik van elk concept een keuzelijst maak omdat dat makkelijk is, kan ik mezelf heel snel klemzetten.
Dus vraag ik: heeft het eigen informatie? Relaties? Verandert het onafhankelijk? Moet het als data beheerd worden? Kan de business er uiteindelijk meer van nodig hebben dan een label?
Dit zijn de vragen die ik in een ontwerpsessie echt stel.
Is er meer dan één kolom informatie? Als de waarde een omschrijving nodig heeft, een duur, een lijst vaardigheden, een eigenaar, is het geen label meer.
Hoeveel waarden? Mijn vuistregel is ongeveer 20. Boven de 20 waarden begint een keuzelijst te haperen, en is het tijd om aan een object te denken. Staten, met vijftig stuks, zijn de uitzondering waarmee we leven, en landen zijn erger; eerlijk, houdt iemand van keuzelijsten met landen? Ik vind ze irritant.
Worden de waarden in de loop van de tijd aangemaakt, en door wie? Een waarde aan een keuzelijst toevoegen is een configuratiewijziging, en dat betekent een admin. Als de business elke week waarden toevoegt, en de mensen die ze toevoegen geen admins zijn, zet een keuzelijst een ticket voor elke nieuwe waarde.
Moeten mensen erop filteren en erover rapporteren? Daar zijn keuzelijsten heel goed in. Lookups zijn minder netjes. Elke lookup voegt een stap toe: een rapporttype volgt maar een korte keten van gerelateerde objecten (een aangepast rapporttype staat hooguit vier objectrelaties toe), het scherm wordt related lists in related lists, en de code wordt ingewikkelder.
Een waardelijst begint vaak als keuzelijst en verdient zich in de loop van de tijd een eigen object. Laat haar dat verdienen.
Soms verandert schaal het antwoord
Section titled “Soms verandert schaal het antwoord ”Een ontwerp dat met een paar duizend records prachtig werkt, kan zich met miljoenen heel anders gedragen.
Kijk dus niet alleen naar het diagram. Ken de getallen.
Steve Trucking doet ongeveer een miljoen leveringen per jaar, met 30 procent groei per jaar. Elke levering verzamelt ongeveer acht statusupdates. Dat zijn dit jaar acht miljoen statusrecords, en in jaar drie zo’n 13,5 miljoen per jaar. Tel daar vier of vijf miljoen foto’s per jaar bij op.
Hetzelfde model. Een heel andere architectuur.
We gaan veel dieper in op dit onderwerp in Architectuur op grote schaal. Onthoud voor nu: volume kan een modelleerbeslissing veranderen. Een relatie die logisch klopt, is niet automatisch op elke schaal het beste fysieke ontwerp.
Verschillende gebruikers willen verschillende vormen
Section titled “Verschillende gebruikers willen verschillende vormen ”Tot nu toe dachten we aan het operationele systeem. Coördinatoren plannen leveringen. Ploegen sluiten stops af. Het systeem verandert terwijl de business draait.
Maar de business wil ook jaren historie analyseren. Welke partners en regio’s lopen achter? Hoe is de levertijd veranderd? Hoe vaak heeft een installatie een tweede bezoek nodig?
Een analytisch systeem wil dezelfde informatie misschien anders georganiseerd hebben. Je hoort termen als datawarehouse, feit, dimensie en sterschema. Die pakken we hier niet uit; bij Steve Trucking is dat het Snowflake-warehouse, en we komen er later in de cursus op terug.
Voor nu: verschillende gebruikers kunnen verschillende vormen van dezelfde waarheid nodig hebben.
AI voegt nog een gebruiker toe
Section titled “AI voegt nog een gebruiker toe ”En nu is er nog een gebruiker: AI.
Een ontvanger sms’t: “Waar is mijn levering?” Een AI-assistent zou dit kunnen opzoeken:
Levering 10427, Route 3312, Stop 7, Vrachtwagen 117, Tijdvak 13.00–15.00.
Een traditionele applicatie volgt die relaties zonder problemen. Maar om de ontvanger te antwoorden, heeft de assistent context nodig die uit meerdere plekken is samengesteld:
Je vaatwasser van Redrock is de zevende stop op de route van vandaag vanuit het distributiecentrum Phoenix. De vrachtwagen is nog drie stops van je verwijderd, en je zit nog binnen je tijdvak van 13.00 tot 15.00 uur.
We hebben informatie uit meerdere gerelateerde entiteiten gehaald en een plattere, contextrijke weergave samengesteld voor één specifieke gebruiker.
Dat betekent niet dat ik mijn genormaliseerde model vernietig. En het betekent zeker niet “AI houdt van platte data, dus stop alles in één gigantisch object”. Doe dat niet.
De bron van waarheid blijft schoon. AI krijgt een weergave die gebouwd is voor de taak die het doet. Het is hetzelfde idee dat we net bij analyse zagen:
Eén bron van waarheid kan meerdere vormen voor gebruik ondersteunen.
Later in de cursus gaan we veel dieper in op grounding en retrieval.
Creëer geen meerdere waarheden
Section titled “Creëer geen meerdere waarheden ”Hier schuilt een gevaar.
Als ik de regio naar de levering kopieer voor rapportage, een platte versie naar Snowflake stuur en een contextrijke versie bouw voor de AI-assistent, welke klopt er dan?
Die vraag heeft een antwoord nodig. Ik wil weten waar de gezaghebbende waarde staat. Al het andere is een weergave van die waarheid voor een doel.
Die plek is het bronsysteem (system of record). Gedenormaliseerde kopieën kunnen goed zijn: het stopscherm, de scorekaart, Snowflake en de AI-context doen hun werk elk beter met een vorm die voor hen gebouwd is, en ernaar verwijzen is prima. Maar als er iets verandert, begint de wijziging in het bronsysteem, meestal het relationele model, en stroomt ze naar buiten naar elke kopie. Niemand corrigeert de regio in Snowflake, of past de context van de AI met de hand aan. Corrigeer het bij de bron, en laat de wijziging doorstromen.
En het doet er het meest toe als data verandert. Als een distributiecentrum vandaag naar een andere regio verhuist, moeten de leveringen van vorige maand dan de nieuwe regio tonen? Misschien. Misschien niet. Voor de historie heb ik misschien de regio nodig die waar was toen de levering plaatsvond. Dat is geen synchronisatieprobleem meer. Dat is een bedrijfsbeslissing.
Daarom mag denormalisatie nooit per ongeluk gebeuren. Elk gedupliceerd feit roept vragen op over eigenaarschap, synchronisatie, historie en vertrouwen. Het is het afwegingsdenken uit hoofdstuk 1: weet wat je koopt (een makkelijker scherm, een eenvoudiger rapport, betere context voor AI) en wat je betaalt (dubbele data, synchronisatie, ingewikkelder eigenaarschap van de waarheid). En omdat we vanuit een schoon logisch model begonnen, kunnen we naar elke kopie wijzen en zeggen: “Ik weet dat dit daar hoort. Ik zet hier een weergave ervan vanwege deze eis.” Dat is een beslissing die we kunnen beoordelen, uitdagen en opschrijven, zodat de volgende architect weet waarom.
Wat een architect hier beslist
Section titled “Wat een architect hier beslist ”Als ik denormalisatie overweeg, beslis ik:
- Waar de gezaghebbende bron van elk bedrijfsfeit staat.
- Of het schone model echte problemen veroorzaakt voor gebruikers, rapportage, schaal of prestaties.
- Of een eenvoudiger weergave de duplicatie waard is, en hoe de kopie betrouwbaar blijft.
- Of historische waarden moeten veranderen als de huidige bron verandert.
- Of analyse of AI een andere vorm van de data nodig heeft dan het operationele systeem.
Het beginpunt verandert nooit: weet waar de waarheid hoort. Geef haar dan, als de eisen het rechtvaardigen, vorm voor levering.
Daarna komt Salesforce weer in beeld. We gaan wat we ontworpen hebben omzetten in een fysiek datamodel.
Verder lezen
Section titled “Verder lezen ”- Build Powerful Reports with Custom Report Types (opens in a new tab) (Engels), Salesforce Admins, 24 juni 2019 (gecontroleerd op 2026-10-12): een aangepast rapporttype “can span up to 4 object relationships” (kan tot 4 objectrelaties omvatten).
- Unleash the hounds, terriers and lapdogs: American Kennel Club recognizes 3 more breeds (opens in a new tab) (Engels), PBS NewsHour, 2 januari 2026 (gecontroleerd op 2026-10-12): de AKC erkent 205 rassen, inclusief deze drie nieuwkomers.
- Voor de lol: de FCI Breeds Nomenclature (opens in a new tab), Fédération Cynologique Internationale (gecontroleerd op 2026-10-12): de rassenlijst van de internationale federatie, in tien groepen. Scroll er doorheen en je ziet waarom Ras een eigen tabel verdiende.