Power BI DAX Measure einfach erklärt | Power BI Fabric Begriffe

Eine DAX Measure ist eine dynamische Berechnung, die sich bei jeder Filterung im Bericht automatisch neu auswertet – und damit aus einem starren Datenmodell ein lebendiges Reporting macht.

Was eine DAX Measure ist – und warum sie deinen Report erst lebendig macht

DAX steht für Data Analysis Expressions und ist die Formelsprache von Microsoft Power BI und Microsoft Fabric. Eine Measure ist darin eine benannte Berechnung – etwa eine Summe, ein Durchschnitt oder eine Wachstumsrate –, die nicht fix in einer Spalte abgelegt wird, sondern erst im Moment der Anzeige ausgewertet wird. Genau dieser Punkt unterscheidet sie von allem, was du aus Excel kennst: Eine Measure rechnet sich bei jedem Klick auf einen Slicer, jede Auswahl in einer Visualisierung und jeden Drill-Down neu.

In einem sauber aufgebauten Power-BI-Dataset arbeiten wir bei DBI mit drei Schichten, und die Measure ist die dritte davon:

Power Query (M) – zum Laden und Vorbereiten der Daten.
Datenmodell – zum Aufbau der relationalen Struktur (Star Schema).
DAX Measures – zum Berechnen und Analysieren der Kennzahlen.

Diese Trennung ist kein Selbstzweck. Sie sorgt dafür, dass jede Berechnung genau eine Aufgabe hat, leicht zu warten ist und sich auch nach Monaten noch nachvollziehen lässt. Eine Measure greift dabei immer auf die Struktur des Datenmodells zurück und nutzt die Beziehungen (Fremdschlüssel zu Primärschlüssel), um Werte korrekt zu aggregieren. Ein sauber modelliertes Star Schema ist deshalb die Grundlage für jede eindeutige Measure-Berechnung.

Measure vs. berechnete Spalte – der wichtigste Unterschied

Diese Verwechslung kostet in der Praxis am meisten Zeit, deshalb hier klar getrennt:

Eine berechnete Spalte wird einmal pro Zeile beim Aktualisieren des Modells berechnet und physisch im Speicher abgelegt. Sie belegt Arbeitsspeicher und kennt nur den Zeilenkontext.

Eine Measure speichert nichts. Sie wird erst zur Laufzeit berechnet – und zwar genau für den Filterkontext, in dem sie gerade steht. Wählst du im Bericht das Jahr 2024 und die Region Süd, rechnet die Measure exakt diese Schnittmenge. Faustregel: Alles, was du aggregieren willst (Summen, Quoten, Vergleiche), gehört in eine Measure. Spalten nutzt du nur für beschreibende Attribute und Schlüssel.

Measures organisieren: die Dummy-Tabelle

Power BI verlangt, dass jede Measure einer Tabelle zugeordnet ist. Statt sie wahllos über deine Fakten und Dimensionen zu verteilen, bündeln wir sie an einem Ort. Dafür legst du eine leere „Dummy"-Tabelle an:

DBI_MEASURES_BASE = DataTable ( "dummy", INTEGER, {{1}} )

Alle Measures, die du anschließend erstellst, ordnest du dieser Tabelle zu. Innerhalb davon gruppierst du über Display Folders (Modellansicht → Measure markieren → Eigenschaft Anzeigeordner ) nach Themen – etwa nach Base, Derived und Format. Das hält dein Modell auch bei 200 Measures übersichtlich.

Die DBI-Measure-Architektur: logisch aufeinander gestapelt

Der Kern unserer Methodik: Measures werden nicht isoliert geschrieben, sondern aufeinander gestapelt . Jede komplexe Kennzahl baut auf einer einfacheren auf. Das macht spätere Anpassungen schnell, sicher und für jeden im Team verständlich.

Die vier Ebenen von unten nach oben:

Base Measures – die Fundamente (Summen, Vorjahr, Delta, kumuliert).
Derived Measures – spezialisierte Kompositionen aus Base Measures (z. B. ein einzelner KPI).
Quoten – ineinander verrechnete Derived Measures.
Switch-KPI – ein Umschalter, um Kennzahlen dynamisch im Visual zu tauschen.

Dazu ein paar feste Namenskonventionen, die du konsequent einhalten solltest:

Den Namen der Faktentabelle als Prefix verwenden.
Nur Großbuchstaben, als Trennzeichen ausschließlich den Unterstrich.
Base Measures werden mit einem führenden Unterstrich eingeleitet (z. B. _VERKÄUFE_IST ).

Für die folgenden Beispiele nehmen wir eine unpivotisierte Faktentabelle DBI_FACT_VERKÄUFE mit einer Spalte wert , eine KPI-Dimension DIM_DBI_KPI und eine lückenlose Datumsdimension DIM_DBI_DATE .

Base Measures – die Fundamente

_IST – der aktuelle Wert

Summiert alle Zeilen der Spalte wert , unabhängig von der KPI. Das ist die Basis, auf der alles Weitere aufsetzt:

_VERKÄUFE_IST = SUM ( DBI_FACT_VERKÄUFE[wert] )

_GJ – das aktuelle Geschäftsjahr

Fixiert die Kennzahl auf das letzte verfügbare Jahr in deiner Zeitreihe. Perioden innerhalb des Jahres lassen sich weiterhin filtern, das Jahr selbst aber nicht:

_VERKÄUFE_GJ =
CALCULATE (
    [_VERKÄUFE_IST],
    DIM_DBI_DATE[Jahr] = MAX ( DIM_DBI_DATE[Jahr] )
)

_VJ – der Vorjahreswert

Wählst du z. B. Januar 2024, gibt diese Measure den Wert für Januar 2023 zurück:

_VERKÄUFE_IST_VJ =
CALCULATE (
    [_VERKÄUFE_IST],
    DATEADD ( DIM_DBI_DATE[date], -1, YEAR ),
    ALL ( DIM_DBI_DATE )
)

Für das Vorvorjahr setzt du einfach -2 statt -1 ein. Und das Schöne am Stapeln: Das Vorjahr lässt sich genauso an andere Base Measures anhängen, z. B. an _VERKÄUFE_GJ .

_DELTA – Veränderung absolut und prozentual

Die absolute Differenz zum Vorjahr:

_VERKÄUFE_IST_VJ_DELTA_ABS =
[_VERKÄUFE_IST] - [_VERKÄUFE_IST_VJ]

Und prozentual – immer über DIVIDE , damit eine Division durch null sauber abgefangen wird:

_VERKÄUFE_IST_VJ_DELTA_PROZ =
DIVIDE ( [_VERKÄUFE_IST_VJ_DELTA_ABS], [_VERKÄUFE_IST_VJ] )

Konvention: Zur Unterscheidung der Deltas immer ein Suffix anhängen – PROZ für Prozent, ABS für absolut.

_KUM – kumulierte Werte (Year-to-Date)

Hierfür ist eine vollständige Zeitreihe ohne Lücken Pflicht, sonst funktioniert die Time-Intelligence nicht:

_VERKÄUFE_IST_KUM =
CALCULATE (
    TOTALYTD ( [_VERKÄUFE_IST], DIM_DBI_DATE[date], ALL ( DIM_DBI_DATE ) )
)

Liegen Teile deiner Zeitreihe in der Zukunft (etwa für Budget- oder Forecast-Daten), willst du verhindern, dass der kumulierte Wert flach nach vorne gezogen wird. Diese Variante kumuliert nur bis zum heutigen Monat – kenntlich gemacht durch das Suffix TDY :

_VERKÄUFE_IST_KUM_TDY =
VAR lastupdatemonth = VALUE ( FORMAT ( TODAY (), "YYYYMM" ) )
RETURN
    CALCULATE (
        TOTALYTD ( [_VERKÄUFE_IST], DIM_DBI_DATE[date], ALL ( DIM_DBI_DATE ) ),
        DIM_DBI_DATE[month_id] < lastupdatemonth
    )

Derived Measures – spezialisiert auf einen KPI

Auf den Base Measures bauen wir nun konkrete Reporting-Kennzahlen auf. Da unsere Faktentabelle mehrere KPIs in derselben Spalte führt (Umsatz, Erlös, Gehälter), filtern wir hier über die DIM_DBI_KPI :

UMSATZ_IST =
CALCULATE (
    [_VERKÄUFE_IST],
    DIM_DBI_KPI[kpi_key] = 1,
    ALLEXCEPT ( DIM_DBI_KPI, DIM_DBI_KPI[kpi_key] )
)

Das ALLEXCEPT stellt sicher, dass eine Filterung der KPI-Dimension im Bericht diese Measure nicht überschreiben kann – UMSATZ_IST bleibt also immer der Umsatz, egal was der Nutzer im Slicer auswählt. Analog legst du GEHALT_IST mit kpi_key = 3 an.

Quoten – Derived Measures ins Verhältnis setzen

Jetzt verrechnen wir zwei abgeleitete Measures miteinander, hier die Gehaltsquote am Umsatz:

GEHALTSQUOTE_UMSATZ_IST =
DIVIDE ( [GEHALT_IST], [UMSATZ_IST] )

Switch-KPI – Kennzahlen dynamisch umschalten

Zum Schluss die Krone: ein Umschalter, mit dem der Nutzer auf einem einzigen Visual zwischen verschiedenen Kennzahlen wechseln kann.

KPI_SWITCH =
VAR selection = SELECTEDVALUE ( DIM_DBI_KPI[kpi_key] )
RETURN
    SWITCH (
        TRUE (),
        selection = 1, [UMSATZ_IST],
        selection = 3, [GEHALT_IST],
        selection = 4, [GEHALTSQUOTE_UMSATZ_IST],
        BLANK ()
    )

Damit das funktioniert, erweiterst du die DIM_DBI_KPI um die Quoten-Einträge und am besten um eine Spalte measure_types , die zwischen derived und quote unterscheidet:

kpi_name	kpi_key	measure_types
umsatz	1	derived
erlös	2	derived
gehälter	3	derived
gehaltsquote_umsatz	4	quote

Bonus: Format Measures für saubere Beschriftungen

Aus der Projektpraxis haben wir Format Measures eingeführt und bewusst von den Time-Intelligence-Measures getrennt. Das sind Measures, die primär für die Textausgabe formatiert sind – etwa ein Datenstand-Label für die Kopfzeile eines Berichts:

Datenstand =
"Stand Ende " &
FORMAT (
    CALCULATE (
        MAX ( DBI_FACT_VERKÄUFE[date_id] ),
        ALLEXCEPT ( DIM_DBI_DATE, DIM_DBI_DATE[date_id] )
    ),
    "MMM yyyy"
)

Deine erste gestapelte Measure in 4 Schritten

Schritt 1: Lege die Measure-Tabelle DBI_MEASURES_BASE als leere DataTable an, damit du alle Measures an einem Ort bündelst.

Schritt 2: Erstelle deine Base Measure _VERKÄUFE_IST mit SUM . Sie ist das Fundament – verwende sie nie isoliert im Bericht, sondern immer als Bezug für höhere Ebenen.

Schritt 3: Stapele darauf das Vorjahr ( _VERKÄUFE_IST_VJ ) und das Delta. Achte darauf, dass deine DIM_DBI_DATE auf Tagesbasis vollständig ist – ohne Lücken funktionieren YTD und Vorjahresvergleiche nicht korrekt.

Schritt 4: Leite spezialisierte Measures ( UMSATZ_IST ) und Quoten ab und ordne alles über Display Folders. Teste früh und gegen die Quelle – ein kurzer SQL-Abgleich auf einen bekannten Zeitraum erspart dir später stundenlange Fehlersuche.

DAX Measure FAQs

Was ist der Unterschied zwischen einer Measure und einer berechneten Spalte?

Eine berechnete Spalte wird beim Refresh pro Zeile berechnet und im Speicher abgelegt. Eine Measure speichert nichts und wird erst zur Laufzeit im jeweiligen Filterkontext ausgewertet. Für Aggregationen, Quoten und Vergleiche nimmst du immer eine Measure.

Braucht man für DAX Programmierkenntnisse?

Für einfache Measures wie Summen oder Durchschnitte reicht ein Klick. Sobald es um Filterkontext, Vorjahresvergleiche oder Quoten geht, lohnt sich ein strukturiertes Vorgehen mit gestapelten Base Measures – genau das macht die Logik auch ohne tiefe Programmiererfahrung beherrschbar.

Warum sollte ich eine eigene Measure-Tabelle anlegen?

Power BI verlangt, dass jede Measure einer Tabelle zugeordnet ist. Eine eigene Dummy-Tabelle bündelt alle Measures an einem Ort und verhindert, dass sie über Fakten und Dimensionen verstreut liegen. Über Display Folders bleibt das Ganze auch bei vielen Kennzahlen übersichtlich.

Was bedeutet Filterkontext?

Der Filterkontext ist die Menge aller Filter, die zum Zeitpunkt der Berechnung aktiv sind – aus Slicern, Zeilen- und Spaltenüberschriften und Cross-Filtering. Eine Measure rechnet immer genau für diesen Kontext. Mit CALCULATE , ALL und ALLEXCEPT steuerst du ihn gezielt.

Warum muss die Zeitreihe lückenlos sein?

Time-Intelligence-Funktionen wie TOTALYTD oder DATEADD setzen eine vollständige, tagesgenaue Datumsdimension voraus. Fehlen Tage, liefern YTD- und Vorjahresberechnungen falsche Ergebnisse. Deshalb baust du die DIM_DBI_DATE immer durchgängig auf.

Mit uns über Power BI Beratung sprechen

Vertiefe dein Wissen mit unseren Webinaren

Melde dich für unsere kostenlosen Webinare an oder abonniere unseren Newsletter, um über neue Webinare und BI-Expertise auf dem Laufenden zu bleiben.

Zu den Webinaren · Newsletter abonnieren

Kostenlose Webinare · Live-Demos & Q&A · Praxisnahe Inhalte · Von BI-Experten

DBI Analytics Microsoft Solutions Partner für Data & AI. Power BI Beratung, Microsoft Fabric Migration und Agentic BI für den DACH-Mittelstand und Konzerne.

Daten & KI mit europäischer Datensouveränität.

Services: Power BI Beratung · BI Consultant · Microsoft Fabric Migration · Managed Agentic BI · Power BI MCP Server · Festpreis-Pakete

Power BI DAX Measure einfach erklärt um Reportings schneller zu machen