Gute Datenmodellierung ist entscheidend, um Power-BI-Berichte zu erstellen, die performant sind und bei Bedarf mitwachsen.
In diesem Tutorial verwenden wir ein von Microsoft bereitgestelltes Beispieldataset, das wir so angepasst haben, dass es die Best Practices der Datenmodellierung widerspiegelt, die wir im Artikel besprechen. Du kannst das Dataset hier herunterladen.
Was ist Datenmodellierung?
Datenmodellierung bedeutet, die Verbindungen zwischen Datenstrukturen visuell darzustellen – inklusive Informationen über die einzelnen Attribute innerhalb dieser Strukturen.
Sprecht man allgemein über Datenmodellierung, fällt am häufigsten der Begriff Sternschema. Dieses Vorgehen zur Gestaltung von Data-Warehouses und relationalen Datenbanken ist weit verbreitet und wird auch in Power BI empfohlen.
Das Sternschema hat zwei zentrale Vorteile:
- Benutzerfreundlichkeit: Ein Sternschema macht dein Datenmodell aufgeräumter und strukturierter – dein Bericht lässt sich leichter bedienen.
- Performance: Sternschemata lassen sich problemlos auf sehr große Datenmengen skalieren. DAX-Messwerte werden schneller berechnet und der gesamte Power-BI-Bericht aktualisiert schneller.
Wie funktioniert ein Sternschema?
Ein Sternschema besteht aus einer zentralen Faktentabelle, von der mehrere Dimensionstabellen abzweigen – wie die Zacken eines Sterns. Idealerweise enthält ein Datenmodell nur eine Faktentabelle. In Power BI sind jedoch auch mehrere Faktentabellen möglich.
Power-BI-Sternschema. Bild: Autor
Eine Faktentabelle besteht aus Werten, die sich zusammenfassen und aggregieren lassen, sowie aus einem oder mehreren Schlüsseln, die zu den Dimensionstabellen verknüpfen. Diese Schlüssel verbinden die Tabellen miteinander. Bei komplexen Modellen oder großen Datenmengen sollten Schlüssel nach Möglichkeit numerisch und nicht als Text vorliegen – das steigert die Performance.
Faktentabellen sollten schmal sein und so wenige Spalten wie möglich enthalten. Beschreibende Spalten wie Produktname oder Produktkategorie gehören – falls nicht schon im Data-Warehouse getrennt – in eigene Dimensionstabellen. Dieser Prozess heißt Normalisierung; Ziel ist es, Redundanzen zu vermeiden.
Dimensionstabellen beschreiben die Merkmale des Datasets. Verwandte Merkmale werden logisch in separaten Tabellen gruppiert, um eine einzelne Tabelle nicht aufzublähen und Beziehungen einfacher zu halten. Dimensionstabellen sollten für die beschriebenen Merkmale eindeutige Werte enthalten; ihre Spalten filtern oder gruppieren später die Daten im Power-BI-Bericht.
Eine Erweiterung des Sternschemas ist das Schneeflockenschema. Dabei werden Dimensionstabellen weiter aufgeteilt, wenn ein Merkmal weitere Kategorien oder Unterkategorien hat. In unserem Fall enthält die Products-Tabelle Product ID, Product Name und Product Category. Im Schneeflockenschema würde die Products-Tabelle nur Product ID und Product Name enthalten; die Product Category läge in einer eigenen Tabelle mit Product Category ID und Product Category.
Power-BI-Schneeflockenschema. Bild: Autor
Allerdings erhöht ein Schneeflockenschema oft unnötig die Komplexität. Zusätzliche Tabellen können die Performance verschlechtern und das Erstellen von Beziehungen erschweren oder unübersichtlich machen.
So erstellst du Beziehungen in Power BI
Es gibt zwei Möglichkeiten, in Power BI eine Beziehung anzulegen:
- Ziehe ein Feld aus einer Tabelle auf das entsprechende Feld in der zweiten Tabelle, zu der du die Beziehung herstellen willst.
- Wähle im Menüband Manage Relationships und klicke auf „New“, um eine Beziehung im gleichen Dialog zu erstellen, den wir gleich besprechen (nur dass er leer startet).
Standardmäßig versucht Power BI, Beziehungen zwischen Tabellen zu erkennen; das klappt nicht immer. Du kannst diese Funktion in den Einstellungen deaktivieren oder automatisch erzeugte Beziehungen löschen. Um eine Beziehung zu bearbeiten, klicke mit der rechten Maustaste auf die Verbindungslinie und wähle „Properties“.
Im Dialog gibt es zwei wichtige Optionen: Kardinalität und Kreuzfilterrichtung. Die Auswahl wirkt sich stark auf deinen Bericht aus – also sorgfältig entscheiden. Schauen wir uns beide Optionen an.
Beziehungen in Power BI erstellen. Bild: Autor
Kardinalität
Es gibt vier Kardinalitäten: Many-to-one, One-to-one, One-to-many und Many-to-many.
Empfohlen ist, dass das Verknüpfungsfeld in mindestens einer Tabelle eindeutige Werte enthält. So kannst du in deinem Modell One-to-many- oder Many-to-one-Beziehungen nutzen.
In unseren Daten besteht eine Beziehung zwischen der Financials-Tabelle und der Products-Tabelle über das Feld Product ID. In der Products-Tabelle ist jedes Produkt eindeutig (jedes Produkt kommt nur einmal vor). In der Financials-Tabelle kann dasselbe Produkt jedoch mehrfach vorkommen – nach Datum, Land, Segment usw.
Many-to-many ist am problematischsten. Es kann in komplexen Modellen sehr nützlich sein, sollte aber nur gewählt werden, wenn du die Folgen vollständig verstehst.
Zur Veranschaulichung erstellen wir eine jährliche Sales-Target-Tabelle nach Produktkategorie im Datenmodell. Wir möchten Umsätze und Ziele nebeneinander im selben Visual ausweisen. Das lässt sich erreichen, indem wir eine Many-to-many-Beziehung zwischen der Sales-Target-Tabelle und der Product-Tabelle herstellen.
Many-to-many-Beziehungen in Power BI. Bild: Autor
Im folgenden Tabellenvisual sehen wir Umsätze und Ziele nebeneinander für jede Produktkategorie.
Produktkategorie, Umsatz und Zielwert. Bild: Autor
Wenn wir diese Tabelle jedoch auf Produktebene betrachten, wären die Zielwerte komplett falsch. Grund ist die unterschiedliche Granularität: Da es Ziele nur auf Kategorieebene gibt, kann Power BI keine sinnvollen Zielwerte auf Produktebene anzeigen und dupliziert sie daher für jedes Produkt der Kategorie. Wenn du diese Auswirkung einer Many-to-many-Beziehung nicht kennst, kann das in der Berichterstattung gravierende Fehler verursachen.
Produktkategorie, Umsatz und Zielwert. Bild: Autor
Richtung
Bei der Kreuzfilterrichtung kannst du zwischen Single und Both wählen. Beziehungen fließen von der Tabelle mit eindeutigen Werten zur Tabelle mit vielen Werten. In unserem Fall verläuft die Beziehung von der Products- zur Financials-Tabelle. Ist die Kreuzfilterrichtung auf Single gesetzt, lässt sich die Financials-Tabelle über Produkt- und Produktkategorie-Felder der Products-Tabelle filtern. Die Products-Tabelle lässt sich jedoch nicht über Product ID in der Financials-Tabelle oder über Merkmale anderer Dimensionstabellen filtern.
Single Direction ist in den meisten Fällen zu empfehlen. Bi‑direktionale Beziehungen (Option „Both“) verschlechtern nicht nur die Performance, sondern können auch Mehrdeutigkeiten beim Filtern erzeugen.
In unserem Beispiel bestehen zwischen Product, Countries und Financials jeweils Single-Direction-One-to-many-Beziehungen. Das bedeutet: Ein Filter nach Land wirkt nicht zurück auf die Product-Tabelle. In den untenstehenden Slicern siehst du: Wenn ein Land (z. B. USA) ausgewählt wird, passt sich der Produktslicer nicht automatisch auf die in diesem Land relevanten Produkte an.
Slicer in Power BI. Bild: Autor
Änderst du die Beziehung zwischen Products und Financials auf bi‑direktional, kann die Filterung in die Products-Tabelle fließen. Dann erscheint z. B. das Produkt Carretera nicht mehr im Produktslicer, weil es in den USA keine Verkäufe dafür gibt.
Slicer in Power BI. Bild: Autor
Alternativ kannst du, um bi‑direktionale Beziehungen zu vermeiden, im Slicer einen Filter setzen, der leere Elemente ausschließt. Beachte: Das müsstest du für jedes Visual tun, das Felder aus mehreren Dimensionstabellen nutzt.
Filter und Slicer in Power BI. Bild: Autor
So optimierst du dein Power-BI-Modell
Der wichtigste Hebel für ein performantes Power-BI-Modell sind gute Modellierungspraktiken wie in diesem Tutorial beschrieben. Häufig ermöglicht schon ein sauberes Datenmodell, dass ein Bericht Millionen oder sogar Milliarden Zeilen skaliert – bei weiterhin solider Performance.
Zusätzlich zu guter Modellierung kannst du Folgendes tun, um dein Power-BI-Modell zu optimieren:
- Time Intelligence deaktivieren – Power BI erstellt automatisch Datums-/Uhrzeit‑Hierarchien, sobald ein Datumsfeld in ein Visual gezogen wird. Jede dieser Hierarchien entspricht im Grunde einer zusätzlichen Tabelle im Modell. Das bläht den Bericht auf, bremst die Visuals und verlängert die Aktualisierung. Deaktiviere diese Funktion und nutze stattdessen eine dedizierte Datumstabelle für alle Datums-/Uhrzeithierarchien.
- Nur benötigte Spalten laden – Entferne im Power Query Editor Spalten, die du im Bericht nicht brauchst. Ein häufig unnötig mitgeladenes Feld ist z. B. eine Row ID (etwa Order ID pro Transaktion in einer Orders-Tabelle). Oft ist diese ID zudem als Text gespeichert, was das Modell zusätzlich aufbläht. Wenn das ID-Feld nicht explizit in einer Beziehung verwendet wird, musst du es in der Regel nicht laden.
- Nur benötigte Zeilen laden – Du musst nicht dein gesamtes Unternehmensdatenarchiv in den Bericht importieren. Gerade bei langen Historien landen sonst viele Daten im Modell, die niemand nutzt. Sprich mit den Stakeholdern und kläre, wie viel Historie sie wirklich brauchen. Falls ältere Daten nötig sind, importiere ggf. nur eine aggregierte Version statt aller Einzeltransaktionen.
Werde ein Power BI Datenanalyst
Beherrsche das beliebteste Business Intelligence Tool der Welt.