Brug af DirectQuery til Power BI-datasæt og Azure Analysis Services (prøveversion)

Med DirectQuery til Power BI-datasæt og Azure Analysis Services (AAS) kan du bruge DirectQuery til at oprette forbindelse til AAS- eller Power BI-datasæt, og hvis du vil, kan du kombinere det med andre DirectQuery-data og importerede data. Rapportforfattere, der gerne vil kombinere dataene fra deres semantiske virksomhedsmodel med andre data, de ejer, f.eks. et Excel-regneark, eller som gerne vil tilpasse eller forbedre metadataene fra deres semantiske virksomhedsmodel, vil især synes, at denne funktion er nyttig.

Aktiver prøveversionsfunktionen

Da funktionaliteten i øjeblikket er en prøveversion, skal du først aktivere den. Det gør du ved at gå til Filer > Indstillinger > Indstillinger i Power BI Desktop og under afsnittet Prøveversionsfunktioner markere afkrydsningsfeltet DirectQuery til Power BI-datasæt og Analysis Services for at aktivere denne prøveversionsfunktion. Du skal måske genstarte Power BI Desktop, før ændringen træder i kraft.

Brug af DirectQuery til direkte forbindelser

Hvis du bruger DirectQuery til Power BI datasæt og Azure Analysis Services kræver det, at din rapport har en lokal model. Du kan starte fra en direkte forbindelse og tilføje eller opgradere til en lokal model, eller du kan starte med en DirectQuery-forbindelse eller importere 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 oprettet forbindelse til en Azure Analysis Services-kilde, får du vist en meddelelse, som ligner følgende billede:

Hvis du har forbindelse til et Power BI-datasæt, kan du se en meddelelse, der fortæller dig, hvilket Power BI-datasæt du har forbindelse til:

Hvis du vil tilpasse metadataene for felter i dit direkte forbundne datasæt, skal du vælge Foretag ændringer af denne model på statuslinjen. Alternativt kan du klikke på knappen Foretag ændringer af denne model på båndet, som vist på følgende billede. I Rapportvisning: knappen Foretag ændringer af denne model under fanen Udformning. I Modelvisning findes knappen under fanen Hjem.

Når du klikker på 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 Power BI-datasæt eller Azure Analysis Services. På følgende billede vises den dialogboks, der kommer frem.

Når du har oprettet en direkte forbindelse til en Analysis Services-kilde, er der ingen lokal model. Hvis du vil bruge DirectQuery til direkte forbundne kilder, f.eks Power BI-datasæt og Azure 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-tjenesten, publiceres der også et datasæt for denne lokale model.

Sammenkædning

Datasæt og de datasæt og modeller, de er baseret på, danner en kæde. Denne proces, der kaldes sammenkdning, gør det muligt at udgive en rapport og et datasæt, der er baseret på Power BI datasæt, hvilket ikke tidligere var muligt.

Forestil dig for eksempel, at dine kollegaer publicerer et Power BI-datasæt kaldet Salg og budget, der er baseret på en Azure Analysis Services-model kaldet Salg, og at de kombinerer det med et Excel-ark kaldet Budget.

Når du publicerer en ny rapport (og et datasæt) kaldet Salg og budget for Europa, der er baseret på Power BI-datasættet Salg og budget, som din kollega har publiceret, og du foretager yderligere ændringer eller udvidelser, mens du gør det, føjer du reelt set en rapport og et datasæt til en kæde bestående af tre led, som startede med Azure Analysis Services-modellen Salg og slutter med dit Power BI-datasæt Salg og budget for Europa. På følgende billede er denne sammenkædningsproces visualiseret.

Kæden på det forrige billede består af tre led, hvilket er den maksimale længde i denne prøveperiode. Udvidelse ud over en kædelængde på tre understøttes ikke og medfører fejl.

Sikkerhedsadvarsel

Hvis du bruger funktionen DirectQuery til Power BI-datasæt og Azure Analysis Services (AAS) , får du vist en dialogboks med en sikkerhedsadvarsel, som vist på følgende billede.

Data kan overføres fra én datakilde til en anden via push, hvilket er den samme sikkerhedsadvarsel som for at kombinere DirectQuery-kilder og importerede kilder i en datamodel. Hvis du vil vide mere om denne funktionsmåde, skal du se Brug af sammensatte modeller i Power BI Desktop.

Funktioner og scenarier, du kan prøve

Følgende liste indeholder forslag til, hvordan du selv kan udforske DirectQuery til Power BI-datasæt og Azure Analysis Services (AAS) :

• Oprettelse af forbindelse til data fra forskellige kilder: Import (f.eks. filer), Power BI-datasæt, Azure Analysis Services
• Oprettelse af relationer mellem forskellige datakilder
• Skrivning af målinger, der bruger felter fra forskellige datakilder
• Oprettelse af nye kolonner til tabeller fra Power BI-datasæt for Azure Analysis Services
• Oprettelse af visualiseringer, der bruger kolonner fra forskellige datakilder

Fra og med versionen af Power BI Desktop fra april 2021 kan du også oprette forbindelse til et perspektiv, når du opretter en DirectQuery-forbindelse til en Azure Analysis Services-model, hvis der er et tilgængeligt perspektiv.

Fra og med versionen af Power BI Desktop fra oktober 2021 har du større kontrol over dine forbindelser:

• Du kan fjerne en tabel fra modellen ved hjælp af feltlisten for at holde modellerne så præcise og tænkelige 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
• Du kan angive, om du vil tilføje tabeller, der efterfølgende føjes til datasættet, når du har forbindelsen i din model
• Med udgivelsen i oktober 2021 blev der foretaget forbedringer af ydeevnen med parallel udførelse af modelforespørgsler og smart cachelagring.

Overvejelser og begrænsninger

Der er nogle få overvejelser, man skal gøre, når man bruger DirectQuery til Power BI-datasæt og Azure Analysis Services (AAS) :

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

• Brugerne skal have tilladelsen "Opret" for alle datasæt i kæden for at få adgang til en rapport, der anvender denne funktion.

• Hvis du vil oprette rapporter i Power BI-tjenesten i en sammensat model, der er baseret på et andet datasæt, skal alle legitimationsoplysninger være angivet. På siden med indstillinger til opdatering af legitimationsoplysninger vises følgende fejl for Azure Analysis Services-kilder, selvom legitimationsoplysningerne er angivet:

  

• Da det er forvirrende og forkert, er det noget, vi snart tager os af.

• Hvis du vil oprette en DirectQuery-forbindelse til et Power BI-datasæt, skal "Tillad XMLA-slutpunkter og Analysér i Excel med datasæt i det lokale miljø" være aktiveret for din lejer.

• I forbindelse med Premium-kapaciteter skal "XMLA-slutpunktet" være indstillet til enten "Skrivebeskyttet" eller "Læs/Skriv".

• Hvis du bruger et klassisk arbejdsområde i kombination med denne funktion, er det ikke tilstrækkeligt at angive tilladelser til selve datasættet. I forbindelse med klassiske arbejdsområder skal alle brugere, der har adgang til rapporter, som udnytter denne funktion, være medlemmer af arbejdsområdet. Overvej at opgradere klassiske arbejdsområder til nye arbejdsområder for at undgå denne situation.

• Der anvendes regler for sikkerhed på rækkeniveau på den kilde, som de er defineret for, men de anvendes ikke på andre datasæt 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.

• KPI'er, sikkerhed på rækkeniveau og oversættelser importeres ikke fra kilden i denne prøveversion.

• Du oplever måske en uventet funktionsmåde, når du bruger et datohierarki. Du løser dette problem 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 i denne artikel.

• Du kan måske se unyttige fejlmeddelelser, når du bruger funktioner med kunstig intelligens i en model, der har en DirectQuery-forbindelse til Azure Analysis Services.

• Brug af ALLSELECTED med en DirectQuery-kilde resulterer i et ufuldstændigt resultat.

• Filtre og relationer:

  • Et filter, der anvendes fra en datakilde på en tabel fra en anden DirectQuery-kilde, kan kun angives for en enkelt kolonne

  • Det anbefales ikke at bruge krydsfiltrering af to tabeller i en DirectQuery-kilde ved at filtrere dem med en tabel uden for kilden, og det understøttes ikke.

  • Et filter kan kun berøre en tabel én gang. Anvendelse af det samme filter på en tabel to gange via en eller flere tabeller uden for DirectQuery-kilden understøttes ikke.

• I prøveperioden kan en kæde af modeller maksimalt bestå af tre led. Det er ikke muligt at forlænge kæden ud over tre led, og det medfører fejl.

• Et frarådes sammenkdningsflag kan angives på en model for at forhindre, at en kæde oprettes eller udvides. Du kan finde flere oplysninger under Administrer DirectQuery-forbindelser til et publiceret datasæt.

• Forbindelsen til et Power BI datasæt vises ikke i Power Query.

Der er også nogle få begrænsninger, du skal være opmærksom på:

• Parametre for database- og servernavne er deaktiveret i øjeblikket.

• Definition af sikkerhed på rækkeniveau på tabeller fra en ekstern kilde understøttes ikke.

• Brug af en af følgende kilder som en DirectQuery-kilde understøttes ikke:

  • SQL Server Analysis Services (SSAS)
  • SAP HANA
  • SAP Business Warehouse
  • Datasæt i realtid

• Brug af DirectQuery på datasæt fra "Mit arbejdsområde" understøttes ikke i øjeblikket.

• Brug af Power BI Embedded med datasæt, der indeholder en DirectQuery-forbindelse til et Power BI-datasæt eller en Azure Analysis Services model, understøttes ikke i øjeblikket.

• Beregningsgrupper på eksterne kilder understøttes ikke med udefinerede forespørgselsresultater.

• Beregnede tabeller understøttes ikke i tjenesten ved hjælp af denne funktion. Når du forsøger at udføre en opdatering af et datasæt med en beregnet tabel eller en beregnet kolonne, som refererer til en Direct Query-datakilde, resulterer det i fejlmeddelelsen "Enkelt logon (SSO) er ikke angivet".

• Automatisk sideopdatering understøttes kun i nogle scenarier, afhængigt af typen af datakilde. Se artiklen Automatisk sideopdatering i Power BI for at få flere oplysninger.

• Oversæt af et datasæt, der bruger DirectQuery til andre datasæt, understøttes ikke i øjeblikket.

• Som med alle DirectQuery-datakildervises hierarkier, der er defineret i en Azure Analysis Services-model eller et Power BI-datasæt, ikke, når der oprettes forbindelse til modellen eller datasættet i DirectQuery-tilstand ved hjælp af Excel.

Overvejelser i forbindelse med lejer

Alle modeller med en DirectQuery-forbindelse til et Power BI-datasæt eller til Azure Analysis Services skal publiceres i den samme lejer, hvilket er især vigtigt, når du får adgang til et Power BI-datasæt eller en Azure 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.

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

I diagrammet fungerer Ash sammen med Contoso og tilgår data, der leveres af Fabrikam. Med Power BI Desktop opretter Ash en DirectQuery-forbindelse til en Azure Analysis Services model, der hostes i Fabrikams lejer.

Til godkendelse bruger Ash en B2B-gæstebrugeridentitet (trin 1 i diagrammet).

Hvis rapporten er publiceret i Contosos Power BI-tjeneste (trin 2), kan det datasæt, der er publiceret i Contoso-lejeren, ikke godkende i forhold til Fabrikams Azure Analysis Services-model (trin 3). Rapporten vil derfor ikke fungere.

Da den anvendte Azure Analysis Services-model i dette scenarie hostes i Fabrikams lejer, skal rapporten også publiceres i Fabrikams lejer. Efter publicering i Fabrikams lejer (trin 4) kan datasættet få adgang til Azure Analysis Services model (trin 5), og rapporten fungerer korrekt.

Sammensatte modeller med DirectQuery-forbindelse til kildemodeller, der er beskyttet af sikkerhed på objektniveau

Når en sammensat model henter data fra et Power BI-datasæt eller Azure Analysis Services via DirectQuery, og denne kildemodel er beskyttet af sikkerhed på objektniveau, kan brugerne af den sammensatte model opleve uventede resultater. I det følgende afsnit forklares det, hvordan disse resultater kan komme frem.

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

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

Når en sammensat model er bygget oven på et OLS-beskyttet Power BI-datasæt eller en Azure Analysis Services-model via DirectQuery-forbindelsen, kopieres modelskemaet fra kildemodellen faktisk til den sammensatte model. Hvad, der kopieres, afhænger af, hvad forfatteren til 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 – de hentes i stedet altid via DirectQuery fra kildemodellen, når det er nødvendigt. Det vil sige, at datahentning altid vender tilbage til kildemodellen, hvor OLS-reglerne gælder.

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

• En person, der ser på den sammensatte model, får muligvis vist 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 objektet blev skjult for forfatteren af den sammensatte model af OLS-reglerne, der styrer adgangen til kildemodellen.

Et vigtigt punkt er, at når den første punkttegn beskrives, vil forbrugere af den sammensatte model aldrig se de faktiske data, som de ikke er klar til at se, da dataene faktisk ikke er placeret i den sammensatte model. På grund af DirectQuery hentes den i stedet efter behov fra kildedatasættet, hvor OLS blokerer for uautoriseret adgang.

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

1. Admin_user publiceret en semantisk model til virksomheder ved hjælp af et Power BI-datasæt eller en Azure Analysis Services-model, der har en kundetabel og en tabel med område. Admin_user datasættet publicerer til tjenesten Power BI og angiver OLS-regler, der har følgende effekt:

   • Økonomibrugere kan ikke se tabellen Kunde
   • Marketingbrugere kan ikke se tabellen Område

2. Finance_user et datasæt med navnet "Finance dataset" og en rapport med navnet "Finance report", der opretter forbindelse via DirectQuery til den semantiske virksomhedsmodel, som blev publiceret i trin 1. Finance-rapporten indeholder en visualisering, der bruger en kolonne fra tabellen Territory.

3. Marketing_user åbner økonomirapporten. Det visuelle element, 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, der ikke kan se tabellen Territory i henhold til de OLS-regler, der er angivet for den semantiske virksomhedsmodel.

4. Marketing_user opretter en ny rapport med navnet "Marketingrapport", der bruger Finance-datasættet som kilde. Feltlisten viser de tabeller og kolonner, som Finance_user har adgang til. Derfor vises tabellen Territory på feltlisten, men tabellen Customer er ikke. Når Marketing_user forsøger at oprette en visualisering, der udnytter en kolonne fra tabellen Territory, returneres der dog en fejl, fordi DirectQuery på det tidspunkt forsøger at hente data fra kildemodellen ved hjælp af Marketing_user's legitimationsoplysninger, og OLS-regler sparker igen ind og blokerer adgangen. Det samme sker, når Marketing_user opretter et nyt datasæt og en ny rapport, der opretter forbindelse til Finance-datasættet med en DirectQuery-forbindelse – de får vist tabellen Territory på listen over felter, da det er det, Finance_user kan se, men når de forsøger at oprette en visualisering, der udnytter denne tabel, blokeres de af OLS-reglerne på den semantiske virksomhedsmodel.

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

6. Kun når Finance-datasættet opdateres, afspejles de opdaterede OLS-regler i det. Det betyder, at når Finance_user opdaterer Finance-datasættet, vises tabellen Territory ikke længere på listen felter, og det visuelle element i finance-rapporten, der bruger en kolonne fra tabellen Territory, returnerer en fejl for Finance_user, da de nu ikke har adgang til tabellen Territory.

Opsummering:

• Brugerne 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 derfor 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 kan aldrig se de faktiske data, som vedkommende ikke er klar til at se, da relevante OLS-regler for 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æsning af et undersæt af tabeller fra Power BI datasæt eller en Azure Analysis Services model

Når du opretter forbindelse til et Power BI datasæt eller en Azure Analysis Services model ved hjælp af en DirectQuery-forbindelse, kan du bestemme, hvilke tabeller der skal oprettes forbindelse til. Du kan også vælge automatisk at tilføje en tabel, der føjes til datasættet eller modellen, når du har forbindelsen til din model. Bemærk, at når du opretter forbindelse til et perspektiv, indeholder din model alle tabeller i datasættet eller modellen, og alle tabeller, der ikke er inkluderet i perspektivet, skjules. Desuden tilføjes alle tabeller, der føjes til perspektivet, automatisk. Denne dialogboks vises ikke for direkte forbindelser.

[!div class="mx-imgBorder"]

Næste trin

Du kan finde flere oplysninger om DirectQuery i følgende ressourcer:

• Brug DirectQuery i Power BI Desktop
• DirectQuery-modeller i Power BI Desktop
• Vejledning til DirectQuery-model i Power BI Desktop
• Har du spørgsmål? Prøv at spørge Power BI-community'et