Datenmodellierung in Power BI: Sternschemata, Beziehungen und Muster für die Leistung

Ein Datenmodell in Power BI entscheidet darüber, wie schnell Ihre Berichte laufen, wie eingängig sie zu bauen sind und wie genau sie Kennzahlen berechnen. Das tragende Muster ist das Sternschema: Faktentabellen (Transaktionen, Ereignisse), umgeben von Dimensionstabellen (Produkte, Kunden, Datumsangaben). Die Beziehungen zwischen den Tabellen steuern, wie Filter weiterfließen und wie DAX-Measures verdichten.

Das Modell richtig zu bekommen zählt mehr als jede gestalterische Entscheidung im Visuellen. Ein schlechtes Modell erzeugt langsame, ungenaue Berichte, die keine noch so gute DAX-Optimierung rettet. Ein sauber gebautes Sternschema mit passenden Beziehungen, sparsamen Datentypen und klaren Measures macht das Bauen von Berichten fast zur Nebensache: Filter wirken wie erwartet, Berechnungen stimmen, und das Tempo bleibt hoch, während die Daten wachsen.

Sternschema: das Fundament

Ein Sternschema trennt Daten in zwei Arten von Tabellen. Faktentabellen enthalten die messbaren Ereignisse: Verkaufstransaktionen, Besuche auf der Website, Support-Tickets. Sie sind hoch (viele Zeilen) und schmal (wenige Spalten), überwiegend numerische Werte und Fremdschlüssel. Dimensionstabellen enthalten die beschreibenden Merkmale: Produktnamen, Kundensegmente, Datumsbezeichnungen. Sie sind breit (viele Spalten) und kurz (verhältnismäßig wenige Zeilen).

Ein konkretes Beispiel: eine Tabelle Sales Fact mit den Spalten DateKey, ProductKey, CustomerKey, Quantity, UnitPrice und TotalAmount. Jeder Schlüssel führt zu einer Dimension: Die Date Dimension liefert Jahr, Quartal, Monat und Wochentag. Die Product Dimension liefert ProductName, Category, Subcategory und Brand. Die Customer Dimension liefert CustomerName, Segment, Region und City.

Sternschemata schlagen flache Tabellen in Power BI aus drei Gründen. Erstens verdichtet die VertiPaq-Engine von Power BI Dimensionsspalten mit geringer Kardinalität außerordentlich gut: Eine Spalte „Category“ mit 20 verschiedenen Werten schrumpft auf fast nichts. Zweitens ist die Filterrichtung eindeutig: Filter fließen von den Dimensionen zu den Fakten und bilden nie einen Kreis. Drittens arbeiten DAX-Measures am besten, wenn sie über eine schmale Faktentabelle mit ganzzahligen Schlüsseln verdichten und nicht breite Tabellen mit wiederholten Texten durchsuchen.

Das Anti-Muster, das es zu vermeiden gilt, ist die „eine große Tabelle“: eine einzige entnormalisierte Tabelle mit jeder Spalte. Bei 10.000 Zeilen läuft das gut. Bei 10 Millionen Zeilen verbraucht sie 5- bis 10-mal mehr Speicher als ein gleichwertiges Sternschema, Filter werden unvorhersehbar, und DAX-Berechnungen verlangsamen sich bis zum Kriechen, weil VertiPaq wiederholte Texte nicht wirksam verdichten kann.

Beziehungen und Filterfluss

Beziehungen legen in Power BI fest, wie Filter sich zwischen Tabellen bewegen. Wählt jemand in einem Datumsschieber „2025“, filtert Power BI die Date Dimension auf dieses Jahr und reicht den Filter über die Beziehung an die Tabelle Sales Fact weiter, sodass nur Transaktionen aus 2025 erscheinen.

Das übliche Muster ist eins zu viele: Eine Zeile in der Dimension passt zu vielen Zeilen in der Faktentabelle. Der Filter fließt immer von der Eins-Seite (Dimension) zur Viele-Seite (Fakt). Diese Richtung ergibt sich von selbst und ist eindeutig.

Beidseitiges Filtern kehrt den Fluss um und lässt Faktentabellen Dimensionen filtern. Ein Beispiel: In einem Visual, das an Sales Fact hängt, ein Produkt auswählen und die Customer Dimension so filtern, dass nur Kunden erscheinen, die dieses Produkt gekauft haben. Das ist mächtig und zugleich riskant: Beidseitige Filter verlangsamen Abfragen und können in verzweigten Modellen mehrdeutige Filterpfade erzeugen. Verzichten Sie darauf, solange der Anwendungsfall es nicht ausdrücklich verlangt.

Rollenspielende Dimensionen entstehen, wenn eine Faktentabelle mehrere Beziehungen zu derselben Dimension hat. Ein Verkaufsfakt kann sowohl OrderDateKey als auch ShipDateKey führen, beide auf die Date Dimension zeigend. Power BI erlaubt je Tabellenpaar nur eine aktive Beziehung. Die zweite wird inaktiv und muss in DAX ausdrücklich über USERELATIONSHIP() aktiviert werden:

ShippedRevenue = CALCULATE(SUM(Sales[TotalAmount]), USERELATIONSHIP(Sales[ShipDateKey], DateDim[DateKey]))

Measures und berechnete Spalten

Diese Unterscheidung bringt die meisten Einsteigerinnen und Einsteiger in Power BI ins Stolpern, und sie falsch zu treffen führt zu aufgeblähten Modellen und falschen Berechnungen.

Berechnete Spalten werden einmal bei der Aktualisierung berechnet und im Modell gespeichert. Sie arbeiten im Zeilenkontext: Jede Zeile bekommt einen Wert auf Basis ihrer eigenen Daten. Verwenden Sie sie für feste Einordnungen, die sich nicht mit den Filtern der Nutzer ändern, etwa eine Spalte PriceBand, die den Listenpreis über einen Schwellenwert in die Bänder Premium und Standard einordnet. Der Wert bleibt gleich, gleich was auf dem Dashboard ausgewählt wird; der vollständige DAX-Ausdruck steht in der Abbildung darunter.

Measures werden zur Abfragezeit als Antwort auf die Handlungen der Nutzer berechnet. Sie arbeiten im Filterkontext: Das Ergebnis ändert sich danach, welche Filter aktiv sind. TotalRevenue = SUM(Sales[TotalAmount]) gibt eine andere Zahl zurück, wenn „EMEA“ statt „Nordamerika“ ausgewählt ist. Measures verbrauchen keinen Speicher, weil sie Formeln sind und keine Daten.

Die Entscheidungsregel: Ändert sich der Wert mit der Auswahl der Nutzer (Gesamtumsatz für die gewählte Region, Wachstum gegenüber dem Vorjahr für das gewählte Produkt), nehmen Sie ein Measure. Steht der Wert je Zeile fest, unabhängig vom Filterkontext (Produkte in Preisbänder einordnen, die Domäne aus einer E-Mail-Adresse ziehen), nehmen Sie eine berechnete Spalte. Im Zweifel nehmen Sie ein Measure: Sie gehen sparsamer mit Speicher um und sind beweglicher.

Hierarchien und Drill-down

Hierarchien ermöglichen das Hineinnavigieren in Visuals. Eine Datumshierarchie (Jahr, Quartal, Monat, Tag) lässt Nutzer bei der Jahressicht beginnen und in Monate hineingehen, um Verläufe zu finden. Eine Produkthierarchie (Kategorie, Unterkategorie, Produkt) lässt sie von breiten Kategorien zu einzelnen Artikeln wandern. Eine Geografiehierarchie (Land, Bundesland, Stadt) trägt die regionale Auswertung.

Bauen Sie Hierarchien in der Modellansicht, indem Sie Spalten in eine Hierarchiegruppe ziehen. Legen Sie immer eine eigene Datumsdimension an, statt sich auf die automatisch erzeugte Datumshierarchie von Power BI zu verlassen: Der eingebaute Fassung fehlen das Geschäftsjahr, eigene Wochendefinitionen und Feiertagskennzeichen. Markieren Sie die Tabelle mit Mark as Date Table, damit Funktionen der Zeitintelligenz wie TOTALYTD und SAMEPERIODLASTYEAR richtig arbeiten.

Leistung optimieren

Leistungsprobleme in Modellen von Power BI gehen fast immer auf eines von fünf Dingen zurück, hier nach Wirkung geordnet:

1. Textschlüssel statt ganzzahliger Schlüssel. Verbindet sich Ihre Faktentabelle über Textspalten wie Produktcodes oder Kundennummern mit Dimensionen, wechseln Sie auf ganzzahlige Ersatzschlüssel. VertiPaq verdichtet Ganzzahlen weit wirksamer, und Hash-Joins auf Ganzzahlen sind 3- bis 5-mal schneller. Diese eine Änderung kann die Modellgröße um 40 % senken.

2. Ungenutzte Spalten. Jede Spalte im Modell verbraucht Speicher und verlängert die Aktualisierung, auch eine Spalte, die in keinem Visual vorkommt. Entfernen Sie Spalten, die Sie nicht brauchen, schon in Power Query, bevor sie das Modell erreichen. Ein häufiger Fall: alle 80 Spalten einer Quelltabelle zu laden, während der Bericht 12 verwendet.

3. Textspalten hoher Kardinalität in Faktentabellen. Eine Spalte „Description“ mit 5 Millionen verschiedenen Werten in einer Faktentabelle bläht das Modell stark auf. Verschieben Sie beschreibenden Text in Dimensionstabellen oder entfernen Sie ihn ganz, wenn er in der Auswertung nicht gebraucht wird.

4. Berechnete Spalten, wo Measures reichen. Eine berechnete Spalte, die laufende Summen für 50 Millionen Zeilen bildet, speichert 50 Millionen Werte. Das gleichwertige Measure berechnet dasselbe Ergebnis im Vorbeigehen und braucht keinen Speicher.

5. Fehlende Verdichtungstabellen. Bei Datenbeständen über 100 Millionen Zeilen legen Sie vorverdichtete Übersichtstabellen im Quellsystem an (oder in Databricks). Die Verdichtungsfunktion von Power BI leitet Abfragen nach Möglichkeit auf die Übersichtstabelle und fällt für das Hineingehen auf die Detailtabelle zurück. Das kann Abfragezeiten von Minuten auf Millisekunden senken.

Als Anhalt für die Größe: Modelle unter 500 MB laufen auf geteilter Kapazität gut. Modelle zwischen 500 MB und 1 GB brauchen sorgfältige Optimierung oder Premium-Kapazität. Modelle über 1 GB verlangen Premium oder Fabric und sollten mit schrittweiser Aktualisierung und Partitionierung arbeiten.

Sicherheit auf Zeilenebene

Die Sicherheit auf Zeilenebene (RLS) schränkt ein, welche Datenzeilen jeder Nutzer sehen darf. Eine Regionalleitung soll nur die Daten ihrer Region sehen. Eine Person im Vertrieb nur ihre Kunden. RLS macht das innerhalb eines einzigen gemeinsamen Berichts möglich.

Die Umsetzung: In Power BI Desktop eine Sicherheitsrolle anlegen, einen DAX-Filterausdruck festlegen und im Power BI Service Nutzer den Rollen zuweisen. Für eine Regionalleitung, die nur EMEA-Daten sehen soll:

[Region] = LOOKUPVALUE(Users[Region], Users[Email], USERPRINCIPALNAME())

Dieser Ausdruck filtert die Tabelle Sales Fact auf Zeilen, die zur zugewiesenen Region des aktuellen Nutzers passen. Der Filter fließt über die Beziehungen weiter: Hängt Sales an Product und Customer, werden auch diese Dimensionen auf das gefiltert, was für EMEA einschlägig ist.

Prüfen Sie RLS in Power BI Desktop über View as Role, bevor Sie veröffentlichen. Nach dem Veröffentlichen im Power BI Service weisen Sie in den Einstellungen des Datensatzes Nutzer oder Gruppen aus Azure AD jeder Sicherheitsrolle zu. Ein häufiger Fehler: den Bericht veröffentlichen, aber das Zuweisen der Nutzer zu den Rollen vergessen. Das Ergebnis ist ein leerer Bericht für alle außer der veröffentlichenden Person.

Fortgeschrittene Muster

Zusammengesetzte Modelle verbinden Tabellen im Import- und im DirectQuery-Modus in einem Modell. Importieren Sie Ihre Dimensionstabellen für schnelles Filtern und lassen Sie große Faktentabellen im DirectQuery-Modus gegen Databricks. So bekommen Sie beides: interaktives Filtern über Dimensionen mit lebenden Faktendaten.

Berechnungsgruppen ersparen sich wiederholende Measures der Zeitintelligenz. Statt für jedes Measure eigene Fassungen für YTD, QTD und MTD anzulegen (Umsatz YTD, Kosten YTD, Marge YTD …), legen Sie eine Berechnungsgruppe mit Elementen der Zeitintelligenz an, die auf jedes Measure wirken. Das kann ein Modell mit 60 Measures auf 20 Basis-Measures plus eine Berechnungsgruppe verkleinern. Verlangt Premium- oder Fabric-Kapazität.

Viele-zu-viele-Beziehungen über Brückentabellen decken die Fälle ab, in denen das übliche Muster eins zu viele nicht passt. Ein Kunde, der zu mehreren Segmenten gehört, oder ein Produkt, das in mehreren Aktionen vorkommt, verlangt eine Brückentabelle, damit keine Zeilen vervielfacht werden. Entwerfen Sie diese sorgfältig: Falsche Brückentabellen erzeugen aufgeblähte Summen.

Rollenspielende Dimensionen sind dieselbe Dimensionstabelle, mehrfach mit verschiedenen Beziehungen verwendet. Die Date Dimension, verbunden mit OrderDate (aktiv) und ShipDate (inaktiv), ist das klassische Beispiel. Verwenden Sie USERELATIONSHIP() in Measures, die den anderen Beziehungspfad brauchen. Manche Modellierende legen lieber getrennte physische Kopien der Dimension an (eine Tabelle OrderDate, eine ShipDate), um der Umständlichkeit inaktiver Beziehungen zu entgehen.

Wie Dawiso Ihr Datenmodell dokumentiert

Datenmodelle in Power BI sind oft Wissen, das nur im Team kursiert. Die Person, die das Modell gebaut hat, weiß, dass „Umsatz“ Retouren ausschließt, dass „aktiver Kunde“ einen Kauf in den letzten 90 Tagen meint und dass die Customer Dimension aus zwei verschiedenen CRM-Systemen aktualisiert wird. Geht diese Person, geht das Wissen mit.

Der Datenkatalog von Dawiso indexiert Datensätze aus Power BI und bildet jede Tabelle und jede Spalte auf Begriffe im Business Glossary ab. Die Definition von „Umsatz“, also brutto oder netto, die Aufnahmekriterien und die maßgebliche Quelle, liegt an einer Stelle und gilt über Power BI, Databricks SQL und Vorstandsunterlagen hinweg.

Die Data Lineage verfolgt jede Dimensions- und Faktentabelle zu ihrem Ursprung zurück: Quelldatenbank, ETL-Pipeline, Staging-Tabelle. Ändert sich ein Quellsystem, etwa bei einem CRM-Umzug, einer Schemaänderung oder einer neuen Datenzufuhr, weist die Lineage von Dawiso aus, welche Datensätze, Measures und Berichte in Power BI betroffen sind, bevor sie brechen.

Über das Model Context Protocol (MCP) können KI-Copiloten Dawiso nach Definitionen von Kennzahlen und nach der Dokumentation des Modells fragen. Wer fragt, wie der Customer Lifetime Value berechnet wird, bekommt die maßgebliche Formel, die Quelltabellen und den Namen des Measures in Power BI, ohne sich durch einen geteilten Ordner veralteter Datenlexika zu graben.

Fazit

Datenmodellierung in Power BI ist eine Disziplin der Architektur und keine Aufgabe der Konfiguration. Das Sternschema ist nicht optional, es ist die Arbeitsweise, für die VertiPaq entworfen wurde. Beziehungen sollten in eine Richtung fließen (Dimension zu Fakt), solange es keinen bestimmten Grund für beidseitiges Filtern gibt. Measures schlagen berechnete Spalten für alles, was auf den Kontext der Nutzer reagiert. Die Optimierung der Leistung beginnt bei Datentypen und ungenutzten Spalten und nicht beim Feilen an DAX. Und die fachliche Logik des Modells, also was „Umsatz“ bedeutet, woher die Daten kommen und wer sie verantwortet, gehört in einen Katalog und nicht in den Kopf einer einzelnen Person.