Wat is een data warehouse?

Een data warehouse is een centraal analytisch systeem dat data uit meerdere bronnen integreert, consolideert en beschikbaar maakt voor rapportage en analyse. Het is fundamenteel anders dan een operationele database (OLTP): een data warehouse is geoptimaliseerd voor leesbewerkingen over grote datahoeveelheden, niet voor snelle schrijf- en updatoperaties.

De vier klassieke kenmerken van een data warehouse (gedefinieerd door Bill Inmon):

• Subject-georiënteerd: georganiseerd rondom businessonderwerpen (verkoop, klanten, producten) in plaats van applicaties.
• Geïntegreerd: data uit meerdere bronnen is geharmoniseerd naar één consistente definitie.
• Niet-volatiel: data in een DWH wordt niet overschreven of verwijderd — historische data blijft bewaard.
• Tijdvariabel: data bevat altijd een tijdsdimensie zodat trends over tijd geanalyseerd kunnen worden.

Kimball: dimensioneel modelleren

Ralph Kimball introduceerde de dimensionele modellering benadering in de jaren negentig en het is tot op de dag van vandaag de meest gebruikte methodologie voor data warehouse design. De kerngedachte: modelleer data vanuit het perspectief van de businessgebruiker, niet vanuit de techniek.

Kimball's aanpak begint met het identificeren van businessprocessen: verkoop, inkoop, klantenservice, productie. Elk businessproces wordt gemodelleerd als een fact table (de meetbare feiten: omzet, aantallen, kosten) omringd door dimensietabellen (de context: wie, wat, waar, wanneer).

De vier stappen van dimensioneel modelleren (de "4-step process"):

1. Kies het businessproces: welk businessproces modelleer je? Bijv. "verkooptransacties".
2. Bepaal de granulariteit: wat stelt één rij in de fact table voor? Bijv. "één verkooporderregel". Dit is de meest kritieke beslissing — wijzig granulariteit nooit achteraf.
3. Identificeer de dimensies: welke context-attributen beschrijven het feit? Datum, klant, product, winkel, medewerker.
4. Identificeer de feiten: welke meetbare grootheden wil je opslaan? Omzet, marge, kortingsbedrag, aantal verkochte stuks.

Het sterschema uitgelegd

Het sterschema is de meest voorkomende implementatie van dimensioneel modelleren. Een centrale fact table is omringd door dimensietabellen, waardoor het model er als een ster uitziet.

-- Fact table: verkooptransacties
CREATE TABLE fact_verkoop (
    verkoop_id        BIGINT       NOT NULL,
    datum_id          INT          NOT NULL,  -- FK naar dim_datum
    klant_id          INT          NOT NULL,  -- FK naar dim_klant
    product_id        INT          NOT NULL,  -- FK naar dim_product
    winkel_id         INT          NOT NULL,  -- FK naar dim_winkel
    omzet             DECIMAL(10,2),
    kostprijs         DECIMAL(10,2),
    marge             DECIMAL(10,2),
    aantal            INT,
    korting_pct       DECIMAL(5,2),
    PRIMARY KEY (verkoop_id)
);

-- Dimensietabel: datum
CREATE TABLE dim_datum (
    datum_id      INT          PRIMARY KEY,
    datum         DATE         NOT NULL,
    dag           INT,
    maand         INT,
    kwartaal      INT,
    jaar          INT,
    dag_naam      VARCHAR(20),
    maand_naam    VARCHAR(20),
    is_weekend    BOOLEAN,
    is_feestdag   BOOLEAN
);

-- Dimensietabel: product
CREATE TABLE dim_product (
    product_id        INT          PRIMARY KEY,
    product_naam      VARCHAR(200),
    subcategorie      VARCHAR(100),
    categorie         VARCHAR(100),
    merk              VARCHAR(100),
    leverancier       VARCHAR(100),
    ean_code          VARCHAR(20)
);

Het sterschema heeft grote voordelen voor BI-tools: de queries zijn eenvoudig (één JOIN van fact naar dimensie), de structuur is begrijpelijk voor business-gebruikers, en de query-performance is uitstekend omdat er minimale JOIN-paden zijn.

Snowflakeschema

Het snowflakeschema is een variatie op het sterschema waarbij dimensietabellen genormaliseerd zijn. In plaats van een platte dim_product tabel heb je aparte tabellen voor categorie, subcategorie en merk die via foreign keys verbonden zijn.

Voordelen: minder redundantie, kleinere opslag, consistentie bij hiërarchische wijzigingen.

Nadelen: complexere queries (meer JOINs), moeilijker te begrijpen voor business-gebruikers, slechter leesbare SQL.

In de praktijk wordt het sterschema aanbevolen voor de meeste situaties. Het snowflakeschema is geschikt als dimensietabellen extreem groot zijn (miljoenen rijen) en normalisatie echte opslagvoordelen oplevert.

Inmon: de Corporate Information Factory

Bill Inmon's benadering (de "Corporate Information Factory") verschilt fundamenteel van Kimball. Inmon stelt dat een data warehouse één enterprise-breed, volledig genormaliseerd (3NF) systeem moet zijn. Vanuit dit centrale DWH worden data marts gevoed — kleinere, subject-georiënteerde datasets voor specifieke afdelingen of businessprocessen.

De architectuur ziet er zo uit: bronsystemen → ETL → Enterprise Data Warehouse (3NF) → ETL → Data Marts (dimensioneel/sterschema) → BI-tools.

Voordelen van Inmon: één geïntegreerde bron van waarheid voor de hele organisatie, hoge datakwaliteit en consistentie, goed voor complexe organisaties met veel bronsystemen.

Nadelen van Inmon: complexer en duurder om te bouwen, langere time-to-first-value omdat je het volledige enterprise model moet ontwerpen voor je data marts kunt leveren, vereist diepgaande business-kennis in de beginfase.

Data Vault 2.0

Data Vault (ontwikkeld door Dan Linstedt) is een hybride benadering die de integratie-voordelen van Inmon combineert met een architectuur die beter schaalbaar is en sneller uitbreidbaar. Data Vault bestaat uit drie typen tabellen:

• Hubs: bevatten de business sleutels (unieke identifiers uit het bronsysteem). Bijv. hub_klant met klant_bk (business key).
• Links: leggen relaties vast tussen hubs. Bijv. lnk_klant_bestelling.
• Satellites: bevatten de beschrijvende attributen en historische wijzigingen. Bijv. sat_klant_details met naam, adres, etc. inclusief geldigheidsperiode.

Data Vault's grote voordeel is flexibiliteit: nieuwe bronnen en attributen kunnen toegevoegd worden zonder bestaande structuren te wijzigen. Dit maakt het geschikt voor agile development en organisaties met veel en veranderende bronnen. Het nadeel: query-complexiteit is hoog; rapporten worden gebouwd op top van een informatiemart (vergelijkbaar met Inmon's data marts) die vanuit de Data Vault gevuld wordt.

Kimball vs Inmon vs Data Vault

Slowly Changing Dimensions (SCD)

Een van de meest voorkomende uitdagingen in data warehouse design is het bijhouden van historische wijzigingen in dimensies. Als een klant van adres verandert of een product van categorie wisselt, wat doe je dan met de historische verkoopdata?

• SCD Type 1 – Overschrijven: de nieuwe waarde overschrijft de oude. Geen historische context bewaard. Geschikt voor correcties (typfout in naam) maar niet voor echte wijzigingen.
• SCD Type 2 – Nieuwe rij: bij elke wijziging wordt een nieuwe rij aangemaakt met een geldigheidsperiode (geldig_van, geldig_tot, is_huidig). Historische verkoopdata blijft gekoppeld aan de versie die gold op het moment van aankoop. De meest gebruikte aanpak.
• SCD Type 3 – Extra kolom: een aparte kolom bewaart de vorige waarde. Eenvoudig maar beperkt tot één wijzigingshistorie per attribuut.
• SCD Type 6 – Hybride: combinatie van Type 1, 2 en 3 voor maximale flexibiliteit.

Implementatie in de cloud

Moderne cloud data warehouses — Snowflake, Azure Synapse, BigQuery, Databricks SQL — bieden features die de implementatie van een goed data warehouse model eenvoudiger en performanter maken dan ooit:

• Columnaire opslag: alle moderne cloud DWH's slaan data kolomsgewijs op. Dit is ideaal voor analytische queries die vaak maar een paar kolommen van een brede tabel scannen.
• Automatische query-optimalisatie: Snowflake's query optimizer, BigQuery's slot-gebaseerde processing en Databricks' Photon-engine doen veel optimalisatiewerk automatisch.
• Scheiden van storage en compute: je betaalt voor opslag en verwerking apart. Dit maakt het economisch haalbaar om grote hoeveelheden historische data te bewaren.
• CLONE/TIME TRAVEL: Snowflake en Delta Lake bieden time travel — je kunt data raadplegen zoals die er gisteren of vorige week uitzag. Ideaal voor forensische analyses en herstel na fouten.

Een praktisch tip voor Snowflake en BigQuery: materializeer niet alles. Views zijn gratis in opslag en worden pas uitgevoerd bij aanroep. Gebruik materialized views of geaggregeerde tabellen alleen als de berekening zwaar en frequent is.

Conclusie

Data warehouse design is een vak dat balanceert tussen theoretische modellen en pragmatische implementatie. Voor de meeste organisaties biedt Kimball's dimensioneel modelleren de beste balans van snelheid, begrijpelijkheid en queryprestaties. Data Vault is een uitstekende aanvulling als je te maken hebt met veel bronsystemen en voortdurend veranderende requirements.

Ongeacht welke methodologie je kiest: investeer in goed ontwerp voor je begint te bouwen. Een slecht ontworpen data warehouse is duur om achteraf te repareren. Betrek business-gebruikers vroeg, stel granulariteit vast voor je begint te bouwen, en documenteer je keuzes. Het fundament dat je nu legt, bepaalt hoe gemakkelijk je het komende decennium data kunt toevoegen en analyses kunt uitvoeren.