Vägledning för aktiva kontra inaktiva relationer

Den här artikeln riktar sig till dig som datamodellerare som arbetar med Power BI Desktop. Det ger dig vägledning om när du ska skapa aktiva eller inaktiva modellrelationer. Som standard sprider aktiva relationer filter till andra tabeller. Inaktiv relation sprider dock bara filter när ett DAX-uttryck aktiverar (använder) relationen.

Not

En introduktion till modellrelationer beskrivs inte i den här artikeln. Om du inte är helt bekant med relationer, deras egenskaper eller hur du konfigurerar dem rekommenderar vi att du först läser artikeln Model-relationer i Power BI Desktop.

Det är också viktigt att du har en förståelse för stjärnscheman. För mer information, se För att förstå stjärnschema och dess betydelse för Power BI.

Aktiva relationer

I allmänhet rekommenderar vi att du definierar aktiva relationer när det är möjligt. De breddar omfattningen och potentialen för hur din modell kan användas av rapportförfattare och användare som arbetar med Q&A.

Överväg ett exempel på en Import-modell utformad för att analysera prestanda för flygflyg i tid (OTP). Modellen har en Flight tabell, som är en faktatabell som lagrar en rad per flygning. Varje rad registrerar flygdatum, flygnummer, avgångs- och ankomstflygplatser samt eventuell fördröjningstid (i minuter). Det finns också en Airport-tabell, som är en -dimensionstabell som lagrar en rad per flygplats. Varje rad beskriver flygplatskoden, flygplatsnamnet och landet eller regionen.

Här är ett partiellt modelldiagram över de två tabellerna.

Det finns två modellrelationer mellan tabellerna Flight och Airport. I tabellen Flight relaterar kolumnerna DepartureAirport och ArrivalAirport till kolumnen Airport i tabellen Airport. I star-schemadesign beskrivs Airport-tabellen som en rollspelsdimension. I den här modellen är de två rollerna avgångsflygplatsen och ankomstflygplatsen.

Även om den här designen fungerar bra för relationsstjärnaschemadesign fungerar den inte bra för Power BI-modeller. Det beror på att modellrelationer är sökvägar för filterspridning, och dessa sökvägar måste vara deterministiska. Mer information om hur du ser till att filterspridningssökvägar är deterministiska finns i lösa tvetydighet för relationssökväg. Därför är den ena relationen aktiv medan den andra är inaktiv (representerad av den streckade linjen). Mer specifikt är det relationen till den ArrivalAirport kolumnen som är aktiv, vilket innebär att filter som tillämpas på den Airport tabellen automatiskt sprids till kolumnen ArrivalAirport i Flight-tabellen.

Den här modelldesignen medför allvarliga begränsningar för hur data kan rapporteras. Mer specifikt går det inte att filtrera Airport-tabellen för att automatiskt isolera flyginformation för en avgångsflygplats. Eftersom rapporter måste filtrera (eller gruppera) efter avgångs- och ankomstflygplatser samtidigtkrävs två aktiva relationer. Att översätta det här kravet till en Power BI-modelldesign innebär att modellen måste ha två flygplatstabeller.

Här är den förbättrade modelldesignen.

Modellen har nu två flygplatstabeller: Departure Airport och Arrival Airport. Varje modellrelation mellan dessa tabeller och tabellen Flight är aktiv. Observera också att kolumnnamnen i tabellerna Departure Airport och Arrival Airport är prefixet med ordet Departure eller Arrival.

Den förbättrade modelldesignen stöder skapande av följande rapportdesign.

Rapportsidan filtrerar efter Melbourne som avgångsflygplats och tabellens visuella grupper efter ankomstflygplatser.

Not

För importmodeller har tillägg av en annan dimensionstabell resulterat i en ökad modellstorlek och längre uppdateringstider. Därför strider det mot rekommendationerna som beskrivs i artikeln Datareduktionstekniker för importmodellering. I exemplet åsidosätter dock kravet på att endast ha aktiva relationer dessa rekommendationer.

Dessutom är det vanligt att dimensionstabeller lagrar låga radantal i förhållande till antal faktatabellrader. Därför är den ökade modellstorleken och uppdateringstiderna sannolikt inte alltför stora.

Refaktoriseringsmetodik

Här är en metod för att omstrukturera en modell från en enda rollspelsdimensionstabell till en design med en tabell per roll.

1. Ta bort eventuella inaktiva relationer.

2. Överväg att byta namn på dimensionstabellen för rollspel för att bättre beskriva dess roll. I exemplet i den här artikeln är tabellen Airport relaterad till kolumnen ArrivalAirport i tabellen Flight, så den har bytt namn till Arrival Airport.

3. Skapa en kopia av rollspelstabellen och ge den ett namn som återspeglar dess roll. Om det är en importtabell rekommenderar vi att du skapar en beräknad tabell. Om det är en DirectQuery-tabell kan du duplicera Power Query-frågan.

   I exemplet skapades tabellen Departure Airport med hjälp av följande beräknade tabelldefinition.

   Departure Airport = 'Arrival Airport'
   

4. Skapa en aktiv relation för att relatera den nya tabellen.

5. Överväg att byta namn på kolumnerna i tabellerna så att de återspeglar sin roll korrekt. I exemplet i den här artikeln prefixas alla kolumner med ordet Departure eller Arrival. Dessa namn säkerställer att rapportvisualiseringar som standard har självbeskrivande och icke-tvetydiga etiketter. Det förbättrar även Q&A-upplevelsen, så att användarna enkelt kan skriva korrekta frågor.

6. Överväg att lägga till beskrivningar i rollspelstabeller. (I fönstret Data visas en beskrivning i ett verktygstips när en rapportförfattare håller markören över tabellen.) På så sätt kan du förmedla ytterligare detaljer om spridning av filter till rapportförfattare.

Inaktiva relationer

Under vissa omständigheter kan inaktiva relationer hantera specifika rapporteringsbehov.

Överväg olika modell- och rapporteringskrav:

• En försäljningsmodell innehåller en Sales tabell med två datumkolumner: OrderDate och ShipDate.
• Varje rad i tabellen Sales registrerar en enskild ordning.
• Datumfilter tillämpas nästan alltid på kolumnen OrderDate, som alltid lagrar ett giltigt datum.
• Endast ett mått kräver spridning av datumfiltret till kolumnen ShipDate, som kan innehålla tomma värden (tills beställningen skickas).
• Det finns inget krav på att samtidigt filtrera (eller gruppera) order och leveransdatumperioder.

Här är ett partiellt modelldiagram över de två tabellerna.

Det finns två modellrelationer mellan tabellerna Sales och Date. I tabellen Sales relaterar kolumnerna OrderDate och ShipDate till kolumnen Date i tabellen Date. I den här modellen är de två rollerna för tabellen Dateorderdatum och leveransdatum. Det är relationen till OrderDate-kolumnen som är aktiv.

Alla de sex måtten – utom ett – måste filtreras efter kolumnen OrderDate. Måttet Orders Shipped måste filtreras efter kolumnen ShipDate.

Här är definitionen av måttet Orders. Det räknar bara raderna i Sales-tabellen i filterkontexten. Alla filter som tillämpas på Date-tabellen sprids till kolumnen OrderDate.

Orders = COUNTROWS(Sales)

Definitionen för Orders Shipped-måttet är här. Den använder funktionen USERELATIONSHIP DAX, som aktiverar filterspridning för en specifik relation, men bara under utvärderingen av uttrycket. I det här exemplet används relationen till kolumnen ShipDate.

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

Den här modelldesignen har stöd för att skapa följande rapportdesign.

Rapportsidan filtrerar efter kvartal 2019 Q4. Tabellen grupperar efter månad och visar olika försäljningsstatistik. Måtten Orders och Orders Shipped ger olika resultat. De använder samma sammanfattningslogik (antal rader i tabellen Sales), men olika filtrerspridning för tabell Date.

Observera att kvartals utsnittet innehåller ett BLANK-alternativ. Det här utsnittsalternativet visas som ett resultat av tabellexpansion. Varje Sales tabellrad har ett giltigt orderdatum, men vissa rader har ett BLANK-leveransdatum – dessa beställningar har ännu inte levererats. Tabellexpansionen tar även hänsyn till inaktiva relationer, och därför kan BLANK:er visas på grund av BLANK:er på många sidor av relationen (eller på grund av dataintegritetsproblem).

OBS

Säkerhetsfilter på radnivå (RLS) sprids endast via aktiva relationer. RLS-filter sprider sig aldrig för inaktiva relationer, även när USERELATIONSHIP DAX-funktionen används i en måttdefinition.

Rekommendationer

Vi rekommenderar att du definierar aktiva relationer när det är möjligt, särskilt när RLS-roller definieras för din datamodell. De breddar omfattningen och potentialen för hur din modell kan användas av rapportförfattare och användare som arbetar med Q&A. Det innebär att dimensionstabeller för rollspel ska dupliceras i din modell.

Under vissa omständigheter kan du dock definiera en eller flera inaktiva relationer för en rollspelsdimensionstabell. Du kan överväga den här metoden när:

• Det finns inget krav på att rapportvisualiseringar ska filtreras efter olika roller samtidigt.
• Du använder DAX-funktionen USERELATIONSHIP för att aktivera en specifik relation för relevanta modellberäkningar.

Relaterat innehåll

Mer information om den här artikeln finns i följande resurser:

• modellrelationer i Power BI Desktop
• Förstå stjärnschema och vikten för Power BI
• Vägledning för felsökning av relationer
• Frågor? Prova att fråga Fabric-communityn
• Förslag? Bidra med idéer för att förbättra Fabric