Delen via


Richtlijnen voor actieve versus inactieve relaties

Dit artikel is bedoeld voor u als gegevensmodeller die werkt met Power BI Desktop. Het biedt richtlijnen voor het maken van actieve of inactieve modelrelaties. Actieve relaties geven standaard filters door aan andere tabellen. Inactieve relatie; filters worden echter alleen doorgegeven wanneer een DAX-expressie de relatie activeert (gebruikt).

Notitie

In dit artikel wordt geen inleiding tot modelrelaties behandeld. Als u niet volledig bekend bent met relaties, eigenschappen of hoe u deze configureert, raden we u aan eerst de modelrelaties te lezen in Power BI Desktop artikel.

Het is ook belangrijk dat u inzicht hebt in het ontwerp van stervormige schema's. Voor meer informatie, zie Begrijp sterschema en het belang voor Power BI.

Actieve relaties

Over het algemeen raden we u aan om waar mogelijk actieve relaties te definiëren. Ze verbreeden het bereik en het potentieel van hoe uw model kan worden gebruikt door rapportauteurs en gebruikers die werken met Q&A.

Bekijk een voorbeeld van een Import-model ontworpen voor het analyseren van de on-time prestaties van luchtvaartmaatschappijen (OTP). Het model heeft een Flight tabel, een feitentabel waarin één rij per vlucht wordt opgeslagen. Elke rij registreert de vluchtdatum, het vluchtnummer, de luchthavens van vertrek en aankomst en eventuele vertragingstijd (in minuten). Er is ook een Airport tabel, een dimensietabel waarin één rij per luchthaven wordt opgeslagen. In elke rij worden de luchthavencode, de naam van de luchthaven en het land of de regio beschreven.

Hier volgt een gedeeltelijk modeldiagram van de twee tabellen.

diagram met een model met twee tabellen: Flight en Airport. Het relatieontwerp wordt beschreven in de volgende alinea.

Er zijn twee modelrelaties tussen de Flight en Airport tabellen. In de Flight tabel hebben de kolommen DepartureAirport en ArrivalAirport betrekking op de kolom Airport van de Airport tabel. In stervormig schemaontwerp wordt de Airport tabel beschreven als een dimensie voor rollenspel. In dit model zijn de twee rollen luchthaven van vertrek en luchthaven van aankomst.

Hoewel dit ontwerp goed werkt voor relationele stervormige schemaontwerpen, werkt het niet goed voor Power BI-modellen. Dat komt doordat modelrelaties paden zijn voor het doorgeven van filters, en deze paden moeten deterministisch zijn. Zie voor meer informatie over het controleren of paden voor filterdoorgifte deterministisch zijn het relatiepad dubbelzinnigheidoplossen. Daarom, zoals in dit voorbeeld wordt weergegeven, is één relatie actief terwijl de andere inactief is (vertegenwoordigd door de stippellijn). Het is met name de relatie met de ArrivalAirport kolom die actief is, wat betekent dat filters die worden toegepast op de Airport tabel automatisch worden doorgegeven aan de ArrivalAirport kolom van de Flight tabel.

Dit modelontwerp legt ernstige beperkingen op voor de wijze waarop de gegevens kunnen worden gerapporteerd. Het is niet mogelijk om de Airport tabel te filteren om vluchtgegevens voor een luchthaven van vertrek automatisch te isoleren. Aangezien rapporten moeten worden gefilterd (of gegroepeerd) op luchthavens van vertrek en aankomst tegelijkertijd, zijn er twee actieve relaties vereist. Als u deze vereiste vertaalt in een Power BI-modelontwerp, moet het model twee luchthaventabellen hebben.

Hier ziet u het verbeterde modelontwerp.

diagram met een model met vier tabellen: Date, Flight, Departure Airport en Arrival Airport.

Het model heeft nu twee luchthaventabellen: Departure Airport en Arrival Airport. Elke modelrelatie tussen deze tabellen en de Flight tabel is actief. U ziet ook dat de kolomnamen in de tabellen Departure Airport en Arrival Airport worden voorafgegaan door het woord Departure of Arrival.

Het verbeterde modelontwerp ondersteunt het produceren van het volgende rapportontwerp.

Diagram dat een rapportpagina toont, heeft twee slicers en een tabelweergave. De slicers zijn Maand en Vertrek Luchthaven.

De rapportpagina filtert op Melbourne als luchthaven van vertrek, en de tabelweergave visualiseert gegroepeerd op luchthavens van aankomst.

Notitie

Voor Import-modellen heeft de toevoeging van een andere dimensietabel geresulteerd in een grotere modelgrootte en langere vernieuwingstijden. Als zodanig is het in strijd met de aanbevelingen die worden beschreven in de technieken voor gegevensreductie voor importmodellering artikel. In het voorbeeld worden deze aanbevelingen echter overschreven door de vereiste om alleen actieve relaties te hebben.

Verder is het gebruikelijk dat dimensietabellen lage rijaantallen opslaan ten opzichte van het aantal feitentabelrijen. De toegenomen modelgrootte en vernieuwingstijden zijn dus waarschijnlijk niet te groot.

Methodologie voor herstructureren

Hier volgt een methodologie voor het herstructureren van een model van één rollenspeldimensietabel tot een ontwerp met één tabel per rol.

  1. Verwijder eventuele inactieve relaties.

  2. Overweeg de naam van de dimensietabel voor rollenspel te wijzigen om de rol beter te beschrijven. In het voorbeeld in dit artikel is de tabel Airport gerelateerd aan de kolom ArrivalAirport van de tabel Flight, dus de naam ervan wordt gewijzigd als Arrival Airport.

  3. Maak een kopie van de rollenspeltabel en geef deze een naam op die de rol weerspiegelt. Als het een importtabel is, raden we u aan een berekende tabel te maken. Als het een DirectQuery-tabel is, kunt u de Power Query-query dupliceren.

    In het voorbeeld is de Departure Airport tabel gemaakt met behulp van de volgende definitie van de berekende tabel.

    Departure Airport = 'Arrival Airport'
    
  4. Maak een actieve relatie om de nieuwe tabel te koppelen.

  5. Overweeg de naam van de kolommen in de tabellen te wijzigen, zodat ze hun rol nauwkeurig weerspiegelen. In het voorbeeld in dit artikel worden alle kolommen voorafgegaan door het woord Vertrek of Aankomst. Deze namen zorgen ervoor dat rapportvisuals standaard zelf-beschrijvende en niet-dubbelzinnige labels bevatten. Het verbetert ook de Q&A-ervaring, zodat gebruikers eenvoudig nauwkeurige vragen kunnen schrijven.

  6. Overweeg beschrijvingen toe te voegen aan rollenspeltabellen. (In het deelvenster Gegevens wordt een beschrijving weergegeven in knopinfo wanneer een auteur van een rapport de cursor boven de tabel beweegt.) Op deze manier kunt u andere details van de filterdoorgifte doorgeven aan rapportauteurs.

Inactieve relaties

In specifieke omstandigheden kunnen inactieve relaties specifieke rapportagebehoeften aanpakken.

Houd rekening met verschillende model- en rapportagevereisten:

  • Een verkoopmodel bevat een Sales tabel met twee datumkolommen: OrderDate en ShipDate.
  • Elke rij in de Sales tabel registreert één order.
  • Datumfilters worden bijna altijd toegepast op de kolom OrderDate, waarin altijd een geldige datum wordt opgeslagen.
  • Slechts één meting vereist datumfilteroverdracht naar de ShipDate kolom, die lege velden kan bevatten (totdat de order is verzonden).
  • Er is geen vereiste om en verzenddatumperioden tegelijk te filteren (of te groeperen).

Hier volgt een gedeeltelijk modeldiagram van de twee tabellen.

diagram met een model met twee tabellen: Verkoop en Datum. De tabel Sales bevat zes metingen.

Er zijn twee modelrelaties tussen de Sales en Date tabellen. In de Sales tabel hebben de kolommen OrderDate en ShipDate betrekking op de kolom Date van de Date tabel. In dit model zijn de twee rollen voor de Date tabel orderdatum en verzenddatum. Dit is de relatie met de OrderDate kolom die actief is.

Alle zes metingen, behalve één, moeten worden gefilterd op de kolom OrderDate. De meting Orders Shipped moet echter filteren op de kolom ShipDate.

Hier volgt de definitie van de Orders meting. Hiermee worden eenvoudigweg de rijen van de Sales tabel in de filtercontext geteld. Alle filters die zijn toegepast op de Date tabel worden doorgegeven aan de kolom OrderDate.

Orders = COUNTROWS(Sales)

Hier is de definitie van de Orders Shipped-meting. Het maakt gebruik van de USERELATIONSHIP DAX-functie, waarmee filterdoorgifte voor een specifieke relatie wordt geactiveerd, maar alleen tijdens de evaluatie van de expressie. In dit voorbeeld wordt de relatie met de kolom ShipDate gebruikt.

Orders Shipped =
CALCULATE(
    COUNTROWS(Sales)
    ,USERELATIONSHIP('Date'[Date], Sales[ShipDate])
)

Dit modelontwerp ondersteunt het produceren van het volgende rapportontwerp.

Diagram die een rapportpagina toont met één slicer en een tabelweergave. De slicer is Kwartaal en de tabelweergave bevat maandelijkse verkoopstatistieken.

De rapportpagina filtert op kwartaal 2019 Q4. De tabel groepeert per maand en toont verschillende verkoopstatistieken. De metingen Orders en Orders Shipped produceren verschillende resultaten. Ze gebruiken allemaal dezelfde samenvattingslogica (aantal rijen van de Sales tabel), maar verschillende Date filterpropagatie.

U ziet dat de kwartaalsnijder een blanco optie bevat. Deze optie voor de slicer verschijnt als gevolg van de uitbreiding van de tabel. Hoewel elke Sales-tabelrij een geldige orderdatum heeft, hebben sommige rijen een LEGE verzenddatum—deze bestellingen wachten nog op verzending. Tabeluitbreiding houdt ook rekening met inactieve relaties, en hierdoor kunnen BLANKS verschijnen vanwege BLANKS aan de veelzijde van de relatie (of vanwege problemen met de gegevensintegriteit).

Notitie

Beveiliging op rijniveau (RLS)-filters worden alleen doorgegeven via actieve relaties. RLS-filters worden nooit doorgegeven voor inactieve relaties, zelfs wanneer de USERELATIONSHIP DAX-functie wordt gebruikt door een metingdefinitie.

Aanbevelingen

U wordt aangeraden waar mogelijk actieve relaties te definiëren, met name wanneer RLS-rollen zijn gedefinieerd voor uw gegevensmodel. Ze verbreeden het bereik en het potentieel van hoe uw model kan worden gebruikt door rapportauteurs en gebruikers die werken met Q&A. Dit betekent dat dimensietabellen voor rollenspel moeten worden gedupliceerd in uw model.

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

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

Raadpleeg de volgende bronnen voor meer informatie over dit artikel: