Modellrelationer i Power BI Desktop

Den här artikeln är avsedd för importdatamodellerare som arbetar med Power BI Desktop. Modelldesign är viktigt när det kommer till att leverera intuitiva, exakta och optimala modeller.

Du hittar en djupare diskussion om optimal modelldesign, inklusive tabellroller och relationer, i artikeln om hur man kan förstå star-scheman och dess betydelse för Power BI.

Syftet med relationer

Lite förenklat kan man säga att Power BI-relationer sprider filter som tillämpas på kolumnerna i modelltabeller till andra modelltabeller. Filter kommer att spridas vidare så långt relationens sökväg sträcker sig, vilket betyder att de kan spridas till flera tabeller.

Relationssökvägar är deterministiska, vilket innebär att filter alltid sprids på samma sätt och utan slumpmässig variation. Relationer kan emellertid inaktiveras eller så kan filterkontexten ändras av modellberäkningar som använder särskilda DAX-funktioner. Mer information finns i avsnittet om relevanta DAX-funktioner längre fram i den här artikeln.

Nu ska vi se hur relationer sprider filter vidare med ett animerat exempel.

I det här exemplet består modellen av fyra tabeller: Kategori, Produkt, År och Försäljning. Tabellen Kategori är relaterad till tabellen Produkt och tabellen Produkt är relaterad till tabellen Försäljning. Tabellen År är också relaterad till tabellen Försäljning. Alla relationer är av typen en-till-många (detta förklaras närmare i slutet av artikeln).

En fråga – kanske genererad av ett visuellt objekt för ett Power BI-kort – frågar efter den totala försäljningskvantiteten för säljordrar för en enda kategori, Cat-A, och för ett enda år, CY2018. Det är därför du kan se filter som tillämpas på tabellerna Kategori och År. Filtret för tabellen Kategori sprids till tabellen Produkt för att isolera två produkter som har tilldelats kategorin Cat-A. Sedan kan tabellfiltren för Produkt spridas till tabellen Försäljning för att isolera bara två försäljningsrader för dessa produkter. Dessa två försäljningsrader representerar försäljningen av produkter som tilldelats kategorin Cat-A. Deras sammanlagda kvantitet är 14 enheter. Samtidigt sprids tabellfiltret för År vidare, för att ytterligare filtrera tabellen Försäljning, vilket ger bara en försäljningsrad för produkter som är tilldelade kategorin Cat-A och som beställdes under året CY2018. Frågan returnerar värdet 11 enheter. Observera att när flera filter tillämpas på en tabell (t.ex. tabellen Försäljning i det här exemplet) är det alltid en AND-operation, vilket kräver att alla villkor måste vara uppfyllda.

Frånkopplade tabeller

Det är ovanligt att en modelltabell inte alls är relaterad till en annan modelltabell. En sådan tabell, i en giltig modelldesign, kallas en frånkopplad tabell. En frånkopplad tabell är inte avsedd att sprida filter till andra modelltabeller. Den används istället för att godkänna "användarindata" (kanske med ett visuellt utsnitt), så att modellberäkningar kan använda indatavärdet på ett meningsfullt sätt. Anta till exempel att en frånkopplad tabell har lästs in med ett intervall av värden för valutaväxelkurser. Så länge ett filter används för att filtrera efter ett enda värde, kan värdet användas genom ett måttuttryck för att konvertera försäljningsvärden.

Konsekvensparametern i Power BI Desktop är en funktion som skapar en frånkopplad tabell. Mer information finns i artikeln om att skapa och använda en konsekvensparameter för att visualisera variabler i Power BI Desktop.

Relationsegenskaper

En modellrelation relaterar en kolumn i en tabell till en kolumn i en annan tabell. (Det finns ett specialfall, där detta krav inte är uppfyllt, och det gäller endast för relationer i flera kolumner i DirectQuery-modeller. Mer information finns i artikeln om DAX-funktionen COMBINEVALUES.)

Kardinalitet

Varje modellrelation måste definieras med en kardinalitetstyp. Det finns fyra alternativ för kardinalitetstyp, som representerar dataegenskaperna för relaterade kolumner "från" och "till". "En"-sidan innebär att kolumnen innehåller unika värden. "många"-sidan innebär att kolumnen kan innehålla dubblettvärden.

De fyra alternativen, tillsammans med deras stenografiska format, beskrivs i följande punktlista:

• En-till-många (1:*)
• Många-till-en (*:1)
• En-till-en (1:1)
• Många-till-många (*:*)

När du skapar en relation i Power BI Desktop, kommer designern automatiskt detektera och ange kardinalitetstypen. Designern skickar frågor till modellen för att veta vilka kolumner som innehåller unika värden. För importmodeller använder den intern lagringsstatistik, för DirectQuery-modeller skickar den profileringsfrågor till datakällan. Men ibland går det fel. Det beror på att tabellerna inte har fyllts på med data än, eller på att kolumnerna du förväntar dig ska innehålla dubblettvärden bara innehåller unika värden för tillfället. I vilket fall kan du uppdatera kardinalitetstypen, under förutsättning att ”en”-sidekolumner innehåller unika värden (eller att tabellen väntar på att laddas med datarader).

Kardinaliteten En-till-många- och Många-till-en är i stort sett samma, och de är även de vanligaste kardinalitetstyperna.

När du konfigurerar en en-till-många-relationer eller många-till-en-relationer, väljer du den som matchar den ordning du har relaterat kolumnerna i. Överväg hur du skulle konfigurera relationen från tabellen Produkt till tabellen Försäljning med hjälp av kolumnen ProduktID som finns i varje tabell. Kardinalitetstypen skulle vara En-till-många, eftersom kolumnen ProduktID i tabellen Produkt innehåller unika värden. Om du har relaterat tabellerna i omvänd riktning, Försäljning till Produkt, skulle kardinaliteten bli Många-till-en.

Ett förhållande En-till-en innebär att båda kolumnerna innehåller unika värden. Den här typen av kardinalitet är inte vanlig, och det är troligen inte en optimal modelldesign, eftersom den leder till lagring av redundanta data. Mer information om hur du använder den här typen av kardinalitet finns i Vägledning för en-till-en-relation.

En många-till-många-relation innebär att båda kolumnerna kan innehålla dubblettvärden. Den här typen av kardinalitet används sällan. Den används vanligen när du utformar komplexa modellkrav. Vägledning om hur du använder den här kardinalitetstypen finns i Vägledning för att lägga till en många-till-många-relationer.

Korsfilterriktning

Varje modellrelation måste definieras med en korsfilterriktning. Ditt val avgör i vilken riktning som filtren kommer att spridas. Vilka korsfilteralternativ som är möjliga beror på kardinalitetstypen.

Enkel korsfilterriktning betyder "enkel riktning" och båda betyder "båda riktningar". En relation som filtrerar i båda riktningarna kallas ofta dubbelriktad.

För en-till-många-relationer går korsfilterriktningen alltid från ”en”-sidan och som tillval från ”många”-sidan (dubbelriktad). För en-till-en-relationer går korsfilterriktningen alltid från båda tabellerna. Slutligen, för många-till-många-relationer, kan korsfilterriktningen gå från en av tabellerna eller från båda tabellerna. Observera att när kardinalitetstypen innehåller en "en"-sida, kommer filtret alltid att spridas från den sidan.

När korsfilterriktningen är inställd på båda, är ytterligare en egenskap tillgänglig. Den kan använda dubbelriktad filtrering när regler för säkerhet på radnivå (RLS) tillämpas. Mer information om RLS finns i artikeln om säkerhet på radnivå (RLS) med Power BI Desktop.

Ändringar av relationskorsfilterriktningen, inklusive inaktivering av filterspridning, kan också göras med en modellberäkning. Detta görs med DAX-funktionen CROSSFILTER.

Dubbelriktade relationer kan påverka prestandan negativt. Om du försöker konfigurera en dubbelriktad relation kan det leda till tvetydiga filterspridningsvägar. I det här fallet kan det hända att Power BI Desktop inte kan genomföra relationsändringen och du får då ett felmeddelande. Ibland kan Power BI Desktop emellertid tillåta att du definierar tvetydiga relationsvägar mellan tabeller. Prioritetsregler som påverkar detekteringen av tvetydigheter och sökvägsupplösning beskrivs längre fram i den här artikeln om prioritetsregler.

Vi rekommenderar att du bara använder dubbelriktad filtrering när det verkligen behövs. Mer information finns i Vägledning för dubbelriktad relation.

Gör den här relationen aktiv

Det kan bara finnas en aktiv väg för filtreringsspridning mellan två modelltabeller. Det går emellertid att lägga till ytterligare relationsvägar, även om dessa relationer måste konfigureras som inaktiva. Inaktiva relationer kan bara göras aktiva under utvärderingen av en modellberäkning. Detta görs med DAX-funktionen USERELATIONSHIP.

Mer information finns i Vägledning för aktiva kontra inaktiva relationer.

Anta referensintegritet

Egenskapen Anta referensintegritet är bara tillgängligt för en-till-många-relationer och en-till-en-relationer mellan två DirectQuery-tabeller i lagringsläge som baseras på samma datakälla. När den är aktiverad kommer internfrågor som skickas till datakällan att koppla samman de två tabellerna med en inre koppling istället för en yttre koppling. Den här egenskapen leder vanligtvis till en allmän förbättring av frågeprestanda om den aktiveras, även om det beror på de specifika egenskaperna för datakällan.

Aktivera alltid denna egenskap när det finns en begränsning för den sekundära nyckeln för databasen mellan de två tabellerna. Om det inte finns en begränsning för sekundärnyckeln, kan du fortfarande aktivera egenskapen, om du är säker på att dataintegritet föreligger.

Relevanta DAX-funktioner

Det finns flera DAX-funktioner som är relevanta för modellrelationer. Varje funktion beskrivs kortfattat i följande punktlista:

• RELATED: Hämtar värdet från "en"-sidan.
• RELATEDTABLE: Hämta en tabell med rader från "många"-sidan.
• USERELATIONSHIP: Tvingar fram användningen av en specifik inaktiv modellrelation.
• CROSSFILTER: Ändrar relationens korsfilterriktning (till en eller båda), eller inaktiverar filterspridningen (ingen).
• COMBINEVALUES: Förenar två eller fler textsträngar till en textsträng. Syftet med den här funktionen är att stödja relationer med flera kolumner i DirectQuery-modeller.
• TREATAS: Applicerar resultatet av ett tabelluttryck som filter till kolumner från en orelaterad tabell.
• Över-och underordnade funktioner: En serie relaterade funktioner som kan användas för att generera beräknade kolumner, för att naturalisera en överordnad-underordnad hierarki. Dessa kolumner kan sedan användas för att skapa en hierarki med fast nivå.

Relationsbedömning

Modellrelationer klassificeras antingen som starka eller svaga ur ett utvärderingsperspektiv. Det är inte en konfigurerbar relationsegenskap. Den är faktiskt härledd från kardinalitetstypen och datakällan för de två relaterade tabellerna. Det är viktigt att förstå utvärderingstypen, eftersom det kan uppstå prestandaeffekter eller konsekvenser om dataintegriteten komprometteras. Dessa konsekvenser och integritetskonsekvenser beskrivs i det här avsnittet.

Men först behöver vi lite modelleringsteori för att helt kunna förstå relationsutvärderingarna.

En import- eller DirectQuery-modell lagrar alla sina data från antingen Vertipaq-cachen eller källdatabasen. I båda fall kan Power BI avgöra om det finns en "en"-sida av en relation.

En sammansatt modell kan emellertid bestå av tabeller med olika lagringslägen (import, DirectQuery eller dubbel) eller flera DirectQuery-källor. Alla källor, inklusive Vertipaq-cachen för importdata, anses vara en källgrupp. Modellrelationer kan sedan klassificeras som intra-källgrupp eller inter-/korskällgrupp. En intra-källgrupprelation är en relation som relaterar två tabeller i en källgrupp, medan en inter-/korskällgrupp relaterar tabeller från olika källgrupper. Observera att relationer i Import- eller DirectQuery-modeller är alltid av typen intra-källgrupp.

Låt oss titta på en sammansatt modell.

I det här exemplet består den sammansatta modellen av två källgrupper: en Vertipaq-källgrupp och en DirectQuery-källgrupp. Vertipaq-källgruppen innehåller tre tabeller och DirectQuery-källgruppen innehåller två tabeller. En relation av typen kors-källgrupp finns för att koppla en tabell i Vertipaq-källgruppen till en tabell i DirectQuery-källgruppen.

Vanliga relationer

En modellrelation är vanlig när frågemotorn kan fastställa relationens ”en”-sida. Den har fått bekräftelse på att kolumnen på "en"-sidan innehåller unika värden. Alla en-till-många-relationer mellan intra-källgrupper är vanliga relationer.

I följande exempel finns det två vanliga relationer, båda markerade som R. Relationer omfattar en-till-många-relationerna som finns i Vertipaq-källgruppen samt en-till-många-relationerna i DirectQuery-källan.

För importmodeller där alla data lagras i Vertipaq-cachen skapas en datastruktur för varje vanlig relation när data uppdateras. Datastrukturerna består av indexerade mappningar för alla kolumn-till-kolumn-värden och syftet är att snabba upp kopplingen av tabeller när frågan körs.

När en fråga körs tillåter vanliga relationer att tabellen utökas. Tabellexpansionen resulterar i att en virtuell tabell skapas, genom att de interna kolumnerna i bastabellen inkluderas och sedan utökas till relaterade tabeller. För importtabeller görs detta i frågemotorn. För DirectQuery-tabeller görs det i den interna frågan som skickas till källdatabasen (förutsatt att egenskapen Anta referensintegritet inte är aktiverad). Frågemotorn jobbar sedan med den expanderade tabellen och använder filter och gruppering utifrån värdena i de expanderade tabellkolumnerna.

Vid en-till-många-relationer sker tabellexpansionen från ”många” till ”en” med hjälp av semantiken VÄNSTER YTTRE KOPPLING. Om det inte finns ett matchande värde från "många"- till "en"-sidan, läggs en tom virtuell rad till i tabellen på "en"-sidan.

Tabellexpansion utförs även för en-till-en-relationer av typen intra-källgrupp, men med fullständig yttre kopplings-semantik. Det säkerställer att tomma virtuella rader läggs till på endera sidan, om det behövs.

De tomma virtuella raderna är i praktiken okända medlemmar. Okända medlemmar representerar överträdelser av referensintegriteten, där värdet på "många"-sidan inte har något motsvarande värde på "en"-sidan. I det optimala fallet ska dessa tomma rader inte existera, och de kan tas bort genom rengöring eller reparation av källdata.

Låt oss ta en titt på hur tabellexpansionen fungerar med ett animerat exempel.

I det här exemplet består modellen av tre tabeller: Kategori, Produkt och Försäljning. Tabellen Kategori är relaterad till tabellen Produkt med en en-till-många-relation, och tabellen Produkt är relaterad till tabellen Försäljning med en en-till-många-relation. Tabellen Kategori innehåller två rader, tabellen Produkt innehåller tre rader och tabellen Försäljning innehåller fem rader. Det finns matchande värden på båda sidor av alla relationer, vilket innebär att det inte finns några överträdelser av referensintegriteten. En expanderad tabell visas när frågan körs. Tabellen består av kolumnerna från alla tre tabeller. Det är i praktiken ett avnormaliserat perspektiv av de data som finns i de tre tabellerna. En ny rad läggs till i tabellen Försäljning, med ett produktions-ID-värde (9) som inte har något matchande värde i tabellen Produkt. Det är en överträdelse av referensintegriteten. I den expanderade tabellen har den nya raden (tomma) värden för tabellkolumnerna Kategori och Produkt.

Begränsade relationer

En modellrelation är begränsad när det inte finns någon garanterad ”en”-sida. Det kan bero på två saker:

• Relationen använder kardinalitetstypen många-till-många (även om en eller båda kolumner innehåller unika värden)
• Relationen är av typen kors-källgrupp (som bara kan användas för sammansatta modeller)

I följande exempel finns det två begränsade relationer, båda markerade som L. De två relationerna omfattar de många-till-många-relationer som finns i Vertipaq-källgruppen samt en-till-många-relationerna i korskällgrupprelationen.

I importmodeller skapas aldrig datastrukturer för begränsade relationer. Det innebär att tabellkopplingarna måste lösas vid när frågan körs.

Tabeller utökas aldrig för begränsade relationer. Tabellkopplingar uppnås med hjälp av inre kopplings-semantik, och därför läggs tomma virtuella rader inte till för att kompensera för överträdelser av referensintegriteten.

Begränsade relationer har även fler restriktioner:

• DAX-funktionen RELATED kan inte användas för att hämta kolumnvärden på ”en”-sidan
• Det finns begränsningar i topologin för tvingande RLS

Regler för prioritet

Dubbelriktade relationer kan leda till flera – och därför tvetydiga – filterspridningsvägar mellan modelltabellerna. I följande lista visas de regler för prioritet som Power BI använder för att identifiera tvetydigheter och vägupplösning:

1. Många-till-en- och en-till-en-relationer, inklusive begränsade relationer
2. Många-till-många-relationer
3. Dubbelriktade relationer, i omvänd riktning (d.v.s. från ”många”-sidan)

Inställningar för prestanda

I följande lista visas prestanda för filterspridning, från snabbast till långsammast prestanda:

1. En-till-många-relation mellan olika intra-källgrupper
2. Många-till-många-modellrelationer som uppnås med en mellanliggande tabell och som omfattar minst en dubbelriktad relation
3. Många-till-många-kardinalitetsrelationer
4. Relationer mellan kors-källgrupper

Nästa steg

Mer information om den här artikeln finns i följande resurser:

• Förstå star-schemat och dess betydelse för Power BI
• Vägledning för en-till-en-relation
• Vägledning för att lägga till en många-till-många-relationer
• Vägledning för aktiva kontra inaktiva relationer
• Vägledning för dubbelriktad relation
• Vägledning vid felsökning av relationer
• Video: Vad du bör och inte bör göra med Power BI-relationer
• Har du några frågor? Fråga Power BI Community
• Har du förslag? Bidra till att förbättra Power BI