Del via

Modellrelasjoner i Power BI Desktop

  • Artikkel

Denne artikkelen er rettet mot import av datamodellerere som arbeider med Power BI Desktop. Det er et viktig modellutformingsemne som er viktig for å levere intuitive, nøyaktige og optimale modeller.

Hvis du vil ha en dypere diskusjon om optimal modellutforming, inkludert tabellroller og relasjoner, kan du se Forstå stjerneskjema og viktigheten for Power BI.

Relasjonsformål

En modellrelasjon overfører filtre i kolonnen i én modelltabell til en annen modelltabell. Filtre overføres så lenge det er en relasjonsbane å følge, noe som kan innebære overføring til flere tabeller.

Relasjonsbaner er deterministiske, noe som betyr at filtre alltid overføres på samme måte og uten tilfeldig variasjon. Relasjoner kan imidlertid deaktiveres eller ha filterkontekst endret av modellberegninger som bruker bestemte DAX-funksjoner. Hvis du vil ha mer informasjon, kan du se emnet relevante DAX-funksjoner senere i denne artikkelen.

Viktig

Modellrelasjoner håndhever ikke dataintegritet. Hvis du vil ha mer informasjon, kan du se emnet Relasjonsevaluering senere i denne artikkelen, som forklarer hvordan modellrelasjoner oppfører seg når det er dataintegritetsproblemer med dataene.

Slik overfører relasjoner filtre med et animert eksempel.

Animert diagram over overføring av relasjonsfilter.

I dette eksemplet består modellen av fire tabeller: Kategori, Produkt, År og Salg. Kategoritabellen er knyttet til Produkt-tabellen, og Produkt-tabellen er knyttet til Salg-tabellen. År-tabellen er også knyttet til Salg-tabellen. Alle relasjoner er én-til-mange (detaljene som er beskrevet senere i denne artikkelen).

En spørring, muligens generert av et Power BI-kortvisualobjekt, ber om det totale salgsantallet for salgsordrer for én enkelt kategori, Cat-A og for ett år, CY2018. Det er derfor du kan se filtre som brukes i kategori- og årtabellene. Filteret i Kategori-tabellen overføres til Produkt-tabellen for å isolere to produkter som er tilordnet kategorien Cat-A. Deretter overføres produkttabellfiltrene til Salg-tabellen for å isolere bare to salgsrader for disse produktene. Disse to salgsradene representerer salg av produkter som er tilordnet kategori Cat-A. Det samlede antallet er 14 enheter. Samtidig overføres årtabellfilteret for å filtrere Salg-tabellen ytterligere, noe som resulterer i bare én salgsrad som er for produkter tilordnet til kategori Cat-A , og som ble bestilt i år CY2018. Antallsverdien som returneres av spørringen, er 11 enheter. Vær oppmerksom på at når flere filtre brukes på en tabell (for eksempel Salg-tabellen i dette eksemplet), er det alltid en AND-operasjon som krever at alle betingelser må være sanne.

Bruke utformingsprinsipper for stjerneskjema

Vi anbefaler at du bruker utformingsprinsipper for stjerneskjema for å produsere en modell bestående av dimensjons- og faktatabeller. Det er vanlig å konfigurere Power BI til å håndheve regler som filtrerer dimensjonstabeller, slik at modellrelasjoner effektivt kan overføre disse filtrene til faktatabeller.

Bildet nedenfor er modelldiagrammet for datamodellen adventure works salgsanalyse. Den viser en stjerneskjemautforming bestående av én enkelt faktatabell med navnet Salg. De fire andre tabellene er dimensjonstabeller som støtter analyse av salgsmål etter dato, delstat, område og produkt. Legg merke til modellrelasjonene som kobler sammen alle tabeller. Disse relasjonene overfører filtre (direkte eller indirekte) til Salg-tabellen .

Skjermbilde av et Power BI Desktop-modelldiagram bestående av tabeller og relasjoner som beskrevet i forrige avsnitt.

Frakoblede tabeller

Det er uvanlig at en modelltabell ikke er relatert til en annen modelltabell. En slik tabell i en gyldig modellutforming beskrives som en frakoblet tabell. En frakoblet tabell er ikke ment å overføre filtre til andre modelltabeller. I stedet godtar den «brukerinndata» (kanskje med et slicervisualobjekt), slik at modellberegninger kan bruke inndataverdien på en meningsfull måte. Vurder for eksempel en frakoblet tabell som er lastet inn med et område med valutakursverdier. Så lenge et filter brukes til å filtrere etter én enkelt renteverdi, kan et måluttrykk bruke denne verdien til å konvertere salgsverdier.

Hva-skjer-hvis-parameteren i Power BI Desktop er en funksjon som oppretter en frakoblet tabell. Hvis du vil ha mer informasjon, kan du se Opprette og bruke en What if-parameter til å visualisere variabler i Power BI Desktop.

Relasjonsegenskaper

En modellrelasjon relaterer én kolonne i en tabell til én kolonne i en annen tabell. (Det finnes ett spesialisert tilfelle der dette kravet ikke er sant, og det gjelder bare for flerkolonnerelasjoner i DirectQuery-modeller. Hvis du vil ha mer informasjon, kan du se artikkelen om COMBINEVALUES DAX-funksjonen.)

Merk

Det er ikke mulig å relatere en kolonne til en annen kolonne i samme tabell. Dette konseptet forveksles noen ganger med muligheten til å definere en sekundærnøkkelbetingelse for relasjonsdatabase som refererer til tabellen selv. Du kan bruke dette relasjonsdatabasekonseptet til å lagre overordnede-underordnede relasjoner (for eksempel er hver ansattpost relatert til en «rapporter til»-ansatt). Du kan imidlertid ikke bruke modellrelasjoner til å generere et modellhierarki basert på denne typen relasjon. Hvis du vil opprette et overordnet-underordnet hierarki, kan du se overordnede og underordnede funksjoner.

Datatyper for kolonner

Datatypen for både «fra»- og «til»-kolonnen i relasjonen skal være den samme. Det kan hende at det ikke fungerer som forventet å arbeide med relasjoner som er definert i DateTime-kolonner . Motoren som lagrer Power BI-data, bruker bare DateTime-datatyper . Datatyper for dato, klokkeslett og dato/klokkeslett/tidssone er Power BI-formateringskonstruksjoner som er implementert øverst. Alle modellavhengige objekter vises fortsatt som DateTime i motoren (for eksempel relasjoner, grupper og så videre). Hvis en bruker velger Dato fra Modellering-fanen for slike kolonner, registrerer de seg derfor ikke som den samme datoen, fordi tidsdelen av dataene fremdeles vurderes av motoren. Les mer om hvordan dato/klokkeslett-typer håndteres. Hvis du vil rette opp virkemåten, bør kolonnedatatypene oppdateres i Power Query-redigering for å fjerne Tid-delen fra de importerte dataene, så når motoren håndterer dataene, vises verdiene på samme måte.

Kardinalitet

Hver modellrelasjon defineres av en kardinalitetstype. Det finnes fire alternativer for kardinalitetstype, som representerer dataegenskapene til kolonnene «fra» og «til» relaterte kolonner. Én-siden betyr at kolonnen inneholder unike verdier. «mange»-siden betyr at kolonnen kan inneholde dupliserte verdier.

Merk

Hvis en dataoppdateringsoperasjon prøver å laste inn dupliserte verdier i en «én»-sidekolonne, vil hele dataoppdateringen mislykkes.

De fire alternativene, sammen med sine korthånds notasjoner, er beskrevet i følgende punktliste:

  • Én-til-mange (1:*)
  • Mange-til-én (*:1)
  • Én-til-én (1:1)
  • Mange-til-mange (*:*)

Når du oppretter en relasjon i Power BI Desktop, oppdager og angir designeren automatisk kardinalitetstypen. Power BI Desktop spør modellen for å vite hvilke kolonner som inneholder unike verdier. For importmodeller bruker den intern lagringsstatistikk. for DirectQuery-modeller sender den profileringsspørringer til datakilden. Noen ganger kan imidlertid Power BI Desktop ta feil. Det kan ta feil når tabeller ennå ikke er lastet inn med data, eller fordi kolonner som du forventer skal inneholde dupliserte verdier for øyeblikket inneholder unike verdier. I begge tilfeller kan du oppdatere kardinalitetstypen så lenge alle «én»-sidekolonner inneholder unike verdier (eller tabellen er ennå ikke lastet inn med rader med data).

En-til-mange (og mange-til-en) kardinalitet

Alternativene for én-til-mange og mange-til-én-kardinalitet er i hovedsak de samme, og de er også de vanligste kardinalitetstypene.

Når du konfigurerer en én-til-mange- eller mange-til-én-relasjon, velger du den som samsvarer med rekkefølgen du knyttet kolonnene til. Vurder hvordan du konfigurerer relasjonen fra Produkt-tabellen til Salg-tabellen ved hjelp av ProduktID-kolonnen som finnes i hver tabell. Kardinalitetstypen vil være én-til-mange, da ProduktID-kolonnen i produkttabellen inneholder unike verdier. Hvis du knyttet tabellene i motsatt retning, Salg til Produkt, vil kardinaliteten være mange-til-en.

En-til-en kardinalitet

En én-til-én-relasjon betyr at begge kolonnene inneholder unike verdier. Denne kardinalitetstypen er ikke vanlig, og den representerer sannsynligvis en suboptimal modellutforming på grunn av lagring av overflødige data.

Hvis du vil ha mer informasjon om hvordan du bruker denne kardinalitetstypen, kan du se Veiledning for én-til-én-relasjon.

Mange-til-mange kardinalitet

En mange-til-mange-relasjon betyr at begge kolonnene kan inneholde dupliserte verdier. Denne kardinalitetstypen brukes sjelden. Det er vanligvis nyttig når du utformer komplekse modellkrav. Du kan bruke den til å relatere mange-til-mange fakta eller å relatere høyere korn fakta. Når for eksempel salgsmålfakta lagres på produktkategorinivå og produktdimensjonstabellen lagres på produktnivå.

Hvis du vil ha veiledning om hvordan du bruker denne kardinalitetstypen, kan du se Veiledning for mange-til-mange-relasjoner.

Merk

Kardinalitetstypen Mange-til-mange støttes for modeller som er utviklet for rapportserver for Power BI januar 2024 og nyere.

Tips

I modellvisning i Power BI Desktop kan du tolke kardinalitetstypen for en relasjon ved å se på indikatorene (1 eller *) på hver side av relasjonslinjen. Hvis du vil finne ut hvilke kolonner som er relatert, må du velge, eller holde markøren over, relasjonslinjen for å utheve kolonnene.

Skjermbilde av to tabeller i modelldiagrammet med kardinalitetsindikatorene uthevet.

Kryssfiltreringsretning

Hver modellrelasjon defineres med en kryssfiltreringsretning. Innstillingen bestemmer retningen(e) som filtrene skal overføre. De mulige alternativene for kryssfiltrering er avhengig av kardinalitetstypen.

Kardinalitetstype Alternativer for kryssfiltrering
Én-til-mange (eller mange-til-en) Enkel
Begge
Én-til-én Begge
Mange-til-mange Enkel (Tabell1 til Tabell2)
Enkel (Tabell2 til Tabell1)
Begge

Enkel kryssfiltreringsretning betyr «én retning», og begge betyr «begge retninger». En relasjon som filtreres i begge retninger, beskrives vanligvis som toveis.

For én-til-mange-relasjoner er kryssfiltreringsretningen alltid fra «én»-siden, og eventuelt fra «mange»-siden (toveis). For én-til-én-relasjoner er kryssfiltreringsretningen alltid fra begge tabellene. Til slutt, for mange-til-mange-relasjoner, kan kryssfiltreringsretning være fra enten én av tabellene eller fra begge tabellene. Legg merke til at når kardinalitetstypen inneholder en «én»-side, overføres alltid filtrene fra den siden.

Når kryssfiltreringsretningen er satt til Begge, blir en annen egenskap tilgjengelig. Den kan bruke toveis filtrering når Power BI håndhever regler for sikkerhet på radnivå (RLS). Hvis du vil ha mer informasjon om RLS, kan du se Sikkerhet på radnivå (RLS) med Power BI Desktop.

Du kan endre kryssfiltreringsretningen for relasjonen, inkludert deaktivering av filteroverføring, ved hjelp av en modellberegning. Det oppnås ved hjelp av CROSSFILTER DAX-funksjonen .

Husk at toveisrelasjoner kan påvirke ytelsen negativt. Hvis du prøver å konfigurere en toveis relasjon, kan det føre til tvetydige filteroverføringsbaner. I dette tilfellet kan Power BI Desktop mislykkes i å utføre relasjonsendringen og varsler deg med en feilmelding. Noen ganger kan imidlertid Power BI Desktop tillate deg å definere tvetydige relasjonsbaner mellom tabeller. Løse tvetydighet for relasjonsbane beskrives senere i denne artikkelen.

Vi anbefaler at du bare bruker toveis filtrering etter behov. Hvis du vil ha mer informasjon, kan du se Veiledning for toveis relasjoner.

Tips

I modellvisning i Power BI Desktop kan du tolke kryssfiltreringsretningen for en relasjon ved å legge merke til pilspissene langs relasjonslinjen. Et enkelt pilspiss representerer et filter i én retning i retningen på pilspissen. en dobbel pilspiss representerer en toveis relasjon.

Skjermbilde av to tabeller i modelldiagrammet med kryssfiltreringspilspissen uthevet.

Gjør denne relasjonen aktiv

Det kan bare være én aktiv filteroverføringsbane mellom to modelltabeller. Det er imidlertid mulig å introdusere flere relasjonsbaner, men du må angi disse relasjonene som inaktive. Inaktive relasjoner kan bare gjøres aktive under evalueringen av en modellberegning. Det oppnås ved hjelp av USERELATIONSHIP DAX-funksjonen.

Generelt anbefaler vi at du definerer aktive relasjoner når det er mulig. De utvider omfanget og potensialet for hvordan rapportforfattere kan bruke modellen din. Bruk av bare aktive relasjoner 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 utformingen når:

  • Det er ikke nødvendig at visualobjekter i rapporten filtreres samtidig etter ulike roller.
  • Du bruker USERELATIONSHIP DAX-funksjonen til å aktivere en bestemt relasjon for relevante modellberegninger.

Hvis du vil ha mer informasjon, kan du se Aktiv kontra inaktiv relasjonsveiledning.

Tips

I modellvisning i Power BI Desktop kan du tolke en relasjons aktiv vs inaktiv status. En aktiv relasjon representeres av en heltrukket linje. en inaktiv relasjon representeres som en stiplet linje.

Skjermbilde av to tabeller i modelldiagrammet og to relasjoner. én heltrukket linje for aktiv og én stiplet linje for inaktiv

Anta referanseintegritet

Egenskapen Anta referanseintegritet er bare tilgjengelig for én-til-mange- og én-til-én-relasjoner mellom to DirectQuery-lagringsmodustabeller som tilhører samme kildegruppe. Du kan bare aktivere denne egenskapen når «mange»-sidekolonnen ikke inneholder NULLer.

Når det er aktivert, vil opprinnelige spørringer som sendes til datakilden, slå sammen de to tabellene ved hjelp av en INNER JOIN i stedet for en OUTER JOIN. Hvis du aktiverer denne egenskapen, forbedres spørringsytelsen, selv om den avhenger av detaljene i datakilden.

Aktiver alltid denne egenskapen når det finnes en sekundærnøkkelbetingelse for databasen mellom de to tabellene. Selv når det ikke finnes en sekundærnøkkelbetingelse, bør du vurdere å aktivere egenskapen så lenge du er sikker på at dataintegritet finnes.

Viktig

Hvis dataintegritet skulle bli kompromittert, eliminerer den indre sammenføyningen enestående rader mellom tabellene. Vurder for eksempel en modellsalgstabell med en ProduktID-kolonneverdi som ikke fantes i den relaterte produkttabellen. Filteroverføring fra Produkt-tabellen til Salg-tabellen eliminerer salgsrader for ukjente produkter. Dette vil resultere i en underdrivelse av salgsresultatene.

Hvis du vil ha mer informasjon, kan du se Anta innstillinger for referanseintegritet i Power BI Desktop.

Relevante DAX-funksjoner

Det finnes flere DAX-funksjoner som er relevante for modellrelasjoner. Hver funksjon beskrives kort i følgende punktliste:

  • RELATERT: Henter verdien fra «én»-siden av en relasjon. Det er nyttig når du involverer beregninger fra forskjellige tabeller som evalueres i radkontekst.
  • RELATEDTABLE: Hente en tabell med rader fra «mange»-siden i en relasjon.
  • USERELATIONSHIP: Tillater en beregning å bruke en inaktiv relasjon. (Teknisk sett endrer denne funksjonen vekten av en bestemt inaktiv modellrelasjon som bidrar til å påvirke bruken.) Det er nyttig når modellen inneholder en rollespilldimensjonstabell, og du velger å opprette inaktive relasjoner fra denne tabellen. Du kan også bruke denne funksjonen til å løse tvetydighet i filterbaner.
  • KRYSSFILTRER: Endrer kryssfiltreringsretningen for relasjonen (til én eller begge), eller den deaktiverer filteroverføring (ingen). Det er nyttig når du må endre eller ignorere modellrelasjoner under evalueringen av en bestemt beregning.
  • COMBINEVALUES: Slår sammen to eller flere tekststrenger i én tekststreng. Formålet med denne funksjonen er å støtte flerkolonnerelasjoner i DirectQuery-modeller når tabeller tilhører samme kildegruppe.
  • TREATAS: Bruker resultatet av et tabelluttrykk som filtre på kolonner fra en ikke-relatert tabell. Det er nyttig i avanserte scenarioer når du vil opprette en virtuell relasjon under evalueringen av en bestemt beregning.
  • Overordnede og underordnede funksjoner: En familie med relaterte funksjoner som du kan bruke til å generere beregnede kolonner for å naturalisere et overordnet-underordnet hierarki. Deretter kan du bruke disse kolonnene til å opprette et hierarki på fast nivå.

Relasjonsevaluering

Modellrelasjoner, fra et evalueringsperspektiv, klassifiseres som enten vanlige eller begrensede. Det er ikke en konfigurerbar relasjonsegenskap. Det er faktisk utledet fra kardinalitetstypen og datakilden til de to relaterte tabellene. Det er viktig å forstå evalueringstypen fordi det kan være ytelsesimplikasjoner eller konsekvenser dersom dataintegritet blir kompromittert. Disse konsekvensene og integritetskonsekvensene beskrives i dette emnet.

For det første kreves noe modelleringsteori for å forstå relasjonsevalueringer fullt ut.

En import- eller DirectQuery-modell henter alle dataene fra Vertipaq-bufferen eller kildedatabasen. I begge tilfeller kan Power BI fastslå at det finnes en «én»-side av en relasjon.

En sammensatt modell kan imidlertid bestå av tabeller ved hjelp av ulike lagringsmoduser (import, DirectQuery eller dobbel) eller flere DirectQuery-kilder. Hver kilde, inkludert Vertipaq-bufferen for importerte data, anses å være en kildegruppe. Modellrelasjoner kan deretter klassifiseres som intrakildegruppe eller inter-/krysskildegruppe. En intrakildegrupperelasjon relaterer to tabeller i en kildegruppe, mens en inter/krysskildegrupperelasjon relaterer tabeller på tvers av to kildegrupper. Vær oppmerksom på at relasjoner i import- eller DirectQuery-modeller alltid er intrakildegrupper.

Her er et eksempel på en sammensatt modell.

Diagram over en sammensatt modell som består av to kildegrupper.

I dette eksemplet består den sammensatte modellen av to kildegrupper: en Vertipaq-kildegruppe og en DirectQuery-kildegruppe. Vertipaq-kildegruppen inneholder tre tabeller, og DirectQuery-kildegruppen inneholder to tabeller. Det finnes én grupperelasjon på tvers av kilder for å relatere en tabell i Vertipaq-kildegruppen til en tabell i DirectQuery-kildegruppen.

Vanlige relasjoner

En modellrelasjon er vanlig når spørringsmotoren kan bestemme «én»-siden i relasjonen. Den bekrefter at «én»-sidekolonnen inneholder unike verdier. Alle én-til-mange intrakildegrupperelasjoner er vanlige relasjoner.

I eksemplet nedenfor er det to vanlige relasjoner, begge merket som R. Relasjoner inkluderer én-til-mange-relasjonen i Vertipaq-kildegruppen, og én-til-mange-relasjonen i DirectQuery-kilden.

Diagram over en sammensatt modell som består av to kildegrupper med de vanlige relasjonene merket.

For importmodeller, der alle data lagres i Vertipaq-bufferen, oppretter Power BI en datastruktur for hver vanlige relasjon ved dataoppdateringstidspunkt. Datastrukturene består av indekserte tilordninger av alle kolonne-til-kolonne-verdier, og deres formål er å akselerere sammenføyning av tabeller ved spørringstidspunkt.

På spørringstidspunktet tillater regelmessige relasjoner at tabellutvidelse skjer. Tabellutvidelse resulterer i oppretting av en virtuell tabell ved å inkludere de opprinnelige kolonnene i basistabellen og deretter utvide til relaterte tabeller. For importtabeller utføres tabellutvidelse i spørringsmotoren. for DirectQuery-tabeller gjøres det i den opprinnelige spørringen som sendes til kildedatabasen (så lenge egenskapen Anta referanseintegritet ikke er aktivert). Spørringsmotoren fungerer deretter på den utvidede tabellen, og bruker filtre og gruppering etter verdiene i de utvidede tabellkolonnene.

Merk

Inaktive relasjoner utvides også, selv når relasjonen ikke brukes av en beregning. Toveisrelasjoner har ingen innvirkning på tabellutvidelse.

For én-til-mange-relasjoner finner tabellutvidelsen sted fra «mange» til «én»-sidene ved hjelp LEFT OUTER JOIN av semantikk. Når en samsvarende verdi fra «mange» til «én»-siden ikke finnes, legges en tom virtuell rad til i sidetabellen «én». Denne virkemåten gjelder bare for vanlige relasjoner, ikke for begrensede relasjoner.

Tabellutvidelse forekommer også for én-til-én intrakildegrupperelasjoner, men ved hjelp FULL OUTER JOIN av semantikk. Denne sammenføyningstypen sikrer at tomme virtuelle rader legges til på hver side, når det er nødvendig.

Tomme virtuelle rader er faktisk ukjente medlemmer. Ukjente medlemmer representerer brudd på referanseintegritet der «mange»-sideverdien ikke har noen tilsvarende «én»-sideverdi. Ideelt sett bør ikke disse blankene eksistere. De kan elimineres ved å rense eller reparere kildedataene.

Slik fungerer tabellutvidelsen med et animert eksempel.

Animert diagram over tabellutvidelse.

I dette eksemplet består modellen av tre tabeller: Kategori, Produkt og Salg. Kategoritabellen er knyttet til produkttabellen med en én-til-mange-relasjon, og produkttabellen er knyttet til Salg-tabellen med en én-til-mange-relasjon. Kategoritabellen inneholder to rader, Produkt-tabellen inneholder tre rader, og Salg-tabellene inneholder fem rader. Det finnes samsvarende verdier på begge sider av alle relasjoner, noe som betyr at det ikke er brudd på referanseintegritet. En utvidet tabell for spørringstid vises. Tabellen består av kolonnene fra alle tre tabellene. Det er effektivt et denormalisert perspektiv for dataene i de tre tabellene. En ny rad legges til i Salg-tabellen, og den har en produksjonsidentifikatorverdi (9) som ikke har noen samsvarende verdi i produkttabellen. Det er et brudd på referanseintegritet. I den utvidede tabellen har den nye raden (tomme) verdier for kolonnene kategori - og produkttabell .

Begrensede relasjoner

En modellrelasjon er begrenset når det ikke er noen garantert «én»-side. En begrenset relasjon kan skje av to grunner:

  • Relasjonen bruker en mange-til-mange kardinalitetstype (selv om én eller begge kolonnene inneholder unike verdier).
  • Relasjonen er krysskildegruppe (som bare kan være tilfelle for sammensatte modeller).

I eksemplet nedenfor er det to begrensede relasjoner, begge merket som L. De to relasjonene inkluderer mange-til-mange-relasjonen i Vertipaq-kildegruppen, og én-til-mange-grupperelasjonen på tvers av kilder.

Diagram over en sammensatt modell som består av to tabeller med de begrensede relasjonene merket.

For importmodeller opprettes det aldri datastrukturer for begrensede relasjoner. I så fall løser Power BI tabellkoblinger på spørringstidspunktet.

Tabellutvidelse forekommer aldri for begrensede relasjoner. Tabellkoblinger oppnås ved hjelp INNER JOIN av semantikk, og derfor legges ikke tomme virtuelle rader til for å kompensere for brudd på referanseintegritet.

Det finnes andre begrensninger knyttet til begrensede relasjoner:

  • RELATED DAX-funksjonen kan ikke brukes til å hente kolonneverdiene på én side.
  • Aktivering av RLS har topologibegrensninger.

Tips

I modellvisning i Power BI Desktop kan du tolke en relasjon som begrenset. En begrenset relasjon representeres med parenteslignende merker ( ) etter kardinalitetsindikatorene.

Skjermbilde av to tabeller i modelldiagrammet med den begrensede relasjonen uthevet.

Løse tvetydighet for relasjonsbane

Toveisrelasjoner kan introdusere flere, og derfor tvetydige filteroverføringsbaner mellom modelltabeller. Når du evaluerer tvetydighet, velger Power BI filteroverføringsbanen i henhold til prioritet og vekt.

Prioritet

Prioritetsnivåer definerer en sekvens med regler som Power BI bruker til å løse tvetydighet i relasjonsbanen. Det første regelsvaret bestemmer banen Power BI vil følge. Hver regel nedenfor beskriver hvordan filtre flyter fra en kildetabell til en måltabell.

  1. En bane som består av én-til-mange-relasjoner.
  2. En bane som består av én-til-mange- eller mange-til-mange-relasjoner.
  3. En bane som består av mange-til-én-relasjoner.
  4. En bane som består av én-til-mange-relasjoner fra kildetabellen til en mellomliggende tabell etterfulgt av mange-til-én-relasjoner fra den mellomliggende tabellen til måltabellen.
  5. En bane som består av én-til-mange- eller mange-til-mange-relasjoner fra kildetabellen til en mellomliggende tabell etterfulgt av mange-til-én- eller mange-til-mange-relasjoner fra den mellomliggende tabellen til måltabellen.
  6. Alle andre baner.

Når en relasjon er inkludert i alle tilgjengelige baner, fjernes den fra vurdering fra alle baner.

Vekt

Hver relasjon i en bane har en vekt. Som standard er hver relasjonstykkelse lik med mindre USERELATIONSHIP-funksjonen brukes. Banetykkelsen er maksimalt av alle relasjonstykkelser langs banen. Power BI bruker banetykkelser til å løse tvetydighet mellom flere baner i samme prioritetsnivå. Den velger ikke en bane med lavere prioritet, men den velger banen med høyere vekt. Antallet relasjoner i banen påvirker ikke tykkelsen.

Du kan påvirke tykkelsen på en relasjon ved hjelp av USERELATIONSHIP-funksjonen . Vekten bestemmes av nestingsnivået for kallet til denne funksjonen, der det innerste kallet får høyest vekt.

Vurder følgende eksempel. Produktsalg-målet tilordner en høyere vekt på relasjonen mellom Sales[ProductID] og Product[ProductID], etterfulgt av relasjonen mellom Inventory[ProductID] og Product[ProductID].

Product Sales = 
CALCULATE(
    CALCULATE(
        SUM(Sales[SalesAmount]), 
        USERELATIONSHIP(Sales[ProductID], Product[ProductID])
    ),
    USERELATIONSHIP(Inventory[ProductID], Product[ProductID])
)

Merk

Hvis Power BI oppdager flere baner som har samme prioritet og samme vekt, returneres en tvetydig banefeil. I dette tilfellet må du løse tvetydigheten ved å påvirke relasjonstykkelsene ved hjelp av USERELATIONSHIP-funksjonen , eller ved å fjerne eller endre modellrelasjoner.

Ytelsesinnstillinger

Følgende ytelse for filteroverføring av listeordrer, fra raskest til laveste ytelse:

  1. Én-til-mange intrakildegrupperelasjoner
  2. Mange-til-mange-modellrelasjoner oppnådd med en mellomliggende tabell, og som involverer minst én toveis relasjon
  3. Mange-til-mange kardinalitetsrelasjoner
  4. Grupperelasjoner på tvers av kilder

Relatert innhold

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