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.
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.
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.
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.
Verwijder eventuele inactieve relaties.
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 kolomArrivalAirport
van de tabelFlight
, dus de naam ervan wordt gewijzigd alsArrival Airport
.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'
Maak een actieve relatie om de nieuwe tabel te koppelen.
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.
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
enShipDate
. - 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.
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.
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.
Verwante inhoud
Raadpleeg de volgende bronnen voor meer informatie over dit artikel: