Power BI Update Jänner 2026

Power BI Performance Deep Dive #1: Das Datenmodell

Bei der Arbeit mit Power BI gelangt man unweigerlich früher oder später an den Punkt, bei dem Performance eine Rolle spielt. Entweder man überschreitet Limits der Modellgröße, Reports reagieren nicht schnell genug oder einzelne Auswertungen laden zu lange. Um euch das Leben zu erleichtern, liefern wir einen Deep Dive über Performance Tuning in Power BI, bei dem wir unsere jahrelange Erfahrung mit euch teilen.

Welche Struktur sollte mein Datenmodell haben?

Als erstes widmen wir uns den Fallstricken bei der Erstellung des Datenmodells. Der wichtigste Punkt ist die grundlegende Struktur des Datenmodells. Dabei sollte, wenn möglich, ein Starschema verwendet werden. Von einem Starschema spricht man falls zentrale Faktentabellen mittels 1:* Beziehungen an Dimensionstabellen angebunden werden. Fakten können Aufträge, Buchungen, Zahlungen oder andere Ereignisse sein über die Fragen wie z.B. „Wann hat dieses Ereignis stattgefunden?“, „Wer war daran beteiligt?“ oder „Wo ist das Ereignis passiert?“. Von Dimensionen spricht man, falls diese in der Lage sind, die oben gestellten Fragen zu beantworten.

Wir empfehlen ein Starschema, weil es genau der Art entspricht, wie die interne Vertipaq-Engine von Power BI Abfragen verarbeitet. (Näheres dazu in unserem nächsten Blogeintrag, der im Februar 2026 erscheint)
Anstatt zwischen Dutzenden von Tabellen hin- und herzuspringen, um einfache Fragen wie „Wie hoch waren die Umsätze nach Region im letzten Monat?“ zu beantworten, kann Power BI die Antwort schnell ermitteln, indem es nur wenige, klar strukturierte Tabellen auswertet.

Im Umkehrschluss bedeutet eine Verwendung eines Starschemas auch das Vermeiden von Beziehungen zwischen zwei Faktentabellen. Weniger kritisch ist die Erweiterung eines Starschemas zu einem Snowflakeschema durch die Verbindung einer Dimensionstabelle zu einer weiteren Dimensionstabelle. Ein Beispiel einer Produkthierarchie durch Verwendung eines Snowflakeschemas sehen wir hier:

Alternativ könnte man die Producttable erweitern und die Informationen dort direkt speichern. Das hätte den Vorteil einer erhöhten Performance und den Nachteil eines höheren Speicherplatzbedarfs.

Wie kann ich meinen Speicherplatzbedarf möglichst gering halten und dabei Abfragen schneller verarbeiten?

Grundlegend dafür ist es, die Kardinalität von Spalten möglichst gering zu halten. Kardinalität beschreibt die Anzahl unterschiedlicher Werte in einer Spalte.

Die VertiPaq Engine komprimiert spaltenbasiert. Je weniger unterschiedliche Werte, umso besser die Kompression – und umso schneller jede Abfrage. In der Praxis heißt das, dass z.B. Datetime Spalten vermieden werden sollten und stattdessen aufgespalten in eine Date- und eine Time-Spalte. Dadurch gibt es weniger unterschiedliche Werte und die Kardinalität wird reduziert.

Außerdem sollten Freitextfelder entfernt werden, falls sie nicht unbedingt benötigt werden. Diese sind selten gleich und damit von hoher Kardinalität.

Besonderes Augenmerk sollte bei Faktentabellen auf diese Tipps gelegt werden. Durch die im Normalfall wesentlich höhere Anzahl an Zeilen ist der Einfluss auf die Performance und den Speicherplatzbedarf ungleich höher als bei Dimensionstabellen.

Außerdem raten wir dazu, nur Spalten ins Modell zu laden, die tatsächlich in Reports verwendet werden. Es mag verlockend klingen, alle Spalten einer Tabelle zu laden um in Zukunft eventuell weniger anpassen zu müssen – das kann aber verheerende Folgen für die Performance des Modells haben und sollte daher vermieden werden.

Tipps & Tricks bei der Definition von Datentypen

Um eine effiziente Verarbeitung zu gewährleisten, sollten Zahlen als Ganzzahl oder Dezimalzahl definiert werden und nicht als Text. Eine Ausnahme bilden hier Produktnummern oder Konten bei denen durchaus führende Nullen vorkommen können – diese würden bei einer Typumwandlung verloren gehen. Um die Kardinalität zu verringern, kann man außerdem darüber nachdenken, bei Dezimalzahlen eine geringere Anzahl an Dezimalstellen zu verwenden.

Was muss ich bei der Erstellung von Beziehungen im Datenmodell beachten?

Wie oben beschrieben, empfehlen wir, im Datenmodell hauptsächlich 1:*-Beziehungen zu verwenden. m:n - Beziehungen (oder many:many) führen in vielen Fällen zu Problemen. Im schlimmsten Fall werden Daten fehlerhaft aggregiert und damit falsche Ergebnisse produziert. Als Alternative bieten sich hier Brückentabellen an. Dabei wird eine Tabelle erstellt, die eindeutige Schlüssel beider Tabellen enthält und durch zwei 1:* - Beziehungen mit den zwei Tabellen verbunden werden kann.

Weiters sollte auf bidirektionale Filterrichtungen verzichtet werden. Bei Erweiterungen des Modells können sonst Zirkelschlüsse entstehen, die eine Erweiterung verhindern. Um bei einer Visualisierung ähnliche Ergebnisse zu erzielen, kann man stattdessen einen Visual Level Filter verwenden bei dem nur Werte angezeigt werden, bei denen ein Measure einen nichtleeren Wert liefert.