Wir bekommen immer wieder die Anforderung, dass gewisse Strukturen in unseren Modellen nicht ausgewogen sind und aus diesem Grund als Parent-Child-Dimension modelliert werden müssen. Unser DeltaMaster-Modeler ist auf solche Anforderungen sehr gut vorbereitet – das Modellieren einer Parent-Child-Dimension geht schnell von der Hand.
Eine Besonderheit solcher Parent-Child-Dimensionen ist, dass auch auf Knotenebene Werte physisch gespeichert werden können. Kein anderer Dimensionstyp bietet diese Fähigkeit.
Wie die physisch auf Knoten vorhandenen Werte auch richtig angezeigt werden und wie das passende Modell aufbaut werden muss, zeigt dieser Blogbeitrag.

Ausgangssituation

In unserem kleinen Beispielmodell haben wir eine nicht ausgewogene Verkaufsorganisation:

Abbildung 1: Verkaufsorganisation

Weiterhin wird im Unternehmen ein komplexes Scoring gebildet, welches Werte zwischen 0 und 100 annehmen kann – auf jeder Ebene der Verkaufsorganisation. Die Berechnung der Werte erfolgt außerhalb von DeltaMaster – schade, weil dies mit einem ausgeklügelten MDX sicher auch zur Laufzeit gelöst werden könnte. Aber hier soll in erster Linie eine schicke Anzeige realisiert werden.

Modellierung der Dimension „Verkaufsorganisation“

In der Modeler-Sitzung wird die Dimension Verkaufsorganisation vom Typ ParentChild angelegt. Handelt es sich um eine zuvor nicht vorhandene Dimension, übernimmt Modeler ein paar wichtige Hand-griffe, die uns im Nachgang die Modellierungsarbeit wesentlich erleichtern und unter Umständen verhindern, dass etwas vergessen wird. Wie üblich können Eingaben durch Vorgabewerte „abgekürzt“ werden.

Der Bericht Level wird vorbefüllt, so dass nichts geändert werden muss – außer vielleicht der Name der Ebene. Mehr wird hier nicht benötigt.

Auch der Bericht Level Attributes ist durch die Vorbefüllung fertig gestellt. Das Resultat in den Metadaten unseres kleinen Modells ist im folgenden Bild dargestellt.

Abbildung 2: Einstellung der Level attributes für eine Parent-Child-Dimension

Wurden alle weiteren Modellierungsarbeiten sachgerecht ausgeführt, kann sich kurze Zeit später bereits mit DeltaMaster auf die fertige Datenbank verbunden und das Ergebnis bestaunt werden:

Abbildung 3: Auswertung Scoring nach Standardmodellierung

Die Werte werden aufaggregiert und die Werte auf den Knoten werden als erstes Kind dargestellt – aber nicht in die Aggregation einbezogen. Für Kontrollzwecke ist diese Darstellung schon einmal nicht verkehrt, leider entspricht sie noch nicht der Anforderung. Zudem werden Anwender regelmäßig durch das doppelte Erscheinen der Knotenelemente irritiert. Die Verdichtungen passen zu den Werten der darunter liegenden Ebene – aber laut Anforderung soll nicht verdichtet werden. Deshalb wird die Dimension Verkaufsorganisation noch einmal überarbeitet.

Überarbeitung der Dimension Verkaufsorganisation

Ausblendung der zusätzlichen Knotenelemente

Zuerst werden die Datenelemente der Knoten entfernt, indem man im Bericht Level attributes die Einstellung im Feld Members w. Data (PC) wie im Bild gezeigt umgestellt:

Abbildung 4 Ausblenden der zusätzlichen Knotenelemente

Wurde die Umstellung erfolgreich durchgeführt und das Modell neu erzeugt, ergibt sich folgende Darstellung:

Abbildung 5: Darstellung des Scorings nach Ausblendung

Auffällig ist beim Betrachten, dass sich die Werte auf den Knoten nicht verändert haben – scheinbar passen die Verdichtungen auch nicht mehr zu den Elementen auf der darunter liegenden Ebene. Da wir die doppelten Knotenelemente zuvor gesehen haben, wissen wir woher der „Fehler“ kommt. Jetzt müssen wir es nur noch schaffen, die Werte der nicht mehr sichtbaren Knotenelemente auf die Knotenelemente selbst zu projizieren.

Übernahme der Werte

In den beiden Artikeln von Microsoft Parent Child Dimensions und Attributes in Parent-Child Hierarchies werden die dazu gehörenden Zusammenhänge beschrieben. Die Übernahme der Knotenwerte auf die Verdichtungselemente erfolgt mit Hilfe eines CustomRollUp-Attributs und mit Hilfe der MDX-Funktion DataMember.

Abbildung 6: Das CustomRollUp-Attribut

Zu beachten ist allerdings, dass die CustomRollUp-Funktion nur auf Verdichtungen in der Dimension angewandt oder besser befüllt werden darf, da sonst die Scoringwerte auf den Basiselementen nicht dargestellt werden (vgl. Blog http://crew.bissantz.de/unaryoperators-und-customrollupcolumns – hier wird das Verhalten ausführlich beschrieben):

Abbildung 7: CustomRollUp auf allen Elementen der Parent-Child Dimension

In der Abfrage zum Aufbau der Dimension wird eine weitere Spalte eingefügt, die den kompletten MDX-Ausdruck für alle Verdichtungselemente enthält. Somit ergibt sich nach dem erneuten kompletten (Neu-)Aufbau der Datenbank folgendes Bild:

Abbildung 8: Korrekte Darstellung der Werte

Perfekt! Das Ergebnis unser Bemühungen ist die korrekte Darstellung der Scoringwerte über die Ver-kaufsorganisation.

Fazit und weitere Überlegungen

Durch das CustomRollUp-Attribut und dessen richtige Befüllung mit der MDX-Funktion DataMember wird die gewünschte Darstellung der Scoringwerte entlang der Hierarchie der Verkaufsorganisation model-liert. Wichtig ist auch eine korrekte Darstellung des Scorings im Zeitverlauf. Dabei muss beachtet wer-den, ob immer alle Scorewerte ermittelt werden oder ob es vielleicht nur teilweise neue Scorings gibt. Die Kennzahl Score im Beispielmodell ist als LastNonEmpty definiert. Die Sorgen und Nöte in Bezug auf LastNonEmpty sind in den Blogbeiträgen „Die LastNonEmpty-Aggregation“ und „Was nicht passt, wird passend gemacht“ beschrieben und sollten beachtet werden.