Modelrelationer i Power BI Desktop

Denne artikel henvender sig til importdataudformere, der arbejder med Power BI Desktop. Det er et vigtigt emne i modeldesign, der er afgørende for at levere intuitive, præcise og optimale modeller.

Du kan finde en dybere diskussion om optimalt modeldesign, herunder tabelroller og relationer, under Forstå stjerneskema og vigtigheden for Power BI.

Relationsformål

En modelrelation overfører filtre, der er anvendt på kolonnen i én modeltabel, til en anden modeltabel. Filtre overføres, så længe der er en relationssti at følge, hvilket kan omfatte overførsel til flere tabeller.

Relationsstier er deterministiske, hvilket betyder, at filtre altid overføres på samme måde og uden tilfældig variation. Relationer kan dog deaktiveres eller have filterkontekst ændret af modelberegninger, der bruger bestemte DAX-funktioner. Du kan få flere oplysninger i emnet Relevante DAX-funktioner senere i denne artikel.

Vigtigt

Modelrelationer gennemtvinger ikke dataintegritet. Du kan få flere oplysninger i emnet Evaluering af relationer senere i denne artikel, som forklarer, hvordan modelrelationer fungerer, når der er problemer med dataintegritet med dine data.

Sådan overfører relationer filtre med et animeret eksempel.

I dette eksempel består modellen af fire tabeller: Kategori, Produkt, År og Salg. Tabellen Kategori er relateret til tabellen Product , og tabellen Product er relateret til tabellen Sales . Tabellen Year er også relateret til tabellen Sales . Alle relationer er en til mange-relationer (som beskrives senere i denne artikel).

En forespørgsel, der muligvis genereres af en Power BI-kortvisualisering, anmoder om det samlede salgsantal for salgsordrer, der er foretaget for en enkelt kategori, Cat-A, og for et enkelt år, CY2018. Det er derfor, du kan se filtre, der er anvendt på tabellerne Kategori og År . Filteret i tabellen Kategori overføres til tabellen Produkt for at isolere to produkter, der er tildelt kategorien Cat-A. Derefter overføres filtrene i tabellen Product til tabellen Sales for kun at isolere to salgsrækker for disse produkter. Disse to salgsrækker repræsenterer salget af produkter, der er tildelt kategorien Cat-A. Deres samlede antal er 14 enheder. Samtidig overføres filteret i tabellen Year for yderligere at filtrere tabellen Sales , hvilket kun resulterer i den ene salgsrække for produkter, der er tildelt kategorien Cat-A , og som blev bestilt i år CY2018. Den mængdeværdi, der returneres af forespørgslen, er 11 enheder. Bemærk, at når der anvendes flere filtre på en tabel (f.eks. tabellen Sales i dette eksempel), er det altid en AND-handling, der kræver, at alle betingelser skal være sande.

Anvend designprincipper for stjerneskemaer

Vi anbefaler, at du anvender designprincipper for stjerneskemaer for at oprette en model, der består af dimensions- og faktatabeller. Det er almindeligt at konfigurere Power BI til at gennemtvinge regler, der filtrerer dimensionstabeller, så modelrelationer effektivt kan overføre disse filtre til faktatabeller.

Følgende billede er modeldiagrammet for datamodellen til salgsanalyse i Adventure Works. Det viser et stjerneskemadesign, der består af en enkelt faktatabel med navnet Sales. De andre fire tabeller er dimensionstabeller, der understøtter analysen af salgsmålinger efter dato, stat, område og produkt. Bemærk, at modelrelationerne forbinder alle tabeller. Disse relationer overfører filtre (direkte eller indirekte) til tabellen Sales .

Frakoblede tabeller

Det er usædvanligt, at en modeltabel ikke er relateret til en anden modeltabel. En sådan tabel i et gyldigt modeldesign beskrives som en afbrudt tabel. En afbrudt tabel er ikke beregnet til at overføre filtre til andre modeltabeller. I stedet accepterer den "brugerinput" (måske med et udsnitsvisual), så modelberegninger kan bruge inputværdien på en meningsfuld måde. Overvej f.eks. en afbrudt tabel, der er indlæst med et interval af valutakursværdier. Så længe der anvendes et filter til at filtrere efter en enkelt satsværdi, kan et målingsudtryk bruge denne værdi til at konvertere salgsværdier.

What if-parameteren i Power BI Desktop er en funktion, der opretter en afbrudt tabel. Du kan få flere oplysninger under Opret og brug en What if-parameter til at visualisere variabler i Power BI Desktop.

Egenskaber for relationer

En modelrelation relaterer én kolonne i en tabel til én kolonne i en anden tabel. Der er ét særligt tilfælde, hvor dette krav ikke er sandt, og det gælder kun for relationer med flere kolonner i DirectQuery-modeller. Du kan få flere oplysninger i artiklen COMBINEVALUES DAX-funktion.)

Bemærk

Det er ikke muligt at relatere en kolonne til en anden kolonne i den samme tabel. Dette begreb forveksles nogle gange med muligheden for at definere en fremmed nøglebegrænsning for en relationel database, der refererer til tabel selv. Du kan bruge dette relationsdatabasekoncept til at gemme overordnede/underordnede relationer (f.eks. er hver medarbejderpost relateret til en "rapporter til"-medarbejder). Du kan dog ikke bruge modelrelationer til at generere et modelhierarki, der er baseret på denne type relation. Hvis du vil oprette et overordnet/underordnet-hierarki, skal du se Overordnede og Underordnede funktioner.

Datatyper for kolonner

Datatypen for både kolonnen "fra" og "til" i relationen skal være den samme. Arbejde med relationer, der er defineret i DateTime-kolonner , fungerer muligvis ikke som forventet. Programmet, der gemmer Power BI-data, bruger kun DateTime-datatyper . Datatyperne Date, Time og Date/Time/Timezone er Power BI-formateringskonstruktioner, der er implementeret øverst. Alle modelafhængige objekter vises stadig som DateTime i programmet (f.eks. relationer, grupper osv.). Hvis en bruger vælger Dato under fanen Udformning for sådanne kolonner, registreres brugeren derfor stadig ikke som den samme dato, fordi tidsdelen af dataene stadig tages i betragtning af programmet. Læs mere om, hvordan dato-/klokkeslætstyper håndteres. For at rette funktionsmåden skal kolonnedatatyperne opdateres i Power Query-editor for at fjerne tidsdelen fra de importerede data, så når programmet håndterer dataene, vises værdierne på samme måde.

Kardinalitet

Hver modelrelation er defineret af en kardinalitetstype. Der er fire indstillinger for kardinalitetstype, der repræsenterer dataegenskaberne for de "fra" og "til"-relaterede kolonner. "en"-siden betyder, at kolonnen indeholder entydige værdier. "mange"-siden betyder, at kolonnen kan indeholde dubletværdier.

Bemærk

Hvis en dataopdateringshandling forsøger at indlæse dubletværdier i en "en"-sidekolonne, mislykkes hele dataopdateringen.

De fire indstillinger er sammen med deres korte notationer beskrevet i følgende punktopstilling:

• En til mange (1:*)
• Mange til en (*:1)
• En til en (1:1)
• Mange til mange (*:*)

Når du opretter en relation i Power BI Desktop, registrerer og angiver designeren automatisk kardinalitetstypen. Power BI Desktop forespørger modellen for at vide, hvilke kolonner der indeholder entydige værdier. I forbindelse med importmodeller bruges intern lagerstatistik. for DirectQuery-modeller sender den profileringsforespørgsler til datakilden. Nogle gange kan Power BI Desktop dog få det galt. Det kan blive forkert, når tabeller endnu ikke er indlæst med data, eller fordi kolonner, som du forventer at indeholde dubletværdier, i øjeblikket indeholder entydige værdier. I begge tilfælde kan du opdatere kardinalitetstypen, så længe alle "en"-sidekolonner indeholder entydige værdier (eller tabellen endnu ikke er indlæst med rækker med data).

Kardinalitet for en til mange (og mange til en)

Kardinalitetsindstillingerne én til mange og mange til en er stort set de samme, og de er også de mest almindelige kardinalitetstyper.

Når du konfigurerer en en til mange- eller mange til en-relation, skal du vælge den, der svarer til den rækkefølge, du har relateret kolonnerne i. Overvej, hvordan du konfigurerer relationen fra tabellen Product til tabellen Sales ved hjælp af kolonnen ProductID , der findes i hver tabel. Kardinalitetstypen er én til mange, da kolonnen ProductID i tabellen Product indeholder entydige værdier. Hvis du har relateret tabellerne i den modsatte retning, Sales to Product, vil kardinaliteten være mange til en.

En til en-kardinalitet

En en til en-relation betyder, at begge kolonner indeholder entydige værdier. Denne kardinalitetstype er ikke almindelig, og den repræsenterer sandsynligvis et uoptimalt modeldesign på grund af lagringen af redundante data.

Du kan finde flere oplysninger om brug af denne kardinalitetstype i Vejledning til en-til-en-relationer.

Mange til mange-kardinalitet

En mange til mange-relation betyder, at begge kolonner kan indeholde dubletværdier. Denne kardinalitetstype bruges sjældent. Det er typisk nyttigt, når du designer komplekse modelkrav. Du kan bruge den til at relatere mange til mange-fakta eller til at relatere fakta med højere detaljeringsrunder. Når salgsmålfakta f.eks. gemmes på produktkategoriniveau, og tabellen med produktdimensioner gemmes på produktniveau.

Du kan finde en vejledning i, hvordan du bruger denne kardinalitetstype, i Vejledning til mange til mange-relationer.

Bemærk

Kardinalitetstypen Mange til mange understøttes for modeller, der er udviklet til Power BI-rapportserver. januar 2024 og nyere.

Tip

I Power BI Desktop-modelvisning kan du fortolke en relations kardinalitetstype ved at se på indikatorerne (1 eller *) på begge sider af relationslinjen. Hvis du vil finde ud af, hvilke kolonner der er relateret, skal du markere eller holde markøren over relationslinjen for at fremhæve kolonnerne.

Retning af krydsfiltrering

Hver modelrelation er defineret med en tværgående filterretning. Indstillingen bestemmer den eller de retninger, som filtrene overføres i. De mulige indstillinger for tværgående filtrering afhænger af kardinalitetstypen.

Kardinalitetstype	Indstillinger for tværgående filtrering
En til mange (eller mange til en)	Enkelt Både
En til en	Både
Mange til mange	Enkelt (Tabel1 til Tabel2) Enkelt (Tabel2 til Tabel1) Både

Enkelt tværgående filterretning betyder "enkelt retning", og Begge betyder "begge retninger". En relation, der filtrerer i begge retninger, beskrives ofte som tovejs.

I forbindelse med en til mange-relationer er den tværgående filterretning altid fra "en"-siden og eventuelt fra "mange"-siden (tovejs). For en til en-relationer er den tværgående filterretning altid fra begge tabeller. Til sidst kan tværgående filterretning for mange til mange-relationer være fra enten en af tabellerne eller fra begge tabeller. Bemærk, at når kardinalitetstypen indeholder en "en"-side, overføres filtrene altid fra den pågældende side.

Når den tværgående filterretning er angivet til Begge, bliver en anden egenskab tilgængelig. Det kan anvende tovejsfiltrering, når Power BI gennemtvinger sikkerhed på rækkeniveau (RLS) regler. Du kan få flere oplysninger om sikkerhed på rækkeniveau under Sikkerhed på rækkeniveau med Power BI Desktop.

Du kan ændre relationens tværgående filterretning, herunder deaktivering af filteroverførsel, ved hjælp af en modelberegning. Det opnås ved hjælp af DAX-funktionen CROSSFILTER .

Vær opmærksom på, at tovejsrelationer kan påvirke ydeevnen negativt. Hvis du forsøger at konfigurere en tovejsrelation, kan det desuden resultere i tvetydige filteroverførselsstier. I dette tilfælde kan Power BI Desktop muligvis ikke bekræfte relationsændringen og advare dig med en fejlmeddelelse. Nogle gange kan Power BI Desktop dog give dig mulighed for at definere tvetydige relationsstier mellem tabeller. Flertydighed i løsning af relationsstien beskrives senere i denne artikel.

Vi anbefaler, at du kun bruger tovejsfiltrering efter behov. Du kan finde flere oplysninger i Vejledning til tovejsrelationer.

Tip

I Power BI Desktop-modelvisning kan du fortolke en relations tværgående filterretning ved at lægge mærke til pilespidserne langs relationslinjen. En enkelt pilespids repræsenterer et filter i en enkelt retning i pilespidsens retning. en dobbelt pilespids repræsenterer en tovejsrelation.

Aktivér denne relation

Der kan kun være én aktiv filteroverførselssti mellem to modeltabeller. Det er dog muligt at introducere yderligere relationsstier, selvom du skal angive disse relationer som inaktive. Inaktive relationer kan kun aktiveres under evalueringen af en modelberegning. Det opnås ved hjælp af DAX-funktionen USERELATIONSHIP .

Generelt anbefaler vi, at du definerer aktive relationer, når det er muligt. De udvider omfanget af og potentialet for, hvordan rapportforfattere kan bruge din model. Hvis du kun bruger aktive relationer, betyder det, at dimensionstabeller med forskellige roller skal duplikeres i din model.

I bestemte situationer kan du dog definere en eller flere inaktive relationer for en dimensionstabel med forskellige roller. Du kan overveje dette design, når:

• Der er ikke noget krav om, at rapportvisualiseringer filtrerer efter forskellige roller samtidigt.
• Du kan bruge USERELATIONSHIP DAX-funktionen til at aktivere en bestemt relation for relevante modelberegninger.

Du kan finde flere oplysninger under Vejledning til aktive i forhold til inaktive relationer.

Tip

I Power BI Desktop-modelvisning kan du fortolke en relations aktive status i forhold til inaktiv status. En aktiv relation repræsenteres af en udfyldt linje. en inaktiv relation repræsenteres som en stiplet linje.

Antag referentiel integritet

Egenskaben Antag referentiel integritet er kun tilgængelig for en til mange- og en til en-relationer mellem to DirectQuery-lagertilstandstabeller, der tilhører den samme kildegruppe. Du kan kun aktivere denne egenskab, når kolonnen "mange" ikke indeholder NULLs.

Når indstillingen er aktiveret, joinforbinder oprindelige forespørgsler, der sendes til datakilden, de to tabeller ved hjælp af en INNER JOIN i stedet for en OUTER JOIN. Aktivering af denne egenskab forbedrer generelt forespørgslens ydeevne, selvom den afhænger af specifikationerne for datakilden.

Aktivér altid denne egenskab, når der findes en fremmed nøglebegrænsning for databasen mellem de to tabeller. Selvom der ikke findes en fremmed nøglebegrænsning, kan du overveje at aktivere egenskaben, så længe du er sikker på, at der findes dataintegritet.

Vigtigt

Hvis dataintegriteten bliver kompromitteret, eliminerer den indre joinforbindelse uoverensstemmende rækker mellem tabellerne. Overvej f.eks. en modeltabel af typen Sales med en værdi i kolonnen ProductID, der ikke findes i den relaterede produkttabel. Filteroverførsel fra tabellen Product til tabellen Sales eliminerer salgsrækker for ukendte produkter. Dette ville resultere i en underdrivelse af salgsresultaterne.

Du kan finde flere oplysninger under Antag indstillinger for referentiel integritet i Power BI Desktop.

Relevante DAX-funktioner

Der er flere DAX-funktioner, der er relevante for modelrelationer. Hver funktion beskrives kort i følgende punktopstilling:

• RELATED: Henter værdien fra "en"-siden af en relation. Det er nyttigt, når du involverer beregninger fra forskellige tabeller, der evalueres i rækkekontekst.
• RELATEDTABLE: Hent en tabel med rækker fra "mange"-siden af en relation.
• USERELATIONSHIP: Gør det muligt for en beregning at bruge en inaktiv relation. (Teknisk set ændrer denne funktion vægten af en bestemt inaktiv modelrelation, hvilket hjælper med at påvirke brugen af den). Det er nyttigt, når din model indeholder en dimensionstabel med forskellige roller, og du vælger at oprette inaktive relationer fra denne tabel. Du kan også bruge denne funktion til at løse flertydighed i filterstier.
• CROSSFILTER: Ændrer relationens tværgående filterretning (til en eller begge), eller den deaktiverer filteroverførsel (ingen). Det er nyttigt, når du har brug for at ændre eller ignorere modelrelationer under evalueringen af en bestemt beregning.
• COMBINEVALUES: Joinforbinder to eller flere tekststrenge til én tekststreng. Formålet med denne funktion er at understøtte relationer med flere kolonner i DirectQuery-modeller, når tabeller tilhører den samme kildegruppe.
• TREATAS: Anvender resultatet af et tabeludtryk som filtre på kolonner fra en ikke-relateret tabel. Det er nyttigt i avancerede scenarier, når du vil oprette en virtuel relation under evalueringen af en bestemt beregning.
• Overordnede og underordnede funktioner: En serie relaterede funktioner, som du kan bruge til at generere beregnede kolonner for at naturalisere et overordnet/underordnet-hierarki. Du kan derefter bruge disse kolonner til at oprette et hierarki på fast niveau.

Evaluering af relationer

Modelrelationer klassificeres fra et evalueringsperspektiv som enten almindelige eller begrænsede. Det er ikke en konfigurerbar relationsegenskab. Det udledes faktisk af kardinalitetstypen og datakilden for de to relaterede tabeller. Det er vigtigt at forstå evalueringstypen, fordi der kan være konsekvenser for ydeevnen eller konsekvenser, hvis dataintegriteten kompromitteres. Disse konsekvenser og integritetskonsekvenser er beskrevet i dette emne.

For det første kræves der modelleringsteori for fuldt ud at forstå relationsevalueringer.

En import- eller DirectQuery-model henter alle dataene fra enten Vertipaq-cachen eller kildedatabasen. I begge tilfælde kan Power BI bestemme, at der findes en "en"-side af en relation.

En sammensat model kan dog indeholde tabeller ved hjælp af forskellige lagringstilstande (import, DirectQuery eller dual) eller flere DirectQuery-kilder. Hver kilde, herunder Vertipaq-cachen for importerede data, anses for at være en kildegruppe. Modelrelationer kan derefter klassificeres som en intern kildegruppe eller en intern/tværgående kildegruppe. En relation mellem en intern kildegruppe relaterer to tabeller i en kildegruppe, mens en relation mellem en intern/tværgående kildegruppe relaterer tabeller på tværs af to kildegrupper. Bemærk, at relationer i import- eller DirectQuery-modeller altid er en intern kildegruppe.

Her er et eksempel på en sammensat model.

I dette eksempel består den sammensatte model af to kildegrupper: en Vertipaq-kildegruppe og en DirectQuery-kildegruppe. Vertipaq-kildegruppen indeholder tre tabeller, og DirectQuery-kildegruppen indeholder to tabeller. Der findes en relation på tværs af kildegrupper for at relatere en tabel i Vertipaq-kildegruppen til en tabel i DirectQuery-kildegruppen.

Almindelige relationer

En modelrelation er almindelig , når forespørgselsprogrammet kan bestemme relationens "en"-side. Den har bekræftelse på, at kolonnen "en" indeholder entydige værdier. Alle en til mange-relationer i en intern kildegruppe er almindelige relationer.

I følgende eksempel er der to almindelige relationer, der begge er markeret som R. Relationer omfatter en til mange-relationen i Vertipaq-kildegruppen og en til mange-relationen i DirectQuery-kilden.

I forbindelse med importmodeller, hvor alle data gemmes i Vertipaq-cachen, opretter Power BI en datastruktur for hver almindelige relation på dataopdateringstidspunktet. Datastrukturerne består af indekserede tilknytninger af alle kolonne-til-kolonne-værdier, og deres formål er at fremskynde sammenføjning af tabeller på forespørgselstidspunktet.

På forespørgselstidspunktet tillader almindelige relationer tabeludvidelse . Tabeludvidelse resulterer i oprettelse af en virtuel tabel ved at inkludere de oprindelige kolonner i basistabellen og derefter udvide til relaterede tabeller. I forbindelse med importtabeller udføres tabeludvidelsen i forespørgselsprogrammet. for DirectQuery-tabeller udføres det i den oprindelige forespørgsel, der sendes til kildedatabasen (så længe egenskaben Antag referentiel integritet ikke er aktiveret). Forespørgselsprogrammet reagerer derefter på den udvidede tabel og anvender filtre og gruppering efter værdierne i de udvidede tabelkolonner.

Bemærk

Inaktive relationer udvides også, selvom relationen ikke bruges af en beregning. Tovejsrelationer påvirker ikke tabeludvidelsen.

I forbindelse med en til mange-relationer sker tabeludvidelsen fra "mange" til "en"-siderne ved hjælp LEFT OUTER JOIN af semantik. Når der ikke findes en tilsvarende værdi fra "mange"-siden til "en"-siden, føjes der en tom virtuel række til "en"-sidetabellen. Denne funktionsmåde gælder kun for almindelige relationer, ikke for begrænsede relationer.

Tabeludvidelse sker også for en til en-relationer i en intern kildegruppe, men ved hjælp FULL OUTER JOIN af semantik. Denne jointype sikrer, at der tilføjes tomme virtuelle rækker på begge sider, når det er nødvendigt.

Tomme virtuelle rækker er reelt ukendte medlemmer. Ukendte medlemmer repræsenterer overtrædelser af referentiel integritet, hvor "mange"-sideværdien ikke har en tilsvarende "en"-sideværdi. Ideelt set bør disse tomme værdier ikke findes. De kan fjernes ved at rense eller reparere kildedataene.

Sådan fungerer tabeludvidelse med et animeret eksempel.

I dette eksempel består modellen af tre tabeller: Kategori, Produkt og Salg. Tabellen Kategori er relateret til tabellen Product med en en til mange-relation, og tabellen Product er relateret til tabellen Sales med en en til mange-relation. Tabellen Kategori indeholder to rækker, tabellen Product indeholder tre rækker, og tabellerne Sales indeholder fem rækker. Der er matchende værdier på begge sider af alle relationer, hvilket betyder, at der ikke er nogen overtrædelser af referentiel integritet. Der vises en udvidet tabel med forespørgselstid. Tabellen består af kolonnerne fra alle tre tabeller. Det er i praksis et denormaliseret perspektiv af dataene i de tre tabeller. Der føjes en ny række til tabellen Sales , og den har en produktions-id-værdi (9), der ikke har nogen tilsvarende værdi i tabellen Product . Det er en overtrædelse af referentiel integritet. I den udvidede tabel har den nye række (Tom) værdier for kolonnerne Kategori og Produkt .

Begrænsede relationer

En modelrelation er begrænset , når der ikke er nogen garanteret "en"-side. Der kan opstå en begrænset relation af to årsager:

• Relationen bruger en mange til mange-kardinalitetstype (også selvom en eller begge kolonner indeholder entydige værdier).
• Relationen er tværgående kildegruppe (hvilket kun kan være tilfældet for sammensatte modeller).

I følgende eksempel er der to begrænsede relationer, der begge er markeret som L. De to relationer omfatter mange til mange-relationen i Vertipaq-kildegruppen og en til mange-relationen på tværs af kildegrupper.

I forbindelse med importmodeller oprettes der aldrig datastrukturer for begrænsede relationer. I dette tilfælde løser Power BI tabeljoinforbindelser på forespørgselstidspunktet.

Tabeludvidelse sker aldrig for begrænsede relationer. Tabeljoinforbindelser opnås ved hjælp INNER JOIN af semantik, og derfor tilføjes der ikke tomme virtuelle rækker for at kompensere for overtrædelser af referentiel integritet.

Der er andre begrænsninger i forbindelse med begrænsede relationer:

• RELATED DAX-funktionen kan ikke bruges til at hente kolonneværdierne på "en"-siden.
• Gennemtvingelse af sikkerhed på rækkeniveau har topologibegrænsninger.

Tip

I Power BI Desktop-modelvisning kan du fortolke en relation som begrænset. En begrænset relation repræsenteres med parenteslignende mærker ( ) efter kardinalitetsindikatorerne.

Løs flertydighed i relationsstien

Tovejsrelationer kan introducere flere og derfor tvetydige stier til filteroverførsel mellem modeltabeller. Når du evaluerer flertydighed, vælger Power BI stien til filteroverførsel i henhold til dens prioritet og vægt.

Prioritet

Prioritetsniveauer definerer en sekvens af regler, som Power BI bruger til at løse flertydighed i relationsstien. Det første regelmatch bestemmer, hvilken sti Power BI følger. Hver regel nedenfor beskriver, hvordan filtre flyder fra en kildetabel til en destinationstabel.

1. En sti, der består af en til mange-relationer.
2. En sti, der består af en til mange- eller mange til mange-relationer.
3. En sti, der består af mange til en-relationer.
4. En sti, der består af en til mange-relationer fra kildetabellen til en mellemliggende tabel efterfulgt af mange til en-relationer fra den mellemliggende tabel til måltabellen.
5. En sti, der består af en til mange- eller mange til mange-relationer fra kildetabellen til en mellemliggende tabel efterfulgt af mange til en- eller mange til mange-relationer fra den mellemliggende tabel til måltabellen.
6. Enhver anden sti.

Når en relation er inkluderet i alle tilgængelige stier, fjernes den fra overvejelser fra alle stier.

Tykkelse

Hver relation i en sti har en vægt. Hver relationsvægt er som standard lig med, medmindre funktionen USERELATIONSHIP bruges. Stitykkelsen er det maksimale af alle relationstykkelser langs stien. Power BI bruger stitykkelserne til at løse flertydighed mellem flere stier på det samme prioritetsniveau. Den vælger ikke en sti med en lavere prioritet, men den vælger stien med den højere vægt. Antallet af relationer i stien påvirker ikke vægten.

Du kan påvirke vægten af en relation ved hjælp af funktionen USERELATIONSHIP . Vægten bestemmes af indlejringsniveauet for opkaldet til denne funktion, hvor det inderste kald modtager den højeste vægt.

Overvej følgende eksempel. Målingen Product Sales tildeler en højere vægt til relationen mellem Sales[ProductID] og Product[ProductID] efterfulgt af relationen mellem Inventory[ProductID] og Product[ProductID].

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

Bemærk

Hvis Power BI registrerer flere stier, der har samme prioritet og samme vægt, returnerer det en tvetydig stifejl. I dette tilfælde skal du løse flertydigheden ved at påvirke relationsvægtene ved hjælp af funktionen USERELATIONSHIP eller ved at fjerne eller ændre modelrelationer.

Indstillinger for ydeevne

Følgende listeordrer filtrerer overførselsydeevnen fra hurtigst til langsomst:

1. En til mange-relationer i en intern kildegruppe
2. Mange til mange-modelrelationer, der opnås med en mellemliggende tabel, og som involverer mindst én tovejsrelation
3. Mange til mange-kardinalitetsrelationer
4. Relationer på tværs af kildegrupper

Relateret indhold

Du kan få flere oplysninger om denne artikel i følgende ressourcer:

• Forstå stjerneskemaet og vigtigheden af Power BI
• Vejledning til en til en-relationer
• Vejledning til mange til mange-relationer
• Vejledning til aktive forhold i forhold til inaktive relationer
• Vejledning til tovejsrelationer
• Vejledning til fejlfinding af relationer
• Video: Må og ikke-gøre-det i Power BI-relationer
• Spørgsmål? Prøv at spørge Power BI-community'et
• Forslag? Bidrag med idéer til forbedring af Power BI