Oft werden in Projekten Attributhierarchien modelliert. Sie gehören zu einem der Schlüsselkonzepte in Analysis Services. Eine Attributhierarchie ist eine Hierarchie basierend auf Attributelementen und kann für jedes Dimensionsattribut definiert werden. Bei der Modellierung entscheiden wir uns, je nach Kundenanforderung, entweder für eine Attributhierarchie als separate Dimension oder für eine sogenannte „Parallele Hierarchie“.

Attributhierarchie als separate Dimension

Um das Verhalten von DeltaMaster bei der Verwendung von Attributhierarchien als separate Dimension zu verdeutlichen, wurde über DeltaMaster Modeler eine Material-Dimension mit weiteren Attributhierarchien erstellt:

Abbildung 1: DeltaMaster Modeler – Level attributes

Wie geht DeltaMaster und im Backend letztlich die Datenbank damit um? Im Sichtfenster sind die Hierarchien als separate Dimension ersichtlich. Das Cockpit zeigt alle Materialien.

Abbildung 2: DeltaMaster – Sicht- und Cockpitfenster

Eine beliebige Auswahl aus den Dimensionen „Material“, „Brand“, „PlanningUnit“ oder „Status“ hat zur Folge, dass die Anzahl der Elemente in der Zeilenachse beschränkt wird. Dieses Verhalten wird auch „Autoexists“ genannt. Dabei wird der Datenraum auf Zellen beschränkt, die tatsächlich im Cube enthalten sind. Also wertet Analysis Services die Ausdrücke der Attribute aus, sobald zwei oder mehr Attributhierarchien der gleichen Dimension in einer SELECT-Anweisung verwendet werden und sorgt damit für eine korrekte Beschränkung der Elemente dieser Attribute. Kurzum: Die Hierarchie-Modellierung sorgt für gültige Kombinationen der Elemente dieser Attribute.

Wird in der Dimension „Brand“ ein Element ausgewählt:

Abbildung 3: DeltaMaster – Dimensionsbrowser

Werden die Cockpit-Zeilen nur auf Materialien dieses Elements beschränkt:

Abbildung 4: DeltaMaster – Ergebnis im Cockpit

Berichtsempfänger und Komplexitätsreduzierung

Oft wünscht man sich in Datenräumen einer multidimensionalen Datenbank das gleiche Verhalten wie in einer relationalen Welt. Vor allem soll für den Berichtsempfänger eine Reduzierung der Komplexität erreicht werden. Bezogen auf den obigen Fall, soll der Anwender im Dimensionsbrowser in anderen Attributhierarchien (Material, PlanningUnit) nur die Materialen sehen, die zum Element „Brand4“ gehören. In DeltaMaster wird diese Funktionalität „Sichtkontext“ genannt, also Be-schränkung der Sicht im Kontext eines ausgewählten Elements. Der Sichtkontext befindet sich im Kontextmenü des Berichts unter dem Punkt „Berichtseigenschaften“.

Mit ein wenig MDX lässt sich diese Anforderung sehr elegant lösen:

Abbildung 5: DeltaMaster – Berichtseigenschaften

Die in der Filter-Funktion benutzten <view>-Konstrukte beziehen sich jeweils auf die Dimensionen „Brand“ und „PlanningUnit“.
Nach Umschalten von DeltaMaster in den Viewer-Modus werden im Dimensionsbrowser der Dimension „Material“ nur noch Elemente der Gruppe „Brand4“ der Dimension „Brand“ angezeigt:

Abbildung 6: DeltaMaster – Dimensionsbrowser

Diese „Anwendungslogik“ hilft dem Anwender, dass hier nichts schiefgehen kann. Nicht sinnvolle
Kombinationen stehen von vornherein nicht zur Auswahl.

Eine Mehrfachauswahl der Brands führt allerdings zu einem Fehler. Wünschenswert wäre das vorhin beschriebene Autoexists-Verhalten auch hier. Und in der Tat kann mit Hilfe der MDX-Funktion „Exists“ auch diese Anforderung gemeistert werden. „Exists“ führt die Operationen manuell aus, die Autoexist automatisch ausführt:

Abbildung 7: DeltaMaster – Berichtseigenschaften

Im Viewer-Modus beschränkt sich nun die Dimension „Material“ automatisch auf die existierenden Elemente der Dimension „Brand“:

Abbildung 8: DeltaMaster – Dimensionsbrowser

Parallele Hierarchie

Wie gehen wir nun mit parallelen Hierarchien um? Zur Veranschaulichung wurde folgendes Szenario modelliert:

Abbildung 9: DeltaMaster – Dimensionsbrowser

Zusätzlich zur Material-Dimension existiert eine parallele Hierarchie mit der Klassifikation der Materialien in Bronze, Gold und Silber.

Bei der Nutzung von parallelen Hierarchien ist zu beachten, dass die in der Sicht ausgewählte Hierarchie mit der im Cockpit verwendeten Hierarchie übereinstimmt. Ansonsten wird folgendes Verhalten beobachtet:

Abbildung 10: DeltaMaster – Standardverhalten bei parallelen Hierarchien

Im Sichtfenster wurde die Hierarchie eingeklammert. Der Bericht liefert alle Materialien und
vernachlässigt die Sichtselektion, also den Status „Bronze“. Um hier das richtige Ergebnis zu erhalten, ist in der Achsendefinition der Zeile die Hierarchie „Material“ auf „Status_Dim“ zu ändern.

Und auch hier gibt es tatsächlich eine elegantere Lösung, um die Achsendefinition dynamisch auf die ausgewählte Hierarchie aus dem Sichtfenster zu ändern. MDX sei Dank:

Abbildung 11: DeltaMaster – Dynamik im Bericht bei parallelen Hierarchien

Die Dimension steht im Sichtfenster nicht mehr in Klammern. Die Hierarchie in der Achsendefinition zeigt zwar auf die Material-Hierarchie, dennoch erledigt den Rest der MDX-Ausdruck und der Bericht liefert die richtigen Elemente.

Grenzen

Obwohl die Aliase der parallelen Hierarchie aktiviert sind, werden sie wie oben ersichtlich nicht
angezeigt. Anders verhält es sich mit Aliasen der Material-Hierarchie. Eine Lösung mit Hilfe von MDX sollte nicht angestrebt werden, da hierbei mit vielen „IF“-Bedingungen gearbeitet werden müsste.

Standardlösung

Und auch in diesem Fall bietet DeltaMaster eine Standardlösung. Die Aktivierung der Option „Bei Sichtwechsel zwischen parallelen Hierarchien Cockpits und Berichte anpassen“ über das Menü „Extras – Optionen“ erledigt das Umschalten der Hierarchien im Cockpit sowie die Benutzung der Aliase völlig automatisch:

Abbildung 12: DeltaMaster – Extras – Optionen