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 relaties worden echter alleen filters 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, hun eigenschappen of hoe u ze configureert, raden we u aan eerst de modelrelaties in Power BI Desktop te lezen.
Het is ook belangrijk dat u inzicht hebt in het ontwerp van stervormige schema's. Zie Meer informatie over stervormige schema's en het belang van 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 met Q&A werken.
Bekijk een voorbeeld van een Import-model dat is ontworpen voor het analyseren van de on-time prestaties van luchtvaartmaatschappijen (OTP). Het model heeft een flight-tabel , een feitentabel die één rij per vlucht opslaat. Elke rij registreert de vluchtdatum, het vluchtnummer, de luchthavens van vertrek en aankomst en eventuele vertragingstijd (in minuten). Er is ook een tabel Airport , een dimensietabel met één rij per luchthaven. 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 tabellen Flight en Airport . In de tabel Flight hebben de kolommen DepartureAirport en ArrivalAirport betrekking op de kolom Luchthaven van de tabel Luchthaven . In stervormig schemaontwerp wordt de tabel Airport beschreven als een rollenspeldimensie. In dit model zijn de twee rollen de luchthaven van vertrek en de luchthaven van aankomst.
Hoewel dit ontwerp goed werkt voor relationele stervormige schemaontwerpen, is dit niet geschikt voor Power BI-modellen. Dit 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, dubbelzinnigheid van relatiepaden oplossen. Daarom, zoals beschreven in dit voorbeeld, is één relatie actief terwijl de andere inactief is (vertegenwoordigd door de stippellijn). Het is met name de relatie met de kolom ArrivalAirport die actief is. Dit betekent dat filters die zijn toegepast op de tabel Airport automatisch worden doorgegeven aan de kolom ArrivalAirport van de tabel Flight.
Dit modelontwerp legt ernstige beperkingen op voor de wijze waarop de gegevens kunnen worden gerapporteerd. Het is niet mogelijk om de tabel Luchthaven te filteren om vluchtgegevens voor een vertrekhaven automatisch te isoleren. Aangezien rapportagevereisten betrekking hebben op filteren (of groeperen) op vertrek- en aankomstluchthavens tegelijk, zijn er twee actieve relaties nodig. 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: Vertrek airport en aankomst luchthaven. De modelrelaties tussen deze tabellen en de tabel Flight zijn actief. U ziet ook dat de kolomnamen in de tabellen Departure Airport en Arrival Airport worden voorafgegaan door het woord Vertrek of Aankomst.
Het verbeterde modelontwerp ondersteunt het produceren van het volgende rapportontwerp.
De rapportpagina filtert door Melbourne als de luchthaven van vertrek en de tabelvisual wordt gegroepeerd op luchthavens van aankomst.
Notitie
Voor Import-modellen heeft de extra tabel geresulteerd in een grotere modelgrootte en langere vernieuwingstijden. Daarom is het in strijd met de aanbevelingen die worden beschreven in de technieken voor gegevensreductie voor importmodellering . In het voorbeeld worden deze aanbevelingen echter overschreven door de vereiste om alleen actieve relaties te hebben.
Verder is het gebruikelijk dat dimensietabellen weinig rijen bevatten 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 is de tabel Airport gerelateerd aan de kolom ArrivalAirport van de tabel Flight , dus de naam is gewijzigd in Arrival 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 definiëren. Als het een DirectQuery-tabel is, kunt u de Power Query-query dupliceren.
In het voorbeeld is de tabel Departure Airport gemaakt met behulp van de volgende berekende tabeldefinitie.
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 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 hun vragen kunnen schrijven.
Overweeg beschrijvingen toe te voegen aan rollenspeltabellen. (In de Deelvenster Velden , een beschrijving wordt weergegeven in knopinfo wanneer een auteur van een rapport de cursor boven de tabel beweegt.) Op deze manier kunt u eventuele aanvullende details van de filterdoorgifte doorgeven aan uw rapportauteurs.
Inactieve relaties
In specifieke omstandigheden kunnen inactieve relaties speciale rapportagebehoeften aanpakken.
Laten we nu rekening houden met verschillende model- en rapportagevereisten:
- Een verkoopmodel bevat een tabel Sales met twee datumkolommen: OrderDate en ShipDate
- Elke rij in de tabel Verkoop registreert één order
- Datumfilters worden bijna altijd toegepast op de kolom Orderdatum, waarin altijd een geldige datum wordt opgeslagen
- Slechts één meting vereist datumfilterdoorgifte naar de kolom ShipDate , die BLANK's kan bevatten (totdat de order is verzonden)
- Er is geen vereiste om order- en verzenddatumperioden tegelijk te filteren (of te groeperen op)
Hier volgt een gedeeltelijk modeldiagram van de twee tabellen.
Er zijn twee modelrelaties tussen de tabellen Verkoop en Datum . In de tabel Sales hebben de kolommen OrderDate en ShipDate betrekking op de kolom Date van de tabel Date. In dit model zijn de twee rollen voor de tabel Datum orderdatum en verzenddatum. Dit is de relatie met de kolom OrderDate die actief is.
Alle zes metingen, behalve één, moeten worden gefilterd op de kolom Orderdatum . De meting Verzonden orders moet echter worden gefilterd op de kolom ShipDate .
Hier volgt de metingdefinitie Orders . In de filtercontext worden simpelweg de rijen van de tabel Sales geteld. Alle filters die worden toegepast op de tabel Date , worden doorgegeven aan de kolom OrderDatum .
Orders = COUNTROWS(Sales)
Hier volgt de definitie van de meting Orders Shipped . Het maakt gebruik van de DAX-functie USERELATIONSHIP , waarmee filterdoorgifte voor een specifieke relatie alleen tijdens de evaluatie van de expressie wordt geactiveerd. 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. In de tabelvisual wordt per maand gegroepeerd en worden verschillende verkoopstatistieken weergegeven. De metingen orders en verzonden orders produceren verschillende resultaten. Ze gebruiken allemaal dezelfde samenvattingslogica (aantal rijen van de tabel Sales ), maar verschillende doorgifte van datumtabelfilters.
U ziet dat de kwartslicer een LEEG item bevat. Dit slicer-item wordt weergegeven als gevolg van tabeluitbreiding. Hoewel elke tabelrij Verkoop een orderdatum heeft, hebben sommige rijen een LEGE verzenddatum. Deze orders moeten nog worden verzonden. Tabeluitbreiding houdt ook rekening met inactieve relaties en daarom kunnen BLANK's worden weergegeven als gevolg van BLANK's aan de veel-kant van de relatie of vanwege problemen met de gegevensintegriteit.
Notitie
Beveiligingsfilters op rijniveau worden alleen doorgegeven via actieve relaties. Beveiligingsfilters op rijniveau worden niet doorgegeven voor inactieve relaties, zelfs niet als UseRelationship expliciet wordt toegevoegd aan een metingdefinitie.
Aanbevelingen
Kortom, we raden u aan om waar mogelijk actieve relaties te definiëren, met name wanneer beveiligingsrollen op rijniveau zijn gedefinieerd voor uw gegevensmodel. Ze verbreeden het bereik en het potentieel van hoe uw model kan worden gebruikt door rapportauteurs en gebruikers die met Q&A werken. Dit betekent dat rollenspeldimensietabellen moeten worden gedupliceerd in uw model.
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 DAX-functie USERELATIONSHIP om een specifieke relatie te activeren voor relevante modelberekeningen
Gerelateerde inhoud
Raadpleeg de volgende bronnen voor meer informatie over dit artikel:
Feedback
Binnenkort beschikbaar: In de loop van 2024 zullen we GitHub Issues geleidelijk uitfaseren als het feedbackmechanisme voor inhoud. Het wordt vervangen door een nieuw feedbacksysteem. Zie voor meer informatie: https://aka.ms/ContentUserFeedback.
Feedback verzenden en weergeven voor