Informationen zum Sternschema und der Wichtigkeit für Power BI

Dieser Artikel befasst sich mit Power BI Desktop-Datenmodellierern. Es beschreibt star schema design and its relevanz to developing Power BI semantic models optimized for performance and usability.

Übersicht über das Sternschema

Das Sternschema ist ein ausgereifter Modellierungsansatz, der von relationalen Data Warehouse weitgehend übernommen wird. Hierzu müssen Modellierer ihre Modelltabellen entweder als Dimension oder Fakt klassifizieren.

• Dimensionstabellen beschreiben Geschäftsentitäten, die Dinge, die Sie modellieren. Entitäten können Produkte, Personen, Orte und Konzepte, einschließlich der Zeit selbst, enthalten. Die Tabelle mit der meisten Konsistenz in einem Sternschema ist eine Datumsdimensionstabelle. Eine Dimensionstabelle enthält eine Schlüsselspalte (oder Spalten), die als eindeutiger Bezeichner und andere Spalten fungiert. Andere Spalten unterstützen das Filtern und Gruppieren Ihrer Daten.
• Faktentabellen speichern Beobachtungen oder Ereignisse und können Verkaufsaufträge, Aktienbilanzen, Wechselkurse, Temperaturen und vieles mehr sein. Eine Faktentabelle enthält Dimensionsschlüsselspalten, die sich auf Dimensionstabellen beziehen, und numerische Messspalten. Die Dimensionsschlüsselspalten bestimmen die Dimensionalität einer Faktentabelle, während die Dimensionsschlüsselwerte die Granularität einer Faktentabelle bestimmen. Betrachten Sie z. B. eine Faktentabelle, die zum Speichern von Verkaufszielen mit zwei Dimensionsschlüsselspalten Date ausgelegt ist, und ProductKey. Es ist leicht zu verstehen, dass die Tabelle zwei Dimensionen enthält. Die Granularität kann jedoch nicht ermittelt werden, ohne die Dimensionsschlüsselwerte zu berücksichtigen. Beachten Sie in diesem Beispiel, dass die in der Date Spalte gespeicherten Werte der erste Tag jedes Monats sind. In diesem Fall handelt es sich bei der Granularität um die monatliche Produktebene.

Im Allgemeinen enthalten Dimensionstabellen eine relativ kleine Anzahl von Zeilen. Faktentabellen können dagegen eine große Anzahl von Zeilen enthalten und im Laufe der Zeit weiter wachsen.

Normalisierung vs. Denormalisierung

Um einige in diesem Artikel beschriebene Konzepte des Sternschemas zu verstehen, ist es wichtig, zwei Begriffe zu kennen: Normalisierung und Denormalisierung.

Normalisierung ist der Begriff, der verwendet wird, um Daten zu beschreiben, die auf eine Weise gespeichert werden, die die Anzahl der repetitiven Daten reduziert. Betrachten Sie eine Tabelle mit Produkten mit einer eindeutigen Schlüsselwertspalte wie dem Product Key und anderen Spalten, die Produktmerkmale beschreiben, z. B. Produktname, Kategorie, Farbe und Größe. Eine Verkaufstabelle gilt als normalisiert, wenn nur Schlüssel wie der Product Key gespeichert werden. Beachten Sie in der folgenden Abbildung, dass nur die ProductKey Spalte das Produkt aufzeichnet.

Wenn in der Sales-Tabelle jedoch Produktdetails über den Schlüssel hinaus gespeichert werden, gilt sie als denormalisiert. Beachten Sie in der folgenden Abbildung, dass die ProductKey und andere produktbezogene Spalten das Produkt aufzeichnen.

Wenn Sie Daten aus einer Exportdatei beziehen oder Daten extrahieren, ist es wahrscheinlich, dass sie einen denormalisierten Satz von Daten darstellt. Verwenden Sie in diesem Fall Power Query, um die Quelldaten in mehrere normalisierte Tabellen zu transformieren und umzuformen.

Wie in diesem Artikel beschrieben, sollten Sie sich bemühen, optimierte Power BI-Semantikmodelle mit Tabellen zu entwickeln, die normalisierte Fakten- und Dimensionsdaten darstellen. Es gibt jedoch eine Ausnahme, bei der eine Schneeflockendimension zur Erstellung einer einzelnen Modelltabelle möglicherweise denormalisiert wird.

Starschemarelevanz für Power BI-Semantikmodelle

Der Sternschemaentwurf und viele verwandte Konzepte, die in diesem Artikel vorgestellt werden, sind ein wichtiger Bestandteil der Entwicklung von Power BI-Modellen mit optimierter Leistung und Benutzerfreundlichkeit.

Berücksichtigen Sie, dass jedes Visuelle Power BI-Bericht eine Abfrage generiert, die an das Power BI-Semantikmodell gesendet wird. Im Allgemeinen filtern, gruppieren und zusammenfassen Sie Modelldaten. Demnach ist ein gut entworfenes Modell eines, das Tabellen für Filterung und Gruppierung sowie Tabellen für die Zusammenfassung bereitstellt. Damit entspricht dieser Entwurf den Prinzipien für Sternschemas:

• Bemaßungstabellen ermöglichen das Filtern und Gruppieren.
• Faktentabellen ermöglichen eine Zusammenfassung.

Es gibt keine Tabelleneigenschaft, die modellieren, um den Tabellentyp als Dimension oder Tatsache festzulegen. Es wird tatsächlich durch die Modellbeziehungen bestimmt. Eine Modellbeziehung richtet einen Filterverteilungspfad zwischen zwei Tabellen ein, und es ist die Kardinalitätseigenschaft der Beziehung, die den Tabellentyp bestimmt. Gängige Beziehungskardinalitäten sind 1:n und dessen umgekehrte Variante n:1. Die "1"-Seite ist immer eine Dimensionstabelle, während die "n"-Seite immer eine Faktentabelle ist.

Ein gut strukturiertes Modelldesign enthält Tabellen, die entweder Dimensionstabellen oder Faktentabellen sind. Vermeiden Sie die Kombination beider Tabellentypen in einer Tabelle. Außerdem wird empfohlen, die richtige Anzahl von Tabellen mit den richtigen Beziehungen bereitzustellen. Es ist auch wichtig, dass Tatsachentabellen immer Daten in einem konsistenten Korn laden.

Letztlich sollten Sie wissen, dass ein optimaler Modellentwurf aus einem Teil Wissenschaft und einem Teil Kunst besteht. Gelegentlich kann eine gute Anleitung außer Acht gelassen werden, wenn es Sinn macht, dies zu tun.

Es gibt viele Konzepte im Zusammenhang mit dem Starschemadesign, die auf ein Power BI-Semantikmodell angewendet werden können. Einige Beispiele für diese Konzepte:

• Measures
• Ersatzschlüssel
• Schneeflockendimensionen
• Dimensionen mit unterschiedlichen Rollen
• Langsam veränderliche Dimensionen
• Junkdimensionen
• Degenerierte Dimensionen
• Faktenlose Faktentabellen

Measures

Im Sternschemaentwurf ist ein Measure eine Faktentabellenspalte, die Werte enthält, die zusammengefasst werden sollen. In einem Power BI-Semantikmodell weist ein Measure eine andere – aber ähnliche – Definition auf. Ein Modell unterstützt sowohl explizite als auch implizite Measures.

• Explizite Measures werden ausdrücklich erstellt und basieren auf einer Formel, die in Data Analysis Expressions (DAX) geschrieben wurde, die eine Zusammenfassung erreicht. Measureausdrücke verwenden häufig DAX-Aggregationsfunktionen wie SUM, MIN, MAX, AVERAGEund andere, um ein skalares Wertergebnis zur Abfragezeit zu erzeugen (Werte werden nie im Modell gespeichert). Measureausdrücke können zwischen einfachen Spaltenaggregationen und komplexeren Formeln variieren, die den Filterkontext und bzw. oder die Beziehungsweitergabe überschreiben. Weitere Informationen finden Sie unter DAX Basics in Power BI Desktop.
• Implizite Measures sind Spalten, die von einem visuellen Bericht oder Q&A zusammengefasst werden können. Sie bieten ihnen einen Komfort als Modellentwickler, da sie in vielen Fällen keine (expliziten) Measures erstellen müssen. Beispielsweise kann die Spalte "Adventure Works reseller sales Sales Amount " auf vielfältige Weise zusammengefasst werden (Summe, Anzahl, Mittelwert, Median, Min, Max und andere), ohne dass für jeden möglichen Aggregationstyp ein Measure erstellt werden muss.

Im Datenbereich werden explizite Measures durch das Rechnersymbol dargestellt, während implizite Measures durch das Sigma-Symbol (∑) dargestellt werden.

Es gibt jedoch drei überzeugende Gründe, warum Sie Möglicherweise Measures erstellen, auch für einfache Zusammenfassungen auf Spaltenebene:

• Wenn Sie wissen, dass Ihre Berichtsautoren das Semantikmodell mithilfe von multidimensionalen Ausdrücken (MDX) abfragen, muss das Modell explizite Measures enthalten. Das liegt daran, dass MDX keine Zusammenfassung von Spaltenwerten erzielen kann. Insbesondere wird MDX beim Ausführen von Analyse in Excel verwendet, da PivotTables MDX-Abfragen ausstellen.

• Wenn Sie wissen, dass Ihre Berichtsautoren Power BI-paginierte Berichte mithilfe des MDX-Abfrage-Designers erstellen, muss das semantische Modell explizite Measures enthalten. Nur der MDX-Abfrage-Designer unterstützt Serveraggregate. Wenn für Berichtsautoren also von Power BI ausgewertete Measures benötigt werden (anstelle der paginierten Berichts-Engine), müssen sie den MDX-Abfrage-Designer verwenden.

• Wenn Sie steuern möchten, wie Ihre Berichtsautoren Spalten auf bestimmte Weise zusammenfassen. Beispielsweise kann die Spalte "Reseller Sales Unit Price " (die einen Satz pro Einheit darstellt) zusammengefasst werden, aber nur mithilfe bestimmter Aggregationsfunktionen. Es sollte niemals summiert werden, aber es ist angemessen, mithilfe anderer Aggregationsfunktionen wie Min, Max oder Mittelwert zusammenzufassen. In diesem Fall kann der Modellierer die Unit Price Spalte ausblenden und Measures für alle geeigneten Aggregationsfunktionen erstellen.

  Dieser Entwurfsansatz eignet gut sich für Berichte, die im Power BI-Dienst erstellt wurden, und für Q&A. Mit Power BI Desktop-Liveverbindungen können Berichtsautoren jedoch ausgeblendete Felder im Datenbereich anzeigen, was dazu führen kann, dass dieser Entwurfsansatz umgangen wird.

Ersatzschlüssel

Ersatzschlüssel sind eindeutige Bezeichner, die Sie zu einer Tabelle hinzufügen können, um die Sternschemamodellierung zu unterstützen. Sie werden definitionsgemäß nicht in den Quelldaten definiert oder gespeichert. Ersatzschlüssel werden in der Regel zu relationalen Data Warehouse-Dimensionstabellen hinzugefügt, um einen eindeutigen Bezeichner für jede Zeile der Dimensionstabelle bereitzustellen.

Power BI-Semantikmodellbeziehungen basieren auf einer einzelnen eindeutigen Spalte in einer Tabelle, die Filter an eine einzelne Spalte in einer anderen Tabelle verteilt. Wenn eine Dimensionstabelle in Ihrem semantischen Modell keine einzelne eindeutige Spalte enthält, müssen Sie einen eindeutigen Bezeichner hinzufügen, um zur "1"-Seite einer Beziehung zu werden. In Power BI Desktop können Sie diese Anforderung erreichen, indem Sie eine Power Query-Indexspalte hinzufügen.

Sie müssen diese Abfrage mit der Abfrage der „n“-Seite zusammenführen, damit Sie auch die Indexspalte hinzufügen können. Wenn Sie diese Abfragen in das semantische Modell laden, können Sie dann eine 1:n-Beziehung zwischen den Modelltabellen erstellen.

Schneeflockendimensionen

Schneeflockendimensionen bestehen aus normalisierten Tabellen für eine einzelne Geschäftseinheit. Zum Beispiel klassifiziert Adventure Works Produkte anhand der Kategorie und der Unterkategorie. Die Produkte werden Unterkategorien zugewiesen, und Unterkategorien wiederum werden Kategorien zugewiesen. Im relationalen Data Warehouse von Adventure Works wird die Produktdimension normalisiert und in drei verknüpften Tabellen gespeichert: DimProductCategory, , DimProductSubcategoryund DimProduct.

Mit ein wenig Fantasie können Sie sich die normalisierten Tabellen außerhalb der Faktentabelle vorstellen, wodurch sich ein Schneeflockendesign ergibt.

In Power BI Desktop können Sie ein Schneeflakedimensionsdesign nachahmen (vielleicht weil ihre Quelldaten dies bewirkt) oder die Quelltabellen kombinieren, um eine einzelne, denormalisierte Modelltabelle zu bilden. Im Allgemeinen überwiegen die Vorteile einer einzelnen Modelltabelle die Vorteile mehrerer Modelltabellen. Die optimale Entscheidung kann davon abhängen, welche Datenmengen und Anforderungen an die Nutzbarkeit für das Modell bestehen.

Folgendes geschieht, wenn Sie sich für das Imitieren eines Schneeflockendimensionsentwurfs entscheiden:

• Power BI lädt weitere Tabellen, was in Hinsicht auf Speicher und Leistung weniger effizient ist. Diese Tabellen müssen Spalten enthalten, um Modellbeziehungen zu unterstützen, was zu größeren Modellen führen kann.
• Längere Verteilungsketten für Beziehungsfilter müssen durchlaufen werden, was möglicherweise weniger effizient ist als Filter, die auf eine einzelne Tabelle angewendet werden.
• Im Datenbereich werden weitere Modelltabellen für Berichtsautoren dargestellt, was zu einer weniger intuitiven Benutzererfahrung führen kann, insbesondere wenn Schneeflakedimensionstabellen nur eine oder zwei Spalten enthalten.
• Es ist nicht möglich, eine Hierarchie zu erstellen, die Spalten aus mehreren Tabellen umfasst.

Wenn Sie sich für die Integration in eine einzelne Modelltabelle entscheiden, können Sie auch eine Hierarchie definieren, die die allgemeinen und genauen Ebenen der Dimension umfasst. Möglicherweise kann die Speicherung redundanter Denormalized-Daten zu einer erhöhten Modellspeichergröße führen, insbesondere für große Dimensionstabellen.

Langsam veränderliche Dimensionen

Eine langsam ändernde Dimension (oder SCD) ist eine, die die Änderung der Dimensionsmember im Laufe der Zeit entsprechend verwaltet. Es wird angewendet, wenn sich Die Werte der Geschäftsentität im Laufe der Zeit langsam in ungeplanter Weise ändern. Ein gutes Beispiel für eine SCD ist eine Kundendimension, da sich die Kontaktdetailsspalten wie E-Mail-Adresse und Telefonnummer selten ändern. Im Gegensatz dazu werden einige Dimensionen als schnell geändert, wenn sich ein Dimension-Attribut häufig ändert, z. B. der Marktpreis einer Aktie. Der gängige Ansatz in diesen Fällen besteht darin, sich häufig ändernde Attributwerte in einem Faktentabellenmeasure zu speichern.

Die Theorie des Sternschemaentwurfs bezieht sich auf zwei gängige Arten sich langsam ändernder Dimensionen: Typ 1 und Typ 2. Eine Dimensionstabelle kann Typ 1 oder Typ 2 sein oder beide Typen gleichzeitig für unterschiedliche Spalten unterstützen.

SCD Typ 1

Eine langsam veränderliche Dimension vom Typ 1 stellt immer die neuesten Werte dar. Wenn Änderungen an den Quelldaten ermittelt werden, werden die Daten der Dimensionstabelle überschrieben. Dieser Entwurfsansatz wird häufig für Spalten verwendet, die ergänzende Werte enthalten, z. B. E-Mail-Adressen oder Telefonnummern von Kunden. Wenn die E-Mail-Adresse oder Telefonnummer eines Kunden geändert wird, aktualisiert die Dimensionstabelle die Kundenzeile mit den neuen Werten. Dies erfolgt so, als hätte der Kunde schon immer über diese Kontaktinformationen verfügt.

Eine nicht inkrementelle Aktualisierung einer Power BI-Modelldimensionstabelle erzielt das Ergebnis eines Typs 1 SCD. Dabei werden die Tabellendaten aktualisiert, um sicherzustellen, dass die neuesten Werte geladen werden.

SCD Typ 2

Eine langsam veränderliche Dimension vom Typ 2 unterstützt die Versionskontrolle für Dimensionselemente. Wenn das Quellsystem keine Versionen speichert, handelt es sich in der Regel um den Load-Prozess des Data Warehouse, der Änderungen erkennt und die Änderung in einer Dimensionstabelle entsprechend verwaltet. In diesem Fall muss die Dimensionstabelle einen Ersatzschlüssel verwenden, um einen eindeutigen Verweis auf eine Version des Dimensionselements bereitzustellen. Sie enthält auch Spalten, die die Gültigkeit des Datumsbereichs der Version definieren (z. B. StartDate und EndDate), und möglicherweise eine Flagspalte (z. B. IsCurrent), um ganz einfach nach aktuellen Dimensionselementen filtern zu können.

Beispielsweise weist Adventure Works jedem Vertriebsmitarbeiter eine Vertriebsregion zu. Wenn ein Vertriebsmitarbeiter einer anderen Region zugewiesen wird, muss eine neue Version des Vertriebsmitarbeiters erstellt werden, um sicherzustellen, dass Verlaufsdaten weiterhin der vorherigen Region zugeordnet bleiben. Die Dimensionstabelle muss Versionen von Vertriebsmitarbeitern und ihren zugeordneten Regionen enthalten, um eine genaue Verlaufsanalyse der Verkäufe pro Vertriebsmitarbeiter zu ermöglichen. Die Tabelle sollte auch Werte für das Start- und Enddatum enthalten, um die Gültigkeitsdauer zu definieren. Aktuelle Versionen definieren möglicherweise ein leeres Enddatum (oder 12.31.9999), was angibt, dass die Zeile die aktuelle Version ist. Die Tabelle muss auch über einen Ersatzschlüssel verfügen, da der Geschäftsschlüssel (in diesem Fall die Mitarbeiter-ID) nicht eindeutig ist.

Denken Sie daran, dass Sie ein Zwischensystem (beispielsweise ein Data Warehouse) zum Ermitteln und Speichern von Änderungen verwenden müssen, wenn die Quelldaten die Versionen nicht speichert. Der Tabellenladevorgang muss vorhandene Daten beibehalten und Änderungen ermitteln. Wenn eine Änderung ermittelt wird, muss der Tabellenladevorgang die aktuelle Version aktualisieren. Die Aufzeichnung dieser Änderungen erfolgt durch Aktualisieren des Werts EndDate und Einfügen einer neuen Version mit dem Wert StartDate, der ab dem vorherigen Wert von EndDate beginnt. Verwandte Fakten müssen außerdem eine zeitbasierte Suche verwenden, um den entsprechenden Dimensionsschlüsselwert für das Faktendatum abzurufen. Ein Power BI-Semantikmodell verwendet Power Query, sodass es dieses Ergebnis nicht erzeugen kann. Allerdings kann es Daten aus einer vorab geladenen Dimensionstabelle vom SCD Typ 2 laden.

Das Power BI-Semantikmodell sollte das Abfragen von verlaufsverlauflichen Daten für ein Element unabhängig von änderungen und für eine Version des Elements unterstützen, die einen bestimmten Zustand des Mitglieds in der Zeit darstellt. Für Adventure Works ermöglicht dieser Entwurf das Abfragen des Vertriebsmitarbeiters unabhängig von der zugewiesenen Vertriebsregion oder einer bestimmten Version des Vertriebsmitarbeiters.

Um diese Anforderung zu erreichen, muss die Bemaßungstabelle des Power BI-Semantikmodells eine Spalte zum Filtern des Verkäufers und eine andere Spalte zum Filtern einer bestimmten Version des Verkäufers enthalten. Es ist wichtig, dass die Versionsspalte eine nicht mehrdeutige Beschreibung wie David Campbell (12/15/2008-06/26/2019) oder David Campbell (06/27/2019-Current). Außerdem ist es wichtig, dass Berichtsautoren und Benutzer über die Grundlagen von SCD Typ 2 informiert sind und wissen, wie geeignete Berichtsentwürfe durch Anwendung der richtigen Filter erstellt werden.

Es ist eine bewährte Entwurfspraxis, eine Hierarchie einzuschließen, mit der visuelle Elemente einen Drilldown auf die Versionsebene ausführen können.

Dimensionen mit unterschiedlichen Rollen

Eine Dimension mit unterschiedlichen Rollen ist eine Dimension, die verwandte Fakten auf verschiedene Weisen filtern kann. Beispielsweise weist die Tabelle "Datumsdimension" bei Adventure Works drei Beziehungen zu den Vertriebsdaten des Händlers auf. dann kann dieselbe Dimensionstabelle zum Filtern der Fakten nach Bestelldatum, Versanddatum und Lieferdatum verwendet werden.

Für Data Warehouses besteht der akzeptierte Entwurfsansatz darin, eine einzelne Datumsdimensionstabelle zu definieren. Die „Rolle“ der Datumsdimension wird anhand der Faktenspalte festgelegt, die zur Abfragezeit zum Verknüpfen der Tabellen verwendet wird. Wenn Sie beispielsweise die Verkäufe nach Datum analysieren, bezieht sich die Tabellenverknüpfung auf die Spalte für Verkäufe nach Datum des Wiederverkäufers.

In einem Power BI-Semantikmodell kann dieses Design durch Erstellen mehrerer Beziehungen zwischen zwei Tabellen imitiert werden. Im Adventure Works-Beispiel würden die Datums- und Verkaufstabellen des Wiederverkäufers über drei Beziehungen verfügen.

Obwohl dieses Design möglich ist, kann es nur eine aktive Beziehung zwischen zwei Power BI-Semantikmodelltabellen geben. Alle anderen Beziehungen müssen als „inaktiv“ festgelegt werden. Eine einzelne aktive Beziehung bedeutet, dass es eine Standardfilterverteilung von Datum zu Händlerverkäufen gibt. In diesem Fall wird die aktive Beziehung auf den am häufigsten verwendeten Filter festgelegt, der von Berichten verwendet wird, was bei Adventure Works die Bestelldatumsbeziehung ist.

Die einzige Möglichkeit, eine inaktive Beziehung zu verwenden, besteht darin, einen DAX-Ausdruck zu verwenden, der die USERELATIONSHIP-Funktion verwendet. In diesem Beispiel muss der Modellentwickler Measures erstellen, um die Analyse der Verkäufe des Wiederverkäufers anhand des Versand- und Lieferdatums zu ermöglichen. Insbesondere wenn die Wiederverkäufertabelle viele Measures definiert, kann dies mühsam sein. Außerdem wird ein unübersichtlicher Datenbereich erstellt, der eine Überbündelung von Measures enthält. Außerdem gibt es weitere Einschränkungen:

• Wenn Berichtsautoren auf das Zusammenfassen von Spalten angewiesen sind, anstatt Measures zu definieren, können sie keine Zusammenfassungen für die inaktiven Beziehungen erzielen, ohne ein Measure auf Berichtsebene zu schreiben. Measures auf Berichtebene können nur beim Erstellen von Berichten in Power BI Desktop definiert werden.
• Mit nur einem aktiven Beziehungspfad zwischen Datum und Verkäufen des Wiederverkäufers ist es nicht möglich, die Verkäufe des Wiederverkäufers gleichzeitig anhand verschiedener Datumsarten zu filtern. Beispielsweise können Sie kein Visual erstellen, dass das Bestelldatum von Verkäufen anhand des Versanddatums abbildet.

Um diese Einschränkungen zu überwinden, besteht eine allgemeine Power BI-Modellierungstechnik darin, eine Dimensionstabelle für jede Rollenspielinstanz zu erstellen. Sie können jede Dimensionstabelle als referenzierende Abfrage mithilfe von Power Query oder einer berechneten Tabelle mit DAX erstellen. Das Modell kann eine Date Tabelle, eine Ship Date Tabelle und eine Delivery Date Tabelle enthalten, wobei jeweils eine einzelne und aktive Beziehung zu den jeweiligen Spalten der Vertriebstabelle für Wiederverkäufer vorhanden ist.

Für diesen Entwurfsansatz müssen Sie nicht mehrere Measures für verschiedene Datumsrollen definieren, und er ermöglicht die gleichzeitige Filterung anhand unterschiedlicher Datumsrollen. Ein geringer Preis für diesen Entwurfsansatz ist jedoch, dass es eine Duplizierung der Datumsdimensionstabelle geben wird, was zu einer erhöhten Modellspeichergröße führt. Da Bemaßungstabellen in der Regel weniger Zeilen relativ zu Faktentabellen speichern, ist dies nur selten ein Problem.

Es wird empfohlen, beim Erstellen von Modelldimensionstabellen für jede Rolle bewährte Entwurfspraktiken zu befolgen:

• Stellen Sie sicher, dass alle Spaltennamen sich selbst beschreiben. Obwohl es möglich ist, eine Year Spalte in allen Datumstabellen zu haben (Spaltennamen sind innerhalb ihrer Tabelle eindeutig), ist sie nicht selbstbeschreibt standardmäßig visuelle Titel. Erwägen Sie, Spalten in jeder Dimensionsrollentabelle umzubenennen, sodass die Ship Date Tabelle eine Jahresspalte mit dem Namen Ship Yearusw. aufweist.
• Stellen Sie bei Bedarf sicher, dass Tabellenbeschreibungen Feedback zu Berichtsautoren (über QuickInfos im Datenbereich ) darüber geben, wie die Filterverteilung eingerichtet ist. Diese Klarheit ist wichtig, wenn das Modell eine generische benannte Tabelle enthält, z Date. B. zum Filtern vieler Faktentabellen. In dem Fall, dass diese Tabelle z. B. eine aktive Beziehung zu der Spalte "Verkaufsauftragsdatum des Händlers" aufweist, sollten Sie eine Tabellenbeschreibung wie Filters reseller sales by order datez. B. angeben.

Weitere Informationen finden Sie unter Aktive und inaktive Beziehungen im Vergleich – Leitfaden.

Junkdimensionen

Eine Junkdimension ist nützlich, wenn viele Dimensionen vorliegen, insbesondere wenn diese aus nur wenigen Attributen bestehen (z. B. aus nur einem) und wenn diese Attribute nur wenige Werte enthalten. Gute Kandidaten umfassen Bestellstatusspalten oder Kundendemografiespalten wie Geschlecht oder Altersgruppe.

Das Entwurfsziel einer Junk-Dimension besteht darin, viele kleine Dimensionen in einer einzigen Dimension zu konsolidieren, um die Größe des Modellspeichers zu reduzieren und auch die Übersichtlichkeit des Datenbereichs zu reduzieren, indem weniger Modelltabellen angezeigt werden.

Eine Junk-Dimension-Tabelle ist in der Regel das kartesische Produkt aller Attributmember der Dimension mit einer Ersatzschlüsselspalte , um jede Zeile eindeutig zu identifizieren. Sie können die Dimension in einer Data Warehouse-Instanz oder durch Erstellen einer Abfrage mit Power Query erstellen, die vollständige äußere Abfragejoins durchführt und dann einen Ersatzschlüssel hinzufügt (Indexspalte).

Sie laden diese Abfrage als Dimensionstabelle in das Modell. Sie müssen diese Abfrage auch mit der Faktenabfrage zusammenführen, damit die Indexspalte in das Modell geladen wird, um die Erstellung einer 1:n-Modellbeziehung zu unterstützen.

Degenerierte Dimensionen

Eine degenerate Dimension bezieht sich auf ein Attribut der Faktentabelle, die zum Filtern erforderlich ist. Die Bestellnummern für die Verkäufe durch Wiederverkäufer bei Adventure Works sind ein gutes Beispiel hierfür. In diesem Fall ist es nicht sinnvoll, eine unabhängige Tabelle zu erstellen, die nur aus dieser spalte besteht, da sie die Größe des Modellspeichers erhöht und zu einer Unübersichtlichkeit im Datenbereich führt.

Im Power BI-Semantikmodell kann es sinnvoll sein, der Faktentabelle die Spalte "Bestellnummer" hinzuzufügen, um das Filtern oder Gruppieren nach Verkaufsauftragsnummer zu ermöglichen. Es ist eine Ausnahme von der zuvor eingeführten Regel, dass Sie tabellentypen nicht mischen sollten (im Allgemeinen sollten Modelltabellen entweder Dimension oder Tatsache sein).

Wenn die Vertriebstabelle der Adventure Works-Händler jedoch Bestellnummer und Zeilennummernspalten enthält und sie zum Filtern erforderlich sind, wäre das Erstellen einer degenerativen Dimensionstabelle ein guter Entwurf. Weitere Informationen finden Sie im Leitfaden zu 1:1-Beziehungen (Degenerierte Dimensionen).

Faktenlose Faktentabellen

Faktenlose Faktentabellen enthalten keine Measurespalten. Sie enthalten nur Dimensionsschlüssel.

Faktenlose Faktentabellen können Beobachtungen enthalten, die mit Dimensionsschlüsseln definiert werden. Beispielsweise zu einem bestimmten Datum und zu einer bestimmten Uhrzeit, ein bestimmter Kunde, der sich bei Ihrer Website angemeldet hat. Sie können ein Measure definieren, um die Zeilen der Faktentabelle zu zählen, um zu analysieren, wann und wie viele Kunden angemeldet sind.

Eine überzeugendere Verwendung einer faktenlosen Faktentabelle besteht darin, Beziehungen zwischen Dimensionen zu speichern, und es ist ein Power BI-Semantikmodellentwurfsansatz, den wir für die Definition von n:n-Dimensionsbeziehungen empfehlen. Im Entwurf von m:n-Dimensionsbeziehungen wird die faktenlose Faktentabelle als bridging table (Überbrückungstabelle) bezeichnet.

Denken Sie beispielsweise daran, dass Vertriebsmitarbeiter einer oder mehrerer Vertriebsregionen zugewiesen werden können. Die Überbrückungstabelle würde als faktenlose Faktentabelle konzipiert werden, die aus zwei Spalten besteht: Vertriebsmitarbeiterschlüssel und Regionsschlüssel. Beide Spalten können doppelte Werte enthalten.

Dieser m:n-Entwurfsansatz ist gut dokumentiert und ist auch ohne Überbrückungstabelle möglich. Allerdings gilt der Ansatz mit der Überbrückungstabelle als bewährte Methode, wenn zwei Dimensionen in Relation gebracht werden. Weitere Informationen finden Sie im Leitfaden zu m:n-Beziehungen (Herstellen von m:n-Beziehungen zwischen Dimensionen).

Zugehöriger Inhalt

Weitere Informationen zum Design des Sternschemas oder zum Power BI-Semantikmodell finden Sie in den folgenden Artikeln:

• Wikipedia-Artikel zur dimensionalen Modellierung
• Modellieren von Beziehungen in Power BI Desktop
• Leitfaden zu 1:1-Beziehungen
• Leitfaden zu m:n-Beziehungen
• Leitfaden zu bidirektionalen Beziehungen
• Aktive und inaktive Beziehungen im Vergleich – Leitfaden
• Dimensionale Modellierung in Microsoft Fabric Warehouse
• Fragen? Versuchen Sie, die Fabric-Community zu fragen
• Vorschläge? Ideen zur Verbesserung von Fabric beitragen