Bruk av sammensatte modeller i Power BI Desktop

Tidligere i Power BI Desktop, da du brukte en DirectQuery i en rapport, var ingen andre datatilkoblinger, enten DirectQuery eller import, tillatt for denne rapporten. Med sammensatte modeller fjernes denne begrensningen. En rapport kan sømløst inkludere datatilkoblinger fra mer enn én DirectQuery- eller importdatatilkobling, i hvilken som helst kombinasjon du velger.

Funksjonaliteten for 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. Disse kildegruppene kan være én eller flere DirectQuery-tilkoblinger og en importtilkobling, to eller flere DirectQuery-tilkoblinger eller en 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 fremgangsmåten fjerner krav for unike verdier i tabeller. Det fjerner også tidligere midlertidige løsninger, som for eksempel å introdusere nye tabeller bare for å etablere relasjoner. Hvis du vil ha mer informasjon, kan du se Bruke mange-mange-relasjoner i Power BI Desktop.

• Lagringsmodus: Nå kan du angi hvilke visualobjekter som spør etter serverdeldatakilder. Denne funksjonen bidrar til å forbedre ytelsen og redusere belastning på bakserveren. Tidligere startet selv enkle visualobjekter, for eksempel slicere, spørringer til serverdelkilder. Hvis du vil ha mer informasjon, kan du se Behandle lagringsmodus i Power BI Desktop.

Bruk sammensatte modeller

Med sammensatte modeller kan du koble til ulike typer datakilder når du bruker Power BI Desktop eller Power Bi-tjeneste. Du kan opprette 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 ha mer informasjon om DirectQuery, kan du se DirectQuery i Power BI.

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

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

Ved å bruke sammensatte modeller kan du for eksempel bygge en modell som kombinerer følgende typer data:

• Salgsdata fra et virksomhetsdatalager.
• Salgsmåldata fra en sql server-database for avdeling.
• Data importert fra et regneark.

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

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

Merk

I konteksten til sammensatte modeller er alle importerte tabeller effektivt én enkelt kilde, uavhengig av de faktiske underliggende datakildene.

Eksempel på en sammensatt modell

For et eksempel på en sammensatt modell kan du vurdere en rapport som kobler til et firmadatalager i SQL Server ved hjelp av DirectQuery. I dette tilfellet inneholder datalageret data fra salg etter land, kvartal og sykkel (produkt), som vist i illustrasjonen nedenfor:

På dette tidspunktet kan du bygge enkle visualobjekter ved hjelp av felt fra denne kilden. Bildet nedenfor viser totalt salg etter ProductName for et valgt kvartal.

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

Det kan være mulig å importere salgsdataene fra datalageret i stedet for å bruke DirectQuery. Salgsdataene kan deretter kombineres med dataene du importerte fra regnearket. Men denne tilnærmingen er urimelig, av grunnene som førte til å bruke DirectQuery i første omgang. Årsakene kan omfatte:

• En kombinasjon av sikkerhetsreglene som håndheves i den underliggende kilden.
• Behovet for å kunne vise de nyeste dataene.
• Den rene skalaen av dataene.

Her kommer sammensatte modeller inn. Sammensatte modeller lar deg koble til datalageret ved hjelp av DirectQuery og deretter bruke Hent data for flere kilder. I dette eksemplet etablerer vi først DirectQuery-tilkoblingen til firmadatalageret. Vi bruker Hent data, velger Excel og navigerer deretter til regnearket som inneholder de lokale dataene våre. Til slutt importerer vi regnearket som inneholder produktnavnene, den tilordnede salgssjefen og prioriteten.

I Felt-listen kan du se to tabeller: den opprinnelige sykkeltabellen fra SQL Server og en ny ProductManagers-tabell. Den nye tabellen inneholder dataene som er importert fra Excel.

På samme måte, i Relasjonsvisning i Power BI Desktop, ser vi nå en annen tabell kalt ProductManagers.

Vi må nå relatere disse tabellene til de andre tabellene i modellen. Som alltid oppretter vi en relasjon mellom sykkeltabellen fra SQL Server og den importerte ProductManagers-tabellen. Dette er forholdet mellom Bike[ProductName] og ProductManagers[ProductName]. Som beskrevet tidligere, alle relasjoner som går over kildestandard til mange-til-mange kardinalitet.

Nå som vi har etablert denne relasjonen, vises den i Relasjon-visningen i Power BI Desktop, som vi forventer.

Vi kan nå opprette visualobjekter ved hjelp av alle feltene i Felter-listen . Denne tilnærmingen blander sømløst data fra flere kilder. Total SalesAmount for hver produktsjef vises for eksempel i følgende bilde:

Følgende eksempel viser et vanlig tilfelle av en dimensjonstabell , for eksempel Produkt eller Kunde, som er utvidet med noen ekstra data importert fra et annet sted. Det er også mulig å få tabeller til å bruke DirectQuery til å koble til ulike kilder. Hvis du vil fortsette med eksemplet vårt, kan du se for deg at salgsmål per land og periode lagres i en egen avdelingsdatabase. Som vanlig kan du bruke Hent data til å koble til disse dataene, som vist på følgende bilde:

Som vi gjorde tidligere, kan vi opprette relasjoner mellom den nye tabellen og andre tabeller i modellen. Deretter kan vi opprette visualobjekter som kombinerer tabelldataene. La oss se på relasjoner-visningen på nytt, der vi har opprettet de nye relasjonene:

Det neste bildet er basert på de nye dataene og relasjonene vi opprettet. Visualobjektet nederst til venstre viser totalt salgsbeløp kontra mål, og variansberegningen viser forskjellen. Salgsbeløpet og måldataene kommer fra to forskjellige SQL Server-databaser.

Angi lagringsmodus

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

Lagringsmodusen kan også vises på verktøytipset for hver tabell.

For alle Power BI Desktop-filer (en PBIX-fil ) som inneholder noen tabeller fra DirectQuery og noen importtabeller, viser statuslinjen en lagringsmodus kalt Blandet. Du kan velge termen på statuslinjen og enkelt bytte alle tabeller til import.

Hvis du vil ha mer informasjon om lagringsmodus, kan du se Behandle lagringsmodus i Power BI Desktop.

Merk

Du kan bruke blandet lagringsmodus i Power BI Desktop og i Power Bi-tjeneste.

Beregnede tabeller

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

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

Viktig

Beregnede tabeller støttes ikke i Power Bi-tjeneste ved hjelp av denne funksjonen med mindre du oppfyller spesifikke krav. Hvis du vil ha mer informasjon om dette, kan du se delen Arbeide med en sammensatt modell basert på en semantisk modell i denne artikkelen.

Sikkerhetsimplikasjoner

Sammensatte modeller har noen sikkerhetsimplikasjoner. En spørring som sendes til én datakilde, kan inneholde dataverdier som er hentet fra en annen kilde. I det tidligere eksemplet sender visualobjektet som viser (Salgsbeløp) av Produktsjef , en SQL-spørring til relasjonsdatabasen Salg. Sql-spørringen kan inneholde navnene på produktledere og tilknyttede produkter.

Så informasjonen som er lagret i regnearket, er nå inkludert i en spørring som sendes til relasjonsdatabasen. Hvis denne informasjonen er konfidensiell, bør du vurdere sikkerhetsimplikasjonene. Vurder spesielt følgende punkter:

• Enhver administrator av databasen som kan vise sporinger eller overvåkingslogger, kan vise denne informasjonen, selv uten tillatelser til dataene i den opprinnelige kilden. I dette eksemplet trenger administratoren tillatelser til Excel-filen.

• Krypteringsinnstillingene for hver kilde bør vurderes. Du vil unngå å hente informasjon fra én kilde ved en kryptert tilkobling og deretter utilsiktet inkludere den i en spørring som sendes til en annen kilde ved en ukryptert tilkobling.

Hvis du vil tillate bekreftelse på at du har vurdert eventuelle sikkerhetsimplikasjoner, viser Power BI Desktop en advarsel når du oppretter en sammensatt modell.

Hvis en forfatter legger til Tabell1 fra modell A i en sammensatt modell (la oss kalle det Modell C for referanse), kan en bruker som viser en rapport som er bygd på modell C, spørre en tabell i modell A som ikke er beskyttet av sikkerhet på radnivå RLS.

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

Ytelsesimplikasjoner

Når du bruker DirectQuery, bør du alltid vurdere ytelse, først og fremst for å sikre at serverdelkilden har tilstrekkelige ressurser til å gi brukerne en god opplevelse. En god opplevelse betyr at visualobjektene oppdateres om fem sekunder eller mindre. Hvis du vil ha mer informasjon om ytelse, kan du se DirectQuery i Power BI.

Bruk av sammensatte modeller legger til andre ytelseshensyn. Et enkelt visualobjekt kan resultere i å sende spørringer til flere kilder, som ofte sender resultatene fra én spørring over til en annen kilde. Denne situasjonen kan resultere i følgende former for kjøring:

• En kildespørring som inneholder et stort antall litterale verdier: Et visualobjekt som for eksempel ber om totalt salgsbeløp for et sett med valgte produktsjefer, må først finne ut hvilke produkter som 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 setning WHERE .

• En kildespørring som spør på et lavere nivå av detaljnivå, der dataene senere aggregeres lokalt: Etter hvert som antall produkter som oppfyller filterkriteriene i Produktsjef , blir stort, kan det bli ineffektivt eller umulig å inkludere alle produkter i en WHERE setningsdel. I stedet kan du spørre relasjonskilden på det lavere nivået av produkter og deretter aggregere resultatene lokalt. Hvis kardinaliteten for produkter overskrider en grense på 1 million, mislykkes spørringen.

• Flere kildespørringer, én per gruppe etter verdi: Når aggregasjonen 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 grupperingen, er det nødvendig å sende én SQL-spørring per gruppe etter verdi.

  Et visualobjekt som ber om et distinkt antall CustomerAccountNumber fra SQL Server-tabellen av produktledere importert fra regnearket, må sende inn detaljene fra tabellen Produktsjefer i spørringen som sendes til SQL Server. Over andre kilder, Redshift, for eksempel, er denne handlingen umulig. I stedet vil det være én SQL-spørring som sendes per Salgssjef, opptil en praktisk grense, og da vil spørringen mislykkes.

Hvert av disse tilfellene har sine egne konsekvenser for ytelsen, og de nøyaktige detaljene varierer for hver datakilde. Selv om kardinaliteten for kolonnene som brukes i relasjonen som føyer sammen de to kildene, forblir lav, noen få tusen, bør ikke ytelsen påvirkes. Etter hvert som kardinaliteten vokser, bør du være mer oppmerksom på innvirkningen på den resulterende ytelsen.

I tillegg betyr bruken av mange-til-mange-relasjoner at separate spørringer må sendes til den underliggende kilden for hvert total- eller delsumnivå, i stedet for å aggregere de detaljerte verdiene lokalt. Et enkelt tabellvisualobjekt med totaler sender to kildespørringer i stedet for én.

Kildegrupper

En kildegruppe er en samling elementer, for eksempel tabeller og relasjoner, fra en DirectQuery-kilde eller alle importkilder som er involvert i en datamodell. En sammensatt modell er laget av én eller flere kildegrupper. Tenk deg følgende eksempler:

• En sammensatt modell som kobler til en Semantisk Power BI-modell kalt Salg og beriker den semantiske modellen ved å legge til et Salg YTD-mål , som ikke er tilgjengelig i den opprinnelige semantiske modellen. Denne modellen består av én kildegruppe.
• En sammensatt modell som kombinerer data ved å importere en tabell fra et Excel-ark kalt Mål og en CSV-fil kalt Områder, og lage en DirectQuery-tilkobling til en Semantisk Power BI-modell kalt Salg. I dette tilfellet er det to kildegrupper som vist i følgende bilde:
  • Den første kildegruppen inneholder tabellene fra Mål-Excel-arket og Område-CSV-filen .
  • Den andre kildegruppen inneholder elementene fra semantisk salgsmodell for Power BI.

Hvis du har lagt til en annen DirectQuery-tilkobling til en annen kilde, for eksempel en DirectQuery-tilkobling til en SQL Server-database kalt Inventory, legges elementene fra denne kilden til en annen kildegruppe:

Merk

Import av data fra en annen kilde legger ikke til en annen kildegruppe, fordi alle elementer fra alle importerte kilder er i én kildegruppe.

Kildegrupper og relasjoner

Det finnes to typer relasjoner i en sammensatt modell:

• Intrakildegrupperelasjoner. Disse relasjonene relaterer elementer i en kildegruppe sammen. Disse relasjonene er alltid vanlige relasjoner med mindre de er mange-til-mange, i så fall er de begrenset.
• Relasjoner på tvers av kildegrupper. Disse relasjonene starter i én kildegruppe og slutter i en annen kildegruppe. Disse relasjonene er alltid begrensede relasjoner.

Les mer om skillet mellom vanlige og begrensede relasjoner og deres innvirkning.

I bildet nedenfor la vi for eksempel til tre grupperelasjoner på tvers av kilder, relatert tabeller på tvers av de ulike kildegruppene sammen:

Lokal og ekstern

Alle elementer som er i en kildegruppe som er en DirectQuery-kildegruppe, betraktes som eksterne, med mindre elementet ble definert lokalt som en del av en utvidelse eller berikelse av DirectQuery-kilden og ikke er en del av den eksterne kilden, for eksempel et mål eller en beregnet tabell. En beregnet tabell basert på en tabell fra DirectQuery-kildegruppen tilhører kildegruppen Importer og regnes som lokal. Alle elementer som er i kildegruppen Importer, regnes som lokale. Hvis du for eksempel definerer følgende mål i en sammensatt modell som bruker en DirectQuery-tilkobling til lagerkilden, anses målet som lokalt:

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

Beregningsgrupper, spørring og målevaluering

Beregningsgrupper gir en måte å redusere antall overflødige mål og gruppere vanlige måluttrykk sammen. Vanlige brukstilfeller er tidsintelligensberegninger der du vil kunne bytte fra faktiske data til måned-til-dato-, kvartal-til-dato- eller hittil i år-beregninger. Når du arbeider med sammensatte modeller, er det viktig å være oppmerksom på samhandlingen mellom beregningsgrupper og om et mål bare refererer til elementer fra én enkelt ekstern kildegruppe. Hvis et mål bare refererer til elementer fra én enkelt ekstern kildegruppe, og den eksterne modellen definerer en beregningsgruppe som påvirker målet, brukes beregningsgruppen, selv om målet ble definert i den eksterne modellen eller i den lokale modellen. Hvis et mål imidlertid ikke refererer til elementer fra én enkelt ekstern kildegruppe, men refererer til elementer fra en ekstern kildegruppe som en ekstern beregningsgruppe brukes på, kan resultatene av målet fortsatt bli påvirket av den eksterne beregningsgruppen. Vurder følgende eksempel:

• Forhandlersalg er et mål som er definert i den eksterne modellen.
• Den eksterne modellen inneholder en beregningsgruppe som endrer resultatet av Forhandlersalg
• Internett-salg er et mål som er definert i den lokale modellen.
• Totalt salg er et mål definert i den lokale modellen, og har følgende definisjon:

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

I dette scenarioet påvirkes ikke Internett-salgsmålet av beregningsgruppen som er definert i den eksterne modellen, fordi de ikke er en del av samme modell. Beregningsgruppen kan imidlertid endre resultatet av mål for forhandlersalg , fordi de er i samme modell. Dette faktum betyr at resultatene som returneres av totalsalgsmålet , må evalueres nøye. Tenk deg at vi bruker beregningsgruppen i den eksterne modellen til å returnere resultater hittil i år. Resultatet som returneres av Forhandlersalg , er nå en hittil i år-verdi, mens resultatet som returneres av Internett-salg fortsatt er faktisk. Resultatet av totalt salg er nå sannsynligvis uventet, da det legger til et faktisk resultat fra år til dato.

Sammensatte modeller på Semantiske Modeller for Power BI og Analysis Services

Ved hjelp av sammensatte modeller med Semantiske Modeller for Power BI og Analysis Services, kan du bygge en sammensatt modell ved hjelp av en DirectQuery-tilkobling for å koble til Semantiske Modeller for Power BI, Azure Analysis Services (AAS) og SQL Server 2022 Analysis Services. Ved hjelp av en sammensatt modell kan du kombinere dataene i disse kildene med andre DirectQuery og importerte data. Rapportforfattere som ønsker å kombinere dataene fra sin semantiske virksomhetsmodell med andre data de eier, for eksempel et Excel-regneark, eller ønsker å tilpasse eller berike metadataene fra sin semantiske virksomhetsmodell, vil finne denne funksjonaliteten spesielt nyttig.

Administrere sammensatte modeller på Semantiske Modeller for Power BI

Hvis du vil aktivere oppretting og forbruk av sammensatte modeller på Semantiske Power BI-modeller, må tenanten ha følgende brytere aktivert:

• Tillat XMLA-endepunkter og Analyser i Excel med lokale semantiske modeller. Hvis denne bryteren deaktiveres, kan ikke en DirectQuery-tilkobling til en semantisk Power BI-modell utføres.
• Brukere kan arbeide med semantiske Power BI-modeller i Excel ved hjelp av en live-tilkobling. Hvis denne bryteren er deaktivert, kan ikke brukere foreta live-tilkoblinger til Semantiske Power BI-modeller, slik at knappen Gjør endringer i denne modellen ikke kan nås.
• Tillat DirectQuery-tilkobling til semantiske Modeller for Power BI. Se avsnittene nedenfor for mer informasjon om denne bryteren og effekten av å deaktivere den.

I tillegg, for Premium-kapasiteter og Premium per bruker , bør innstillingen «XMLA-endepunkt» aktiveres og angis til enten Skrivebeskyttet eller Lese/skrive.

Leieradministratorer kan aktivere eller deaktivere DirectQuery-tilkoblinger til Semantiske Power BI-modeller i administrasjonsportalen. Selv om dette er aktivert som standard, stopper deaktivering av det brukere fra å publisere nye sammensatte modeller på Semantiske Power BI-modeller til tjenesten.

Eksisterende rapporter som bruker en sammensatt modell på en semantisk Power BI-modell, fortsetter å fungere, og brukere kan fortsatt opprette den sammensatte modellen ved hjelp av Desktop, men kan ikke publisere til tjenesten. I stedet, når du oppretter en DirectQuery-tilkobling til den semantiske Power BI-modellen ved å velge Gjør endringer i denne modellen , ser du følgende advarsel:

På denne måten kan du fortsatt utforske den semantiske modellen i det lokale Power BI Desktop-miljøet og opprette den sammensatte modellen. Du kan imidlertid ikke publisere rapporten til tjenesten. Når du publiserer rapporten og modellen, ser du at følgende feilmelding og publikasjon er blokkert:

Live-tilkoblinger til Semantiske Power BI-modeller påvirkes ikke av bryteren, og det er heller ikke live- eller DirectQuery-tilkoblinger til Analysis Services. Disse fortsetter å fungere uavhengig av om bryteren er slått av. Alle publiserte rapporter som bruker en sammensatt modell på en semantisk Power BI-modell, vil også fortsette å fungere selv om bryteren er slått av etter at de ble publisert.

Bygge en sammensatt modell på en semantisk modell eller modell

Hvis du bygger en sammensatt modell på en Semantisk Power BI-modell eller Analysis Services-modell, må rapporten ha en lokal modell. Du kan starte fra en live-tilkobling og legge til eller oppgradere til en lokal modell, eller starte med en DirectQuery-tilkobling eller importerte data, som automatisk oppretter en lokal modell i rapporten.

Hvis du vil se hvilke tilkoblinger som brukes i modellen, kan du kontrollere statuslinjen nederst til høyre i Power BI Desktop. Hvis du bare er koblet til en Analysis Services-kilde, ser du en melding som følgende bilde:

Hvis du er koblet til en semantisk Power BI-modell, ser du en melding som forteller deg hvilken Semantisk Power BI-modell du er koblet til:

Hvis du vil tilpasse metadataene for felt i den direkte tilkoblede semantiske modellen, velger du Gjør endringer i denne modellen på statuslinjen. Du kan også velge Gjør endringer i denne modellknappen på båndet, som vist på bildet nedenfor. Gjør endringer i denne modellen i kategorien Modellering i rapportvisning. I modellvisning er knappen på Hjem-fanen.

Hvis du velger knappen, vises en dialogboks som bekrefter tillegg av en lokal modell. Velg Legg til en lokal modell for å aktivere oppretting av nye kolonner eller endring av metadata, for felt fra Semantiske Modeller for Power BI eller Analysis Services. Bildet nedenfor viser dialogboksen som vises.

Når du er koblet direkte til en Analysis Services-kilde, finnes det ingen lokal modell. Hvis du vil bruke DirectQuery for direkte tilkoblede kilder, for eksempel Semantiske Modeller for Power BI og Analysis Services, må du legge til en lokal modell i rapporten. Når du publiserer en rapport med en lokal modell til Power Bi-tjeneste, publiseres en semantisk modell for den lokale modellen en brønn.

Kjeding

Semantiske modeller og semantiske modeller som de er basert på danner en kjede. Med denne prosessen, kalt kjedering, kan du publisere en rapport og semantisk modell basert på andre semantiske Modeller for Power BI, en funksjon som tidligere ikke var mulig.

Tenk deg for eksempel at kollegaen din publiserer en Semantisk Power BI-modell kalt Salg og Budsjett basert på en Analysis Services-modell kalt Salg, og kombinerer den med et Excel-ark kalt Budsjett.

Når du publiserer en ny rapport (og semantisk modell) kalt Salg og Budsjett Europa basert på salg og budsjett Power BI semantisk modell publisert av kollegaen din, gjør noen ytterligere endringer eller utvidelser som du gjør det, legger du effektivt til en rapport og semantisk modell i en kjede av lengde tre, som startet med Sales Analysis Services-modellen, og slutter med semantisk modell for Salg og Budsjett Europa . Bildet nedenfor visualiserer denne kjedeprosessen.

Kjeden i det forrige bildet er av lengde tre, som er den maksimale lengden. Utvidelse utover en kjedelengde på tre støttes ikke, og resulterer i feil.

Tillatelser og lisensiering

Brukere som får tilgang til rapporter ved hjelp av en sammensatt modell, må ha riktige tillatelser til alle semantiske modeller og modeller i kjeden.

Eieren av den sammensatte modellen krever kompileringstillatelse på semantiske modeller som brukes som kilder, slik at andre brukere kan få tilgang til disse modellene på vegne av eieren. Oppretting av sammensatt modelltilkobling i Power BI Desktop eller redigering av rapporten i Power BI krever derfor kompileringstillatelser for semantiske modeller som brukes som kilder.

Brukere som viser rapporter ved hjelp av den sammensatte modellen, krever vanligvis lesetillatelser for selve den sammensatte modellen og de semantiske modellene som brukes som kilder. Byggetillatelser kan være nødvendige hvis rapportene er i et Pro-arbeidsområde. Disse leierbryterne må være aktivert for brukeren.

De nødvendige tillatelsene kan illustreres med følgende eksempel:

• Sammensatt modell A (eid av eier A)

  • Datakilde A1: Semantisk modell B.
    Eier A må ha kompileringstillatelse på semantisk modell B for at brukere skal kunne vise rapporten ved hjelp av sammensatt modell A.

• Sammensatt modell C (eid av eier C)

  • Datakilde C1: Semantisk modell D
    Eier C må ha kompileringstillatelse på semantisk modell D for at brukere skal kunne vise rapporten ved hjelp av sammensatt modell C.
  • Datakilde C2: Sammensatt modell A
    Eier C må ha kompileringstillatelse på komposittmodell A og lesetillatelse på semantisk modell B.

En bruker som viser rapporter ved hjelp av sammensatt modell A , må ha lesetillatelser for både sammensatt modell A og semantisk modell B, mens en bruker som viser rapporter ved hjelp av sammensatt modell C , må ha lesetillatelser på sammensatt modell C, semantisk modell D, sammensatt modell A og semantisk modell B.

Merk

Se dette blogginnlegget for viktig informasjon om tillatelser som kreves for sammensatte modeller på Semantiske Modeller for Power BI og Analysis Services-modeller.

Hvis et datasett i kjeden er i et Premium per bruker-arbeidsområde, trenger brukeren tilgang til en Premium per bruker-lisens. Hvis et datasett i kjeden er i et Pro-arbeidsområde, trenger brukeren tilgang til den en Pro-lisens. Hvis alle datasettene i kjeden er på Premium-kapasiteter eller Fabric F64 eller større kapasitet, kan en bruker få tilgang til det ved hjelp av en gratislisens.

Sikkerhetsadvarsel

Hvis du bruker funksjonen Sammensatte modeller på semantiske Modeller for Power BI og Analysis Services-modeller , får du en dialogboks for sikkerhetsadvarsel, som vises i bildet nedenfor.

Data kan overføres fra én datakilde til en annen, som er den samme sikkerhetsadvarselen for å kombinere DirectQuery og importere kilder i en datamodell. Hvis du vil lære mer om denne virkemåten, kan du se bruke sammensatte modeller i Power BI Desktop.

Scenarier som støttes

Du kan bygge sammensatte modeller ved hjelp av data fra Semantiske Modeller for Power BI eller Analysis Services-modeller for å betjene følgende scenarioer:

• Koble til data fra ulike kilder: Importer (for eksempel filer), Semantiske Modeller for Power BI, Analysis Services-modeller
• Opprette relasjoner mellom ulike datakilder
• Skrive mål som bruker felt fra ulike datakilder
• Opprette nye kolonner for tabeller fra Semantiske Modeller for Power BI eller Analysis Services-modeller
• Opprette visualobjekter som bruker kolonner fra ulike datakilder
• Du kan fjerne en tabell fra modellen ved hjelp av feltlisten for å holde modellene så konsise og lene seg som mulig (hvis du kobler til et perspektiv, kan du ikke fjerne tabeller fra modellen)
• Du kan angi hvilke tabeller som skal lastes inn, i stedet for å måtte laste inn alle tabeller når du bare vil ha et bestemt delsett med tabeller. Se Laste inn et delsett med tabeller senere i dette dokumentet.
• Du kan angi om du vil legge til tabeller som senere legges til i den semantiske modellen etter at du har opprettet tilkoblingen i modellen.

Arbeide med en sammensatt modell basert på en semantisk modell

Når du arbeider med DirectQuery for Power BI semantiske modeller og Analysis Services, bør du vurdere følgende informasjon:

• Hvis du oppdaterer datakildene, og det er feil med motstridende felt- eller tabellnavn, løser Power BI feilene for deg.

• Du kan ikke redigere, slette eller opprette nye relasjoner i samme semantiske Power BI-modell eller Analysis Services-kilde. Hvis du har redigeringstilgang til disse kildene, kan du gjøre endringene direkte i datakilden i stedet.

• Du kan ikke endre datatyper av kolonner som lastes inn fra en semantisk Power BI-modell eller Analysis Services-kilde. Hvis du må endre datatypen, endrer du den i kilden eller bruker en beregnet kolonne.

• Hvis du vil bygge rapporter i Power Bi-tjeneste på en sammensatt modell basert på en annen semantisk modell, må all legitimasjon angis.

• Tilkoblinger til en lokal SQL Server 2022- og senere Analysis Services-server eller IAAS krever en lokal datagateway (standardmodus).

• Alle tilkoblinger til eksterne Power BI-semantiske modeller gjøres ved hjelp av enkel pålogging. Godkjenning med en tjenestekontohaver støttes for øyeblikket ikke.

• RLS-regler brukes på kilden de er definert for, men brukes ikke på andre semantiske modeller i modellen. RLS som er definert i rapporten, brukes ikke på eksterne kilder, og RLS som er angitt på eksterne kilder, brukes ikke på andre datakilder. Du kan heller ikke definere RLS i en tabell som lastes inn fra en ekstern kilde, og RLS som er definert i lokale tabeller, filtrerer ikke noen tabeller som er lastet inn fra en ekstern kilde.

• KPI-er, sikkerhet på radnivå og oversettelser importeres ikke fra kilden.

• Det kan hende du ser en uventet virkemåte når du bruker et datohierarki. Du kan løse dette problemet ved å bruke en datokolonne i stedet. Når du har lagt til et datohierarki i et visualobjekt, kan du bytte til en datokolonne ved å klikke på pil ned i feltnavnet og deretter klikke på navnet på feltet i stedet for å bruke Datohierarki:

  

  Hvis du vil ha mer informasjon om hvordan du bruker datokolonner kontra datohierarkier, kan du se bruke automatisk dato eller klokkeslett i Power BI Desktop.

• Maksimal lengde på en kjede av modeller er tre. Utvidelse utover kjedelengden på tre støttes ikke, og resulterer i feil.

• Et motløs kjedeflagg kan angis på en modell for å hindre at en kjede opprettes eller utvides. Hvis du vil ha mer informasjon, kan du se Administrere DirectQuery-tilkoblinger til en publisert semantisk modell.

• Tilkoblingen til en semantisk Power BI-modell eller Analysis Services-modell vises ikke i Power Query.

Følgende begrensninger gjelder når du arbeider med DirectQuery for Semantiske Modeller og Analysis Services for Power BI:

• Parametere for database- og servernavn er deaktivert.
• Definering av RLS på tabeller fra en ekstern kilde støttes ikke.
• Bruk av følgende kilder som DirectQuery-kilde støttes ikke:
  • SQL Server Analysis Services (SSAS) tabellmodeller før versjon 2022
  • Flerdimensjonale SSAS-modeller
  • SAP HANA
  • SAP Business Warehouse
  • Semantiske modeller i sanntid
  • Eksempel på semantiske modeller
  • Excel Online-oppdatering
  • Data importert fra Excel- eller CSV-filer på tjenesten
  • Bruksmetrikk
  • Semantiske modeller lagret i Mitt arbeidsområde
• Bruk av Power BI Embedded med semantiske modeller som inkluderer en DirectQuery-tilkobling til en Analysis Services-modell, støttes for øyeblikket ikke.
• Publisering av en rapport på nettet ved hjelp av funksjonen publiser til nett støttes ikke.
• Beregningsgrupper på eksterne kilder støttes ikke, med udefinerte spørringsresultater.

• Beregnede tabeller og beregnede kolonner som refererer til en DirectQuery-tabell fra en datakilde med enkel pålogging (SSO)-godkjenning, støttes i Power Bi-tjeneste med en tilordnet delbar skytilkobling og / eller detaljert tilgangskontroll.

• Hvis du gir nytt navn til et arbeidsområde etter at DirectQuery-tilkoblingen er konfigurert, må du oppdatere datakilden i Power BI Desktop for at rapporten skal fortsette å fungere.
• Automatisk sideoppdatering (APR) støttes bare for enkelte scenarioer, avhengig av datakildetypen. Hvis du vil ha mer informasjon, kan du se Automatisk sideoppdatering i Power BI.
• Overta en semantisk modell som bruker DirectQuery til andre semantiske modeller-funksjonen , støttes for øyeblikket ikke.
• Som med alle DirectQuery-datakilder vises ikke hierarkier som er definert i en Analysis Services-modell eller Power BI-semantisk modell når du kobler til modellen eller semantisk modell i DirectQuery-modus ved hjelp av Excel.

Det finnes noen andre ting du bør vurdere når du arbeider med Semantiske modeller og Analysis Services for DirectQuery for Power BI:

• Bruk kolonner med lav kardinalitet i grupperelasjoner på tvers av kilder: Når du oppretter en relasjon på tvers av to forskjellige kildegrupper, bør kolonnene som deltar i relasjonen (også kalt sammenføyningskolonnene) ha lav kardinalitet, ideelt sett 50 000 eller mindre. Denne vurderingen gjelder for ikke-strengnøkkelkolonner. for strengnøkkelkolonner, kan du se følgende vurdering.
• Unngå å bruke store strengnøkkelkolonner i grupperelasjoner på tvers av kilder: Når du oppretter en grupperelasjon på tvers av kilder, unngår du å bruke store strengkolonner som relasjonskolonner, spesielt for kolonner som har større kardinalitet. Når du må bruke strengkolonner som relasjonskolonne, beregner du den forventede strenglengden for filteret ved å multiplisere kardinalitet (C) med gjennomsnittslengden for strengkolonnen (A). Kontroller at den forventede strenglengden er under 250 000, slik at A ∗ C < 250 000.

Hvis du vil ha mer informasjon og veiledning, kan du se veiledning for sammensatt modell.

Leierhensyn

Enhver modell med en DirectQuery-tilkobling til en semantisk Power BI-modell eller til Analysis Services må publiseres i samme leier, noe som er spesielt viktig når du får tilgang til en Semantisk Power BI-modell eller en Analysis Services-modell ved hjelp av B2B-gjesteidentiteter, som vist i diagrammet nedenfor. Se gjestebrukere som kan redigere og behandle innhold for å finne nettadressen til leieren for publisering.

Vurder følgende diagram. De nummererte trinnene i diagrammet er beskrevet i avsnitt som følger.

I diagrammet fungerer Ash med Contoso og får tilgang til data levert av Fabrikam. Med Power BI Desktop oppretter Ash en DirectQuery-tilkobling til en Analysis Services-modell som driftes i Fabrikams leier.

For å godkjenne bruker Ash en B2B-gjestebrukeridentitet (trinn 1 i diagrammet).

Hvis rapporten publiseres til Contosos Power Bi-tjeneste (trinn 2), kan ikke den semantiske modellen publisert i Contoso-leieren godkjennes mot Fabrikams Analysis Services-modell (trinn 3). Rapporten fungerer derfor ikke.

I dette scenarioet, siden Analysis Services-modellen som brukes, driftes i Fabrikams leier, må rapporten også publiseres i Fabrikams leier. Etter vellykket publisering i Fabrikams leier (trinn 4), kan den semantiske modellen få tilgang til Analysis Services-modellen (trinn 5) og rapporten fungerer som den skal.

Arbeide med sikkerhet på objektnivå

Når en sammensatt modell henter data fra en Semantisk Power BI-modell eller Analysis Services via DirectQuery, og denne kildemodellen er sikret av sikkerhet på objektnivå, kan det hende at forbrukere av den sammensatte modellen legger merke til uventede resultater. Avsnittet nedenfor forklarer hvordan disse resultatene kan komme.

Sikkerhet på objektnivå (OLS) gjør det mulig for modellforfattere å skjule objekter som utgjør modellskjemaet (det vil si tabeller, kolonner, metadata osv.) fra modellforbrukere (for eksempel en rapportbygger eller en sammensatt modellforfatter). Når du konfigurerer OLS for et objekt, oppretter modellforfatteren en rolle, og fjerner deretter tilgangen til objektet for brukere som er tilordnet denne rollen. Fra disse brukernes synspunkt finnes det skjulte objektet ganske enkelt ikke.

OLS er definert for og brukt på kildemodellen. Den kan ikke defineres for en sammensatt modell som er bygd på kildemodellen.

Når en sammensatt modell bygges oppå en OLS-beskyttet Power BI-semantisk modell eller Analysis Services-modell via DirectQuery-tilkobling, kopieres modellskjemaet fra kildemodellen over til den sammensatte modellen. Hva som kopieres, avhenger av hva forfatteren av den sammensatte modellen har tillatelse til å se i kildemodellen i henhold til OLS-reglene som gjelder der. Dataene kopieres ikke over til den sammensatte modellen – i stedet hentes de alltid via DirectQuery fra kildemodellen ved behov. Datahenting kommer med andre ord alltid tilbake til kildemodellen, der OLS-regler gjelder.

Siden den sammensatte modellen ikke er sikret av OLS-regler, er objektene som forbrukere av den sammensatte modellen ser, de som forfatteren av den sammensatte modellen kan se i kildemodellen i stedet for hva de selv kan ha tilgang til. Dette kan føre til følgende situasjoner:

• Noen som ser på den sammensatte modellen, kan se objekter som er skjult for dem i kildemodellen av OLS.
• De kan derimot IKKE se et objekt i den sammensatte modellen som de kan se i kildemodellen, fordi objektet ble skjult for den sammensatte modellforfatteren av OLS-reglene som kontrollerer tilgangen til kildemodellen.

Et viktig poeng er at til tross for saken som er beskrevet i det første punktet, ser forbrukere av den sammensatte modellen aldri faktiske data de ikke skal se, fordi dataene ikke er plassert i den sammensatte modellen. I stedet, på grunn av DirectQuery, hentes den etter behov fra kildesemantisk modell, der OLS blokkerer uautorisert tilgang.

Med denne bakgrunnen i tankene kan du vurdere følgende scenario:

1. Admin_user publiserte en semantisk organisasjonsmodell ved hjelp av en Semantisk Power BI-modell eller en Analysis Services-modell som har en kundetabell og en distriktstabell. Admin_user publiserer den semantiske modellen til Power Bi-tjeneste og angir OLS-regler som har følgende effekt:

   • Finansbrukere kan ikke se Kunde-tabellen
   • Markedsføringsbrukere kan ikke se distriktstabellen

2. Finance_user publiserer en semantisk modell kalt "Finance semantic model" og en rapport kalt "Finance report" som kobles via DirectQuery til foretakssemantisk modell publisert i trinn 1. Finansrapporten inneholder et visualobjekt som bruker en kolonne fra distriktstabellen.

3. Marketing_user åpner finansrapporten. Visualobjektet som bruker distriktstabellen, vises, men returnerer en feil, fordi når rapporten åpnes, prøver DirectQuery å hente dataene fra kildemodellen ved hjelp av legitimasjonen til Marketing_user, som er blokkert fra å se distriktstabellen i henhold til OLS-reglene som er angitt i foretakssemantisk modell.

4. Marketing_user oppretter en ny rapport kalt «Markedsføringsrapport» som bruker semantisk finansmodell som kilde. Feltlisten viser tabellene og kolonnene som Finance_user har tilgang til. Distrikt-tabellen vises derfor i feltlisten, men kundetabellen er ikke det. Men når Marketing_user prøver å opprette et visualobjekt som bruker en kolonne fra distriktstabellen, returneres en feil, fordi DirectQuery på det tidspunktet prøver å hente data fra kildemodellen ved hjelp av legitimasjonen til Marketing_user, og OLS-regler sparker igjen inn og blokkerer tilgang. Det samme skjer når Marketing_user oppretter en ny semantisk modell og rapport som kobler til semantisk finansmodell med en DirectQuery-tilkobling – de ser distriktstabellen i feltlisten, siden det er det Finance_user kunne se, men når de prøver å opprette et visualobjekt som bruker denne tabellen, blokkeres de av OLS-reglene for semantisk virksomhetsmodell.

5. La oss nå si at Admin_user oppdaterer OLS-reglene på foretakssemantisk modell for å hindre finans i å se distriktstabellen.

6. De oppdaterte OLS-reglene gjenspeiles bare i semantisk finansmodell når den oppdateres. Når Finance_user oppdaterer semantisk finansmodell, vises ikke distriktstabellen lenger i feltlisten, og visualobjektet i finansrapporten som bruker en kolonne fra distriktstabellen, returnerer en feil for Finance_user, fordi de nå ikke har tilgang til distriktstabellen.

Slik oppsummerer du:

• Forbrukere av en sammensatt modell ser resultatene av OLS-reglene som var gjeldende for forfatteren av den sammensatte modellen da de opprettet modellen. Når en ny rapport opprettes basert på den sammensatte modellen, viser feltlisten derfor tabellene som forfatteren av den sammensatte modellen hadde tilgang til da de opprettet modellen, uavhengig av hva den gjeldende brukeren har tilgang til i kildemodellen.
• OLS-regler kan ikke defineres på selve den sammensatte modellen.
• En forbruker av en sammensatt modell vil aldri se faktiske data de ikke skal se, fordi relevante OLS-regler på kildemodellen blokkerer dem når DirectQuery prøver å hente dataene ved hjelp av legitimasjonen.
• Hvis kildemodellen oppdaterer OLS-reglene, påvirker disse endringene bare den sammensatte modellen når den oppdateres.

Laste inn et delsett av tabeller fra en Semantisk Power BI-modell eller Analysis Services-modell

Når du kobler til en Semantisk Power BI-modell eller Analysis Services-modell ved hjelp av en DirectQuery-tilkobling, kan du bestemme hvilke tabeller du vil koble til. Du kan også velge å legge til en tabell som kan legges til i semantisk modell eller modell automatisk etter at du har opprettet tilkoblingen til modellen. Når du kobler til et perspektiv, inneholder modellen alle tabeller i den semantiske modellen, og alle tabeller som ikke er inkludert i perspektivet, er skjult. Dessuten legges alle tabeller som kan legges til i perspektivet, automatisk. I Innstillinger-menyen kan du bestemme deg for å koble til tabeller som legges til semantisk modell automatisk etter at du har konfigurert tilkoblingen.

Denne dialogboksen vises ikke for live-tilkoblinger.

Merk

Denne dialogboksen vises bare hvis du legger til en DirectQuery-tilkobling i en Semantisk Power BI-modell eller Analysis Services-modell i en eksisterende modell. Du kan også åpne denne dialogboksen ved å endre DirectQuery-tilkoblingen til semantisk Power BI-modell eller Analysis Services-modell i datakildeinnstillingene etter at du opprettet den.

Konfigurere dedupliseringsregler

Du kan angi dedupliseringsregler for å holde mål- og tabellnavn unike i en sammensatt modell ved hjelp av Innstillinger-alternativet i dialogboksen som vises tidligere:

I det forrige eksemplet la vi til ' (markedsføring)' som et suffiks i en tabell eller et målnavn som er i konflikt med en annen kilde i den sammensatte modellen. Du kan gjøre følgende:

• skriv inn en tekst som skal legges til navnet på motstridende tabeller eller mål
• angi om du vil at teksten skal legges til i tabellen eller målnavnet som et prefiks eller et suffiks
• bruke dedupliseringsregelen på tabeller, mål eller begge deler
• Velg å bruke dedupliseringsregelen bare når en navnekonflikt oppstår, eller bruk den hele tiden. Standarden er å bruke regelen bare når duplisering forekommer. I vårt eksempel får ikke en tabell eller måling fra markedsføringskilden som ikke har et duplikat i salgskilden, en navneendring.

Når du har opprettet tilkoblingene og konfigurert dedupliseringsregelen, viser feltlisten både Kunde og Kunde (markedsføring) i henhold til dedupliseringsregelen som er konfigurert i eksemplet vårt:

Hvis du ikke angir en dedupliseringsregel, eller dedupliseringsreglene du har angitt, ikke løser navnekonflikten, brukes fortsatt standarddedupliseringsreglene. Standarddedupliseringsreglene legger til et tall i navnet på det motstridende elementet. Hvis det er en navnekonflikt i kundetabellen, får én av Kunde-tabellene navnet Kunde 2.

XMLA-endringer og sammensatte modeller

Når du endrer en semantisk modell ved hjelp av XMLA, må du oppdatere ChangedProperties og PBI_RemovedChildren samling for det endrede objektet for å inkludere eventuelle endrede eller fjernede egenskaper. Hvis du ikke utfører denne oppdateringen, kan Power BI-modelleringsverktøy overskrive eventuelle endringer neste gang skjemaet synkroniseres med tilhørende Lakehouse.

De støttede modellene for å endre en semantisk modell ved hjelp av XMLA er følgende:

• Gi nytt navn til tabell/kolonne (ChangeProperty = navn)
• Fjern tabell (legg til tabell i PBI_RemovedChildren merknad i spørringsuttrykket)

Hensyn og begrensninger

Sammensatte modeller presenterer noen hensyn og begrensninger:

Tilkoblinger i blandet modus – Når du bruker en blandet modustilkobling som inneholder nettbaserte data (for eksempel en Semantisk Power BI-modell) og en lokal semantisk modell (for eksempel en Excel-arbeidsbok), må du ha gatewaytilordning etablert for at visualobjekter skal vises riktig.

Trinnvis oppdatering støttes for øyeblikket bare for sammensatte modeller som kobler til SQL-, Oracle- og Teradata-datakilder.

Følgende live connect-tabellkilder kan ikke brukes med sammensatte modeller:

• SAP HANA
• SAP Business Warehouse
• SQL Server Analysis Services tidligere enn versjon 2022
• Bruksmåledata (Mitt arbeidsområde)

Bruk av semantiske modeller for strømming i sammensatte modeller støttes ikke.

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

Hvis du bruker sikkerhet på radnivå i en sammensatt modell med noen av tabellene i DirectQuery-modus, må du oppdatere modellen for å bruke nye oppdateringer fra DirectQuery-tabellene. Hvis for eksempel en Bruker-tabell i DirectQuery-modus har nye brukerposter i kilden, inkluderes de nye postene bare etter neste modelloppdatering. Power BI-tjenesten bufrer brukere-spørringen for å forbedre ytelsen og laster ikke inn dataene fra kilden på nytt før neste manuelle eller planlagte oppdatering.

Relatert innhold

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

• Bruke mange-til-mange-relasjoner i Power BI Desktop
• Behandle lagringsmodus i Power BI Desktop
• DirectQuery i Power BI
• Power BI-datakilder
• Modellrelasjoner i Power BI Desktop