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. Microsoft hat Datasets in Power BI im November 2023 in Semantikmodelle umbenannt, und dieser Artikel verwendet den aktuellen Namen.

Das Modell richtig zu bekommen zählt mehr als jede gestalterische Entscheidung im Visuellen. Ein schlecht geschnittenes Modell macht Berichte langsam und Berechnungen fehleranfällig, und DAX-Optimierung kann das nur teilweise ausgleichen. 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 passen besser zu Power BI als flache Tabellen, und der Leitfaden von Microsoft zum Sternschema empfiehlt sie für Semantikmodelle. Drei Gründe stechen heraus. Erstens verdichtet die VertiPaq-Engine von Power BI Spalten mit wenigen verschiedenen Werten sehr gut: Eine Spalte „Category“ mit 20 verschiedenen Werten belegt kaum Platz. 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 kleinen Datenmengen funktioniert das. Mit wachsender Zeilenzahl steht jeder beschreibende Wert in jeder Zeile, sodass das Modell mehr Speicher braucht, DAX breitere Tabellen durchsuchen muss und schwerer nachzuvollziehen ist, was was filtert. Microsoft rät, jede Modelltabelle entweder als Dimension oder als Fakt anzulegen und beides nicht zu mischen.

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. Standardmäßig steht die Kreuzfilterrichtung der Beziehung auf „Einfach“: Der Filter fließt von der Eins-Seite (Dimension) zur Viele-Seite (Fakt), und das hält die Filterpfade 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 Beziehungen verlangen mehr Verarbeitung, was Abfragen verlangsamen kann, und sie können ein Modell mehrdeutig machen, wenn mehr als ein Filterpfad zwei Tabellen verbindet. Braucht nur ein einzelnes Measure die umgekehrte Richtung, empfiehlt Microsoft, sie in diesem Measure mit der DAX-Funktion CROSSFILTER einzuschalten statt an der Beziehung.

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 viele 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 darüber.

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. Und lässt sich ein fester Wert je Zeile berechnen, bevor die Daten das Modell erreichen, bevorzugt der Leitfaden von Microsoft zur Datenreduktion eine benutzerdefinierte Spalte in Power Query (oder in der Quelle) gegenüber einer berechneten DAX-Spalte, weil berechnete Spalten sich meist schlechter komprimieren lassen und erst entstehen, wenn alle Tabellen geladen sind.

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 Funktion Auto date/time von Power BI zu verlassen: Deren ausgeblendete Tabellen kennen nur Kalenderjahre, lassen keine weiteren Spalten wie Wochen zu, können nicht mehrere Faktentabellen zugleich filtern und vergrößern das Modell für jede Datumsspalte. Markieren Sie die Tabelle mit Mark as Date Table, damit Funktionen der Zeitintelligenz wie TOTALYTD und SAMEPERIODLASTYEAR richtig arbeiten.

Leistung optimieren

Die meisten Leistungsprobleme in Modellen von Power BI gehen auf wenige Ursachen zurück. Fünf davon lohnt es, zuerst zu prüfen:

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 speichert numerische Spalten mit Wertcodierung und Text mit Hashcodierung, die eine Wörterbuchsuche erfordert; der Leitfaden von Microsoft zur Datenreduktion hält fest, dass die Umwandlung von Text hoher Kardinalität in ganze Zahlen bei großen Tabellen die Datenmenge deutlich senken kann.

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 Spalten einer breiten Quelltabelle zu laden, während der Bericht ein Dutzend 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 sehr großen Faktentabellen im DirectQuery-Modus legen Sie vorverdichtete Übersichtstabellen im Quellsystem an (oder in Databricks). Die benutzerdefinierten Aggregationen von Power BI beantworten Abfragen aus der Übersichtstabelle (meist im Import-Modus gespeichert), sofern deren Granularität die Abfrage abdeckt, und schicken den Rest an die Detailtabelle im DirectQuery-Modus. Übersichtsabfragen kommen dann aus dem Speicher statt aus der Quelle.

Größengrenzen: Die Standardgrenze für ein Semantikmodell liegt bei 1 GB, und freigegebene Kapazität (Pro-Arbeitsbereiche) unterstützt Modelle bis zu dieser Größe. Darüber hinaus braucht ein Modell einen Arbeitsbereich mit Premium Per User oder eine Premium- oder Fabric-Kapazität mit aktiviertem Speicherformat für große Semantikmodelle; dann richtet sich die Grenze nach der Größe der Kapazität. VertiPaq komprimiert gut (Microsoft nennt etwa eine 10-fache Komprimierung der Quelldaten), doch große Faktentabellen profitieren trotzdem von der inkrementellen Aktualisierung, die auch mit Pro verfügbar ist und nur die jüngsten Partitionen aktualisiert.

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())

Auf einer Dimensionstabelle Region (oder Geography) definiert, lässt dieser Ausdruck nur die zugewiesene Region des aktuellen Nutzers stehen, und der Filter fließt dann über die Eins-zu-viele-Beziehung weiter zur Tabelle Sales Fact. In die andere Richtung fließen Filter standardmäßig nicht: Eine Regel auf der Faktentabelle filtert Product oder Customer nur dann, wenn für die Beziehung die Option „Sicherheitsfilter in beide Richtungen anwenden“ aktiviert ist.

Prüfen Sie RLS in Power BI Desktop über View as Role, bevor Sie veröffentlichen, und danach im Service über Test as role. Nach dem Veröffentlichen weisen Sie auf der Seite Sicherheit des Semantikmodells jeder Rolle Nutzer oder Sicherheitsgruppen aus Microsoft Entra ID zu. Eine häufige Überraschung: Ein Viewer ohne zugewiesene Rolle sieht in der Regel gar keine Daten.

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. Die Dokumentation von Microsoft zu zusammengesetzten Modellen beschreibt die Abwägungen bei Sicherheit und Leistung.

Berechnungsgruppen ersparen Ihnen wiederkehrende 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. Bei 20 Basis-Measures sind das 20 Measures plus eine Berechnungsgruppe statt 80 Measures. Power BI Desktop legt Berechnungsgruppen in der Modellansicht an, und das Hinzufügen einer Gruppe schaltet die Eigenschaft Discourage implicit measures ein, weil Berechnungselemente nur auf explizite Measures wirken.

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. Der Leitfaden von Microsoft empfiehlt genau diese Brückentabelle, wenn zwei Dimensionen verknüpft werden, mit einem beidseitigen Filter über die Brücke, damit Filter weiterfließen.

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. Der Leitfaden von Microsoft zum Sternschema beschreibt die Alternative als gängige Technik: eine eigene Kopie der Dimension je Rolle (eine Tabelle OrderDate, eine ShipDate), jede mit einer aktiven Beziehung, was zudem das gleichzeitige Filtern nach beiden Datumsangaben erlaubt. Das zählt, wenn das Modell Sicherheit auf Zeilenebene nutzt, denn Microsoft warnt, dass USERELATIONSHIP() bei aktivierter RLS unerwartete Fehler verursachen kann.

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 übernimmt Metadaten aus Power BI über den Connector für Power BI: Semantikmodelle (im Connector als Datasets geführt) mit ihren Spalten und Measures, einschließlich des Ausdrucks jedes Measures, dazu Berichte, Dashboards, Dataflows und Datenquellen. Das Business Glossary enthält die Begriffe, Kennzahlen und Regeln dahinter, mit zugewiesenem Data Owner und Data Steward, und Glossareinträge lassen sich mit Katalogobjekten verknüpfen. Die Definition von „Umsatz“, also brutto oder netto, die Aufnahmekriterien und die maßgebliche Quelle, liegt an einer Stelle statt im Kopf der Person, die das Modell gebaut hat.

Die Data Lineage aus dem Connector für Power BI arbeitet auf Objektebene: Ein Bericht nutzt ein Semantikmodell, das Semantikmodell liest aus einer Datenquelle, und die Datenquelle ist über ein Gateway angebunden. Ändert sich ein Quellsystem, etwa bei einem CRM-Umzug, einer Schemaänderung oder einer neuen Datenzufuhr, zeigt diese Kette, welche Semantikmodelle und Berichte der betroffenen Datenquelle nachgelagert sind. Einzelne Spalten, Measures oder DAX-Ausdrücke verfolgt sie nicht, sodass die Prüfung, welches Measure durch eine geänderte Spalte nicht mehr funktioniert, eine Aufgabe der Modellierung bleibt.

Über das Model Context Protocol (MCP) können KI-Copiloten den Dawiso MCP-Server nutzen, um den Katalog zu durchsuchen, die Details eines Objekts zu lesen und seiner Lineage zu folgen. Ein Analyst, der fragt, wie der Customer Lifetime Value berechnet wird, kann die Definition aus dem Glossar und das dokumentierte Measure in Power BI bekommen, mit seinem Ausdruck und dem Semantikmodell, in dem es liegt, 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 der Standard, den Microsoft selbst in seinen Leitfäden für Semantikmodelle empfiehlt. 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.

Quellen

• Microsoft Learn, New name for Power BI datasets, November 2023.
• Microsoft Learn, Understand star schema and the importance for Power BI.
• Microsoft Learn, Bi-directional relationship guidance.
• SQLBI (Alberto Ferrari), Bidirectional relationships and ambiguity in DAX, November 2023.
• Microsoft Learn, Data reduction techniques for Import modeling.
• Microsoft Learn, Auto date/time guidance in Power BI Desktop.
• Microsoft Learn, User-defined aggregations.
• Microsoft Learn, Large semantic models in Power BI Premium.
• Microsoft Learn, Configure incremental refresh and real-time data for Power BI semantic models.
• Microsoft Learn, Row-level security (RLS) with Power BI.
• Microsoft Learn, Use composite models in Power BI Desktop.
• Microsoft Learn, Create calculation groups in Power BI.
• Dawiso Help, Power BI connector.
• Dawiso Help, Business Glossary.
• Dawiso Help, Role of ownership in data governance.
• Dawiso Help, Dawiso Model Context Protocol (MCP).