Leitfaden für zusammengesetzte Modelle in Power BI Desktop

Dieser Artikel richtet sich an Datenmodellierer, die zusammengesetzte Modelle für Power BI entwickeln. Er beschreibt Anwendungsfälle zusammengesetzter Modelle und bietet Ratschläge für das Design. In erster Linie hilft Ihnen dieser Leitfaden festzustellen, ob ein zusammengesetztes Modell für Ihre Lösung geeignet ist. Wenn dies der Fall ist, hilft Ihnen dieser Artikel auch beim Design optimaler Modelle und Berichte.

Anwendungsfälle für zusammengesetzte Modelle

Per Definition kombiniert ein zusammengesetztes Modell mehrere Quellgruppen. Bei einer Quellgruppe kann es sich um importierte Daten oder eine Verbindung mit einer DirectQuery-Quelle handeln. Eine DirectQuery-Quelle kann entweder eine relationale Datenbank oder ein anderes tabellarisches Modell sein, bei dem es sich um ein Power BI-Semantikmodell oder ein tabellarisches Analysis Services-Modell handeln kann. Ein tabellarisches Modell, das mit einem anderen tabellarischen Modell verknüpft ist, wird als Verkettung bezeichnet. Weitere Informationen finden Sie unter Verwenden von DirectQuery für Power BI-Semantikmodelle und Analysis Services.

Eine Verknüpfung mit tabellarischen Modellen bietet sich besonders dann an, wenn ein semantisches Unternehmensmodell, bei dem es sich um ein Power BI-Semantikmodell oder ein Analysis Services-Modell handelt, erweitert werden soll. Ein semantisches Unternehmensmodell ist für das Design und den Betrieb eines Data Warehouse von grundlegender Bedeutung. Es stellt zur Darstellung von Geschäftsdefinitionen und Terminologie eine Abstraktionsebene für die Daten im Data Warehouse bereit. Häufig wird es als Bindeglied zwischen physischen Datenmodellen und Berichterstellungstools wie Power BI verwendet. In den meisten Organisationen wird es von einem zentralen Team verwaltet, weshalb es auch als Unternehmensmodell bezeichnet wird. Weitere Informationen finden Sie im Nutzungsszenario zu Enterprise BI.

Ein zusammengesetztes Modell eignet sich in den folgenden Situationen:

• Sie haben bereits ein DirectQuery-Modell, dessen Leistung Sie verbessern möchten. In einem zusammengesetzten Modell können Sie die Leistung verbessern, indem Sie für jede Tabelle geeigneten Speicher einrichten. Sie können auch benutzerdefinierte Aggregationen hinzufügen. Beide Optimierungen werden weiter unten in diesem Artikel näher erläutert.
• Sie möchten ein DirectQuery-Modell durch zusätzliche Daten erweitern, die in das Modell importiert werden müssen. Die importierten Daten können Sie aus einer anderen Datenquelle oder aus berechneten Tabellen laden.
• Sie möchten zwei oder mehr DirectQuery-Datenquellen in einem einzelnen Modell kombinieren. Bei diesen Quellen kann es sich um relationale Datenbanken oder andere tabellarische Modelle handeln.

Auswerten anderer möglicher Modelldesigns

Zusammengesetzte Power BI-Modelle können zwar bestimmte Designprobleme lösen, jedoch auch die Leistung beeinträchtigen. In einigen Situationen, die weiter unten in diesem Artikel beschrieben werden, sind auch unerwartete Berechnungsergebnisse bekannt. Aus diesen Gründen sollten Sie für Ihre Lösung auch andere mögliche Modelldesigns auswerten.

Wenn möglich, sollten Sie ein Modell im Importmodus entwickeln. Er bietet größtmögliche Flexibilität für Entwürfe und die beste Leistung.

Allerdings können Herausforderungen, die im Zusammenhang mit großen Datenmengen oder der Berichterstellung bei Quasi-Echtzeitdaten stehen, nicht immer durch Importmodelle gelöst werden. In diesen Fällen würde sich ein DirectQuery-Modell anbieten, vorausgesetzt, Ihre Daten sind in einer einzelnen Datenquelle gespeichert, die vom DirectQuery-Modus unterstützt wird. Weitere Informationen finden Sie unter DirectQuery-Modelle in Power BI Desktop.

Tabellenspeichermodus

In einem zusammengesetzten Modell können Sie den Speichermodus jeder Tabelle (mit Ausnahme berechneter Tabellen) konfigurieren.

• DirectQuery: Dieser Modus empfiehlt sich für Tabellen, die große Datenmengen enthalten oder in Quasi-Echtzeit Ergebnisse liefern müssen. Daten werden nie in diese Tabellen importiert. In der Regel handelt es sich bei diesen Tabellen um Faktentabellen, also um zusammengefasste Tabellen.
• Import: Dieser Modus empfiehlt sich für Tabellen, die nicht zum Filtern und Gruppieren von Faktentabellen im DirectQuery- oder Hybridmodus verwendet werden. Dieser Modus ist außerdem die einzige Option für Tabellen, die auf Quellen basieren, die nicht vom DirectQuery-Modus unterstützt werden. Bei berechneten Tabellen handelt es sich immer um Importtabellen.
• Dual: Diesen Modus sollten Sie für Tabellen des Typs Dimension verwenden, wenn die Chance besteht, dass sie zusammen mit DirectQuery-Faktentabellen aus derselben Quelle abgefragt werden.
• Hybrid: In diesem Modus empfiehlt es sich, eine Faktentabelle durch Hinzufügen von Importpartitionen sowie einer DirectQuery-Partition zu konfigurieren, wenn Sie die neuesten Datenänderungen in Echtzeit hinzufügen möchten oder wenn Sie schnellen Zugriff auf die am häufigsten verwendeten Daten mithilfe von Importpartitionen bereitstellen möchten, während der Großteil der seltener verwendeten Daten weiterhin im Data Warehouse verbleibt.

Beim Abfragen eines zusammengesetzten Modells durch Power BI sind mehrere Szenarios denkbar:

• Es werden nur Import- oder Dualtabellen abgefragt: Power BI ruft alle Daten aus dem Modellcache ab. Dadurch wird die schnellstmögliche Leistung erzielt. Dieses Szenario kommt häufig bei Tabellen des Typs „Dimension“ vor, die mit Filtern oder Datenschnittvisuals abgefragt werden.
• Es werden nur Dual- oder DirectQuery-Tabellen abgefragt, die aus derselben Quelle stammen: Power BI ruft alle Daten durch eine oder mehrere native Abfragen an die DirectQuery-Quelle ab. Dadurch wird eine gute Leistung erzielt, insbesondere wenn in den Quelltabellen geeignete Indizes vorhanden sind. Dieses Szenario wird häufig bei Abfragen verwendet, bei denen Dimensionstabellen mit dem Modus „Dual“ mit DirectQuery-Faktentabellen verknüpft sind. Diese Abfragen sind quellgruppenintern, d. h., dass alle 1:1- oder 1:n-Beziehungen als reguläre Beziehungen bewertet werden.
• Es werden nur Dual- oder Hybridtabellen abgefragt, die aus derselben Quelle stammen: Dies ist eine Kombination der beiden vorherigen Szenarien. Power BI ruft die Daten aus dem Modellcache ab, sofern sie in Importpartitionen verfügbar sind. Andernfalls sendet Power BI eine oder mehrere native Abfragen an die DirectQuery-Quelle. Dies bietet die schnellstmögliche Leistung, da nur ein Slice der Daten im Data Warehouse abgefragt wird, vor allem dann, wenn geeignete Indizes für die Quelltabellen vorhanden sind. Wie bei dualen Dimensionstabellen und DirectQuery-Faktentabellen erfolgen diese Abfragen innerhalb der Quellgruppe, so dass alle 1:1- oder 1:n-Beziehungen als reguläre Beziehungen ausgewertet werden.
• Alle anderen Abfragen: Diese Abfragen umfassen quellgruppenübergreifende Beziehungen. Dies liegt darin begründet, dass eine Importtabelle mit einer DirectQuery-Tabelle oder eine Dualtabelle mit einer DirectQuery-Tabelle aus einer anderen Quelle verknüpft ist und sich die Ausgangstabelle deshalb wie eine Importtabelle verhält. Alle Beziehungen werden als beschränkte Beziehungen bewertet. Das bedeutet auch, dass Gruppierungen, die auf Nicht-DirectQuery-Tabellen angewendet werden, als materialisierte Unterabfragen (virtuelle Tabellen) an die DirectQuery-Quelle gesendet werden müssen. In diesem Fall kann die native Abfrage ineffizient sein, insbesondere bei großen Gruppierungssätzen.

Zusammenfassend empfiehlt sich Folgendes:

• Überlegen Sie gut, ob ein zusammengesetztes Modell die richtige Lösung für Sie ist. Es erlaubt zwar die Integration verschiedener Datenquellen auf Modellebene, gestaltet das Design aber auch komplexer. Die Konsequenzen werden weiter unten in diesem Artikel beschrieben.
• Wählen Sie bei einer Faktentabelle, in der große Datenmengen gespeichert sind oder die in Quasi-Echtzeit Ergebnisse liefern muss, als Speichermodus DirectQuery aus.
• Erwägen Sie die Verwendung des Hybridmodus, indem Sie eine Richtlinie für die inkrementelle Aktualisierung und Echtzeitdaten definieren oder die Faktentabelle mit TOM, TMSL oder dem Tool eines Drittanbieters partitionieren. Weitere Informationen finden Sie unter Inkrementelle Aktualisierung und Echtzeitdaten für semantische Modelle sowie im Nutzungsszenario Erweiterte Datenmodellverwaltung.
• Wählen Sie bei einer Dimensionstabelle, die zusammen mit DirectQuery- oder hybriden Faktentabellen aus derselben Quelle abgefragt wird, als Speichermodus Dual aus.
• Stellen Sie das Aktualisierungsintervall so ein, dass der Modellcache für Dual- und hybride Tabellen (und für alle abhängigen berechneten Tabellen) mit den Quelldatenbanken synchron gehalten wird.
• Bemühen Sie sich um quellgruppenübergreifende Datenintegrität (auch im Modellcache), denn wenn in beschränkten Beziehungen verknüpfte Spaltenwerte nicht übereinstimmen, können in den Abfrageergebnissen Reihen verloren gehen.
• Optimieren Sie DirectQuery-Datenquellen wenn möglich mit geeigneten Indizes für effiziente Joins, Filter, Gruppierungen.

Benutzerdefinierte Aggregationen

DirectQuery-Tabellen können Sie benutzerdefinierte Aggregationen hinzufügen. Deren Zweck besteht darin, die Leistung bei Abfragen mit höherer Granularität zu verbessern.

Aggregationen, die im Modell zwischengespeichert werden, verhalten sich wie Importtabellen, können aber nicht wie Modelltabellen verwendet werden. Wenn Sie einem DirectQuery-Modell Importaggregationen hinzufügen, erhalten Sie ein zusammengesetztes Modell.

Für Aggregationen gilt folgende Grundregel: Die Anzahl ihrer Zeilen sollte mindestens um den Faktor 10 kleiner sein als die Zeilenanzahl der zugrunde liegenden Tabelle. Wenn die zugrunde liegende Tabelle z. B. 1 Milliarde Zeilen hat, sollte die Aggregationstabelle nicht länger als 100 Millionen Zeilen sein. Wenn Sie sich an diese Regel halten, erhalten Sie im Gegenzug für die Erstellungs- und Verwaltungskosten einer Aggregationstabelle auch eine angemessene Leistungssteigerung.

quellgruppenübergreifende Beziehungen

Wenn eine Modellbeziehung Quellgruppen umfasst, wird sie als quellgruppenübergreifende Beziehung bezeichnet. Auch bei quellgruppenübergreifenden Beziehungen handelt es sich um eingeschränkte Beziehungen, da es keine garantierte „Eins“-Seite gibt. Weitere Informationen finden Sie im Abschnitt Bewertung von Beziehungen.

Beachten Sie beim Definieren von quellgruppenübergreifenden Beziehungen die folgenden Empfehlungen.

• Verwenden Sie Beziehungsspalten mit niedriger Kardinalität: Für eine optimale Leistung sollten Beziehungsspalten eine niedrige Kardinalität aufweisen, d. h. weniger als 50.000 eindeutige Werte speichern. Diese Empfehlung gilt insbesondere bei einer Kombination tabellarischer Modelle sowie bei Nicht-Text-Spalten.
• Vermeiden Sie in Beziehungen große Textspalten: Wenn Sie Textspalten in einer Beziehung verwenden müssen, berechnen Sie die erwartete Textlänge für den Filter, indem Sie die Kardinalität mit der durchschnittlichen Länge der Textspalte multiplizieren. Die maximal mögliche Textlänge sollte 1.000.000 Zeichen nicht überschreiten.
• Erhöhen Sie die Beziehungsgranularität: Erstellen Sie nach Möglichkeit Beziehungen mit einer höheren Granularität. Ordnen Sie beispielsweise eine Datumstabelle nicht ihrem Datumsschlüssel zu, sondern verwenden Sie stattdessen den Monatsschlüssel. Dieser Designansatz setzt voraus, dass die verknüpfte Tabelle eine Spalte mit dem Monatsschlüssel enthält und die Berichte keine täglichen Fakten abrufen.
• Streben Sie möglichst immer nach einem einfachen Beziehungsdesign: Erstellen Sie nur bei Bedarf eine quellgruppenübergreifende Beziehung und versuchen Sie, die Anzahl der Tabellen im Beziehungspfad gering zu halten. Dieser Designansatz trägt zur Verbesserung der Leistung und zur Vermeidung mehrdeutiger Beziehungspfade bei.

Szenario 1 für quellgruppenübergreifende Beziehungen

Nachfolgend finden Sie die Beschreibung eines Szenarios mit einem komplexen Beziehungsdesign, das unterschiedliche, aber dennoch gültige Ergebnisse zurückgeben kann.

In diesem Szenario besteht zwischen der Tabelle Region aus Quellgruppe A und den Tabellen Datum und Verkäufe aus Quellgruppe B eine Beziehung. Die Beziehung zwischen der Tabelle Region und der Tabelle Datum ist aktiv, während die Beziehung zwischen der Tabelle Region und der Tabelle Verkäufe inaktiv ist. Außerdem besteht eine aktive Beziehung zwischen der Tabelle Region und der Tabelle Verkäufe – beide aus Quellgruppe B. Die Tabelle Verkäufe enthält ein Measure mit der Bezeichnung Gesamtverkäufe, die Tabelle Region enthält die beiden Measures RegionaleVerkäufe und RegionaleVerkäufeDirekt.

Die Measures sind wie folgt definiert.

TotalSales = SUM(Sales[Sales])
RegionalSales = CALCULATE([TotalSales], USERELATIONSHIP(Region[RegionID], Sales[RegionID]))
RegionalSalesDirect = CALCULATE(SUM(Sales[Sales]), USERELATIONSHIP(Region[RegionID], Sales[RegionID]))

Das Measure RegionaleVerkäufe bezieht sich auf das Measure Gesamtverkäufe, das Measure RegionaleVerkäufeDirekt hingegen nicht. Stattdessen verwendet das Measure RegionaleVerkäufeDirekt den Ausdruck SUM(Sales[Sales]) – den gleichen Ausdruck verwendet auch das Measure Gesamtverkäufe.

Der Unterschied im Ergebnis ist subtil. Bei der Auswertung des Measures RegionaleVerkäufe wendet Power BI den Filter der Tabelle Region sowohl auf die Tabelle Verkäufe als auch auf die Tabelle Datum an. Daher überträgt sich der Filter von der Tabelle Datum auch auf die Tabelle Verkäufe. Dagegen überträgt Power BI bei der Auswertung des Measures RegionaleVerkäufeDirekt den Filter der Tabelle Region lediglich auf die Tabelle Verkäufe. Die von den Measures RegionaleVerkäufe und RegionaleVerkäufeDirekt zurückgegebenen Ergebnisse können abweichen, obwohl die Ausdrücke semantisch identisch sind.

Szenario 2 für quellgruppenübergreifende Beziehungen

Nachfolgend finden Sie die Beschreibung eines Szenarios mit einer quellgruppenübergreifenden Beziehung, deren Beziehungsspalten eine hohe Kardinalität aufweisen.

In diesem Szenario sind die Tabelle Datum und die Tabelle Verkäufe über die Datumsschlüssel-Spalten miteinander verknüpft. Die Datumsschlüssel-Spalten haben den Datentyp „Integer“. Sie speichern ganze Zahlen im Format JJJJMMTT. Die Tabellen gehören zu verschiedenen Quellgruppen. Darüber hinaus handelt es sich um eine Beziehung mit hoher Kardinalität, da das früheste Datum in der Tabelle Datum der 1. Januar 1900 und das letzte Datum der 31. Dezember 2100 ist. Die Tabelle enthält also bei je einer Zeile für jedes Datum im Zeitraum von 1900 bis 2100 insgesamt 73.414 Zeilen.

In diesem Szenario gibt es zwei Problempunkte.

Der erste Problempunkt: Wenn Sie die Spalten der Tabelle Datum als Filter verwenden, wird durch Filterübertragung die Spalte Datumsschlüssel der Tabelle Verkäufe ebenfalls gefiltert, um deren Measures auszuwerten. Wenn Sie nach einem einzelnen Jahr filtern, beispielsweise nach dem Jahr 2022, enthält die DAX-Abfrage einen Filterausdruck wie diesen: Sales[DateKey] IN { 20220101, 20220102, …20221231 }. Die Textgröße der Abfrage kann in diesem Fall extrem groß werden, wenn der Filterausdruck sehr viele Werte enthält oder es sich bei den Filterwerten um lange Zeichenfolgen handelt. Die Generierung und anschließende Ausführung einer solch langen Abfrage ist in punkto Ressourcenverbrauch sowohl für Power BI als auch für die Datenquelle sehr kostspielig.

Der zweite Problempunkt: Wenn Sie die Spalten der Tabelle Datum – wie Jahr, Quartal oder Monat – als Gruppierungsspalten für Filter verwenden, werden alle nur möglichen eindeutigen Kombinationen aus Jahr, Quartal oder Monat und den Werten der Spalte Datumsschlüssel gebildet. Die Abfragezeichenfolge, die Filter für die Gruppierungsspalten und die Beziehungsspalte enthält, kann in einem solchen Fall extrem groß werden. Dies gilt insbesondere, wenn die Anzahl der Gruppierungsspalten bzw. die Kardinalität der verknüpfenden Spalte (Datenschlüssel) groß ist.

Leistungsprobleme lassen sich wie folgt umgehen:

• Fügen Sie der Datenquelle die Tabelle Datum hinzu. Dadurch erhalten Sie ein Modell mit nur einer Quellgruppe (es handelt sich demnach nicht mehr um ein zusammengesetztes Modell).
• Erhöhen Sie die Granularität der Beziehung. Beispielsweise können Sie beiden Tabellen die Spalte Monatsschlüssel hinzufügen und die Beziehung mit diesen Spalten bilden. Durch Erhöhen der Beziehungsgranularität geht für den Bericht jedoch die Möglichkeit verloren, tägliche Verkaufsaktivitäten zurückzugeben – es sei denn, Sie verwenden die Spalte Datumsschlüssel der Tabelle Verkäufe.

Szenario 3 für quellgruppenübergreifende Beziehungen

Nachfolgend finden Sie die Beschreibung eines Szenarios mit einer quellgruppenübergreifenden Beziehung, deren Tabellen keine übereinstimmenden Werte aufweisen.

In diesem Szenario besteht eine Beziehung zwischen der Tabelle Datum der Quellgruppe B und der Tabelle Verkäufe der gleichen Quellgruppe sowie der Tabelle Ziel der Quellgruppe A. Für alle Beziehungen gilt ausgehend von der Tabelle Datum im Bezug auf die Jahr-Spalten die Zuordnung 1:n. Die Tabelle Verkäufe enthält die Spalte Verkaufsbetrag mit den Umsätzen aus den Verkäufen, während die Tabelle Ziel die Spalte Zielbetrag mit den Zielumsätzen enthält.

In der Tabelle Datum werden die Jahre 2021 und 2022 gespeichert. In der Tabelle Verkäufe werden die Umsätze aus den Verkäufen des Jahres 2021 (100) und 2022 (200) gespeichert, während in der Tabelle Ziel die Zielumsätze für die Jahre 2021 (100), 2022 (200) und 2023 (300) – das noch in der Zukunft liegt – gespeichert sind.

Wenn ein Tabellenvisual in Power BI das zusammengesetzte Modell durch Gruppieren der Spalte Jahr der Tabelle Datum und Summieren der Spalten Verkaufsbetrag und Zielbetrag abfragt, wird für das Jahr 2023 kein Zielbetrag zurückgegeben. Grund hierfür ist, dass es sich bei der quellgruppenübergreifenden Beziehung um eine eingeschränkte Beziehung handelt, die sich der INNER JOIN-Semantik bedient, durch die aber keine Zeilen zurückgegeben werden, die nicht auf beiden Seiten übereinstimmende Werte haben. Jedoch ergibt diese Beziehung einen korrekten Gesamtzielbetrag (600), da auf die Auswertung kein Filter angewendet wird, der sich der Tabelle Datum bedient.

Wenn es sich bei der Beziehung zwischen der Tabelle Datum und der Tabelle Ziel um eine quellgruppeninterne Beziehung handelt (dies unter der Voraussetzung, dass die Tabelle Ziel zur Quellgruppe B gehört), würde das Visual für den Zielbetrag im Jahr 2023 (und alle weiteren Jahre ohne Übereinstimmung) den Eintrag (leer) enthalten.

Weitere Informationen zu eingeschränkten Beziehungen finden Sie unter Beziehungsauswertung.

Berechnungen

Beachten Sie bei zusammengesetzten Modellen mit berechneten Spalten und Berechnungsgruppen unbedingt die in diesem Fall geltenden besonderen Einschränkungen.

Berechnete Spalten

Berechnete Spalten, die einer DirectQuery-Tabelle hinzugefügt wurden und ihre Daten aus einer relationalen Datenbank wie Microsoft SQL Server beziehen, können nur Ausdrücke verwenden, die jeweils für nur eine Zeile ausgeführt werden. Diese Ausdrücke dürfen keine DAX-Iteratorfunktionen wie SUMXoder Funktionen zur Änderung des Filterkontexts wie CALCULATE enthalten.

Ein berechneter Spaltenausdruck in einer DirectQuery-Remotetabelle kann nur zeilenintern auswerten. Sie können einen solchen Ausdruck zwar erstellen, jedoch führt er in einem Visual zu einem Fehler. Wenn Sie beispielsweise einer DirectQuery-Remotetabelle namens DimProduct mit dem Ausdruck [Product Sales] / SUM (DimProduct[ProductSales])eine berechnete Spalte hinzufügen, können Sie den Ausdruck erfolgreich im Modell speichern. Bei Verwendung in einem Visual kommt es jedoch aufgrund der Missachtung der Einschränkung der zeileninternen Auswertung zu einem Fehler.

Dagegen können berechnete Spalten in einer DirectQuery-Remotetabelle, bei der es sich um ein tabellarisches Modell (also ein Power BI-Semantikmodell oder ein Analysis Services-Modell) handelt, flexibler verwendet werden. In diesem Fall sind alle DAX-Funktionen möglich, da der Ausdruck innerhalb des tabellarischen Quellmodells ausgewertet wird.

Viele Ausdrücke setzen voraus, dass die berechnete Spalte vor der Verwendung oder Aggregierung als Gruppe oder Filter in Power BI materialisiert wird. Wenn eine berechnete Spalte über eine große Tabelle materialisiert wird, kann dies – in Abhängigkeit der Kardinalität der Spalten, anhand derer die Berechnung erfolgt – in Bezug auf CPU und Arbeitsspeicher äußerst kostspielig sein. Wir empfehlen in diesem Fall, berechnete Spalten dem Quellmodell hinzuzufügen.

Berechnungsgruppen

Bei Berechnungsgruppen in einer Quellgruppe, die mit einem Power BI-Semantikmodell oder einem Analysis Services-Modell verknüpft ist, gibt Power BI möglicherweise unerwartete Ergebnisse zurück. Weitere Informationen finden Sie unter Berechnungsgruppen, Abfragen und Measureauswertung.

Modelldesign

Für optimierte Power BI-Modelle sollten Sie nach Möglichkeit ein Sternschemadesign verwenden.

Erstellen Sie Dimensionstabellen getrennt von Faktentabellen, damit Power BI Verknüpfungen richtig interpretieren und effiziente Abfragepläne erstellen kann. An sich gilt diese Empfehlung für jedes Power BI-Modell, im besonderen jedoch für Modelle, die Quellgruppe eines zusammengesetzten Modells werden sollen. Ein solches Design erlaubt eine einfachere und effizientere Integration weiterer Tabellen in Downstreammodellen.

Vermeiden Sie nach Möglichkeit Dimensionstabellen in einer Quellgruppe, die sich auf eine Faktentabelle in einer anderen Quellgruppe beziehen. Denn quellgruppeninterne Beziehungen sind wesentlich einfacher zu handhaben als quellgruppenübergreifende Beziehungen, insbesondere bei Beziehungsspalten mit hoher Kardinalität. Wie zuvor beschrieben, müssen die Beziehungsspalten bei quellgruppenübergreifenden Beziehungen übereinstimmende Werte aufweisen. Andernfalls sind die Ergebnisse in Berichtsvisuals oft nicht korrekt.

Sicherheit auf Zeilenebene

Wenn Ihr Modell benutzerdefinierte Aggregationen, berechnete Spalten in Importtabellen oder berechnete Tabellen enthält, stellen Sie die ordnungsgemäße Einrichtung sowie gründliche Tests der Sicherheit auf Zeilenebene (Row-Level Security, RLS) sicher.

Wenn das zusammengesetzte Modell mit anderen tabellarischen Modellen verknüpft ist, werden RLS-Regeln nur auf die Quellgruppe, d. h. auf das lokale Modell angewendet, in dem sie definiert sind. Auf andere Quellgruppen bzw. Remotemodelle werden sie nicht angewendet. Außerdem können Sie RLS-Regeln nicht für eine Tabelle einer anderen Quellgruppe oder für eine lokale Tabelle definieren, die sich auf eine andere Quellgruppe bezieht.

Berichtsentwurf

In einigen Situationen können Sie die Leistung eines zusammengesetzten Modells durch ein optimiertes Berichtslayout verbessern.

Visuals mit nur einer Quellgruppe

Erstellen Sie nach Möglichkeit Visuals, die Felder aus nur einer Quellgruppe verwenden. Von Visuals generierte Abfragen funktionieren besser, wenn das Ergebnis aus nur einer Quellgruppe abgerufen wird. Wenn Sie Daten aus verschiedenen Quellgruppen abrufen müssen, empfiehlt es sich nach Möglichkeit, zwei Visuals nebeneinander anzuordnen – eines für jede Quellgruppe.

Verwenden von Synchronisierungsslicern

In einigen Situationen können Sie quellgruppenübergreifende Beziehungen in Modellen durch Synchronisierungsslicer umgehen. Dadurch lassen sich Quellgruppen bei verbesserter Leistung visuell kombinieren.

Betrachten wir hierzu ein Szenario, in dem das Modell zwei Quellgruppen aufweist. Jede Quellgruppe verfügt über eine Produkttabelle des Typs „Dimension“, die zum Filtern von Reseller- und Internetverkäufen verwendet wird.

In diesem Szenario enthält Quellgruppe A die Tabelle Produkt, die wiederum mit der Tabelle Resellerverkäufe verknüpft ist. Quellgruppe B enthält die Tabelle Produkt2, die ihrerseits mit der Tabelle Internetverkäufe verknüpft ist. In diesem Szenario gibt es keine quellgruppenübergreifenden Beziehungen.

Im Bericht fügen Sie einen Slicer hinzu, der die Seite anhand der Spalte Farbe der Tabelle Produkt filtert. Der Slicer filtert standardmäßig die Tabelle Resellerverkäufe, nicht aber die Tabelle Internetverkäufe. Danach fügen Sie einen ausgeblendeten Slicer hinzu, für den Sie die Spalte Farbe der Tabelle Produkt2 verwenden. Wenn Sie nun in den Erweiterten Optionen der Synchronisierungsslicer einen identischen Gruppennamen konfigurieren, werden Filter, die auf den sichtbaren Slicer angewendet werden, automatisch auch auf den ausgeblendeten Slicer übertragen.

Weitere Informationen finden Sie unter Synchronisieren separater Slicer.

Weitere Empfehlungen

Hier finden Sie weitere Tipps und Empfehlungen zum Design und zur Verwaltung zusammengesetzter Modelle.

• Leistung und Skalierung: Wenn Ihre Berichte zuvor live mit einem Power BI-Semantikmodell oder Analysis Services-Modell verbunden waren, konnte der Power BI-Dienst die Inhalte der Visualcaches berichtsübergreifend wiederverwenden. Wenn Sie die Liveverbindung zugunsten eines lokalen DirectQuery-Modells konvertiert haben, ist Berichten der Rückgriff auf diese Caches nicht mehr möglich. Womöglich kommt es daher zu Leistungseinbußen oder sogar zu Aktualisierungsfehlern. Auch die Workload des Power BI-Dienstes steigt dadurch. Vermutlich müssen Sie daher die Kapazität erhöhen oder die Workload auf andere Kapazitäten verteilen. Weitere Informationen zur Datenaktualisierung und Caching finden Sie unter Aktualisieren von Daten in Power BI.
• Umbenennen: Es wird davon abgeraten, in zusammengesetzten Modellen verwendete semantische Modelle oder deren Arbeitsbereiche umzubenennen. Der Grund hierfür ist, dass zusammengesetzte Modelle Verbindungen mit Power BI-Semantikmodellen nicht über interne eindeutige Bezeichner, sondern über die Namen der Arbeitsbereiche und semantischen Modelle herstellen. Durch Umbenennen eines semantischen Modells oder Arbeitsbereichs können die vom zusammengesetzten Modell verwendeten Verbindungen verloren gehen.
• Governance: Wenn Ihr Modell Ihre Single Version of the Truth ist, also Ihr einziges Modell, das Ihnen zuverlässige Daten zurückgibt, raten wir von einem zusammengesetzten Modell ab. Der Grund hierfür ist, dass zusammengesetzte Modelle von anderen Datenquellen oder Modellen abhängig sind. Wenn an diesen aber Änderungen vorgenommen werden, kann es passieren, dass das zusammengesetzte Modell nicht mehr funktioniert. Stattdessen empfehlen wir als „Single Version of the Truth“ die Veröffentlichung eines semantisches Unternehmensmodells. Dieses Modell kann als zuverlässige Basis betrachtet werden. Andere Datenmodellierer können dieses Basismodell dann durch spezialisierte zusammengesetzte Modelle erweitern.
• Datenherkunft: Wir raten Ihnen dringend, vor der Veröffentlichung von Änderungen an zusammengesetzten Modellen die Funktionen Datenherkunft und Semantikmodellauswirkungsanalyse auszuführen. Diese Funktionen des Power BI-Dienstes helfen Ihnen, die Beziehungen zwischen semantischen Modellen und deren Verwendung besser zu verstehen. Für externe semantische Modelle, die in der Herkunftsansicht angezeigt werden, sich tatsächlich aber in einem anderen Arbeitsbereich befinden, können keine Auswirkungsanalysen ausgeführt werden. Wenn Sie eine Auswirkungsanalyse für ein externes semantisches Modell durchführen möchten, müssen Sie hierfür zum Quellarbeitsbereich navigieren.
• Schemaupdates: Nach Schemaänderungen an Upstreamdatenquellen sollten Sie Ihr zusammengesetztes Modell in Power BI Desktop aktualisieren. Das Modell muss anschließend im Power BI-Dienst erneut veröffentlicht werden. Stellen Sie nach einer solchen Aktualisierung sicher, dass Berechnungen und abhängige Berichte gründlich getestet werden.

Zugehöriger Inhalt

Weitere Informationen zu den Themen dieses Artikels finden Sie in den folgenden Ressourcen.

• Verwenden zusammengesetzter Modelle in Power BI Desktop
• Modellieren von Beziehungen in Power BI Desktop
• DirectQuery-Modelle in Power BI Desktop
• Verwenden von DirectQuery in Power BI Desktop
• Verwenden von DirectQuery für Power BI-Semantikmodelle und Analysis Services
• Speichermodus in Power BI Desktop
• Benutzerdefinierte Aggregationen
• Haben Sie Fragen? Stellen Sie Ihre Frage in der Power BI-Community.
• Vorschläge? Einbringen von Ideen zur Verbesserung von Power BI