Del via

Aktiv kontra inaktiv relasjonsveiledning

  • Artikkel

Denne artikkelen er rettet mot deg som en 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.

Notat

En innføring i modellrelasjoner dekkes ikke i denne artikkelen. Hvis du ikke er helt kjent med relasjoner, deres egenskaper eller hvordan du konfigurerer dem, anbefaler vi at du først leser Modellrelasjoner 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 Q&A.

Vurder et eksempel på en importmodell utformet for å analysere flyavgang i tide (OTP). Modellen har en Flight tabell, som er en faktatabell som lagrer én rad per flyvning. Hver rad registrerer flydato, flynummer, avreise- og ankomstflyplasser og eventuell forsinkelsestid (i minutter). Det finnes også en Airport tabell, som er en dimensjonstabell 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.

diagram som viser en modell som inneholder to tabeller: Flight og Airport. Relasjonsutformingen er beskrevet i avsnittet nedenfor.

Det finnes to modellrelasjoner mellom tabellene Flight og Airport. Kolonnene DepartureAirport og ArrivalAirport i Flight tabellen er knyttet til Airport kolonnen i Airport tabellen. I utforming av stjerneskjema beskrives Airport tabellen som en rollespilldimensjon. I denne modellen er de to rollene avreiseflyplass og ankomstflyplass.

Selv om denne utformingen fungerer bra for relasjonelle stjerneskjemautforminger, fungerer det ikke bra for Power BI-modeller. Dette 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 vist i dette eksemplet, er én relasjon aktiv, mens den andre er inaktiv (representert av den stiplede linjen). Nærmere bestemt er det relasjonen til den ArrivalAirport kolonnen som er aktiv, noe som betyr at filtre som brukes i Airport tabellen, 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 Airport tabellen for automatisk å isolere flydetaljer for en avreiseflyplass. Ettersom rapporter må filtrere (eller gruppere) etter avreise- og ankomstflyplasser samtidig, kreves det to aktive relasjoner. Hvis du oversetter dette kravet til en Power BI-modellutforming, må modellen ha to flyplasstabeller.

Her er den forbedrede modellutformingen.

diagram som viser en modell som inneholder fire tabeller: Dato, flyreise, avreiseflyplass og ankomstflyplass.

Modellen har nå to flyplasstabeller: Departure Airport og Arrival Airport. Hver modellrelasjon mellom disse tabellene og Flight tabellen er aktiv. Legg også merke til at kolonnenavnene i tabellene Departure Airport og Arrival Airport er prefiks med ordet Avreise eller ankomst.

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

diagram som viser at en rapportside har to slicere og et tabellvisualobjekt. Slicerne er måned og avreise flyplass.

Rapportsiden filtreres etter Melbourne som avgangsflyplass, og tabellvisualobjektet grupperes etter ankomstflyplasser.

Notat

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

Videre er det vanlig at dimensjonstabeller lagrer lave radantall i forhold til antall faktatabellrader. 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 dimensjonstabellen for rollespill for å beskrive rollen bedre. I eksemplet i denne artikkelen er Airport tabellen relatert til den ArrivalAirport kolonnen i Flight tabellen, slik at den får nytt navn som Arrival Airport.

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

    I eksemplet ble Departure Airport 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 i denne artikkelen er alle kolonnene prefiks 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 nøyaktige spørsmål.

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

Inaktive relasjoner

I bestemte tilfeller kan inaktive relasjoner dekke bestemte rapporteringsbehov.

Vurder ulike modell- og rapporteringskrav:

  • En salgsmodell inneholder en Sales tabell som har to datokolonner: OrderDate og ShipDate.
  • Hver rad i Sales tabellen registrerer én enkelt rekkefølge.
  • 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 sendes).
  • Det er ikke nødvendig å filtrere (eller gruppere) ordrer samtidig og forsendelsesdatoperioder.

Her er et delvis modelldiagram over de to tabellene.

diagram som viser en modell som inneholder to tabeller: Salg og Dato. Salg-tabellen inneholder seks mål.

Det finnes to modellrelasjoner mellom tabellene Sales og Date. Kolonnene OrderDate og ShipDate i Sales tabellen er knyttet til Date kolonnen i Date tabellen. I denne modellen er de to rollene for Date tabellen ordredato og forsendelsesdato. Det er relasjonen til den OrderDate kolonnen som er aktiv.

Alle de seks målene, unntatt ett, må filtreres etter kolonnen OrderDate. Det Orders Shipped målet må imidlertid filtrere etter ShipDate-kolonnen.

Her er måldefinisjonen for Orders. Den teller ganske enkelt radene i Sales tabellen i filterkonteksten. Eventuelle filtre som brukes på Date tabellen overføres til kolonnen OrderDate.

Orders = COUNTROWS(Sales)

Her er måldefinisjonen for Orders Shipped. Den bruker USERELATIONSHIP DAX-funksjonen, som aktiverer filteroverføring for en bestemt relasjon, men 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.

diagram som viser en rapportside med én slicer og et tabellvisualobjekt. Sliceren er Kvartal, og tabellvisualobjektet viser månedlig salgsstatistikk.

Rapportsiden filtreres etter kvartal 2019 Q4. Tabellvisualobjektet grupperer etter måned og viser ulike salgsstatistikker. Målingene Orders og Orders Shipped gir forskjellige resultater. Hver av dem bruker den samme sammendragslogikken (telle rader i Sales tabellen), men forskjellige Date tabellfilteroverføring.

Legg merke til at kvartalssliceren inneholder et BLANK-alternativ. Dette sliceralternativet vises som et resultat av tabellutvidelse. Selv om hver Sales tabellrad har en gyldig ordredato, har noen rader en TOM forsendelsesdato – disse ordrene er ennå ikke sendt. Tabellutvidelse anser 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).

Notat

Sikkerhet på radnivå (RLS) filtreres bare gjennom aktive relasjoner. RLS-filtre overføres aldri for inaktive relasjoner, selv når USERELATIONSHIP DAX-funksjonen brukes av en måldefinisjon.

Anbefalinger

Vi anbefaler at du definerer aktive relasjoner når det er mulig, spesielt når RLS-roller er definert for datamodellen. De utvider omfanget og potensialet for hvordan modellen kan brukes av rapportforfattere, og brukere som arbeider med Q&A. Det betyr at rollespilldimensjonstabeller bør dupliseres i modellen.

I bestemte tilfeller kan du imidlertid definere én eller flere inaktive relasjoner for en rollespilldimensjonstabell. Du kan vurdere denne fremgangsmåten når:

  • Det er ikke nødvendig at visualobjekter i rapporten filtreres samtidig etter ulike roller.
  • 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: