Expanded Tables in DAX

Marcus Wegener
vor 2 Tagen
4 Min. Lesezeit

Es gibt Themen im DAX-Umfeld, die man irgendwann einmal wahrnimmt, kurz einordnet und dann gedanklich zur Seite legt. Nicht, weil sie unwichtig wären, sondern weil sie im Alltag selten explizit benannt werden. Expanded Tables gehören für mich genau in diese Kategorie. Sie sind kein Feature, keine Funktion, kein Objekt im Datenmodell – und trotzdem erklären sie sehr viel von dem Verhalten, das wir in DAX täglich beobachten.

Bewusst wahrgenommen habe ich Expanded Tables das erste Mal über Tom Martens. Es war mehr ein „ah, interessant“ als ein echtes Durchdringen des Konzepts. Nach dem Daten-WG Offsite und einem längeren Gespräch mit Jasmin war für mich klar: Wenn ich DAX wirklich erklären will und nicht nur Funktionen aneinanderreihe, dann muss ich mich damit tiefer beschäftigen.

Warum man so wenig über Expanded Tables findet

Wer versucht, über Google mehr zu Expanded Tables zu finden, merkt schnell, wie dünn die Quellenlage ist. Je nach Suchbegriff stößt man auf „expanded tables“, „extended tables“ oder „expanded views“, aber wirklich praxisnahe Erklärungen sind selten. Das liegt nicht daran, dass das Thema unwichtig wäre, sondern daran, dass es nie offiziell dokumentiert wurde.

Expanded Tables stammen aus den frühen DAX-Tagen, etwa aus der Zeit zwischen 2010 und 2012. Damals wurden viele Konzepte eher erklärend als formal beschrieben. In der offiziellen Microsoft-DAX-Referenz tauchen Expanded Tables nicht auf. Das führt dazu, dass viele DAX-Entwickler mit den Effekten arbeiten, ohne das zugrunde liegende Denkmodell explizit zu benennen. Genau hier setzt das Konzept der Expanded Tables an.

Expanded Tables als gedankliches Hilfsmodell

Wichtig ist zunächst eines: Expanded Tables existieren nicht physisch. Es gibt keine Tabelle in der VertiPaq Engine, die plötzlich breiter wird. Es wird nichts materialisiert, was du dir anzeigen lassen könntest. Expanded Tables sind ein theoretisches Konstrukt, das hilft zu verstehen, wie DAX Filter, Beziehungen und Kontexte interpretiert.

Die Grundidee ist relativ einfach. Immer wenn Tabellen über Beziehungen miteinander verbunden sind, kann man sich vorstellen, dass eine Tabelle um Spalten aus den verbundenen Tabellen „erweitert“ wird. Diese Erweiterung erfolgt dabei immer in Richtung der Eindeutigkeit, also typischerweise von einer Faktentabelle in Richtung einer Dimension.

Nimm ein einfaches Sternschema: eine Sales-Tabelle mit einem Order-Date, verbunden mit einer Datumstabelle. In der Logik der Expanded Tables kannst du dir vorstellen, dass jede Zeile der Sales-Tabelle zusätzlich alle relevanten Spalten der Datumstabelle enthält. Monat, Jahr, Kalenderwoche – all das ist gedanklich Teil der erweiterten Tabelle, auch wenn es physisch nicht existiert.

Dieses Denkmodell erklärt, warum Funktionen wie RELATED überhaupt funktionieren. RELATED greift nicht „magisch“ auf eine andere Tabelle zu, sondern nutzt genau diese gedankliche Erweiterung entlang der Beziehung.

Theorie versus Realität in der Engine

Ein Stolperstein ist die Annahme, dass Expanded Tables tatsächlich irgendwo intern aufgebaut werden. Das ist nicht der Fall. Die VertiPaq Engine arbeitet spaltenorientiert und extrem effizient. Eine physische Materialisierung solcher breiten Tabellen wäre weder notwendig noch sinnvoll.

Trotzdem verhält sich DAX in vielen Situationen so, als ob diese Erweiterung existieren würde. Genau hier liegt der Wert des Konzepts. Es geht nicht darum, was technisch gespeichert wird, sondern darum, wie Filter und Kontexte logisch interpretiert werden.

Wenn du also hörst, dass Expanded Tables „nicht existieren“, ist das korrekt. Wenn du aber versuchst, komplexes Filterverhalten ohne dieses Konzept zu erklären, wird es schnell schwer verständlich.

Aktive und inaktive Relationen im Kontext von Expanded Tables

Besonders spannend wird das Thema, sobald inaktive Beziehungen ins Spiel kommen. In vielen Modellen gibt es mehr als eine Beziehung zwischen zwei Tabellen, etwa eine aktive Beziehung auf das Order-Date und eine inaktive Beziehung auf das Shipment-Date.

In der Logik der Expanded Tables bedeutet das: Es gibt potenziell mehrere mögliche Erweiterungen derselben Tabelle, abhängig davon, welche Beziehung gerade aktiv ist. Standardmäßig wird nur die aktive Beziehung genutzt. Sobald du jedoch in einer CALCULATE-Anweisung mit USERELATIONSHIP arbeitest, änderst du genau diese Erweiterung.

Gedanklich entsteht dadurch eine andere Version derselben Tabelle. Die Zeilen sind gleich, aber die angebundene Datumstabelle – und damit die „unsichtbaren“ Spalten wie Monat oder Jahr – unterscheiden sich. Das ist kein Nebeneffekt, sondern zentral für das Verständnis von DAX.

Zwei Expansionen gleichzeitig denken

In meinem Beispiel im Video treibe ich dieses Konzept bewusst auf die Spitze. Ich nutze dieselbe Sales-Tabelle zweimal: einmal mit der aktiven Beziehung auf das Order-Date und einmal virtuell mit der aktivierten Beziehung auf das Shipment-Date. Beide Tabellen sehen auf den ersten Blick identisch aus. Die sichtbaren Spalten sind gleich. Und trotzdem verhalten sie sich unterschiedlich, sobald sie in einer Berechnung miteinander interagieren.

Der Grund liegt genau in der Expansion. Auch wenn die Monatsspalte nicht explizit Teil der Abfrage ist, ist sie logisch vorhanden. Beim Vergleich der beiden Tabellen werden nicht nur die offensichtlichen Spalten berücksichtigt, sondern auch die implizit erweiterten Spalten aus der Datumstabelle.

Dadurch gibt es am Ende nur eine einzige Zeile, die in beiden erweiterten Tabellen exakt übereinstimmt. Und genau deshalb ist das Ergebnis der Berechnung nicht die Summe aller Werte, sondern exakt der Wert 30.

Warum das Konzept der Expanded Tables so wichtig ist

Expanded Tables helfen dabei, scheinbar „magisches“ DAX-Verhalten erklärbar zu machen. Warum filtert CALCULATE plötzlich stärker als erwartet? Warum liefert eine Filterung über eine virtuelle Tabelle ein anderes Ergebnis als gedacht? Warum spielt eine Datumsspalte eine Rolle, obwohl sie gar nicht explizit verwendet wird?

All diese Fragen lassen sich deutlich sauberer beantworten, wenn man das Denkmodell der Expanded Tables im Hinterkopf behält. Es zwingt dazu, nicht nur sichtbare Spalten zu betrachten, sondern auch die logischen Erweiterungen, die durch Beziehungen entstehen.

Gerade bei komplexeren Modellen mit mehreren Datumsbezügen, inaktiven Beziehungen und virtuellen Tabellen ist dieses Verständnis entscheidend.

Mein persönliches zu Expanded Tables

Expanded Tables sind kein offizielles Feature, kein Buzzword und kein „Geheimtrick“. Sie sind ein Denkmodell, das hilft, DAX konsistenter und verständlicher zu interpretieren. Vielleicht ist genau das der Grund, warum sie so selten explizit beschrieben werden. Sie passen nicht gut in eine Funktionsreferenz, sind aber enorm wertvoll für das mentale Modell.

Mein Ziel mit dem Video und diesem Beitrag ist nicht, eine endgültige Wahrheit zu formulieren, sondern einen Einstieg zu bieten. Wenn du beginnst, DAX-Abfragen mit dem Gedanken an Expanded Tables zu lesen, verändern sich viele Details. Dinge, die vorher zufällig wirkten, bekommen plötzlich Struktur. Und genau darin liegt für mich der eigentliche Wert dieses Konzepts.

Wenn du neugierig geworden bist, welche weiteren Möglichkeiten in Power BI stecken und du deine Fähigkeiten erweitern möchtest, dann schau dir unser Power BI Training auf der Daten-WG Website an. In diesem Training gehen wir tiefer in die Praxis, zeigen fortgeschrittene Use Cases und viele Tipps aus echten Projekten.