Eine häufige Frage in Kundenprojekten ist, ob und wie durch den DeltaMaster-Anwender innerhalb existierender Dimensionen individuelle (Zwischen-)Summen oder Gruppierungen definiert werden können, die in den Stammdaten der Quellsysteme nicht existieren. Hierzu gibt es mehrere recht einfache Möglichkeiten, die je nach Anwendungsfall genutzt werden können. Spannend wird es vor allem dann, wenn Elemente in mehreren Summen oder Gruppen vorkommen sollen.
Der Trivialfall: berechnete Elemente
DeltaMaster erlaubt es dem Anwender ab der Benutzerstufe Pivotizer, berechnete Elemente anzulegen. Sollen beispielsweise mehrere Kunden aus unterschiedlichen Regionen in mehreren Auswertungen zu einer Summe zusammengefasst werden, reicht die Definition eines berechneten Elements („Calculated Member“) im Dimensionsbrowser:
Abb. 1: Berechnete Elemente im Dimensionsbrowser
Abb. 2: Editor für berechnete Elemente
Die Vorteile dieser Variante sind die einfache Definition durch den Anwender direkt in DeltaMaster und die ebenso einfache Nutzung als Filter in der Sicht oder in Cockpits/Berichten – ganz wie mit existierenden Elementen. Mitunter als Nachteil empfunden wird der Umstand, dass für berechnete Elemente keine „Zerlegung“ der Summe per Drill-down (Plus-Symbol) möglich ist.
Ring frei zur nächsten Runde: benutzerdefinierte Hierarchien
Genau diese Zerlegung der Gruppierungen in ihre Bestandteile ist in DeltaMaster auf der Stufe Miner mit benutzerdefinierten Hierarchien möglich. Die Elemente einer gesamten Dimensionsebene werden dabei in zwei oder mehrere Cluster eingeordnet. Dies kann auf unterschiedliche Weise erfolgen:
- mit Hilfe von Analyseverfahren (Rangfolge, ABC-Analyse, Portfolio, Verteilungsanalyse etc.):
Nach Ausführung der jeweiligen Analyse kann das Ergebnis als „virtuelle Hierarchie“ in die Dimension zurückgeschrieben werden und bleibt in der Analysesitzung bzw. Anwendung im Repository erhalten.
Abb. 3: Virtuelle Hierarchie aus Analyseergebnis erstellen
Abb. 4: Auswahl der virtuellen Hierarchie im Dimensionsbrowser
2. auf der Basis von Elementeigenschaften:
Sind in der betroffenen Dimension bereits geeignete Elementeigenschaften (Attribute, MemberProperties) vorhanden, kann die gewünschte Klassifikation direkt in DeltaMaster nachträglich angelegt werden. Ein entsprechender Menüeintrag hierfür findet sich im Dimensionsbrowser:
Abb. 5: Hierarchie aus Elementeigenschaft erstellen
3. durch individuelle Auswahl:
Völlig freie, von statisch oder dynamisch definierten Merkmalen unabhängige Klassifikationen sind durch einfache Multiselektion von Elementen einer Dimensionsebene im Dimensionsbrowser möglich. Im ersten Schritt entstehen zwei Klassen, „Auswahl“ und „Restklasse“. Nachträglich können mit Hilfe des Kontextmenüs beliebig viele zusätzliche Klassen erstellt und Elemente zwischen den Klassen verschoben werden.
Abb. 6: Zusätzliche Klassen erstellen
Allen Varianten dieses Ansatzes gemein ist die „Spielregel“, dass alle Elemente einer Dimensionsebene gruppiert werden müssen, d. h. Elemente dürfen weder weggelassen noch mehrfach zugeordnet werden, und die Klassifikation darf keine Elemente unterschiedlicher Ebenen enthalten.
Wenn einmal nicht genug ist: multiple Gruppierung über m:n-Zuordnungen
Was ist nun aber zu tun, wenn die Aufgabenstellung genau dies, die multiple Klassifikation einzelner Elemente, erfordert? Ein Beispiel: Kunden, die in der Basishierarchie geographisch gemäß der vertrieblichen Zuordnung strukturiert sind, sollen zusätzlich Verbänden zugeordnet werden. Das delikate Detail: Es gibt Regionalverbände, Branchenverbände und vieles mehr, und jeder Kunde kann keinem, einem einzigen oder mehreren Verbänden angehören. Die Analyse soll flexibel nicht nur über die ursprüngliche Hierarchie möglich sein, sondern es soll nach Verbänden gefiltert werden können, und das gesamte Zahlenmaterial soll auch die Verbands(zwischen)summen liefern. Doppelzählungen sind dabei selbstverständlich unbedingt zu vermeiden.
Hier ist ein kleiner Trick im OLAP-Datenmodell gefragt. Einmal mehr hilft uns Microsofts genialer Ansatz der m:n-Beziehungen. Basis ist eine einfache zweispaltige Tabelle in der Datenbank, in der die Zugehörigkeit von Kunden zu Verbänden gespeichert ist.
Abb. 7: Tabelle mit m:n-Beziehungen
Das Beispiel zeigt, dass die Kunden „Albert & Albert“ sowie „Allberg Sys“ Mitglied in jeweils zwei Verbänden sind.
Mit der obigen Tabelle wird im Datenmodell eine sogenannte Bridge-MeasureGroup angelegt. Diese dient anschließend der Verbindung der existierenden MeasureGroups mit der neuen Dimension Verband.
Die Pflege der Verbandszugehörigkeit kann durch den Anwender erfolgen, beispielsweise in einer relationalen DeltaMaster-Eingabeanwendung. Mit Hilfe der DeltaMaster-CustomApp kann per Zusatzmenü die sofortige Aktualisierung der Dimension erzielt werden.
Hier das gewünschte Ergebnis:
Abb. 8: Ergebnis der Pflege zur Verbandszugehörigkeit
Der Kunde „Albert & Albert“ ist unter zwei Verbänden sichtbar, die Summe aller Verbände zählt den Umsatz des Kunden von 4.503 EUR jedoch nicht zweimal. Die Umsatzsumme aller Verbände von 16.661.602 EUR ist nicht die Summe der darunter angezeigten Verbände, da nicht alle Kunden Verbänden zugeordnet sind.
