In diesem Artikel widmen wir uns einem der wichtigsten Themen der Datenmodellierung, nämlich dem Sternenschema. Wenn ihr skalierbare Modelle mit Power BI bauen möchtet, kommt ihr um das Sternenschema nicht herum.
Vorstellung des Sternenschemas
Das Sternenschema ist eine seit Jahren etablierte Best Practice für den Aufbau dimensionaler Datenmodelle. Es kommt sowohl in relationalen Datawarehouses als auch in analytischen Datenmodellen im Rahmen des Reportings zum Einsatz. Das Sternenschema sowie weitere Methoden wurden insbesondere von Ralph Kimball geprägt, einer Koryphäe im Bereich der dimensionalen Modellierung.
Warum sollte ich mich mit dem Sternenschema befassen?
Gerade Personen, welche mit Power BI anfangen, neigen dazu die Anwendung des Sternenschemas zu umgehen, sogar wenn diese schon davon gehört haben. Mache bitte nicht diesen Fehler und versuche so früh wie möglich die hier vorgestellten Methoden in deinem Datenmodell zu berücksichtigen.
Folgend findest du eine Auswahl wesentlicher Gründe, warum deine Datenmodelle dem Sternenschema folgen sollten. Das Gegenstück zu einem Sternenschema ist übrigens eine einzige flache Tabelle (Flat Table), welche alle benötigten Daten enthält. Wenn wir also über die Vorteile eines Sternenschemas sprechen, vergleichen wir es mit dem Flat Table Ansatz.
Nachvollziehbarkeit: Bei der Anwendung des Sternenschemas werden die zugrunde liegenden Daten auf verschiedene Tabellen aufgeteilt und miteinander in Beziehung gesetzt. Durch das Aufteilen können sowohl du als auch Dritte die Inhalte des resultierenden Datenmodells deutlich besser verstehen, was darüber hinaus auch die Zusammenarbeit vereinfacht.
Skalierbarkeit: Das Sternenschema ist eine weit bekannte Praxis seit vielen Jahren. Ich wage hier die These, dass nahezu alle fortgeschrittenen BI-Entwickler:innen dieses Modell kennen und anwenden können. Solch standardisierte Methoden, welche auch noch weit bekannt und akzeptiert sind, sind der Treiber für echte Skalierung.
Bessere DAX-Measures: Bei sehr kleinen Modellen und einfachen Anforderungen hat dieser Aspekt ehrlich gesagt weniger Gewicht. Aber aus jedem Modell können sich mit der Zeit weitere Anforderungen anschließen und irgendwann ist man an dem Punkt, wo das DAX-Coding immer umständlicher wird, wenn die Lösung nicht auf einem sauberen Datenmodell aufgesetzt ist. Aber auch das Anwenden auf einfache Modelle ist zielführend, da du auf diese Art und Weise immer die gleichen Methoden benutzt.
Performance: Die Anwendung des Sternenschemas minimiert die Datenmenge Eures Modells. Als Faustregel lässt sich sagen: Je größer die zugrunde liegende Datenmenge ist und je umfangreicher die darauf basierenden Berechnungen sind, desto größer ist die Performanceverbesserung eines Sternenschema-Modells im Vergleich zu eines einfachen Flat Table Ansatzes.
Aufbau des Sternenschemas
Nun schauen wir uns die wesentlichen Komponenten eines Sternenschemas an. Die folgende Abbildung zeigt ein klassisches Sternenschema. Wie du sehen kannst, besteht es aus einer Faktentabelle, mehreren Dimensionstabellen sowie Beziehungen zwischen der Fakten- und den Dimensionstabellen.
Nun gehen wir eine Ebene runter und schauen uns anhand der Date-Dimensionstabelle (Dim_Date) und der Faktentabelle (Fact_Sales) die wesentlichen Komponenten des Sternenschemas an. Darunter findest du die Kurzbeschreibung zu den jeweiligen Komponenten.
| Nr. | Komponente | Kurzbeschreibung |
|---|---|---|
| 1 | Dimensionstabellen | repräsentiert eine bestimmte Stammdatenkategorie, welche für die Analyse der Daten verwendet werden soll, z.B. Produkte, Kunden oder Zeit |
| 2 | Entität | ist eine Zeile innerhalb der Dimensionstabelle und entspricht einem Objekt innerhalb der Dimensionstabelle. In der Dimensionstabelle Dim_Date ist zum Beispiel ein Tag eine Entität und besitzt somit eine eigene Zeile. In der Tabelle Dim_Product ist jedes einzelne Produkt eine eigene Entität und somit als eigene Zeile aufgelistet. |
| 3 | Primärschlüsselspalte | eine Spalte in einer Dimensionstabelle, welche für jede Entität einen eindeutigen Wert vorhält. Dieser Wert wird auch Primärschlüssel genannt. Der Primärschlüssel identifiziert eine Entität eindeutig und somit auch eine Zeile in der Dimensionstabelle. |
| 4 | Attribute | sind weitere Spalten innerhalb der Dimensionstabelle, welche für die Beschreibung, Kategorisierung und Gruppierung der Entitäten innerhalb der Dimensionstabelle verwendet werden. Bei der Tabelle Dim_Date sind dies zum Beispiel die Spalten Monat, Quartal und Jahr. Zum Beispiel besitzt der 01.03.2023 für das Attribut "Monat" den Wert "März". Das Produkt "Banane" könnte zum Beispiel für das Attribut "Produktgruppe" den Wert "Obst" haben. |
| 5 | Faktentabelle | ist die Tabelle, welche die zu analysierenden Wertespalten und darüber hinaus sogenannte Fremdschlüsselspalten beinhaltet. Die Faktentabelle bildet die Grundlage für die Berechnungen. |
| 6 | Wertespalte | ist eine Spalte in der Faktentabelle, welche die Werte für die Berechnungen enthält, zum Beispiel den Umsatz, Account-Saldo oder die Menge eines verkauften Produkts. Eine Faktentabelle kann dementsprechend auch mehrere Wertspalten haben. |
| 7 | Fremdschlüsselspalten | sind in der Faktentabelle enthaltene Spalten, welche jeweils über eine Beziehung mit der Primärschlüsselspalte einer Dimensionstabelle verknüpft sind. Eine Fremdschlüsselspalte verwendet die Werte der zugeordneten Primärschlüsselspalte. Auf diese Art und Weise wird bestimmt, zu welcher Entität eine Zeile der Faktentabelle (und somit auch der Wert in der Wertespalte) gehört. |
| 8 | 1:n-Beziehung | die technische Verbindung zwischen einer Primärschlüsselspalte und einer Fremdschlüsselspalte. In einem klassischen Sternenschema ist die Beziehung eine 1:n-Beziehung, da in der Primärschlüsselspalte jeder Wert nur einmal vorkommt und in der Fremdschlüsselspalte Werte mehrmals vorkommen können. |
Wie bekomme ich Daten in das Sternenschema-Format?
In einem Artikel zu den Kernaktivitäten einer Reporting-Lösung bin ich darauf eingegangen, dass Quellsysteme die Daten in der Regel für die transaktionale Verarbeitung (OLTP) vorhalten, wir die Daten jedoch gerne in einem für analytische Verarbeitung (OLAP) optimierten Format vorliegen haben möchten. Die Überführung der Daten aus einem OLTP-Format in ein OLAP-Format bedarf der Datenintegration mittels ETL-Aktivitäten.
Das Sternenschema ist genauso ein Form des OLAP-Formats und du solltest während der Arbeit mit Power BI stets daran interessiert sein, die Daten in dieser Form vorliegen zu haben, bevor du Berechnungen durchführst und deine Ergebnisse visualisiert.
Es gibt in Verbindung mit Power BI zwei grundsätzliche Szenarien, wie du an dein Sternenschema-Format kommst.
- Du verbindest dich mit dem Quellsystem und verwendest Power Query, um die Daten mittels ETL-Regeln in das Format zu bringen
- Es existiert in deinem Unternehmen bereits ein Data Warehouse. Im besten Fall sollte dieses auch unter Berücksichtigung der Sternenschema-Methoden aufgesetzt sein, sodass du nur noch Zugriff auf die relevanten Tabellen benötigst
Es gibt natürlich auch die hybride Variante, bei welcher die Daten zwar im Datawarehouse vorliegen, du aber trotzdem in Power Query ETL-Logik ergänzt. Dies geschieht sogar häufig, da das Datawarehouse die Daten so bereitstellt, dass möglichst viele davon profitieren, während du für deinen Sachverhalt ggf. individuelle Sonderanforderungen hast.
Weiterer Artikel zu Sternenschema und ETL in Arbeit! In diesem Artikel geht es erst einmal um das Sternenschema an sich. Die Überführung vorliegender Daten in das Sternenschema mittels Power Query wird in einem separaten Artikel behandelt.
Wie sieht das Ganze in Power BI aus?
Nun schauen wir uns an, wie das Sternenschema in Power BI abgebildet wird. Darüber hinaus zeige ich dir gängige Fehler in diesem Zusammenhang und wie du diese erkennst. Da wir das Thema Datenintegration und ETL in einem separaten Artikel behandeln, gehen wir hier von dem Szenario aus, dass die Dimensions- und Faktentabellen bereits über ein Datawarehouse zur Verfügung stehen.
Sternenschema in Power BI aufbauen
Nachdem wir uns über Power Query mit dem Datawarehouse verbunden haben, stehen uns eine Faktentabelle namens Fact_Sales sowie zwei Dimensionstabellen namens Dim_Date und Dim_Product zur Verfügung.
In der Tabelle Dim_Date entspricht eine Zeile genau einem Tag im Kalenderjahr. Somit verwenden wir die Datumsspalte namens PK_Date als Primärschlüsselspalte.
In der Tabelle Dim_Product entspricht jede Zeile genau einem bestimmten Produkt. Im Datawarehouse wurde für jede Zeile ein Produktprimärschlüssel (PK_ProductKey) anhand einer aufsteigenden Zahlenfolge generiert, sodass jedes Produkt einen eindeutigen Schlüsselwert aufweist.
Wenn ihr genau hinschaut seht ihr, dass es in der Tabelle Dim_Product darüber hinaus eine Spalte namens ProductLabel gibt, welche die „echte“ Produktnummer aufzeigt, welche auch im Tagesgeschäft verwendet wird. Diese könnte theoretisch auch als Primärschlüsselspalte verwendet werden. Jedoch wurde das Schema im Datawarehouse so aufgesetzt, dass für die Produkte neue Schlüssel generiert wurden.
Ein technisch generierter Primärschlüssel, so wie bei unserer Produkttabelle, wird als Surrogate Key bezeichnet. Ein aus dem Tagesgeschäft verwendeter Primärschlüssel wird als Natural Key bezeichnet. Weitere Beispiele für Natural Keys sind die Personalnummer, Kontonummer oder Kundennummer.
Nun werfen wir eine Blick auf die Faktentabelle. Wir ihr sehen könnt, gibt es hier entsprechend die Fremdschlüsselspalten ProductKey und FK_Date. Im Gegensatz zu den Dimensionstabellen können dort die Schlüsselwerte redundant vorkommen, da ja an einem Tag auch mehrere Produkte gekauft werden können. Und wenn dies geschieht, wird mit jedem Verkauf eine Zeile in der Faktentabelle erzeugt und der gleiche Tag als Fremdschlüsselreferenz zur Dim_Date-Tabelle verwendet.
Darüber hinaus sehen wir die Wertespalte namens SalesAmount, welche die Verkaufsumsätze jedes Verkaufs abbildet. Die erste Zeile gibt zum Beispiel wieder, dass am 02.01.20 das Produkt mit dem Primärschlüsselwert 956 verkauft wurde und damit ein Umsatz von 1.544,40 Euro erzielt wurde.
Da unsere Tabellen bereits im Datawarehouse aufbereitet wurden, laden wir diese direkt weiter in die Data Model View.
In der Data Model View werden nun die Beziehungen zwischen den Primärschlüsselspalten der Dimensionstabellen und den Fremdschlüsselspalten der Faktentabelle gesetzt.
Beim Laden der Daten über Power Query in die Data Model View versucht Power BI auf Basis der Spaltennamen selbstständig die Beziehungen zu setzen. Sollte dies nicht der Fall sein, kannst du die Beziehungen per Drag & Drop selbst setzen, indem du auf ein Primärschlüsselfeld klickst und es mit gedrückter Maus auf das zugehörige Fremdschlüsselfeld in der Faktentabelle ziehst.
Beziehungen haben in Power BI zwei wesentliche Eigenschaften, die Kardinalität und die Filterrichtung.
Kardinalität der Beziehung:
Beachte auf dem Bild die Enden der Beziehungen. Das Sternchen-Symbol zeigt die n-Seite der 1:n-Beziehung. Das 1-Symbol zeigt die 1-Seite der 1:n-Beziehung. Sollte es in deinem Modell anders aussehen, sind die Werte in der Primärschlüsselspalte der Dimensionstabelle nicht eindeutig und/oder die Werte in der Fremdschlüsselspalte der Faktentabelle nicht mehrdeutig. Zweiteres kann vorkommen und ist theoretisch ok, ist aber eher selten der Fall.
Filterrichtung der Beziehung:
Neben der Kardinalität besitzt eine Beziehung in Power BI eine Filterrichtung, welche durch den Pfeil gekennzeichnet ist. In unserem Fall kann Dim_Date zum Beispiel Fact_Sales filtern. Fact_Sales kann aber wiederum nicht Dim_Date filtern. Gleiches gilt für Dim_Product und Fact_Sales. Auch wenn Dim_Product die Fact_Sales-Tabelle filtern kann, kann sie jedoch nicht Dim_Date filtern.
Das Sternenschema in Power BI benutzen
Sobald das Datenmodell bereitsteht, können wir auch schon mit dem Aufbau des Berichts in der Report View beginnen. In dem folgenden Beispiel verwende ich ein Matrix-Visual, um die Umsätze nach Zeit und Produktfarbe zu analysieren.
Wie du sehen kannst, habe ich aus den verschiedenen Tabellen die Spalten in das Visual gezogen.
- Die Umsätze aus der Fact_Sales-Tabelle sind in dem Wertefeld des Matrix-Visuals
- Die Attribute Jahr, Quartal und Monat aus der Dim_Date-Tabelle sind in dem Zeilenfeld des Matrix-Visuals
- Das Attribute für die Produktfarbe aus der Dim_Product-Tabelle ist in dem Spaltenfeld des Matrix-Visuals
Obwohl die Spalten aus verschiedenen Tabellen kommen, ist es möglich diese miteinander auszuwerten. Dies funktioniert allein über die gesetzten 1:n-Beziehungen. Die Umsätze liegen zwar in der Faktentabelle, sind aber über die Schlüsselspalten inkl. der Beziehung anhand der Dimensionstabellenattribute auswertbar.
Klassische Fehler bei der Verwendung des Sternenschemas in Power BI
Im Zusammenhang mit dem Sternenschema gibt es typische Fehler, welche dir gerade am Anfang öfter über den Weg laufen. Daher zeige ich nun, welche Fehler dies sind und wann diese auftauchen.
Fehlende Werte in der Primärschlüsselspalte (Dimensionstabelle)
Manchmal kommt es vor, dass du in einer Fremdschlüsselspalte in der Faktentabelle Schlüsselwerte hast, welche jedoch nicht in der verknüpften Primärschlüsselspalte vorkommen. In dem unteren Beispiel gibt es in der Faktentabelle zum Beispiel Werte für 2020. Meine Dim_Date Dimensionstabelle führt aber nur Datumswerte ab 2021 auf. Daher kann Power BI keine Verbindung zwischen den Datumswerten der Faktentabelle und denen der Dimensionstabelle ableiten.
Dies spiegelt sich darin wieder, dass einige Ausprägungen sinnvolle Ergebnisse abbilden, jedoch zusätzliche Werte ohne Zuordnung angezeigt werden (siehe Bild unten).
Falsche Spalten für Beziehung oder abweichende Datentypen
Eine weitere klassische Fehlerquelle ist, dass durch dich oder durch Power BI (bei automatischer Zuordnung) die Beziehung zwischen den falschen Spalten gesetzt wurde. Wenn dies passiert und die Spalten keine übereinstimmenden Schlüsselwerte besitzen, kann Power BI auch keine Werte zu den Ausprägungen der Dimensionstabelle finden. Das Ergebnis sieht dann wie in dem untenstehenden Bild aus. Das gleiche Problem bekommt ihr auch, wenn ihr zwar die richtigen Spalten miteinander verknüpft, jedoch diese Spalten nicht den gleichen Datentyp vorweisen.
Beachte: Prüfe genau, ob die richtigen Spalten miteinander verknüpft sind und stelle sicher, dass die verknüpften Spalten den gleichen Datentyp vorweisen.
Fehlende Beziehung
Wenn ihr zum Beispiel mit mehreren Faktentabellen arbeitet (siehe nächstes Kapitel) und nicht jede Dimensionstabelle mit jeder Faktentabelle verbunden ist, dann kann es auch mal vorkommen, dass ihr versehentlich eine Faktentabelle mit einer nicht verknüpften Dimensionstabelle in ein Visual zusammenführt. Unter gewissen Umständen identifiziert Power BI dann, dass zwischen diesen Tabellen keine Beziehung besteht und gibt folgende Fehlermeldung zurück.
Hinweis: Im Zusammenhang mit der Verwendung von Measures (womit du früh anfangen solltest) gibt es fortgeschrittene Szenarien, bei welchen bewusst Tabellen ohne Beziehung zu einer Faktentabelle als Hilfstabelle für Berechnungen verwendet werden. In diesen Szenarien kommt kein Error, da über die DAX-Logik ein Berechnungsverhalten mitgegeben wird.
Ausbaustufen des Sternenschemas
Wir haben uns in diesem Beitrag das klassische Sternenschema angeschaut. Mit zunehmenden Anforderungen entsteht allerdings die Notwendigkeit, das Modell um weitere Aspekte zu erweitern. Auch wenn wir uns im Rahmen dieses Artikels auf die Grundlagen konzentrieren, möchte ich dir mit der folgenden Übersicht erste Impulse für weitere Themen im Zusammenhang mit dem Sternenschema geben.
| Ausbaustufe | Kurzbeschreibung |
|---|---|
| Schneeflocken Schema | eine Form des Sternenschemas, bei welcher mehrere Dimensionstabellen hintereinandergeschaltet werden. So gibt es zum Beispiel eine Dimensionstabelle für Produkte und eine für Produktgruppen. Die Produkttabelle ist mit der Faktentabelle verknüpft und die Produktgruppentabelle mit der Produkttabelle. Persönlich versuche ich diese Form in meinen Modellen zu vermeiden. Es gibt aber einige Szenarien, in welchen es durchaus einen Mehrwert generiert. |
| Mehrere Faktentabellen | Dies ist ein sehr häufig vorkommendes und vor allem effektives Mittel für die cross-funktionale Auswertung. In unserem Beispiel haben wir nur eine Faktentabelle und mehrere Dimensionstabellen angeschaut. Natürlich könnte es neben unserer Fact_Sales-Tabelle noch eine Fact_Temperature-Tabelle geben. Wenn nun beide Faktentabellen mit einer Dim_Date-Tabelle verknüpft sind ist es möglich, die Umsätze in Verbindung mit dem Wetter zu analysieren, obwohl die Daten in verschiedenen Tabellen liegen. |
| Junk-Dimension | In unserem Beispiel waren die Dimensionstabellen trennscharf und verfügten über eine Reihe weiterer Attribute für eine gruppierte Auswertung. Es gibt jedoch regelmäßig auch einspaltige Kategorien ohne weitere relevante Attribute, nach denen man Daten auswerten möchte. Damit man nun nicht für jede dieser Kategorien eine neue Dimensionstabelle anlegen muss, gibt es das Prinzip der Junk-Dimension. Die Junk-Dimension fasst mehrere fremdartige Kategorien in einer Tabelle zusammen, wobei für alle Kombinationen der Kategorieausprägungen eine eigene Zeile generiert wird. Diese Junk-Dimension lässt sich dann mit der Faktentabelle verknüpfen und über die Junk-Dimension filtern, ohne das Datenmodell mit mehreren einspaltigen Dimensionen aufzublähen. |
| Slowly Changing Dimensions | Dimensionen repräsentieren die Stammdaten eines Datenmodells. In unserem einfach Beispiel gehen wir allerdings davon aus, dass eine Entität bezogen auf ein Attribut einen bestimmten Wert aufweist. Was ist aber, wenn sich ein Attributwert für eine Entität ändert und ich diese Veränderung auch historisch auswerten möchte? Die Anforderung, Historie in Dimensionstabellen abzubilden, wird Slowly Changing Dimensions genannt, wobei es vier verschiedene Typen gibt, welche Lösungsansätze für den Umgang mit der historischen Analyse von Dimensionstabellen beschreiben. |
Fazit
Diese Artikel gab dir eine Einführung in die Grundlagen des Sternenschemas. Ich hoffe, dass du aus dem Artikel die folgenden Punkte entnehmen konntest.
- Das Sternenschemas ist eine der wichtigsten Grundlagen für die Datenmodellierung mit Power BI
- Es fördert die Nachvollziehbarkeit, Skalierbarkeit, das DAX-Coding und die Performance
- Ein Sternenschema besteht aus Dimensionstabellen, einer oder mehreren Faktentabellen, Primärschlüsselspalten, Fremdschlüsselspalten, Attributen, Beziehungen und Wertespalten
- Dimensionstabellen repräsentieren die Stammdaten und beinhalten Attribute für die Kategorisierung
- Mithilfe der Dimensionstabellen werden die Faktentabellen gefiltert. wodurch die darin enthaltenen Werte anhand der Attribute gruppiert ausgewertet werden können
- Du weißt, wie ein Sternenschema in Power BI aussieht und wie du schnell Fehler in deinem Modell erkennst
- Du solltest die beschriebenen Methoden sowohl bei kleinen als auch bei großen Datenmodell anwenden
Ich freue mich sehr, dass du es bis hierhin geschafft hast! Bleib datenhungrig und bis bald!
