Bruge sammensatte modeller i Power BI Desktop

Tidligere i Power BI Desktop, da du brugte en DirectQuery i en rapport, var ingen andre dataforbindelser, hverken DirectQuery eller import, tilladt for den pågældende rapport. Med sammensatte modeller fjernes denne begrænsning. En rapport kan uden problemer indeholde dataforbindelser fra mere end én DirectQuery eller importere dataforbindelse i en hvilken som helst kombination, du vælger.

Funktionen sammensatte modeller i Power BI Desktop består af tre relaterede funktioner:

• Sammensatte modeller: Gør det muligt for en rapport at have to eller flere dataforbindelser fra forskellige kildegrupper. Disse kildegrupper kan være en eller flere DirectQuery-forbindelser og en importforbindelse, to eller flere DirectQuery-forbindelser eller en hvilken som helst kombination heraf. I denne artikel beskrives sammensatte modeller i detaljer.

• Mange til mange-relationer: Med sammensatte modeller kan du oprette mange til mange-relationer mellem tabeller. Denne fremgangsmåde fjerner kravene til entydige værdier i tabeller. Det fjerner også tidligere midlertidige løsninger, såsom introduktion af nye tabeller kun for at etablere relationer. Du kan finde flere oplysninger under Anvend mange til mange-relationer i Power BI Desktop.

• Lagringstilstand: Du kan nu angive, hvilke visualiseringer der forespørger back end-datakilder. Denne funktion hjælper med at forbedre ydeevnen og reducere back end-belastningen. Tidligere startede selv simple visualiseringer, f.eks. udsnit, forespørgsler til back end-kilder. Du kan få flere oplysninger under Administrer lagringstilstand i Power BI Desktop.

Brug sammensatte modeller

Med sammensatte modeller kan du oprette forbindelse til forskellige typer datakilder, når du bruger Power BI Desktop eller Power BI-tjeneste. Du kan oprette disse dataforbindelser på flere måder:

• Ved at importere data til Power BI, som er den mest almindelige måde at hente data på.
• Ved at oprette direkte forbindelse til data i det oprindelige kildelager ved hjælp af DirectQuery. Du kan få mere at vide om DirectQuery under DirectQuery i Power BI.

Når du bruger DirectQuery, gør sammensatte modeller det muligt at oprette en Power BI-model, f.eks. en enkelt .pbix Power BI Desktop-fil, der udfører en eller begge af følgende handlinger:

• Kombinerer data fra en eller flere DirectQuery-kilder.
• Kombinerer data fra DirectQuery-kilder og importerer data.

Ved hjælp af sammensatte modeller kan du f.eks. oprette en model, der kombinerer følgende datatyper:

• Salgsdata fra et virksomhedsdata warehouse.
• Salgsmåldata fra en afdelings SQL Server-database.
• Data, der er importeret fra et regneark.

En model, der kombinerer data fra mere end én DirectQuery-kilde, eller som kombinerer DirectQuery med importdata, kaldes en sammensat model.

Du kan oprette relationer mellem tabeller, som du altid har gjort, selvom disse tabeller kommer fra forskellige kilder. Alle relationer, der er på tværs af kilder, oprettes med en kardinalitet på mange til mange, uanset deres faktiske kardinalitet. Du kan ændre dem til en til mange, mange til en eller en til en. Uanset hvilken kardinalitet du angiver, har relationer på tværs af kilder forskellige funktionsmåder. Du kan ikke bruge DAX-funktioner (Data Analysis Expressions) til at hente værdier på one siden fra many siden. Du kan også se en indvirkning på ydeevnen i forhold til mange til mange-relationer i den samme kilde.

Bemærk

I forbindelse med sammensatte modeller er alle importerede tabeller reelt en enkelt kilde, uanset de faktiske underliggende datakilder.

Eksempel på en sammensat model

For et eksempel på en sammensat model skal du overveje en rapport, der har oprettet forbindelse til et firmadata warehouse i SQL Server ved hjælp af DirectQuery. I dette tilfælde indeholder data warehouse'et Sales by Country, Quarter og Bike (Product) som vist på følgende billede:

På dette tidspunkt kan du oprette simple visualiseringer ved hjælp af felter fra denne kilde. På følgende billede vises det samlede salg efter ProductName for et valgt kvartal.

Men hvad nu, hvis du har data i et Excel-regneark om produktchefen, der er tildelt til hvert produkt, sammen med marketingprioriteten? Hvis du vil have vist Salgsbeløb efter Produktchef, er det muligvis ikke muligt at føje disse lokale data til virksomhedens data warehouse. Eller det kan tage måneder i bedste fald.

Det kan være muligt at importere disse salgsdata fra data warehouse'et i stedet for at bruge DirectQuery. Og salgsdataene kan derefter kombineres med de data, du har importeret fra regnearket. Denne fremgangsmåde er dog urimelig af de grunde, der i første omgang førte til brugen af DirectQuery. Årsagerne kan omfatte:

• En kombination af de sikkerhedsregler, der gennemtvinges i den underliggende kilde.
• Behovet for at kunne få vist de nyeste data.
• Den store skala af dataene.

Her kommer sammensatte modeller ind i det. Sammensatte modeller giver dig mulighed for at oprette forbindelse til data warehouse'et ved hjælp af DirectQuery og derefter bruge Hent data til flere kilder. I dette eksempel opretter vi først DirectQuery-forbindelsen til virksomhedens data warehouse. Vi bruger Hent data, vælger Excel og navigerer derefter til det regneark, der indeholder vores lokale data. Endelig importerer vi det regneark, der indeholder produktnavnene, den tildelte salgschef og prioriteten.

På listen Felter kan du se to tabeller: den oprindelige cykeltabel fra SQL Server og en ny ProductManagers-tabel. Den nye tabel indeholder de data, der er importeret fra Excel.

På samme måde kan vi i relationsvisningen i Power BI Desktop nu se en anden tabel med navnet ProductManagers.

Vi skal nu relatere disse tabeller til de andre tabeller i modellen. Som altid opretter vi en relation mellem tabellen Bike fra SQL Server og den importerede ProductManagers-tabel . Det vil altså være relationen mellem Bike[ProductName] og ProductManagers[ProductName]. Som beskrevet tidligere er alle relationer, der går på tværs af kilden, som standard mange til mange-kardinalitet.

Nu, hvor vi har oprettet denne relation, vises den i relationsvisningen i Power BI Desktop, som vi ville forvente.

Vi kan nu oprette visualiseringer ved hjælp af et af felterne på listen Felter . Denne fremgangsmåde blander problemfrit data fra flere kilder. Det samlede SalesAmount for hver Produktchef vises f.eks. på følgende billede:

I følgende eksempel vises et almindeligt tilfælde af en dimensionstabel , f.eks . Product eller Customer, der er udvidet med nogle ekstra data, der er importeret et andet sted fra. Det er også muligt at få tabeller til at bruge DirectQuery til at oprette forbindelse til forskellige kilder. For at fortsætte med vores eksempel kan du forestille dig, at salgsmål pr. land og periode er gemt i en separat afdelingsdatabase. Som sædvanlig kan du bruge Hent data til at oprette forbindelse til disse data, som vist på følgende billede:

Som vi gjorde tidligere, kan vi oprette relationer mellem den nye tabel og andre tabeller i modellen. Derefter kan vi oprette visualiseringer, der kombinerer tabeldataene. Lad os se på visningen Relationer igen, hvor vi har oprettet de nye relationer:

Det næste billede er baseret på de nye data og relationer, vi har oprettet. Visualiseringen nederst til venstre viser det samlede salgsbeløb i forhold til Mål, og variansberegningen viser forskellen. Dataene Sales Amount og Target stammer fra to forskellige SQL Server-databaser.

Angiv lagringstilstanden

Hver tabel i en sammensat model har en lagringstilstand, der angiver, om tabellen er baseret på DirectQuery eller import. Lagringstilstanden kan vises og ændres i ruden Egenskab . Hvis du vil have vist lagringstilstanden, skal du højreklikke på en tabel på listen Felter og derefter vælge Egenskaber. På følgende billede vises lagringstilstanden for tabellen SalesTargets .

Lagringstilstanden kan også vises i værktøjstippet for hver tabel.

For alle Power BI Desktop-filer (en .pbix-fil ), der indeholder nogle tabeller fra DirectQuery og nogle importtabeller, viser statuslinjen en lagringstilstand med navnet Blandet. Du kan vælge dette ord på statuslinjen og nemt skifte alle tabeller til import.

Du kan få flere oplysninger om lagringstilstand under Administrer lagringstilstand i Power BI Desktop.

Bemærk

Du kan bruge blandet lagringstilstand i Power BI Desktop og i Power BI-tjeneste.

Beregnede tabeller

Du kan føje beregnede tabeller til en model i Power BI Desktop, der bruger DirectQuery. DAX (Data Analysis Expressions), der definerer den beregnede tabel, kan referere til enten importerede eller DirectQuery-tabeller eller en kombination af de to.

Beregnede tabeller importeres altid, og deres data opdateres, når du opdaterer tabellerne. Hvis en beregnet tabel refererer til en DirectQuery-tabel, viser visualiseringer, der refererer til DirectQuery-tabellen, altid de nyeste værdier i den underliggende kilde. Alternativt kan visualiseringer, der refererer til den beregnede tabel, vise værdierne på det tidspunkt, hvor den beregnede tabel sidst blev opdateret.

Vigtigt

Beregnede tabeller understøttes ikke i Power BI-tjeneste ved hjælp af denne funktion. Se afsnittet Arbejd med en sammensat model baseret på en semantisk model i denne artikel for at få flere oplysninger.

Sikkerhedsmæssige konsekvenser

Sammensatte modeller har nogle sikkerhedsmæssige konsekvenser. En forespørgsel, der sendes til én datakilde, kan indeholde dataværdier, der er hentet fra en anden kilde. I det tidligere eksempel sender den visualisering, der viser (Salgsbeløb) efter Product Manager , en SQL-forespørgsel til relationsdatabasen Salg. Denne SQL-forespørgsel kan indeholde navnene på produktchefer og deres tilknyttede produkter.

Så de oplysninger, der er gemt i regnearket, er nu inkluderet i en forespørgsel, der sendes til relationsdatabasen. Hvis disse oplysninger er fortrolige, bør du overveje de sikkerhedsmæssige konsekvenser. Overvej især følgende punkter:

• Alle administratorer af databasen, der kan få vist sporinger eller overvågningslogge, kan få vist disse oplysninger, selv uden tilladelser til dataene i den oprindelige kilde. I dette eksempel skal administratoren have tilladelser til Excel-filen.

• Krypteringsindstillingerne for hver kilde skal tages i betragtning. Du vil undgå at hente oplysninger fra én kilde via en krypteret forbindelse og derefter utilsigtet inkludere dem i en forespørgsel, der sendes til en anden kilde af en ukrypteret forbindelse.

Power BI Desktop viser en advarsel, når du opretter en sammensat model, for at bekræfte, at du har overvejet eventuelle sikkerhedsmæssige konsekvenser.

Hvis en forfatter føjer Table1 fra Model A til en sammensat model (lad os kalde den Model C som reference), kan en bruger, der får vist en rapport, der er baseret på Model C, desuden forespørge en hvilken som helst tabel i Model A, der ikke er beskyttet af sikkerhed på rækkeniveau.

Af lignende årsager skal du være forsigtig, når du åbner en Power BI Desktop-fil, der sendes fra en kilde, der ikke er tillid til. Hvis filen indeholder sammensatte modeller, sendes oplysninger, som en person henter fra én kilde, ved hjælp af legitimationsoplysningerne for den bruger, der åbner filen, til en anden datakilde som en del af forespørgslen. Oplysningerne kan ses af den ondsindede forfatter af Power BI Desktop-filen. Når du åbner en Power BI Desktop-fil, der indeholder flere kilder, viser Power BI Desktop en advarsel. Advarslen svarer til den, der vises, når du åbner en fil, der indeholder oprindelige SQL-forespørgsler.

Konsekvenser for ydeevnen

Når du bruger DirectQuery, skal du altid overveje ydeevnen, primært for at sikre, at back end-kilden har tilstrækkelige ressourcer til at give brugerne en god oplevelse. En god oplevelse betyder, at visualiseringerne opdateres på fem sekunder eller mindre. Du kan finde flere råd om ydeevnen i DirectQuery i Power BI.

Brug af sammensatte modeller tilføjer andre overvejelser i forbindelse med ydeevnen. En enkelt visualisering kan resultere i, at der sendes forespørgsler til flere kilder, som ofte overfører resultaterne fra én forespørgsel til en anden kilde. Denne situation kan resultere i følgende former for udførelse:

• En kildeforespørgsel, der indeholder et stort antal konstantværdier: En visualisering, der anmoder om det samlede salgsbeløb for et sæt valgte produktchefer, skal f.eks. først finde ud af, hvilke produkter der blev administreret af disse produktchefer. Denne sekvens skal ske, før visualiseringen sender en SQL-forespørgsel, der indeholder alle produkt-id'erne i en WHERE delsætning.

• En kildeforespørgsel, der forespørger på et lavere granularitetsniveau, hvor dataene senere aggregeres lokalt: Da antallet af produkter , der opfylder filterkriterierne i Product Manager , bliver stort, kan det blive ineffektivt eller umuligt at inkludere alle produkter i en WHERE delsætning. Du kan i stedet forespørge relationskilden på det lavere niveau af Produkter og derefter samle resultaterne lokalt. Hvis kardinaliteten for Produkter overskrider en grænse på 1 million, mislykkes forespørgslen.

• Flere kildeforespørgsler, én pr. gruppe efter værdi: Når sammenlægningen bruger DistinctCount og er grupperet efter en kolonne fra en anden kilde, og hvis den eksterne kilde ikke understøtter effektiv overførsel af mange konstantværdier, der definerer gruppering, er det nødvendigt at sende én SQL-forespørgsel pr. gruppe efter værdi.

  En visualisering, der anmoder om et specifikt antal CustomerAccountNumber fra SQL Server-tabellen af produktchefer , der er importeret fra regnearket, skal overføre oplysningerne fra tabellen Product Managers i den forespørgsel, der sendes til SQL Server. I forhold til andre kilder, f.eks. Redshift, er denne handling ikke mulig. I stedet sendes der én SQL-forespørgsel pr. salgschef op til en praktisk grænse, hvorefter forespørgslen mislykkes.

Hver af disse sager har sine egne konsekvenser for ydeevnen, og de nøjagtige oplysninger varierer for hver datakilde. Selvom kardinaliteten for de kolonner, der bruges i den relation, der joinforbinder de to kilder, stadig er lav, bør ydeevnen ikke påvirkes. I takt med at denne kardinalitet vokser, skal du være mere opmærksom på indvirkningen på den resulterende ydeevne.

Desuden betyder brugen af mange til mange-relationer, at der skal sendes separate forespørgsler til den underliggende kilde for hvert total- eller subtotalniveau i stedet for at aggregere de detaljerede værdier lokalt. En simpel tabelvisualisering med totaler sender to kildeforespørgsler i stedet for én.

Kildegrupper

En kildegruppe er en samling elementer, f.eks. tabeller og relationer, fra en DirectQuery-kilde eller alle importkilder, der er involveret i en datamodel. En sammensat model er lavet af en eller flere kildegrupper. Overvej følgende eksempler:

• En sammensat model, der opretter forbindelse til en semantisk Power BI-model med navnet Sales og forbedrer den semantiske model ved at tilføje en Sales YTD-måling , som ikke er tilgængelig i den oprindelige semantiske model. Denne model består af én kildegruppe.
• En sammensat model, der kombinerer data ved at importere en tabel fra et Excel-ark med navnet Targets og en CSV-fil med navnet Områder og oprette en DirectQuery-forbindelse til en semantisk Power BI-model med navnet Salg. I dette tilfælde er der to kildegrupper som vist på følgende billede:
  • Den første kildegruppe indeholder tabellerne fra Excel-arket Targets og CSV-filen Område .
  • Den anden kildegruppe indeholder elementerne fra semantikmodellen Sales Power BI.

Hvis du har føjet en anden DirectQuery-forbindelse til en anden kilde, f.eks. en DirectQuery-forbindelse til en SQL Server-database kaldet Inventory, tilføjes elementerne fra den pågældende kilde som en anden kildegruppe:

Bemærk

Import af data fra en anden kilde tilføjer ikke en anden kildegruppe, fordi alle elementer fra alle importerede kilder er i én kildegruppe.

Kildegrupper og -relationer

Der er to typer relationer i en sammensat model:

• Relationer for intern kildegruppe. Disse relationer relaterer elementer i en kildegruppe sammen. Disse relationer er altid almindelige relationer, medmindre de er mange til mange, i hvilket tilfælde de er begrænset.
• Relationer på tværs af kildegrupper. Disse relationer starter i én kildegruppe og ender i en anden kildegruppe. Disse relationer er altid begrænsede relationer.

Læs mere om forskellen mellem almindelige og begrænsede relationer og deres indvirkning.

På følgende billede har vi f.eks. tilføjet tre relationer på tværs af kildegrupper, der relaterer tabeller på tværs af de forskellige kildegrupper sammen:

Lokal og ekstern

Alle elementer i en kildegruppe, der er en DirectQuery-kildegruppe, betragtes som eksterne, medmindre elementet er defineret lokalt som en del af en udvidelse eller forbedring af DirectQuery-kilden og ikke er en del af fjernkilden, f.eks. en måling eller en beregnet tabel. En beregnet tabel, der er baseret på en tabel fra DirectQuery-kildegruppen, tilhører kildegruppen "Import" og anses for at være lokal. Alle elementer i kildegruppen "Import" anses for at være lokale. Hvis du f.eks. definerer følgende måling i en sammensat model, der bruger en DirectQuery-forbindelse til lagerkilden, anses målingen for at være lokal:

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

Beregningsgrupper, evaluering af forespørgsler og målinger

Beregningsgrupper gør det muligt at reducere antallet af redundante målinger og gruppere almindelige målingsudtryk sammen. Typiske use cases er time intelligence-beregninger, hvor du vil kunne skifte fra faktiske værdier til måned-til-dato-, kvartal-til-dato- eller års-til-dato-beregninger. Når du arbejder med sammensatte modeller, er det vigtigt at være opmærksom på interaktionen mellem beregningsgrupper, og om en måling kun refererer til elementer fra en enkelt fjernkildegruppe. Hvis en måling kun refererer til elementer fra en enkelt ekstern kildegruppe, og fjernmodellen definerer en beregningsgruppe, der påvirker målingen, anvendes denne beregningsgruppe, selvom målingen blev defineret i fjernmodellen eller i den lokale model. Men hvis en måling ikke refererer til elementer fra en enkelt fjernkildegruppe med udelt adgang, men henviser til elementer fra en ekstern kildegruppe, hvor der anvendes en ekstern beregningsgruppe, kan resultaterne af målingen stadig blive påvirket af fjernberegningsgruppen. Se følgende eksempel:

• Reseller Sales er en måling, der er defineret i fjernmodellen.
• Fjernmodellen indeholder en beregningsgruppe, der ændrer resultatet af Reseller Sales
• Internet Sales er en måling, der er defineret i den lokale model.
• Total Sales er en måling, der er defineret i den lokale model, og har følgende definition:

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

I dette scenarie påvirkes målingen Internet Sales ikke af den beregningsgruppe, der er defineret i fjernmodellen, fordi de ikke er en del af den samme model. Beregningsgruppen kan dog ændre resultatet af målingen Reseller Sales , fordi de er i samme model. Dette betyder, at de resultater, der returneres af målingen Total Sales , skal evalueres omhyggeligt. Forestil dig, at vi bruger beregningsgruppen i fjernmodellen til at returnere resultater for år til dato. Det resultat, der returneres af Reseller Sales , er nu en år-til-dato-værdi, mens resultatet, der returneres af Internet Sales , stadig er en faktisk værdi. Resultatet af Samlet salg er nu sandsynligvis uventet, da det føjer en faktisk værdi til et års-til-dato-resultat.

Sammensatte modeller på semantiske Power BI-modeller og Analysis Services

Ved hjælp af sammensatte modeller med semantiske Power BI-modeller og Analysis Services kan du oprette en sammensat model ved hjælp af en DirectQuery-forbindelse til at oprette forbindelse til semantiske Power BI-modeller, Azure Analysis Services (AAS) og SQL Server 2022 Analysis Services. Ved hjælp af en sammensat model kan du kombinere dataene i disse kilder med andre DirectQuery og importerede data. Rapportforfattere, der vil kombinere dataene fra deres semantiske virksomhedsmodel med andre data, de ejer, f.eks. et Excel-regneark, eller som vil tilpasse eller forbedre metadataene fra deres semantiske virksomhedsmodel, vil finde denne funktionalitet særlig nyttig.

Administration af sammensatte modeller på semantiske Power BI-modeller

Hvis du vil aktivere oprettelse og forbrug af sammensatte modeller på semantiske Power BI-modeller, skal følgende parametre være aktiveret for din lejer:

• Tillad XMLA-slutpunkter og analysér i Excel med semantiske modeller i det lokale miljø. Hvis denne parameter er deaktiveret, kan der ikke oprettes en DirectQuery-forbindelse til en semantisk Power BI-model.
• Brugerne kan arbejde med semantiske Power BI-modeller i Excel ved hjælp af en direkte forbindelse. Hvis denne parameter er deaktiveret, kan brugerne ikke oprette direkte forbindelser til semantiske Power BI-modeller, så knappen Foretag ændringer af denne model ikke kan nås.
• Tillad DirectQuery-forbindelse til semantiske Power BI-modeller. Se følgende afsnit for at få flere oplysninger om denne parameter og effekten af at deaktivere den.

For Premium-kapaciteter og Premium pr. bruger skal indstillingen "XMLA-slutpunkt" være aktiveret og indstillet til enten "Skrivebeskyttet" eller "Læse/skrive".

Lejeradministratorer kan aktivere eller deaktivere DirectQuery-forbindelser til semantiske Power BI-modeller på administrationsportalen. Selvom dette er aktiveret som standard, vil deaktivering af den effektivt forhindre brugerne i at publicere nye sammensatte modeller på semantiske Power BI-modeller til tjenesten.

Eksisterende rapporter, der bruger en sammensat model på en semantisk Power BI-model, fungerer fortsat, og brugerne kan stadig oprette den sammensatte model ved hjælp af Desktop, men de kan ikke publicere til tjenesten. Når du i stedet opretter en DirectQuery-forbindelse til den semantiske Power BI-model ved at vælge Foretag ændringer af denne model , får du vist følgende advarselsmeddelelse:

På denne måde kan du stadig udforske den semantiske model i dit lokale Power BI Desktop-miljø og oprette den sammensatte model. Du kan dog ikke publicere rapporten til tjenesten. Når du publicerer rapporten og modellen, får du vist følgende fejlmeddelelse, og publikationen blokeres:

Bemærk, at direkte forbindelser til semantiske Power BI-modeller ikke påvirkes af kontakten, og at de heller ikke er direkte eller DirectQuery-forbindelser til Analysis Services. Disse fungerer fortsat, uanset om kontakten er slået fra. Alle publicerede rapporter, der anvender en sammensat model på en semantisk Power BI-model, fungerer fortsat, selvom kontakten er blevet deaktiveret, efter at de blev publiceret.

Oprettelse af en sammensat model på en semantisk model eller model

Oprettelse af en sammensat model på en semantisk Power BI-model eller Analysis Services-model kræver, at din rapport har en lokal model. Du kan starte fra en direkte forbindelse og føje eller opgradere til en lokal model eller starte med en DirectQuery-forbindelse eller importerede data, hvilket automatisk opretter en lokal model i din rapport.

Hvis du vil se, hvilke forbindelser der bruges i din model, skal du kontrollere statuslinjen i nederste højre hjørne af Power BI Desktop. Hvis du kun har forbindelse til en Analysis Services-kilde, får du vist en meddelelse som følgende billede:

Hvis du har forbindelse til en semantisk Power BI-model, får du vist en meddelelse om, hvilken semantisk Power BI-model du har forbindelse til:

Hvis du vil tilpasse metadataene for felter i din semantiske model med direkte forbindelse, skal du vælge Foretag ændringer af denne model på statuslinjen. Du kan også vælge knappen Foretag ændringer af denne model på båndet, som vist på følgende billede. I Rapportvisning skal du klikke på knappen Foretag ændringer af denne model under fanen Udformning . I Modelvisning er knappen på fanen Hjem .

Når du vælger knappen, vises en dialogboks, der bekræfter tilføjelsen af en lokal model. Vælg Tilføj en lokal model for at aktivere oprettelse af nye kolonner eller ændring af metadataene for felter fra semantiske Power BI-modeller eller Analysis Services. På følgende billede vises den dialogboks, der vises.

Når du har direkte forbindelse til en Analysis Services-kilde, er der ingen lokal model. Hvis du vil bruge DirectQuery til direkte forbundne kilder, f.eks. semantiske Power BI-modeller og Analysis Services, skal du føje en lokal model til din rapport. Når du publicerer en rapport med en lokal model til Power BI-tjeneste, udgives en semantisk model for den lokale model en brønd.

Kæde

Semantiske modeller og de semantiske modeller, som de er baseret på, udgør en kæde. Denne proces, der kaldes sammenkædning, giver dig mulighed for at publicere en rapport og en semantisk model, der er baseret på andre semantiske Power BI-modeller, en funktion, der tidligere ikke var mulig.

Forestil dig f.eks., at din kollega publicerer en semantisk Power BI-model med navnet Salg og Budget , der er baseret på en Analysis Services-model kaldet Salg, og kombinerer den med et Excel-ark kaldet Budget.

Når du publicerer en ny rapport (og semantisk model) kaldet Sales and Budget Europe , der er baseret på den semantiske Power BI-model Sales and Budget , der er udgivet af din kollega, og som foretager yderligere ændringer eller udvidelser, efterhånden som du gør det, føjer du effektivt en rapport og semantisk model til en kæde af tre længder, som startede med Sales Analysis Services-modellen, og slutter med din semantiske Power BI-semantikmodel Sales and Budget Europe . Følgende billede visualiserer denne sammenkædningsproces.

Kæden i det forrige billede er af længden tre, hvilket er den maksimale længde. Udvidelse ud over en kædelængde på tre understøttes ikke og resulterer i fejl.

Tilladelser og licenser

Brugere, der får adgang til rapporter ved hjælp af en sammensat model, skal have de rette tilladelser til alle semantiske modeller og modeller i kæden.

Ejeren af den sammensatte model kræver tilladelsen Opret for de semantiske modeller, der bruges som kilder, så andre brugere kan få adgang til disse modeller på vegne af ejeren. Derfor kræver oprettelse af den sammensatte modelforbindelse i Power BI Desktop eller oprettelse af rapporten i Power BI tilladelsen Opret for de semantiske modeller, der bruges som kilder.

Brugere, der får vist rapporter ved hjælp af den sammensatte model, kræver generelt læsetilladelser til selve den sammensatte model og de semantiske modeller, der bruges som kilder. Oprettelsestilladelser kan være påkrævet, hvis rapporterne er i et Pro-arbejdsområde. Disse lejerparametre skal aktiveres for brugeren.

De påkrævede tilladelser kan illustreres med følgende eksempel:

• Sammensat model A (ejet af ejer A)

  • Datakilde A1: Semantisk model B.
    Ejer A skal have tilladelsen Opret for semantisk model B , for at brugerne kan få vist rapporten ved hjælp af sammensat model A.

• Sammensat model C (ejet af ejer C)

  • Datakilde C1: Semantisk model D
    Ejer C skal have tilladelsen Opret for semantisk model D , for at brugerne kan få vist rapporten ved hjælp af sammensat model C.
  • Datakilde C2: Sammensat model A
    Ejer C skal have tilladelsen Opret for sammensat model A og læsetilladelse til semantisk model B.

En bruger, der får vist rapporter ved hjælp af sammensat model A , skal have læsetilladelser til både sammensat model A og semantisk model B, mens en bruger, der får vist rapporter ved hjælp af sammensat model C , skal have læserettigheder til sammensat model C, semantisk model D, sammensat model A og semantisk model B.

Bemærk

Se dette blogindlæg for at få vigtige oplysninger om de tilladelser, der kræves til sammensatte modeller på semantiske Power BI-modeller og Analysis Services-modeller.

Hvis et datasæt i kæden er i et Premium pr. bruger-arbejdsområde, skal den bruger, der har adgang til det, have en Premium pr. bruger-licens. Hvis et datasæt i kæden er i et Pro-arbejdsområde, skal den bruger, der tilgår det, have en Pro-licens. Hvis alle datasæt i kæden er på Premium-kapaciteter eller Fabric F64 eller større kapacitet, kan en bruger få adgang til det ved hjælp af en gratis licens.

Sikkerhedsadvarsel

Hvis du bruger funktionen DirectQuery til power BI-semantiske modeller og Analysis Services, får du vist en dialogboks med en sikkerhedsadvarsel, der vises på følgende billede.

Data kan pushes fra én datakilde til en anden, hvilket er den samme sikkerhedsadvarsel for at kombinere DirectQuery og importkilder i en datamodel. Hvis du vil vide mere om denne funktionsmåde, skal du se Brug af sammensatte modeller i Power BI Desktop.

Understøttede scenarier

Du kan bygge sammensatte modeller ved hjælp af data fra semantiske Power BI-modeller eller Analysis Services-modeller for at betjene følgende scenarier:

• Forbind til data fra forskellige kilder: Import (f.eks. filer), semantiske Power BI-modeller, Analysis Services-modeller
• Oprettelse af relationer mellem forskellige datakilder
• Skrivning af målinger, der bruger felter fra forskellige datakilder
• Oprettelse af nye kolonner til tabeller fra semantiske Power BI-modeller eller Analysis Services-modeller
• Oprettelse af visualiseringer, der bruger kolonner fra forskellige datakilder
• Du kan fjerne en tabel fra din model ved hjælp af feltlisten for at holde modeller så præcise og lean som muligt (hvis du opretter forbindelse til et perspektiv, kan du ikke fjerne tabeller fra modellen)
• Du kan angive, hvilke tabeller der skal indlæses, i stedet for at skulle indlæse alle tabeller, når du kun vil have et bestemt undersæt af tabeller. Se Indlæsning af et undersæt af tabeller senere i dette dokument.
• Du kan angive, om du vil føje tabeller, der efterfølgende føjes til den semantiske model, når du har oprettet forbindelse i din model.

Arbejde med en sammensat model, der er baseret på en semantisk model

Når du arbejder med DirectQuery til semantiske Power BI-modeller og Analysis Services, skal du overveje følgende:

• Hvis du opdaterer dine datakilder, og der er fejl med modstridende felt- eller tabelnavne, løser Power BI fejlene for dig.

• Du kan ikke redigere, slette eller oprette nye relationer i den samme semantiske Power BI-model eller Analysis Services-kilde. Hvis du har redigeringsadgang til disse kilder, kan du i stedet foretage ændringerne direkte i datakilden.

• Du kan ikke ændre datatyper for kolonner, der indlæses fra en semantisk Power BI-model eller Analysis Services-kilde. Hvis du har brug for at ændre datatypen, skal du enten ændre den i kilden eller bruge en beregnet kolonne.

• Hvis du vil oprette rapporter i Power BI-tjeneste på en sammensat model, der er baseret på en anden semantisk model, skal alle legitimationsoplysninger angives.

• Forbind ioner til en SQL Server 2022 og nyere Analysis Services-server i det lokale miljø eller IAAS kræver en datagateway i det lokale miljø (standardtilstand).

• Alle forbindelser til eksterne Power BI-semantiske modeller oprettes ved hjælp af enkeltlogon. Godkendelse med en tjenesteprincipal understøttes ikke i øjeblikket.

• RLS-regler anvendes på den kilde, de er defineret for, men anvendes ikke på andre semantiske modeller i modellen. Sikkerhed på rækkeniveau, der er defineret i rapporten, anvendes ikke på eksterne kilder, og sikkerhed på rækkeniveau, der er angivet på eksterne kilder, anvendes ikke på andre datakilder. Du kan heller ikke definere sikkerhed på rækkeniveau i en tabel, der er indlæst fra en ekstern kilde, og sikkerhed på rækkeniveau, der er defineret i lokale tabeller, filtrerer ikke nogen tabeller, der er indlæst fra en ekstern kilde.

• KPI'er, sikkerhed på rækkeniveau og oversættelser importeres ikke fra kilden.

• Du får muligvis vist en uventet funktionsmåde, når du bruger et datohierarki. Du kan løse problemet ved at bruge en datokolonne i stedet. Når du har føjet et datohierarki til en visualisering, kan du skifte til en datokolonne ved at klikke på pil ned i feltnavnet og derefter klikke på navnet på feltet i stedet for at bruge Datohierarki:

  

  Du kan finde flere oplysninger om brug af datokolonner i forhold til datohierarkier under Anvend automatisk dato eller klokkeslæt i Power BI Desktop.

• Den maksimale længde på en kæde af modeller er tre. Udvidelse ud over kædelængden på tre understøttes ikke og resulterer i fejl.

• Der kan angives et fraråde sammenkædningsflag for en model for at forhindre, at en kæde oprettes eller udvides. Du kan finde flere oplysninger under Administrer DirectQuery-forbindelser til en publiceret semantisk model .

• Forbindelsen til en semantisk Power BI-model eller Analysis Services-model vises ikke i Power Query.

Følgende begrænsninger gælder, når du arbejder med DirectQuery til semantiske Power BI-modeller og Analysis Services:

• Parametre for database- og servernavne er deaktiveret i øjeblikket.
• Definition af sikkerhed på rækkeniveau for tabeller fra en ekstern kilde understøttes ikke.
• Brug af en af følgende kilder som DirectQuery-kilde understøttes ikke:
  • SSAS-tabelmodeller (SQL Server Analysis Services) før version 2022
  • SSAS Flerdimensionelle modeller
  • SAP HANA
  • SAP Business Warehouse
  • Semantiske modeller i realtid
  • Semantiske eksempelmodeller
  • Opdatering af Excel Online
  • Data, der er importeret fra Excel- eller CSV-filer i tjenesten
  • Forbrugsdata
  • Semantiske modeller, der er gemt i "Mit arbejdsområde"
• Brug af Power BI Embedded med semantiske modeller, der indeholder en DirectQuery-forbindelse til en Analysis Services-model, understøttes ikke i øjeblikket.
• Publicering af en rapport på internettet ved hjælp af funktionen Publicer på internettet understøttes ikke.
• Beregningsgrupper på eksterne kilder understøttes ikke med udefinerede forespørgselsresultater.
• Beregnede tabeller understøttes ikke i tjenesten ved hjælp af denne funktion. Hvis du forsøger at udføre en opdatering på en semantisk model med en beregnet tabel eller en beregnet kolonne, der refererer til en DirectQuery-datakilde, resulterer det i fejlmeddelelsen "Enkeltlogon (SSO) er ikke angivet".
• Hvis du omdøber et arbejdsområde, når DirectQuery-forbindelsen er konfigureret, skal du opdatere datakilden i Power BI Desktop, for at rapporten kan fortsætte med at fungere.
• Automatisk sideopdatering understøttes kun i nogle scenarier, afhængigt af datakildetypen. Du kan få flere oplysninger i artiklen Automatisk sideopdatering i Power BI .
• Overtagelse af en semantisk model, der bruger funktionen DirectQuery til andre semantiske modeller , understøttes ikke i øjeblikket.
• Som med enhver DirectQuery-datakilde vises hierarkier, der er defineret i en Analysis Services-model eller en semantisk Power BI-model, ikke, når der oprettes forbindelse til modellen eller den semantiske model i DirectQuery-tilstand ved hjælp af Excel.

Der er et par andre ting, du skal overveje , når du arbejder med DirectQuery til semantiske Power BI-modeller og Analysis Services:

• Brug kolonner med lav kardinalitet i relationer på tværs af kildegrupper: Når du opretter en relation på tværs af to forskellige kildegrupper, skal de kolonner, der deltager i relationen (også kaldet joinkolonnerne), have lav kardinalitet, ideelt set 50.000 eller mindre. Denne overvejelse gælder for nøglekolonner, der ikke er strenge. for kolonner med strengnøgler skal du se følgende overvejelse.
• Undgå at bruge store strengenøglekolonner i relationer på tværs af kildegrupper: Når du opretter en relation på tværs af kildegrupper, skal du undgå at bruge store strengkolonner som relationskolonner, især for kolonner med større kardinalitet. Når du skal bruge strengkolonner som relationskolonne, skal du beregne den forventede strenglængde for filteret ved at multiplicere kardinaliteten (C) med den gennemsnitlige længde af strengkolonnen (A). Sørg for, at den forventede strenglængde er under 250.000, så A ∗ C < 250.000.

Du kan finde flere overvejelser og vejledning i vejledning til sammensatte modeller.

Overvejelser i forbindelse med lejer

Alle modeller med en DirectQuery-forbindelse til en semantisk Power BI-model eller Analysis Services skal publiceres i den samme lejer, hvilket især er vigtigt, når du opretter adgang til en semantisk Power BI-model eller en Analysis Services-model ved hjælp af B2B-gæsteidentiteter, som vist i følgende diagram. Se Gæstebrugere, der kan redigere og administrere indhold, for at finde lejerens URL-adresse til publicering.

Overvej følgende diagram. De nummererede trin i diagrammet er beskrevet i efterfølgende afsnit.

I diagrammet arbejder Ash med Contoso og får adgang til data fra Fabrikam. Ved hjælp af Power BI Desktop opretter Ash en DirectQuery-forbindelse til en Analysis Services-model, der hostes i Fabrikams lejer.

Ash bruger en B2B Guest-brugeridentitet (trin 1 i diagrammet) til godkendelse.

Hvis rapporten publiceres på Contosos Power BI-tjeneste (trin 2), kan den semantiske model, der er publiceret i Contoso-lejeren, ikke godkendes i forhold til Fabrikams Analysis Services-model (trin 3). Derfor fungerer rapporten ikke.

Da den anvendte Analysis Services-model i dette scenarie hostes i Fabrikams lejer, skal rapporten også publiceres i Fabrikams lejer. Efter en vellykket publikation i Fabrikams lejer (trin 4) kan den semantiske model få adgang til Analysis Services-modellen (trin 5), og rapporten fungerer korrekt.

Arbejde med sikkerhed på objektniveau

Når en sammensat model henter data fra en semantisk Power BI-model eller Analysis Services via DirectQuery, og denne kildemodel er sikret af sikkerhed på objektniveau, kan forbrugere af den sammensatte model opleve uventede resultater. I følgende afsnit forklares det, hvordan disse resultater kan opstå.

Sikkerhed på objektniveau (OLS) gør det muligt for modelforfattere at skjule objekter, der udgør modelskemaet (dvs. tabeller, kolonner, metadata osv.) fra modelforbrugere (f.eks. en report builder eller en sammensat modelforfatter). Når modelforfatteren konfigurerer OLS for et objekt, opretter den en rolle og fjerner derefter adgangen til objektet for brugere, der er tildelt den pågældende rolle. Set fra disse brugeres synspunkt findes det skjulte objekt ganske enkelt ikke.

OLS er defineret for og anvendt på kildemodellen. Den kan ikke defineres for en sammensat model, der er baseret på kildemodellen.

Når en sammensat model er bygget oven på en SES-beskyttet Power BI-semantisk model eller Analysis Services-model via DirectQuery-forbindelse, kopieres modelskemaet fra kildemodellen til den sammensatte model. Det, der kopieres, afhænger af, hvad forfatteren af den sammensatte model har tilladelse til at se i kildemodellen i henhold til de OLS-regler, der gælder der. Selve dataene kopieres ikke til den sammensatte model – i stedet hentes de altid via DirectQuery fra kildemodellen, når det er nødvendigt. Med andre ord kommer datahentning altid tilbage til kildemodellen, hvor OLS-regler gælder.

Da den sammensatte model ikke er beskyttet af OLS-regler, er de objekter, som forbrugere af den sammensatte model kan se, dem, som forfatteren af den sammensatte model kan se i kildemodellen i stedet for det, de selv har adgang til. Dette kan resultere i følgende situationer

• En person, der kigger på den sammensatte model, kan se objekter, der er skjult for dem i kildemodellen af OLS.
• Omvendt kan de muligvis IKKE se et objekt i den sammensatte model, som de kan se i kildemodellen, fordi dette objekt blev skjult for forfatteren af den sammensatte model af OLS-reglerne, der styrer adgangen til kildemodellen.

Et vigtigt punkt er, at på trods af det tilfælde, der er beskrevet i det første punkttegn, vil forbrugere af den sammensatte model aldrig se faktiske data, de ikke skal se, fordi dataene faktisk ikke er placeret i den sammensatte model. På grund af DirectQuery hentes den i stedet efter behov fra den semantiske kildemodel, hvor OLS blokerer uautoriseret adgang.

Med denne baggrund i tankerne skal du overveje følgende scenarie:

1. Administration_user har publiceret en semantisk virksomhedsmodel ved hjælp af en semantisk Power BI-model eller en Analysis Services-model, der har en kundetabel og en områdetabel. Administration_user publicerer den semantiske model til Power BI-tjeneste og angiver OLS-regler, der har følgende virkning:

   • Økonomibrugere kan ikke se tabellen Kunde
   • Marketingbrugere kan ikke se tabellen Territory

2. Finance_user publicerer en semantisk model kaldet "Finance semantisk model" og en rapport med navnet "Finance report", der opretter forbindelse via DirectQuery til den semantiske virksomhedsmodel, der er publiceret i trin 1. Økonomirapporten indeholder en visualisering, der bruger en kolonne fra tabellen Territory.

3. Marketing_user åbner finansrapporten. Den visualisering, der bruger tabellen Territory, vises, men returnerer en fejl, fordi DirectQuery forsøger at hente dataene fra kildemodellen ved hjælp af legitimationsoplysningerne for Marketing_user, som er blokeret fra at få vist tabellen Territory i henhold til de OLS-regler, der er angivet i den semantiske virksomhedsmodel.

4. Marketing_user opretter en ny rapport med navnet "Marketingrapport", der bruger den semantiske økonomimodel som kilde. Feltlisten viser de tabeller og kolonner, som Finance_user har adgang til. Derfor vises tabellen Territory på listen felter, men det er tabellen Customer ikke. Men når Marketing_user forsøger at oprette en visualisering, der udnytter en kolonne fra tabellen Territory, returneres der en fejl, fordi DirectQuery på det tidspunkt forsøger at hente data fra kildemodellen ved hjælp af Marketing_user legitimationsoplysninger, og OLS-regler sparker og blokerer adgang igen. Det samme sker, når Marketing_user opretter en ny semantisk model og rapport, der opretter forbindelse til den semantiske økonomimodel med en DirectQuery-forbindelse – de får vist tabellen Territory på listen felter, da det er det, Finance_user kunne se, men når de forsøger at oprette en visualisering, der udnytter tabellen, blokeres de af OLS-reglerne for den semantiske virksomhedsmodel.

5. Lad os nu sige, at Administration_user opdaterer OLS-reglerne for den semantiske virksomhedsmodel for at forhindre Finance i at se tabellen Territory.

6. De opdaterede OLS-regler afspejles kun i den semantiske økonomimodel, når den opdateres. Når Finance_user opdaterer den semantiske økonomimodel, vises tabellen Territory derfor ikke længere på listen felter, og det visuelle element i økonomirapporten, der bruger en kolonne fra tabellen Territory, returnerer en fejl for Finance_user, fordi de nu ikke har adgang til tabellen Territory.

Sådan opsummerer du:

• Forbrugere af en sammensat model kan se resultaterne af de OLS-regler, der var gældende for forfatteren af den sammensatte model, da de oprettede modellen. Når der oprettes en ny rapport baseret på den sammensatte model, viser feltlisten de tabeller, som forfatteren af den sammensatte model havde adgang til, da modellen blev oprettet, uanset hvad den aktuelle bruger har adgang til i kildemodellen.
• OLS-regler kan ikke defineres for selve den sammensatte model.
• En forbruger af en sammensat model får aldrig vist faktiske data, som de ikke skal se, fordi relevante OLS-regler i kildemodellen blokerer dem, når DirectQuery forsøger at hente dataene ved hjælp af deres legitimationsoplysninger.
• Hvis kildemodellen opdaterer sine OLS-regler, påvirker disse ændringer kun den sammensatte model, når den opdateres.

Indlæser et undersæt af tabeller fra en semantisk Power BI-model eller Analysis Services-model

Når du opretter forbindelse til en semantisk Power BI-model eller Analysis Services-model ved hjælp af en DirectQuery-forbindelse, kan du beslutte, hvilke tabeller der skal oprettes forbindelse til. Du kan også vælge automatisk at tilføje en tabel, der kan blive føjet til den semantiske model eller model, når du har oprettet forbindelse til din model. Når du opretter forbindelse til et perspektiv, indeholder din model alle tabeller i den semantiske model, og alle tabeller, der ikke er inkluderet i perspektivet, skjules. Desuden tilføjes alle tabeller, der kan blive føjet til perspektivet, automatisk. I menuen Indstillinger kan du vælge automatisk at oprette forbindelse til tabeller, der føjes til den semantiske model, når du først har konfigureret forbindelsen.

Denne dialogboks vises ikke for direkte forbindelser.

Bemærk

Denne dialogboks vises kun, hvis du føjer en DirectQuery-forbindelse til en semantisk Power BI-model eller Analysis Services-model til en eksisterende model. Du kan også åbne denne dialogboks ved at ændre DirectQuery-forbindelsen til den semantiske Power BI-model eller Analysis Services-model i indstillingerne for datakilden, når du har oprettet den.

Konfiguration af deduplikeringsregler

Du kan angive deduplikeringsregler for at holde målings- og tabelnavne entydige i en sammensat model ved hjælp af indstillingen Indstillinger i den dialogboks, der blev vist tidligere:

I det forrige eksempel har vi besluttet at føje ' (marketing)' som et suffiks til et tabel- eller målingsnavn, der er i konflikt med en anden kilde i den sammensatte model. Bemærk, at du kan:

• angiv en tekst, der skal føjes til navnet på modstridende tabeller eller målinger
• angiv, om teksten skal føjes til tabel- eller målingsnavnet som præfiks eller suffiks
• anvende deduplationsreglen på tabeller, målinger eller begge dele
• Vælg kun at anvende deduplikeringsreglen, når der opstår en navnekonflikt, eller anvend den hele tiden. Standarden er kun at anvende reglen, når der sker duplikering. I vores eksempel får alle tabeller eller målinger fra marketingkilden, der ikke har en dublet i salgskilden, ikke en navneændring.

Når du har oprettet forbindelserne og konfigureret deduplikeringsreglen, viser din feltliste både 'Kunde' og 'Kunde (marketing)' i henhold til den deduplikeringsregel, der er konfigureret i vores eksempel:

Hvis du ikke angiver en deduplationsregel eller de deduplikeringsregler, du har angivet, kan du ikke løse navnet i konflikt med standardafduplikeringsreglerne, der stadig anvendes. Standardafduplikeringsreglerne føjer et tal til navnet på det modstridende element. Hvis der opstår en navnekonflikt i tabellen 'Kunde', omdøbes en af tabellerne 'Kunde' til 'Kunde 2'.

Overvejelser og begrænsninger

Sammensatte modeller præsenterer et par overvejelser og begrænsninger:

Forbindelser i blandet tilstand – Når du bruger en forbindelse i blandet tilstand, der indeholder onlinedata (f.eks. en semantisk Power BI-model) og en semantisk model i det lokale miljø (f.eks. en Excel-projektmappe), skal du have oprettet gatewaytilknytninger, for at visualiseringer kan vises korrekt.

I øjeblikket understøttes trinvis opdatering kun for sammensatte modeller, der opretter forbindelse til sql-, Oracle- og Teradata-datakilder.

Følgende live-Forbind tabelkilder kan ikke bruges sammen med sammensatte modeller:

• SAP HANA
• SAP Business Warehouse
• SQL Server Analysis Services tidligere end version 2022
• Forbrugsdata (Mit arbejdsområde)

Brug af semantiske streamingmodeller i sammensatte modeller understøttes ikke.

De eksisterende begrænsninger for DirectQuery gælder stadig, når du bruger sammensatte modeller. Mange af disse begrænsninger er nu pr. tabel, afhængigt af tabellens lagringstilstand. En beregnet kolonne i en importtabel kan f.eks. referere til andre tabeller, der ikke findes i DirectQuery, men en beregnet kolonne i en DirectQuery-tabel kan stadig kun referere til kolonner i den samme tabel. Der gælder andre begrænsninger for modellen som helhed, hvis nogen af tabellerne i modellen er DirectQuery. Funktionen QuickInsights er f.eks. ikke tilgængelig for en model, hvis nogen af tabellerne i den har lagringstilstanden DirectQuery.

Relateret indhold

Du kan finde flere oplysninger om sammensatte modeller og DirectQuery i følgende artikler:

• Anvend mange til mange-relationer i Power BI Desktop
• Administrer lagringstilstand i Power BI Desktop
• DirectQuery i Power BI
• Power BI-datakilder
• Modelrelationer i Power BI Desktop