Power BI-Verwendungsszenarios: Erweiterte Datenmodellverwaltung

Hinweis

Dieser Artikel ist Teil der Artikelreihe zur Power BI-Implementierungsplanung. Diese Reihe konzentriert sich hauptsächlich auf die Power BI-Erfahrung in Microsoft Fabric. Eine Einführung in die Artikelreihe finden Sie unter Power BI-Implementierungsplanung.

Bei diesem Verwendungsszenario geht es um die erweiterte Datenmodellverwaltung, die erforderlich ist, wenn ein Power BI-Inhaltsersteller zum Entwickeln, Verwalten und Optimieren von Datenmodellen ein Drittanbietertool verwendet. Einige Drittanbietertools sind externe Tools, die von Power BI Desktop direkt unterstützt werden. Sie können auch ein veröffentlichtes Datenmodell (Semantikmodell) verwalten, indem Sie direkt mit dem XMLA-Endpunkt im Power BI-Dienst kommunizieren.

Datenmodelle werden im Power BI-Dienst, in Azure Analysis Services (AAS) oder in SQL Server Analysis Services (SSAS) gehostet. Bei diesem Verwendungsszenario geht es um die Verwendung des XMLA-Endpunkts im Power BI-Dienst.

Tipp

Viele bezeichnen Drittanbietertools als externe Tools. Tools werden jedoch hinsichtlich ihrer Verwendung unterscheiden. Das Herstellen einer Verbindung mit einem lokalen Datenmodell in Power BI Desktop ist die wörtlichste Interpretation des Begriffs externes Tool. Bei diesem Verwendungsszenario zur erweiterten Datenmodellverwaltung geht es um das Herstellen einer Verbindung mit einem Remotedatenmodell (also einem Semantikmodell, das im Power BI-Dienst gehostet wird) mithilfe des XMLA-Endpunkts. Weitere Informationen zu den verschiedenen Möglichkeiten der Verwendung von Drittanbietertools finden Sie weiter unten in diesem Artikel.

Sie können eine Verbindung mit einem Datenmodell mithilfe des Protokolls XML for Analysis (XMLA) herstellen. Beim XMLA-Protokoll handelt es sich um ein Protokoll nach Industriestandard, das von mehr als 25 Anbietern unterstützt wird, darunter auch Microsoft. Alle Tools, auch Drittanbietertools, die mit dem XMLA-Protokoll kompatibel sind, verwenden Microsoft-Clientbibliotheken zum Lesen und/oder Schreiben von Daten in einem Datenmodell. Konnektivität wird über einen XMLA-Endpunkt erreicht. Dabei handelt es sich um eine API, die von einem Datenmodell verfügbar gemacht wird, das für Semantikmodellersteller*innen zusätzliche Entwicklungs- und Verwaltungsfunktionen bereitstellt.

Hinweis

Bei diesem Verwendungsszenario zur erweiterten Datenmodellverwaltung handelt es sich um eines der Szenarios zur Inhaltsverwaltung und -bereitstellung. Eine umfassende Liste mit Self-Service-Verwendungsszenarios finden Sie unter Power BI-Verwendungsszenarios.

Einige Aspekte, die in den Szenarios für die inhaltsorientierte Zusammenarbeit und Übermittlung von Inhalten beschrieben sind, werden der Kürze halber in diesem Artikel nicht behandelt. Lesen Sie für vollständige Informationen zuerst diese Artikel.

Szenariodiagramm

Bei diesem Verwendungsszenarios zur erweiterten Datenmodellverwaltung geht es in erster Linie um die Verwendung von Tabular Editor zum Verwalten des Datenmodells. Sie können Ihre Datenmodelle mithilfe des im Rahmen von Power BI Premium verfügbaren XMLA-Endpunkts im Power BI-Dienst veröffentlichen.

Wichtig

Manchmal bezieht sich dieser Artikel auf Power BI Premium oder seine Kapazitätsabonnements (P-SKUs). Beachten Sie, dass Microsoft derzeit Kaufoptionen konsolidiert und die SKUs von Power BI Premium pro Kapazität einstellt. Neue und vorhandene Kunden sollten stattdessen den Kauf von Fabric-Kapazitätsabonnements (F-SKUs) in Betracht ziehen.

Weitere Informationen finden Sie unter Wichtige Updates zur Power BI Premium-Lizenzierung und Häufig gestellte Fragen zu Power BI Premium.

Tipp

Es wird empfohlen, das Verwendungsszenario Self-Service-Inhaltsveröffentlichung durchzulesen (sofern noch nicht geschehen). Das Szenario für die erweiterte Datenmodellverwaltung baut auf diesem Szenario auf.

Hinweis

Manchmal werden die Begriffe Semantikmodell und Datenmodell synonym verwendet. Aus Sicht des Power BI-Diensts wird der Begriff Semantikmodell verwendet. Aus Entwicklungsperspektive wird Datenmodell (oder kurz Modell) verwendet. In diesem Artikel haben beide Begriffe dieselbe Bedeutung. Ebenso haben Semantikmodellersteller*innen und Datenmodellierer*innen dieselbe Bedeutung.

Das folgende Diagramm enthält eine allgemeine Übersicht über die am häufigsten verwendeten Benutzeraktionen und Tools zum Entwickeln, Verwalten oder Optimieren von Datenmodellen.

Tipp

Wir empfehlen Ihnen, das Szenariodiagramm herunterzuladen, wenn Sie es in Ihre Präsentation, Dokumentation oder Ihren Blogbeitrag einbinden oder als Wandposter ausdrucken möchten. Da es sich um ein SVG-Bild (Scalable Vector Graphics) handeln kann, können Sie es ohne Qualitätsverlust nach oben oder unten skalieren.

Das Szenariodiagramm veranschaulicht die folgenden Benutzeraktionen, Tools und Features:

Element	Beschreibung
	Modellersteller*innen entwickeln Datenmodelle mithilfe von Tabular Editor. Häufig werden erste Entwürfe (wie Power Query-Arbeiten) in Power BI Desktop durchgeführt und erst danach mit Tabular Editor weitergearbeitet (im Szenariodiagramm nicht dargestellt).
	Über das Datenmodell wird eine Verbindung mit Daten in mindestens einer Datenquelle hergestellt.
	Für einige Datenquellen ist möglicherweise ein lokales Datengateway oder ein VNet-Gateway für die Datenaktualisierung erforderlich, z. B. solche, die sich in einem privaten Organisationsnetzwerk befinden.
	Die Datenmodellentwicklung erfolgt in Tabular Editor. Die Bearbeitung von Power Query (M)-Skripts wird unterstützt. Modellersteller können C#-Skripts verwenden, um die Entwicklung zu beschleunigen.
	Wenn sie fertig sind, veröffentlichen Semantikmodellersteller*innen das Datenmodell mit Tabular Editor im Power BI-Dienst mithilfe des XMLA-Endpunkts des Zielarbeitsbereichs.
	Das Datenmodell wird in einem dedizierten Arbeitsbereich zum Speichern und Schützen von freigegebenen Semantikmodellen veröffentlicht. Der Zugriff auf den Arbeitsbereich mithilfe des XMLA-Endpunkts ist nur möglich, wenn der Arbeitsbereich Lizenzmodus auf Fabric-Kapazität, Premium-Kapazität, Premium pro Benutzeroder Eingebettet festgelegt ist.
	Berichtsersteller*innen erstellen Berichte mithilfe einer Liveverbindung mit dem freigegebenen Semantikmodell.
	Berichtsersteller*innen entwickeln Berichte in Power BI Desktop. Abgesehen von der bewussten Trennung von Berichten und Semantikmodellen folgen Inhaltsersteller*innen dem typischen Prozess zur Berichtserstellung.
	Wenn er bereit ist, veröffentlichen Berichtersteller ihre Power BI Desktop-Datei (PBIX) oder Power BI-Projektdatei (PBIP) im Power BI-Dienst.
	Berichte werden in einem dedizierten Arbeitsbereich zum Speichern und Sichern von Berichten und Dashboards veröffentlicht.
	Veröffentlichte Berichte bleiben mit dem freigegebenen Semantikmodell verbunden, das in einem anderen Arbeitsbereich gespeichert ist. Am freigegebenen Semantikmodell vorgenommene Änderungen wirken sich auf alle abhängigen Berichte aus.
	Drittanbietertools können den XMLA-Endpunkt zum Abfragen des freigegebenen Semantikmodells verwenden. Andere XMLA-kompatible Tools, wie DAX Studio, Semantikverknüpfung aus Fabric-Notizbüchern oder Windows PowerShell, können verwendet werden, um das freigegebene Semantikmodell abzufragen oder zu aktualisieren. Power BI Desktop, Excel und Report Builder können ebenfalls eine Verbindung mit dem XMLA-Endpunkt herstellen (im Szenariodiagramm nicht dargestellt).
	Andere Tools von Microsoft und Drittanbietern können den XMLA-Endpunkt verwenden, um das Semantikmodell zu verwalten und eine Lebenszyklusverwaltung für Anwendungen bereitzustellen. Weitere Informationen finden Sie unter XMLA-Endpunkt-basierte Clienttools.
	Fabric-Administratoren verwalten die Mandanteneinstellung und ermöglichen so die Verwendung des XMLA-Endpunkts. Der Administrator muss den XMLA-Endpunkt für Fabric-Kapazitäten, Premium-Kapazitäten und Premium-Einstellungen pro Benutzer aktivieren.
	Fabric-Administratoren überwachen und überwachen Aktivitäten im Fabric-Portal.

Wesentliche Punkte

Nachstehend sind einige wichtige Punkte aufgeführt, auf die im Szenario für die erweitere Datenmodellverwaltung besonders hingewiesen werden muss.

Anwendungen und Tools von Drittanbietern

Enterprise BI-Teams verwenden häufig Clienttools wie Tabular Editor (im Szenariodiagramm dargestellt und im nächsten Thema beschrieben) zur Verwaltung von zentralisierten Semantikmodellen. Semantikmodellersteller*innen, die erweiterte Modellierungsfunktionen verwenden möchten, können jedoch die in diesem Verwendungsszenario beschriebenen Methoden nutzen.

Es gibt mehrere Möglichkeiten für die Verwendung von Drittanbieteranwendungen:

• Herstellen einer Verbindung mit einem Remotedatenmodell mithilfe des XMLA-Endpunkts: Mit einigen Drittanbietertools kann eine direkte Verbindung mit einem Remotedatenmodell im Power BI-Dienst (oder in Analysis Services) hergestellt werden. Sobald eine Verbindung mit dem XMLA-Endpunkt hergestellt wurde, werden alle TOM-Vorgänge (Tabular Object Model) unterstützt. Um diesen Ansatz geht es in diesem Verwendungsszenario hauptsächlich.
• Herstellen einer Verbindung mit einem lokalen Datenmodell in Power BI Desktop: Mit einigen Drittanbietertools kann eine Verbindung mit einem lokalen Datenmodell hergestellt werden, das in Power BI Desktop geöffnet ist (im Szenariodiagramm nicht dargestellt). Dabei gibt es jedoch einige Einschränkungen, und nicht alle Funktionen der externen Tools werden offiziell unterstützt.
• Herstellen einer Verbindung mit einer Vorlagendatei in Power BI Desktop: Bei einigen Drittanbietertools werden die Funktionen mithilfe einer PBIT-Vorlagendatei (Power BI Desktop) auf einfache Weise bereitgestellt (im Szenariodiagramm nicht dargestellt).

Tabular Editor

Tabular Editor ist im Szenariodiagramm dargestellt. Hierbei handelt es sich um ein Drittanbietertool, das von der Power BI-Community weithin angenommen wird. Tabular Editor bietet beim Verwalten von tabellarischen Datenmodellen unter anderem folgende Vorteile:

• Einrichten von Datenmodellfunktionen, die in Power BI Desktop nicht unterstützt werden: Tabular Editor stellt eine Schnittstelle zum Einrichten von Sicherheit auf Objektebene (Object Level Security, OLS), Berechnungsgruppen, Perspektiven, Übersetzungen und Partitionen bereit.
• Unterstützung für gleichzeitige Modellentwicklung: Bei Datenmodellentwicklungstools von Microsoft wie Visual Studio mit Analysis Services-Projekten wird die gesamte Datenmodelldefinition in einer Model.bim-Datei gespeichert. Diese ein Datei kann einem Team von Entwickler*innen die gemeinsame Arbeit an einem Datenmodell erschweren. Tabular Editor enthält ein Feature mit der Bezeichnung Ordnerserialisierung. Mit der Ordnerserialisierung wird die Datei „Model.bim“ in einzelne objektspezifische Dateien innerhalb einer organisierten Ordnerstruktur zerlegt. Dadurch können verschiedene Datenmodellierer*innen an verschiedenen Dateien arbeiten, ohne dass die Gefahr besteht, dass die Arbeit der anderen überschrieben wird.
• Integration in die Quellcodeverwaltung: Durch die Ordnerserialisierung kann das Quellcodeverwaltungssystem Änderungen leicht erkennen, was die Zusammenführung von Datenquellen und die Konfliktlösung erleichtert.
• Verbesserte Qualität und Gestaltung des Datenmodells: Tabular Editor wird in Best Practices Analyzer (BPA) integriert. Dank BPA können Datenmodellierer*innen mithilfe von anpassbaren Regeln die Qualität, Konsistenz und Leistung von Datenmodellen verbessern. Auf GitHub können verschiedene Best-Practices-Regeln (von Microsoft bereitgestellt) heruntergeladen werden.
• Höhere Produktivität beim Entwickeln von Datenmodellen: Die Schnittstelle Tabular Editor eignet sich besonders gut zum Durchführen von Batchänderungen, zum Debuggen sowie zum Anzeigen von Datenmodellabhängigkeiten. Tabular Editor unterscheidet sich von Power BI Desktop insofern, als dass die Schnittstelle im getrennten Modus arbeitet. Dadurch können Änderungen am Datenmodell im getrennten Modus vorgenommen und als Änderungsbatch committet werden. Diese Arbeitsweise ermöglicht insbesondere für erfahrene Datenmodellierer*innen eine schnellere Entwicklung und Prüfung. Darüber hinaus ist es auch möglich, C#-Skripts zu erstellen und als Makros zu speichern. Mit diesen Skripts können mehrere Datenmodelle effizienter verwaltet und synchronisiert werden.

XMLA-Endpunkt

Beim XMLA-Endpunkt wird das XMLA-Protokoll verwendet, um alle Features eines tabellarischen Datenmodells verfügbar zu machen. Dazu gehören einigeDatenmodellierungsvorgänge, die von Power BI Desktop nicht unterstützt werden. Mithilfe der TOM-API können am Datenmodell programmgesteuerte Änderungen vorgenommen werden.

Der XMLA-Endpunkt sorgt darüber hinaus auch für Konnektivität. Mit einem Semantikmodell kann nur dann eine Verbindung hergestellt werden, wenn der Lizenzmodus des Arbeitsbereichs auf Premium-Einzelbenutzerlizenz, Premium-Kapazitätslizenz oder Eingebettet festgelegt ist. Sobald eine Verbindung hergestellt wurde, kann ein XMLA-kompatibles Tool auf zwei Arten auf das Datenmodell zugreifen:

• Schreiben von Daten und Metadaten: Bei Verwendung des XMLA-Endpunkts mit Lese-/Schreibzugriff ist Folgendes möglich:
  • Datenmodellierungsfunktionen, die von Power BI Desktop nicht unterstützt werden, wie Sicherheit auf Objektebene (Object Level Security, OLS), Berechnungsgruppen, Perspektiven, Übersetzungen und Partitionsverwaltung.
  • Komplexere Bereitstellungen. Beispielsweise eine partielle Bereitstellung oder eine reine Metadatenbereitstellung, bei der nur ein neues Measure veröffentlicht wird.
  • Asynchrone Semantikmodellaktualisierung. Beispielsweise die Aktualisierung einer Tabelle oder einer Partition.
• Lesen von Daten und Metadaten: Bei einer schreibgeschützten Verwendung des XMLA-Endpunkts ist Folgendes möglich:
  • Überwachen, Debuggen und Verfolgen von Semantikmodellen und Abfragen.
  • Damit können mit Drittanbietertools für die Erstellung von Datenberichten Daten visualisiert werden, die aus einem freigegebenen Semantikmodell stammen. Diese Technik bietet eine gute Möglichkeit, die Vorteile und Investitionen in verwaltete Self-Service-BI zu erweitern.

Warnung

Nachdem Sie ein Semantikmodell mithilfe des XMLA-Endpunkts geändert oder veröffentlicht haben, können Sie es nicht mehr über den Power BI-Dienst als Power BI Desktop-Datei herunterladen.

XMLA-Einstellungen pro Kapazität

Für jede Power BI Premium-Kapazität und Power BI Embedded-Kapazität gibt es eine Einstellung, mit der festgelegt werden kann, ob der XMLA-Endpunkt schreibgeschützt ist, über Lese-/Schreibzugriff verfügt oder deaktiviert ist. Diese Einstellung ist auch für alle Arbeitsbereiche mit Premium-Einzelbenutzerlizenz im Power BI-Mandanten verfügbar. Für alle Kapazitäten, die Semantikmodelle enthalten, die nicht mit Power BI Desktop verwaltet werden sollen, muss der Schreib-/Lesezugriff für XMLA aktiviert sein.

Tipp

Die XMLA-Endpunkteinstellung (Schreib-/Schreibzugriff, schreibgeschützt oder deaktiviert) gilt für alle Arbeitsbereiche und Semantikmodelle, die einer bestimmten Kapazität zugewiesen sind. Es können mehrere Kapazitäten eingerichtet werden, um die Verwaltung von Inhalten für die einzelnen Kapazitäten zu dezentralisieren und/oder anzupassen.

XMLA-Mandanteneinstellung

Außer den XMLA-Endpunkteinstellungen müssen Power BI-Administrator*innen die Mandanteneinstellungen verwenden, um XMLA-Endpunkte und „In Excel analysieren“ mit lokalen Semantikmodellen zuzulassen. Wenn diese Option aktiviert ist, können Sie allen Benutzer*innen oder bestimmten Sicherheitsgruppen die Verwendung der XMLA-Endpunktfunktionalität erlauben.

Hinweis

Zum Festlegen, welche Benutzer*innen Inhalte anzeigen und/oder bearbeiten können, werden weiterhin alle üblichen Sicherheits- und Datenschutzfeatures angewendet.

Tools von Drittanbietern

Power BI Desktop kann die umfassenden Anforderungen der meisten Ersteller*innen von Self-Service-Inhalten erfüllen. Drittanbietertools bieten jedoch andere Unternehmensfeatures und -funktionen. Daher haben sich Drittanbietertools wie Tabular Editor in der Power BI-Community insbesondere bei erfahrenen Inhaltsersteller*innen, Entwickler*innen und IT-Expert*innen durchgesetzt.

Tipp

In diesem Blogbeitrag wird beschrieben, wie das Power BI-Produktteam mit Drittanbietertools Entwicklungsprioritäten neu bewerten, die Reichweite der Power BI-Plattform vergrößern und intelligentere und diversere Anforderungen vonseiten der Benutzercommunity erfüllen kann.

Hinweis

Für einige Drittanbietertools wie etwa für Tabular Editor 3 ist eine kostenpflichtige Lizenz erforderlich. Andere Communitytools sind kostenlose Open-Source-Tools (z B. Tabular Editor 2, DAX Studio und ALM Toolkit). Sie sollten die Funktionen der einzelnen Tools, die Kosten und das Supportmodell sorgfältig prüfen, damit Sie Ihre Community von Inhaltsersteller*innen angemessen unterstützen können.

Datenmodellverwaltung

Bei diesem Verwendungsszenario geht es hauptsächlich um den Inhaltsersteller, der Datenmodelle mit Tabular Editor verwaltet. Bei seltenen Anforderungen an die erweiterte Datenmodellverwaltung, wie die gelegentliche Verwaltung von Partitionen, kann ein Tool wie SQL Server Management Studio (SSMS) verwendet werden. Es ist auch möglich, dass .NET-Entwickler*innen Power BI-Semantikmodelle mithilfe der TOM-API erstellen und verwalten.

Tipp

Wenn Sie den XMLA-Endpunkt für die Datenmodellverwaltung verwenden, sollten Sie die Einstellung Speicherformat für große Semantikmodelle aktivieren. Wenn diese Einstellung aktiviert ist, kann das Speicherformat für große Semantikmodelle die Leistung von XMLA-Schreibvorgängen verbessern.

Trennung von Datenmodell und Berichten

Wenn dieses Verwendungsszenario erfolgreich sein soll, müssen Sie Berichte vom Datenmodell trennen. Bei diesem Ansatz werden Power BI Desktop-Dateien, wie im Verwendungsszenario Verwaltete Self-Service-BI beschrieben, getrennt verwaltet. Selbst wenn ein und dieselbe Person für die gesamte Entwicklung verantwortlich ist, ist die Trennung von Semantikmodellen und Berichten wichtig, da Berichtsinhalte von Tabular Editor nicht erkannt werden.

Gatewaysetup

Beim Zugriff auf Datenquellen, die sich im privaten Organisationsnetzwerk oder in einem virtuellen Netzwerk befinden, ist normalerweise ein Datengateway erforderlich. Das lokale Datengateway wird relevant, sobald ein Datenmodell im Power BI-Dienst veröffentlicht wird. Ein Gateway erfüllt zwei Zwecke: Aktualisieren importierter Daten oder Anzeigen eines Berichts, der eine Liveverbindung oder ein DirectQuery-Semantikmodell abfragt (nicht im Szenariodiagramm dargestellt).

Hinweis

Anstelle von Gateways im persönlichen Modus wird dringend ein zentrales Datengateway im Standardmodus empfohlen. Im Standardmodus unterstützt das Datengateway Liveverbindungs- und DirectQuery-Vorgänge (zusätzlich zu geplanten Datenaktualisierungsvorgängen).

Weitere Informationen finden Sie unter Lokales Datengateway (Standardmodus).

Systemüberwachung

Das Aktivitätsprotokoll erfasst Benutzeraktivitäten, die im Power BI-Dienst stattfinden. Power BI-Administrator*innen können die erfassten Aktivitätsprotokolldaten für Auditzwecke verwenden, um Aktivitäten zu verstehen, bei denen über XMLA-Endpunkte eine Verbindung hergestellt wird.

Zugehöriger Inhalt

Weitere nützliche Szenarios, die Ihnen bei Entscheidungen zur Power BI-Implementierung helfen können, finden Sie im Artikel Power BI-Verwendungsszenarios.