Kontext - die fortgeschrittene Version Teil 1

Im Artikel über Kontexte haben wir eine Einführung  zu den entsprechenden Begriffen gegeben. Mit dem dort erläuterten Modell kann man gut arbeiten – bei fortgeschrittenen DAX-Funktionen, wie beispielsweise der Funktion Calculate(), sollte man den Kontext besser verstehen – dafür brauchen wir aber einen Mehrteiler :-)

Zeilenkontext – was war das gleich?

In einer berechneten Spalte können wir leicht eine Berechnung über andere Spalten vornehmen – beispielsweise einen Bruttopreis: Die Adressierung der Spalten erfolgt über den Namen ohne Tabellenname – das ist nicht erforderlich, da klar ist, dass die Spalten der aktuellen Zeile gemeint sind. Die Berechnung erfolgt im Kontext der aktuellen Zeile.

Kontext im berechneten Feld

In einem berechneten Feld können wir nicht einfach sagen:

• [Netto] + [Netto] * [Ust] / 100 oder
• Auftrag[Netto] + Auftrag[Netto] * Auftrag[Ust] / 100

Klar – hier existiert kein Zeilenkontext. Wenn wir trotzdem beispielsweise die Summe der Bruttowerte haben möchten, verwenden wir einen Iterator: Die Funktion SumX ist ein Iterator – wie alle Funktionen, die mit einem X enden. Das bedeutet, dass die Funktion für jede Zeile der übergebenen Tabelle Auftrag einen Zeilenkontext erstellt, für diesen dann den angegebenen Ausdruck auswertet und am Ende zusammenzählt (bei MinX eben den kleinsten Wert, bei MaxX den größten usw.).

Der Benutzerkontext

Der Benutzer stellt auch einen Kontext zur Verfügung – durch Slicer oder auch durch die Umgebung in der Pivot-Tabelle. Das berechnete Feld MySum wird im Kontext der jeweiligen Pivot-Tabelle ausgeführt: Die "Umgebung" oder eben der Benutzerkontext für jede Zeile von MySum ist hier eben die Auftragsnummer. Das heißt, dass MySum abhängig ist vom Benutzerkontext. Oder besser: Der erste Parameter der Funktion SumX enthält zwar die Tabelle Auftrag, diese enthält aber jeweils nur die Zeilen, die laut Benutzerkontext zur Verfügung stehen. MySum wird in dieser Pivot-Tabelle 10 mal ausgewertet - jedes Mal über die Tabelle Auftrag, die aber jedes Mal nur eine Zeile, nämlich den Aktuellen Auftrag enthält. Das bedeutet: ==> Es wird immer erst der Benutzerkontext ausgewertet und über das Ergebnis werden die Zeilenkontexte gebildet.

Filter statt Tabelle

Legen wir ein zweites berechnetes Feld an und übergeben keine Tabelle, sondern einen Filter auf eine Tabelle (der zweite Teil bleibt gleich):

Dann verändert sich die Pivot-Tabelle wie folgt: Alle Felder, außer bei Auftrag = 1, sind leer. Warum nicht überall “10”? Ganz einfach: In Zeile 2 wird MySumFilter mit dem Benutzerkontext "Auftrag=2" ausgewertet. Damit bleiben in der an SumX übergebenen Tabelle eine Zeile übrig, nämlich die mit der Auftragsnummer "2". Von diesen Zeilen (es ist nur eine) werden alle Zeilen zurückgegeben, die als Auftragsnummer “1” haben – so bestimmt es der Ausdruck der Funktion Filter. Es wird also keine Zeile zurückgegeben. ==> Filter Ausdrücke in Iteratoren ergänzen also den aktuellen Benutzerkontext – sie überschreiben ihn nicht. Durch einen Filter werden Daten noch weiter eingegrenzt.

Den Benutzerkontext beeinflussen

Nun möchten wir aber überall “10” stehen haben – wir möchten also immer über alle Zeilen iterieren, egal welcher Benutzerkontext gesetzt ist. Dazu verwenden wir die Funktion All(): Syntax: ALL(

) oder ALL(; ;...) Wir legen ein drittes berechnetes Feld an – MySumFilterAll:

Das Ergebnis sieht dann wie folgt aus: Mit All() weisen wir an, dass ALLE Zeilen genommen werden sollen, unabhängig des gesetzten Benutzerfilters für die Tabelle Auftrag. All() löscht natürlich keinen Filter, sondern gibt von der übergebenen Tabelle alle angeforderten Spalten zurück – unabhängig des aktuellen Benutzer-Kontextes. Das bedeutet, man kann All() verwenden als

• ALL(

): und bekommt so alle Spalten der übergebenen Tabelle zurück

ALL(; ;…): und bekommt so alle genannten Spalten zurück

Die zweite Variante werden wir im Zusammenhang mit der Calculate()-Funktion weiter beleuchten.