Cardinaliteit - Power Bi

Wat is cardinaliteit?

Cardinaliteit beschrijft hoe twee tabellen zich tot elkaar verhouden: hoeveel rijen in tabel A komen overeen met hoeveel rijen in tabel B. Het is de grondslag van elke relatie in een Power BI- of Fabric-model, en één van de plaatsen waar modellen stilletjes stuk gaan.

De basisvraag: is een waarde in deze kolom uniek, of kan ze meerdere keren voorkomen? Het antwoord bepaalt welk type relatie je kan leggen, hoe filters propageren en of je rapport de juiste som laat zien.

De vier types met voorbeelden

Power BI kent vier cardinaliteitstypes. Microsoft noteert ze als 1:*, *:1, 1:1 en *:*. De "1" betekent: unieke waarden. De "*" betekent: mag dubbele waarden bevatten.

One-to-many (1:*)
De klassieker. Eén productrecord in de Product-tabel matcht met veel orderlijnen in de Orders-tabel. Je legt de relatie van Product naar Orders, waarbij ProductID in Product uniek is. Filters propageren van Product naar Orders: wie een productcategorie selecteert, filtert automatisch de orderlijnen mee.

Many-to-one (*:1)
Hetzelfde, omgekeerd bekeken. Orderlijnen wijzen terug naar een uniek klantrecord. Functioneel identiek aan one-to-many, gewoon vanaf de andere kant gelezen.

One-to-one (1:1)
Beide kanten bevatten unieke waarden. Eén klantrecord in CRM matcht met exact één klantrecord in het loyaliteitsprogramma. Relatief zeldzaam, en vaak een teken dat de twee tabellen eigenlijk dezelfde entiteit beschrijven en beter samengevoegd worden.

Many-to-many (*:*)
Beide kanten bevatten dubbele waarden. Komt voor wanneer feiten op verschillende granulariteit staan: salesdoelen per productcategorie tegenover orders per SKU. Krachtig, maar ook gevaarlijk: mislukte *:*-modellen zijn een hoofdoorzaak van vreemde totalen. Gebruik het bewust, niet omdat je de juiste 1:* niet gevonden hebt.

Cross-filter direction

Elke relatie heeft naast een cardinaliteit ook een filterrichting: welke kant gaan filters uit?

Single direction
De standaard. Filters gaan van de "één"-kant naar de "veel"-kant. Eenduidig, snel, voorspelbaar.

Both (bidirectioneel)
Filters gaan beide kanten op. Soms nodig, vaak duur. Bidirectionele filters op grote modellen zorgen voor trage queries, ambigue filterpaden en onverwachte totalen. Microsoft's eigen guidance: gebruik het alleen als je het écht nodig hebt, bij voorkeur op kleine dimensietabellen.

In een gezond star schema heb je enkel single-direction 1:*-relaties van dimensies naar de feittabel. Dat model is snel, goed te begrijpen en laat zich vlot slicen. Zodra je bidirectioneel moet gaan sleutelen, is dat meestal een signaal dat je onderliggende model anders moet.

Regular versus limited relationships

Minder bekend, maar belangrijk voor performance: Power BI onderscheidt regular en limited relaties.

Regular relationships
One-to-many binnen dezelfde source group, meestal importmodellen. De engine bouwt bij refresh een geïndexeerde mapping en kan tabellen snel expanderen. Alle filter-propagatie die je intuïtief verwacht, werkt hier.

Limited relationships
Many-to-many, of relaties tussen verschillende source groups in een composite model. De engine weet op voorhand niet welke kant uniek is en moet runtime joinen met INNER JOIN-semantiek. Gevolg: blanco-rijen worden niet aangevuld, de RELATED-functie werkt niet over de relatie heen, en RLS kent extra beperkingen.

Je herkent limited relationships in de modelview aan haakjes-achtige indicatoren naast de "1"- of "*"-symbolen op de relatielijn.

Valkuilen

Dubbele waarden breken de refresh
Een refresh die een one-to-many-relatie probeert te laden met dubbele waarden aan de "één"-kant, faalt volledig. De fix is zelden "zet de relatie op many-to-many". De echte vraag is: waarom zitten er dubbels in wat een dimensietabel zou moeten zijn? Meestal is dat een bug in de source, geen modelleringskeuze.

Many-to-many als pleister
Als iemand een relatie op *:* zet "omdat het anders niet werkt", stop. Er is bijna altijd een ster onder die je over het hoofd zag. Een bridge-tabel met een surrogate key, een aparte datum-dimensie, een conformed klantdimensie: meestal lost dat het probleem op zonder de kost van many-to-many.

Bidirectioneel als gewoonte
"Als ik overal bidirectioneel zet, werkt alles." Ja, tot je twee paden tussen dezelfde tabellen hebt en Power BI een ambiguity-error gooit. Of tot je queries op een groot model instorten. Start altijd single direction, zet bidirectioneel aan met een concrete reden.

DateTime-relaties die niet matchen
Relaties op datetime-kolommen werken niet zoals je verwacht, omdat de engine ook het tijdsgedeelte meeneemt. Cast je kolommen naar een zuivere Date voordat je de relatie legt, anders krijg je een model dat refresht maar niets matcht.