Dimensioneel modelleren (Kimball-methode)

Wat is dimensioneel modelleren?

Dimensioneel modelleren is een ontwerpmethode voor data warehouses en analytische modellen waarin je feiten en context strikt uit elkaar houdt. Je splitst je data in feittabellen (wat er gebeurde) en dimensietabellen (wie, wat, waar, wanneer). Samen vormen ze een star schema: één centrale feittabel omringd door de dimensies die de context leveren.

De methode werd in 1996 geformaliseerd door Ralph Kimball in The Data Warehouse Toolkit. De derde editie van dat boek dateert uit 2013 en is nog steeds het standaardwerk in het vak. Zijn kamp staat tegenover de top-down school van Bill Inmon, die wél met een enterprise-brede genormaliseerde integratielaag begint.

Je kan een dimensioneel model zien als een foto met bijschrift. Het feit is de foto (omzet, aantal stuks, tijd in een proces), de dimensies zijn de antwoorden op wie, wat, waar, wanneer. Zonder bijschrift is de foto maar half begrijpbaar. Zonder foto is het bijschrift leeg.

Feiten, dimensies en grain

Feittabellen
Bevatten de numerieke waarden die je wil optellen, middelen of tellen: omzetbedrag, aantal orderlijnen, verwerkingsduur. Plus de sleutels naar de relevante dimensies. Vaak smal (weinig kolommen), maar lang (veel rijen).

Dimensietabellen
Bevatten de beschrijvende context: product, klant, datum, verkoper, vestiging. Typisch breed (veel kolommen) met hiërarchieën ingebouwd (productcategorie naar productgroep naar SKU).

Grain
Het meest onderschatte begrip in de methode. Grain zegt wat één rij in je feittabel voorstelt: "één orderlijn", "één geboekte afspraak", "één dagelijkse voorraadstand per SKU per vestiging". Zet je dat niet scherp voor je begint, dan wordt je model een kluwen waar geen rapport nog klopt.

Slowly Changing Dimensions
Klanten verhuizen, verkopers wisselen van team, producten krijgen nieuwe categorieën. Moet een historisch rapport de oude of de nieuwe waarde tonen? Kimball's Type 0 tot Type 7 SCD-patronen geven je een taal om die keuze expliciet te maken.

Conformed dimensions
Dezelfde dimensie (bijvoorbeeld Klant of Datum) wordt in meerdere feittabellen gedeeld. Dat maakt cross-process rapportering mogelijk: omzet versus marketingkosten per klantgroep per maand, zonder dat je aan het konkelen bent.

Kimball's vier ontwerpstappen

Kimball schreef een methode in vier stappen die vandaag nog even bruikbaar is.

1. Kies een bedrijfsproces. Orders, leveringen, betalingen, personeelsmutaties. Eén proces per feittabel.

2. Verklaar de grain. "Eén rij per orderlijn op het moment van bevestiging." Op die keuze kan je later niet meer terugkomen zonder opnieuw te beginnen.

3. Identificeer de dimensies. Welke beschrijvende context kleeft aan een rij uit dit proces? Datum, klant, product, verkoper, kanaal.

4. Identificeer de feiten. Welke getallen wil je meten en aggregeren op die grain? Aantallen, bedragen, duurwaarden.

De stappen lijken triviaal, en juist daar gaat het vaak mis. Teams duiken direct in de tabelstructuur zonder grain te verklaren, en lopen twee maanden later tegen dubbeltellingen op die niemand meer kan uitleggen.

Kimball versus Inmon

De klassieke discussie in data warehousing. Inmon, wiens "Building the Data Warehouse" in 1992 uitkwam, pleit voor een top-down aanpak: eerst een enterprise-brede, sterk genormaliseerde data warehouse (3NF), daarboven afgeleide dimensionele marts voor rapportering.

Kimball pleit voor een bottom-up aanpak: start met het belangrijkste bedrijfsproces, modelleer dat dimensioneel, en groei organisch door conformed dimensions tussen marts te delen.

In de praktijk gebruiken veel organisaties een mengvorm: een genormaliseerde of Data Vault-integratielaag onderin, en daarboven dimensionele serveerschema's voor BI. Kimball's dimensionele modelleerprincipes domineren nog altijd op die bovenste laag, ongeacht wat eronder staat.

Is Kimball vandaag nog relevant?

Het korte antwoord: ja voor BI op lakehouses en warehouses, minder voor bepaalde AI- en self-service-scenario's.

Waar Kimball wint
Microsoft Fabric en Databricks bevelen expliciet een star schema aan als fundering voor Power BI semantische modellen. De reden is simpel: Power BI's VertiPaq-engine is geoptimaliseerd voor die vorm. Eén feittabel met dimensies rondom, presteert beter en laat business users eenvoudig eigen berekeningen bouwen. Dertig jaar na publicatie is dat principe niet verouderd.

Wat evolueerde
De fysieke implementatie. Waar Kimball oorspronkelijk over aparte databases sprak met zware ETL-pipelines, zijn marts vandaag vaak gewoon views of logische tabellen bovenop een lakehouse. De methodologie blijft, de plumbing is lichter.

Surrogate keys (numerieke ID's naast natuurlijke sleutels) zijn iets minder heilig geworden: op columnar storage is het performantievoordeel kleiner. Schema-evolutie is eveneens toegankelijker geworden (Delta, Iceberg) dan in de relationele warehouses van 2000.

Waar het wringt
AI- en data-science-workflows werken vaak liever met brede, gedenormaliseerde tabellen (One Big Table). Elke join die een feature-engineer moet doen is een kans op een bug. DuckDB, BigQuery en self-service op Snowflake verdragen en moedigen die brede vorm aan. Voor die workloads is Kimball soms overkill.

Semi-gestructureerde bronnen (JSON-events, logs, webclicks) laten zich moeilijker in een klassiek star schema persen. Data Vault of lakehouse-patronen met late binding werken dan beter in de integratielaag.

Welke principes overleven?

Zelfs als je geen aparte warehouse meer bouwt, blijven deze Kimball-principes overeind.

• Grain-discipline. Voor elk analytisch model moet je kunnen zeggen wat één rij betekent. Zonder dat lopen rapporten onvermijdelijk uit elkaar.

• Expliciete dimensies. Beschrijvende context hoort in aparte tabellen of in duidelijk afgelijnde kolommen, zodat filters en slicers consistent bedienen.

• Conformed dimensions. Gedeelde definities van klant, product en datum voorkomen de eeuwige "maar in mijn rapport staat een ander cijfer"-discussie.

• SCD als expliciete keuze. De beslissing om historische waarden te bewaren of te overschrijven is geen technisch detail, het is een bedrijfskeuze. Kimball gaf ons de taal om die keuze scherp te stellen.

Waar Kimball niet past

Real-time event streams, graph-workloads, ongestructureerde documenten en modellen voor machine learning volgen andere patronen. Kimball is gemaakt voor gestructureerde bedrijfsprocessen die in de tijd geaggregeerd worden. Voor dat domein blijft het de logische keuze, ook op moderne cloud-platforms. Voor de rest: kies het patroon dat bij de workload past, en vermijd de reflex om alles in een ster te willen persen.