Power BI-forbrugsscenarier: Avanceret administration af datamodeller

Bemærk

Denne artikel er en del af power BI-implementeringsplanlægningsserierne. I denne serie fokuseres der primært på Power BI-oplevelsen i Microsoft Fabric. Du kan få en introduktion til serien under Planlægning af implementering af Power BI.

I dette forbrugsscenarie fokuseres der på administration af avancerede datamodeller, hvilket er, når en Power BI-indholdsopretter er afhængig af et tredjepartsværktøj til at udvikle, administrere eller optimere datamodeller. Nogle tredjepartsværktøjer er eksterne værktøjer, som Power BI Desktop understøtter direkte. Du kan også administrere en publiceret datamodel (semantisk model) ved at kommunikere direkte med XMLA-slutpunktet i Power BI-tjeneste.

Datamodeller hostes enten i Power BI-tjeneste, Azure Analysis Services (AAS) eller SQL Server Analysis Services (SSAS). I dette forbrugsscenarie fokuseres der på brugen af XMLA-slutpunktet i Power BI-tjeneste.

Tip

Mange mennesker refererer til tredjepartsværktøjer som eksterne værktøjer. Der skelnes dog mellem, hvordan forskellige værktøjer kan bruges. Oprettelse af forbindelse til en lokal datamodel i Power BI Desktop er den mest bogstavelige fortolkning af udtrykket eksternt værktøj. I dette scenarie for administration af avancerede datamodeller fokuseres der på at oprette forbindelse til en ekstern datamodel (en semantisk model, der hostes i Power BI-tjeneste) ved hjælp af XMLA-slutpunktet. Du kan finde flere oplysninger om de forskellige måder at bruge tredjepartsværktøjer på senere i denne artikel.

Du kan opnå forbindelse til en datamodel ved hjælp af XML for Analysis-protokollen (XML for Analysis). XMLA-protokollen er en branchestandardprotokol, der understøttes af mere end 25 leverandører, herunder Microsoft. Alle værktøjer, herunder tredjepartsværktøjer, der overholder XMLA-protokollen, bruger Microsoft-klientbiblioteker til at læse og/eller skrive data til en datamodel. Der opnås forbindelse med et XMLA-slutpunkt, som er en API, der eksponeres af en datamodel, der udvider de udviklings- og administrationsfunktioner, der er tilgængelige for semantiske modeloprettere.

Bemærk

Dette scenarie for administration af avancerede datamodeller er et af scenarierne til administration og udrulning af indhold. Du kan se en komplet liste over selvbetjeningsscenarier i Power BI-forbrugsscenarier.

Nogle aspekter, der er beskrevet i emnet om indholdssamarbejde og leveringsscenarier , beskrives ikke kort i denne artikel. Du kan få fuld dækning ved at læse disse artikler først.

Scenariediagram

I dette scenarie for administration af avancerede datamodeller fokuseres der på at bruge Tabular Editor til at administrere datamodellen. Du kan publicere en datamodel til Power BI-tjeneste ved hjælp af XMLA-slutpunktet, som er tilgængeligt med Power BI Premium.

Vigtigt

Denne artikel henviser til tider Power BI Premium eller dens kapacitetsabonnementer (P-SKU'er). Vær opmærksom på, at Microsoft i øjeblikket konsoliderer købsmuligheder og udfaser Power BI Premium pr. kapacitets-SKU'er. Nye og eksisterende kunder bør overveje at købe Fabric-kapacitetsabonnementer (F SKU'er) i stedet.

Du kan få flere oplysninger under Vigtige opdateringer, der kommer til Power BI Premium-licenser og Ofte stillede spørgsmål om Power BI Premium.

Tip

Vi anbefaler, at du gennemser forbrugsscenariet for publicering af indhold via selvbetjening, hvis du ikke kender det. Scenariet for administration af avancerede datamodeller bygger på dette scenarie.

Bemærk

Nogle gange bruges begreberne semantisk model og datamodel i flæng. Fra et Power BI-tjeneste perspektiv kaldes det generelt semantisk model. Fra et udviklingsperspektiv kaldes det for en datamodel (eller model for korte). I denne artikel har begge ord samme betydning. På samme måde har en semantisk modelopretter og en dataudformer den samme betydning.

I følgende diagram vises en oversigt på højt niveau over de mest almindelige brugerhandlinger og -værktøjer, der kan hjælpe dig med at udvikle, administrere eller optimere datamodeller.

Tip

Vi opfordrer dig til at downloade scenariediagrammet , hvis du vil integrere det i din præsentation, dokumentation eller dit blogindlæg – eller udskrive det som en vægplakat. Da det er et SVG-billede (Scalable Vector Graphics), kan du skalere det op eller ned uden tab af kvalitet.

Scenariediagrammet viser følgende brugerhandlinger, værktøjer og funktioner:

Vare	Beskrivelse
	Modeloprettere udvikler datamodeller ved hjælp af Tabeleditor. Det er almindeligt, at det indledende designarbejde (f.eks. Power Query-arbejde) udføres i Power BI Desktop, før du skifter til Tabeleditor (ikke afbildet i scenariediagrammet).
	Datamodellen opretter forbindelse til data fra en eller flere datakilder.
	Nogle datakilder kan kræve en datagateway i det lokale miljø eller en VNet-gateway til opdatering af data, f.eks. dem, der er placeret i et privat organisationsnetværk.
	Udvikling af datamodeller sker i Tabeleditor. Redigering af M-scripts (Power Query) understøttes. Modeludviklere kan bruge C#-scripts til at fremskynde udviklingen.
	Når de er klar, publicerer semantiske modeloprettere datamodellen fra Tabular Editor til Power BI-tjeneste ved hjælp af XMLA-slutpunktet for destinationsarbejdsområdet.
	Datamodellen publiceres i et arbejdsområde, der er dedikeret til lagring og sikring af delte semantiske modeller. Adgang til arbejdsområdet ved hjælp af XMLA-slutpunktet er kun muligt, når arbejdsområdets licenstilstand er angivet til Fabric-kapacitet, Premium-kapacitet, Premium pr. bruger eller Embedded.
	Rapportoprettere opretter rapporter ved hjælp af en direkte forbindelse til den delte semantiske model.
	Rapportoprettere udvikler rapporter i Power BI Desktop. Bortset fra bevidst at adskille rapporter fra semantiske modeller følger indholdsoprettere den typiske proces til oprettelse af rapporter.
	Når de er klar, publicerer rapportoprettere deres Power BI Desktop-fil (.pbix) eller Power BI-projektfil (.pbip) til Power BI-tjeneste.
	Rapporter publiceres i et arbejdsområde, der er dedikeret til lagring og sikring af rapporter og dashboards.
	Publicerede rapporter forbliver forbundet med den delte semantiske model, der er gemt i et andet arbejdsområde. Alle ændringer af den delte semantiske model påvirker alle afhængige rapporter.
	Tredjepartsværktøjer kan bruge XMLA-slutpunktet til at forespørge den delte semantiske model. Andre XMLA-kompatible værktøjer – f.eks. DAX Studio, Semantic Link fra Fabric-notesbøger eller Windows PowerShell – kan bruges til at forespørge eller opdatere den delte semantiske model. Power BI Desktop, Excel og Report Builder kan også oprette forbindelse ved hjælp af XMLA-slutpunktet (ikke afbildet i scenariediagrammet).
	Andre Microsoft- og tredjepartsværktøjer kan bruge XMLA-slutpunktet til at administrere den semantiske model og levere administration af programlivscyklus. Du kan få mere at vide under XMLA-slutpunktsbaserede klientværktøjer.
	Fabric-administratorer administrerer lejerindstillingen for at aktivere brugen af XMLA-slutpunktet. Administratoren skal aktivere XMLA-slutpunktet for Fabric-kapaciteter, Premium-kapaciteter og Premium pr. bruger-indstillinger.
	Fabric-administratorer fører tilsyn med og overvåger aktivitet på Fabric-portalen.

Vigtige punkter

Følgende er nogle vigtige punkter, der skal understreges i forbindelse med administrationsscenariet for avancerede datamodeller.

Tredjepartsprogrammer og -værktøjer

Enterprise BI-teams bruger ofte klientværktøjer, f.eks. Tabeleditor (afbildet i scenariediagrammet og beskrevet i næste emne), for at hjælpe dem med at administrere centraliserede semantiske modeller. Alle semantiske modeloprettere, der ønsker at arbejde med avancerede modelleringsfunktioner, kan dog drage fordel af de metoder, der er beskrevet i dette forbrugsscenarie.

Der er flere måder at bruge tredjepartsprogrammer på:

• Opret forbindelse til en ekstern datamodel ved hjælp af XMLA-slutpunktet: Nogle tredjepartsværktøjer kan oprette direkte forbindelse til en fjerndatamodel i Power BI-tjenesten (eller Analysis Services). Når du har oprettet forbindelse til XMLA-slutpunktet, understøttes alle TOM-handlinger (Tabular Object Model). Denne fremgangsmåde er det primære fokus i dette forbrugsscenarie.
• Opret forbindelse til en lokal datamodel i Power BI Desktop: Nogle tredjepartsværktøjer kan oprette forbindelse til en lokal datamodel, der er åben i Power BI Desktop (ikke afbildet i scenariediagrammet). Der er dog nogle begrænsninger, og ikke al ekstern værktøjsfunktionalitet understøttes officielt.
• Opret forbindelse til en skabelonfil i Power BI Desktop: Nogle tredjepartsværktøjer distribuerer deres funktionalitet på en let måde ved hjælp af en Power BI Desktop-skabelonfil (.pbit) (ikke afbildet i scenariediagrammet).

Tabular Editor

Tabeleditoren er afbildet i scenariediagrammet. Det er et tredjepartsværktøj, der er blevet udbredt i Power BI-community'et. Nogle af fordelene ved at administrere tabellariske datamodeller med Tabeleditor omfatter:

• Konfiguration af datamodelfunktioner, der ikke understøttes i Power BI Desktop: Tabeleditor indeholder en grænseflade til konfiguration af sikkerhed på objektniveau (OLS), beregningsgrupper, perspektiver, oversættelser og partitioner.
• Understøttelse af samtidig modeludvikling: Microsoft-værktøjer til udvikling af datamodeller, f.eks. Visual Studio med Analysis Services-projekter, gemmer hele datamodeldefinitionen i en Model.bim--fil. Denne enkelt fil kan gøre det svært for et team af udviklere at arbejde sammen om en enkelt datamodel. Tabeleditor har en funktion, der kaldes mappe serialisering. Mappe serialisering dekonstruerer filen Model.bim til separate objektspecifikke filer i en organiseret mappestruktur. Forskellige dataudformere kan derefter arbejde på forskellige filer med mindre risiko for at overskrive hinandens indsats.
• Integration med versionsstyring: Mappe serialisering gør det muligt for kildekontrolsystemet nemt at registrere ændringer af datamodeller, hvilket gør det nemmere at foretage kildefletninger og konfliktløsning.
• Forbedret kvalitet og design af datamodeller: Tabeleditor kan integreres med BPA (Best Practices Analyzer). BPA hjælper dataudviklere med et sæt regler, der kan tilpasses, og som kan forbedre kvaliteten, ensartetheden og ydeevnen af datamodeller. Du kan downloade et sæt regler for bedste praksis (leveret af Microsoft) fra GitHub.
• øget produktivitet ved udvikling af datamodeller: Brugergrænsefladen i Tabeleditor gør den velegnet til at udføre batchredigeringer, foretage fejlfinding og få vist afhængigheder af datamodeller. Tabeleditor adskiller sig fra Power BI Desktop, da den fungerer i afbrudt tilstand. Du kan foretage ændringer af datamodeller i afbrudt tilstand og bekræfte dem som en batch af ændringer. Hvis du arbejder på denne måde, kan du hurtigere udvikle og validere, især for erfarne dataudformere. Det er også muligt at oprette C#-scripts og gemme dem som makroer. Disse scripts kan hjælpe dig med at forbedre effektiviteten af administration og synkronisering af flere datamodeller.

XMLA-slutpunkt

XMLA-slutpunktet bruger XMLA-protokollen til at vise alle funktioner i en tabeldatamodel, herunder nogle datamodelleringshandlinger , der ikke understøttes af Power BI Desktop. Du kan bruge TOM API'en til at foretage programmatiske ændringer af en datamodel.

XMLA-slutpunktet giver også forbindelse. Du kan kun oprette forbindelse til en semantisk model, når det arbejdsområde, hvor licenstilstanden er angivet til Premium pr. bruger, Premium pr. kapacitet eller Embedded. Når der er oprettet forbindelse, kan et XMLA-kompatibelt værktøj arbejde på datamodellen på to måder:

• Skrivedata og metadata: Læse-/skrivebrug af XMLA-slutpunktet gør det muligt at:
  • Datamodelleringsfunktioner, der ikke understøttes af Power BI Desktop, f.eks. sikkerhed på objektniveau (OLS), beregningsgrupper, perspektiver, oversættelser og partitionsstyring.
  • Mere komplekse udrulninger. Det kan f.eks. være en delvis udrulning eller en installation udelukkende af metadata, der kun udgiver en enkelt ny måling.
  • Asynkron opdatering af semantisk model. Det kan f.eks. være opdatering af en enkelt tabel eller partition.
• Læs data og metadata: Skrivebeskyttet brug af XMLA-slutpunktet gør det muligt at:
  • Overvågning, fejlfinding og sporing af semantiske modeller og forespørgsler.
  • Gør det muligt for tredjepartsværktøjer til datarapportering at visualisere data, der stammer fra en delt semantisk model. Denne teknik er en god måde at udvide fordelene og investeringerne i administreret selvbetjenings-BI på.

Advarsel!

Når du har redigeret eller publiceret en semantisk model ved hjælp af XMLA-slutpunktet, kan du ikke længere downloade den fra Power BI-tjeneste som en Power BI Desktop-fil.

XMLA-indstillinger pr. kapacitet

Hver Power BI Premium-kapacitet og Power BI Embedded-kapacitet har en indstilling til at styre, om XMLA-slutpunktet er skrivebeskyttet, læse/skrive eller fra. Denne indstilling er også tilgængelig for alle Premium pr. bruger-arbejdsområder i Power BI-lejeren. Læse-/skriveadgang til XMLA skal være aktiveret for hver kapacitet, der indeholder semantiske modeller, som du vil administrere med et andet værktøj end Power BI Desktop.

Tip

Indstillingen for XMLA-slutpunktet (læse/skrive, skrivebeskyttet eller deaktiveret) gælder for alle arbejdsområder og semantiske modeller, der er tildelt en bestemt kapacitet. Du kan konfigurere flere kapaciteter for at decentralisere og/eller tilpasse, hvordan indhold administreres for hver kapacitet.

Indstilling for XMLA-lejer

Ud over indstillingerne for XMLA-slutpunktet skal en Power BI-administrator bruge lejerindstillingerne til at tillade XMLA-slutpunkter og Analysér i Excel med semantiske modeller i det lokale miljø. Når indstillingen er aktiveret, kan du tillade, at alle brugere eller bestemte sikkerhedsgrupper bruger XMLA-slutpunktsfunktioner.

Bemærk

Alle standardfunktioner til sikkerhed og databeskyttelse gælder stadig for at angive, hvilke brugere der kan få vist og/eller redigere indhold.

Tredjepartsværktøjer

Power BI Desktop kan håndtere komplette behov for de fleste oprettere af selvbetjeningsindhold. Tredjepartsværktøjer tilbyder dog andre virksomhedsfunktioner og -funktionalitet. Derfor er tredjepartsværktøjer, f.eks . Tabular Editor, blevet udbredt i Power BI-community'et, især for avancerede indholdsforfattere, udviklere og it-teknikere.

Tip

I dette blogindlæg beskrives det, hvordan tredjepartsværktøjer gør det muligt for Power BI-produktteamet at revurdere deres udviklingsprioriteter, øge rækkevidden af Power BI-platformen og imødekomme mere avancerede og forskelligartede anmodninger fra brugergruppen.

Bemærk

Nogle tredjepartsværktøjer kræver en betalt licens, f.eks. Tabular Editor 3. Andre communityværktøjer er gratis og åben kildekode (f.eks. Tabular Editor 2, DAX Studio og ALM Toolkit). Vi anbefaler, at du omhyggeligt evaluerer funktionerne i de enkelte værktøjer, omkostninger og supportmodeller, så du i tilstrækkelig grad kan understøtte dit community af indholdsforfattere.

Administration af datamodeller

Det primære fokus i dette forbrugsscenarie er på den indholdsopretter, der bruger Tabeleditor til at administrere en datamodel. I forbindelse med sjældne krav til administration af avancerede datamodeller, f.eks. lejlighedsvis partitionsstyring, kan du vælge at bruge et værktøj, f.eks. SQL Server Management Studio (SSMS). Det er også muligt for en .NET-udvikler at oprette og administrere semantiske Power BI-modeller ved hjælp af TOM-API'en.

Tip

Når du bruger XMLA-slutpunktet til administration af datamodeller, anbefaler vi, at du aktiverer indstillingen for lagringsformatet for store semantiske modeller. Når indstillingen er aktiveret, kan lagringsformatet for den store semantiske model forbedre ydeevnen for XMLA-skrivehandlinger.

Adskillelse af datamodel og rapporter

Hvis dette forbrugsscenarie skal lykkes, skal du adskille rapporter fra datamodellen. Denne fremgangsmåde resulterer i administration af separate Power BI Desktop-filer som beskrevet i det administrerede selvbetjente BI-forbrugsscenarie . Selvom den samme person er ansvarlig for al udvikling, er adskillelsen af semantiske modeller og rapporter vigtig, fordi Tabeleditor ikke har kendskab til rapportindhold.

Konfiguration af gateway

Der kræves typisk en datagateway, når du får adgang til datakilder, der er placeret i det private organisationsnetværk eller et virtuelt netværk. Datagatewayen i det lokale miljø bliver relevant, når en datamodel publiceres til Power BI-tjeneste. De to formål med en gateway er at opdatere importerede data eller få vist en rapport, der forespørger en direkte forbindelse eller en DirectQuery-semantisk model (ikke afbildet i scenariediagrammet).

Bemærk

En central datagateway i standardtilstand anbefales på det kraftigste via gateways i personlig tilstand. I standardtilstand understøtter datagatewayen direkte forbindelse og DirectQuery-handlinger (ud over planlagte dataopdateringshandlinger).

Du kan få flere oplysninger under Datagateway i det lokale miljø (standardtilstand).

Systemtilsyn

Aktivitetsloggen registrerer brugeraktiviteter, der forekommer i Power BI-tjeneste. Power BI-administratorer kan bruge de aktivitetslogdata, der indsamles, til at udføre overvågning for at hjælpe dem med at forstå aktiviteter, der opretter forbindelse via XMLA-slutpunkter.

Relateret indhold

Du kan finde andre nyttige scenarier, der kan hjælpe dig med power BI-implementeringsbeslutninger, i artiklen Power BI-forbrugsscenarier .