Waarom deze discussie juist nu zo vaak terugkomt

De term Lakehouse wordt vaak gelezen als: “datawarehouse modeling is verleden tijd”. In de praktijk is het meer: je verschuift de opslag en een deel van de transformaties naar open formats en schaalbare compute, terwijl BI-consumptie nog steeds structuur nodig heeft. De Lakehouse helpt je om data breed beschikbaar te maken, maar maakt niet automatisch je data begrijpelijk of herbruikbaar.

Fabric versterkt dat gevoel omdat het platform de route van ruwe data naar rapportage heel kort maakt. Je kunt in een Lakehouse landen, met notebooks transformeren en vanuit dezelfde omgeving een Power BI semantic model maken. Juist door die snelheid ontstaat de verleiding om de “curated” laag over te slaan en direct een brede tabel aan te bieden.

Maar zodra meerdere teams dezelfde data consumeren, krijg je vragen die geen opslagvraag zijn maar een semantiekvraag. Wat is precies “omzet”, welke datum telt, en hoe filtert een regio door op een fact? Dat zijn precies de vragen die dimensioneel modelleren oplost door definities en relaties expliciet te maken.

Microsoft Fabric vs losse Azure diensten: wat verandert er echt voor je modelleerkeuzes?

Microsoft Fabric is in de kern een geïntegreerd SaaS-platform waar storage, data-engineering, integratie en BI dichter op elkaar zitten. In de klassieke “losse Azure” aanpak combineer je vaak ADLS Gen2, Azure Data Factory, Synapse of Databricks en Power BI met meer losse governance en meer integratiewerk. OneLake wordt daarbij vaak gezien als een SaaS-abstractie bovenop ADLS Gen2-concepten, maar dan met Fabric-native integratie en beheer.

Die integratie is een voordeel, omdat je minder tijd kwijt bent aan plumbing en meer aan standaardisatie. Data Factory in Fabric is bijvoorbeeld nadrukkelijk gepositioneerd als dicht bij Azure Data Factory, met veel overlap in activiteiten, maar ingebed in het Fabric-ecosysteem. Een team kan daardoor sneller een end-to-end flow bouwen die van landing tot consumptie consistent blijft.

Alleen: integratie is geen vervanging voor informatie-architectuur. Je kunt met Fabric sneller op weg, maar als je in de curated laag geen afspraken maakt over dimensies, keys en definities, ga je die discussie later alsnog voeren in DAX, in rapporten of in “duplicaat datasets”. Het platform maakt het makkelijker om het goed te doen, maar het doet het niet automatisch voor je.

De Gold laag in het Lakehouse tijdperk is een productlaag, geen dump

De medallion-architectuur binnen Fabric wordt expliciet gebruikt als patroon om data van ruw naar business-ready te brengen. Het doel van die lagen is niet alleen datakwaliteit, maar ook een duidelijke scheiding tussen raw, refined en curated consumptie. Fabric beschrijft dit patroon als een manier om het ontwerp te implementeren en te laten landen in je platformkeuzes.

De Gold laag is daarmee de plek waar je data “verpakt” als iets dat een businessgebruiker, BI-consultant of analyst consistent kan gebruiken. Dat betekent: stabiele definities, herbruikbare dimensies, en feiten die aansluiten op KPI’s en vragen. Je maakt hier keuzes die je downstream complexiteit verlagen, omdat iedereen op dezelfde concepten bouwt.

In Fabric zie je dat terug in hoe semantic models worden omschreven: het gaat om een businessvriendelijke laag met metrics en terminologie, en die is typisch star schema georiënteerd. Als je Gold laag geen duidelijke semantiek heeft, ga je semantic models per rapport “op maat” maken, en dat is precies hoe wildgroei ontstaat.

Dimensioneel modelleren in de Gold laag blijft je beste stuurmiddel

Dimensioneel modelleren is niet “normaliseren of denormaliseren”, maar het modelleren van de business in feiten en dimensies. In Fabric Warehouse-documentatie wordt star schema expliciet als aanbevolen ontwerpbenadering neergezet, met feitentabellen en dimensietabellen die je analysebehoefte representeren. Daarmee maak je je model leesbaar: feiten zijn meetbaar, dimensies zijn beschrijvend, en de relaties vertellen hoe je mag filteren en groeperen.

Het grote voordeel in een Lakehouse-context is dat je de ruwe, brede en soms rommelige werkelijkheid niet doorschuift naar BI. Je houdt die complexiteit in Bronze en Silver, en presenteert in Gold een versie die aansluit op hoe mensen vragen stellen. Dat maakt je dataproduct robuuster, ook als bronnen veranderen of uitbreiden.

Praktisch betekent dit vaak: een beperkt aantal fact tables per domein, gedeelde conformed dimensions (zoals datum, klant, product) en een sleutelstrategie die joinen snel en betrouwbaar maakt. Je bouwt hiermee niet alleen rapporten, maar een herbruikbaar analytisch fundament.

Star schema’s in Microsoft Fabric vs brede flat tables: waarom “makkelijk” vaak duur wordt

Brede flat tables zijn populair omdat ze op dag één weinig denkwerk lijken te vragen. Alles staat in één tabel, dus je hoeft geen relaties te leggen en je kunt snel een visual bouwen. Het probleem is dat je daarmee semantiek verstopt in kolomnamen, duplicatie introduceert en definities impliciet maakt.

Power BI guidance is juist zo sterk op stermodellen omdat ze performance en usability verbeteren. In een flat table herhaal je dimensie-attributen op factniveau, wat je model groter maakt en vaak minder efficiënt in opslag en compressie werkt. Daarnaast maakt het je DAX-werk lastiger, omdat je minder natuurlijke plekken hebt voor filters, rollups en consistente measures.

Er is ook een teamdynamiek-probleem: flat tables nodigen uit tot “even een kolom erbij” voor één rapport. Op termijn krijg je één monster-tabel die niemand durft aan te raken, en ondertussen bouwt elk team toch weer eigen varianten omdat de definitie niet meer te vertrouwen is.

Wat dit doet met Power BI performance en gebruiksgemak, ook met Direct Lake

Power BI is gebouwd rondom een model met relaties, filtercontext en herbruikbare measures. De guidance over star schema legt precies uit waarom dit ontwerp helpt bij performance en bij een voorspelbare gebruikerservaring. Een stermodel reduceert ambiguity, houdt filterroutes simpel en maakt het makkelijker om één semantic model centraal te delen.

Ook in Fabric-context is dat relevant, omdat Fabric semantic models typisch als star schema worden gepositioneerd. Direct Lake verandert vooral hoe data wordt gelezen, maar niet het feit dat je modelstructuur bepaalt hoe makkelijk je filters, slicers en DAX werken. In recente Fabric-richtlijnen rond Direct Lake wordt zelfs expliciet aangeraden om het simpel te houden met een star schema-achtige opzet en complexe relationship patronen te vermijden.

Gebruiksgemak is vaak de stille killer: een goed stermodel zorgt dat businessgebruikers intuïtief kunnen slicen op klant, product en tijd zonder dat je rapporten vol “workarounds” zitten. En voor BI-consultants betekent het: minder tijd aan brandjes, meer tijd aan echte inzichten en adoptie.

Hoe je dit praktisch organiseert in Fabric zonder extra frictie

De meest werkbare aanpak is: Bronze en Silver blijven Lakehouse-gericht en houden ruimte voor data-engineering realiteit. De Gold laag wordt bewust ingericht als consumptielaag, waar je kiest voor dimensioneel modelleren en stabiele dataproducten. Fabric ondersteunt meerdere werkstijlen, maar het doel blijft hetzelfde: een curated laag die BI en analytics direct kan gebruiken.

Vervolgens maak je een semantic model dat aansluit op die Gold laag en dat je als herbruikbare “single source of truth” kunt delen. Microsoft beschrijft semantic models als de plek voor businessvriendelijke terminologie en analyse, en dat past precies bij het idee dat je niet elk rapport zijn eigen mini-model geeft. Als je dit goed neerzet, kun je rapporten bouwen als dunne lagen bovenop hetzelfde fundament.

Tot slot helpt Fabric je om de “losse Azure puzzel” te verminderen, omdat integratie en data-to-BI flow meer ingebouwd is. Maar de win zit pas echt in het moment dat je Gold laag als product behandelt en star schema’s als standaard inzet, in plaats van als “extra stap”.

De brug naar je MOFU: van discussie naar herhaalbaar stappenplan

Als je dit artikel tot hier gevolgd hebt, heb je waarschijnlijk al munitie om de “flat table reflex” te doorbreken. Toch blijft de praktijk weerbarstig, omdat iedereen net een andere bron, domein en rapportvraag heeft. Daarom is de volgende stap niet nóg een mening, maar een herhaalbaar patroon dat je elke keer opnieuw kunt toepassen.

De meest effectieve manier om dit te operationaliseren is een compacte cheatsheet die je door de keuzes loodst: wat hoort in Silver, wat modelleer je in Gold, hoe kies je fact-grain, welke dimensies maak je conformed, en hoe richt je je semantic model in zodat Power BI logisch blijft. Daarmee verklein je het risico dat teams op eigen houtje een “snel model” maken dat later schuld wordt.

Precies daar hoort een MOFU-download thuis: niet als marketingtruc, maar als versneller om van inzicht naar consistente uitvoering te gaan. En als je team daarna verder wil, is een gerichte Microsoft Fabric training de logische stap om dit ook echt in je eigen omgeving werkend te krijgen.

Samenvatting

Star schema’s zijn niet “ouderwets datawarehouse”, maar een bewezen manier om semantiek en analysebaarheid te borgen. Microsoft positioneert zowel Fabric Warehouse als Fabric semantic models sterk richting een star schema-benadering, omdat dit performance en usability in Power BI verbetert. In een Lakehouse-architectuur blijft de Gold laag de plek waar je van data naar dataproduct gaat, en dimensioneel modelleren is daarbij het stuurmiddel.

Brede flat tables lijken snel, maar leiden vaak tot grotere modellen, onduidelijke definities en meer DAX-complexiteit. Ook met Direct Lake blijft een simpele, stervormige modelstructuur een sterke default. Fabric vs losse Azure diensten gaat vooral over integratie en governance, maar je grootste winst zit nog steeds in het bewust ontwerpen van je consumptielaag.