Top 10 DAX-Funktionen

Dirk Müller
8. Jan.
7 Min. Lesezeit

DAX ist der Moment, in dem Power BI von schönes Dashboard zu belastbare Steuerung wird. Und DAX ist gleichzeitig der Moment, in dem viele Berichte anfangen, sich „komisch“ anzufühlen: Prozentwerte passen nicht, Totals sind überraschend, ein Slicer wirkt plötzlich nicht mehr – oder alles wird langsam, sobald man eine Kleinigkeit ergänzt. Das liegt selten an deiner Tipperei. Es liegt fast immer am Kontext.

Microsoft beschreibt DAX als Bibliothek aus Funktionen und Operatoren, mit denen du Formeln und Ausdrücke in Power BI (und verwandten Tabular-Modellen) erstellen kannst. Die offizielle DAX-Funktionsreferenz umfasst dabei über 250 Funktionen. Du musst die nicht alle kennen. Aber du solltest ein kleines Set so gut beherrschen, dass du in den meisten Praxisfällen nicht mehr rätst, sondern steuerst.

DAX rechnet immer im Kontext

In DAX ist „was wird berechnet?“ nur die halbe Frage. Die andere Hälfte ist: „Worauf genau wird gerade gerechnet?“ – also welche Filter gerade gelten (aus Visual, Slicern, Seitenfiltern, Beziehungen und aus DAX selbst). Microsoft unterscheidet dabei zentral Row Context und Filter Context.

Wenn du das einmal ernst nimmst, werden viele typische Probleme plötzlich logisch:

Ein Prozentwert ist „falsch“, weil dein Nenner nicht den Kontext entfernt, den du im Kopf entfernt hast.
Ein KPI ist „inkonsistent“, weil ein Filter in CALCULATE stillschweigend vorhandene Filter überschreibt.
Ein Vergleich „nach Versanddatum“ geht nicht, weil die Beziehung in deinem Modell nicht aktiv ist – und DAX ohne Hinweis die aktive nimmt.

Die Top-10-Funktionen unten sind im Kern Werkzeuge, um Kontext zu setzen, zu halten oder bewusst zu ignorieren.

1) CALCULATE – der Kontext-Motor

Wenn du nur eine Funktion wirklich verstehen möchtest, dann diese. CALCULATE wertet einen Ausdruck in einem geänderten Filterkontext aus. Und genau das ist das, was du ständig brauchst: „Umsatz nur für Produktgruppe X“, „Umsatz ohne Kanal Y“, „Umsatz nach anderem Datum“, „Umsatz im Vorjahr“ – das sind alles Kontext-Themen.

Wichtig ist dabei: Ein Filterargument in CALCULATE fügt einen Filter hinzu oder überschreibt bestehende Filter auf derselben Spalte. Das ist einer der häufigsten Gründe für „Warum ignoriert mein Measure meinen Slicer?“.

Beispiel (simpel, aber real):

[Umsatz Rot] =
CALCULATE(
    [Umsatz],
    'Produkt'[Farbe] = "Rot"
)

Wenn im Report schon „Farbe = Blau“ gefiltert ist, dann gewinnt hier „Rot“, weil du dieselbe Spalte neu filterst. Genau dieses Verhalten ist manchmal gewollt – und manchmal der Bug. Der Trick ist nicht, CALCULATE zu meiden, sondern es bewusst zu kombinieren. Und dafür brauchst du direkt Funktion Nummer 2.

2) KEEPFILTERS – addiere Filter statt sie zu ersetzen

KEEPFILTERS ist dein Sicherheitsgurt, wenn du zusätzlich einschränken willst, ohne den Nutzerkontext kaputt zu machen. Laut Microsoft nutzt du KEEPFILTERS im Kontext von CALCULATE/CALCULATETABLE, um deren Standardverhalten zu überschreiben.

Die Idee: Normalerweise ersetzt CALCULATE Filter auf betroffenen Spalten. Mit KEEPFILTERS sagst du: „Nein – behalte vorhandene Filter und wende meinen Filter zusätzlich an.“

Das ist Gold für Measures, die du wie Bausteine wiederverwendest. Du baust ein stabiles Basemeasure (z. B. [Umsatz]) und daraus Varianten, die sich wie erwartet verhalten, auch wenn Nutzer im Report filtern.

[Umsatz Rot (respektiert Filter)] =
CALCULATE(
    [Umsatz],
    KEEPFILTERS('Produkt'[Farbe] = "Rot")
)

Microsoft nennt genau dieses Pattern als Verbesserung, weil es existierende Filter nicht überschreibt. Wenn du öfter denkst „Ich will nur weiter einschränken, nicht umstellen“ – dann gehört KEEPFILTERS in dein Standardrepertoire.

3) REMOVEFILTERS (und ALL)

Der schnellste Weg zu „falschen Prozentwerten“ ist ein Nenner, der nicht wirklich „Gesamt“ ist. Dafür brauchst du eine klare Art, Filter gezielt zu entfernen.

REMOVEFILTERS kann nur zum Entfernen von Filtern verwendet werden – nicht, um eine Tabelle zurückzugeben. Das klingt wie ein Detail, ist aber super praktisch: Es macht deine Absicht glasklar („ich entferne Filter“), und du nutzt es typischerweise als Modifier in CALCULATE.

[Umsatz Alle Channels] =
CALCULATE(
    [Umsatz],
    REMOVEFILTERS('Sales'[Channel])
)

Das ist genau der Nenner-Baustein, den du für Quoten brauchst: „Anteil dieses Channels am Gesamtumsatz“ oder „Umsatz je Produkt relativ zum Gesamtumsatz“.

ALL macht etwas Ähnliches, aber aus einer anderen Richtung: Es gibt alle Zeilen einer Tabelle (oder alle Werte einer Spalte) zurück und ignoriert Filter, die angewendet wurden. In CALCULATE kann ALL damit ebenfalls Filter löschen.

Microsoft schreibt sogar explizit, dass – wenn REMOVEFILTERS in deinem Tool unterstützt wird – es besser sein kann, REMOVEFILTERS zum Filterentfernen zu nutzen. Praktisches Muster für einen Anteil:

[% vom Gesamtumsatz] =
DIVIDE(
    [Umsatz],
    CALCULATE([Umsatz], REMOVEFILTERS('Produkt'))
)

Wichtige Einschränkung (DirectQuery/RLS): REMOVEFILTERS ist in DirectQuery nicht unterstützt, wenn es in berechneten Spalten oder RLS-Regeln verwendet wird. Das ist nichts, was du im Tagesgeschäft ständig triffst – aber wenn es knallt, willst du wissen, dass es dokumentierte Grenzen gibt.

4) FILTER – wenn du wirklich kompliziert filtern musst

FILTER ist eine dieser Funktionen, die viele zu früh zu oft nutzen – und sich damit Performance- und Kontextprobleme einhandeln. Microsoft beschreibt FILTER als Funktion, die du nutzt, um die Zeilen einer Tabelle zu reduzieren; sie wird typischerweise nicht allein, sondern eingebettet in andere Funktionen verwendet, die eine Tabelle als Argument brauchen.

Der Nutzen ist klar: Du kannst Bedingungen formulieren, die du als einfachen booleschen Filter nicht sauber hinbekommst – zum Beispiel, wenn du über berechnete Logik filtern musst oder komplexe Bedingungen brauchst.

[Umsatz High Margin] =
CALCULATE(
    [Umsatz],
    FILTER('Produkt', 'Produkt'[Marge%] > 0.30)
)

Aber jetzt der wichtige Teil: Microsoft hat eine eigene Best-Practice-Empfehlung „Avoid using FILTER as a filter argument“. Der Kern: Wo möglich, nimm boolesche Filterausdrücke (und kombiniere sie mit KEEPFILTERS), statt FILTER als Tabelle zu übergeben. Das ist meist lesbarer und oft effizienter. Du brauchst FILTER. Aber du willst nicht, dass FILTER dein Standardhammer wird.

5) SUMX – der Zeile-für-Zeile-Rechner

SUMX nimmt als erstes Argument eine Tabelle (oder einen Tabellenausdruck) und summiert dann einen Ausdruck, der je Zeile ausgewertet wird. Microsoft nennt SUMX ausdrücklich eine Iteratorfunktion.

Das klingt abstrakt, ist aber genau das, was du brauchst, wenn „Umsatz“ nicht als fertige Spalte vorliegt, sondern sich aus Menge × Preis ergibt – oder wenn du gewichtete Logik rechnest.

[Umsatz (Zeilenlogik)] =
SUMX(
    'Sales',
    'Sales'[Menge] * 'Sales'[Stückpreis]
)

Die typische Falle: SUMX fühlt sich so „richtig“ an, dass man es überall einsetzt. Aber Iteration über viele Zeilen ist teurer als eine simple Aggregation. In echten Modellen ist SUMX dann ideal, wenn du es bewusst verwendest – und gefährlich, wenn du damit „Modellprobleme übertünchst“.

6) DIVIDE – Prozentwerte ohne Drama

Wenn du Quoten baust, willst du nicht erklären müssen, warum da plötzlich „Infinity“, Fehler oder BLANK auftaucht. DIVIDE löst das sauber: Du gibst Zähler und Nenner an und optional ein Alternativergebnis, falls der Nenner 0 ist.

[Marge %] =
DIVIDE([Gewinn], [Umsatz], 0)

Microsoft hat dafür sogar eine Best-Practice-Seite, die DIVIDE explizit dem „/“-Operator gegenüberstellt.

Im Alltag bedeutet das: Deine Measures sind robuster, und du bekommst weniger „Wieso ist das leer/kaputt?“-Rückfragen. Gerade bei KPIs, die in vielen Visuals wiederverwendet werden, ist das kein Detail, sondern Hygiene.

7) SELECTEDVALUE – die „Was ist ausgewählt?“-Funktion

Viele Reports leben davon, dass sich etwas abhängig von einer Auswahl verhält: ein dynamischer Titel, eine Kennzahl, ein Hinweistext („Bitte genau ein Land wählen“), ein KPI-Switch.

SELECTEDVALUE gibt einen Wert zurück, wenn genau ein eindeutiger Wert im Kontext vorhanden ist, ansonsten ein Alternativergebnis. Die Doku zeigt auch das äquivalente Pattern über HASONEVALUE/VALUES – und verlinkt direkt auf Best Practices.

[Ausgewähltes Land] =
SELECTEDVALUE(Kunde[Land], "Mehrfach/Keins")

Microsoft empfiehlt ausdrücklich: Nutze SELECTEDVALUE statt VALUES-Pattern, weil es eleganter und effizienter ist.

Und auch hier gilt: Es gibt dokumentierte DirectQuery-Einschränkungen, wenn SELECTEDVALUE in berechneten Spalten oder RLS-Regeln verwendet wird.

8) SWITCH – verständliche Logik statt IF-Verschachtelung

Du kannst mit IF vieles bauen. Du willst es nur irgendwann nicht mehr lesen.

SWITCH wertet einen Ausdruck gegen eine Liste von Werten aus und liefert passende Ergebnisse zurück; Microsoft nennt es explizit geeignet, um mehrere verschachtelte IFs zu vermeiden.

Das ist ideal, wenn du Nutzern eine Auswahl gibst („Umsatz“, „Gewinn“, „Marge%“) und dein Visual abhängig davon ein anderes Measure zeigen soll.

[KPI] =
SWITCH(
    SELECTEDVALUE('KPI Selector'[KPI]),
    "Umsatz", [Umsatz],
    "Gewinn", [Gewinn],
    "Marge%", [Marge %],
    BLANK()
)

Das fühlt sich sofort „professioneller“ an, weil du eine klare, zentrale Logik hast – und weil du später einfacher Cases ergänzen kannst, ohne ein IF-Kartenhaus umzuschubsen.

9) USERELATIONSHIP – alternative Beziehungen gezielt nutzen

Der Klassiker: Du hast eine Faktentabelle mit mehreren Datumsfeldern (Bestelldatum, Versanddatum, Rechnungsdatum). Im Modell kann nur eine Beziehung aktiv sein, aber du willst je nach KPI ein anderes Datum verwenden.

USERELATIONSHIP sagt in einer Berechnung: „Nutze für diesen Ausdruck die Beziehung zwischen diesen beiden Spalten.“

[Umsatz nach Versanddatum] =
CALCULATE(
    [Umsatz],
    USERELATIONSHIP('Sales'[ShipDate], 'Date'[Date])
)

Wichtig ist hier die dokumentierte Einschränkung: USERELATIONSHIP kann nicht verwendet werden, wenn Row-Level Security für die Tabelle definiert ist, in der das Measure enthalten ist (Microsoft beschreibt das als Fehlerfall).

In der Praxis heißt das: USERELATIONSHIP ist ein super Pattern – bis RLS ins Spiel kommt. Dann brauchst du entweder ein anderes Modell-Design oder alternative Ansätze. Aber du willst diese Grenze kennen, bevor du im Rollout damit kollidierst.

10) TREATAS – virtuelle Beziehungen ohne Modellumbau

TREATAS ist das Werkzeug für den Moment, in dem du denkst: „Ich bräuchte jetzt eine Beziehung, aber ich will das Modell nicht anfassen.“ Oder: „Ich habe einen Disconnected Slicer/Selector und möchte damit Fakten filtern.“

Microsoft beschreibt TREATAS sehr klar: Es wendet das Ergebnis eines Tabellenausdrucks als Filter auf Spalten einer nicht verknüpften Tabelle an.

[Umsatz (virtuelle Region)] =
CALCULATE(
    [Umsatz],
    TREATAS(
        VALUES('Region Selector'[Region]),
        Kunde[Region]
    )
)

Das ist extrem mächtig, weil du Filter „übertragen“ kannst – auch ohne physische Beziehung. Gleichzeitig ist es eines der Patterns, das du sauber dokumentieren solltest, weil es sonst später schwer zu erklären ist, woher der Filter eigentlich kommt. TREATAS ist Skalpell, nicht Hammer.

Fazit: Wenn du diese 10 beherrschst, wird DAX vorhersehbar

Du musst DAX nicht auswendig können. Du musst es steuerbar machen.

Mit CALCULATE verstehst du, wie Kontext verändert wird.
Mit KEEPFILTERS, REMOVEFILTERS/ALL kontrollierst du, ob Filter ergänzt oder entfernt werden.
Mit FILTER und SUMX löst du die Fälle, wo einfache Aggregation nicht reicht – aber bewusst.
Mit DIVIDE, SELECTEDVALUE, SWITCH baust du robuste, report-taugliche Logik
Mit USERELATIONSHIP und TREATAS bekommst du Modellrealität in den Griff, ohne jedes Mal am Datenmodell herumzubauen.

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:

Power BI Training – für einen sauberen, praxisnahen Einstieg
Power BI Coaching – für konkrete Herausforderungen in Modellen, DAX oder Performance
Data Strategy Check – um eure Analytics-Organisation ganzheitlich einzuordnen

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