top of page
Suche

The Five Pillars of DAX

DAX ist in vielen Power-BI-Projekten der Punkt, an dem aus einem hübschen Bericht ein belastbares Steuerungsinstrument wird. Gleichzeitig ist DAX häufig der Bereich, in dem Teams am längsten im Nebel stochern. Measures werden kopiert, angepasst, erweitert – und irgendwann weiß niemand mehr genau, warum eine Kennzahl in einer Matrix stimmt, in einer Karte aber plötzlich anders aussieht.


Das Problem ist selten, dass zu wenige DAX-Funktionen bekannt sind. Meist fehlt das Verständnis für die Mechanik dahinter. DAX wird nicht durch viele Funktionen beherrschbar, sondern durch wenige Grundkonzepte. Genau hier helfen die Five Pillars of DAX: Row Context, Filter Context, Iterators, Context Transition und Expanded Tables.


Wer diese fünf Säulen versteht, schreibt nicht automatisch perfekte Measures. Aber er erkennt schneller, warum ein Ergebnis falsch ist, warum ein Measure langsam läuft und warum eine Formel in einem Visual funktioniert, in einem anderen aber nicht. Für Power-BI-Teams ist das mehr als Entwicklerwissen. Es ist die Grundlage für verlässliches Reporting.



DAX ist keine Excel-Formelsammlung

Viele starten mit DAX, als wäre es eine etwas modernere Excel-Formelsprache. Das ist verständlich, führt aber schnell in die falsche Richtung. In Excel denkt man häufig in Zellen. In Power BI denkt DAX in Tabellen, Beziehungen, Filtern und Kontexten.


Ein Measure wie Umsatz = SUM(Sales[Amount]) sieht simpel aus. Die eigentliche Frage lautet aber nicht nur: Was summiert diese Formel? Sondern: Über welche Zeilen der Tabelle wird gerade summiert? Genau diese Frage beantwortet der aktuelle Filterkontext.


Das macht DAX so stark. Ein Measure kann in einer Gesamtkarte, einer Matrix nach Jahr, einem Diagramm nach Produktgruppe und einem Drilldown nach Kunde jeweils das passende Ergebnis liefern. Die Formel bleibt gleich, aber der Kontext verändert sich. Wer das nicht sauber versteht, landet schnell bei Workarounds, Hilfsspalten und Measures, die nur zufällig richtig wirken.

Eine gute Grundlage dafür ist ein sauberes Modell. DAX kann schlechte Modellierung nicht dauerhaft reparieren. Wenn Beziehungen unklar sind, Dimensionen fehlen oder Faktentabellen direkt gegeneinander verdrahtet werden, wird auch die beste Formel irgendwann unverständlich. Deshalb gehört DAX immer zusammen mit Datenmodellierung in Power BI gedacht.


Pillar 1: Row Context

Der Row Context beschreibt die aktuelle Zeile, in der ein Ausdruck ausgewertet wird. Das klingt einfach, ist aber eine der häufigsten Quellen für Missverständnisse.

Ein klassisches Beispiel ist eine berechnete Spalte:

Zeilenumsatz = Sales[Quantity] * Sales[Unit Price]


Hier ist klar, welche Menge und welcher Preis gemeint sind: die Werte der aktuellen Zeile. Die Berechnung läuft Zeile für Zeile durch die Tabelle. Genau das ist Row Context.


Wichtig ist aber: Row Context bedeutet nicht automatisch Filter Context. Nur weil DAX in einer bestimmten Zeile rechnet, wird dadurch nicht automatisch das gesamte Modell auf diese Zeile gefiltert. Diese Unterscheidung ist zentral. Viele Fehler entstehen, weil Entwickler erwarten, dass eine Zeilenlogik automatisch auch in Beziehungen und Aggregationen hineinwirkt.


Calculated Columns sind deshalb nicht grundsätzlich schlecht. Sie sind nur ein anderes Werkzeug als Measures. Eine berechnete Spalte ist sinnvoll, wenn eine Information dauerhaft zeilenbezogen gebraucht wird – etwa für Gruppierungen, Achsen, Slicer oder einfache Klassifikationen. Sie ist weniger geeignet, wenn eine Kennzahl dynamisch auf Filter, Slicer und Berichtskontext reagieren soll.


Die saubere Frage lautet also nicht: „Sind calculated columns gut oder schlecht?“ Die bessere Frage lautet: Muss dieses Ergebnis dynamisch auf den Berichtskontext reagieren – oder ist es eine stabile Eigenschaft einer Zeile?


Pillar 2: Filter Context


Der Filter Context bestimmt, welche Daten für eine Berechnung sichtbar sind. Er entsteht durch Visuals, Slicer, Seitenfilter, Berichtsfilter, Beziehungen im Modell und DAX-Funktionen.

Nehmen wir ein Measure:

Umsatz = SUM(Sales[Amount])


In einer Karte zeigt es vielleicht den Gesamtumsatz. In einer Matrix mit Jahren zeigt es den Umsatz je Jahr. In einem Balkendiagramm nach Produktkategorie zeigt es den Umsatz je Kategorie. Das Measure bleibt identisch. Der Filter Context verändert sich.


Das ist der Kern von Power BI: Eine zentrale Kennzahlenlogik wird in unterschiedlichen fachlichen Perspektiven ausgewertet. Genau deshalb sind Measures in professionellen Modellen so wichtig. Sie verhindern, dass dieselbe Kennzahl an zehn Stellen leicht unterschiedlich berechnet wird.


Für Fachbereiche ist Filter Context keine technische Nebensache. Er entscheidet darüber, ob eine Kennzahl im Meeting belastbar ist. Wenn der Vertrieb auf Region, das Controlling auf Kostenstelle und die Geschäftsführung auf Gesamtjahr schaut, muss klar sein, ob alle über dieselbe Kennzahl sprechen – nur in unterschiedlichem Kontext.


Gerade bei komplexeren Reports lohnt sich deshalb ein kritischer Blick auf die Kennzahlenlogik. Wer merkt, dass Measures zunehmend schwer erklärbar werden, sollte nicht noch mehr Formeln stapeln, sondern die Logik systematisch prüfen. Genau dafür eignet sich ein fachlicher Review im Rahmen von Power BI Coaching.


Pillar 3: Iterators

Iteratoren sind DAX-Funktionen, die über eine Tabelle laufen und einen Ausdruck zeilenweise auswerten. Typische Beispiele sind SUMX, AVERAGEX, FILTER, CONCATENATEX oder TOPN. Der Unterschied zwischen SUM und SUMX ist für viele Aha-Moment und Stolperfalle zugleich. SUM(Sales[Amount]) summiert eine vorhandene Spalte. SUMX(Sales, Sales[Quantity] * Sales[Unit Price]) läuft über jede Zeile der Tabelle, berechnet erst den Ausdruck und summiert anschließend die Ergebnisse.


Das ist mächtig, weil dadurch dynamische Berechnungen möglich werden, ohne jede Zwischenlogik als physische Spalte im Modell zu speichern. Gleichzeitig kann es Performance kosten, wenn Iteratoren unbedacht über sehr große Tabellen laufen oder unnötig komplexe Ausdrücke auswerten.


Iteratoren sind kein Performance-Problem an sich. Sie werden problematisch, wenn sie als Ersatz für saubere Modellierung oder klare Measures missbraucht werden. Ein gut eingesetzter Iterator macht eine Berechnung präziser. Ein schlecht eingesetzter Iterator macht sie langsamer, schwerer wartbar und anfälliger für Kontextfehler.


In der Praxis sollte jedes Team verstehen, wann ein Iterator wirklich nötig ist. Wenn eine einfache Aggregation reicht, ist sie meist vorzuziehen. Wenn erst pro Zeile eine fachliche Logik berechnet werden muss, ist ein Iterator oft der richtige Weg.


Pillar 4: Context Transition und CALCULATE

CALCULATE ist wahrscheinlich die wichtigste und zugleich am häufigsten missverstandene DAX-Funktion. Sie wertet einen Ausdruck in einem veränderten Filterkontext aus. Das klingt nüchtern, ist aber der Schlüssel zu vielen professionellen Measures.


Ein Beispiel:

Umsatz Vorjahr = CALCULATE([Umsatz], SAMEPERIODLASTYEAR('Date'[Date]))

Hier wird nicht einfach eine neue Zahl berechnet. DAX nimmt das vorhandene Umsatz-Measure und verändert den Filterkontext auf den Vergleichszeitraum. Genau darin liegt die Stärke von CALCULATE: Es trennt die Kennzahl von der Perspektive, in der sie ausgewertet wird.


Noch wichtiger wird CALCULATE bei der Context Transition. Dabei wird ein Row Context in einen Filter Context überführt. Das ist besonders relevant, wenn Measures innerhalb von zeilenweisen Berechnungen ausgewertet werden.


Für den Alltag reicht zunächst eine klare Regel: CALCULATE ist keine magische Korrekturfunktion. CALCULATE verändert den Kontext. Wer CALCULATE nur einsetzt, bis das Ergebnis zufällig passt, baut technische Schulden in sein Modell ein. Wer versteht, welcher Filter entfernt, ergänzt oder überschrieben wird, kann DAX gezielt steuern.


Genau an dieser Stelle trennen sich einfache Power-BI-Berichte von belastbaren BI-Lösungen. Wenn Kennzahlen über Zeitintelligenz, Segmentierung, Plan-Ist-Vergleiche oder Ausnahmelogiken laufen, muss CALCULATE sauber verstanden werden. Sonst entstehen Measures, die in Demo-Situationen funktionieren, aber im echten Reporting-Alltag brechen.


Pillar 5: Expanded Tables

Expanded Tables sind die Säule, die viele DAX-Erklärungen auslassen – und genau deshalb ist sie so wichtig. Vereinfacht gesagt betrachtet DAX eine Tabelle nicht immer nur isoliert. Durch Beziehungen können zusätzliche Spalten aus verbundenen Tabellen in die logische Auswertung einbezogen werden.


Das ist einer der Gründe, warum Filterverhalten manchmal überraschend wirkt. Wer in CALCULATE ganze Tabellen als Filter verwendet, filtert nicht immer nur die sichtbare Tabelle im naiven Sinne. Beziehungen und erweiterte Tabellenstrukturen können dazu führen, dass viel mehr Kontext beteiligt ist, als man erwartet.


Eine sehr praktische Regel lautet deshalb: Filtere Spalten, nicht ganze Tabellen. Statt eine komplette Faktentabelle in einen Filterausdruck zu ziehen, sollte möglichst präzise auf die fachlich relevante Spalte gefiltert werden. Das ist meist verständlicher, stabiler und performanter.


Gerade in großen Modellen ist dieser Punkt entscheidend. DAX-Performance entsteht nicht nur durch schnellere Hardware oder weniger Visuals. Sie entsteht durch saubere Filterlogik, klare Beziehungen und Measures, die dem Modell nicht unnötig viel Arbeit aufdrücken. Wer tiefer in typische Engpässe einsteigen möchte, findet ergänzende Ansätze unter Power BI Performance.


Warum die fünf Säulen zusammengehören

Die Five Pillars funktionieren nicht isoliert. In echten Measures greifen sie fast immer ineinander. Ein Iterator erzeugt Row Context. CALCULATE kann daraus Filter Context machen. Der bestehende Filter Context wird durch Visuals, Slicer und Beziehungen geprägt. Expanded Tables beeinflussen, wie Filter tatsächlich wirken. Genau deshalb lassen sich viele DAX-Probleme nicht lösen, indem man nur eine Funktion austauscht.


Ein typisches Muster aus der Praxis: Ein Measure liefert im Gesamtergebnis den richtigen Wert, aber auf Zeilenebene falsche Ergebnisse. Oder umgekehrt. Häufig steckt dahinter kein Rechenfehler, sondern ein Kontextproblem. Vielleicht wird ein Filter überschrieben. Vielleicht fehlt ein Iterator. Vielleicht wird eine Tabelle statt einer Spalte gefiltert. Vielleicht ist die Beziehung im Modell nicht eindeutig genug.


Gute DAX-Entwicklung ist deshalb weniger Formelschreiben und mehr Kontextdiagnose. Die entscheidende Fähigkeit besteht darin, zu erkennen, welcher Kontext gerade aktiv ist und wie eine Funktion diesen Kontext verändert.


DAX, Visual Calculations und KI: Was sich verändert – und was nicht

Power BI entwickelt sich weiter. Visual Calculations machen bestimmte Berechnungen direkt im Visual einfacher. KI-gestützte Werkzeuge können DAX-Vorschläge erzeugen, Formeln erklären oder erste Measures generieren. Auch semantische Modelle werden stärker in umfassende Plattformen wie Microsoft Fabric eingebettet.


Das ist hilfreich, aber es verschiebt nicht die Verantwortung. Eine KI kann ein Measure vorschlagen. Sie weiß aber nicht automatisch, ob die Kennzahl fachlich korrekt, governancefähig und im Unternehmen akzeptiert ist. Visual Calculations können schnelle Lösungen ermöglichen, ersetzen aber keine wiederverwendbare Kennzahlenlogik im Modell.


Für Teams bedeutet das: Neue Werkzeuge sind willkommen, aber sie machen Grundlagenwissen nicht überflüssig. Im Gegenteil. Je mehr automatisch generiert wird, desto wichtiger wird die Fähigkeit, Ergebnisse kritisch zu prüfen. DAX bleibt eine Sprache der fachlichen Verantwortung.


Wer regelmäßig Dashboards baut, sollte DAX daher nicht getrennt vom Berichtserlebnis betrachten. Ein gutes Measure ist nur dann wirklich gut, wenn es im Visual verständlich, performant und fachlich belastbar bleibt. Der Zusammenhang zwischen Kennzahlenlogik und Darstellung wird besonders deutlich bei Power BI Dashboard Best Practices.


Was Power-BI-Teams konkret tun sollten

Teams müssen DAX nicht akademisch lernen. Sie brauchen eine gemeinsame Arbeitsweise, die Fehler reduziert und Wissen im Team verankert. Dazu gehören klare Namenskonventionen für Measures, eine zentrale Measure-Tabelle, dokumentierte Kernkennzahlen und regelmäßige Reviews kritischer DAX-Logik. Besonders wichtige Measures sollten nicht nur technisch getestet, sondern fachlich erklärt werden können: Welche Filter wirken? Welche Annahmen stecken in der Berechnung? Wann liefert das Measure bewusst keinen Wert?


Auch Performance sollte früh geprüft werden. Wenn ein Bericht erst kurz vor dem Go-live langsam wird, sind Ursachen oft schwerer zu isolieren. Besser ist es, bereits während der Entwicklung auf Modellstruktur, Cardinality, Beziehungen, Iteratoren und unnötig komplexe Measures zu achten.


Für Einsteiger kann eine kuratierte Funktionsauswahl helfen. Aber Funktionslisten allein reichen nicht. Eine Übersicht wie Top 10 DAX-Funktionen wird erst dann wirklich wertvoll, wenn klar ist, in welchem Kontext diese Funktionen arbeiten.

Fazit: DAX-Kompetenz beginnt beim Kontext

The Five Pillars of DAX bringen Ordnung in ein Thema, das in vielen Power-BI-Teams unnötig kompliziert wirkt. Row Context, Filter Context, Iterators, Context Transition und Expanded Tables erklären nicht jede einzelne DAX-Funktion im Detail. Aber sie erklären, warum DAX so arbeitet, wie es arbeitet.


Der wichtigste Schritt ist der Wechsel von „Welche Funktion brauche ich?“ zu „Welcher Kontext wirkt gerade?“ Genau dadurch werden Measures nachvollziehbarer, Modelle robuster und Diskussionen über Kennzahlen deutlich sachlicher.


Für Unternehmen ist das kein reines Entwicklerproblem. Wenn zentrale Reports auf DAX-Logik basieren, muss diese Logik belastbar sein. Andernfalls entstehen Diskussionen über Zahlen, die eigentlich Diskussionen über Modellierung, Filter und Kennzahlendefinitionen sind.

Der nächste sinnvolle Schritt

Power BI entfaltet seinen Nutzen erst dann vollständig, wenn Dashboards sauber aufgebaut, Datenmodelle durchdacht und Kennzahlen klar definiert sind.Genau diese Grundlagen entscheiden darüber, ob Berichte genutzt oder ignoriert werden.


Wenn du Power BI strukturiert aufsetzen oder bestehende Lösungen verbessern willst, unterstützen wir dich mit:


So wird aus einem funktionierenden Bericht eine belastbare Analytics-Lösung.

bottom of page