Aktiv kontra inaktiv relasjonsveiledning

Denne artikkelen er rettet mot deg som datamodellerer som arbeider med Power BI Desktop. Den gir deg veiledning om når du skal opprette aktive eller inaktive modellrelasjoner. Som standard overfører aktive relasjoner filtre til andre tabeller. Inaktiv relasjon overfører imidlertid bare filtre når et DAX-uttrykk aktiverer (bruker) relasjonen.

Merk

En innføring i modellrelasjoner dekkes ikke i denne artikkelen. Hvis du ikke er helt kjent med relasjoner, egenskaper eller hvordan du konfigurerer dem, anbefaler vi at du først leser modellrelasjonene i Power BI Desktop-artikkelen .

Det er også viktig at du har en forståelse av utforming av stjerneskjema. Hvis du vil ha mer informasjon, kan du se Forstå stjerneskjema og viktigheten for Power BI.

Aktive relasjoner

Generelt anbefaler vi at du definerer aktive relasjoner når det er mulig. De utvider omfanget og potensialet for hvordan modellen kan brukes av rapportforfattere og brukere som arbeider med spørsmål og svar.

Vurder et eksempel på en importmodell som er utformet for å analysere flyavgang i tide (OTP). Modellen har en Flight-tabell , som er en faktatypetabell som lagrer én rad per fly. Hver rad registrerer flydato, flynummer, avreise- og ankomstflyplasser og eventuell forsinkelsestid (i minutter). Det finnes også en flyplasstabell , som er en dimensjonstypetabell som lagrer én rad per flyplass. Hver rad beskriver flyplasskoden, flyplassnavnet og landet eller området.

Her er et delvis modelldiagram over de to tabellene.

Det finnes to modellrelasjoner mellom flight- og flyplasstabellene. I Flight-tabellen er Kolonnene DepartureAirport og ArrivalAirport knyttet til flyplasskolonnen i flyplasstabellen. I utforming av stjerneskjema beskrives flyplasstabellen som en rollespilldimensjon. I denne modellen er de to rollene avreise flyplass og ankomst flyplass.

Selv om denne utformingen fungerer bra for relasjonelle stjerneskjemautforminger, fungerer den ikke for Power BI-modeller. Det er fordi modellrelasjoner er baner for filteroverføring, og disse banene må være deterministiske. Hvis du vil ha mer informasjon om hvordan du sikrer at filteroverføringsbaner er deterministiske, kan du se løse tvetydighet i relasjonsbanen. Derfor, som beskrevet i dette eksemplet, er én relasjon aktiv, mens den andre er inaktiv (representert av den stiplede linjen). Spesielt er det relasjonen til ArrivalAirport-kolonnen som er aktiv. Dette betyr at filtre som brukes på flyplasstabellen, automatisk overføres til ArrivalAirport-kolonnen i Flight-tabellen.

Denne modellutformingen gir alvorlige begrensninger på hvordan dataene kan rapporteres. Spesielt er det ikke mulig å filtrere flyplasstabellen for automatisk å isolere flydetaljer for en avreiseflyplass. Ettersom rapporteringskrav innebærer filtrering (eller gruppering) etter avreise- og ankomstflyplasser samtidig, er det behov for to aktive relasjoner. Hvis du oversetter dette kravet til en Power BI-modellutforming, må modellen ha to flyplasstabeller.

Her er den forbedrede modellutformingen.

Modellen har nå to flyplasstabeller: Avreiseflyplass og ankomstflyplass. Modellrelasjonene mellom disse tabellene og Flight-tabellen er aktive. Legg også merke til at kolonnenavnene i tabellene Avreiseflyplass og Ankomstflyplass er prefikset med ordet Avreise eller Ankomst.

Den forbedrede modellutformingen støtter produksjon av følgende rapportutforming.

Rapportsiden filtrerer etter Melbourne som avreiseflyplass, og tabellvisualobjektet grupperer etter ankomstflyplasser.

Merk

For importmodeller har den ekstra tabellen resultert i økt modellstørrelse og lengre oppdateringstider. Som sådan motsier den anbefalingene som er beskrevet i artikkelen Datareduksjonsteknikker for importmodellering . I eksemplet overstyrer imidlertid kravet om å bare ha aktive relasjoner disse anbefalingene.

Videre er det vanlig at dimensjonstypetabeller inneholder lave radantall i forhold til antall faktatyper i tabellrader. Det er derfor ikke sannsynlig at de økte modellstørrelsene og oppdateringstidene er for store.

Refaktoreringsmetodikk

Her er en metodikk for å refaktorere en modell fra en enkelt rollespilldimensjonstabell, til en utforming med én tabell per rolle.

1. Fjern inaktive relasjoner.

2. Vurder å gi nytt navn til den rollespillende dimensjonstypetabellen for å beskrive rollen bedre. I eksemplet er flyplasstabellen relatert til ArrivalAirport-kolonnen i Flight-tabellen, så den har fått nytt navn som Ankomstflyplass.

3. Opprett en kopi av rollespilltabellen, og gi den et navn som gjenspeiler rollen. Hvis det er en importtabell, anbefaler vi at du definerer en beregnet tabell. Hvis det er en DirectQuery-tabell, kan du duplisere Power Query-spørringen.

   I eksemplet ble Avreiseflyplass-tabellen opprettet ved hjelp av følgende beregnede tabelldefinisjon.

   Departure Airport = 'Arrival Airport'
   

4. Opprett en aktiv relasjon for å relatere den nye tabellen.

5. Vurder å gi nytt navn til kolonnene i tabellene, slik at de gjenspeiler rollen deres nøyaktig. I eksemplet er alle kolonnene prefikset med ordet Avreise eller Ankomst. Disse navnene sikrer at rapportvisualobjekter som standard har selvbeskrivende og ikke-tvetydige etiketter. Det forbedrer også Q&A-opplevelsen, slik at brukerne enkelt kan skrive spørsmålene sine.

6. Vurder å legge til beskrivelser i rollespilltabeller. (I Feltruten vises en beskrivelse i et verktøytips når en rapportforfatter holder markøren over tabellen.) På denne måten kan du formidle eventuelle ekstra filteroverføringsdetaljer til rapportforfatterne.

Inaktive relasjoner

I bestemte tilfeller kan inaktive relasjoner dekke spesielle rapporteringsbehov.

La oss nå vurdere ulike modell- og rapporteringskrav:

• En salgsmodell inneholder en Salgstabell som har to datokolonner: Ordredato og Forsendelsesdato
• Hver rad i Salg-tabellen registrerer én enkelt ordre
• Datofiltre brukes nesten alltid på OrderDate-kolonnen , som alltid lagrer en gyldig dato
• Bare ett mål krever datofilteroverføring til ShipDate-kolonnen , som kan inneholde BLANK-er (inntil bestillingen leveres)
• Det er ikke noe krav om samtidig filtrering (eller grupper etter) ordre - og forsendelsesdatoperioder

Her er et delvis modelldiagram over de to tabellene.

Det finnes to modellrelasjoner mellom tabellene Salg og Dato . Kolonnene Ordredato og Forsendelsesdato er knyttet til Dato-kolonnen i Dato-tabellen i salg-tabellen. I denne modellen er de to rollene for Dato-tabellen ordredato og forsendelsesdato. Det er relasjonen til OrderDate-kolonnen som er aktiv.

Alle de seks målene, unntatt ett, må filtreres etter OrderDate-kolonnen . Ordrer sendt må imidlertid filtrere etter ShipDate-kolonnen .

Her er måldefinisjonen ordrer . Den teller ganske enkelt radene i Salg-tabellen i filterkonteksten. Alle filtre som brukes i Dato-tabellen , overføres til OrderDate-kolonnen .

Orders = COUNTROWS(Sales)

Her er måldefinisjonen Ordrer sendt . Den bruker DAX-funksjonen USERELATIONSHIP , som aktiverer filteroverføring for en bestemt relasjon bare under evalueringen av uttrykket. I dette eksemplet brukes relasjonen til ShipDate-kolonnen .

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

Denne modellutformingen støtter produksjon av følgende rapportutforming.

Rapportsiden filtreres etter kvartal 2019 4. kvartal. Tabellvisualobjektet grupperer etter måned og viser ulike salgsstatistikker. Ordrer og ordrer sendt mål gir forskjellige resultater. Hver av dem bruker den samme sammendragslogikken (telle rader i Salg-tabellen ), men ulike datotabellfilteroverføringer .

Legg merke til at kvartalssliceren inneholder et BLANK-element. Dette slicerelementet vises som et resultat av tabellutvidelse. Selv om hver salgstabellrad har en ordredato, har noen rader en TOM forsendelsesdato – disse ordrene er ennå ikke sendt. Tabellutvidelse vurderer også inaktive relasjoner, og derfor kan BLANK-er vises på grunn av BLANK-er på mange-siden av relasjonen, eller på grunn av problemer med dataintegritet.

Merk

Sikkerhetsfiltre på radnivå overføres bare gjennom aktive relasjoner. Sikkerhetsfiltre på radnivå overføres ikke for inaktive relasjoner selv om UseRelationship legges til eksplisitt i en måldefinisjon.

Anbefalinger

Sammendrag anbefaler vi at du definerer aktive relasjoner når det er mulig, spesielt når sikkerhetsroller på radnivå er definert for datamodellen. De utvider omfanget og potensialet for hvordan modellen kan brukes av rapportforfattere og brukere som arbeider med spørsmål og svar. Det betyr at rollespillende dimensjonstypetabeller skal dupliseres i modellen.

I bestemte tilfeller kan du imidlertid definere én eller flere inaktive relasjoner for en rollespillende dimensjonstypetabell. Du kan vurdere denne utformingen når:

• Det er ikke noe krav for rapportvisualobjekter å filtrere etter ulike roller samtidig
• Du bruker DAX-funksjonen USERELATIONSHIP til å aktivere en bestemt relasjon for relevante modellberegninger

Relatert innhold

Hvis du vil ha mer informasjon om denne artikkelen, kan du se følgende ressurser:

• Modellrelasjoner i Power BI Desktop
• Forstå stjerneskjema og viktigheten for Power BI
• Veiledning for feilsøking av relasjoner
• Spørsmål? Prøv å spørre Power BI-fellesskap
• Forslag? Bidra med ideer for å forbedre Power BI