De vraag "hoe ontwerp je een datawarehouse?" heeft drie klassieke antwoorden, elk met een eigen filosofie en sterke aanhang in de community. Het is geen religieuze keuze — moderne projecten mengen vaak elementen — maar je moet ze kennen om te begrijpen waarom je iets doet zoals je het doet.

1. Kimball — dimensionele bottom-up aanpak

Ralph Kimball publiceerde in 1996 The Data Warehouse Toolkit, dat tot op de dag van vandaag de facto bijbel is voor BI-developers. Zijn aanpak:

• Bottom-up: bouw eerst data marts per business proces (sales, inventory, finance), die later samen het enterprise warehouse vormen.
• Dimensioneel modelleren: star schemas met fact tables (metingen) en dimension tables (context).
• Conformed dimensions: dezelfde klantdimensie wordt hergebruikt in elke data mart, zodat marts onderling vergelijkbaar zijn.
• Bus matrix: een tabel met business processen op de rij-as en dimensies op de kolom-as, die laat zien welke dimensies waar gebruikt worden.

Voorbeeld van een minimaal Kimball star schema:

-- Fact table: één rij per verkoopregel
CREATE TABLE fact_sales (
  sales_key       BIGINT IDENTITY,
  date_key        INT,         -- FK naar dim_date
  customer_key    INT,         -- FK naar dim_customer
  product_key     INT,         -- FK naar dim_product
  store_key       INT,         -- FK naar dim_store
  quantity        INT,
  unit_price      DECIMAL(10,2),
  revenue         DECIMAL(12,2),
  load_timestamp  TIMESTAMP
);

-- Dimension table: contextuele attributen, gedenormaliseerd
CREATE TABLE dim_customer (
  customer_key    INT IDENTITY PRIMARY KEY,    -- surrogate key
  customer_id     VARCHAR(50),                 -- business key
  name            VARCHAR(200),
  segment         VARCHAR(50),
  country         VARCHAR(50),
  city            VARCHAR(100),
  valid_from      DATE,
  valid_to        DATE,
  is_current      BOOLEAN
);

De surrogate keys (customer_key) ontkoppelen het warehouse van de bron-IDs. Dat lijkt overdreven, maar het maakt SCD Type 2-historie mogelijk en beschermt je tegen wijzigingen aan de business key.

Slowly Changing Dimensions in Kimball

Een dimensie is zelden statisch — klanten verhuizen, productcategorieën worden hernoemd, salesgebieden gereorganiseerd. Kimball heeft hiervoor zeven SCD-types gedefinieerd, waarvan deze drie het meest gebruikt worden:

• SCD Type 1 — overschrijven: oude waarde wordt vervangen, geen historie. Geschikt voor correcties van typefouten of velden waar historie niet relevant is.
• SCD Type 2 — historische rijen: bij elke wijziging een nieuwe rij met valid_from, valid_to en is_current. De gouden standaard voor analyses op het juiste moment in de tijd.
• SCD Type 3 — vorige waarde naast huidige: voeg een kolom previous_segment toe naast segment. Compact, maar onthoudt slechts één wijziging terug.

SCD Type 2 is in 90% van de gevallen wat je wilt voor business-kritische dimensies. Type 1 voor velden waar niemand naar terugkijkt, Type 3 voor zeldzame "voor en na"-vergelijkingen.

2. Inmon — top-down enterprise warehouse

Bill Inmon ziet het anders: bouw eerst een centraal, genormaliseerd Enterprise Data Warehouse in 3NF, en lever data marts daaruit af. Dat staat bekend als de Corporate Information Factory (CIF).

• Top-down: eerst een ondernemingsbreed model, dan pas use-case-specifieke data marts.
• 3NF in de kern: minimale redundantie, hoge data integriteit.
• Single version of the truth: één centrale waarheid, marts zijn afgeleiden.

Voorbeeld 3NF-fragment in Inmon-stijl:

CREATE TABLE customer (
  customer_id   INT PRIMARY KEY,
  name          VARCHAR(200),
  segment_id    INT REFERENCES segment(segment_id),
  address_id    INT REFERENCES address(address_id),
  created_at    TIMESTAMP
);

CREATE TABLE address (
  address_id    INT PRIMARY KEY,
  street        VARCHAR(200),
  city_id       INT REFERENCES city(city_id),
  postal_code   VARCHAR(10)
);

CREATE TABLE city (
  city_id       INT PRIMARY KEY,
  city_name     VARCHAR(100),
  country_id    INT REFERENCES country(country_id)
);

Voor analyses bouw je vervolgens dimensionele marts op basis van dit centrale model. Het kost meer initieel, maar het schaalt voor grote organisaties met veel bronsystemen.

3. Data Vault — agility en auditbaarheid

Dan Linstedt's Data Vault (DV2.0) is de jongste van de drie. Het probeert het schaalvoordeel van Inmon te combineren met de agility van Kimball, en voegt sterke auditbaarheid toe — bruikbaar in regulated industries (finance, pharma, insurance).

Data Vault kent drie soorten tabellen:

• Hubs — bevatten alleen business keys + load metadata. Eén hub per kernentiteit (klant, product, order).
• Links — many-to-many relaties tussen hubs.
• Satellites — alle beschrijvende attributen + historie, gehangen aan een hub of link.

-- Hub: alleen business key + metadata
CREATE TABLE hub_customer (
  customer_hk     CHAR(32),         -- hash key
  customer_id     VARCHAR(50),      -- business key
  load_dts        TIMESTAMP,
  record_source   VARCHAR(50)
);

-- Satellite: beschrijvende data, historisch
CREATE TABLE sat_customer_details (
  customer_hk     CHAR(32),
  load_dts        TIMESTAMP,
  hash_diff       CHAR(32),         -- detecteert wijzigingen
  name            VARCHAR(200),
  segment         VARCHAR(50),
  country         VARCHAR(50),
  record_source   VARCHAR(50),
  PRIMARY KEY (customer_hk, load_dts)
);

-- Link: relatie tussen hubs
CREATE TABLE link_customer_order (
  link_hk         CHAR(32),
  customer_hk     CHAR(32),
  order_hk        CHAR(32),
  load_dts        TIMESTAMP,
  record_source   VARCHAR(50)
);

De volledige historie en herkomst (record_source, load_dts) zit ingebouwd in elke tabel — handig voor audits en GDPR. Nadeel: zonder een goede automatiseringslaag (bijvoorbeeld dbtvault, Wherescape, Vaultspeed) wordt Data Vault snel een berg boilerplate-code.

Hash keys en hash diff — twee patronen die je móet kennen

Het hashen van business keys (bijvoorbeeld MD5 of SHA-256) doet drie dingen: het maakt parallel laden mogelijk (geen lookup nodig), het maakt bron-overschrijdende joins triviaal (zelfde input → zelfde hash), en het levert een vaste sleutellengte op. De hash_diff in satellites is een hash over alle beschrijvende attributen — als hij gelijk is aan de vorige rij, wordt geen nieuwe rij toegevoegd. Zo voorkom je duplicaten zonder dure rij-vergelijkingen.

Vergelijking

Aspect	Kimball	Inmon	Data Vault
Aanpak	Bottom-up	Top-down	Modulair / agile
Modelvorm	Star schema	3NF	Hubs / Links / Satellites
Time-to-value	Weken	Maanden tot jaren	Weken (met automatisering)
Schaalbaarheid	Goed	Uitstekend	Uitstekend
Flexibiliteit bij verandering	Matig	Lastig	Hoog (additief)
Auditbaarheid	Beperkt	Beperkt	Ingebouwd
Leercurve	Laag	Hoog	Hoog
BI-tool friendly	Direct	Via marts	Via marts (Information Mart Layer)

De medallion architecture (modern)

Sinds de opkomst van het lakehouse (Delta Lake, Iceberg) is de medallion architecture populair geworden — vooral in Databricks en Microsoft Fabric:

• Bronze — ruwe ingest van bronsystemen, immutable, append-only.
• Silver — opgeschoond, geharmoniseerd, deduplicaten verwijderd. Vaak in een Data Vault- of 3NF-stijl.
• Gold — business-ready dimensionele modellen, meestal Kimball-stijl, voor BI en ML.

De medallion-laagjes komen overeen met staging / integratie / presentatie uit hoofdstuk 1, maar dan op een lakehouse-platform. Dezelfde principes, modernere tooling.

Hoe kies je het juiste patroon?

Een eenvoudige beslissingsboom:

1. Klein team, één bedrijfstak, snel resultaat nodig? → Kimball.
2. Grote enterprise met tientallen bronnen, governance kritisch? → Inmon of Data Vault.
3. Strikte audittrail nodig (financieel, medisch, verzekering)? → Data Vault.
4. Lakehouse-platform met machine learning naast BI? → Medallion (Bronze/Silver/Gold).
5. Mengsel? → Hybride, met dimensionele goldlaag op een Data Vault-silverlaag.

Praktijkscenario: een hybride aanpak in een retail-omgeving

Een Nederlandse retailer met 12 webshops in vijf landen had twee problemen: marketing wilde elke week een nieuwe campagne-rapportage, finance vroeg een GDPR-proof audittrail op klantniveau. Een pure Kimball-aanpak loste het tweede niet op, een pure Data Vault-aanpak was te traag voor het eerste. De gekozen architectuur:

• Bronze (Delta Lake) — alle CDC-streams van Kafka, één bestand per source per uur, append-only.
• Silver (Data Vault 2.0) — hubs voor klant, order, product, store; satellites met SCD2-historie. dbtvault genereerde 80% van de DDL en transformaties.
• Gold (Kimball star schemas) — fact_sales, fact_inventory, dim_customer (Type 2), dim_product (Type 1 voor naamswijzigingen). Power BI rapporten draaiden direct op gold.

Resultaat: marketing kreeg dashboards binnen een sprint, finance kreeg een herleidbare audittrail per record, en nieuwe bronsystemen (een nieuwe webshop, een logistieke partner) konden in dagen worden toegevoegd zonder bestaande modellen te raken. De prijs: drie ETL-lagen onderhouden in plaats van één — maar elk laag had een duidelijk doel.

Anti-patterns om te vermijden

• "Sterk-hub-schema" — een fact-tabel die direct met productie-IDs joint zonder surrogate keys. Bij elke schema-change in de bron breekt je warehouse.
• "One Big Table" — één enorme gedenormaliseerde tabel waar alles in zit. Werkt voor demo's, breekt onder schaal.
• "Spaghettistraal" — geen integratielaag, marts trekken rechtstreeks uit verschillende bronnen. Definities lopen uiteen, garbagedata.
• "Te diep genormaliseerd in goldlaag" — eindgebruikers in BI-tools willen wide tables, geen 12-way joins.

Veelgestelde vragen