Bruk sammensatte modeller i Power BI Desktop

Tidligere når du brukte en DirectQuery i en rapport i Power BI Desktop, var ingen andre datatilkoblinger, verken DirectQuery eller Import, tillatt for den rapporten. Med sammensatte modeller fjernes den begrensningen. En rapport kan nå sømløst inkludere datatilkoblinger fra mer enn én DirectQuery- eller importer data-tilkobling, i hvilken som helst kombinasjon du måtte ønske.

Funksjonaliteten med sammensatte modeller i Power BI Desktop består av tre relaterte funksjoner:

  • Sammensatte modeller: Lar en rapport ha to eller flere datatilkoblinger fra ulike kildegrupper. For eksempel kan den ha én eller flere DirectQuery-tilkoblinger og en importtilkobling, to eller flere DirectQuery-tilkoblinger, eller hvilken som helst kombinasjon av disse. Denne artikkelen beskriver sammensatte modeller i detalj.

  • Mange-til-mange-relasjoner: Med sammensatte modeller kan du etablere mange-til-mange-relasjoner mellom tabeller. Denne tilnærmingen fjerner krav om unike verdier i tabeller. Den fjerner også tidligere midlertidige løsninger, for eksempel introduksjon av bare nye tabeller for å opprette relasjoner. For mer informasjon, kan du se Bruke mange-til-mange-relasjoner i Power BI Desktop.

  • Lagringsmodus: Nå kan du angi hvilke visualobjekter som kjører spørring til datakilder på serverdelen. Visualobjekter som ikke krever en spørring, importeres selv om de er basert på DirectQuery. Denne funksjonen bidrar til å forbedre ytelsen og redusere belastningen på serverdelen. Tidligere innledet til og med enkle visualobjekter, for eksempel slicere, spørringer til serverdelkilder. For mer informasjon, kan du se Administrere lagringsmodus i Power BI Desktop.

Bruk av sammensatte modeller

Med sammensatte modeller kan du koble til forskjellige datakilder når du bruker Power BI Desktop eller Power BI-tjenesten. Du kan utføre disse datatilkoblingene på et par måter:

  • Ved å importere data til Power BI, som er den vanligste måten å hente data på.
  • Ved å koble direkte til data i det opprinnelige kilderepositoriet ved hjelp av DirectQuery. Hvis du vil finne ut mer om DirectQuery, kan du se Bruk av DirectQuery i Power BI.

Når du bruker DirectQuery, gjør sammensatte modeller det mulig å opprette en Power BI-modell, for eksempel en enkelt .pbix i Power BI Desktop, som gjør det ene eller begge av følgende:

  • Kombinerer data fra én eller flere DirectQuery-kilder.
  • Kombinerer data fra DirectQuery-kilder og importerte data.

Du kan for eksempel ved hjelp av sammensatte modeller bygge en modell som kombinerer følgende typer data:

  • Salgsdata fra et datalager for en organisasjon.
  • Salgsmåldata fra en SQL Server-database på avdelingsnivå.
  • Data som er importert fra et regneark.

En modell som kombinerer data fra mer enn én DirectQuery-kilde, eller kombinerer DirectQuery med importerte data, kalles en sammensatt modell.

Du kan opprette relasjoner mellom tabeller som du alltid har gjort, selv når disse tabellene kommer fra ulike kilder. Alle relasjoner som er krysskilder, opprettes med en kardinalitet for mange-til-mange, uavhengig av deres faktiske kardinalitet. Du kan endre dem til én-til-mange, mange-til-én eller én-til-én. Avhengig av hvilken kardinalitet du angir, har kryss kilde relasjoner forskjellige virkemåter. Du kan ikke bruke DAX-funksjoner (Data Analysis Expressions) til å hente verdier på one-siden fra many-siden. Du kan også se en ytelsespåvirkning kontra mange-til-mange-relasjoner i samme kilde.

Obs!

I forbindelse med sammensatte modeller behandles importerte tabeller som en enkelt kilde, uavhengig av den underliggende datakilden.

Eksempel på en sammensatt modell

Et eksempel på en sammensatt modell kan være en rapport som er koblet til et datalager for en virksomhet i SQL Server ved hjelp av DirectQuery. I dette tilfellet inneholder datalageret data for salg etter land, kvartal og sykkel (produkt) , som vist i illustrasjonen nedenfor:

Relasjonsvisning for sammensatte modeller

Nå kan du bygge enkle visualobjekter ved bruk av felter fra denne kilden. Det følgende bildet viser totalt salgsbeløp etter ProductName for et valgt kvartal.

Visualobjekt basert på data

Men hva om du har data i et Office Excel-regneark om produktsjefen som er tilordnet til hvert produkt, sammen med markedsføringsprioriteten? Hvis du vil vise salgsbeløp etter produktsjef, er det kanskje ikke mulig å legge til disse lokale dataene i firmaets datalager. Eller det kan ta måneder i beste fall.

Det kan være mulig å importere disse salgsdataene fra datalageret i stedet for å bruke DirectQuery. Og salgsdataene kan deretter kombineres med dataene som du har importert fra regnearket. Denne fremgangsmåten er imidlertid urimelig, av årsakene som førte til at DirectQuery ble brukt i utgangspunktet. Årsakene kan omfatte:

  • Enkelte kombinasjoner av sikkerhetsreglene som er brukt i den underliggende datakilden.
  • Behovet for å kunne vise de nyeste dataene.
  • Størrelsen på dataene.

Her kommer sammensatte modeller inn i bildet. Med sammensatte modeller kan du koble til datalageret ved bruk av DirectQuery og deretter bruke GetData for flere kilder. I dette eksemplet vil vi først opprette DirectQuery-tilkoblingen til firmaets datalager. Vi bruker GetData, velger Excel og navigerer deretter til regnearket som inneholder de lokale dataene. Til slutt importerer vi regnearket som inneholder produktnavn, tilordnet salgssjef og prioritet.

Navigator-vinduet

Du kan se to tabeller i Felter-listen: den opprinnelige Sykkel-tabellen fra SQL Server og en ny ProductManagers-tabell. Den nye tabellen inneholder data som er importert fra Excel.

Feltvisning i tabeller

På samme måte finnes det nå en ekstra tabell som heter ProductManagers i Relasjonsvisning i Power BI Desktop.

Relasjonsvisning av tabeller

Nå må vi relatere disse tabellene til de andre tabellene i modellen. Som alltid oppretter vi en relasjon mellom Sykkel-tabellen fra SQL Server og den importerte ProductManagers-tabellen. Det vil si relasjonen er mellom Sykkel [ProductName] og ProductManagers [ProductName] . Som beskrevet tidligere må alle relasjoner som går på tvers av kilde, ha mange-til-mange-kardinalitet som standard.

Vinduet Opprett relasjon

Når vi har etablert relasjonen, vises den i Relasjonsvisning i Power BI Desktop som forventet.

Den nye relasjonsvisningen

Vi kan nå opprette visualobjekter ved hjelp av feltene i Felter-listen. Denne tilnærmingen kombinerer sømløst data fra flere kilder. For eksempel vises totalen for SalesAmount for hver produktsjef i bildet nedenfor:

Feltruten

Eksemplet nedenfor viser et vanlig tilfelle av en dimensjontabell, for eksempel Produkt eller Kunde, som er utvidet med noen ekstra data importert fra et annet sted. Tabeller kan også bruke DirectQuery til å koble til forskjellige kilder. Hvis vi fortsetter med eksemplet, kan du se at SalesTargets per Land og Periode lagres i en separat database på avdelingsnivå. Du kan som vanlig bruke Get data til å koble til disse dataene, som vist på bildet nedenfor:

Navigator-vinduet

I likhet med tidligere kan vi etablere relasjoner mellom den nye tabellen og andre tabeller i modellen og deretter opprette visualobjekter som kombinerer tabelldataene. La oss ta en titt på Relasjonsvisning på nytt, hvor vi har etablert de nye relasjonene:

Relasjonsvisning med mange tabeller

Neste bilde er basert på de nye dataene og relasjoner som vi opprettet. Visualobjektet nederst til venstre viser totalen for SalesAmount kontra Mål, og beregning av avvik viser forskjellen. Dataene for SalesAmount og Mål kommer fra to forskjellige SQL Server-databaser.

Bilde som viser flere data

Innstilling av lagringsmodus

Hver tabell i en sammensatt tabell har en lagringsmodus som angir om tabellen er basert på DirectQuery eller import. Lagringsmodus kan vises og endres i Egenskap-ruten. Hvis du vil vise lagringsmodellen, høyreklikker du på en tabell i Felter-listen og velger deretter Egenskaper. Bildet nedenfor viser lagringsmodusen for SalesTargets-tabellen.

Du kan også vise lagringsmodus i verktøytipset for hver tabell.

Verktøytips som viser lagringsmodusen

For hver Power BI Desktop-fil (en .pbix-fil) som inneholder noen tabeller fra DirectQuery og noen importtabeller, viser statuslinjen at lagringsmodus er Blandet. Du kan klikke på det begrepet i statuslinjen og enkelt bytte tabellene du vil importere.

For mer informasjon om lagringsmodus, kan du se Administrere lagringsmodus i Power BI Desktop.

Obs!

Du kan bruke Blandet lagringsmodus i Power BI Desktop og i Power BI-tjenesten.

Beregnede tabeller

Du kan legge til beregnede tabeller i en modell som bruker DirectQuery. Data Analysis Expressions (DAX) som definerer den beregnede tabellen, kan referere til importerte tabeller eller DirectQuery-tabeller eller en kombinasjon av de to.

Beregnede tabeller importeres alltid, og dataene i disse tabellene oppdateres når tabellen oppdateres. Hvis en beregnet tabell refererer til en DirectQuery-tabell, viser visualobjekter som refererer til DirectQuery-tabellen, alltid de nyeste verdiene i den underliggende datakilden. Visualobjekter som refererer til den beregnede tabellen, kan også vise verdiene på tidspunktet da den beregnede tabellen sist ble oppdatert.

Sikkerhetsimplikasjoner

Sammensatte tabeller kan ha noen sikkerhetsimplikasjoner. En spørring som sendes til én datakilde, kan inkludere dataverdier som er blitt hentet fra en annen datakilde. I det tidligere eksemplet sender visualobjektet som viser (SalesAmount) etter produktsjef, en SQL-spørring til relasjonsdatabasen for salg. Den SQL-spørringen kan inneholde navnene på produktsjefer og tilknyttede produkter.

Skript som viser sikkerhetsimplikasjoner

Derfor inkluderes nå informasjon som er lagret i regnearket, i en spørring som sendes til relasjonsdatabasen. Hvis denne informasjonen er konfidensiell, må du ta sikkerhetsimplikasjonene med i betraktningen. Du bør spesielt ta hensyn til punktene nedenfor:

  • En hvilken som helst administrator av databasen som kan vise sporinger eller revisjonslogger, kan vise denne informasjonen, selv uten tillatelser til dataene i den opprinnelige kilden. I dette eksemplet må administratoren får tillatelse til å vise Excel-filen.

  • Krypteringsinnstillingene for hver kilde bør vurderes. Du vil unngå at det hentes informasjon fra én kilde gjennom en kryptert tilkobling, som deretter ved et uhell inkluderes i en spørring som sendes til en annen kilde gjennom en ukryptert tilkobling.

For å få bekreftelse på at du har vurdert alle sikkerhetsimplikasjonene vises det en advarselsmelding i Power BI Desktop når du oppretter en sammensatt modell.

Dessuten, hvis en forfatter legger til Tabell1 fra Modell A til en sammensatt modell (vi kaller den Modell C for referanse), kan en bruker som viser en rapport som bygger på Modell C kunne utføre en spørring på hvilken som helst tabell i Modell A som ikke er beskyttet av RLS.

Av lignende årsaker må du være forsiktig når du åpner en Power BI Desktop-fil som ble sendt fra en uklarert kilde. Hvis filen inneholder sammensatte modeller, vil informasjon som noen henter fra én kilde ved hjelp av legitimasjonen til brukeren som åpner filen, sendes til en annen datakilde som en del av spørringen. Informasjonen kan vises av forfatteren av Power BI Desktop-filen. Når du først åpner en Power BI Desktop-fil som inneholder flere kilder, vises det en advarsel i Power BI Desktop. Denne advarselen ligner den som vises når du åpner en fil som inneholder opprinnelige SQL-spørringer.

Ytelsesimplikasjoner

Ytelse bør alltid vurderes når du bruker DirectQuery, hovedsakelig for å sikre at kildene på serverdelen har tilstrekkelige ressurser til å gi en god opplevelse for brukerne. En god opplevelse betyr at visualobjektene oppdateres på fem sekunder eller mindre. For råd om ytelse, kan du se Bruke DirectQuery i Power BI.

Bruk av sammensatte modeller betyr ekstra ytelsesvurderinger. Ett enkelt visualobjekt kan resultere i at det sendes spørringer til flere kilder, som ofte sender resultatene fra én spørring til en annen kilde. Denne situasjonen kan føre til følgende former for kjøringer:

  • En SQL-spørring som inneholder et stort antall litterale verdier: Et visualobjekt som ber om totalt SalesAmount for et utvalg produktsjefer, må for eksempel først finne hvilke produkter om ble administrert av disse produktsjefene. Denne sekvensen må skje før visualobjektet sender en SQL-spørring som inneholder alle produkt-ID-ene i en WHERE-setning.

  • En SQL-spørring som sender spørringer på et lavere nivå av tetthet, hvor dataene senere aggregeres lokalt: Etter som antallet produkter som oppfyller filtervilkårene på produktsjef, vokser, kan det bli lite effektivt eller umulig å inkludere alle produktene i en WHERE-setning. Du kan i stedet spørre relasjonskilden på et lavere nivå for Produkter og deretter aggregere resultatene lokalt. Hvis kardinaliteten til produkter overskrider en grense på 1 million, mislykkes spørringen.

  • Flere SQL-spørringer, én per gruppe etter verdi: Når aggregeringen bruker DistinctCount og grupperes etter en kolonne fra en annen kilde, og hvis den eksterne kilden ikke støtter effektiv overføring av mange litterale verdier som definerer gruppen, er det nødvendig å sende én SQL-spørring per gruppe etter verdi.

    Et visualobjekt som spør etter en bestemt telling av CustomerAccountNumber (fra SQL Server-tabellen) etter produktsjefer importert fra regnearket, må hente inn detaljene fra produktsjefer-tabellen i spørringen som ble sendt til SQL Server. Denne handlingen er umulig over andre kilder, for eksempel Redshift. Det blir i stedet sendt én SQL-spørring per salgssjef, opptil en praktisk grense der spørringen ville mislykkes.

Hvert av disse tilfellene har sine egne konsekvenser for ytelsen, og nøyaktige detaljer varierer for hver datakilde. Selv om kardinaliteten til kolonnene som brukes i relasjonen som forbinder de to kildene, forblir lav, et par tusen, skal det ikke gå ut over ytelsen. Når denne kardinaliteten vokser, må du vie mer oppmerksom til innvirkningen på ytelsen.

I tillegg til dette betyr bruken av mange-til-mange-relasjoner at separate spørringer må sendes til den underliggende kilden for hvert nivå av totalsum eller delsum, i stedet for at de detaljerte verdiene aggregeres lokalt. Et enkelt visualobjekt for en tabell med totalsummer ville sende to SQL-spørringer i stedet for én.

Begrensninger og viktige hensyn

Denne versjonen av sammensatte modeller har noen begrensninger:

For øyeblikket støttes trinnvis oppdatering for sammensatte modeller som kobles til SQL-, Oracle- og Teradata-datakilder.

De følgende Live Connect flerdimensjonale kildene kan ikke brukes med sammensatte modeller:

  • SAP HANA
  • SAP Business Warehouse
  • SQL Server Analysis Services
  • Power BI-datasett
  • Azure Analysis Services

Når du kobler til disse flerdimensjonale kildene ved hjelp av DirectQuery, kan du verken koble til en annen DirectQuery-kilde eller kombinere den med importerte data.

De eksisterende begrensningene til DirectQuery gjelder fortsatt når du bruker sammensatte modeller. Mange av disse begrensningene gjelder nå per tabell, avhengig av lagringsmodusen til tabellen. En beregnet kolonne i en importert tabell kan for eksempel referere til andre tabeller, men en beregnet kolonne i en DirectQuery-tabell kan fremdeles bare referere til kolonner i samme tabell. Andre begrensninger gjelder for modellen som en helhet, hvis noen av tabellene i modellen er av typen DirectQuery. QuickInsights-funksjonen er for eksempel ikke tilgjengelig på en modell hvis noen av tabellene har en lagringsmodus av typen DirectQuery.

Neste trinn

Hvis du vil ha mer informasjon om sammensatte modeller og DirectQuery, kan du se følgende artikler: