Auf einem SQLPASS Event zur Einführung von Power BI und DAX kam vom vortragendem MVP ein Hinweis, dass man bei Microsoft die Sprache MDX als so schwierig für den Anwender eingestuft habe, dass Microsoft sich entschlossen habe, MDX mit DAX zu ersetzen.

In meiner Wahrnehmung ist DAX nicht unbedingt einfacher als MDX, auch nach langjähriger Beschäftigung mit DAX würde ich eher das Gegenteil behaupten. Richtig ist: es gab immer eine grosse Anfangshürde bei MDX. Hatte man diese Hürde aber überwunden, war die Sprache auf Grund ihrer klaren Grundlage fast schon leicht verständlich und intuitiv anzuwenden. Dagegen macht DAX bei den ersten Versuchen den Eindruck, leichter verständlich zu sein, aber die Schwierigkeiten zeigen sich schnell. Am Schluss ist es eine grosse Aufgabe, verläßliche KPIs zu entwicklen, also DAX-Code, der unter allen Umständen das erwartete Ergebnis liefert.

Meine Erfahrung zeigt, dass die Komplexität der Sprache DAX zu Herausforderungen beim Unterrichten und generell beim Erlernen der Sprache führt: das Thema muss schleifenartig vermittelt bzw. erlernt werden, so, wie es auch das Handbuch "The Definitive Guide To DAX" macht.

Die typische Zielgruppe für DAX, die Excel PowerUser wie z.B. Finanz-Analysten, ist primär an schneller Einsetzbarkeit interessiert, nicht an den Grundlagen der Sprache. Die Sprache soll nicht als Selbstzweck, sondern als Werkzeug verstanden werden. Viele PowerUser sind tatsächlich in der Lage, diese Art von Effektivität mit den folgenden Mitteln zu erreichen:

Die Schwierigkeiten beginnen dort, wo sich gewisse Umstände ändern:

1. Ein DAX-KPI wurde entwickelt und funktioniert offensichtlich. Der KPI wird deployt und ein Anwender nutzt die interaktiven Möglichkeiten eines PowerBI-Berichts, um den KPI in anderen Visuals oder mit anderen Daten zu verwenden als in der Entwicklungs-Umgebung. Plötzlich zeigt der KPI falsche Werte an.

2. Die Zielrichtung eines KPIs ändert sich geringfügig. Beispielsweise möchte der Kunde statt des Vormonats-Wertes gern den Vorwochen-Wert sehen. Der resultierende DAX-Code kann jetzt alles andere als trivial sein. Ev. kommen jetzt auch Schwächen im Datenmodell zum Vorschein.

Aus meiner jetzigen Perspektive gibt es keine einfachen DAX-Expressions bzw. einfachen DAX-Abfragen. Daher scheitert man mit dem Versuch, einfache Beispiele zu verstehen, die zu schwierigeren gesteigert werden. Selbst wenige Zeilen einer DAX-KPI müssen mit allen Konsequenzen verstanden sein; und das ist eine anspruchsvolle Aufgabe.

Komplexität von DAX-KPIs muss nicht durch komplexen Code oder viele Zeilen Code bedingt sein, sondern kann einfach durch die Vielfalt der Einsatz-Szenarien zustande kommen. Ganz besonders komplex ist die Funktion CALCULATE; das Keyword CALCULATE ist ein Knackpunkt der Sprache. Man könnte auch sagen: wer CALCULATE wirklich verstanden hat, kann DAX-Code entwickeln.

Den Anfangspunkt in beiden Sprachen - MDX und DAX - bilden die Dimensions-Daten wie z.B. Jahre und Regionen. In MDX ist man als Entwickler damit beschäftigt, aus den Dimensions-Daten korrekte Tupels zu bilden wie z.B. (2018, East). Einfache Aggregate wie z.B. Summen- oder Count-Aggregate ergeben sich dabei automatisch, da sie den Tupels zugeordnet sind.

In DAX werden Dimensions-Daten dazu verwendet, implizit oder explizit Filter zu bilden. Mit Filtern wird auf einen Haufen von Fakten-Zeilen verwiesen. Im Gegensatz zu MDX müssen die vielen Fakten-Zeilen aber noch in einem weiteren Schritt durch eine vom Anwender definierte Rollup-Formel zu einem Skalar verdichtet werden. Erst der Skalar läßt sich in einer Zelle anzeigen. Ein wesentlicher Unterschied zwischen beiden Sprachen ist also, dass in MDX im Wesentlichen eine einzelne Adressierungs-Aufgabe entsteht, während in DAX noch eine zusätzliche Verdichtungs-Aufgabe anfällt.

In MDX stellte das Erlernen der Tupel-Syntax eine so grosse Anfangs-Hürde dar, dass sie in der Vergangenheit den Zugang zur Sprache für viele grundsätzlich verhindert hat. MDX erscheint Anwendern meist zu mathematisch und der Schritt vom Business Case, der in menschlicher Sprache formuliert wird, hin zur Implementierung in mathematischer Tupel-Syntax ist weit. Dagegen haben Anwender das Gefühl, mit den Objekten der Sprache DAX - also Tabellen, Spalten und Relationships - schon vertraut zu sein und meinen daher, mit diesen Objekte den Business Case besser darstellen zu können.

Zwei typische Stolpersteine in DAX sind die Begriffe Tabelle und Spalte. Beide Cube-Produkte - Analysis Services MultiDimensional auf der einen Seite und Analysis Services Tabular bzw. Power BI auf der anderen Seite - haben gemeinsam, dass sie Tabellen als Quell-Objekte verwenden und daraus Spalten-Objekten generieren. Das Ganze wird dann als Cube präsentiert. Aber eine Tabelle, die der Tabulare Cube zeigt, ist nicht die gleiche Tabelle, aus der die Quell-Daten gewonnen werden!

Bei beiden Cube-Varianten transformiert die Vertipaq-Engine Daten einer relationalen Welt in Daten einer dimensionalen Welt. In beiden Welten gibt es eigene Typen, Begriffe, Sprachen etc. Diese Tatsache führt zu Komplexität: der Transformations-Prozess ist komplex, die Daten sind komplex, die Begriffe sind komplex etc. Die Philosophie von SelfService bringt es mit sich, Komplexität möglichst vor dem Anwender zu verbergen. Tatsächlich aber können die tabularen Quell-Objekte und deren Eigenschaften nicht (ganz) verborgen werden, da der SelfService-Anwender in seinem Measure beschreiben muss, wie aus relationen Daten - von der Granularität der Faktentabelle aufwärts - Cube-Daten aggregiert werden (s.o.). Auf diese Weise wird der PowerUser dann doch wieder mit zwei Welten konfrontiert und es entsteht ein unvermeidlicher Objekt- und Konzept-Mischmasch, der sich als Komplexität niederschlägt. Die Sprache DAX selbst wirkt dabei nicht komplex, sie zeigt ein einheitliches Bild und die Syntax scheint auf Grund der Objekt-Typen Tabelle, Spalte, Relationship etc. leicht verständlich.

Ein Measure ist bei MDX und DAX eine Art Code-Snippet. Ein Measure wird in der UI wie eine Tabellen-Spalte dargestellt und kann vom Anwender durch Interaktion auf der Berichts-Oberfläche platziert werden. Durch die Stelle, an der das Measure abgelegt wird, entsteht für das Measure ein Kontext. Der Kontext liefert Daten zur Parametrierung des Code-Snippets. Durch die jeweils unterschiedlichen Kontexte entstehen unterschiedliche Parametrierungen für das Measure und am Schluss auch unterschiedliche Werte.

Durch folgende Gegebenheiten entstehen geänderte Kontexte:

Den möglichen Kontext und seinen Einfluss auf ein KPI vorherzusehen, ist die besondere Herausforderung bei DAX. Bei MDX ist das Problem grundsätzlich zwar auch vorhanden, aber es wurde schon beim Entwickeln des Cubes zum größten Teil automatisch durch die Software gelöst. Bei der Entwicklung von KPIs mit DAX müssen die möglichen Kontexte im Code schon berücksichtigt werden. Diese Leistung ist dann möglich, wenn der DAX-Entwickler die Mechanik von DAX genau versteht. Genau hier ist aber das Problem: auf Grund des Self-Service-Gedankens sind die komplexen Verhaltensweisen in Automatismen weitestgehend verborgen und zeigen sich erst, wenn das Measure live zum Einsatz kommt.