Variablen in relationalen Anwendungen geben die Kontrolle über die Gestaltung von Planungsanwendungen und über Verknüpfungen in Grafischen Tabellen. Gleichzeitig lassen sich nun viel einfacher Kennzahlen erstellen, die sich auf den Kontext eines Berichtes beziehen.
Variablen in relationalen Anwendungen – die Grundidee
Mit dem aktuellen Release 6.4.4 wurde die Berichtserstellung auf relationalen Modellen vereinfacht. Ermöglicht wurde dies durch die Einführung neuer Variablen in relationalen Anwendungen, die einen niedrigschwelligen Einstieg bei gleichzeitig stark angestiegener Funktionalität erlauben.
Nun einfach zu realisieren: nur dann Verknüpfungen, wenn der Umsatz 100.000 übersteigt!
Häufig möchte man Berechnungen oder Funktionalitäten in Abhängigkeit vom Kontext implementieren. In der multidimensionalen OLAP-Welt steht mit der Abfragesprache MDX von Haus aus ein mächtiges Werkzeug zur Verfügung. Mit MDX ist es möglich, sich über Befehle wie [Kunden].[Kunden].currentmember auf den gerade aktiven Kunden oder mit ([Measures].[Umsatz],[Kunden].[Kunden].currentmember) auf seinen Umsatz zu beziehen.
Mit dem Release 6.4.4 können wir nun solche Referenzen auch auf relationalen Modellen einsetzen. Dabei können wir uns im Gegensatz zu OLAP-Modellen nicht auf fertige MDX-Konstrukte beziehen, sondern haben die Funktionalitäten in unserer SQL-Engine nachgebildet.
Das Gute daran für Sie: Sie können sich nun genauso einfach wie auf OLAP-Cubes auf den Kontext Ihres Berichtes beziehen, ohne dass bei Ihnen vertiefte SQL-Kenntnisse vorliegen müssen.
Bemerkung: Natürlich kann es nie schaden, diese vertieften Kenntnisse trotzdem zu besitzen! Mit ihnen können wir in manch komplexeren Anwendungsfällen noch feiner auf gegebene Rahmenbedingungen reagieren und noch immer passgenaue Lösungen erstellen.
Mit diesen Variablen können Sie zum Beispiel bestimmen, auf welchen Zellen einer Planungsanwendung Eingaben erlaubt sein sollen, welche Zellen einer Grafischen Tabelle auf weitere Berichte verweisen dürfen und sie können raffinierte Analysewerte anlegen, die sich auf den Kontext beziehen.
In der obigen Abbildung sehen Sie ein Anwendungsbeispiel: Mit den neuen Variablen für relationale Anwendungen ist es gelungen, die Verknüpfungen nur dann anzuzeigen, wenn für den Umsatz überhaupt ein Wert vorliegt, der dann auch noch die 100000-Euro-Grenze überschreiten muss.
Variablen für den Kontext
Fangen wir langsam an: Nehmen wir doch zunächst einmal an, dass wir uns in einer Zelle einer Grafischen Tabelle befinden.
Von hier aus können wir uns mit den nun implementierten Neuerungen schon einmal auf die folgenden Größen beziehen:
- <value> – der Zahlenwert in dieser Zelle
- <measure> – die ID des zugehörigen Analysewerts
- <dimXkey>, <dimX> – Name des aktuellen Elementes aus der Dimension mit der ID X
- <dimXlevel> – die Ebene des aktuellen Elements, ausgedrückt als Zahl. Es wird beginnend von 0 für das All-Element pro hinabgestiegene Ebene eine 1 addiert.
- <dimXuniquename> – ein eindeutiger Bezeichner für ein Element innerhalb einer Hierarchie
Als Demonstrationsbeispiel nehmen wir uns einen Bericht aus unserer Demo-Anwendung Chair her, an dem wir den Einsatz dieser fünf Größen veranschaulichen wollen.
Variablen in relationalen Anwendungen in Verknüpfungen nutzen
Neu ist im aktuellen Release auch die Möglichkeit, bei relationalen Anwendungen Bedingungen für Verknüpfungen zu hinterlegen, sodass diese überhaupt angezeigt werden. In dem verknüpften Bericht können weitere Details aufgeführt werden, die bei direkter Erwähnung den Hauptbericht überfrachten könnten (aber denken Sie immer an die Möglichkeit der Navigation an Ort und Stelle im Hauptbericht!).
Der Aufbau und Inhalt des verlinkten Berichts ist hier für unsere Überlegungen weniger relevant und wir stellen uns in Gedanken einen interessanten Bericht vor, den wir vom Hauptbericht aus unmittelbar erreichen wollen.
In unserem Hauptbericht verwenden wir die drei Dimensionen Vertrieb, Kunde und Produkt sowie die Kennzahlen Umsatz und Rabatt. Die Kundendimension können wir als Berichtsempfänger noch weiter aufklappen (dies lässt sich unter “Achse bearbeiten” in den Optionen festlegen!).
Aktivieren wir nun im Editieren-Menü auf der rechten Seite den Punkt Verknüpfungen und verweisen auf einen anderen Bericht, sind die Verknüpfungen standardmäßig für alle Zellen aktiv:
Standardmäßig sind Verknüpfungen auf allen Zellen aktiv
Neuer Tab Bedingung
Wechseln wir nun beim Optionsmenü der Verknüpfungen in den neuen Tab Bedingung, lässt sich dort ein Ausdruck eingeben, der als Ergebnis True oder False ergibt. Folgerichtig wird bei True die Verknüpfung angezeigt, bei False nicht. Bei gedrückter Alt-Taste lassen sich mit Mouseover einige benötigte IDs ablesen:
Benötigte IDs können im unteren Teil des Fensters abgelesen werden
Beispielsweise erkennen wir hier, dass Folgendes gilt:
- Kunde hat die Dimensions-ID 2
- Lohn hat die Measure-ID 2
- Das Element Nord in der Regions-Ebene besitzt innerhalb der Kunden-Hierarchie den eindeutigen Bezeichner [1|2]
- Aus dem Bezeichner [1|2] lässt sich ableiten: Die Regions-Ebene hat das Level 1 und der Key des Elementes Nord ist ‘2’.
Durch weiteres Überfahren mit der Maus sehen wir, dass die Dimensionen Produkt und Vertrieb die IDs 3 bzw. 5 besitzen. Umsatz und Rabatt haben die Measure-IDs 5 bzw. 4.
In der Vertriebsdimension wird deutlich, dass zum Beispiel Vertriebler Hohlmaier auf dem Level 1 liegt und durch den Key ‘V1’ beschrieben wird, es also nicht zwingend ein als Zahl interpretierbarer String sein muss.
Vertriebler Hohlmaier ist intern ‘V1’
Referenz auf <value>
Versuchen wir es nun einmal mit der Bedingung “<value> >= 100000”, die wir auch bereits in der anfangs gezeigten Grafik eingesetzt haben. Demzufolge sollen nur Zellen mit einem Wert gleich oder über 100.000 mit Verknüpfungspfeil erscheinen:
Verknüpfung nur bei Werten oberhalb der Schranke 100.000
Diese Bedingung sorgt gleichzeitig dafür, dass Zellen ohne Wert keine Verknüpfung erhalten. “<value> >= 100000” ignoriert den konkreten Analysewert, egal ob Umsatz oder Rabatt – beide Fälle werden gleichbehandelt.
Kennzahl-Variablen nutzen
Soll der Verknüpfungspfeil für jede Zelle erscheinen, in der ein Zahlenwert vorliegt, so hilft die Abfrage “<value> is not null”:
Verknüpfung nur bei vorhandenen Werten
Nun wollen wir zusätzlich die Verknüpfungen für alle Kennzahlen außer Rabatt zeigen. Effektiv bleibt hier also die Kennzahl Umsatz übrig. Rabatt hatte die Measure-ID 4. Mehrere Bedingungen, die zusammen erfüllt sein müssen, lassen sich mit “and” verknüpfen (bei hinreichenden Bedingungen kann auch “or” zum Einsatz kommen).
Wir ergänzen die bisherige Bedingung “<value> is not null” um die Abfrage “<measure> != 4” (!= steht für ungleich):
Keine Verknüpfung für Rabatt und nur bei vorhandenen Werten
Die runden Klammern dienen hier der besseren Erkennbarkeit der Zusammengehörigkeit der Terme und wären im vorliegenden Beispiel nicht unbedingt erforderlich.
Mit Variablen in relationalen Anwendungen Dimensionen ansprechen
Analog kann man Bedingungen angeben, sodass Verknüpfungen nur für bestimmte Dimensionselemente erscheinen. Möchten wir diese nur für Region Süd aktivieren und der Wert in der Zelle soll ≥ 100.000 sein, führt der Ausdruck “(<value> >= 100000) and (<dim2key> = ‘1’)” zum vermeintlich schnellen Erfolg:
Verknüpfungen für Werte >= 100.000, aber nur für Süd
Die 2 in dim2key bezeichnet die Dimension Kunde und ‘1’ steht in der Regions-Ebene für Süd. “Süd” ist nur ein Bezeichner, der hier nicht angesprochen wird.
Der eindeutige Name (uniquename)
Wir hatten den Drill-in in der Kundendimension erlaubt. Wenn man nun in die Gebietsebene unterhalb der Regionen hinabsteigt, stellt man fest, dass auch für Süd 1 Verknüpfungen aktiviert sind:
Verknüpfungen auch für Süd 1
Dies liegt daran, dass Keys zwar in einer einzigen Ebene eindeutig sind, aber für zwei Elemente aus unterschiedlichen Ebenen identisch sein können. Auch “Süd 1” besitzt den Key ‘1’.
Um die Verknüpfung nur für Süd anzeigen zu lassen, haben wir zwei Optionen:
Am einfachsten ist es, sich auf den in der gesamten Hierarchie eindeutigen, mehrteiligen Uniquename-Bezeichner [1|1] zu beziehen:
Verknüpfungen nur für Süd
Alternativ ließe sich die Eindeutigkeit auch herstellen, indem zum Key ‘1’ noch das numerische Level 1 der Ebene Regionen mit der Bedingung <dim2level> = 1 hinzugefügt wird:
Verknüpfungen nur für Süd, zweite Variante
Mehrere Elemente
Es ist auch möglich, für mehrere Elemente gleichzeitig Verknüpfungen zu erlauben.
Nun sollen Verknüpfungen für Nord und Süd sichtbar sein. Nord wird mit ‘[1|2]’ angesprochen:
Verknüpfungen für Nord und Süd
Der Befehl mit “IN” lässt sich auch für Measures anwenden. Zum Beispiel führt “<measure > IN (4,5)” in diesem Modell zur Darstellung von Verknüpfungen von Rabatt und Umsatz.
Variablen in relationalen Anwendungen der Planung
Bisher haben wir Ausdrücke gebildet, die mit einem Wert “True” eine Verknüpfung anzeigen und mit “False” nicht.
Bei der Planung lassen sich exakt die gleichen Konstruktionen verwenden, bloß bestimmen sie hier (hier: im Tab Dateneingabe der im Editiermenu sichtbaren Eigenschaften), ob auf einer Zelle eine Eingabe stattfinden kann oder nicht.
In der folgenden Grafischen Tabelle sollen Absätze (Measure-ID 0) auf der Ebene der Produktgruppen (Level 2) der Produkte (Dimensions-ID 3) geplant werden. Die Umsätze sollen sich hier automatisch über Multiplikation mit fixen Preisen ergeben und somit werden diese selbst nicht direkt geplant:
Eingabe der Absatzzahlen auf der mittleren Ebene
Mit dem Ausdruck “<dim3level> = 2 and <measure> = 0” wird das Gewünschte erreicht.
Auch in der Planung lässt sich nun somit viel genauer und einfacher steuern, auf welchen Zellen Eingaben erlaubt sein sollen.
Darüber hinaus können wir nun auch bei Zellkommentaren eine Bedingung – in der genau gleichen Form wie bisher beschrieben – hinterlegen, ob und welche Zellkommentare sichtbar sein sollen:
Zellkommentare nur für “Ist”
Ergo lassen sich nun Planungsanwendungen deutlich leichter administrieren und den eigenen Wünschen anpassen.
Variablen in relationalen Anwendungen, die sich auf die Sicht beziehen
Es ist auch möglich, sich nicht nur auf Elemente der Achsen zu beziehen, sondern auch auf die im Berichtsfilter eingestellten Elemente.
- <viewXkey> – Name des aktuellen Elementes der Dimension X in der Sicht
- <viewXlevel> – die Ebene des aktuellen Elements der Dimension X in der Sicht.
Diese Größen verhalten sich ansonsten so wie ihre Verwandten <dimXkey> und <dimXlevel>. Im folgenden Beispiel erscheinen die Verknüpfungen nur, wenn in der Sicht Vertriebler Hohlmaier ausgewählt wird.
Verknüpfungen nur für Hohlmaier sichtbar
Zum Beispiel kann dann eine per Publisher verschickte Sitzung für Hohlmaier Verknüpfungen enthalten, für Baumann nicht.
Bemerkung: Die Referenz <view5key> wird in einfache Anführungsstriche eingebettet: ‘<view5key>’.
Weitere Einschränkung: Bei einer Mehrfachauswahl in der Sicht wird nur das erste Element berücksichtigt.
Mit den neuen Variablen in relationalen Anwendungen ergeben sich so viele neue Möglichkeiten, sodass wir hier nur mögliche Richtungen andeuten wollen.
Parent-Child-Hierarchien
Liegt zum Beispiel eine Parent-Child-Hierarchie mit unterschiedlich langen Ästen vor, so können wir mit einem SQL-Ausdruck (der nun allerdings die bereits angesprochenen “vertieften” Kenntnisse voraussetzt) alle Blattelemente am Ende der Äste für Eingabe bzw. hier für Verknüpfungen aktivieren.
Unsere Tabelle “[PC]” auf dem SQL-Server möge folgendermaßen aussehen (links oben). Rechts oben sehen wir auch schon die Grafische Tabelle mit den Verknüpfungen (bzw. alternativ “möglichen Planeingaben”):
Verknüpfungen nur für Child-Elemente
Wie funktioniert der gegebene Ausdruck? Dazu müssen wir wissen, dass die Child-Dimension diejenige ist, die in DeltaMaster sichtbar ist (mit ID 0). Mit dem Befehl <dim0> lesen wir das aktuelle Element aus und schauen dann, ob es Child-Elemente gibt, die dieses Element als Parent besitzen. Für Blatt-Elemente am Ende der Äste gibt es solche Child-Elemente nicht, der SELECT-Befehl liefert keine einzige Zeile und die Negation “NOT EXISTS” wird somit wahr und wir sehen die Verknüpfung.
In diesem Beispiel ist Wert nur für Blatt-Elemente vorhanden. Über die aktivierte Aggregation (Modellieren, Hierarchieeigenschaften) ergeben sich dann aggregierte Werte auch für die übergeordneten Elemente.
Hier können Sie sich wieder eine Planungsanwendung vorstellen – zum Beispiel mit einer Kontendimension -, bei der auf den Blättern geplant wird und sich die Werte der übergeordneten Elemente durch automatische Aggregation ergeben.
Benutzerdefinierte Analysewerte
Auch die Möglichkeiten dieses Abschnitts sind in einem eigenem, nur diesem Thema gewidmeten Blog-Beitrag besser aufgehoben. Hier sei eine mögliche Anwendung beschrieben.
Angenommen, die Vertriebler Herr Hohlmaier und Frau Baumann haben sich unterschiedliche Boni-Modelle ausgehandelt. Herr Hohlmaier erhält nach Kundenumsatz gestaffelte Provisionssätze (<20000: 0 %, ≥ 500.000: 22 %, sonst 10 %) und Frau Baumann bekommt, unabhängig vom Umsatz, beim Kunden Bundesagentur für Arbeit 25 %, bei Classic Home 20 % und ansonsten 10 %.
Dann lässt sich die Logik entweder im Back-End verankern oder eben auch per Selfservice in DeltaMaster ausdrücken:
Die Definition des Provisionsanteils
Wir nehmen hier Bezug auf die Uniquenames der beiden Personen aus dem Vertrieb, der beiden mit Namen genannten Kunden und auf den gegebenen Analysewert Umsatz.
Auf der Ebene der Kunden sind diese Werte wohldefiniert und wir können eine Tabelle der Provisionen erstellen:
Übersicht der Provisionen
Natürlich ist dies nur ein Beispiel von vielen und mögliche Umsetzungen sind so zahlreich, wie es Anwendungsszenarios gibt.
