Använda sammansatta modeller i Power BI Desktop

Tidigare i Power BI Desktop, när du använde en DirectQuery i en rapport, tilläts inga andra dataanslutningar, vare sig DirectQuery eller import, för den rapporten. Med sammansatta modeller tas den begränsningen bort. En rapport kan sömlöst inkludera dataanslutningar från mer än en DirectQuery- eller importdataanslutning, oavsett vilken kombination du väljer.

Funktionen sammansatta modeller i Power BI Desktop består av tre relaterade funktioner:

• Sammansatta modeller: Tillåter att en rapport har två eller flera dataanslutningar från olika källgrupper. Dessa källgrupper kan vara en eller flera DirectQuery-anslutningar och en importanslutning, två eller flera DirectQuery-anslutningar eller någon kombination av dessa. I den här artikeln beskrivs sammansatta modeller i detalj.

• Många-till-många-relationer: Med sammansatta modeller kan du upprätta många-till-många-relationer mellan tabeller. Den här metoden tar bort kraven på unika värden i tabeller. Den tar också bort tidigare lösningar, som att introducera nya tabeller endast för att upprätta relationer. Mer information finns i Tillämpa många-många-relationer i Power BI Desktop.

• Lagringsläge: Nu kan du ange vilka visuella objekt som frågar efter serverdelsdatakällor. Den här funktionen hjälper till att förbättra prestanda och minska belastningen på serverdelen. Tidigare initierade även enkla visuella objekt, till exempel utsnitt, frågor till serverdelskällor. Mer information finns i Hantera lagringsläge i Power BI Desktop.

Använda sammansatta modeller

Med sammansatta modeller kan du ansluta till olika typer av datakällor när du använder Power BI Desktop eller Power BI-tjänst. Du kan göra dessa dataanslutningar på ett par olika sätt:

• Genom att importera data till Power BI, vilket är det vanligaste sättet att hämta data.
• Genom att ansluta direkt till data i den ursprungliga källlagringsplatsen med hjälp av DirectQuery. Mer information om DirectQuery finns i DirectQuery i Power BI.

När du använder DirectQuery gör sammansatta modeller det möjligt att skapa en Power BI-modell, till exempel en enda .pbix Power BI Desktop-fil som utför någon av eller båda av följande åtgärder:

• Kombinerar data från en eller flera DirectQuery-källor.
• Kombinerar data från DirectQuery-källor och importerar data.

Genom att till exempel använda sammansatta modeller kan du skapa en modell som kombinerar följande typer av data:

• Försäljningsdata från ett företags informationslager.
• Försäljningsmåldata från en avdelningsbaserad SQL Server-databas.
• Data som importeras från ett kalkylblad.

En modell som kombinerar data från mer än en DirectQuery-källa eller som kombinerar DirectQuery med importdata kallas för en sammansatt modell.

Du kan skapa relationer mellan tabeller som du alltid har gjort, även när dessa tabeller kommer från olika källor. Alla relationer mellan källor skapas med kardinaliteten många-till-många, oavsett deras faktiska kardinalitet. Du kan ändra dem till en-till-många, många-till-en eller en-till-en. Oavsett vilken kardinalitet du anger har relationer mellan källor olika beteende. Du kan inte använda DAX-funktioner (Data Analysis Expressions) för att hämta värden på one sidan från many sidan. Du kan också se en prestandapåverkan jämfört med många-till-många-relationer inom samma källa.

Kommentar

Inom ramen för sammansatta modeller är alla importerade tabeller i praktiken en enda källa, oavsett de faktiska underliggande datakällorna.

Exempel på en sammansatt modell

Ett exempel på en sammansatt modell är att överväga en rapport som ansluter till ett företagsdatalager i SQL Server med hjälp av DirectQuery. I det här fallet innehåller informationslagret data om försäljning efter land, kvartal och cykel (produkt), enligt följande bild:

Nu kan du skapa enkla visuella objekt med hjälp av fält från den här källan. Följande bild visar den totala försäljningen efter ProductName för ett valt kvartal.

Men vad händer om du har data i ett Excel-kalkylblad om produkthanteraren som tilldelats varje produkt, tillsammans med marknadsföringsprioriteten? Om du vill visa försäljningsbelopp efter Product Manager kanske det inte går att lägga till dessa lokala data i företagets informationslager. Eller så kan det ta månader i bästa.

Det kan vara möjligt att importera dessa försäljningsdata från informationslagret i stället för att använda DirectQuery. Och försäljningsdata kan sedan kombineras med de data som du har importerat från kalkylbladet. Den metoden är dock orimlig av de skäl som ledde till att DirectQuery överst. Orsakerna kan vara:

• En kombination av de säkerhetsregler som tillämpas i den underliggande källan.
• Behovet av att kunna visa de senaste data.
• Den stora skalan av data.

Här kommer sammansatta modeller in. Med sammansatta modeller kan du ansluta till informationslagret med Hjälp av DirectQuery och sedan använda Hämta data för fler källor. I det här exemplet upprättar vi först DirectQuery-anslutningen till företagets informationslager. Vi använder Hämta data, väljer Excel och navigerar sedan till kalkylbladet som innehåller våra lokala data. Slutligen importerar vi kalkylbladet som innehåller produktnamnen, den tilldelade försäljningschefen och prioriteten.

I listan Fält kan du se två tabeller: den ursprungliga Bike-tabellen från SQL Server och en ny ProductManagers-tabell . Den nya tabellen innehåller data som importerats från Excel.

På samma sätt ser vi nu en annan tabell med namnet ProductManagers i relationsvyn i Power BI Desktop.

Nu måste vi relatera dessa tabeller till de andra tabellerna i modellen. Som alltid skapar vi en relation mellan tabellen Bike från SQL Server och den importerade tabellen ProductManagers . Relationen är alltså mellan Bike[ProductName] och ProductManagers[ProductName]. Som tidigare nämnts är alla relationer som går över källan standard till kardinaliteten många-till-många.

Nu när vi har upprättat den här relationen visas den i relationsvyn i Power BI Desktop, som vi kan förvänta oss.

Nu kan vi skapa visuella objekt med hjälp av något av fälten i listan Fält . Den här metoden blandar sömlöst data från flera källor. Till exempel visas den totala SalesAmount för varje Product Manager i följande bild:

I följande exempel visas ett vanligt fall för en dimensionstabell , till exempel Produkt eller Kund, som utökas med vissa extra data som importeras från någon annanstans. Det går också att låta tabeller använda DirectQuery för att ansluta till olika källor. Om du vill fortsätta med vårt exempel kan du tänka dig att försäljningsmål per land och period lagras i en separat avdelningsdatabas. Som vanligt kan du använda Hämta data för att ansluta till dessa data, enligt följande bild:

Som vi gjorde tidigare kan vi skapa relationer mellan den nya tabellen och andra tabeller i modellen. Sedan kan vi skapa visuella objekt som kombinerar tabelldata. Nu ska vi titta på vyn Relationer igen, där vi har upprättat de nya relationerna:

Nästa bild baseras på de nya data och relationer som vi har skapat. Det visuella objektet längst ned till vänster visar totalt försäljningsbelopp jämfört med mål, och variansberäkningen visar skillnaden. Försäljningsbelopp och måldata kommer från två olika SQL Server-databaser.

Ange lagringsläge

Varje tabell i en sammansatt modell har ett lagringsläge som anger om tabellen baseras på DirectQuery eller import. Lagringsläget kan visas och ändras i fönstret Egenskap . Om du vill visa lagringsläget högerklickar du på en tabell i listan Fält och väljer sedan Egenskaper. Följande bild visar lagringsläget för tabellen SalesTargets .

Lagringsläget kan också visas på knappbeskrivningen för varje tabell.

För alla Power BI Desktop-filer (en .pbix-fil ) som innehåller vissa tabeller från DirectQuery och vissa importtabeller visar statusfältet ett lagringsläge med namnet Mixed. Du kan välja den termen i statusfältet och enkelt växla alla tabeller till import.

Mer information om lagringsläge finns i Hantera lagringsläge i Power BI Desktop.

Kommentar

Du kan använda blandat lagringsläge i Power BI Desktop och i Power BI-tjänst.

Beräknade tabeller

Du kan lägga till beräknade tabeller i en modell i Power BI Desktop som använder DirectQuery. De dataanalysuttryck (DAX) som definierar den beräknade tabellen kan referera till antingen importerade tabeller eller DirectQuery-tabeller eller en kombination av de två.

Beräknade tabeller importeras alltid och deras data uppdateras när du uppdaterar tabellerna. Om en beräknad tabell refererar till en DirectQuery-tabell visar visuella objekt som refererar till DirectQuery-tabellen alltid de senaste värdena i den underliggande källan. Visuella objekt som refererar till den beräknade tabellen visar också värdena vid den tidpunkt då den beräknade tabellen senast uppdaterades.

Viktigt!

Beräknade tabeller stöds inte i Power BI-tjänst med den här funktionen om du inte uppfyller specifika krav. Mer information om detta finns i avsnittet Arbeta med en sammansatt modell baserat på en semantisk modell i den här artikeln.

Säkerhetskonsekvenser

Sammansatta modeller har vissa säkerhetskonsekvenser. En fråga som skickas till en datakälla kan innehålla datavärden som har hämtats från en annan källa. I det tidigare exemplet skickar det visuella objekt som visar (Försäljningsbelopp) av Product Manager en SQL-fråga till relationsdatabasen Försäljning. SQL-frågan kan innehålla namnen på Produktansvariga och deras associerade produkter.

Information som lagras i kalkylbladet ingår nu i en fråga som skickas till relationsdatabasen. Om den här informationen är konfidentiell bör du överväga säkerhetskonsekvenserna. Tänk särskilt på följande:

• Alla administratörer av databasen som kan visa spårnings- eller granskningsloggar kan visa den här informationen, även utan behörighet till data i den ursprungliga källan. I det här exemplet skulle administratören behöva behörigheter till Excel-filen.

• Krypteringsinställningarna för varje källa bör beaktas. Du vill undvika att hämta information från en källa med en krypterad anslutning och sedan oavsiktligt inkludera den i en fråga som skickas till en annan källa av en okrypterad anslutning.

Power BI Desktop visar ett varningsmeddelande när du skapar en sammansatt modell för att kunna bekräfta att du har övervägt eventuella säkerhetskonsekvenser.

Om en författare lägger till Table1 från Modell A till en sammansatt modell (låt oss kalla den Modell C som referens) kan en användare som visar en rapport som bygger på Model C fråga vilken tabell som helst i Modell A som inte skyddas av säkerhets-RLS på radnivå.

Av liknande skäl bör du vara försiktig när du öppnar en Power BI Desktop-fil som skickas från en ej betrodd källa. Om filen innehåller sammansatta modeller skickas information som någon hämtar från en källa genom att använda autentiseringsuppgifterna för den användare som öppnar filen till en annan datakälla som en del av frågan. Informationen kan visas av den skadliga författaren till Power BI Desktop-filen. När du först öppnar en Power BI Desktop-fil som innehåller flera källor visar Power BI Desktop en varning. Varningen liknar den som visas när du öppnar en fil som innehåller interna SQL-frågor.

Prestandaöverväganden

När du använder DirectQuery bör du alltid överväga prestanda, främst för att säkerställa att serverdelskällan har tillräckligt med resurser för att ge användarna en bra upplevelse. En bra upplevelse innebär att de visuella objekten uppdateras om fem sekunder eller mindre. Mer prestandainformation finns i DirectQuery i Power BI.

Att använda sammansatta modeller lägger till andra prestandaöverväganden. Ett enda visuellt objekt kan resultera i att frågor skickas till flera källor, vilket ofta skickar resultaten från en fråga till en annan källa. Den här situationen kan resultera i följande former av körning:

• En källfråga som innehåller ett stort antal literalvärden: Till exempel skulle ett visuellt objekt som begär totalt försäljningsbelopp för en uppsättning valda produktchefer först behöva hitta vilka produkter som hanterades av dessa produktchefer. Den här sekvensen måste ske innan det visuella objektet skickar en SQL-fråga som innehåller alla produkt-ID:t i en WHERE -sats.

• En källfråga som frågar på en lägre kornighetsnivå, där data senare aggregeras lokalt: När antalet produkter som uppfyller filtervillkoren på Product Manager blir stort kan det bli ineffektivt eller ogenomförbart att inkludera alla produkter i en WHERE sats. I stället kan du fråga relationskällan på den lägre nivån av Produkter och sedan aggregera resultatet lokalt. Om kardinaliteten för Produkter överskrider en gräns på 1 miljon misslyckas frågan.

• Flera källfrågor, en per grupp efter värde: När aggregeringen använder DistinctCount och grupperas efter en kolumn från en annan källa, och om den externa källan inte stöder effektiv överföring av många literalvärden som definierar gruppering, är det nödvändigt att skicka en SQL-fråga per grupp efter värde.

  Ett visuellt objekt som begär ett distinkt antal CustomerAccountNumber från SQL Server-tabellen av produkthanterare som importerats från kalkylbladet måste skicka in informationen från tabellen Product Managers i frågan som skickas till SQL Server. Över andra källor är Redshift till exempel den här åtgärden ogenomförbar. I stället skulle det finnas en SQL-fråga som skickas per Sales Manager, upp till en praktisk gräns, då frågan skulle misslyckas.

Vart och ett av dessa fall har sina egna konsekvenser för prestanda och den exakta informationen varierar för varje datakälla. Även om kardinaliteten för de kolumner som används i relationen som ansluter till de två källorna fortfarande är låg, bör några tusen, prestanda inte påverkas. I takt med att kardinaliteten växer bör du vara mer uppmärksam på hur prestandan påverkas.

Dessutom innebär användningen av många-till-många-relationer att separata frågor måste skickas till den underliggande källan för varje total- eller delsummanivå i stället för att aggregera de detaljerade värdena lokalt. Ett enkelt visuellt tabellobjekt med summor skulle skicka två källfrågor i stället för en.

Källgrupper

En källgrupp är en samling objekt, till exempel tabeller och relationer, från en DirectQuery-källa eller alla importkällor som ingår i en datamodell. En sammansatt modell består av en eller flera källgrupper. Föreställ dig följande exempel:

• En sammansatt modell som ansluter till en Power BI-semantisk modell med namnet Försäljning och berikar den semantiska modellen genom att lägga till ett ytd-mått för försäljning, som inte är tillgängligt i den ursprungliga semantiska modellen. Den här modellen består av en källgrupp.
• En sammansatt modell som kombinerar data genom att importera en tabell från ett Excel-blad med namnet Mål och en CSV-fil med namnet Regioner och göra en DirectQuery-anslutning till en Power BI-semantisk modell med namnet Försäljning. I det här fallet finns det två källgrupper som visas i följande bild:
  • Den första källgruppen innehåller tabellerna från Excel-bladet Mål och CSV-filen Regions .
  • Den andra källgruppen innehåller objekten från Sales Power BI-semantikmodellen.

Om du har lagt till en annan DirectQuery-anslutning till en annan källa, till exempel en DirectQuery-anslutning till en SQL Server-databas med namnet Inventory, läggs objekten från den källan till en annan källgrupp:

Kommentar

Om du importerar data från en annan källa läggs ingen annan källgrupp till eftersom alla objekt från alla importerade källor finns i en källgrupp.

Källgrupper och relationer

Det finns två typer av relationer i en sammansatt modell:

• Relationer mellan källgrupper. Dessa relationer relaterar objekt inom en källgrupp tillsammans. Dessa relationer är alltid vanliga relationer om de inte är många-till-många, i vilket fall de är begränsade.
• Relationer mellan källgrupper. Dessa relationer börjar i en källgrupp och slutar i en annan källgrupp. Dessa relationer är alltid begränsade relationer.

Läs mer om skillnaden mellan regelbundna och begränsade relationer och deras inverkan.

I följande bild har vi till exempel lagt till tre relationer mellan källgrupper som relaterar tabeller mellan de olika källgrupperna:

Lokal och fjärransluten

Alla objekt som finns i en källgrupp som är en DirectQuery-källgrupp betraktas som fjärranslutna, såvida inte objektet har definierats lokalt som en del av ett tillägg eller en berikning till DirectQuery-källan och inte är en del av fjärrkällan, till exempel ett mått eller en beräknad tabell. En beräknad tabell som baseras på en tabell från DirectQuery-källgruppen tillhör källgruppen "Importera" och anses vara lokal. Alla objekt som finns i källgruppen "Importera" anses vara lokala. Om du till exempel definierar följande mått i en sammansatt modell som använder en DirectQuery-anslutning till inventeringskällan anses måttet vara lokalt:

[Average Inventory Count] = Average(Inventory[Inventory Count])

Beräkningsgrupper, frågor och måttutvärdering

Beräkningsgrupper är ett sätt att minska antalet redundanta mått och gruppera gemensamma måttuttryck tillsammans. Vanliga användningsfall är tidsinformationsberäkningar där du vill kunna växla från faktiska värden till hittills i månaden, kvartal till datum eller hittills i år. När du arbetar med sammansatta modeller är det viktigt att vara medveten om interaktionen mellan beräkningsgrupper och om ett mått endast refererar till objekt från en enda fjärrkällagrupp. Om ett mått endast refererar till objekt från en enda fjärrkällagrupp och fjärrmodellen definierar en beräkningsgrupp som påverkar måttet tillämpas den beräkningsgruppen, även om måttet definierades i fjärrmodellen eller i den lokala modellen. Men om ett mått inte enbart refererar till objekt från en enda fjärrkällgrupp, utan refererar till objekt från en fjärrkällgrupp där en fjärrberäkningsgrupp tillämpas, kan resultatet av måttet fortfarande påverkas av fjärrberäkningsgruppen. Ta följande som exempel:

• Reseller Sales är ett mått som definierats i fjärrmodellen.
• Fjärrmodellen innehåller en beräkningsgrupp som ändrar resultatet av Reseller Sales
• Internet Sales är ett mått som definierats i den lokala modellen.
• Total försäljning är ett mått som definierats i den lokala modellen och har följande definition:

[Total Sales] = [Internet Sales] + [Reseller Sales]

I det här scenariot påverkas inte måttet InternetFörsäljning av den beräkningsgrupp som definierats i fjärrmodellen eftersom de inte ingår i samma modell. Beräkningsgruppen kan dock ändra resultatet av måttet Reseller Sales eftersom de finns i samma modell. Det innebär att resultaten som returneras av måttet Total försäljning måste utvärderas noggrant. Anta att vi använder beräkningsgruppen i fjärrmodellen för att returnera resultat hittills i år. Resultatet som returneras av Reseller Sales är nu ett värde hittills i år, medan resultatet som returneras av Internet Sales fortfarande är ett verkligt värde. Resultatet av Total försäljning är nu sannolikt oväntat, eftersom det lägger till ett faktiskt resultat hittills i år.

Sammansatta modeller på Power BI-semantiska modeller och Analysis Services

Med hjälp av sammansatta modeller med Power BI-semantiska modeller och Analysis Services kan du skapa en sammansatt modell med hjälp av en DirectQuery-anslutning för att ansluta till Power BI-semantiska modeller, Azure Analysis Services (AAS) och SQL Server 2022 Analysis Services. Med hjälp av en sammansatt modell kan du kombinera data i dessa källor med andra DirectQuery och importerade data. Rapportförfattare som vill kombinera data från sin företagssemantiska modell med andra data som de äger, till exempel ett Excel-kalkylblad eller vill anpassa eller utöka metadata från företagets semantiska modell, tycker att den här funktionen är särskilt användbar.

Hantera sammansatta modeller på Power BI-semantiska modeller

För att aktivera skapande och förbrukning av sammansatta modeller i Power BI-semantiska modeller måste klientorganisationen ha följande växlar aktiverade:

• Tillåt XMLA-slutpunkter och analysera i Excel med lokala semantiska modeller. Om den här växeln är inaktiverad går det inte att upprätta en DirectQuery-anslutning till en Power BI-semantisk modell.
• Användare kan arbeta med Power BI-semantiska modeller i Excel med hjälp av en live-anslutning. Om den här växeln är inaktiverad kan användarna inte göra liveanslutningar till Power BI-semantiska modeller så att knappen Gör ändringar i den här modellen inte kan nås.
• Tillåt DirectQuery-anslutning till Power BI-semantiska modeller. Mer information om den här växeln och effekten av att inaktivera den finns i följande stycken.

För Premium-kapaciteter och Premium per användare ska dessutom inställningen "XMLA-slutpunkt" aktiveras och anges till antingen "Skrivskyddad" eller "Läs/skriv".

Klientadministratörer kan aktivera eller inaktivera DirectQuery-anslutningar till Power BI-semantiska modeller i administratörsportalen. Även om detta är aktiverat som standard hindrar inaktivering användare från att publicera nya sammansatta modeller på Power BI-semantiska modeller till tjänsten.

Befintliga rapporter som använder en sammansatt modell på en Power BI-semantisk modell fortsätter att fungera och användarna kan fortfarande skapa den sammansatta modellen med desktop men kan inte publicera till tjänsten. När du skapar en DirectQuery-anslutning till Power BI-semantikmodellen genom att välja Gör ändringar i den här modellen visas i stället följande varningsmeddelande:

På så sätt kan du fortfarande utforska den semantiska modellen i din lokala Power BI Desktop-miljö och skapa den sammansatta modellen. Du kan dock inte publicera rapporten till tjänsten. När du publicerar rapporten och modellen visas följande felmeddelande och publikationen blockeras:

Liveanslutningar till Power BI-semantiska modeller påverkas inte av växeln och är inte heller live- eller DirectQuery-anslutningar till Analysis Services. Dessa fortsätter att fungera oavsett om växeln har inaktiverats. Dessutom fortsätter alla publicerade rapporter som använder en sammansatt modell på en Power BI-semantisk modell att fungera även om växeln har inaktiverats efter att de har publicerats.

Skapa en sammansatt modell på en semantisk modell eller modell

Om du skapar en sammansatt modell på en Power BI-semantisk modell eller Analysis Services-modell måste rapporten ha en lokal modell. Du kan börja från en live-anslutning och lägga till eller uppgradera till en lokal modell, eller börja med en DirectQuery-anslutning eller importerade data, som automatiskt skapar en lokal modell i rapporten.

Om du vill se vilka anslutningar som används i din modell kontrollerar du statusfältet i det nedre högra hörnet av Power BI Desktop. Om du bara är ansluten till en Analysis Services-källa visas ett meddelande som liknar följande bild:

Om du är ansluten till en Power BI-semantisk modell visas ett meddelande om vilken Power BI-semantikmodell du är ansluten till:

Om du vill anpassa metadata för fält i din liveanslutna semantiska modell väljer du Gör ändringar i den här modellen i statusfältet. Du kan också välja knappen Gör ändringar i den här modellen i menyfliksområdet, som du ser i följande bild. I rapportvyn gör du ändringar i den här modellknappen på fliken Modellering . I modellvyn finns knappen på fliken Start .

Om du väljer knappen visas en dialogruta som bekräftar tillägg av en lokal modell. Välj Lägg till en lokal modell för att skapa nya kolumner eller ändra metadata för fält från Power BI-semantikmodeller eller Analysis Services. Följande bild visar dialogrutan som visas.

När du är ansluten live till en Analysis Services-källa finns det ingen lokal modell. Om du vill använda DirectQuery för liveanslutna källor, till exempel Power BI-semantiska modeller och Analysis Services, måste du lägga till en lokal modell i rapporten. När du publicerar en rapport med en lokal modell till Power BI-tjänst publiceras en semantisk modell för den lokala modellen en brunn.

Kedjekoppling

Semantiska modeller och semantiska modeller som de baseras på utgör en kedja. Med den här processen, som kallas länkning, kan du publicera en rapport och semantisk modell baserat på andra Power BI-semantiska modeller, en funktion som tidigare inte var möjlig.

Anta till exempel att din kollega publicerar en Power BI-semantisk modell med namnet Försäljning och budget baserat på en Analysis Services-modell med namnet Försäljning och kombinerar den med ett Excel-blad med namnet Budget.

När du publicerar en ny rapport (och semantisk modell) med namnet Sales and Budget Europe baserat på power BI-semantikmodellen för försäljning och budget som publicerats av din kollega och gör ytterligare ändringar eller tillägg när du gör det, lägger du effektivt till en rapport och semantisk modell i en kedja med längd tre, som började med Sales Analysis Services-modellen. och slutar med din Sales and Budget Europe Power BI-semantisk modell. Följande bild visualiserar den här länkningsprocessen.

Kedjan i föregående bild är av längd tre, vilket är den maximala längden. Det går inte att utöka längre än en kedjelängd på tre och resulterar i fel.

Behörigheter och licensiering

Användare som kommer åt rapporter med en sammansatt modell måste ha rätt behörighet till alla semantiska modeller och modeller i kedjan.

Ägaren till den sammansatta modellen kräver build-behörighet för de semantiska modeller som används som källor så att andra användare kan komma åt dessa modeller för ägarens räkning. Därför kräver skapandet av den sammansatta modellanslutningen i Power BI Desktop eller redigering av rapporten i Power BI build-behörigheter för de semantiska modeller som används som källor.

Användare som visar rapporter med hjälp av den sammansatta modellen kräver vanligtvis läsbehörigheter för själva den sammansatta modellen och de semantiska modeller som används som källor. Byggbehörigheter kan krävas om rapporterna finns på en Pro-arbetsyta. Dessa klientväxlar ska vara aktiverade för användaren.

De behörigheter som krävs kan illustreras med följande exempel:

• Sammansatt modell A (ägs av ägare A)

  • Datakälla A1: Semantisk modell B.
    Ägare A måste ha behörigheten Skapa på semantisk modell B för att användarna ska kunna visa rapporten med hjälp av sammansatt modell A.

• Sammansatt modell C (ägs av ägare C)

  • Datakälla C1: Semantisk modell D
    Ägare C måste ha behörighet att skapa semantisk modell D för att användarna ska kunna visa rapporten med hjälp av sammansatt modell C.
  • Datakälla C2: Sammansatt modell A
    Ägare C måste ha behörigheten Skapa för sammansatt modell A och Läs på semantisk modell B.

En användare som visar rapporter med sammansatt modell A måste ha läsbehörighet till både sammansatt modell A och semantisk modell B, medan en användare som visar rapporter med sammansatt modell C måste ha läsbehörighet för sammansatt modell C, semantisk modell D, sammansatt modell A och semantisk modell B.

Kommentar

I det här blogginlägget finns viktig information om behörigheter som krävs för sammansatta modeller i Power BI-semantiska modeller och Analysis Services-modeller.

Om någon datauppsättning i kedjan finns i en Premium per användare-arbetsyta behöver användaren som kommer åt den en Premium-licens per användare. Om någon datauppsättning i kedjan finns på en Pro-arbetsyta behöver användaren som kommer åt den en Pro-licens. Om alla datauppsättningar i kedjan finns på Premium-kapaciteter eller Infrastruktur F64 eller större kapacitet kan en användare komma åt den med en kostnadsfri licens.

Säkerhetsvarning

Med funktionen Sammansatta modeller i Power BI-semantikmodeller och Analysis Services-modeller visas en dialogruta för säkerhetsvarningar som visas i följande bild.

Data kan skickas från en datakälla till en annan, vilket är samma säkerhetsvarning för att kombinera DirectQuery och importera källor i en datamodell. Mer information om det här beteendet finns i använda sammansatta modeller i Power BI Desktop.

Stödda scenarier

Du kan skapa sammansatta modeller med hjälp av data från Power BI-semantiska modeller eller Analysis Services-modeller för att betjäna följande scenarier:

• Ansluta till data från olika källor: Importera (till exempel filer), Power BI-semantiska modeller, Analysis Services-modeller
• Skapa relationer mellan olika datakällor
• Skriva mått som använder fält från olika datakällor
• Skapa nya kolumner för tabeller från Power BI-semantiska modeller eller Analysis Services-modeller
• Skapa visuella objekt som använder kolumner från olika datakällor
• Du kan ta bort en tabell från din modell med hjälp av fältlistan för att hålla modellerna så koncisa och magra som möjligt (om du ansluter till ett perspektiv kan du inte ta bort tabeller från modellen)
• Du kan ange vilka tabeller som ska läsas in i stället för att behöva läsa in alla tabeller när du bara vill ha en specifik delmängd av tabellerna. Se Läsa in en delmängd av tabeller senare i det här dokumentet.
• Du kan ange om du vill lägga till tabeller som senare läggs till i den semantiska modellen när du har skapat anslutningen i din modell.

Arbeta med en sammansatt modell baserat på en semantisk modell

När du arbetar med DirectQuery för Power BI-semantiska modeller och Analysis Services bör du tänka på följande information:

• Om du uppdaterar dina datakällor och det finns fel med fält- eller tabellnamn som står i konflikt löser Power BI felen åt dig.

• Du kan inte redigera, ta bort eller skapa nya relationer i samma Power BI-semantikmodell eller Analysis Services-källa. Om du har redigeringsåtkomst till dessa källor kan du göra ändringarna direkt i datakällan i stället.

• Du kan inte ändra datatyper för kolumner som läses in från en Power BI-semantisk modell eller Analysis Services-källa. Om du behöver ändra datatypen ändrar du den i källan eller använder en beräknad kolumn.

• Om du vill skapa rapporter i Power BI-tjänst på en sammansatt modell baserat på en annan semantisk modell måste alla autentiseringsuppgifter anges.

• Anslutningar till en LOKAL SQL Server 2022- och senare Analysis Services-server eller IAAS kräver en lokal datagateway (standardläge).

• Alla anslutningar till fjärranslutna Power BI-semantiska modeller görs med enkel inloggning. Autentisering med tjänstens huvudnamn stöds inte för närvarande.

• RLS-regler tillämpas på källan där de definieras, men tillämpas inte på andra semantiska modeller i modellen. RLS som definieras i rapporten tillämpas inte på fjärrkällor och RLS som anges på fjärrkällor tillämpas inte på andra datakällor. Du kan inte heller definiera RLS i en tabell som lästs in från en fjärrkälla, och RLS som definierats i lokala tabeller filtrerar inte några tabeller som lästs in från en fjärrkälla.

• KPI:er, säkerhet på radnivå och översättningar importeras inte från källan.

• Du kan se ett oväntat beteende när du använder en datumhierarki. Lös problemet genom att använda en datumkolumn i stället. När du har lagt till en datumhierarki i ett visuellt objekt kan du växla till en datumkolumn genom att klicka på nedåtpilen i fältnamnet och sedan klicka på namnet på fältet i stället för att använda Datumhierarki:

  

  Mer information om hur du använder datumkolumner jämfört med datumhierarkier finns i Tillämpa automatiskt datum eller tid i Power BI Desktop.

• Den maximala längden på en modellkedja är tre. Det går inte att utöka utöver kedjelängden på tre och resulterar i fel.

• En flagga för avrådande länkning kan ställas in på en modell för att förhindra att en kedja skapas eller utökas. Mer information finns i Hantera DirectQuery-anslutningar till en publicerad semantisk modell.

• Anslutningen till en Power BI-semantisk modell eller Analysis Services-modell visas inte i Power Query.

Följande begränsningar gäller när du arbetar med DirectQuery för Power BI-semantiska modeller och Analysis Services:

• Parametrar för databas- och servernamn är för närvarande inaktiverade.
• Det går inte att definiera RLS för tabeller från en fjärrkälla.
• Det går inte att använda någon av följande källor som DirectQuery-källa:
  • SQL Server Analysis Services-tabellmodeller (SSAS) före version 2022
  • Flerdimensionella SSAS-modeller
  • SAP HANA
  • SAP Business Warehouse
  • Semantiska realtidsmodeller
  • Exempel på semantiska modeller
  • Excel Online-uppdatering
  • Data som importeras från Excel- eller CSV-filer på tjänsten
  • Användningsstatistik
  • Semantiska modeller som lagras i "Min arbetsyta"
• Användning av Power BI Embedded med semantiska modeller som innehåller en DirectQuery-anslutning till en Analysis Services-modell stöds inte för närvarande.
• Det går inte att publicera en rapport på webben med funktionen publicera på webben.
• Beräkningsgrupper på fjärrkällor stöds inte, med odefinierade frågeresultat.

• Beräknade tabeller och beräknade kolumner som refererar till en DirectQuery-tabell från en datakälla med enkel inloggningsautentisering (SSO) stöds i Power BI-tjänst med en tilldelad delningsbar molnanslutning och/eller detaljerad åtkomstkontroll.

• Om du byter namn på en arbetsyta efter att DirectQuery-anslutningen har konfigurerats måste du uppdatera datakällan i Power BI Desktop för att rapporten ska fortsätta fungera.
• Automatisk siduppdatering (APR) stöds endast för vissa scenarier, beroende på datakällans typ. Mer information finns i Automatisk siduppdatering i Power BI.
• Ta över en semantisk modell som använder DirectQuery till andra semantiska modeller stöds inte för närvarande.
• Precis som med alla DirectQuery-datakällor visas inte hierarkier som definierats i en Analysis Services-modell eller Power BI-semantisk modell när du ansluter till modellen eller semantikmodellen i DirectQuery-läge med Excel.

Det finns några andra saker att tänka på när du arbetar med DirectQuery för Power BI-semantiska modeller och Analysis Services:

• Använd kolumner med låg kardinalitet i relationer mellan källgrupper: När du skapar en relation mellan två olika källgrupper bör kolumnerna som deltar i relationen (kallas även kopplingskolumner) ha låg kardinalitet, helst 50 000 eller mindre. Detta gäller för icke-strängande nyckelkolumner. Se följande överväganden för strängnyckelkolumner.
• Undvik att använda stora strängnyckelkolumner i relationer mellan källgrupper: När du skapar en korskällgruppsrelation bör du undvika att använda stora strängkolumner som relationskolumner, särskilt för kolumner som har större kardinalitet. När du måste använda strängkolumner som relationskolumn beräknar du den förväntade stränglängden för filtret genom att multiplicera kardinaliteten (C) med den genomsnittliga längden på strängkolumnen (A). Kontrollera att den förväntade stränglängden är under 250 000, så att A ∗ C < 250 000.

Mer information och vägledning finns i vägledningen för sammansatta modeller.

Klientorganisationsöverväganden

Alla modeller med en DirectQuery-anslutning till en Power BI-semantisk modell eller till Analysis Services måste publiceras i samma klientorganisation, vilket är särskilt viktigt när du kommer åt en Power BI-semantisk modell eller en Analysis Services-modell med hjälp av B2B-gästidentiteter, enligt beskrivningen i följande diagram. Se Gästanvändare som kan redigera och hantera innehåll för att hitta klientorganisations-URL:en för publicering.

Tänk på följande diagram. De numrerade stegen i diagrammet beskrivs i stycken som följer.

I diagrammet arbetar Ash med Contoso och kommer åt data som tillhandahålls av Fabrikam. Med Power BI Desktop skapar Ash en DirectQuery-anslutning till en Analysis Services-modell som finns i Fabrikams klientorganisation.

För att autentisera använder Ash en B2B-gästanvändares identitet (steg 1 i diagrammet).

Om rapporten publiceras till Contosos Power BI-tjänst (steg 2) kan den semantiska modellen som publicerats i Contoso-klientorganisationen inte autentiseras mot Fabrikams Analysis Services-modell (steg 3). Därför fungerar inte rapporten.

I det här scenariot, eftersom Analysis Services-modellen som används finns i Fabrikams klientorganisation, måste rapporten också publiceras i Fabrikams klientorganisation. Efter en lyckad publicering i Fabrikams klientorganisation (steg 4) kan den semantiska modellen komma åt Analysis Services-modellen (steg 5) och rapporten fungerar korrekt.

Arbeta med säkerhet på objektnivå

När en sammansatt modell hämtar data från en Power BI-semantisk modell eller Analysis Services via DirectQuery, och den källmodellen skyddas av säkerhet på objektnivå, kan konsumenter av den sammansatta modellen märka oväntade resultat. I följande avsnitt beskrivs hur dessa resultat kan uppstå.

Med säkerhet på objektnivå (OLS) kan modellförfattare dölja objekt som utgör modellschemat (dvs. tabeller, kolumner, metadata osv.) från modellkonsumenter (till exempel en rapportbyggare eller en sammansatt modellförfattare). När du konfigurerar OLS för ett objekt skapar modellförfattaren en roll och tar sedan bort åtkomsten till objektet för användare som har tilldelats till den rollen. Från dessa användares synvinkel finns det dolda objektet helt enkelt inte.

OLS definieras för och tillämpas på källmodellen. Det kan inte definieras för en sammansatt modell som bygger på källmodellen.

När en sammansatt modell bygger på en OLS-skyddad Power BI-semantisk modell eller Analysis Services-modell via DirectQuery-anslutning kopieras modellschemat från källmodellen till den sammansatta modellen. Vad som kopieras beror på vad den sammansatta modellförfattaren tillåts se i källmodellen enligt DE OLS-regler som gäller där. Data kopieras inte över till den sammansatta modellen – i stället hämtas de alltid via DirectQuery från källmodellen när det behövs. Med andra ord återgår datahämtningen alltid till källmodellen, där OLS-reglerna gäller.

Eftersom den sammansatta modellen inte skyddas av OLS-regler är de objekt som konsumenter av den sammansatta modellen ser de som den sammansatta modellförfattaren kan se i källmodellen i stället för vad de själva kan ha åtkomst till. Detta kan resultera i följande situationer:

• Någon som tittar på den sammansatta modellen kan se objekt som är dolda från dem i källmodellen av OLS.
• Däremot kanske de INTE ser ett objekt i den sammansatta modellen som de kan se i källmodellen, eftersom objektet var dolt från den sammansatta modellförfattaren av OLS-reglerna som styr åtkomsten till källmodellen.

En viktig punkt är att trots det fall som beskrivs i den första punkten ser konsumenter av den sammansatta modellen aldrig faktiska data som de inte ska se, eftersom data inte finns i den sammansatta modellen. På grund av DirectQuery hämtas den i stället efter behov från källsemantikmodellen, där OLS blockerar obehörig åtkomst.

Med den här bakgrunden i åtanke bör du tänka på följande scenario:

1. Admin_user publicerat en företagssemantisk modell med hjälp av en Power BI-semantisk modell eller en Analysis Services-modell som har en kundtabell och en områdestabell. Admin_user publicerar semantikmodellen till Power BI-tjänst och anger OLS-regler som har följande effekt:

   • Ekonomianvändare kan inte se tabellen Kund
   • Marknadsföringsanvändare kan inte se tabellen Område

2. Finance_user publicerar en semantisk modell med namnet "Finance semantic model" och en rapport med namnet "Finance report" som ansluter via DirectQuery till företagssemantikmodellen som publicerades i steg 1. Ekonomirapporten innehåller ett visuellt objekt som använder en kolumn från tabellen Område.

3. Marketing_user öppnar finansrapporten. Det visuella objekt som använder tabellen Område visas, men returnerar ett fel, eftersom DirectQuery när rapporten öppnas försöker hämta data från källmodellen med hjälp av autentiseringsuppgifterna för Marketing_user, som blockeras från att se tabellen Område enligt OLS-reglerna som angetts för företagets semantiska modell.

4. Marketing_user skapar en ny rapport med namnet "Marknadsföringsrapport" som använder finance-semantikmodellen som källa. Fältlistan visar de tabeller och kolumner som Finance_user har åtkomst till. Tabellen Område visas därför i fältlistan, men det är inte kundtabellen. Men när Marketing_user försöker skapa ett visuellt objekt som använder en kolumn från tabellen Område returneras ett fel, eftersom DirectQuery vid den tidpunkten försöker hämta data från källmodellen med hjälp av Marketing_user autentiseringsuppgifter, och OLS-reglerna startar igen och blockerar åtkomst. Samma sak händer när Marketing_user skapar en ny semantisk modell och rapport som ansluter till finance-semantikmodellen med en DirectQuery-anslutning – de ser tabellen Område i fältlistan, eftersom det är vad Finance_user kan se, men när de försöker skapa ett visuellt objekt som använder tabellen blockeras de av OLS-reglerna för företagets semantiska modell.

5. Anta nu att Admin_user uppdaterar OLS-reglerna för företagets semantiska modell för att hindra Finance från att se tabellen Område.

6. De uppdaterade OLS-reglerna återspeglas bara i finance-semantikmodellen när den uppdateras. När Finance_user uppdaterar finance-semantikmodellen visas tabellen Område inte längre i fältlistan, och det visuella objektet i finansrapporten som använder en kolumn från tabellen Område returnerar därför ett fel för Finance_user eftersom de nu inte har behörighet att komma åt tabellen Område.

Sammanfattningsvis:

• Konsumenter av en sammansatt modell ser resultatet av OLS-reglerna som var tillämpliga för författaren till den sammansatta modellen när de skapade modellen. När en ny rapport skapas baserat på den sammansatta modellen visar fältlistan därför tabellerna som författaren till den sammansatta modellen hade åtkomst till när de skapade modellen, oavsett vad den aktuella användaren har åtkomst till i källmodellen.
• OLS-regler kan inte definieras på själva den sammansatta modellen.
• En konsument av en sammansatt modell ser aldrig faktiska data som de inte ska se, eftersom relevanta OLS-regler för källmodellen blockerar dem när DirectQuery försöker hämta data med sina autentiseringsuppgifter.
• Om källmodellen uppdaterar sina OLS-regler påverkar dessa ändringar bara den sammansatta modellen när den uppdateras.

Läsa in en delmängd av tabeller från en Power BI-semantisk modell eller Analysis Services-modell

När du ansluter till en Power BI-semantisk modell eller Analysis Services-modell med hjälp av en DirectQuery-anslutning kan du bestämma vilka tabeller du ska ansluta till. Du kan också välja att automatiskt lägga till en tabell som kan läggas till i den semantiska modellen eller modellen när du har skapat anslutningen till din modell. När du ansluter till ett perspektiv innehåller din modell alla tabeller i den semantiska modellen och alla tabeller som inte ingår i perspektivet är dolda. Dessutom läggs alla tabeller som kan läggas till i perspektivet automatiskt. På menyn Inställningar kan du välja att automatiskt ansluta till tabeller som läggs till i semantikmodellen när du har konfigurerat anslutningen.

Den här dialogrutan visas inte för liveanslutningar.

Kommentar

Den här dialogrutan visas bara om du lägger till en DirectQuery-anslutning till en Power BI-semantisk modell eller Analysis Services-modell till en befintlig modell. Du kan också öppna den här dialogrutan genom att ändra DirectQuery-anslutningen till Power BI-semantikmodellen eller Analysis Services-modellen i inställningarna för datakällan när du har skapat den.

Konfigurera dedupliceringsregler

Du kan ange dedupliceringsregler för att hålla mått- och tabellnamn unika i en sammansatt modell med hjälp av alternativet Inställningar i dialogrutan som visades tidigare:

I föregående exempel lade vi till " (marknadsföring)" som ett suffix i en tabell eller ett måttnamn som står i konflikt med en annan källa i den sammansatta modellen. Du kan:

• ange en text som ska läggas till i namnet på tabeller eller mått som är i konflikt
• ange om du vill att texten ska läggas till i tabellen eller måttnamnet som ett prefix eller ett suffix
• tillämpa dedupliceringsregeln på tabeller, mått eller båda
• Välj att endast tillämpa dedupliceringsregeln när en namnkonflikt inträffar eller tillämpa den hela tiden. Standardvärdet är att endast tillämpa regeln när dubblering sker. I vårt exempel får inte någon tabell eller ett mått från marknadsföringskällan som inte har en dubblett i försäljningskällan någon namnändring.

När du har upprättat anslutningarna och konfigurerat dedupliceringsregeln visar fältlistan både "Kund" och "Kund (marknadsföring)" enligt dedupliceringsregeln som konfigurerats i vårt exempel:

Om du inte anger någon dedupliceringsregel, eller om dedupliceringsregler som du angav inte löser namnkonflikten, tillämpas standardreglerna för deduplicering fortfarande. Standardregler för deduplicering lägger till ett tal i namnet på det objekt som är i konflikt. Om det finns en namnkonflikt i tabellen Kund byter en av tabellerna "Kund" namnet "Kund 2".

XMLA-ändringar och sammansatta modeller

När du ändrar en semantisk modell med HJÄLP av XMLA måste du uppdatera samlingen ChangedProperties och PBI_RemovedChildren för det ändrade objektet så att de innehåller eventuella ändrade eller borttagna egenskaper. Om du inte utför uppdateringen kan Power BI-modelleringsverktyg skriva över eventuella ändringar nästa gång schemat synkroniseras med dess associerade Lakehouse.

De modeller som stöds för att ändra en semantisk modell med XMLA är följande:

• Namnbyte för tabell/kolumn (ChangeProperty = namn)
• Ta bort tabell (lägg till tabell i PBI_RemovedChildren kommentar i frågeuttrycket)

Beaktanden och begränsningar

Sammansatta modeller har några överväganden och begränsningar:

Anslutningar i blandat läge – När du använder en anslutning i blandat läge som innehåller onlinedata (till exempel en Power BI-semantisk modell) och en lokal semantisk modell (till exempel en Excel-arbetsbok), måste du ha gatewaymappning upprättad för att visuella objekt ska visas korrekt.

För närvarande stöds inkrementell uppdatering endast för sammansatta modeller som ansluter till SQL-, Oracle- och Teradata-datakällor.

Följande Live Connect-tabellkällor kan inte användas med sammansatta modeller:

• SAP HANA
• SAP Business Warehouse
• SQL Server Analysis Services tidigare än version 2022
• Användningsstatistik (Min arbetsyta)

Det går inte att använda strömmande semantiska modeller i sammansatta modeller.

De befintliga begränsningarna för DirectQuery gäller fortfarande när du använder sammansatta modeller. Många av dessa begränsningar är nu per tabell, beroende på tabellens lagringsläge. En beräknad kolumn i en importtabell kan till exempel referera till andra tabeller som inte finns i DirectQuery, men en beräknad kolumn i en DirectQuery-tabell kan fortfarande bara referera till kolumner i samma tabell. Andra begränsningar gäller för modellen som helhet, om någon av tabellerna i modellen är DirectQuery. Funktionen QuickInsights är till exempel inte tillgänglig i en modell om någon av tabellerna i den har ett lagringsläge med DirectQuery.

Om du använder säkerhet på radnivå i en sammansatt modell med några av tabellerna i DirectQuery-läge måste du uppdatera modellen för att tillämpa nya uppdateringar från DirectQuery-tabellerna. Om till exempel en användare-tabell i DirectQuery-läge har nya användarposter vid källan inkluderas de nya posterna först efter nästa modelluppdatering. Power BI-tjänsten cachelagrar frågan Användare för att förbättra prestanda och läser inte in data från källan igen förrän nästa manuella eller schemalagda uppdatering.

Relaterat innehåll

Mer information om sammansatta modeller och DirectQuery finns i följande artiklar:

• Tillämpa många-till-många-relationer i Power BI Desktop
• Hantera lagringsläge i Power BI Desktop
• DirectQuery i Power BI
• Power BI-datakällor
• Modellrelationer i Power BI Desktop