De 9 meest gemaakte datamodel-fouten in Power BI (en hoe een audit ze blootlegt)

De meeste Power BI-modellen zijn traag en onbetrouwbaar door systematische fouten. Deze fouten zitten zo diep in de architectuur dat gebruikers ze als 'normaal' accepteren. Een professionele datamodel-audit legt deze patronen binnen minuten bloot.

In vijftien jaar datamodellering heb ik duizenden modellen gezien. Dezelfde negen fouten komen steeds terug — met voorspelbare impact op performance, onderhoud en accuratesse. Dit artikel legt deze patronen bloot en toont hoe je ze systematisch opspoort.

Fout 1: Bidirectionele relaties als standaardoplossing

Het patroon: Teams maken standaard bidirectionele relaties tussen alle tabellen omdat "dan werkt alles altijd". Filters gaan beide kanten op, waardoor elke visualisatie correct lijkt te functioneren zonder technische kennis.

Waarom mensen dit doen: Het is de snelste weg naar een werkend dashboard. Je hoeft geen tijd te besteden aan het analyseren van datastromen of het begrijpen van dimensie-feit verhoudingen. Alles filtert alles — probleem opgelost.

Wat er mis gaat: Bidirectionele relaties creëren ambiguïteit in de DAX-engine. De query-engine moet raden welk filterpad te gebruiken bij complexe berekeningen. Dit leidt tot inconsistente resultaten tussen visualisaties en exponentieel trage performance bij grote datasets. Je krijgt mystery-bugs waarbij dezelfde metric verschillende waarden toont afhankelijk van de context.

De grondoorzaak: Het komt door onvoldoende begrip van het star schema. Teams behandelen Power BI als Excel — waar elke cel met elke cel kan communiceren. Maar relationele databases en OLAP-engines zijn geoptimaliseerd voor hierarchische filterstromen van dimensies naar feiten.

Wat dan wel werkt: Gebruik bidirectionele relaties alleen voor many-to-many scenarios waar het echt nodig is. Bouw je model op het star schema principe: dimensietabellen filteren feittabellen, niet andersom. Als je complexe many-to-many verhoudingen hebt, los ze op met bridge-tabellen en expliciete DAX-berekeningen.

Fout 2: Import van complete bronsystemen zonder transformatie

Het patroen: Teams importeren complete tabellen uit ERP-systemen, CRM-databases of Excel-bestanden zonder filtering of transformatie. Een typisch model bevat 50+ kolommen per tabel, waarvan er maar 5 gebruikt worden in rapporten.

Waarom mensen dit doen: Het voelt veiliger om "alles" te importeren voor het geval dat. Transformaties in Power Query lijken complex en tijdrovend. Teams denken: "Storage is goedkoop, dus waarom filteren?"

Wat er mis gaat: Elke onnodige kolom telt mee in de geheugenvoetafdruk van het model. VertiPaq compression — Power BI's kolom-gebaseerde storage — werkt het best met weinig, goed gestructureerde kolommen. Onnodige kolommen leiden tot 3x tot 5x grotere modellen, langere refresh-tijden en hogere Premium-capaciteitskosten.

De grondoorzaak: Teams missen het verschil tussen operational data en analytical data. ERP-tabellen zijn genormaliseerd voor transactionele consistentie — niet voor analytical queries. Je hebt een bewuste transformatie nodig om van OLTP naar OLAP te gaan.

Wat dan wel werkt: Importeer alleen kolommen die nodig zijn voor analyse of berekeningen. Gebruik Power Query om onnodige kolommen te verwijderen, datatypes te optimaliseren en berekende kolommen te creëren. Een goed analytical model heeft 10-15 kolommen per tabel, niet 50+.

Fout 3: Calculated columns in plaats van measures

Het patroon: Teams maken calculated columns voor alle berekeningen — omzetgroei, running totals, percentages. Deze kolommen bevatten voor elke rij een voorberekende waarde die wordt opgeslagen in het model.

Waarom mensen dit doen: Calculated columns lijken intuïtiever — je ziet de waarde direct in de data-weergave. Voor Excel-gebruikers voelt het natuurlijk om berekeningen in kolommen te maken, net als formules in spreadsheets.

Wat er mis gaat: Calculated columns worden row-by-row berekend en opgeslagen in het model. Bij een miljoen rijen data neemt elke calculated column een miljoen waarden in het geheugen in beslag. Ze kunnen niet aggregeren over verschillende filter-contexten en maken het model onnodig groot en traag.

De grondoorzaak: Teams begrijpen het verschil niet tussen storage-tijd en query-tijd. Calculated columns zijn storage-tijd — ze worden eenmaal berekend en opgeslagen. Measures zijn query-tijd — ze worden dynamisch berekend op basis van de huidige filter-context.

Wat dan wel werkt: Gebruik measures voor alle aggregaties — sommen, gemiddelden, percentages, groeicijfers. Calculated columns alleen voor statische eigenschappen die nodig zijn voor grouping of filtering. Een vuistregel: als je resultaat verandert op basis van filters of slicers, gebruik een measure.

Fout 4: Datum-kolommen als tekst importeren

Het patroon: Datum-kolommen komen binnen als tekst ("31-12-2024", "December 2024") of als datetime-waarden zonder datum-hiërarchie. Teams gebruiken deze kolommen direct in visualisaties zonder een proper datum-dimension.

Waarom mensen dit doen: Het werkt initieel voor basis-rapportage. Je kunt groeperen op maand of jaar, en de visualisaties zien er correct uit. Het lijkt onnodig werk om een aparte datumtabel te maken.

Wat er mis gaat: Tekst-datums kunnen niet chronologisch sorteren — "April" komt voor "Februari" in alfabetische volgorde. Time intelligence functies (YTD, QTD, same period last year) werken niet. Je krijgt geen automatische hiërarchieën of de mogelijkheid om flexibel te filteren op kwartalen, weken of custom periodes.

De grondoorzaak: Teams onderschatten het belang van proper datum-dimensies. Ze behandelen datums als gewone attributen in plaats van als de backbone van tijd-gebaseerde analyse.

Wat dan wel werkt: Creëer een dedicated datumtabel met alle benodigde attributen — jaar, kwartaal, maand, week, werkdag/weekend. Gebruik proper datum-datatypes en zorg voor een contiguous datum-range. Implementeer time intelligence met DATESYTD(), SAMEPERIODLASTYEAR() en vergelijkbare DAX-functies. Een goede datum-dimensie is de basis voor elke analytical model.

Fout 5: Complex model met te veel cross-filter relaties

Het patroon: Het model heeft 15+ tabellen met een web van relaties tussen alle tabellen. Elke tabel filtert meerdere andere tabellen, waardoor een complexe afhankelijkheidsgrafiek ontstaat zonder duidelijke hiërarchie.

Waarom mensen dit doen: Het reflecteert vaak de complexiteit van het bronsysteem. Teams proberen alle business-relaties uit het operational systeem te repliceren in het analytical model. "Als klanten gerelateerd zijn aan producten én aan regio's, dan moeten alle drie de tabellen elkaar filteren."

Wat er mis gaat: Complexe cross-filter patronen maken het model onvoorspelbaar en traag. DAX-berekeningen worden ambiguous omdat de engine meerdere filterpaden kan volgen naar hetzelfde resultaat. Debugging wordt onmogelijk omdat je niet weet welk filterpad wordt gebruikt voor een specifieke visualisatie.

De grondoorzaak: Gebrek aan dimensional modeling discipline. Teams proberen normalized OLTP-structuren te forceren in een denormalized OLAP-context.

Wat dan wel werkt: Implementeer een proper star schema met duidelijke feit- en dimensietabellen. Feittabellen in het centrum, dimensietabellen aan de randen. Cross-filters alleen tussen dimensies waar echt nodig (bijvoorbeeld product-category hiërarchieën). Voor complexe many-to-many relaties gebruik je bridge-tabellen of DAX CROSSFILTER() functies.

Fout 6: Refresh-strategieën zonder incrementeel laden

Het patroon: Het model refresht elke dag alle data compleet opnieuw, ongeacht of er nieuwe data is. Een model met 3 jaar historische data laadt elke nacht 3 jaar data opnieuw, ook al is er maar één dag nieuwe data bijgekomen.

Waarom mensen dit doen: Full refresh is de default en veiligste optie. Het voorkomt data-inconsistenties en je bent zeker dat alles up-to-date is. Incrementeel laden lijkt complex en risicovol.

Wat er mis gaat: Onnodige kosten en trage performance. Premium-capaciteit wordt belast op basis van CPU-tijd en geheugengebruik tijdens refresh. Een full refresh van 500MB data kost 10x meer capaciteit dan een incrementele refresh van 50MB nieuwe data. Bij grote datasets kunnen refreshes falen door timeouts.

De grondoorzaak: Teams optimaliseren niet voor productie-schaal. Ze bouwen models alsof ze altijd klein blijven, zonder rekening te houden met data-groei over tijd.

Wat dan wel werkt: Implementeer incrementeel refreshen voor grote tabellen met time-based data. Gebruik RangeStart en RangeEnd parameters in Power Query om alleen nieuwe of gewijzigde rijen te laden. Voor transactionele data refresh je alleen de laatste 30-90 dagen incrementeel en behoud je historische data onveranderd.

Fout 7: Security implementatie op visualisatie-niveau

Het patroon: Security wordt geregeld door verschillende rapporten te maken voor verschillende gebruikersgroepen, of door visualisaties te verbergen op basis van gebruikersrollen. Managers krijgen rapport A, medewerkers krijgen rapport B.

Waarom mensen dit doen: Het is de meest directe manier om verschillende toegangsniveaus te creëren. Je kunt snel verschillende versies maken zonder de onderliggende data-architectuur aan te passen.

Wat er mis gaat: Deze aanpak schaalt niet en is onveilig. Gebruikers kunnen via andere routes (zoals Excel-connecties of API's) toegang krijgen tot onderliggende data. Je moet meerdere versies van hetzelfde rapport onderhouden, wat leidt tot inconsistenties en dubbel werk. Compliance met GDPR wordt praktisch onmogelijk.

De grondoorzaak: Security wordt gezien als een UI-probleem in plaats van een data-probleem. Teams implementeren security als laatste stap in plaats van als foundation van het model.

Wat dan wel werkt: Implementeer Row Level Security (RLS) op model-niveau. Definieer security-rollen en filter-regels in het datamodel zelf, zodat gebruikers alleen de data zien die ze mogen zien, ongeacht hoe ze toegang krijgen. Een proper RLS-implementatie beveiligt data op engine-niveau, niet op UI-niveau.

Fout 8: Performance-problemen oplossen met meer hardware

Het patroon: Wanneer rapporten traag laden, wordt de oplossing gezocht in hogere Premium-capaciteit of meer geheugen. "Laten we upgraden van P1 naar P2, dan wordt alles sneller."

Waarom mensen dit doen: Hardware-upgrades lijken de eenvoudigste oplossing. Je hoeft het model niet te herontwerpen en gebruikers merken direct verbetering. Het is de "quick fix" voor performance-problemen.

Wat er mis gaat: Root-cause blijft bestaan. Een slecht model wordt iets sneller, maar blijft slecht. Je betaalt 2x zoveel voor capaciteit terwijl de onderliggende inefficiënties onopgelost blijven. Bij verdere data-groei loop je tegen dezelfde problemen aan.

De grondoorzaak: Teams behandelen symptomen in plaats van oorzaken. Performance-problemen komen meestal door model-design, niet door hardware-tekorten.

Wat dan wel werkt: Systematische performance-analyse met DAX Studio en Performance Analyzer. Meet waar de bottlenecks zitten — in de storage engine, formula engine, of visualisatie-rendering. Optimaliseer model-design, relaties en DAX-formules voordat je hardware-upgrades overweegt. Proper performance-tuning kan 5-10x snellere queries opleveren zonder extra kosten.

Fout 9: Ontbrekende documentatie en governance

Het patroon: Het model groeit organisch zonder documentatie van business-logica, data-bronnen of berekeningen. Verschillende teams voegen tabellen en measures toe zonder centrale coördinatie. Niemand weet meer precies hoe complexe KPI's berekend worden.

Waarom mensen dit doen: Documentatie voelt niet urgent — het model werkt toch? Teams focussen op deliverables (rapporten) in plaats van op onderhoud en governance. "We documenteren het later wel" — maar later komt nooit.

Wat er mis gaat: Technical debt stapelt zich op. Wijzigingen worden risicovol omdat niemand de impact kan voorspellen. Nieuwe teamleden hebben weken nodig om het model te begrijpen. Bug-fixing wordt een archeologische expeditie door DAX-code zonder uitleg.

De grondoorzaak: Teams onderschatten de levenscyclus van analytical modellen. Ze bouwen voor de korte termijn zonder rekening te houden met onderhoud, uitbreiding en teamwisselingen.

Wat dan wel werkt: Implementeer model-documentatie as code. Gebruik beschrijvende namen voor measures en tabellen. Documenteer business-logica in measure-omschrijvingen. Implementeer een governance framework met duidelijke eigenaarschap en wijzigingsprocedures. Nieuwe measures moeten code-review krijgen voordat ze in productie gaan.

Hoe een professionele audit deze fouten blootlegt

Een systematische datamodel-audit gebruikt geautomatiseerde tools en methodieken om deze patronen te detecteren. Moderne audit-tools scannen het model op structurele problemen, performance-bottlenecks en governance-risico's.

Geautomatiseerde detectie vindt bidirectionele relaties, oversized calculated columns en ontbrekende datum-dimensies binnen seconden. De tool analyseert het model-schema en markeert afwijkingen van best practices.

Performance-metrieken tonen de werkelijke impact van elk probleem — hoeveel langzamer wordt het model door calculated columns, hoeveel geheugen bespaar je door onnodige kolommen te verwijderen.

Prioriteit-scoring helpt te focussen op de grootste impact-items eerst. Niet alle fouten zijn even kritiek — de audit toont waar je tijd het best besteedt.

Een volledige audit levert een concrete actieplan op met geschatte tijd-investering en verwachte performance-verbetering per item. Teams kunnen zo systematisch hun model upgraden in plaats van ad-hoc problemen oplossen.

De korte versie

• Bidirectionele relaties en calculated columns maken modellen exponentieel traag — gebruik measures en proper star schema
• Import alleen relevante kolommen en implementeer incrementeel refreshen — full data-imports zijn geldverspilling
• Security op model-niveau (RLS) is de enige veilige manier — visualisatie-level security is een illusie
• Performance-problemen los je op in model-design, niet met duurder hardware
• Professionele audits detecteren deze patronen geautomatiseerd en leveren concrete actieplannen