Verwenden zusammengesetzter Modelle in Power BI Desktop

Wenn Sie bislang DirectQuery in einem Bericht in Power BI Desktop verwendet haben, waren keine anderen Datenverbindungen für diesen Bericht zulässig – ganz gleich, ob es sich um DirectQuery- oder Importdatenverbindungen handelte. Bei zusammengesetzten Modellen ist diese Einschränkung hinfällig. Ein Bericht kann problemlos mehrere DirectQuery- oder Importdatenverbindungen in einer beliebigen Kombination derselbigen umfassen.

Die Funktion „Zusammengesetzte Modelle“ in Power BI Desktop besteht aus drei in Beziehung stehenden Features:

• Zusammengesetzte Modelle: Ermöglicht es, dass ein Bericht zwei oder mehr Datenverbindungen aus verschiedenen Quellgruppen hat. Bei diesen Quellgruppen könnte es sich um eine oder mehrere DirectQuery-Verbindungen und eine Importverbindung, zwei oder mehrere DirectQuery-Verbindungen oder eine beliebige Kombination davon handeln. In diesem Artikel werden die zusammengesetzten Modelle ausführlich erläutert.

• m:n-Beziehungen: Mithilfe zusammengesetzter Modelle können Sie m:n-Beziehungen zwischen Tabellen einrichten. Bei diesem Ansatz entfallen die Anforderungen für eindeutige Werte in Tabellen. Zudem sind vorherige Problemumgehungen hinfällig, wie z.B. die Einführung neuer Tabellen zum Einrichten von Beziehungen. Weitere Informationen finden Sie unter Anwenden von m:n-Beziehungen in Power BI Desktop.

• Speichermodus: Sie können nun angeben, welche Visuals Back-End-Datenquellen abfragen. Mit diesem Feature kann die Leistung verbessert und die Auslastung des Back-Ends verringert werden. Zuvor initiierten sogar einfache Visuals wie Slicer Abfragen von Back-End-Quellen. Weitere Informationen erhalten Sie unter Verwalten des Speichermodus in Power BI Desktop.

Verwenden von zusammengesetzten Modelle

Mithilfe zusammengesetzter Modelle können Sie eine Verbindung mit verschiedenen Arten von Datenquellen herstellen, wenn Sie Power BI Desktop oder den Power BI-Dienst verwenden. Sie haben mehrere Möglichkeiten, diese Datenverbindungen einzurichten:

• Durch das Importieren von Daten in Power BI, was den einfachsten Weg darstellt, Daten abzurufen
• Durch die direkte Verbindung mit Daten im ursprünglichen Quellrepository über DirectQuery. Weitere Informationen zu DirectQuery finden Sie unter Verwenden von DirectQuery mit Power BI.

Bei Verwendung von DirectQuery mit zusammengesetzten Modellen ist es möglich, ein Power BI-Modell – beispielsweise eine einzelne Power BI Desktop-Datei im PBIX-Format – für folgende Zwecke zu erstellen:

• Kombinieren von Daten aus mindestens einer DirectQuery-Quelle
• Kombinieren von Daten aus DirectQuery-Quellen und Importdaten

Wenn Sie z.B. zusammengesetzte Modelle verwenden, können Sie ein Modell erstellen, das die folgenden Datentypen kombiniert:

• Verkaufsdaten eines Data Warehouse von einem Unternehmen
• Verkaufszieldaten von einer SQL Server-Abteilungsdatenbank
• Daten, die aus einem Arbeitsblatt importiert wurden

Ein Modell, bei dem Daten aus mehr als einer DirectQuery-Quelle kombiniert werden oder bei dem DirectQuery mit importierten Daten kombiniert wird, wird als zusammengesetztes Modell bezeichnet.

Sie können wie gewohnt Beziehungen zwischen Tabellen herstellen, auch wenn diese Tabellen aus verschiedenen Quellen stammen. Alle quellenübergreifenden Beziehungen werden mit einer Kardinalität von m:n erstellt, unabhängig von ihrer tatsächlichen Kardinalität. Sie können sie in 1:n, n:1 oder m:n ändern. Unabhängig von der festgelegten Kardinalität weisen quellenübergreifende Beziehungen ein abweichendes Verhalten auf. Sie können keine DAX-Funktionen (Data Analysis Expressions) verwenden, um Werte der one-Seite von der many-Seite aus abzurufen. Ferner stellen Sie möglicherweise eine beeinträchtigte Leistung im Vergleich mit m:n-Beziehungen innerhalb der gleichen Quelle fest.

Beispiel für ein zusammengesetztes Modell

Ein Beispiel für ein zusammengesetztes Modell wäre ein Bericht, der über DirectQuery mit einem Data Warehouse eines Unternehmens in SQL Server verbunden ist. In diesem Fall enthält das Data Warehouse die Daten Sales by Country (Verkäufe nach Land/Region), Quarter (Quartal) und Bike (Product) (Fahrrad (Produkt)), so wie in folgender Abbildung dargestellt:

Nun könnten Sie mithilfe von Feldern aus dieser Quelle einfache Visuals erstellen. Die folgende Abbildung zeigt den Gesamtumsatz nach ProductName für ein ausgewähltes Quartal.

Aber was geschieht, wenn die Daten zu den den einzelnen Produkten zugewiesenen Produktmanagern (Product Manager) zusammen mit der Marketingprioriät in einer Excel-Arbeitsmappe vorliegen? Wenn Sie den Sales Amount (Verkaufssumme) nach Product Manager anzeigen möchten, können Sie diese lokalen Daten möglicherweise nicht dem Data Warehouse des Unternehmens hinzuzufügen. Bestenfalls dauert es ansonsten Monate.

Es ist vielleicht möglich, diese Umsatzdaten über das Data Warehouse zu importieren anstatt über DirectQuery. Die Verkaufsdaten könnten dann mit den Daten kombiniert werden, die Sie vom Arbeitsblatt importiert haben. Dieser Ansatz ist jedoch nicht sinnvoll angesichts der Beweggründe, aus denen DirectQuery überhaupt verwendet wird. Diese Gründe sind unter anderem folgende:

• Sicherheitsregeln, die in der zugrunde liegenden Quelle erzwungen werden
• Die Notwendigkeit, die neuesten Daten anzuzeigen
• Das schiere Volumen der Daten

An dieser Stelle kommen zusammengesetzte Modelle ins Spiel. Zusammengesetzte Modelle ermöglichen es Ihnen, über DirectQuery eine Verbindung herzustellen und dann Daten abrufen für weitere Quellen zu verwenden. In diesem Beispiel richten wir zunächst die DirectQuery-Verbindung für das Data Warehouse des Unternehmens. Wir verwenden Daten abrufen, wählen Excel aus, und navigieren dann zu dem Arbeitsblatt, das unsere lokalen Daten enthält. Schließlich importieren wir das Arbeitsblatt, das die Produktnamen (Product Name), den zugewiesenen Vertriebsleiter (Sales Manager) und die Priorität (Priority) enthält.

In der Liste Fields (Felder) sehen Sie zwei Tabellen: die ursprüngliche Bike-Tabelle von SQL Server und die neue ProductManagers-Tabelle. Die neue Tabelle enthält die Daten, die von Excel importiert wurden.

Auch in Power BI Desktop finden Sie unter Beziehungsansicht nun eine weitere Tabelle mit dem Namen ProductManagers.

Nun müssen wir diese Tabellen mit den anderen Tabellen im Modell verknüpfen. Wir erstellen wie immer eine Beziehung zwischen der Bike-Tabelle von SQL Server und der importierten ProductManagers-Tabelle. Das heißt, die Beziehung wird zwischen Bike[ProductName] und ProductManagers[ProductName] aufgebaut. Wie zuvor erwähnt, weisen alle quellenübergreifenden Beziehungen die Standardkardinalität m:n auf.

Da wir nun diese Beziehung erstellt haben, wird die sie erwartungsgemäß in Power BI Desktop in der Beziehungsansicht angezeigt.

Nun können wir Visuals erstellen, indem wir ein beliebiges Feld der Liste Fields- (Felder) verwenden. Mit diesem Ansatz werden problemlos Daten aus mehreren Quellen vermischt. Beispielsweise wird der gesamte SalesAmount für jeden Product Manager in folgender Darstellung abgebildet:

Im folgenden Beispiel wird ein häufiges Szenario einer Dimensionstabelle dargestellt (z. B. Product oder Customer), die mit einigen zusätzlichen Daten aus anderen Quellen erweitert wird. Es ist ebenso möglich, dass Tabellen DirectQuery verwenden, um eine Verbindung zu verschiedenen Quellen herzustellen. Stellen Sie sich für unser Beispiel zudem vor, dass SalesTargets nach Country und Period in einer separaten Abteilungsdatenbank gespeichert werden würden. Mit Daten abrufen können Sie wie gewohnt eine Verbindung mit diesen Daten herstellen, wie in der folgenden Abbildung dargestellt wird:

Wie im Beispiel vorher, können wir Beziehungen zwischen der neuen Tabelle und anderen Tabellen im Modell erstellen. Dann können wir Visuals erstellen, die die Tabellendaten kombinieren. Werfen wir erneut einen Blick auf die Beziehungsansicht, in der wir die neuen Beziehungen erstellt haben.

Die nächste Abbildung basiert auf den neuen Daten und Beziehungen, die wir erstellt haben. Das Visual links unten zeigt den gesamten Umsatz (Sales Amount) versus das Ziel (Target) sowie die Berechnung der Varianz für den Unterschied an. Die Daten von Sales Amount und Target stammen aus zwei unterschiedlichen SQL Server-Datenbanken.

Festlegen des Speichermodus

Jede Tabelle in einem zusammengesetzten Modell weist einen Speichermodus auf, der angibt, ob die Tabelle auf DirectQuery oder Importen basiert. Der Speichermodus kann im Bereich Eigenschaft angezeigt und geändert werden. Um den Speichermodus anzuzeigen, klicken Sie mit der rechten Maustaste in die Feldliste, und wählen Sie Eigenschaften aus. Die folgende Abbildung zeigt den Speichermodus für die SalesTargets-Tabelle.

Der Speichermodus ist auch in der QuickInfo für die einzelnen Tabellen einsehbar.

Bei Power BI Desktop-Dateien (PBIX-Format), die zum Teil Tabellen vom DirectQuery und importierte Tabellen enthalten, wird in der Statusleiste der Speichermodus mit dem Status Gemischt angezeigt. Sie können diese Bezeichnung in der Statusleiste auswählen und können so problemlos zwischen allen zu importierenden Tabellen wechseln.

Weitere Informationen zum Speichermodus finden Sie unter Verwalten des Speichermodus in Power BI Desktop.

Berechnete Tabellen

Sie können einem Modell in Power BI Desktop, das DirectQuery verwendet, berechnete Tabelle hinzufügen. Die Data Analysis Expressions-Bibliothek (DAX), die die berechnete Tabelle definiert, kann entweder auf importierte Tabellen oder DirectQuery-Tabellen oder eine Kombination aus diesen beiden verweisen.

Berechnete Tabellen werden immer importiert, und die Daten in diesen Tabellen werden bei Aktualisierung der Tabellen aktualisiert. Wenn eine berechnete Tabelle auf eine DirectQuery-Tabelle verweist, zeigen Visuals, die auf die DirectQuery-Tabelle verweisen, immer die neuesten Werte in der zugrunde liegenden Quelle an. Visuals, die auf die berechnete Tabelle verweisen, zeigen alternativ die Werte für den Zeitpunkt an, als die berechnete Tabelle zuletzt aktualisiert wurde.

Folgen für die Sicherheit

Zusammengesetzte Modelle haben Folgen für die Sicherheit. Eine an eine Datenquelle gesendete Abfrage kann Datenwerte enthalten, die von einer Quelle abgerufen wurden. Im vorherigen Beispiel hat das Visual, das den Sales Amount nach Product Manager angezeigt hat, eine SQL-Abfrage an die relationale Datenbank „Sales“ (Verkäufe) gesendet. Diese SQL-Abfrage kann die Namen der Product Manager sowie die zugehörigen Produkte enthalten.

Die Informationen, die in der Tabelle gespeichert sind, sind nun in einer Abfrage enthalten, die an die relationale Datenbank gesendet wird. Berücksichtigen Sie die genannten Folgen für die Sicherheit, wenn diese Informationen vertraulich sind. Beachten Sie insbesondere die folgenden Punkte:

• Jeder Administrator der Datenbank, der die Ablaufverfolgungen oder Überwachungsprotokolle anzeigen kann, kann diese Informationen einsehen, auch ohne Berechtigungen für die Daten in der ursprünglichen Datenquelle. In diesem Beispiel benötigt der Administrator Berechtigungen für die Excel-Datei.

• Die Verschlüsselungseinstellungen für jede Quelle müssen berücksichtigt werden. Sie sollten keine Informationen über eine verschlüsselte Verbindung aus einer Quelle abrufen und diese dann versehentlich in eine Abfrage einschließen, die über eine nicht verschlüsselte Verbindung an eine andere Quelle gesendet wird.

Um zu bestätigen, dass Sie die Auswirkungen auf die Sicherheit verstanden haben, wird in Power BI Desktop eine Warnmeldung angezeigt, wenn Sie ein zusammengesetztes Modell erstellen.

Wenn ein Autor außerdem Tabelle1 aus Modell A zu einem zusammengesetzten Modell hinzufügt (Modell C als Referenz), kann ein Benutzer, der einen auf Modell C basierenden Bericht anzeigt, jede beliebige Tabelle in Modell A abfragen, die nicht von RLS geschützt wird.

Aus ähnlichen Gründen müssen Sicherheitsvorkehrungen getroffen werden, wenn eine Power BI Desktop-Datei geöffnet wird, die nicht von einer vertrauenswürdigen Quelle gesendet wurde. Sollte die Datei zusammengesetzte Modelle enthalten, werden Informationen, die eine Person mithilfe der Anmeldeinformationen des Benutzers, der die Datei öffnet, aus einer Quelle abruft, als Teil einer Abfrage an eine andere Datenquelle gesendet. Die Informationen können vom böswilligen Autor der Power BI Desktop-Datei angezeigt werden. Wenn Sie das erste Mal eine Power BI Desktop-Datei öffnen, die mehrere Quellen enthält, zeigt Power BI Desktop eine Warnung an. Diese Warnung ist mit der Warnung vergleichbar, die beim Öffnen einer Datei mit nativen SQL-Abfragen angezeigt wird.

Folgen für die Leistung

Bei der Verwendung von DirectQuery sollte stets die Leistung berücksichtigt werden, und zwar in erster Linie, um sicherzustellen, dass die Back-End-Quelle genügend Ressourcen aufweist, um ein zufriedenstellendes Benutzererlebnis bereitzustellen. Das bedeutet, dass sich die Visuals in weniger als fünf Sekunden aktualisieren. Weitere Empfehlungen zur Leistung finden Sie unter DirectQuery in Power BI.

Das Verwenden von zusammengesetzten Modelle bringt andere Punkte hinsichtlich der Leistung mit sich. Ein einzelnes Visual kann dazu führen, dass Abfragen an mehrere Quellen gesendet werden, wodurch die Ergebnisse häufig von einer Abfrage zu einer zweiten Quelle weitergeleitet werden. Diese Situation kann in den folgenden Ausführungsmöglichkeiten eintreten:

• Eine Quell-Abfrage, die eine große Anzahl an literalen Werten enthält: Zum Beispiel ein Visual, das den gesamten Sales Amount-Wert für eine Reihe ausgewählter Product Managers enthält, die zunächst ermitteln müssen, welche Produkte von diesen Product Managers verwaltet wurden. Diese Sequenz muss erfolgen, bevor das Visual eine SQL-Abfrage sendet, die alle Produkt-IDs in einer WHERE-Klausel enthält.

• Eine Quell-Abfrage, die auf einer niedrigeren Granularitätsebene abfragt, wobei die Daten später lokal aggregiert werden: Da die Anzahl der Produkte zunimmt, die den Filterkriterien unter Product Manager entsprechen, kann es ineffizient oder nicht praktikabel sein, alle Produkte in einer WHERE-Klausel zusammenzufassen. Stattdessen können Sie die relationale Quelle auf der unteren Products-Ebene abfragen und die Ergebnisse dann lokal aggregieren. Wenn die Kardinalität der Produkte einen Grenzwert von 1 Million überschreitet, tritt bei der Abfrage ein Fehler auf.

• Mehrere Quell-Abfragen, eine pro Gruppe nach Wert: Wenn die Aggregation DistinctCount eine Gruppierung nach einer bestimmten Spalte aus einer anderen Quelle verwendet, muss eine SQL-Abfrage pro Gruppe nach Wert gesendet werden, wenn die externe Quelle keine effiziente Übergabe von vielen Literalwerten mit definierter Gruppierung unterstützt.

  Ein Visual, das eine diskrete Anzahl von CustomerAccountNumber-Werten (aus der SQL Server-Tabelle) nach ProductManagers-Werten (aus dem Arbeitsblatt) anfordert, muss die Details aus der Tabelle ProductManagers in der Abfrage übergeben, die an SQL Server gesendet wird. Diese Aktion ist für andere Quellen – z. B. Redshift – nicht durchführbar. Stattdessen müsste eine SQL-Abfrage pro Sales Manager gesendet werden, bis zu einem bestimmten durchführbaren Grenzwert, bei dessen Überschreitung die Abfrage einen Fehler verursachen würde.

Jeder dieser Fälle bringt andere Folgen für die Leistung mit sich, wobei die jeweiligen Details je nach Datenquelle variieren können. Obwohl die Kardinalität der in der Beziehung verwendeten Spalten zur Verknüpfung der zwei Quellen weiterhin gering ausfällt (im vierstelligen Bereich), sollte die Leistung nicht beeinträchtigt werden. Mit zunehmender Kardinalität sollten Sie Ihre Aufmerksamkeit auf den Einfluss auf die resultierende Leistung richten.

Darüber hinaus hat die Verwendung von m:n-Beziehungen zur Folge, dass die Einzelwerte nicht lokal aggregiert werden, sondern dass für die einzelnen Ebenen der Gesamt- bzw. Zwischensumme separate Abfragen an die zugrunde liegende Quelle gesendet werden müssen. Ein einfaches Tabellenvisual mit Gesamtbeträgen würde anstelle von einer Quell-Abfrage zwei senden.

Quellgruppen

Eine Quellgruppe ist eine Sammlung von Elementen, wie zum Beispiel Tabellen und Beziehungen, aus einer DirectQuery-Quelle oder allen an einem Datenmodell beteiligten Importquellen. Ein zusammengesetztes Modell besteht aus einer oder mehreren Quellgruppen. Betrachten Sie die folgenden Beispiele:

• Ein zusammengesetztes Modell, das eine Verbindung mit einem Power BI-Semantikmodell namens Umsatz herstellt und das Semantikmodell erweitert, indem ein im ursprünglichen Semantikmodell nicht verfügbares Measure Umsatz seit Jahresbeginn hinzugefügt wird. Dieses Modell umfasst eine Quellgruppe.
• Ein zusammengesetztes Modell, das Daten aus dem Import einer Tabelle aus einer Excel-Arbeitsmappe namens Ziele und einer CSV-Datei namens Regionen kombiniert und eine DirectQuery-Verbindung mit einem Power BI-Semantikmodell namens Umsatz herstellt. In diesem Fall gibt es zwei Quellgruppen, wie in der folgenden Abbildung dargestellt:
  • Die erste Quellgruppe enthält die Tabellen aus der Excel-Arbeitsmappe Ziele und die CSV-Datei Regionen.
  • Die zweite Quellgruppe enthält die Elemente aus dem Power BI-Semantikmodell Umsatz.

Wenn Sie eine weitere DirectQuery-Verbindung mit einer anderen Quelle hinzugefügt haben, z. B. eine DirectQuery-Verbindung mit einer SQL Server-Datenbank namens Inventory (Bestand), werden die Elemente aus dieser Quelle als eine weitere Quellgruppe hinzugefügt:

Quellgruppen und Beziehungen

Es gibt zwei Arten von Beziehungen in einem zusammengesetzten Modell:

• Quellgruppeninterne Beziehungen Diese Beziehungen verknüpfen Elemente innerhalb einer Quellgruppe miteinander. Diese Beziehungen sind immer reguläre Beziehungen, sofern sie nicht den Typ m:n aufweisen. In diesem Fall sind sie eingeschränkt.
• Quellgruppenübergreifende Beziehungen Diese Beziehungen beginnen in einer Quellgruppe und enden in einer anderen Quellgruppe. Diese Beziehungen sind immer eingeschränkte Beziehungen.

Lesen Sie mehr über den Unterschied zwischen regulären und eingeschränkten Beziehungen und deren Auswirkungen.

Auf der folgenden Abbildung haben wir zum Beispiel drei quellgruppenübergreifende Beziehungen hinzugefügt, die Tabellen verschiedener Quellgruppen miteinander verknüpfen:

Lokal und remote

Jedes Element in einer DirectQuery-Quellgruppe wird als remote betrachtet, es sei denn, das Element wurde lokal als Teil einer Erweiterung oder Anreicherung der DirectQuery-Quelle definiert und ist kein Teil der Remotequelle, z. B. ein Measure oder eine berechnete Tabelle. Eine berechnete Tabelle basierend auf einer Tabelle aus der DirectQuery-Quellgruppe gehört zur Quellgruppe „Import“ und wird als lokal betrachtet. Jedes Element in der Quellgruppe „Import“ gilt als lokal. Wenn Sie beispielsweise das folgende Measure in einem zusammengesetzten Modell definieren, das eine DirectQuery-Verbindung mit der Quelle „Bestand“ verwendet, wird das Measure als lokal betrachtet:

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

Berechnungsgruppen, Abfragen und Measureauswertung

Berechnungsgruppen bieten eine Möglichkeit, die Anzahl redundanter Measures zu verringern und gemeinsame Measureausdrücke zu gruppieren. Typische Anwendungsfälle sind Business-Intelligence-Berechnungen auf Zeitbasis, bei denen Sie von Istwerten zu Berechnungen von Monat bis heute, Quartal bis heute oder Jahr bis heute wechseln müssen. Bei der Arbeit mit zusammengesetzten Modellen ist es wichtig, die Interaktion zwischen Berechnungsgruppen zu berücksichtigen und zu beachten, ob ein Measure nur auf Elemente aus einer einzelnen Remotequellgruppe verweist. Wenn ein Measure nur auf Elemente aus einer einzigen Remotequellgruppe verweist und das Remotemodell eine Berechnungsgruppe definiert, die sich auf das Measure auswirkt, wird diese Berechnungsgruppe angewendet, auch wenn das Measure im Remotemodell oder im lokalen Modell definiert wurde. Wenn ein Measure jedoch nicht ausschließlich auf Elemente aus einer einzelnen Remotequellgruppe verweist, sondern auch auf Elemente aus einer Remotequellgruppe, auf die eine Remoteberechnungsgruppe angewandt wird, können die Ergebnisse des Measures auch von der Remoteberechnungsgruppe beeinflusst werden. Betrachten Sie das folgenden Beispiel:

• „Handelspartnerumsatz“ ist ein Measure, das im Remotemodell definiert ist.
• Das Remotemodell enthält eine Berechnungsgruppe, die das Ergebnis von „Handelspartnerumsatz“ ändert.
• „Internetumsatz“ ist ein Measure, das im lokalen Modell definiert ist.
• „Gesamtumsatz“ ist ein Measure, das im lokalen Modell definiert ist und die folgende Definition aufweist:

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

In diesem Szenario wirkt sich das Measure Internetumsatz nicht auf die im Remotemodell definierte Berechnungsgruppe aus, da sie nicht zum selben Modell gehört. Die Berechnungsgruppe kann jedoch das Ergebnis des Measures Handelspartnerumsatz ändern, da sie sich im selben Modell befindet. Diese Tatsache bedeutet, dass die vom Measure Gesamtumsatz zurückgegebenen Ergebnisse sorgfältig ausgewertet werden müssen. Angenommen, wir verwenden die Berechnungsgruppe im Remotemodell, um Ergebnisse seit Jahresbeginn zurückzugeben. Das von Handelspartnerumsatz zurückgegebene Ergebnis ist jetzt ein Wert seit Jahresbeginn, während das von Internetumsatz zurückgegebene Ergebnis weiterhin ein Istwert ist. Das Ergebnis von Gesamtumsatz ist nun wahrscheinlich unerwartet, da es ein Istwertergebnis auf ein Ergebnis seit Jahresbeginn addiert.

Zusammengesetzte Modelle für Power BI-Semantikmodelle und Analysis Services

Mithilfe zusammengesetzter Modelle mit Power BI-Semantikmodellen und Analysis Services können Sie ein zusammengesetztes Modell mithilfe einer DirectQuery-Verbindung erstellen, um eine Verbindung mit Power BI-Semantikmodellen, Azure Analysis Services (AAS) und SQL Server 2022 Analysis Services herzustellen. Mithilfe eines zusammengesetzten Modells können Sie die Daten in diesen Quellen mit anderen DirectQuery- und importierten Daten kombinieren. Berichtsautoren, die die Daten aus ihrem semantischen Unternehmensmodell mit anderen Daten in ihrem Besitz kombinieren möchten, z. B. mit einer Excel-Tabelle, oder die Metadaten aus ihrem semantischen Unternehmensmodell personalisieren oder anreichern möchten, werden dieses Funktion besonders nützlich finden.

Verwalten von zusammengesetzten Modellen in Power BI-Semantikmodellen

Um die Erstellung und den Verbrauch zusammengesetzter Modelle in Power BI-Semantikmodellen zu ermöglichen, müssen für Ihren Mandanten die folgenden Optionen aktiviert sein:

• Zulassen von XMLA-Endpunkten und „In Excel analysieren“ mit lokalen Semantikmodellen. Wenn diese Option deaktiviert ist, kann keine DirectQuery-Verbindung mit einem Power BI-Semantikmodell hergestellt werden.
• Benutzer können über eine Liveverbindung mit Power BI-Semantikmodellen in Excel arbeiten. Wenn diese Option deaktiviert ist, können Benutzer keine Liveverbindungen mit Power BI-Semantikmodellen herstellen, sodass die Schaltfläche Änderungen an diesem Modell vornehmen nicht erreicht werden kann.
• DirectQuery-Verbindung mit Power BI-Semantikmodellen zulassen. Weitere Informationen zu dieser Option und zu den Auswirkungen der Deaktivierung finden Sie in den folgenden Abschnitten.

Darüber hinaus sollte für Premium-Kapazitäten und die Premium-Einzelbenutzerlizenz die Einstellung „XMLA-Endpunkt“ aktiviert und auf „Schreibgeschützt“ oder „Lesen/Schreiben“ festgelegt werden.

Mandantenadministratoren können DirectQuery-Verbindungen mit Power BI-Semantikmodellen im Verwaltungsportal aktivieren oder deaktivieren. Während diese standardmäßig aktiviert sind, werden mit deren Deaktivierung Benutzer an der Veröffentlichung neuer zusammengesetzter Modelle für semantische Power BI-Modelle in dem Dienst gehindert.

Vorhandene Berichte, die ein zusammengesetztes Modell für ein semantisches Power BI-Modell nutzen, funktionieren weiterhin, und Benutzer können das zusammengesetzte Modell weiterhin mithilfe von Desktop erstellen, es aber nicht in dem Dienst veröffentlichen. Stattdessen erhalten Sie, wenn Sie eine DirectQuery-Verbindung mit dem Power BI-Semantikmodell erstellen, indem Sie Änderungen an diesem Modell vornehmen auswählen, die folgende Warnmeldung:

Auf diese Weise können Sie das Semantikmodell immer noch in Ihrer lokalen Power BI Desktop-Umgebung erkunden und das zusammengesetzte Modell erstellen. Sie können den Bericht jedoch nicht im Dienst veröffentlichen. Wenn Sie den Bericht und das Modell veröffentlichen, wird die folgende Fehlermeldung angezeigt, und die Veröffentlichung wird blockiert:

Weder Liveverbindungen mit semantischen Power BI-Modellen noch Live- oder DirectQuery-Verbindungen mit Analysis Services werden von der Option beeinflusst. Diese funktionieren weiterhin unabhängig davon, ob die Option deaktiviert wurde. Auch alle veröffentlichten Berichte, die ein zusammengesetztes Modell für ein semantisches Power BI-Modell nutzen, funktionieren weiterhin, auch wenn die Option nach der Veröffentlichung deaktiviert wurde.

Erstellen eines zusammengesetzten Modells für ein Semantikmodell oder Modell

Für das Erstellen eines zusammengesetzten Modells in einem Power BI-Semantikmodell oder Analysis Services-Modell muss Ihr Bericht über ein lokales Modell verfügen. Sie können von einer Liveverbindung aus starten, ein lokales Modell hinzufügen oder darauf upgraden oder mit einer DirectQuery-Verbindung oder importierten Daten beginnen, wodurch in Ihrem Bericht automatisch ein lokales Modell erstellt wird.

Um zu prüfen, welche Verbindungen in Ihrem Modell verwendet werden, sehen Sie rechts unten in Power BI Desktop auf der Statusleiste nach. Wenn Sie nur mit einer Analysis Services-Quelle verbunden sind, sehen Sie eine Meldung wie in der folgenden Abbildung:

Wenn Sie mit einem Power BI-Semantikmodell verbunden sind, sehen Sie eine Meldung, die angibt, mit welchem Power BI-Semantikmodell Sie verbunden sind:

Wenn Sie die Metadaten der Felder in Ihrem live verbundenen Semantikmodell anpassen möchten, wählen Sie auf der Statusleiste Änderungen an diesem Modell vornehmen aus. Alternativ können Sie auch auf die Schaltfläche Make changes to this model (Änderungen an diesem Modell vornehmen) auf dem Menüband klicken, wie in der folgenden Abbildung gezeigt. In der Berichtsansicht befindet sich die Schaltfläche Make changes to this model (Änderungen an diesem Modell vornehmen) auf der Registerkarte Modellierung. In der Modellansicht befindet sich die Schaltfläche auf der Registerkarte Start.

Wenn Sie die Schaltfläche auswählen, wird ein Dialogfeld angezeigt, in dem das Hinzufügen eines lokalen Modells bestätigt wird. Wählen Sie Lokales Modell hinzufügen aus, damit das Erstellen neuer Spalten oder das Ändern der Metadaten für Felder aus Power BI-Semantikmodellen oder Analysis Services aktiviert wird. Die folgende Abbildung zeigt das angezeigte Dialogfeld.

Wenn Sie eine Liveverbindung mit einer Analysis Services Quelle hergestellt haben, ist kein lokales Modell vorhanden. Um DirectQuery für live verbundene Quellen wie Power BI-Semantikmodelle und Analysis Services zu verwenden, müssen Sie Ihrem Bericht ein lokales Modell hinzufügen. Wenn Sie einen Bericht mit einem lokalen Modell im Power BI-Dienst veröffentlichen, wird auch ein Semantikmodell für dieses lokale Modell veröffentlicht.

Verketten

Semantikmodelle sowie die Semantikmodelle, auf denen sie basieren, bilden eine Kette. Mit diesem Verkettung genannten Prozess können Sie einen Bericht und ein Semantikmodell basierend auf anderen Power BI-Semantikmodellen veröffentlichen, was bisher nicht möglich war.

Stellen Sie sich beispielsweise vor, Ihr Kollege veröffentlicht ein semantisches Power BI-Modell mit dem Namen Umsatz und Budget, das auf einem Analysis Services-Modell mit dem Namen Umsatz basiert, und kombiniert es mit einer Excel-Tabelle mit dem Namen Budget.

Wenn Sie einen neuen Bericht (und ein neues semantisches Modell) namens Umsatz und Budget Europa veröffentlichen, das auf dem von Ihrem Kollegen veröffentlichten semantisches Power BI-Modell Umsatz und Budget basiert, erfolgt bei weiteren Änderungen oder Erweiterungen tatsächlich das Hinzufügen eines Berichts und semantisches Modell zu einer Kette der Länge drei. Diese begann mit dem Analysis Services-Modell Umsatz und endet mit Ihrem semantisches Power BI-Modell Umsatz und Budget Europa. Die folgende Abbildung veranschaulicht diesen Verkettungsprozess.

Die Kette in der vorherigen Abbildung hat die Länge drei, was die maximale Länge ist. Eine höhere Kettenlänge als drei wird nicht unterstützt und führt zu Fehlern.

Berechtigungen und Lizenzierung

Benutzer, die mithilfe eines Verbundmodells auf Berichte zugreifen, müssen über die erforderlichen Berechtigungen für alle Semantikmodelle und Modelle in der Kette verfügen.

Der Besitzer des Verbundmodells benötigt eine Build-Berechtigung für die Semantikmodelle, die als Quellen verwendet werden, damit andere Benutzer im Namen des Besitzers auf diese Modelle zugreifen können. Das Erstellen der Verbundmodellverbindung in Power BI Desktop und das Erstellen des Berichts in Power BI erfordern daher Build-Berechtigungen für die Semantikmodelle, die als Quellen verwendet werden.

Benutzer, die Berichte mit dem Verbundmodell anzeigen, benötigen in der Regel Leseberechtigungen für das Verbundmodell selbst und die Semantikmodelle, die als Quellen verwendet werden. Build-Berechtigungen sind möglicherweise erforderlich, wenn sich die Berichte in einem Pro-Arbeitsbereich befinden. Diese Mandantenwechsel sollten für Benutzer aktiviert werden.

Die erforderlichen Berechtigungen können mit dem folgenden Beispiel veranschaulicht werden:

• Verbundmodell A (im Besitz von Besitzer A)

  • Datenquelle A1: Semantikmodell B.
    Besitzer A muss über die Berechtigung Build für Semantikmodell B verfügen, damit Benutzer den Bericht mithilfe von dem Verbundmodell A anzeigen können.

• Verbundmodell C (im Besitz von Besitzer C)

  • Datenquelle C1: Semantikmodell D
    Besitzer C muss über die Berechtigung Build für Semantikmodell D verfügen, damit Benutzer den Bericht mithilfe von dem Verbundmodell A anzeigen können.
  • Datenquelle C2: Verbundmodell A
    Besitzer C muss über die Berechtigung Build für das Verbundmodell A und Lesen für Semantikmodell B verfügen.

Ein Benutzer, der Berichte mit dem Verbundmodell A anzeigt, muss über Leseberechtigungen für Verbundmodell A und Semantikmodell B verfügen, während ein Benutzer, der Berichte mithilfe von Verbundmodell C anzeigt, über Leseberechtigungen für das Verbundmodell C, Semantikmodell D , Verbundmodell A und Semantikmodell B verfügen muss.

Wenn sich ein Dataset in der Kette in einem Arbeitsbereich mit Premium-Einzelbenutzerlizenz befindet, ist für den Benutzerzugriff eine Premium-Einzelbenutzerlizenz erforderlich. Wenn sich ein Dataset in der Kette in einem Pro-Arbeitsbereich befindet, ist für den Benutzerzugriff eine Pro-Lizenz erforderlich. Wenn sich alle Datasets in der Kette in Premium-Kapazitäten oder Fabric F64-Kapazitäten oder höher befinden, können Benutzer*innen über eine Free-Lizenz darauf zugreifen.

Sicherheitswarnung

Bei Verwenden des Features Zusammengesetzte Modelle für semantische Power BI-Modelle und Analysis Services-Modelle wird, wie in der folgenden Abbildung gezeigt, ein Dialogfeld mit einer Sicherheitswarnung eingeblendet.

Daten können per Push aus einer Datenquelle in eine andere verschoben werden, was der Sicherheitswarnung für das Kombinieren von DirectQuery und Importquellen in einem Datenmodell entspricht. Weitere Informationen zu diesem Verhalten finden Sie unter Verwenden von zusammengesetzten Modellen in Power BI Desktop.

Unterstützte Szenarios

Sie können zusammengesetzte Modelle mithilfe von Daten aus Power BI-Semantikmodellen oder Analysis Services-Modellen erstellen, um die folgenden Szenarien zu unterstützen:

• Verbinden mit Daten aus verschiedenen Quellen: Importe (z. B. Dateien), Power BI-Semantikmodelle, Analysis Services-Modelle
• Erstellen von Beziehungen zwischen verschiedenen Datenquellen
• Schreiben von Measures, die Felder aus unterschiedlichen Datenquellen verwenden
• Erstellen neuer Spalten für Tabellen aus Power BI-Semantikmodellen oder Analysis Services-Modellen
• Erstellen von Visuals, die Spalten aus unterschiedlichen Datenquellen verwenden
• Sie können eine Tabelle mithilfe der Feldliste aus Ihrem Modell entfernen, um Modelle so präzise und schlank wie möglich zu halten (wenn Sie eine Verbindung mit einer Perspektive herstellen, können Sie keine Tabellen aus dem Modell entfernen).
• Sie können angeben, welche Tabellen geladen werden sollen, anstatt alle Tabellen laden zu müssen, wenn Sie nur eine bestimmte Teilmenge von Tabellen aufrufen möchten. Weitere Informationen finden Sie unter „Laden einer Teilmenge von Tabellen“ weiter unten in diesem Dokument.
• Sie können angeben, ob dem semantischen Modell Tabellen hinzugefügt werden sollen, die später hinzugefügt werden, nachdem Sie die Verbindung in Ihrem Modell hergestellt haben.

Arbeiten mit einem zusammengesetzten Modell basierend auf einem Semantikmodell

Berücksichtigen Sie beim Arbeiten mit DirectQuery für semantische Power BI-Modelle und Analysis Services Folgendes:

• Wenn Sie Ihre Datenquellen aktualisieren und es Fehler mit in Konflikt stehenden Feld- oder Tabellennamen gibt, behebt Power BI die Fehler für Sie.

• Sie können im selben semantischen Power BI-Modell oder derselben Analysis Services-Quelle keine neuen Beziehungen bearbeiten, löschen oder erstellen. Wenn du Zugriff auf diese Quellen hast, kannst du stattdessen die Änderungen direkt in der Datenquelle vornehmen.

• Sie können die Datentypen von Spalten, die aus einem Power BI-Semantikmodell oder einer Analysis Services-Quelle geladen werden, nicht ändern. Wenn Sie den Datentyp ändern müssen, ändern Sie ihn entweder in der Quelle, oder verwenden Sie eine berechnete Spalte.

• Um Berichte im Power BI-Dienst für ein zusammengesetztes Modell zu erstellen, das auf einem anderen semantischen Modell basiert, müssen alle Anmeldeinformationen festgelegt sein.

• Verbindungen mit einem SQL Server 2022 und höher, einem lokalen Analysis Services-Server oder mit IAAS erfordern ein lokales Datengateway (Standardmodus).

• Alle Verbindungen mit Modellen für Power BI-Remote-Semantikmodellen werden mithilfe einmaligen Anmeldens vorgenommen. Die Authentifizierung mit einem Dienstprinzipal wird derzeit nicht unterstützt.

• RLS-Regeln (Row-Level Security, Sicherheit auf Zeilenebene) werden auf die Quelle angewendet, für die sie definiert sind, aber nicht auf andere semantischen Modelle im Modell. Im Bericht definierte RLS wird nicht auf Remotequellen angewendet, und RLS, die für Remotequellen festgelegt wurde, wird nicht auf andere Datenquellen angewendet. Außerdem können Sie RLS nicht für eine Tabelle definieren, die aus einer Remotequelle geladen wurde, und RLS, die in lokalen Tabellen definiert ist, filtert keine Tabellen, die aus einer Remotequelle geladen werden.

• KPIs, die Sicherheit auf Zeilenebene und Übersetzungen werden nicht aus der Quelle importiert.

• Bei Verwendung einer Datumshierarchie kann es zu unerwartetem Verhalten kommen. Um dieses Problem zu beheben, verwenden Sie stattdessen eine Datumsspalte. Nach dem Hinzufügen einer Datumshierarchie zu einem Visual können Sie zu einer Datumsspalte wechseln, indem Sie im Feldnamen auf den Abwärtspfeil klicken und dann auf den Namen dieses Feldes klicken, anstatt Datumshierarchie zu verwenden:

  

  Weitere Informationen zur Verwendung von Datumsspalten im Vergleich zu Datumshierarchien finden Sie unter Anwenden der automatischen Angabe von Datum oder Uhrzeit in Power BI Desktop.

• Die maximale Länge einer Modellkette beträgt drei. Eine höhere Kettenlänge als drei wird nicht unterstützt und führt zu Fehlern.

• Das Flag discourage chaining (Verkettung abhalten) kann für ein Modell festgelegt werden, um zu verhindern, dass eine Kette erstellt oder erweitert wird. Weitere Informationen finden Sie unter Verwalten von DirectQuery-Verbindungen mit einem veröffentlichten Semantikmodell.

• Die Verbindung mit einem semantischen Power BI-Modell oder einem Analysis Services-Modell wird in Power Query nicht angezeigt.

Die folgenden Einschränkungen gelten, beim Arbeiten mit DirectQuery für Power BI-Semantikmodelle und Analysis Services:

• Parameter für Datenbank- und Servernamen sind derzeit deaktiviert.
• Das Definieren von RLS für Tabellen aus einer Remotequelle wird nicht unterstützt.
• Die Verwendung einer der folgenden Quellen als DirectQuery-Quelle wird nicht unterstützt:
  • SQL Server Analysis Services (SSAS) – Tabellarische Modelle vor Version 2022
  • Mehrdimensionale SSAS-Modelle
  • SAP HANA
  • SAP Business Warehouse
  • Semantikmodelle in Echtzeit
  • Beispielsemantikmodelle
  • Aktualisierung von Excel für das Web
  • Aus Excel- oder CSV-Dateien im Dienst importierte Daten
  • Nutzungsmetriken
  • Semantikmodelle, die in „Mein Arbeitsbereich“ gespeichert sind
• Die Verwendung von Power BI Embedded mit Semantikmodellen, die eine DirectQuery-Verbindung zu einem Analysis Services-Modell enthalten, wird derzeit nicht unterstützt.
• Das Veröffentlichen eines Berichts im Web mithilfe des Features „Im Web veröffentlichen“ wird nicht unterstützt.
• Berechnungsgruppen für Remotequellen werden nicht unterstützt und liefern undefinierte Abfrageergebnisse.

• Berechnete Tabellen und Spalten, die auf eine DirectQuery-Tabelle aus einer Datenquelle mit SSO-Authentifizierung verweisen, werden im Power BI-Dienst mit einer zugewiesenen freigabefähigen Cloudverbindung und/oder präziser Zugriffskontrolle unterstützt.

• Wenn Sie einen Arbeitsbereich umbenennen, nachdem die DirectQuery-Verbindung eingerichtet wurde, müssen Sie die Datenquelle in Power BI Desktop aktualisieren, damit der Bericht weiterhin funktioniert.
• Die automatische Seitenaktualisierung wird je nach Datenquellentyp nur für einige Szenarien unterstützt. Weitere Informationen finden Sie unter Automatische Seitenaktualisierung in Power BI.
• Die Übernahme eines Semantikmodells, welches das Feature DataQuery für andere Datasets verwendet, wird derzeit nicht unterstützt.
• Wie bei jeder DirectQuery-Datenquelle werden Hierarchien, die in einem Analysis Services-Modell oder in einem semantischen Power BI-Modell definiert sind, nicht angezeigt, wenn eine Verbindung mit dem Modell oder semantischen Modell im DirectQuery-Modus über Excel hergestellt wird.

Bei der Arbeit mit DirectQuery für Power BI-Semantikmodelle und Analysis Services sind weitere Punkte zu beachten:

• Verwenden von Spalten mit geringer Kardinalität in quellübergreifenden Gruppenbeziehungen: Wenn Sie eine Beziehung über zwei verschiedene Quellgruppen erstellen, sollten die an der Beziehung beteiligten Spalten (auch als „Joinspalten“ bezeichnet) eine geringe Kardinalität aufweisen, idealerweise 50.000 oder weniger. Dieser Hinweis gilt für Nicht-Zeichenfolgenschlüsselspalten. Informationen zu Zeichenfolgenschlüsselspalten finden Sie im folgenden Hinweis.
• Vermeiden Sie die Verwendung großer Zeichenfolgenschlüsselspalten in quellübergreifenden Gruppenbeziehungen: Vermeiden Sie beim Erstellen einer quellübergreifenden Gruppenbeziehung die Verwendung großer Zeichenfolgenspalten als Beziehungsspalten, insbesondere für Spalten mit größerer Kardinalität. Wenn Sie Zeichenfolgenspalten als Beziehungsspalte verwenden müssen, berechnen Sie die erwartete Zeichenfolgenlänge für den Filter, indem Sie die Kardinalität (C) mit der durchschnittlichen Länge der Zeichenfolgenspalte (A) multiplizieren. Stellen Sie sicher, dass die erwartete Zeichenfolgenlänge unter 250.000 liegt, sodass A ∗ C < 250.000.

Weitere Überlegungen und Anleitungen finden Sie unter Leitfaden zu zusammengesetzten Modellen.

Überlegungen zu Mandanten

Jedes Modell mit einer DirectQuery-Verbindung mit einem Power BI-Semantikmodell oder mit Analysis Services muss im selben Mandanten veröffentlicht werden. Dies ist besonders wichtig, wenn Sie mithilfe von B2B-Gastidentitäten auf ein Power BI-Semantikmodell oder ein Analysis Services-Modell zugreifen, wie im folgenden Diagramm dargestellt. Lesen Sie Gastbenutzer, die Inhalte bearbeiten und verwalten können, um die Mandanten-URL für die Veröffentlichung zu finden.

Betrachten Sie das folgende Diagramm: Die nummerierten Schritte im Diagramm werden in den folgenden Absätzen beschrieben.

Im Diagramm arbeitet Ash mit Contoso zusammen und greift auf die von Fabrikam bereitgestellten Daten zu. Ash erstellt mit Power BI Desktop eine DirectQuery-Verbindung mit einem Analysis Services-Modell, das im Mandanten von Fabrikam gehostet wird.

Zur Authentifizierung verwendet Ash eine B2B-Gastbenutzeridentität (Schritt 1 im Diagramm).

Wenn der Bericht im Power BI-Dienst von Contoso veröffentlicht wird (Schritt 2), kann sich das im Contoso-Mandanten veröffentlichte semantische Modell nicht erfolgreich beim Analysis Services-Modell von Fabrikam authentifizieren (Schritt 3). Daher funktioniert der Bericht nicht.

Da das verwendete Analysis Services-Modell in diesem Szenario im Mandanten von Fabrikam gehostet wird, muss der Bericht auch im Mandanten von Fabrikam veröffentlicht werden. Nach erfolgreicher Veröffentlichung im Fabrikam-Mandanten (Schritt 4) kann das semantische Modell erfolgreich auf das Analysis Services-Modell (Schritt 5) zugreifen, und der Bericht funktioniert ordnungsgemäß.

Arbeiten mit Sicherheit auf Objektebene (Object-Level Security, OLS)

Wenn ein zusammengesetztes Modell über eine DirectQuery-Verbindung Daten aus einem semantischen Power BI-Modell oder aus Analysis Services erhält und das Quellmodell durch Sicherheit auf Objektebene geschützt ist, erhalten die Benutzer des zusammengesetzten Modells möglicherweise unerwartete Ergebnisse. Im folgenden Abschnitt wird erläutert, wie diese Ergebnisse zustande kommen können.

Mithilfe der Sicherheit auf Objektebene (Object-Level Security, OLS) können Modellautoren Objekte, aus denen ein Modellschema besteht (d. h. Tabellen, Spalten, Metadaten usw.), vor Modellverbrauchern (z. B. einem Berichtsersteller oder dem Autor eines zusammengesetzten Modells) verbergen. Beim Konfigurieren von OLS für ein Objekt erstellt der Modellautor zunächst eine Rolle und entfernt dann den Zugriff auf das Objekt für Benutzer, die dieser Rolle zugewiesen sind. Aus Sicht dieser Benutzer ist das ausgeblendete Objekt dann einfach nicht vorhanden.

OLS wird für das Quellmodell definiert und angewendet. Sie kann nicht für das auf dem Quellmodell basierende zusammengesetzte Modell definiert werden.

Wenn man ein Verbundmodell, über eine DirectQuery-Verbindung auf Basis eines OLS-geschützten Power BI-Semantikmodells oder Analysis Services-Modells erstellt, dann wird das Modellschema des Quellmodells in das Verbundmodell kopiert. Was genau kopiert wird, hängt jedoch davon ab, was der Autor des zusammengesetzten Modells gemäß den geltenden OLS-Regeln im Quellmodell sehen darf. Die Daten werden nicht in das zusammengesetzte Modell kopiert, sondern bei Bedarf immer über DirectQuery aus dem Quellmodell abgerufen. Das heißt, der Datenabruf geht immer wieder zum Quellmodell zurück, für das die OLS-Regeln gelten.

Da das zusammengesetzte Modell nicht durch OLS-Regeln geschützt ist, handelt es sich bei den Objekten, die die Verbraucher des zusammengesetzten Modells sehen, um jene Objekte, die der Autor des zusammengesetzten Modells im Quellmodell sehen konnte; jedoch nicht zwangsläufig um die Objekte, auf die sie selbst Zugriff haben. Aus diesem Grund könnten die folgenden Situationen entstehen:

• Jemand, der sich das zusammengesetzte Modell ansieht, kann möglicherweise Objekte sehen, die vor ihm durch die OLS-Regeln im Quellmodell verborgen werden.
• Im Gegensatz dazu sieht er im zusammengesetzten Modell möglicherweise ein Objekt NICHT, das er im Quellmodell sehen KANN, weil dieses Objekt vor dem Autor des zusammengesetzten Modells durch die OLS-Regeln, die den Zugriff auf das Quellmodell steuern, verborgen wurde.

Wichtig ist dabei, dass die Benutzer des zusammengesetzten Modells – trotz des im ersten Punkt genannten Falls – niemals Daten sehen, die sie nicht sehen dürfen, da sich die Daten nicht im zusammengesetzten Modell befinden. Stattdessen werden die Daten über DirectQuery nach Bedarf aus dem Quell-Semantikmodell abgerufen, wobei OLS nicht autorisierte Zugriffe blockiert.

Betrachten wir vor diesem Hintergrund das folgende Szenario:

1. Admin_user hat mithilfe eines semantischen Power BI-Modells oder eines Analysis Services-Modells ein semantisches Enterprise-Modell veröffentlicht, das eine Customer-Tabelle und eine Territory-Tabelle enthält. Admin_user veröffentlicht das Semantikmodell im Power BI-Dienst und legt OLS-Regeln fest, welche die folgenden Auswirkungen haben:

   • Finanzbenutzer können die Tabelle „Customer“ nicht sehen
   • Marketingbenutzer können die Tabelle „Territory“ nicht sehen.

2. Finance_user veröffentlicht ein Semantikmodell mit dem Namen „Finanzsemantikmodell“ und einen Bericht namens „Finanzbericht“, der über DirectQuery eine Verbindung mit dem in Schritt 1 veröffentlichten Enterprise-Semantikmodell herstellt. Der Finanzbericht enthält ein Visual, das eine Spalte aus der Tabelle „Territory“ verwendet.

3. Marketing_user öffnet den Finanzbericht. Das Visual, das die Tabelle „Territory“ verwendet, wird zwar angezeigt, gibt jedoch einen Fehler zurück, da DirectQuery beim Öffnen des Berichts versucht, die Daten aus dem Quellmodell mithilfe der Anmeldeinformationen von Marketing_user abzurufen. Dieser kann die Tabelle „Territory“ jedoch gemäß den OLS-Regeln des Enterprise-Semantikmodells nicht sehen.

4. Marketing_user erstellt einen neuen Bericht namens „Marketingbericht“, der das Finanzsemantikmodell als Quelle verwendet. Die Feldliste enthält die Tabellen und Spalten, auf die Finance_user Zugriff hat. Deshalb wird zwar die Tabelle „Territory“ in der Feldliste angezeigt, aber nicht die Tabelle „Customer“. Wenn Marketing_user jedoch versucht, ein Visual zu erstellen, das eine Spalte aus der Tabelle „Territory“ nutzt, wird ihm ein Fehler zurückgegeben, da DirectQuery an diesem Punkt versucht, Daten aus dem Quellmodell mithilfe der Anmeldeinformationen von Marketing_user abzurufen. Hier kommen wieder die OLS-Regeln zum Einsatz, die den Zugriff blockieren. Dasselbe geschieht, wenn Marketing_user ein neues semantisches Modell und einen Bericht erstellt, die über DirectQuery eine Verbindung mit dem semantischen Modell „Finance“ herstellen. Er sieht dann zwar die Tabelle „Territory“ in der Feldliste, da Finance_user diese sehen kann, aber wenn er versucht, ein Visual auf Grundlage dieser Tabelle zu erstellen, wird dies durch die OLS-Regeln im semantischen Enterprise-Modell blockiert.

5. Nehmen wir nun an, dass Admin_user die OLS-Regeln für das Enterprise-Semantikmodell aktualisiert, um zu verhindern, dass Finanze_user die Tabelle „Territory“ sehen.

6. Die aktualisierten OLS-Regeln werden erst im Finanzsemantikmodell widergespiegelt, wenn es aktualisiert wird. Wenn Finance_user also das semantische Modell „Finance“ aktualisiert, wird die Tabelle „Territory“ nicht mehr in der Feldliste angezeigt, und das Visual im Finance-Bericht, das eine Spalte aus der Tabelle „Territory“ verwendet, gibt einen Fehler für Finance_user zurück, da dieser jetzt nicht mehr auf die Tabelle zugreifen darf.

Zusammenfassung:

• Die Verbraucher eines zusammengesetzten Modells sehen ein Ergebnis, das auf den OLS-Regeln basiert, die für den Autor des zusammengesetzten Modells zum Zeitpunkt der Modellerstellung gegolten haben. Wenn also ein neuer Bericht basierend auf dem zusammengesetzten Modell erstellt wird, zeigt die Feldliste die Tabellen an, auf die der Autor des zusammengesetzten Modells zum Zeitpunkt der Erstellung Zugriff hatte. Dies ist unabhängig davon, worauf der aktuelle Benutzer im Quellmodell Zugriff hat.
• OLS-Regeln können nicht für das zusammengesetzte Modell selbst definiert werden.
• Die Benutzer eines zusammengesetzten Modells werden niemals Daten sehen, die sie nicht sehen dürfen, denn die entsprechenden OLS-Regeln im Quellmodell blockieren den Zugriff, wenn DirectQuery versucht, die Daten mit ihren Anmeldeinformationen abzurufen.
• Wenn die OLS-Regeln des Quellmodells aktualisiert werden, wirken sich die Änderungen erst auf das zusammengesetzte Modell aus, nachdem dieses ebenfalls aktualisiert wurde.

Laden einer Teilmenge von Tabellen aus einem Power BI-Semantikmodell oder Analysis Services-Modell

Beim Herstellen einer Verbindung mit einem Power BI-Semantikmodell oder Analysis Services-Modell mithilfe einer DirectQuery-Verbindung können Sie entscheiden, mit welchen Tabellen eine Verbindung hergestellt werden soll. Sie können auch festlegen, dass automatisch eine Tabelle hinzugefügt wird, die dem Semantikmodell oder Modell hinzugefügt wird, nachdem Sie die Verbindung mit Ihrem Modell hergestellt haben. Wenn Sie eine Verbindung mit einer Perspektive herstellen, enthält Ihr Modell alle Tabellen im semantischen Modell, und alle Tabellen, die nicht in der Perspektive enthalten sind, werden ausgeblendet. Darüber hinaus wird jede Tabelle, die der Perspektive möglicherweise hinzugefügt wird, automatisch hinzugefügt. Im Menü Einstellungen können Sie sich entscheiden, ob Sie entweder automatisch eine Verbindung mit Tabellen herstellen möchten, die dem semantischen Modell hinzugefügt werden, oder nachdem Sie die Verbindung eingerichtet haben.

Dieses Dialogfeld wird für Liveverbindungen nicht angezeigt.

Einrichten von Deduplizierungsregeln

Sie können Deduplizierungsregeln angeben, um Maß- und Tabellennamen in einem zusammengesetzten Modell eindeutig zu halten, indem Sie die Option Einstellungen im vorherig gezeigten Dialogfeld verwenden:

Im vorherigen Beispiel haben wir „(marketing)“ als Suffix zu jedem Tabellen- oder Maßeinheitsnamen hinzugefügt, der in Konflikt mit einer anderen Quelle im zusammengesetzten Modell steht. Sie können Folgendes ausführen:

• geben Sie einen Text ein, der dem Namen von widersprüchlichen Tabellen oder Maßeinheiten hinzugefügt werden soll
• geben Sie an, ob der Text der Tabelle oder dem Maßeinheitsnamen als Präfix oder Suffix hinzugefügt werden soll
• wenden Sie die Deduplizierungsregel auf Tabellen, Maßeinheiten oder beides an
• Wählen Sie aus, ob die Deduplizierungsregel nur dann angewendet werden soll, wenn ein Namenskonflikt auftritt, oder sie immer angewendet werden soll. Standardmäßig wird die Regel nur angewendet, wenn eine Duplizierung auftritt. In unserem Beispiel wird bei allen Tabellen oder Maßeinheiten aus der Marketingquelle, die nicht über ein Duplikat in der Vertriebsquelle verfügt, der Name nicht geändert.

Nachdem Sie die Verbindungen herstellen und die Deduplizierungsregel eingerichtet haben, zeigt Ihre Feldliste sowohl „Kunde“ als auch „Kunde (Marketing)“ gemäß der in unserem Beispiel eingerichteten Deduplizierungsregel an:

Wenn Sie keine Deduplizierungsregel angeben oder die von Ihnen angegebenen Deduplizierungsregeln den Namenskonflikt nicht lösen, werden dennoch die Standarddeduplizierungsregeln angewendet. Die Standarddeduplizierungsregeln fügen dem Namen eines in Konflikt stehenden Elements eine Zahl hinzu. Bei einem Namenskonflikt in der Tabelle „Kunde“ wird eine der Tabellen mit der Bezeichnung „Kunde“ in „Kunde 2“ umbenannt.

XMLA-Änderungen und zusammengesetzte Modelle

Beim Ändern eines semantischen Modells mithilfe von XMLA müssen Sie die ChangedProperties - und PBI_RemovedChildren-Auflistung für das geänderte Objekt aktualisieren, um geänderte oder entfernte Eigenschaften einzuschließen. Wenn Sie diese Aktualisierung nicht ausführen, überschreiben Power BI-Modellierungstools möglicherweise alle Änderungen, wenn das Schema das nächste Mal mit dem zugeordneten Lakehouse synchronisiert wird.

Die unterstützten Modelle zum Ändern eines semantischen Modells mithilfe von XMLA sind die folgenden:

• Umbenennen von Tabellen/Spalten (ChangeProperty = Name)
• Entfernen einer Tabelle (Hinzufügen einer Tabelle zu PBI_RemovedChildren Anmerkung im Abfrageausdruck)

Überlegungen und Einschränkungen

Bei zusammengesetzten Modellen gibt es einige Überlegungen und Einschränkungen:

Verbindungen im gemischten Modus: Wenn Sie eine Verbindung mit einem gemischten Modus verwenden, die Onlinedaten (z. B. ein Power BI-Semantikmodell) und ein lokales Semantikmodell (z. B. eine Excel-Arbeitsmappe) enthält, müssen Sie die Gatewayzuordnung eingerichtet haben, damit visuelle Elemente ordnungsgemäß angezeigt werden.

Derzeit wird die inkrementelle Aktualisierung nur für zusammengesetzte Modelle unterstützt, die mit SQL-, Oracle- und Teradata-Datenquellen verbunden sind.

Die folgenden (mehrdimensionalen) Live Connect-Tabellenquellen können nicht mit zusammengesetzten Modellen verwendet werden:

• SAP HANA
• SAP Business Warehouse
• SQL Server Analysis Services früher als Version 2022
• Nutzungsmetriken (Mein Arbeitsbereich)

Die Verwendung von Streamingsemantikmodellen in zusammengesetzten Modellen wird nicht unterstützt.

Die bestehenden Einschränkungen für die Verwendung von DirectQuery gelten nach wie vor für die Verwendung des Features „Zusammengesetzte Modelle“. Viele dieser Einschränkungen gelten jetzt abhängig vom Speichermodus der Tabelle für eine einzelne Tabelle. Beispielsweise kann eine berechnete Spalte in einer importierten Tabelle auf andere Tabellen verweisen, die sich nicht in DirectQuery befinden, während eine berechnete Spalte in einer DirectQuery-Tabelle nach wie vor nur auf Spalten in derselben Tabelle verweisen kann. Es gelten weitere Einschränkungen für das Modell als Ganzes, wenn eine der Tabellen im Modell DirectQuery enthält. Das Feature QuickInsights ist nicht für Modelle verfügbar, wenn eine der Tabellen den Speichermodus „DirectQuery“ aufweist.

Wenn Sie die Sicherheit auf Zeilenebene in einem zusammengesetzten Modell mit einigen Tabellen im DirectQuery-Modus verwenden, müssen Sie das Modell aktualisieren, um neue Updates aus den DirectQuery-Tabellen anzuwenden. Wenn beispielsweise eine Benutzertabelle im DirectQuery-Modus neue Benutzerdatensätze an der Quelle enthält, werden die neuen Datensätze erst nach der nächsten Modellaktualisierung einbezogen. Power BI Service speichert die Benutzerabfrage zwischen, um die Leistung zu verbessern, und lädt die Daten erst aus der Quelle neu, wenn die nächste manuelle oder geplante Aktualisierung erfolgt.

Zugehöriger Inhalt

Weitere Informationen zu zusammengesetzten Modellen und DirectQuery finden Sie in den folgenden Artikeln:

• Anwenden von m:n-Beziehungen in Power BI Desktop
• Verwalten des Speichermodus in Power BI Desktop
• DirectQuery in Power BI
• Power BI-Datenquellen
• Modellieren von Beziehungen in Power BI Desktop