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.

Kommentar

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 Modellrelationer i Power BI Desktop .

Det är också viktigt att du har en förståelse för star-schemadesign. Mer information finns i Förstå star-schema och vikten 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.

Tänk dig ett exempel på en importmodell som är utformad för att analysera flygresans prestanda i tid (OTP). Modellen har en Flight-tabell , som är en tabell av faktatyp 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 flygplatstabell , som är en tabell av dimensionstyp 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 flygplatskolumneni tabellen Airport. I star-schemadesign beskrivs flygplatstabellen som en rollspelsdimension. I den här modellen är de två rollerna avgångsflygplats och ankomstflygplats.

Även om den här designen fungerar bra för relationsstjärnaschemadesign, så fungerar den inte 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 relationssökvägens tvetydighet. Därför, enligt beskrivningen i det här exemplet, är en relation aktiv medan den andra är inaktiv (representeras av den streckade linjen). Mer specifikt är det relationen till kolumnen ArrivalAirport som är aktiv. Det innebär att filter som tillämpas på flygplatstabellen automatiskt sprids till kolumnen ArrivalAirport i tabellen Flight.

Den här modelldesignen medför allvarliga begränsningar för hur data kan rapporteras. Mer specifikt går det inte att filtrera flygplatstabellen för att automatiskt isolera flyginformation för en avgångsflygplats. Eftersom rapporteringskraven omfattar filtrering (eller gruppering) efter avgångs- och ankomstflygplatser samtidigt behö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: Avgångsflygplatsen och Ankomstflygplatsen. Modellrelationerna mellan dessa tabeller och tabellen Flight är aktiva. Observera också att kolumnnamnen i tabellerna Avgångsflygplats och Ankomstflygplats har prefixet Avgång eller Ankomst.

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

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

Kommentar

För importmodeller har den ytterligare tabellen 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 tabeller av dimensionstyp innehåller låga radantal i förhållande till antal tabellrader av faktatyp. 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 tabell av dimensionstyp med rollspel till en design med en tabell per roll.

1. Ta bort eventuella inaktiva relationer.

2. Överväg att byta namn på tabellen av dimensionstyp för rollspel för att bättre beskriva dess roll. I exemplet är tabellen Flygplats relaterad till kolumnen ArrivalAirport i tabellen Flight, så den har bytt namn till Ankomstflygplats.

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

   I exemplet skapades tabellen Avgångsflygplats 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 är alla kolumner prefix med ordet Avgång eller Ankomst. 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 sina frågor.

6. Överväg att lägga till beskrivningar i rollspelstabeller. (I Fältfönstret , en beskrivning visas i en knappbeskrivning när en rapportförfattare hovrar markören över tabellen.) På så sätt kan du förmedla ytterligare information om filterspridning till rapportförfattarna.

Inaktiva relationer

Under vissa omständigheter kan inaktiva relationer hantera särskilda rapporteringsbehov.

Nu ska vi överväga olika modell- och rapporteringskrav:

• En försäljningsmodell innehåller en sales-tabell som har två datumkolumner: OrderDate och ShipDate
• Varje rad i tabellen Försäljning registrerar en enskild order
• Datumfilter tillämpas nästan alltid på kolumnen OrderDate , som alltid lagrar ett giltigt datum
• Endast ett mått kräver datumfilterspridning till kolumnen ShipDate , som kan innehålla BLANK:er (tills ordern levereras)
• Det finns inget krav på att samtidigt filtrera (eller gruppera efter) order - och leveransdatumperioder

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

Det finns två modellrelationer mellan tabellerna Försäljning och Datum . I tabellen Försäljning relaterar kolumnerna OrderDate och ShipDate till kolumnen Datum i tabellen Datum . I den här modellen är de två rollerna för tabellen Datum orderdatum och leveransdatum. Det är relationen till kolumnen OrderDate som är aktiv.

Alla sex mått – utom ett – måste filtreras efter kolumnen OrderDate . Måttet Order Shipped måste dock filtreras efter kolumnen ShipDate .

Här är måttdefinitionen Beställningar . Det räknar helt enkelt raderna i tabellen Försäljning i filterkontexten. Alla filter som tillämpas på tabellen Datum sprids till kolumnen OrderDate .

Orders = COUNTROWS(Sales)

Här är måttdefinitionen Beställningar levererade . Den använder dax-funktionen USERELATIONSHIP , som aktiverar filterspridning för en specifik relation endast 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. Det visuella tabellobjektet grupperar efter månad och visar olika försäljningsstatistik. Måtten Order och Orders Shipped ger olika resultat. Var och en använder samma sammanfattningslogik (antal rader i tabellen Försäljning ), men olika spridning av datumtabellfilter .

Observera att kvartals utsnittet innehåller ett BLANK-objekt. Det här utsnittsobjektet visas som ett resultat av tabellexpansionen. Varje försäljningstabellrad har ett 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.

Kommentar

Säkerhetsfilter på radnivå sprids endast via aktiva relationer. Säkerhetsfilter på radnivå sprids inte för inaktiva relationer även om UseRelationship uttryckligen läggs till i en måttdefinition.

Rekommendationer

Sammanfattningsvis rekommenderar vi att du definierar aktiva relationer när det är möjligt, särskilt när säkerhetsroller på radnivå definieras för datamodellen. 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 tabeller av dimensionstyp av rollspel ska dupliceras i din modell.

Under vissa omständigheter kan du dock definiera en eller flera inaktiva relationer för en tabell av rollspelsdimensionstyp. Du kan tänka på den här designen 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å star-schema och vikten för Power BI
• Vägledning för relationsfelsökning
• Frågor? Prova att fråga Power BI Community
• Förslag? Bidra med idéer för att förbättra Power BI