Het probleem: Power BI direct op bronsystemen

In de beginfase van veel Power BI-trajecten wordt de kortste weg gekozen: Power BI Desktop wordt direct verbonden met de brondatabase, de Exact Online API of een set Excel-bestanden. Dit werkt voor prototypes, maar in productie leidt het tot een aantal fundamentele problemen:

  • Trage queries op de productiedatabase: Analytische queries over grote transactietabellen zijn zwaar. Ze belassen de OLTP-database die ook de dagelijkse operaties ondersteunt. Dat leidt tot wederzijdse prestatieproblemen.
  • Versiesplit: Financiën gebruikt een andere exportdatum dan Operations, en HR heeft weer zijn eigen Excel. Iedereen trekt data op een ander moment uit het bronsysteem — met afwijkende cijfers als gevolg.
  • Geen historische data: De meeste bronsystemen bewaren alleen de huidige staat van records. Als een medewerker van team wisselt of een product wordt hernoemd, is de historische context verdwenen.
  • Schaalproblemen: Naarmate het aantal rapporten groeit, neemt de belasting op het bronsysteem toe. Elke nieuwe Power BI-gebruiker die een rapport opent genereert extra queries.

Een datawarehouse is de architectuuroplossing voor al deze problemen. Het is een aparte database, specifiek ontworpen voor analytische workloads, die data samenvoegt vanuit meerdere bronnen en opslaat in een voor rapportage geoptimaliseerd formaat.

Wat is een datawarehouse?

Een datawarehouse (DWH) is een centrale opslaag voor geïntegreerde, historische, thematisch georiënteerde data die is bedoeld voor analysetoepassing. De klassieke definitie van Bill Inmon beschrijft vier kenmerken: subject-oriented (georganiseerd naar bedrijfsdomein), integrated (meerdere bronnen samengevoegd), non-volatile (data wordt niet verwijderd maar toegevoegd), en time-variant (historische snapshots worden bewaard).

In de praktijk van 2024 ziet een modern datawarehouse er voor middelgrote organisaties zo uit: een Azure SQL Database (of Azure Synapse voor grotere organisaties) gevuld via een Python ETL-pipeline, gestructureerd volgens de Medallion Architecture, en verbonden met Power BI via Import mode.

Medallion Architecture: Bronze, Silver, Gold

De Medallion Architecture — gepopulariseerd door Databricks maar breed toegepast in Azure SQL-omgevingen — verdeelt het datawarehouse in drie lagen met toenemende datakwaliteit:

Laag 1
Bronze
Ruwe data zoals ontvangen van de bron. Geen transformaties. Volledig bewaard als audit trail. Ideaal voor reprocessing bij fouten.
Laag 2
Silver
Gestaged en gevalideerde data. Datatypes gecorrigeerd, lege waarden gevuld, duplicaten verwijderd. Klaar voor verdere transformatie.
Laag 3
Gold
Rapportage-gereed data. Star Schema met feittabellen en dimensies. Geoptimaliseerd voor snelle DAX-queries in Power BI.

In Azure SQL implementeer je dit via aparte schema's: bronze, silver, gold. De ETL-pipeline laadt naar Bronze, stored procedures of SQL-transformaties promoveren data naar Silver en Gold. Power BI verbindt uitsluitend met het Gold-schema.

Eén versie van de waarheid

Het meest gehoorde argument voor een datawarehouse is "één versie van de waarheid" — en het is terecht. In organisaties zonder datawarehouse zien we regelmatig het volgende: de CFO heeft andere omzetcijfers dan de Sales Manager, en beiden zijn overtuigd dat hun cijfers kloppen. De discussie in de vergadering gaat over de cijfers, niet over de business.

Dit probleem ontstaat omdat financiën en sales op verschillende momenten data exporteren, of verschillende filters hanteren, of verschillende definities gebruiken voor "omzet" (inclusief BTW? Ex BTW? Inclusief creditnota's?). In een datawarehouse worden al deze definities centraal vastgelegd in de transformatielaag en het datamodel. Iedereen trekt uit dezelfde bron — de Gold-laag — op hetzelfde moment. De discussie over cijfers verdwijnt.

Datakwaliteit en validatie

Een datawarehouse is niet alleen een opslaglaag — het is ook een kwaliteitslaag. In de Silver-laag implementeer je validatieregels die garanderen dat de data die Power BI ziet compleet en correct is:

  • Volledigheidscheck: Zijn alle dagboeken aanwezig? Klopt het aantal transacties met de verwachting?
  • Referentiële integriteit: Verwijst elke factuurlijn naar een bestaande klant in de dimensietabel?
  • Saldo-validatie: Klopt het boekhoudkundig saldo (debiet = crediet)?
  • Outlier-detectie: Zijn er transacties met onverwacht hoge of negatieve waarden?

Als een validatiecheck faalt, wordt de data niet gepromoveerd naar de Gold-laag. De dag-refresh faalt en er wordt een alert gestuurd. Power BI blijft draaien op de vorige, correcte dataset totdat het probleem is opgelost. Dit is veel beter dan een Power BI-dashboard dat stilzwijgend verkeerde cijfers toont.

Historische data: terug in de tijd kijken

Een van de krachtigste features van een datawarehouse is de mogelijkheid om historische snapshots te bewaren. Dit wordt geïmplementeerd via Slowly Changing Dimensions (SCD) Type 2: bij een wijziging van een dimensierecord (bijv. een medewerker wisselt van afdeling) wordt niet de bestaande rij overschreven, maar wordt een nieuwe rij toegevoegd met een geldigheidsperiode.

Dit maakt analyses mogelijk als: "Hoeveel omzet heeft klant X gegenereerd in de periode dat ze in segment 'Groot' zaten?" of "Wat was de productiviteit van team A in 2022 voordat de reorganisatie plaatsvond?" Zonder SCD Type 2 in het datawarehouse zijn dit soort vragen onbeantwoordbaar.

Performance: waarom een datawarehouse sneller is

De Gold-laag van het datawarehouse is geoptimaliseerd voor analytische queries, niet voor transactieverwerking. Dit uit zich in concrete ontwerpkeuzes:

  • Star Schema: Één centrale feittabel met snelle joins naar compacte dimensietabellen. Geen genormaliseerde structuur met tientallen joins zoals in een OLTP-database.
  • Columnstore-indexen: Azure SQL ondersteunt clustered columnstore indexes die data per kolom opslaan in plaats van per rij. Aggregaties over grote datasets zijn hiermee 10–100x sneller.
  • Pre-aggregaties: Complexe berekeningen (rolling averages, running totals) kunnen als berekende kolommen in de Gold-laag worden opgeslagen zodat Power BI ze niet hoeft te herberekenen.
  • Geen concurrentie met OLTP: De datawarehouse-database heeft geen ander gebruik dan rapportage. Zware analytische queries verstoren geen operationele processen.

Schaalbaarheid: van één bron naar tien

Een van de grootste voordelen van een datawarehouse-architectuur wordt pas duidelijk wanneer de organisatie groeit. Start je met één bronsysteem (bijv. Exact Online), dan is het verleidelijk om direct te koppelen. Maar zodra je een tweede bron toevoegt (AFAS voor HRM) en een derde (WiseTech LSP voor transport), wordt de combinatie van meerdere directe koppelingen in Power BI onbeheersbaar.

In het datawarehouse worden alle bronnen naar dezelfde Gold-laag getransformeerd. Een medewerker uit AFAS wordt gekoppeld aan een medewerker in OnsDB via een unieke personeelsidentifier. Een factuur uit Exact Online wordt gekoppeld aan een zending in WiseTech LSP via het ordernummer. Power BI ziet een consistent, geïntegreerd datamodel — ongeacht hoeveel bronnen er achter zitten.

Klaar voor een professioneel datawarehouse?

Argus BI bouwt Azure SQL datawarehouses voor transport- en zorgorganisaties. Van intake tot eerste rapportages in 4–8 weken.

Laat je datawarehouse bouwen

Veelgestelde vragen

Is een datawarehouse ook geschikt voor kleine organisaties (< 50 medewerkers)?

Ja. Een datawarehouse hoeft niet groot of complex te zijn. Voor een organisatie van 30–50 medewerkers volstaat een eenvoudig Azure SQL schema met een Bronze- en Gold-laag, gevuld door een enkelvoudige Python ETL-pipeline. De initiële investering is beperkt, en de terugverdientijd via bespaarde rapportage-uren is meestal kort.

Hoe lang duurt het bouwen van een datawarehouse?

Een eerste versie met één of twee bronkoppelingen, een Medallion-structuur en een Power BI-rapportagelaag is in 4–8 weken operationeel. Complexere omgevingen met meerdere bronsystemen, geavanceerde validaties en historische datatransitie kosten 2–4 maanden. Argus BI levert altijd een werkend MVP binnen de eerste 4 weken.

Wat is het verschil tussen een datawarehouse en een data lake?

Een datawarehouse slaat gestructureerde, gemodelleerde data op die klaar is voor rapportage (SQL-tabellen, strak schema). Een data lake slaat ruwe data op in elk formaat zonder vooraf vastgelegd schema. Voor Power BI rapportages is de Gold-laag van een Medallion-architectuur (datawarehouse-stijl) de meest geschikte aanpak. Een data lake is zinvol voor machine learning en exploratief onderzoek op grote datavolumes.

Kan ik bestaande Power BI-rapporten koppelen aan een nieuw datawarehouse?

Ja. Argus BI migreert bestaande Power BI-rapporten naar een nieuwe Azure SQL-bron als onderdeel van het datawarehouse-project. We stemmen de kolomnamen en datatypen af op de bestaande Power BI-modellen zodat rapporten minimaal hoeven te worden aangepast. Bestaande DAX-formules blijven in de meeste gevallen ongewijzigd.