CiAgICA8IS0tIExpbmtlZEluIC0tPgogICAgPHNjcmlwdCB0eXBlPSJ0ZXh0L2phdmFzY3JpcHQiPgogICAgICAgIF9saW5rZWRpbl9wYXJ0bmVyX2lkID0gIjEyMzUwNzMiOwogICAgICAgIHdpbmRvdy5fbGlua2VkaW5fZGF0YV9wYXJ0bmVyX2lkcyA9IHdpbmRvdy5fbGlua2VkaW5fZGF0YV9wYXJ0bmVyX2lkcyB8fCBbXTsKICAgICAgICB3aW5kb3cuX2xpbmtlZGluX2RhdGFfcGFydG5lcl9pZHMucHVzaChfbGlua2VkaW5fcGFydG5lcl9pZCk7CiAgICA8L3NjcmlwdD48c2NyaXB0IHR5cGU9InRleHQvamF2YXNjcmlwdCI+CiAgICAgICAgKGZ1bmN0aW9uKCl7dmFyIHMgPSBkb2N1bWVudC5nZXRFbGVtZW50c0J5VGFnTmFtZSgic2NyaXB0IilbMF07CiAgICAgICAgICAgIHZhciBiID0gZG9jdW1lbnQuY3JlYXRlRWxlbWVudCgic2NyaXB0Iik7CiAgICAgICAgICAgIGIudHlwZSA9ICJ0ZXh0L2phdmFzY3JpcHQiO2IuYXN5bmMgPSB0cnVlOwogICAgICAgICAgICBiLnNyYyA9ICJodHRwczovL3NuYXAubGljZG4uY29tL2xpLmxtcy1hbmFseXRpY3MvaW5zaWdodC5taW4uanMiOwogICAgICAgICAgICBzLnBhcmVudE5vZGUuaW5zZXJ0QmVmb3JlKGIsIHMpO30pKCk7CiAgICA8L3NjcmlwdD4KICAgIDxub3NjcmlwdD4KICAgICAgICA8aW1nIGhlaWdodD0iMSIgd2lkdGg9IjEiIHN0eWxlPSJkaXNwbGF5Om5vbmU7IiBhbHQ9IiIgc3JjPSJodHRwczovL3B4LmFkcy5saW5rZWRpbi5jb20vY29sbGVjdC8/cGlkPTEyMzUwNzMmZm10PWdpZiIgLz4KICAgIDwvbm9zY3JpcHQ+CiAgICA8IS0tIEVuZCBMaW5rZWRJbiAtLT4KICAgIA==
Generic filters
Exact matches only
Search in title
Search in excerpt
Search in content

Wenn Zahlen nicht genug sind

Graphische Tabellen in DeltaMaster auf Grundlage einer SSAS-Datenbank sind optimal geeignet, um viele Daten kompakt und übersichtlich anzuzeigen. Was ist aber, wenn dem Endanwender die Aussagekraft der Zahlen nicht genug ist, sondern sich zusätzlich noch Erklärungen zu den Ausprägungen der Kennzahlen direkt in der Graphischen Tabelle anzeigen lassen möchte? Im folgenden Blogbeitrag wird erläutert, wie Texte in die Graphische Tabelle integriert und dynamisch gepflegt werden können.

Problemstellung

Das Datenmodell des fiktiven Stuhlherstellers Chair AG beinhaltet bereits Ist- und Plandaten. Aus diesen Daten kann mithilfe von DeltaMaster problemlos eine Planabweichung dargestellt werden. Allerdings kann es vorkommen, dass nach der Erstellung des Plans initial unvorhergesehene Entwicklungen auftreten, die dazu führen können, dass dieser nicht erreicht werden kann. Des Weiteren können diese Entwicklungen zu der Erkenntnis führen, dass zu konservativ geplant wurde. In diesen Fällen liegt der Wunsch nahe, nachträglich externe Faktoren quantitativ zusätzlich zur Planabweichung auszuweisen. Dies ist allerdings nicht immer aussagekräftig genug oder in manchen Fällen ist es gar nicht möglich, derartige Entwicklungen überhaupt zu quantifizieren. Auch aufgrund etwaiger sich kompensierender Effekte ist es nicht nur spannend zu wissen, wie groß die schlussendliche Auswirkung der Änderung der Prämissen auf das Budget sind, sondern welche Auswirkungen überhaupt eine Rolle gespielt haben. In DeltaMaster gibt es bereits die Möglichkeit, Kommentare in die Graphische Tabelle einzubinden oder von der Graphischen Tabelle in einen SQL-Durchgriff abzuspringen. Im Folgenden wird gezeigt, wie diese Informationen direkt in der Graphischen Tabelle angezeigt werden können.

Grundlagen zu String-Kennzahlen in SSAS

Für Kennzahlen in SSAS gibt es die Möglichkeit, den Datentyp zu konvertieren. Für den vorliegenden Fall sind die Konvertierungen zwischen numerischen Werten und Strings von Interesse. Die MDX-Funktion „StrToValue“ konvertiert den übergebenen String in eine Zahl, während die Funktion „CSTR“ aus einer übergebenen Zahl einen String erzeugt.

Der Unterschied in der Formatierung wird schnell deutlich:

Kennzahlen in SSAS
Die Kennzahl Umsatz übernimmt die eingestellte Formatierung sowie den Standard-BI-Farbmodus (blau/rot) in DeltaMaster und wird wie für Zahlen üblich rechtsbündig angezeigt. Die Kennzahl „UmsatzText“ ist definiert als CSTR([Measures].[Umsatz]). Sie hat weder Farbe noch Formatierungseinstellungen und wird linksbündig dargestellt.

Anzeigen eines Textes mithilfe eines berechneten Elements

Eine einfache Möglichkeit, den gewünschten Text in der Graphischen Tabelle anzuzeigen, ist, ein berechnetes Element zu definieren, welches den Text in seiner Definition beinhaltet. Das könnte z.B. so aussehen:

“Der aktuelle Umsatz unterscheidet sich um”

+ CSTR(([Wertart].[Wertart].[temp],[Measures].[Umsatz]))

+ “€ vom Plan”

[Wertart].[Wertart].[temp] bezieht sich hier auf die absolute Planabweichung. Das Ergebnis sieht folgendermaßen aus:

Absolute Planabweichung
Man kann erkennen, dass Aggregationen kein Problem darstellen. Auch die Kombination mit der Kumulationsdimension oder anderen berechneten Elementen bereitet hier (unter Beachtung der jeweiligen SolveOrder) keine Probleme. Allerdings ist dieser Text noch nicht wirklich dynamisch. Eine einfache Erweiterung des Textes ist, diesen abhängig von einer Bedingung zu ändern.

Die Definition des berechneten Elements als:

“Der aktuelle Umsatz ist um”

+ CSTR(ABS(([Wertart].[Wertart].[temp],[Measures].[Umsatz])))

+ “€”

+ IIF(([Wertart].[Wertart].[temp],[Measures].[Umsatz])>0,”größer”,”kleiner”)

+ “als der Plan”

Führt zu folgendem Ergebnis:

Das Ergebnis ist nun ein bisschen dynamischer, allerdings hat der generierte Text noch keinerlei Mehrwert gegenüber der einfachen Ausweisung des Deltas in der Graphischen Tabelle.

Auslagern der Bedingungen in die Datenbank

Zurück zu dem Ausgangsproblem der Chair AG. Es soll nicht der Wert einer Kennzahl in einen Text geschrieben werden, sondern es soll erklärt werden, warum eine Kennzahl einen gewissen Wert ausweist.

Um dies abbilden zu können, wird das Datenmodell um eine Dimension „Erklärung“ und eine MeasureGroup „Erklärungen“ erweitert. Es gibt in unserem Szenario zwei verschiedene Möglichkeiten, warum sich der Ist- vom Planwert verändert haben könnte: Wachstum des Marktes und Veränderung der Anzahl der eigenen Filialen.

Die Dimension Erklärung besteht neben ID und Bezeichnung aus den folgenden Attributen:

 

Hierbei beinhalten die ersten sechs Attribute erklärungsspezifische Textbausteine, die abhängig von verschiedenen Bedingungen entweder den ersten oder den zweiten Wert annehmen sollen. Die Bedingungen sind an Measures geknüpft, deren Name in die Attribute 7-9 gepflegt wird. Die hier angegebenen Measures sollten so definiert werden, dass das Vorzeichen der Measure über die Bedingung entscheidet. Die Anzahl der Attribute kann beliebig erweitert werden. Hierbei ist es nicht notwendig, dass es genauso viele Bedingungen wie Textbausteinpositionen gibt. Es ist möglich, die verschiedenen Bedingungen flexibel für die verschiedenen Textbausteine zu verwenden. Dies wird dann relevant, wenn das System erweitert wird und sehr viele Textbausteine verwendet werden, diese aber nur von wenigen Bedingungen abhängen. Um dies steuern zu können, wird das letzte Attribut verwendet. Hier wird für jede Textbausteinposition festgelegt, welche Bedingung verwendet werden soll. Soll für Textbaustein 1 Bedingung 1, für Textbaustein 2 Bedingung 3 und für Textbaustein 3 Bedingung 2 verwendet werden muss dieses Attribut den Wert „132“ enthalten.

Die MeasureGroup Erklärungen baut auf dem Kontenansatz der SSAS auf. Die Bedeutung des Wertes einer Measure wird erst durch eine Dimension bestimmt. In diesem Falle wird aber nicht nur eine Measure benötigt:

 

Hierbei sind sowohl die Attribute als auch die Measures analog zu den bestehenden Measures erweiterbar, wenn komplexere Texte mit mehr verschiedenen Zahlen angezeigt werden sollen. Die Measure „RecCount_Erklärungen“ ist ein einfacher Datensatzzähler. Die Measures „Value1“ und „Value2“ sollen im Text erscheinen. Die Measures „Hilfsmeasure1“ und „Hilfsmeasure2“ werden für Berechnungen sowie Bedingungen verwendet und haben pro Erklärung einen anderen Wert. Die „Erklärungen_DC“ Measures zählt die verschiedenen Erklärungen. Diese wird später benötigt, um auf dem All-Element etwas Sinnvolles anzeigen zu können.

Der in DeltaMaster angezeigte Text kommt jetzt nicht mehr aus einem berechneten Element, sondern wird im CubeScript per CREATE MEMBER erstellt. Diese neue Measure soll nie Werte anzeigen, wenn „RecCount_Erklärungen“ den Wert 0 enthält:

HTML1

Dies muss explizit definiert werden, damit die Textbausteine nicht ohne Measures angezeigt werden.

Ein einzelner Textbaustein wird durch folgenden Code erzeugt:

HTML2

Hierbei wird das „conditions“-Attribut an der relevanten Stelle (hier Textbaustein 1) geprüft und – abhängig von dem Wert an der Stelle – die Measure der Bedingung ausgewertet. Ist die erzeugte Measure größer als 0, wird die erste Möglichkeit für den Textbaustein verwendet, in jedem anderen Fall die zweite.

An diese Textbausteine können nun die Measures angefügt werden:

HTML3

Hierbei ist zu beachten, dass diese als Text formatiert sein müssen und falls sie leer sind, ein leerer String angefügt werden muss. Zu beachten ist die Positionierung der Leerzeichen. Hier wird das Leerzeichen nur im Falle einer gefüllten Measure gewünscht.

Textbausteine und Measures können beliebig aneinandergereiht werden.

Um nicht nur Texte für die einzelnen Ausprägungen der Erklärungsdimension zu bekommen, wird nach dem Erzeugen der „ErklärungsText“-Measure noch ein Scope über das All-Element der Erklärungsdimension definiert:

HTML4

Dies führt dazu, dass, wenn nur eine Erklärung gefunden wurde, diese angezeigt wird, und wenn mehrere gefunden wurden, dass diese gezählt werden.

Für das oben beschriebene Szenario sieht die Dimensionstabelle wie folgt aus:

Dimensionstabelle

Jetzt müssen nur noch die verschiedenen Measures für die Erklärungen definiert werden.

Für Erklärung 1 wird ein Wachstum im Vergleich zum Vorjahr benötigt. Dazu wird der Gesamtmarktumsatz in Hilfsmeasure1 gespeichert. Das Wachstum wird durch den Ausdruck

HTML5

in Hilfsmeasure2 gespeichert. Das Vorzeichen dieser Measure ist gleichzeitig entscheidend, ob im Text „gewachsen“ oder „geschrumpft“ angezeigt werden soll. Die anzuzeigende Zahl soll jedoch immer positiv sein. Daher wird die Measure „Value1“ wie folgt berechnet:

HTML6

Für Erklärung 2 werden Filialeröffnungen („Value1“) und Filialschließungen („Value2“) gemessen. Wenn beides existiert, soll zwischen den beiden Texten ein Semikolon stehen. Dies wird durch „Hilfsmeasure2“ sichergestellt:

HTML7

Das Ergebnis sieht in DeltaMaster jetzt so aus:

Ergebnis DeltaMaster

Die Texte können jetzt analog zu normalen Measures verwendet werden.

Drill-down nach Erklärungen:

Drill down nach Erklaerung

Drill-down nach PLZ:

Drill down nach PLZ

Man kann erkennen, dass Aggregationen problemlos funktionieren. Auch Kumulationen funktionieren. Hier muss lediglich die „SCOPE_Isolation“-Klausel in den DeltaMaster-Optionen (Registerkarte System) aktiviert werden oder die Definition des Kumulationselements in das Cubeskript (vor die Text-berechnung) verschoben werden.

Abschließende Hinweise:

Der hier gezeigte Aufbau der Text-Measures funktioniert sehr robust, flexibel und performant. Allerdings muss man sich vor der Implementierung die Frage stellen, ob die Texte tatsächlich einen Mehrwert gegenüber einer Graphischen Tabelle mit ausschließlich Zahlen bringen. Ist dies der Fall, ist dies eine sehr schöne Möglichkeit, die Funktionalitäten der SSAS auf Texte anzuwenden. Allerdings muss man sich im Klaren sein, dass diese Implementierung einen hohen Pflegeaufwand mit sich bringt, denn jeder neue Text muss nicht nur aus Textbausteinen in der Dimensionstabelle aufgebaut werden, sondern gegebenenfalls auch mit einzelnen SCOPE-Statements im Cubeskript angepasst werden.

Der gezeigte Ansatz ist lediglich die Grundstruktur für derartige Texte. Diese kann beliebig erweitert werden. Zum Beispiel können die Namen von Dimensionselementen im Text mit angezeigt werden oder sogar ähnlich zum CustomRollUp-Ansatz beliebige MDX-Statements anstatt Measures als Bedingung oder Text mithilfe der Funktion StrToValue angegeben werden.