Wat is Dimensioneel Modelleren?
Dimensioneel modelleren is een data modeling techniek specifiek ontworpen voor data warehouses en business intelligence. Het werd gepopulariseerd door Ralph Kimball en richt zich op het organiseren van data op een manier die query performance optimaliseert en begrijpelijk is voor business gebruikers.
Waarom Dimensioneel Modelleren?
Traditionele relationele modellen zijn geoptimaliseerd voor transaction processing (OLTP), maar niet voor analytics (OLAP). Dimensionele modellen draaien de normalisatieregels om voor betere leesperformance en gebruiksgemak:
- 10-100x snellere queries dan genormaliseerde modellen
- Intuïtief begrijpbaar voor business gebruikers
- Consistente business definities door conformed dimensions
- Schalbaar voor grote datasets
De Basis Bouwstenen
Fact Tables
Wat: Bevatten meetbare feiten
Voorbeelden: Verkoopbedragen, hoeveelheden, aantallen
Kenmerken: Numerieke values, additive measures
Sleutel: Foreign keys naar dimensions
Dimension Tables
Wat: Beschrijvende attributen
Voorbeelden: Klant, Product, Tijd, Locatie
Kenmerken: Tekstuele attributen, hiërarchieën
Sleutel: Surrogate keys voor historie
Keys & Granulariteit
Grain: Het laagste detailniveau
Surrogate Key: Kunstmatige PK (1,2,3...)
Natural Key: Business identifier (SKU123)
Composite Key: Combinatie van dimensions
Schema Types: Star vs Snowflake
| Aspect | Star Schema | Snowflake Schema | Recommendatie |
|---|---|---|---|
| Structuur | Eén centrale fact table met direct verbonden dimensions | Genormaliseerde dimensions met sub-dimensions | Star voor performance, Snowflake voor storage |
| Query Performance | ⭐⭐⭐⭐⭐ (Excellent) | ⭐⭐⭐ (Good) | Star schema wint altijd op performance |
| Storage Efficiency | ⭐⭐⭐ (Redundant data) | ⭐⭐⭐⭐⭐ (Efficient) | Snowflake bespaart storage |
| Onderhoud | ⭐⭐⭐⭐ (Eenvoudig) | ⭐⭐ (Complex) | Star schema is makkelijker te onderhouden |
| Ease of Use | ⭐⭐⭐⭐⭐ (Intuïtief) | ⭐⭐ (Complex voor gebruikers) | Business users prefereren star schema |
| Typische Use Case | BI reporting, dashboards, ad-hoc queries | Data science, compliance, zeer grote dimensions | 90% van de cases: star schema |
Voorbeeld: Retail Star Schema
-- Fact Table: Sales
CREATE TABLE fact_sales (
sales_key INT PRIMARY KEY,
date_key INT, -- FK naar dim_date
product_key INT, -- FK naar dim_product
store_key INT, -- FK naar dim_store
customer_key INT, -- FK naar dim_customer
quantity_sold INT,
sales_amount DECIMAL(10,2),
cost_amount DECIMAL(10,2),
profit_amount DECIMAL(10,2)
);
-- Dimension Table: Product
CREATE TABLE dim_product (
product_key INT PRIMARY KEY,
product_id VARCHAR(50), -- Natural key
product_name VARCHAR(255),
category VARCHAR(100),
subcategory VARCHAR(100),
brand VARCHAR(100),
unit_price DECIMAL(10,2),
start_date DATE,
end_date DATE,
is_current BOOLEAN
);
Het 4-Stappen Kimball Design Process
Stap 1: Selecteer het Business Process
1
Identificeer Kern Processen
- Verkooptransacties
- Voorraadniveaus
- Klantservice calls
- Marketing campagnes
- Supply chain bewegingen
2
Defineer de Grain
- Laagste niveau: Per verkoopregel, per dag
- Business vraag: "Wat is het laagste detail?"
- Voorbeeld grain: "Één rij per verkochte producteenheid per winkel per kassa transactie"
3
Documenteer Requirements
- Wie zijn de gebruikers?
- Welke vragen moeten beantwoord worden?
- Welke KPI's zijn belangrijk?
- Hoe vaak wordt data vernieuwd?
Stap 2: Declareer de Grain
1
Bepaal het Meest Gedetailleerde Niveau
- Transactioneel: Per transactieregel
- Periodiek: Dagelijks, wekelijks samengevat
- Snapshot: Momentopname (bv. dagelijkse voorraad)
2
Kies het Juiste Grain Type
| Grain Type | Voordelen | Nadelen | Gebruik Wanneer |
|---|---|---|---|
| Transaction Grain | Maximale flexibiliteit, alle details beschikbaar | Grote storage, complexe queries | Detailed analysis, drill-down nodig |
| Periodic Grain | Kleinere size, snellere queries | Details verloren, aggregatie vooraf nodig | Management reporting, KPI tracking |
| Snapshot Grain | Trend analysis, status over tijd | Data redundancy, storage intensive | Inventory, account balances |
Stap 3: Identificeer de Dimensions
1
Standaard Dimensions
- Tijd Dimension: Dag, week, maand, kwartaal, jaar
- Product Dimension: SKU, categorie, merk, prijs
- Klant Dimension: Demografie, segment, regio
- Locatie Dimension: Winkel, regio, land
- Medewerker Dimension: Afdeling, functie, manager
2
Geavanceerde Dimension Types
Slowly Changing Dimensions (SCD)
- Type 1: Overwrite (geen historie)
- Type 2: New row (volledige historie)
- Type 3: Add column (beperkte historie)
- Type 6: Hybrid (1+2+3)
Junk Dimensions
- Combineer kleine attributes
- Vermijd te veel foreign keys
- Voorbeeld: flags, indicators
- Verbeter performance
Conformed Dimensions
- Zelfde betekenis tussen marts
- Enterprise-wide consistentie
- Bouwsteen voor data warehouse
- Vermijd silo's
Stap 4: Identificeer de Facts
1
Fact Types & Additivity
| Fact Type | Additivity | Voorbeeld | Aggregatie Regel |
|---|---|---|---|
| Additive | ⭐⭐⭐⭐⭐ | Quantity sold, Sales amount | SUM over alle dimensions |
| Semi-Additive | ⭐⭐⭐ | Bank balance, Inventory level | SUM over sommige dimensions |
| Non-Additive | ⭐ | Unit price, Ratio, Percentage | AVG, MIN, MAX (geen SUM) |
| Factless Facts | N/A | Events, Attendance | COUNT alleen |
2
Fact Table Types
Transaction Facts
- Één rij per transactie
- Meest gedetailleerd
- Voor: sales, purchases
- Grain: laagst mogelijk
Periodic Snapshot
- Regelmatige momentopname
- Voor: inventory, balances
- Grain: per periode
- Vast formaat over tijd
Accumulating Snapshot
- Volgt proces door tijd
- Voor: order fulfillment
- Meerdere datum columns
- Wordt geüpdatet
Geavanceerde Dimensionele Patronen
Slowly Changing Dimensions (SCD) Implementatie
Type 1: Overwrite
-- Eenvoudig, geen historie
UPDATE dim_customer
SET city = 'Utrecht'
WHERE customer_id = 'CUST123';
Gebruik wanneer: Foutcorrecties, geen historie nodig
Type 2: New Row
-- Sluit huidige rij
UPDATE dim_customer
SET end_date = '2024-12-19',
is_current = FALSE
WHERE customer_key = 456;
-- Voeg nieuwe rij toe
INSERT INTO dim_customer
VALUES (789, 'CUST123', 'Amsterdam',
'2024-12-20', NULL, TRUE);
Gebruik wanneer: Volledige historie nodig
Type 3: Add Column
-- Voeg previous_value column toe
ALTER TABLE dim_customer
ADD previous_city VARCHAR(100);
-- Update beide columns
UPDATE dim_customer
SET previous_city = city,
city = 'Rotterdam'
WHERE customer_id = 'CUST123';
Gebruik wanneer: Beperkte historie genoeg
Bridge Tables voor Many-to-Many
Soms hebben dimensions een many-to-many relatie met facts. Bridge tables lossen dit op:
-- Many customers per account, many accounts per customer
CREATE TABLE bridge_customer_account (
customer_key INT,
account_key INT,
relationship_type VARCHAR(50),
start_date DATE,
end_date DATE,
weighting_factor DECIMAL(3,2) DEFAULT 1.0
);
-- Query met weighting factor
SELECT
c.customer_name,
SUM(f.balance * b.weighting_factor) AS weighted_balance
FROM fact_account_balance f
JOIN bridge_customer_account b ON f.account_key = b.account_key
JOIN dim_customer c ON b.customer_key = c.customer_key
GROUP BY c.customer_name;
Performance Optimalisatie Tips
Indexing Strategie
- Fact tables: Clustered index op date key
- Dimension tables: Index op surrogate key
- Foreign keys: Altijd geïndexeerd
- Bitmaps: Voor low-cardinality columns
- Columnstore: Voor moderne data warehouses
Partitionering
- Range partitioning: Op datum (maand/kwartaal)
- List partitioning: Op regio of categorie
- Hash partitioning: Voor gelijke verdeling
- Partition pruning: Automatische performance winst
- Consideratie: Max 100-200 partities
Query Optimalisatie
- Filter early: WHERE clause op dimensions
- Aggregate late: GROUP BY als laatste
- Avoid SELECT *: Specificeer alleen nodig columns
- Use surrogate keys: Niet natural keys in joins
- Materialized views: Voor veelgebruikte aggregaties
Performance Voorbeeld: Retail Data Mart
Scenario: 100 miljoen verkoopregels, 5 jaar historie, 50+ gebruikers gelijktijdige queries.
| Optimalisatie | Voor Implementatie | Na Implementatie | Performance Winst |
|---|---|---|---|
| Clustered Columnstore | 45 seconden | 8 seconden | 82% sneller |
| Partitionering (maand) | 30 seconden | 5 seconden | 83% sneller |
| Appropriate Indexing | 25 seconden | 3 seconden | 88% sneller |
| Materialized View | 15 seconden | 0.5 seconden | 97% sneller |
Dimensioneel Modelleren in Moderne Data Platforms
Platform-specifieke Overwegingen
1
Snowflake
- Micro-partitions: Automatische optimalisatie
- Clustering keys: Vergelijkbaar met indexing
- Zero-copy cloning: Snelle dev/test environments
- Best practice: Gebruik tijd-travel voor SCD Type 2
2
Databricks Delta Lake
- Delta format: ACID transactions op data lakes
- Z-ordering: Optimaliseert data layout
- Time travel: Ingebouwd historie management
- Best practice: Gebruik Delta Live Tables voor ETL
3
Microsoft Fabric
- OneLake: Unified storage voor alle data
- Direct Lake mode: Power BI op raw data
- Semantic model: Ingebouwd dimensional model
- Best practice: Gebruik Fabric voor end-to-end integratie
Best Practices & Veelgemaakte Fouten
Do's
- Begin met conformed dimensions
- Gebruik surrogate keys altijd
- Defineer grain duidelijk vooraf
- Test met business users vroeg
- Documenteer business definitions
- Plan voor historie (SCD strategie)
- Monitor query performance
Don'ts
- Niet normaliseren zoals OLTP
- Geen intelligent keys gebruiken
- Niet te veel dimensions in één fact
- Geen business logic in ETL verbergen
- Niet performance voor design opofferen
- Geen onnodige complexiteit
- Niet zonder requirements beginnen
Tooling Recommendations
- Design: Erwin, ER/Studio, SQLDBM
- Documentatie: Data Dictionary tools
- Version control: Git voor data models
- Testing: dbt voor data quality
- Orchestration: Apache Airflow, Azure Data Factory
- Monitoring: Query performance dashboards
Conclusie & Volgende Stappen
Key Takeaways
Voor Business
- Dimensionele modellen zijn gebruiksvriendelijk
- Snellere time-to-insight
- Consistente business definities
- Betere data governance
Voor Technische Teams
- Betere query performance
- Eenvoudigere ETL processen
- Schalbaar design
- Herbruikbare componenten
Voor Organisaties
- Single source of truth
- Lagere TCO voor data platform
- Hogere adoption rates
- Betere data-driven beslissingen
Implementatie Roadmap
1
Week 1-2: Requirements & Design
- Identificeer belangrijkste business process
- Interview stakeholders en gebruikers
- Defineer conformed dimensions
- Creëer conceptueel model
2
Week 3-4: Development & Testing
- Bouw dimensions en facts
- Implementeer ETL pipelines
- Test met sample queries
- Valideer met business users
3
Week 5-6: Deployment & Optimization
- Deploy naar production
- Monitor query performance
- Optimaliseer indexes/partitions
- Documenteer en train gebruikers
Eindadvies: Begin klein met één business process, leer van de ervaring, en scale dan op. Dimensioneel modelleren is zowel een kunst als een wetenschap - de balans tussen technische optimalisatie en business bruikbaarheid is essentieel.
Data Modeling Experts Nodig?
Vind ervaren Data Modelers en Data Architects voor je data warehouse project
