Power BI berechnete Spalte: Unterschied zu Measures, DAX-Anleitung & Best Practices

Definition

Eine Power BI berechnete Spalte ist eine zusätzliche Spalte im Datenmodell, deren Wert pro Zeile mit einer DAX-Formel berechnet und gespeichert wird.

Sie ist kein Ersatz für ETL in Power Query und keine Kennzahl (Measure), die erst zur Laufzeit im Visual aggregiert wird.

Einleitung

Wenn im Reporting Kategorien fehlen, der Sortierwert nicht passt oder du aus mehreren Feldern ein nutzbares Attribut bauen willst, ist die berechnete Spalte oft der schnellste Hebel. Entscheidend ist nur: Spalten sind “pro Zeile”, Measures sind “pro Auswertung”. Wer das verwechselt, baut ein Modell, das langsam wird oder sich später schwer erklären lässt.

Berechnete Spalte vs. Measure: die klare Trennlinie

Eine berechnete Spalte wird beim Daten-Refresh für jede Zeile berechnet und als Wert im Modell abgelegt. Damit eignet sie sich perfekt zum Filtern, Gruppieren, Sortieren oder als Achse in Visuals.

Ein Measure wird erst berechnet, wenn ein Visual es anfordert, also abhängig von Filterkontext, Zeile/Spalte in einer Matrix und Slicern. Measures sind die richtige Wahl für Summen, Quoten, Vergleich Vorjahr oder dynamische KPI-Logik.

• Berechnete Spalte: “Welche Kategorie hat diese Zeile?”
• Measure: “Wie hoch ist die Kennzahl für die aktuell ausgewählte Menge?”
• Merksatz: Attribute = Spalte, Kennzahlen = Measure.

Schritt für Schritt: berechnete Spalte mit DAX erstellen

So erstellst du eine berechnete Spalte in Power BI Desktop:

• Wechsle in Power BI Desktop in die Daten- oder Modellansicht und markiere die Ziel-Tabelle.
• Klicke im Menü auf “Neue Spalte”.
• Gib eine DAX-Formel ein und bestätige mit Enter.

Ein typisches Beispiel für eine Segmentierung nach Einzelumsatz:

UmsatzSegment = IF ( 'Sales'[Amount] >= 1000, "A", "B" )

Danach kannst du “UmsatzSegment” als Slicer nutzen oder in einer Matrix als Zeilenfeld verwenden, ohne jedes Mal eine neue Logik in Visuals nachzubauen.

Praxisbeispiel: bessere Filter ohne Excel-Bastelei

Ein Finance-Team will Buchungen nach “Kostenart-Gruppe” auswerten, aber in der Quelle gibt es nur eine Kontonummer. Statt das Mapping monatlich in Excel zu pflegen, entsteht eine Mapping-Tabelle (Konto → Gruppe) und im Fakt wird die Gruppe per Beziehung gezogen. Dann genügt eine berechnete Spalte für ein stabiles Attribut wie “Gruppe_Sort”, damit die Reihenfolge im Bericht stimmt. Ergebnis: weniger manuelle Pflege, konsistente Filter und weniger Diskussionen über “welche Excel war die richtige?”.

Power Query vs. DAX: was gehört wohin?

In der Praxis entscheidet weniger die Syntax, sondern Wartbarkeit und Performance:

• Power Query nutzen, wenn du Daten bereinigst oder standardisierst (Datentypen, Split/Trim, Join/Merge, Duplikate, Normalisierung).
• DAX (berechnete Spalte) nutzen, wenn du ein Modell-Attribut brauchst, das eng an Beziehungen oder Modelllogik hängt (z. B. RELATED, Sortierspalten, Klassifikationen).
• Wenn eine Logik in Power Query stabil und quellnah abbildbar ist, ist sie dort meist besser aufgehoben.

Faustregel: Transformation möglichst früh (Power Query), Modelllogik gezielt im Modell (DAX). Das hilft auch dabei, dass nicht-IT-affine Nutzer später auf saubere, eindeutige Felder zugreifen und direkt in Power BI oder Excel weiterarbeiten können.

Modellierung & Performance: typische Fehler bei berechneten Spalten

Berechnete Spalten erhöhen Speichervolumen (VertiPaq) und können Refresh-Zeit verlängern. Häufige Stolpersteine:

• Zu viele hoch-kardinale Textspalten (z. B. zusammengesetzte Freitext-Schlüssel), die kaum gefiltert werden müssen.
• Spalten, die eigentlich Measures sein müssten (z. B. “Umsatz pro Kunde” als Spalte statt als Measure).
• Komplexe LOOKUPVALUE-Konstrukte als Workaround für fehlende Beziehungen.

Best Practice: Star-Schema bevorzugen, Beziehungen sauber setzen und nur die Spalten erzeugen, die im Bericht wirklich als Feld gebraucht werden.

Wann externe Unterstützung sinnvoll wird

Externe Hilfe lohnt sich, wenn die berechnete Spalte nur das Symptom ist, aber das Modell daneben liegt. Typische Situationen:

• Die Zahlen sind “irgendwie” widersprüchlich, weil Filterkontext, Beziehungen oder Granularitäten nicht sauber sind.
• Refresh oder Bericht wird langsam, sobald neue Spalten hinzugefügt werden.
• Mehrere Teams bauen parallel Logik, und niemand weiß, welche Regel die gültige ist.

Dann bringt ein kurzer Modell-Check oft schneller messbaren Nutzen als das nächste DAX-Feintuning: weniger manuelle Nacharbeit, klarere KPIs und weniger Risiko, dass ein Report bei Änderungen “kippt”.