Del via

Bruke mange-til-mange-relasjoner i Power BI Desktop

  • Artikkel

Med relasjoner med en mange-til-mange-kardinalitet i Power BI Desktop, kan du koble sammen tabeller som bruker en kardinalitet av mange-til-mange. Du kan enkelt og intuitivt opprette datamodeller som inneholder to eller flere datakilder. Relasjoner med en mange-til-mange-kardinalitet er en del av de større sammensatte modellfunksjonene i Power BI Desktop. Hvis du vil ha mer informasjon om sammensatte modeller, kan du se Bruke sammensatte modeller i Power BI Desktop

Skjermbilde av en mange-til-mange-relasjon i Rediger relasjon-ruten.

Hva en relasjon med en mange-til-mange kardinalitet løser

Før relasjoner med en mange-til-mange-kardinalitet ble tilgjengelig, ble relasjonen mellom to tabeller definert i Power BI. Minst én av tabellkolonnene som var involvert i relasjonen, måtte inneholde unike verdier. Ofte inneholdt imidlertid ingen kolonner unike verdier.

To tabeller kan for eksempel ha hatt en kolonne kalt CountryRegion. Verdiene i CountryRegion var imidlertid ikke unike i noen av tabellene. Hvis du vil bli med i slike tabeller, må du opprette en midlertidig løsning. Én løsning kan være å introdusere ekstra tabeller med de nødvendige unike verdiene. Med relasjoner med en mange-til-mange-kardinalitet kan du koble sammen slike tabeller direkte hvis du bruker en relasjon med en kardinalitet av mange-til-mange.

Bruke relasjoner med en mange-til-mange-kardinalitet

Når du definerer en relasjon mellom to tabeller i Power BI, må du definere kardinaliteten for relasjonen. For eksempel vil relasjonen mellom ProductSales og Product – ved hjelp av kolonnene ProductSales[ProductCode] og Product[ProductCode]– defineres som Mange-1. Vi definerer relasjonen på denne måten fordi hvert produkt har mange salg, og kolonnen i produkttabellen (ProductCode) er unik. Når du definerer en relasjonskardinalitet som Mange-1, 1-Mange eller 1-1, validerer Power BI den, slik at kardinaliteten du velger samsvarer med de faktiske dataene.

Ta for eksempel en titt på den enkle modellen i dette bildet:

Skjermbilde av produktsalg og produkttabell i relasjonsvisning.

Tenk deg nå at produkttabellen bare viser to rader, som vist:

Skjermbilde av et visualobjekt for produkttabeller med to rader.

Tenk deg også at Salg-tabellen bare har fire rader, inkludert en rad for en produkt C. På grunn av en referanseintegritetsfeil finnes ikke produkt C-raden i produkttabellen.

Skjermbilde av et Visualobjekt for salg-tabellen med fire rader.

Produktnavn og pris (fra produkttabellen), sammen med totalt antall for hvert produkt (fra Tabellen Produktsalg), vises som vist:

Skjermbilde av et visualobjekt som viser produktnavn, pris og antall.

Som du kan se i det foregående bildet, er en tom ProductName-rad knyttet til salg for produkt C. Denne tomme raden står for følgende vurderinger:

  • Alle rader i ProductSales-tabellen der det ikke finnes noen tilsvarende rad i produkttabellen. Det er et problem med referanseintegritet, som vi ser for produkt C i dette eksemplet.

  • Alle rader i ProductSales-tabellen som sekundærnøkkelkolonnen er null for.

Av disse grunnene står den tomme raden i begge tilfeller for salg der ProductName og Price er ukjente.

Noen ganger er tabellene sammenføyd med to kolonner, men ingen av kolonnene er unike. Vurder for eksempel disse to tabellene:

  • Salg-tabellen viser salgsdata etter delstat, og hver rad inneholder salgsbeløpet for salgstypen i denne tilstanden. Delstatene inkluderer CA, WA og TX.

    Skjermbilde av en Salgstabell som viser salg etter stat.

  • CityData-tabellen viser data om byer, inkludert populasjonen og staten (for eksempel CA, WA og New York).

    Skjermbilde av en salgstabell som viser by, stat og populasjon.

En kolonne for delstat er nå i begge tabellene. Det er rimelig å ønske å rapportere om både totalt salg etter stat og total befolkning i hver stat. Det finnes imidlertid et problem: Delstat-kolonnen er ikke unik i noen av tabellene.

Den forrige midlertidige løsningen

Før utgivelsen av Power BI Desktop i juli 2018 kunne du ikke opprette en direkte relasjon mellom disse tabellene. En vanlig løsning var å:

  • Opprett en tredje tabell som bare inneholder de unike tilstands-ID-ene. Tabellen kan være en hvilken som helst eller alle av:

    • En beregnet tabell (definert ved hjelp av dataanalyseuttrykk [DAX]).
    • En tabell basert på en spørring som er definert i Power Query-redigering, som kan vise de unike ID-ene som er hentet fra én av tabellene.
    • Det kombinerte fullstendige settet.

  • Deretter relaterer du de to opprinnelige tabellene til den nye tabellen ved hjelp av vanlige Mange-1-relasjoner .

Du kan la den midlertidige tabellen være synlig. Eller du kan skjule den midlertidige løsningstabellen, slik at den ikke vises i Felter-listen . Hvis du skjuler tabellen, blir mange-1-relasjonene vanligvis satt til å filtrere i begge retninger, og du kan bruke Delstat-feltet fra begge tabellene. Sistnevnte kryssfiltrering vil overføres til den andre tabellen. Denne tilnærmingen vises i følgende bilde:

Skjermbilde av en skjult tilstandstabell i Relasjonsvisning.

Et visualobjekt som viser Delstat (fra CityData-tabellen), sammen med total befolkning og totalt salg, vil da vises som følger:

Skjermbilde som viser en tabell med data om stat, befolkning og salg.

Merk

Fordi tilstanden fra CityData-tabellen brukes i denne midlertidige løsningen, er det bare statene i tabellen som er oppført, slik at TX utelates. I motsetning til mange-1-relasjoner , mens totalraden inkluderer alle salg (inkludert de av TX), inkluderer ikke detaljene en tom rad som dekker slike rader som ikke samsvarer. På samme måte vil ingen tom rad dekke Salg som det finnes en nullverdi for staten for.

La oss si at du også legger til By i visualobjektet. Selv om populasjonen per by er kjent, gjentar salgene som vises for by, bare salgene for den tilsvarende delstaten. Dette scenarioet oppstår vanligvis når kolonnegrupperingen ikke er relatert til et samlet mål, som vist her:

Skjermbilde av en tabell som viser befolkning og salg i delstat og by.

La oss si at du definerer den nye Salg-tabellen som kombinasjonen av alle delstater her, og vi gjør den synlig i Felter-listen . Det samme visualobjektet viser Stat (i den nye tabellen), den totale populasjonen og totalt salg:

Skjermbilde av et visualobjekt som viser visualobjekter for stat, befolkning og salg.

Som du kan se, vil TX – med salgsdata , men ukjente befolkningsdata – og New York – med kjente befolkningsdata , men ingen salgsdata – bli inkludert. Denne løsningen er ikke optimal, og den har mange problemer. For relasjoner med en mange-til-mange-kardinalitet løses de resulterende problemene, som beskrevet i neste del.

Hvis du vil ha mer informasjon om hvordan du implementerer denne midlertidige løsningen, kan du se Veiledning for mange-til-mange-relasjoner.

Bruke en relasjon med en mange-til-mange-kardinalitet i stedet for den midlertidige løsningen

Du kan relatere tabeller direkte, for eksempel de vi beskrev tidligere, uten å måtte ty til lignende løsninger. Det er nå mulig å angi relasjonskardinaliteten til mange-til-mange. Denne innstillingen angir at ingen av tabellene inneholder unike verdier. For slike relasjoner kan du fortsatt kontrollere hvilken tabell som filtrerer den andre tabellen. Eller du kan bruke toveis filtrering, der hver tabell filtrerer den andre.

Kardinaliteten i Power BI Desktop er standard for mange-til-mange når den fastslår at ingen av tabellene inneholder unike verdier for relasjonskolonnene. I slike tilfeller bekrefter en advarsel at du vil angi en relasjon, og at endringen ikke er den utilsiktede effekten av et dataproblem.

Når du for eksempel oppretter en relasjon direkte mellom CityData og Salg – der filtre skal flyte fra CityData til Salg – viser Power BI Desktop dialogboksen Rediger relasjon :

Skjermbilde av dialogboksen Rediger relasjon med kardinalitet og kryssfiltreringsretning uthevet.

Den resulterende relasjonsvisningen viser deretter den direkte, mange-til-mange-relasjonen mellom de to tabellene. Tabellens utseende i Felter-listen , og deres senere virkemåte når visualobjektene opprettes, ligner på da vi brukte den midlertidige løsningen. Den ekstra tabellen som viser de distinkte tilstandsdataene, vises ikke i den midlertidige løsningen. Som beskrevet tidligere, vises et visualobjekt som viser data om stat, befolkning og salg :

Skjermbilde av en tabell for delstat, befolkning og salg.

De viktigste forskjellene mellom relasjoner med en mange-til-mange-kardinalitet og de mer typiske Mange-1-relasjonene er som følger:

  • Verdiene som vises, inneholder ikke en tom rad som står for rader som ikke samsvarer i den andre tabellen. Verdiene tar heller ikke hensyn til rader der kolonnen som brukes i relasjonen i den andre tabellen, er null.

  • Du kan ikke bruke funksjonen fordi mer enn én RELATED() rad kan være relatert.

  • ALL() Hvis du bruker funksjonen i en tabell, fjernes ikke filtre som brukes på andre, relaterte tabeller av en mange-til-mange-relasjon. I det foregående eksemplet ville ikke et mål som er definert som vist her, fjerne filtre på kolonner i den relaterte CityData-tabellen:

    Skjermbilde av et skripteksempel. Eksemplet er Salg totalt = Beregn(Sum('Salg'[Salg]), Alle('Salg')).

    Et visualobjekt som viser totaldata for delstat, salg og salg, vil resultere i denne grafikken:

    Skjermbilde av et tabellvisualobjekt som viser totalt antall delstater, salg og salg som er resultatet av formelen.

Med de foregående forskjellene i tankene må du kontrollere at beregningene som bruker ALL(<Table>), for eksempel % av totalsummen, returnerer de tiltenkte resultatene.

Hensyn og begrensninger

Det finnes noen begrensninger for denne utgivelsen av relasjoner med en mange-til-mange kardinalitet og sammensatte modeller.

Følgende Live Connect-kilder (flerdimensjonale) kan ikke brukes med sammensatte modeller:

  • SAP HANA
  • SAP Business Warehouse
  • SQL Server Analysis Services
  • Semantiske modeller for Power BI
  • Azure Analysis Services

Når du kobler til disse flerdimensjonale kildene ved hjelp av DirectQuery, kan du ikke koble til en annen DirectQuery-kilde eller kombinere den med importerte data.

De eksisterende begrensningene ved bruk av DirectQuery gjelder fortsatt når du bruker relasjoner med en mange-til-mange-kardinalitet. Mange begrensninger er nå per tabell, avhengig av lagringsmodusen for tabellen. En beregnet kolonne i en importert tabell kan for eksempel referere til andre tabeller, men en beregnet kolonne i en DirectQuery-tabell kan fortsatt bare referere til kolonner i samme tabell. Andre begrensninger gjelder for hele modellen hvis noen tabeller i modellen er DirectQuery. QuickInsights- og Q&A-funksjonene er for eksempel utilgjengelige på en modell hvis en tabell i den har en lagringsmodus for DirectQuery.

Relatert innhold

Hvis du vil ha mer informasjon om sammensatte modeller og DirectQuery, kan du se følgende artikler: