Veiledning for toveis relasjoner

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 toveis modellrelasjoner. En toveis relasjon er en relasjon som filtreres i begge retninger.

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.

Generelt anbefaler vi at du minimerer bruken av toveisrelasjoner. Det er fordi de kan påvirke ytelsen til modellspørringen negativt, og muligens levere forvirrende opplevelser for rapportbrukerne.

Det finnes imidlertid tre scenarioer når toveis filtrering kan løse spesifikke krav:

• Spesielle modellrelasjoner
• sliceralternativer «med data»
• Analyse av dimensjon til dimensjon

Spesielle modellrelasjoner

Toveisrelasjoner spiller en viktig rolle når du oppretter følgende to spesielle modellrelasjonstyper:

• Én-til-én: Alle én-til-én-relasjoner må være toveis – det er ikke mulig å konfigurere ellers. Vanligvis anbefaler vi ikke å opprette disse typene relasjoner. Hvis du vil ha en fullstendig diskusjon og alternative utformingsmønstre, kan du se én-til-én-relasjonsveiledning.
• Mange-til-mange-: Når du relaterer to dimensjonstabeller, kreves det en brotabell. Det kreves et toveis filter for å sikre at filtre overføres over brotabellen. Hvis du vil ha mer informasjon, kan du se Veiledning for mange-til-mange-relasjoner.

Sliceralternativer «med data»

Toveisrelasjoner kan levere slicere som begrenser alternativer til hvor dataene finnes. (Hvis du er kjent med Excel-pivottabeller og slicere, er det standard virkemåte når du henter data fra en Semantisk Power BI-modell eller en Analysis Services-modell.) Hvis du vil forklare hva det betyr, må du først vurdere følgende modelldiagram.

Den første tabellen heter Customer., og den inneholder tre kolonner: Country-Region, Customerog CustomerCode. Den andre tabellen heter Product, og den inneholder tre kolonner: Color, Productog SKU. Den tredje tabellen heter Sales, og den inneholder fire kolonner: CustomerCode, OrderDate, Quantityog SKU. Tabellene Customer og Product er dimensjonstabeller, og hver av dem har en én-til-mange-relasjon til Sales-tabellen. Hver relasjon filtreres i én retning.

For å beskrive hvordan toveis filtrering fungerer, har modelldiagrammet blitt endret for å vise tabellradene. Alle eksempler i denne artikkelen er basert på disse dataene.

Raddetaljene for de tre tabellene er beskrevet i følgende punktliste:

• Tabellen Customer har to rader:
  • CustomerCode CUST-01, CustomerCustomer-1, Country-RegionUSA
  • CustomerCode CUST-02, CustomerCustomer-2, Country-RegionAustralia
• Tabellen Product har tre rader:
  • SKU CL-01, ProductT-skjorte, ColorGrønn
  • SKU CL-02, ProductJeans, ColorBlå
  • SKU AC-01, ProductHatt, ColorBlå
• Tabellen Sales har tre rader:
  • OrderDate 1. januar 2019CustomerCodeCUST-01, SKUCL-01, Quantity10
  • OrderDate 2. februar 2019CustomerCodeCUST-01, SKUCL-02, Quantity20
  • OrderDate 3. mars 2019, CustomerCodeCUST-02, SKUCL-01, Quantity30

Vurder nå følgende rapportside.

Siden består av to slicere og et kortvisualobjekt. Den første sliceren er basert på Country-Region-feltet, og den har to alternativer: Australia og USA. Det er for tiden skiver av Australia. Den andre sliceren er basert på Product feltet, og den har tre alternativer: Hat, Jeans og T-skjorte. Ingen elementer er valgt (det vil si at ingen produkter filtreres). Kortvisualobjektet viser et antall på 30.

Når rapportbrukere deler opp etter Australia, vil du kanskje begrense produktsliceren til å vise alternativer der data relaterer til australske salg. Det er det som er ment ved å vise sliceralternativene «med data». Du kan oppnå denne virkemåten ved å angi relasjonen mellom tabellene Product og Sales for å filtrere i begge retninger.

Produktsliceren viser nå et enkelt alternativ: T-skjorte. Dette alternativet representerer det eneste produktet som selges til australske kunder.

Først anbefaler vi at du vurderer nøye om denne utformingen fungerer for rapportbrukerne. Noen rapportbrukere synes opplevelsen er forvirrende fordi de ikke forstår hvorfor sliceralternativer vises dynamisk eller forsvinner når de samhandler med andre slicere.

Hvis du bestemmer deg for å vise sliceralternativene «med data», anbefaler vi ikke at du konfigurerer en toveis relasjon. Toveisrelasjoner krever mer behandling, slik at de kan påvirke spørringsytelsen negativt, spesielt ettersom antall toveisrelasjoner i modellen øker.

Det finnes en bedre måte å oppnå det samme resultatet på: I stedet for å bruke toveisfiltre, kan du bruke et filter på visuelt nivå på selve produktsliceren.

La oss nå vurdere at relasjonen mellom Product og Sales tabeller ikke lenger filtreres i begge retninger. Og følgende måldefinisjon er lagt til i Sales tabellen.

Total Quantity = SUM(Sales[Quantity])

Hvis du vil vise produktsliceralternativene "med data", må det ganske enkelt filtreres etter Total Quantity mål ved hjelp av betingelsen "er ikke tom".

Analyse av dimensjon til dimensjon

Et annet scenario som involverer toveisrelasjoner behandler en faktatabell som en brotabell. På denne måten støtter den analyse av dimensjonstabelldata i filterkonteksten til en annen dimensjonstabell.

Bruk eksempelmodellen i denne artikkelen til å vurdere hvordan følgende spørsmål kan besvares:

• Hvor mange farger ble solgt til australske kunder?
• Hvor mange land/regioner kjøpte jeans?

Begge spørsmålene kan besvares uten å summere data i faktatabellen for brobygging. De krever imidlertid at filtre overføres fra én dimensjonstabell til den andre. Når filtre overføres via faktatabellen, kan oppsummering av dimensjonstabellkolonner oppnås ved hjelp av DISTINCTCOUNT DAX-funksjonen , og muligens MIN- og MAX DAX-funksjoner.

Siden faktatabellen oppfører seg som en brotabell, kan du bruke veiledningen for mange-til-mange-relasjoner for å relatere to dimensjonstabeller. Det krever at du konfigurerer minst én relasjon for å filtrere i begge retninger. Hvis du vil ha mer informasjon, kan du se Veiledning for mange-til-mange-relasjoner.

Men, som allerede beskrevet i denne artikkelen, vil denne utformingen sannsynligvis resultere i en negativ innvirkning på ytelsen, og brukeropplevelsens konsekvenser knyttet til sliceralternativer "med data". Vi anbefaler derfor at du aktiverer toveis filtrering i en måldefinisjon ved hjelp av CROSSFILTER DAX-funksjonen i stedet. Du kan bruke CROSSFILTER-funksjonen til å endre filterretninger – eller til og med deaktivere relasjonen – under evalueringen av et uttrykk.

Vurder følgende måldefinisjon som er lagt til i Sales-tabellen. I dette eksemplet er modellrelasjonen mellom tabellene Customer og Sales konfigurert til å filtrere i en enkeltretning.

Different Countries Sold =
CALCULATE(
    DISTINCTCOUNT(Customer[Country-Region]),
    CROSSFILTER(
        Customer[CustomerCode],
        Sales[CustomerCode],
        BOTH
    )
)

Under evalueringen av Different Countries Sold-målet filtreres relasjonen mellom Customer og Sales tabeller i begge retninger.

Følgende tabellvisualobjekt presenterer statistikk for hvert solgte produkt. Kolonnen Quantity er ganske enkelt summen av antallverdier. Kolonnen Different Countries Sold representerer det distinkte antallet landområdeverdier for alle kunder som har kjøpt produktet.

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 én-til-én-relasjon
• Veiledning for mange-til-mange-relasjoner
• Veiledning for feilsøking av relasjoner
• Spørsmål? Prøv å spørre Fabric Community
• Forslag? Bidra med ideer for å forbedre Fabric