Modelrelaties in Power BI Desktop

Dit artikel is bedoeld voor het importeren van gegevensmodelleerders die met Power BI Desktop werken. Het is een belangrijk onderwerp over het ontwerpen van modellen dat essentieel is voor het leveren van intuïtieve, nauwkeurige en optimale modellen.

Zie Stervormig schema en het belang van Power BI voor een diepere bespreking van het optimale modelontwerp, inclusief tabelrollen en -relaties.

Relatiedoel

Met een modelrelatie worden filters die zijn toegepast op de kolom van één modeltabel doorgegeven aan een andere modeltabel. Filters worden doorgegeven zolang er een relatiepad is dat moet worden gevolgd. Dit kan betrekking hebben op doorgifte naar meerdere tabellen.

Relatiepaden zijn deterministisch, wat betekent dat filters altijd op dezelfde manier en zonder willekeurige variatie worden doorgegeven. Relaties kunnen echter worden uitgeschakeld of filtercontext laten wijzigen door modelberekeningen die gebruikmaken van bepaalde DAX-functies. Zie het onderwerp Relevante DAX-functies verderop in dit artikel voor meer informatie.

Belangrijk

Modelrelaties dwingen geen gegevensintegriteit af. Zie het onderwerp Relatie-evaluatie verderop in dit artikel voor meer informatie, waarin wordt uitgelegd hoe modelrelaties zich gedragen wanneer er problemen zijn met gegevensintegriteit met uw gegevens.

Hier ziet u hoe relaties filters doorgeven met een voorbeeld met animatie.

In dit voorbeeld bestaat het model uit vier tabellen: Categorie, Product, Jaar en Verkoop. De tabel Categorie heeft betrekking op de tabel Product en de tabel Product heeft betrekking op de tabel Verkoop . De tabel Year heeft ook betrekking op de tabel Sales . Alle relaties zijn een-op-veel (waarvan de details verderop in dit artikel worden beschreven).

Een query, mogelijk gegenereerd door een Visual van een Power BI-kaart, vraagt de totale verkoophoeveelheid aan voor verkooporders die zijn gemaakt voor één categorie, Cat-A en voor één jaar, CY2018. Daarom kunt u filters zien die zijn toegepast op de tabellen Categorie en Jaar . Het filter in de tabel Categorie wordt doorgegeven aan de tabel Product om twee producten te isoleren die zijn toegewezen aan de categorie Cat-A. Vervolgens worden de filters van de tabel Product doorgegeven aan de tabel Sales om slechts twee verkooprijen voor deze producten te isoleren. Deze twee verkooprijen vertegenwoordigen de verkoop van producten die zijn toegewezen aan categorie Cat-A. De gecombineerde hoeveelheid is 14 eenheden. Tegelijkertijd wordt het tabelfilter Year doorgegeven om de tabel Verkoop verder te filteren, wat resulteert in slechts de één verkooprij voor producten die zijn toegewezen aan categorie Cat-A en die in jaar CY2018 is besteld. De door de query geretourneerde hoeveelheid is 11 eenheden. Houd er rekening mee dat wanneer meerdere filters worden toegepast op een tabel (zoals de tabel Sales in dit voorbeeld), het altijd een AND-bewerking is, waarbij alle voorwaarden moeten worden voldaan.

Ontwerpprincipes voor stervormige schema's toepassen

U wordt aangeraden ontwerpprincipes voor stervormige schema's toe te passen om een model te produceren dat bestaat uit dimensie- en feitentabellen. Het is gebruikelijk om Power BI in te stellen om regels af te dwingen die dimensietabellen filteren, zodat modelrelaties deze filters efficiënt kunnen doorgeven aan feitentabellen.

De volgende afbeelding is het modeldiagram van het gegevensmodel van de verkoopanalyse van Adventure Works. Het toont een stervormig schemaontwerp dat bestaat uit één feitentabel met de naam Sales. De andere vier tabellen zijn dimensietabellen die ondersteuning bieden voor de analyse van verkoopmetingen op datum, staat, regio en product. Let op de modelrelaties die alle tabellen verbinden. Deze relaties geven filters (direct of indirect) door aan de tabel Sales .

Niet-verbonden tabellen

Het is ongebruikelijk dat een modeltabel niet is gerelateerd aan een andere modeltabel. Een dergelijke tabel in een geldig modelontwerp wordt beschreven als een niet-verbonden tabel. Een niet-verbonden tabel is niet bedoeld om filters door te geven aan andere modeltabellen. In plaats daarvan accepteert het 'gebruikersinvoer' (mogelijk met een slicervisual), waardoor modelberekeningen de invoerwaarde op een zinvolle manier kunnen gebruiken. Denk bijvoorbeeld aan een niet-verbonden tabel die wordt geladen met een bereik van wisselkoerswaarden. Zolang een filter wordt toegepast om te filteren op één frequentiewaarde, kan een metingexpressie die waarde gebruiken om verkoopwaarden te converteren.

De what-if-parameter van Power BI Desktop is een functie waarmee een niet-verbonden tabel wordt gemaakt. Zie Een What if-parameter maken en gebruiken voor het visualiseren van variabelen in Power BI Desktop voor meer informatie.

Relatie-eigenschappen

Een modelrelatie heeft één kolom in een tabel met één kolom in een andere tabel. (Er is één speciaal geval waarbij deze vereiste niet waar is en alleen van toepassing is op relaties met meerdere kolommen in DirectQuery-modellen. Zie het artikel over de DAX-functie COMBINEVALUES voor meer informatie.)

Notitie

Het is niet mogelijk om een kolom te koppelen aan een andere kolom in dezelfde tabel. Dit concept wordt soms verward met de mogelijkheid om een refererende sleutelbeperking voor een relationele database te definiëren die zelf verwijst naar een tabel. U kunt dit relationele databaseconcept gebruiken om relaties tussen bovenliggende en onderliggende items op te slaan (bijvoorbeeld elke werknemersrecord is gerelateerd aan een werknemer die rapporteert aan). U kunt echter geen modelrelaties gebruiken om een modelhiërarchie te genereren op basis van dit type relatie. Als u een bovenliggende en onderliggende hiërarchie wilt maken, raadpleegt u de functies Bovenliggend en Onderliggend.

Gegevenstypen van kolommen

Het gegevenstype voor zowel de kolom 'van' als 'naar' van de relatie moet hetzelfde zijn. Werken met relaties die zijn gedefinieerd in Datum/tijd-kolommen werkt mogelijk niet zoals verwacht. De engine waarin Power BI-gegevens worden opgeslagen, maakt alleen gebruik van datum/tijd-gegevenstypen ; Gegevenstypen Datum, Tijd en Datum/Tijd/Tijdzone zijn Power BI-opmaakconstructies die bovenaan zijn geïmplementeerd. Alle modelafhankelijke objecten worden nog steeds weergegeven als DateTime in de engine (zoals relaties, groepen, enzovoort). Als een gebruiker daarom Datum selecteert op het tabblad Modellering voor dergelijke kolommen, worden ze nog steeds niet geregistreerd als dezelfde datum, omdat het tijdgedeelte van de gegevens nog steeds door de engine wordt overwogen. Lees meer over hoe datum-/tijdtypen worden verwerkt. Om het gedrag te corrigeren, moeten de kolomgegevenstypen worden bijgewerkt in de Power Query-editor om het tijdgedeelte van de geïmporteerde gegevens te verwijderen, dus wanneer de engine de gegevens verwerkt, worden de waarden hetzelfde weergegeven.

Kardinaliteit

Elke modelrelatie wordt gedefinieerd door een kardinaliteitstype. Er zijn vier opties voor kardinaliteitstypen, die de gegevenskenmerken van de gerelateerde kolommen 'van' en 'naar' vertegenwoordigen. De 'een'-zijde betekent dat de kolom unieke waarden bevat; de 'veel'-zijde betekent dat de kolom dubbele waarden kan bevatten.

Notitie

Als een bewerking voor het vernieuwen van gegevens dubbele waarden probeert te laden in een kolom aan de 'een'-zijde, mislukt het vernieuwen van de hele gegevens.

De vier opties, samen met hun verkorte notaties, worden beschreven in de volgende lijst met opsommingstekens:

• Een-op-veel (1:*)
• Veel-op-een (*:1)
• Een-op-een (1:1)
• Veel-op-veel (*:*)

Wanneer u een relatie maakt in Power BI Desktop, detecteert en stelt de ontwerper automatisch het type kardinaliteit in. Power BI Desktop voert een query uit op het model om te weten welke kolommen unieke waarden bevatten. Voor importmodellen wordt gebruikgemaakt van interne opslagstatistieken; voor DirectQuery-modellen worden profileringsquery's naar de gegevensbron verzonden. Soms kan Power BI Desktop het echter fout krijgen. Het kan verkeerd zijn wanneer tabellen nog moeten worden geladen met gegevens, of omdat kolommen die u verwacht dubbele waarden te bevatten, momenteel unieke waarden bevatten. In beide gevallen kunt u het type kardinaliteit bijwerken zolang een 'een'-zijde kolommen unieke waarden bevatten (of de tabel moet worden geladen met rijen met gegevens).

Een-op-veel-kardinaliteit (en veel-op-een) kardinaliteit

De opties voor een-op-veel - en veel-op-een-kardinaliteit zijn in wezen hetzelfde en zijn ook de meest voorkomende kardinaliteitstypen.

Wanneer u een een-op-veel- of veel-op-een-relatie configureert, kiest u de relatie die overeenkomt met de volgorde waarin u de kolommen hebt gerelateerd. Overweeg hoe u de relatie van de tabel Product naar de tabel Verkoop configureert met behulp van de kolom Product-id in elke tabel. Het type kardinaliteit zou een-op-veel zijn, omdat de kolom Product-id in de tabel Product unieke waarden bevat. Als u de tabellen in omgekeerde richting hebt gerelateerd, verkoop naar product, is de kardinaliteit veel-op-een.

Een-op-een-kardinaliteit

Een een-op-een-relatie betekent dat beide kolommen unieke waarden bevatten. Dit type kardinaliteit is niet gebruikelijk en het vertegenwoordigt waarschijnlijk een suboptimaal modelontwerp vanwege de opslag van redundante gegevens.

Zie de richtlijnen voor een-op-een-relatie voor meer informatie over het gebruik van dit type kardinaliteit.

Veel-op-veel-kardinaliteit

Een veel-op-veel-relatie betekent dat beide kolommen dubbele waarden kunnen bevatten. Dit type kardinaliteit wordt niet vaak gebruikt. Dit is doorgaans handig bij het ontwerpen van complexe modelvereisten. U kunt deze gebruiken om veel-op-veel-feiten te relateren of om nauwkeurigere feiten te relateren. Wanneer bijvoorbeeld verkoopdoelgegevens worden opgeslagen op productcategorieniveau en de tabel productdimensie wordt op productniveau opgeslagen.

Zie De richtlijnen voor veel-op-veel-relaties voor hulp bij het gebruik van dit type kardinaliteit.

Notitie

Het type veel-op-veel-kardinaliteit wordt ondersteund voor modellen die zijn ontwikkeld voor Power BI Report Server januari 2024 en hoger.

Tip

In de modelweergave van Power BI Desktop kunt u het kardinaliteitstype van een relatie interpreteren door de indicatoren (1 of *) aan beide zijden van de relatielijn te bekijken. Als u wilt bepalen welke kolommen gerelateerd zijn, moet u de relatielijn selecteren of aanwijzen om de kolommen te markeren.

Kruisfilterrichting

Elke modelrelatie wordt gedefinieerd met een kruisfilterrichting. Uw instelling bepaalt de richting(en) die filters doorgeven. De mogelijke opties voor kruislings filteren zijn afhankelijk van het type kardinaliteit.

Type kardinaliteit	Opties voor kruislings filteren
Een-op-veel (of veel-op-een)	Eén Beide
Individuele	Beide
Veel-op-veel	Enkel (Tabel1 naar Tabel2) Enkel (tabel2 tot tabel1) Beide

Eén kruisfilterrichting betekent 'één richting' en Beide betekent 'beide richtingen'. Een relatie die in beide richtingen filtert, wordt meestal beschreven als bidirectioneel.

Voor een-op-veel-relaties is de kruisfilterrichting altijd van de 'een'-kant en optioneel van de 'veel'-zijde (bidirectioneel). Voor een-op-een-relaties is de kruisfilterrichting altijd van beide tabellen. Ten slotte kan voor veel-op-veel-relaties kruisfilterrichting afkomstig zijn uit een van de tabellen of uit beide tabellen. U ziet dat wanneer het type kardinaliteit een 'een'-zijde bevat, die filters altijd vanaf die kant worden doorgegeven.

Wanneer de kruisfilterrichting is ingesteld op Beide, wordt er een andere eigenschap beschikbaar. Het kan bidirectionele filters toepassen wanneer In Power BI regels voor beveiliging op rijniveau (RLS) worden afgedwongen. Zie beveiliging op rijniveau (RLS ) met Power BI Desktop voor meer informatie over beveiliging op rijniveau.

U kunt de kruisfilterrichting voor relaties wijzigen, inclusief het uitschakelen van filterdoorgifte, met behulp van een modelberekening. Dit wordt bereikt met behulp van de DAX-functie CROSSFILTER .

Houd er rekening mee dat bidirectionele relaties een negatieve invloed kunnen hebben op de prestaties. Als u een bidirectionele relatie probeert te configureren, kan dit leiden tot dubbelzinnige paden voor het doorgeven van filters. In dit geval kan power BI Desktop de relatiewijziging niet doorvoeren en wordt u gewaarschuwd met een foutbericht. Soms kunt u echter met Power BI Desktop dubbelzinnige relatiepaden tussen tabellen definiëren. Het oplossen van dubbelzinnigheid van relatiepaden wordt verderop in dit artikel beschreven.

We raden u aan bidirectioneel filteren alleen te gebruiken als dat nodig is. Zie bidirectionele relatierichtlijnen voor meer informatie.

Tip

In de modelweergave van Power BI Desktop kunt u de kruisfilterrichting van een relatie interpreteren door de pijlpunten langs de relatielijn te noteren. Eén pijlpunt vertegenwoordigt een filter in één richting in de richting van de pijlpunt; een dubbele pijlpunt vertegenwoordigt een bidirectionele relatie.

Deze relatie activeren

Er kan slechts één actief pad voor het doorgeven van filters tussen twee modeltabellen zijn. Het is echter mogelijk om extra relatiepaden te introduceren, hoewel u deze relaties als inactief moet instellen. Inactieve relaties kunnen alleen actief worden gemaakt tijdens de evaluatie van een modelberekening. Dit wordt bereikt met behulp van de DAX-functie USERELATIONSHIP .

Over het algemeen raden we u aan om waar mogelijk actieve relaties te definiëren. Ze verbreeden het bereik en het potentieel van hoe auteurs van rapporten uw model kunnen gebruiken. Als u alleen actieve relaties gebruikt, betekent dit dat rollenspeldimensietabellen in uw model moeten worden gedupliceerd.

In specifieke omstandigheden kunt u echter een of meer inactieve relaties definiëren voor een rollenspeldimensietabel. U kunt dit ontwerp overwegen wanneer:

• Er is geen vereiste voor rapportvisuals om tegelijkertijd te filteren op verschillende rollen.
• U gebruikt de USERELATIONSHIP DAX-functie om een specifieke relatie te activeren voor relevante modelberekeningen.

Zie richtlijnen voor actieve versus inactieve relaties voor meer informatie.

Tip

In de modelweergave van Power BI Desktop kunt u de actieve versus inactieve status van een relatie interpreteren. Een actieve relatie wordt vertegenwoordigd door een ononderbroken lijn; een inactieve relatie wordt weergegeven als een stippellijn.

Referentiële integriteit aannemen

De eigenschap Referentiële integriteit aannemen is alleen beschikbaar voor een-op-veel- en een-op-een-relaties tussen twee DirectQuery-opslagmodustabellen die deel uitmaken van dezelfde brongroep. U kunt deze eigenschap alleen inschakelen wanneer de kolom 'veel'-zijde geen NULL's bevat.

Wanneer deze optie is ingeschakeld, worden systeemeigen query's die naar de gegevensbron worden verzonden, de twee tabellen samengevoegd met behulp van een INNER JOIN in plaats van een OUTER JOIN. Over het algemeen verbetert het inschakelen van deze eigenschap de queryprestaties, hoewel deze afhankelijk is van de specifieke kenmerken van de gegevensbron.

Schakel deze eigenschap altijd in wanneer er een beperking voor een refererende databasesleutel tussen de twee tabellen bestaat. Zelfs als er geen beperking voor refererende sleutels bestaat, kunt u overwegen de eigenschap in te schakelen zolang u bepaalde gegevensintegriteit hebt.

Belangrijk

Als de gegevensintegriteit gecompromitteerd moet worden, elimineert de inner join niet-overeenkomende rijen tussen de tabellen. Denk bijvoorbeeld aan een modelverkooptabel met een kolomwaarde Product-id die niet bestond in de gerelateerde tabel Product. Filterdoorgifte van de tabel Product naar de tabel Verkoop elimineert verkooprijen voor onbekende producten. Dit zou resulteren in een understatement van de verkoopresultaten.

Zie Referentiële integriteitsinstellingen aannemen in Power BI Desktop voor meer informatie.

Relevante DAX-functies

Er zijn verschillende DAX-functies die relevant zijn voor modelrelaties. Elke functie wordt kort beschreven in de volgende lijst met opsommingstekens:

• RELATED: Haalt de waarde op uit de 'een'-kant van een relatie. Het is handig bij het uitvoeren van berekeningen uit verschillende tabellen die worden geëvalueerd in rijcontext.
• RELATEDTABLE: Haal een tabel met rijen op uit de 'veel'-kant van een relatie.
• USERELATIONSHIP: Hiermee kan een berekening een inactieve relatie gebruiken. (Technisch gezien wijzigt deze functie het gewicht van een specifieke inactieve modelrelatie die helpt om het gebruik ervan te beïnvloeden.) Het is handig wanneer uw model een rollenspeldimensietabel bevat en u ervoor kiest om inactieve relaties op basis van deze tabel te maken. U kunt deze functie ook gebruiken om dubbelzinnigheid in filterpaden op te lossen.
• CROSSFILTER: wijzigt de kruisfilterrichting van de relatie (op een of beide), of schakelt filterdoorgifte (geen) uit. Het is handig wanneer u modelrelaties tijdens de evaluatie van een specifieke berekening moet wijzigen of negeren.
• COMBINEVALUES: voegt twee of meer tekenreeksen toe aan één tekenreeks. Het doel van deze functie is het ondersteunen van relaties met meerdere kolommen in DirectQuery-modellen wanneer tabellen deel uitmaken van dezelfde brongroep.
• TREATAS: Hiermee past u het resultaat van een tabelexpressie toe als filters op kolommen uit een niet-gerelateerde tabel. Het is handig in geavanceerde scenario's wanneer u een virtuele relatie wilt maken tijdens de evaluatie van een specifieke berekening.
• Bovenliggende en onderliggende functies: Een reeks gerelateerde functies die u kunt gebruiken om berekende kolommen te genereren om een bovenliggende en onderliggende hiërarchie te naturaliseren. U kunt deze kolommen vervolgens gebruiken om een hiërarchie op vast niveau te maken.

Relatie-evaluatie

Modelrelaties worden vanuit evaluatieperspectief geclassificeerd als normaal of beperkt. Het is geen configureerbare relatie-eigenschap. Het is in feite afgeleid van het type kardinaliteit en de gegevensbron van de twee gerelateerde tabellen. Het is belangrijk om inzicht te krijgen in het evaluatietype, omdat er mogelijk gevolgen zijn voor de prestaties of dat de gegevensintegriteit wordt aangetast. Deze implicaties en integriteitsgevolgen worden in dit onderwerp beschreven.

Ten eerste is enige modelleertheorie vereist om volledig inzicht te hebben in relatieevaluaties.

Een import- of DirectQuery-modelbronnen alle gegevens uit de Vertipaq-cache of de brondatabase. In beide gevallen kan Power BI bepalen dat er een 'een'-kant van een relatie bestaat.

Een samengesteld model kan echter bestaan uit tabellen met verschillende opslagmodi (importeren, DirectQuery of dual) of meerdere DirectQuery-bronnen. Elke bron, met inbegrip van de Vertipaq-cache met geïmporteerde gegevens, wordt beschouwd als een brongroep. Modelrelaties kunnen vervolgens worden geclassificeerd als intra-brongroep of inter-/crosssourcegroep. Een relatie binnen een brongroep heeft betrekking op twee tabellen binnen een brongroep, terwijl een relatie tussen meerdere brongroepen tabellen in twee brongroepen relateert. Relaties in import- of DirectQuery-modellen zijn altijd intra-brongroep.

Hier volgt een voorbeeld van een samengesteld model.

In dit voorbeeld bestaat het samengestelde model uit twee brongroepen: een Vertipaq-brongroep en een DirectQuery-brongroep. De Vertipaq-brongroep bevat drie tabellen en de DirectQuery-brongroep bevat twee tabellen. Er bestaat één relatie tussen meerdere brongroepen om een tabel in de Vertipaq-brongroep te koppelen aan een tabel in de DirectQuery-brongroep.

Reguliere relaties

Een modelrelatie is regelmatig wanneer de query-engine de 'een'-kant van de relatie kan bepalen. Er wordt bevestigd dat de kolom 'een'-zijde unieke waarden bevat. Alle een-op-veel-relaties binnen de brongroep zijn gewone relaties.

In het volgende voorbeeld zijn er twee reguliere relaties, beide gemarkeerd als R. Relaties omvatten de een-op-veel-relatie in de Vertipaq-brongroep en de een-op-veel-relatie in de DirectQuery-bron.

Voor importmodellen, waarbij alle gegevens worden opgeslagen in de Vertipaq-cache, maakt Power BI een gegevensstructuur voor elke reguliere relatie tijdens het vernieuwen van gegevens. De gegevensstructuren bestaan uit geïndexeerde toewijzingen van alle kolom-naar-kolomwaarden en hun doel is om het samenvoegen van tabellen tijdens query's te versnellen.

Bij het uitvoeren van query's kunnen normale relaties tabeluitbreidingen uitvoeren. Tabeluitbreiding resulteert in het maken van een virtuele tabel door de systeemeigen kolommen van de basistabel op te tellen en vervolgens uit te breiden naar gerelateerde tabellen. Voor importtabellen wordt tabeluitbreiding uitgevoerd in de query-engine; voor DirectQuery-tabellen wordt deze uitgevoerd in de systeemeigen query die naar de brondatabase wordt verzonden (zolang de eigenschap Referentiële integriteit aannemen niet is ingeschakeld). De query-engine werkt vervolgens op de uitgevouwen tabel, waarbij filters worden toegepast en gegroepeerd op de waarden in de uitgevouwen tabelkolommen.

Notitie

Inactieve relaties worden ook uitgevouwen, zelfs wanneer de relatie niet wordt gebruikt door een berekening. Bidirectionele relaties hebben geen invloed op tabeluitbreiding.

Voor een-op-veel-relaties vindt tabeluitbreiding plaats van de 'veel' naar de 'een'-zijde met behulp van LEFT OUTER JOIN semantiek. Wanneer er geen overeenkomende waarde van de 'veel' aan de 'een'-zijde bestaat, wordt er een lege virtuele rij toegevoegd aan de 'een'-zijtabel. Dit gedrag is alleen van toepassing op reguliere relaties, niet op beperkte relaties.

Tabeluitbreiding vindt ook plaats voor een-op-een-intra-brongroeprelaties, maar met behulp van FULL OUTER JOIN semantiek. Dit jointype zorgt ervoor dat lege virtuele rijen aan beide zijden worden toegevoegd, indien nodig.

Lege virtuele rijen zijn in feite onbekende leden. Onbekende leden vertegenwoordigen schendingen van referentiële integriteit, waarbij de waarde aan de 'veel'-zijde geen overeenkomende 'één'-zijdewaarde heeft. In het ideale geval mogen deze lege waarden niet bestaan. Ze kunnen worden verwijderd door de brongegevens op te schonen of te herstellen.

Hier ziet u hoe tabeluitbreiding werkt met een voorbeeld met animatie.

In dit voorbeeld bestaat het model uit drie tabellen: Categorie, Product en Verkoop. De tabel Categorie heeft betrekking op de tabel Product met een een-op-veel-relatie en de tabel Product heeft betrekking op de tabel Verkoop met een een-op-veel-relatie. De tabel Categorie bevat twee rijen, de tabel Product bevat drie rijen en de tabellen Sales bevat vijf rijen. Er zijn overeenkomende waarden aan beide zijden van alle relaties, wat betekent dat er geen schendingen van referentiële integriteit zijn. Er wordt een uitgevouwen tabel met querytijd weergegeven. De tabel bestaat uit de kolommen uit alle drie de tabellen. Het is effectief een gedenormaliseerd perspectief van de gegevens in de drie tabellen. Er wordt een nieuwe rij toegevoegd aan de tabel Verkoop en deze heeft een productie-id-waarde (9) die geen overeenkomende waarde bevat in de tabel Product . Het is een schending van referentiële integriteit. In de uitgevouwen tabel bevat de nieuwe rij (Lege) waarden voor de kolommen Categorie en Product .

Beperkte relaties

Een modelrelatie is beperkt wanneer er geen gegarandeerde 'een'-zijde is. Een beperkte relatie kan om twee redenen optreden:

• De relatie maakt gebruik van een veel-op-veel-kardinaliteitstype (zelfs als een of beide kolommen unieke waarden bevatten).
• De relatie is een cross-source-groep (dit kan alleen het geval zijn voor samengestelde modellen).

In het volgende voorbeeld zijn er twee beperkte relaties, beide gemarkeerd als L. De twee relaties omvatten de veel-op-veel-relatie in de Vertipaq-brongroep en de een-op-veel-relatie tussen brongroepen.

Voor importmodellen worden gegevensstructuren nooit gemaakt voor beperkte relaties. In dat geval worden tabeldeelnames tijdens het uitvoeren van query's omgezet in Power BI.

Tabeluitbreiding vindt nooit plaats voor beperkte relaties. Tabeldeelnames worden bereikt met behulp van INNER JOIN semantiek en daarom worden lege virtuele rijen niet toegevoegd om schendingen van referentiële integriteit te compenseren.

Er zijn andere beperkingen met betrekking tot beperkte relaties:

• De RELATED DAX-functie kan niet worden gebruikt om de kolomwaarden aan de 'een'-zijde op te halen.
• Het afdwingen van beveiliging op rijniveau heeft topologiebeperkingen.

Tip

In de modelweergave van Power BI Desktop kunt u een relatie interpreteren als beperkt. Een beperkte relatie wordt weergegeven met haakjes () na de kardinaliteitsindicatoren.

Ambiguïteit van relatiepad oplossen

Bidirectionele relaties kunnen meerdere, dus dubbelzinnige, filterdoorgiftepaden tussen modeltabellen introduceren. Bij het evalueren van dubbelzinnigheid kiest Power BI het pad voor het doorgeven van filters op basis van de prioriteit en het gewicht.

Prioriteit

Prioriteitslagen definiëren een reeks regels die power BI gebruikt om dubbelzinnigheid van relatiepaden op te lossen. De eerste regelovereenkomst bepaalt het pad dat Power BI volgt. In elke regel hieronder wordt beschreven hoe filters van een brontabel naar een doeltabel stromen.

1. Een pad dat bestaat uit een-op-veel-relaties.
2. Een pad dat bestaat uit een-op-veel- of veel-op-veel-relaties.
3. Een pad dat bestaat uit veel-op-een-relaties.
4. Een pad dat bestaat uit een-op-veel-relaties van de brontabel naar een tussenliggende tabel, gevolgd door veel-op-een-relaties uit de tussenliggende tabel naar de doeltabel.
5. Een pad dat bestaat uit een-op-veel- of veel-op-veel-relaties van de brontabel naar een tussenliggende tabel, gevolgd door veel-op-een- of veel-op-veel-relaties van de tussenliggende tabel naar de doeltabel.
6. Elk ander pad.

Wanneer een relatie is opgenomen in alle beschikbare paden, wordt deze verwijderd uit overweging van alle paden.

Gewicht

Elke relatie in een pad heeft een gewicht. Standaard is elk relatiegewicht gelijk, tenzij de functie USERELATIONSHIP wordt gebruikt. Het padgewicht is het maximum van alle relatiegewichten langs het pad. Power BI gebruikt de padgewichten om dubbelzinnigheid tussen meerdere paden in dezelfde prioriteitslaag op te lossen. Het kiest geen pad met een lagere prioriteit, maar kiest het pad met het hogere gewicht. Het aantal relaties in het pad heeft geen invloed op het gewicht.

U kunt het gewicht van een relatie beïnvloeden met behulp van de functie USERELATIONSHIP . Het gewicht wordt bepaald door het nestniveau van de aanroep naar deze functie, waarbij de binnenste aanroep het hoogste gewicht ontvangt.

Bekijk het volgende voorbeeld. De meting Productverkoop wijst een hoger gewicht toe aan de relatie tussen Sales[ProductID] en Product[ProductID], gevolgd door de relatie tussen Inventory[ProductID] en Product[ProductID].

Product Sales = 
CALCULATE(
    CALCULATE(
        SUM(Sales[SalesAmount]), 
        USERELATIONSHIP(Sales[ProductID], Product[ProductID])
    ),
    USERELATIONSHIP(Inventory[ProductID], Product[ProductID])
)

Notitie

Als Power BI meerdere paden detecteert met dezelfde prioriteit en hetzelfde gewicht, wordt er een dubbelzinnige padfout geretourneerd. In dit geval moet u de dubbelzinnigheid oplossen door de relatiegewichten te beïnvloeden met behulp van de functie USERELATIONSHIP of door modelrelaties te verwijderen of te wijzigen.

Prestatievoorkeur

In de volgende lijst ziet u de prestaties van filterdoorgifte, van de snelste naar de traagste prestaties:

1. Een-op-veel-relaties tussen brongroepen
2. Veel-op-veel-modelrelaties die zijn bereikt met een tussenliggende tabel en die ten minste één bidirectionele relatie omvatten
3. Veel-op-veel-kardinaliteitsrelaties
4. Relaties tussen brongroepen

Gerelateerde inhoud

Raadpleeg de volgende bronnen voor meer informatie over dit artikel:

• Stervormige schema's en het belang van Power BI begrijpen
• Richtlijnen voor een-op-een-relatie
• Richtlijnen voor veel-op-veel-relaties
• Richtlijnen voor actieve versus inactieve relaties
• Richtlijnen voor bidirectionele relaties
• Richtlijnen voor het oplossen van problemen met relaties
• Video: De do's en don'ts van Power BI-relaties
• Vragen? Vraag het Power BI-community
• Suggesties? Ideeën bijdragen om Power BI te verbeteren