Die Definition und Strukturierung von Merkmalen, häufig in Form von Hierarchien, ist einer der zentralen Aspekte der multidimensionalen Modellierung. In den meisten Fällen handelt es sich dabei um „balancierte“ Strukturen, d.h. der Detaillierungsgrad ist bei allen Ausprägungen gleich tief, weshalb man auch von symmetrischen Hierarchien spricht. Ein allgegenwärtiges Beispiel dafür ist das Merkmal Zeit in der typischen Struktur „Jahr-Quartal-Monat-Tag“: Jeder Tag kann eindeutig einem Monat zugeordnet werden, dieser wiederum einem Quartal und letzteres schließlich einem Jahr. Ähnlich verhalten sich die meisten Produkthierarchien, wenn sie beispielsweise in Haupt- und Unterwarengruppen gegliedert werden. Die Basisdaten zum Aufbau solcher Hierarchien werden meist in tabellarischer Form, also spaltenweise, bereitgestellt. Gerade in SQL-Tabellen oder auch Access- oder Excel-Dateien ist diese Eigenschaft derart selbstverständlich, dass sie meist gar nicht erwähnt oder auch nur bedacht wird. Der OLAP-Jargon spricht in diesem Kontext von regulären Dimensionen.

Was aber, wenn ein Anwendungsfall „unbalancierte“, also asymmetrische Strukturen beinhaltet? Konkret formuliert: Wie ist vorzugehen, wenn z.B. eine Organisationsstruktur abgebildet werden soll, die zwar im Inland über Regionen und Gebiete bis zu einzelnen Vertriebsniederlassungen verzweigt (also drei Ebenen tief ist), in den europäischen Ländern aber nur Regionalbüros existieren (zwei Ebenen) und im Rest der Welt sogar lediglich Landeszentralen (eine Ebene)? Wie ist mit beliebig tiefen Kontenstrukturen (Kostenartenbaum) oder Materialstücklisten wie in der Produktion üblich zu verfahren?

Abstrahiert betrachtet sind in derartigen Situationen vor allem folgende Umstände gegeben:

• Die einzelnen Zweige der Hierarchie sind unterschiedlich tief verzweigt.
• Die Dimension hat unter Umständen unvorhersehbar viele Ebenen.
• Die eindeutige Benennung der Ebenen ist möglicherweise schwierig oder unmöglich.
• Die Bereitstellung der zugehörigen Basisinformationen in tabellarischer Form ist ineffizient, oder die Rohdaten liegen in Form von Stücklisten vor, die aufgrund ihres im Allgemeinen zweispaltigen Aufbaus nach der Logik “x gehört zu y” bzw. “y besteht aus x” auch als Parent-Child-Listen bezeichnet werden.

Microsoft Analysis Services kennt zwei unterschiedliche Konzepte zum Umgang mit den oben beschriebenen Fällen: Parent-Child-Dimensionen und Ragged Dimensions. Das Endergebnis sieht für den Anwender im Idealfall unabhängig von der Anwendung des einen oder anderen Ansatzes identisch aus, doch in (speicher-)technischer und prozessoraler Hinsicht unterschieden sich beide gravierend.

Parent-Child-Dimensionen

„Echt asymmetrische“ Hierarchien werden in Analysis Services als Parent-Child-Dimensionen (PC) modelliert. Hierzu wird für eines der Dimensionsattribute die „Type“-Eigenschaft auf die Einstellung „Parent“ gesetzt. Dabei ist grundsätzlich nur ein Parent-Attribut pro Dimension erlaubt, es kann also nur eine PC-Hierarchie pro Dimension definiert werden. Zusätzlich dürfen beliebig viele weitere reguläre Attribute/Hierarchien existieren.

Das Importformat für PC-Hierarchien sind stücklistenartige zweispaltige Tabellen, aus denen die Beziehung eines jeden Elements (Child) zum jeweils übergeordneten Element (Parent) hervorgeht. Damit kann eine beliebige Hierarchietiefe abgebildet werden. Zudem ist bei Bedarf die Verwendung sogenannter „unärer Operatoren“ für elementweise Berechnungen möglich. Hierzu wird die gewünschte Operation (Addition, Subtraktion, %-Quote etc.) einfach durch eine weitere Spalte angegeben. Weitere Details zu dieser Funktionalität sind in einem separaten Blog-Artikel („Unäre Operatoren und Custom Rollup Formulas“ von MAN) beschrieben.

PC-Hierarchien haben jedoch auch Nachteile:

• Da die in Analysis Service bedeutsame Ebenensemantik per Definition nicht existent ist und diverse Optimierungsalgorithmen ebenenbasiert sind, sind sie grundsätzlich schlecht(er) optimierbar. Daher resultiert auch die im Analysis Services Performance Guide zu findende Faustregel, nach der nicht mehr als zwei PC-Dimensionen pro Cube verwendet werden sollten.
• Ebenenbasierte Operationen im Frontend sind schwieriger durchführbar bzw. interpretierbar. Begriffe wie „Land-Region-Gebiet“ sind besser verständlich als neutrale Bezeichnungen wie „Vertrieb1-Vertrieb2-Vertrieb3“, die in PC-Hierarchien zwingend sind. Gut zu wissen, dass bei der Verwendung von DeltaMaster zumindest die Rechenlogik auch bei Operationen auf unvollständigen Ebenen erhalten bleibt, denn beispielsweise beim Ranking werden fehlende Details durch intelligent generierte MDX-Statements automatisch durch Elemente der nächsthöheren Ebene(n) aufgefüllt, so dass das Ergebnis sich stets zu 100% addiert.
• Auch Berechtigungen werden auf Attributebene (d.h. in der Regel ebenenweise) definiert, was sich bei PC-Dimensionen ebenfalls schwierig gestaltet.
• Sofern die Rohdaten nicht bereits als Stückliste vorliegen, zieht die Konvertierung meist Programmieraufwand nach sich.

Ragged Dimensions

Als Alternative zu „echten“ PC-Dimensionen bieten sich „quasi-asymmetrische“ Strukturen an, die zwar in technischer Sicht wie reguläre Dimensionen streng ebenenbasiert sind, durch Ausblenden von Teilästen jedoch unbalanciert aussehen. Derartige Dimensionen werden in Analysis Services als Ragged Dimensions bezeichnet. „Ragged“ wird wörtlich zwar mit „lumpig“ übersetzt, was in Seminaren immer wieder für Verwunderung oder Gelächter sorgt, doch ist ein „Ragged Type“ auch ein Flattersatz, also der typographische Fachbegriff für links- oder rechtsbündige Ausrichtung im Gegensatz zum Blocksatz. Dieses Bild verdeutlicht gut das Grundkonzept: Sowohl in den Rohdaten als auch in der Dimension können am rechten Rand Lücken existieren.

Die Umsetzung in der Praxis erfolgt innerhalb der Dimensionshierarchien mit Hilfe der Ebeneneigenschaft „HideMemberIf“. Neben der Voreinstellung „Never“ für reguläre Dimensionen existieren vier weitere Optionen, von denen die beiden am häufigsten eingesetzten „NoName“ (kein Text) oder „ParentName“ (Text identisch wie der des übergeordneten Elements) sind. Im Ergebnis sieht die Hierarchie also nach PC aus, verhält sich technisch jedoch genauso wie eine reguläre Dimension – und genauso performant!

Die Vor- und Nachteile von Ragged Dimensions sind generell umgekehrt zu PC-Dimensionen, d.h. für sie sprechen vor allem gute Optimierbarkeit und uneingeschränkte Ebenensemantik. Wiederum ist zu berücksichtigen, dass dann, wenn die Rohdaten als Stückliste vorliegen, das tabellarische Format mitunter nur mit Programmieraufwand erzeugt werden kann (vgl. hierzu den ebenfalls separaten Blogartikel “Flachklopfen” von SAJ).

Entscheidungsregeln

Wann sollte also welche Variante zum Einsatz kommen? Aus technischen Gründen scheint vieles für Ragged Dimensions zu sprechen, aus fachlicher Sicht sind PC-Dimensionen jedoch oft unabwendbar. Abschließend eine kleine Checkliste zur Entscheidungsfindung.

• Ist die maximale Hierarchietiefe unbekannt?
  Dieser Umstand spricht für eine PC-Dimension, denn ansonsten müssten entweder Dummy-Ebenen „auf Halde“ angelegt werden oder die Dimension nachträglich erweitert werden.
• Liegen die Rohdaten als Stückliste vor?
  Auch dann bietet sich eine PC-Dimension an, denn wie oben erwähnt, ist die automatisierte (d.h. im regelmäßigen Datenbewirtschaftungsprozess wiederholbare) Konvertierung einer Stückliste in Tabellenform nicht trivial.
• Sind elementweise Rechenregeln (z.B. keine, negative oder quotale Aggregation) erforderlich?
  Idealerweise kommen hierzu unäre Operatoren zum Einsatz, und diese sind nur in PC-Hierarchien möglich. Vorsicht: Das alternative Konzept der Custom Rollup Formulas, die auch in regulären Dimensionen verfügbar sind, arbeitet mit genau entgegengesetzter Logik. Näheres hierzu siehe im oben erwähnten Blog-Artikel.
• Sollen hierarchische Kennzahlen abgebildet werden (z.B. Kontenstrukturen)?
  Hierbei handelt es sich wiederum um einen klassischen Anwendungsfall für eine PC-Dimension in Kombination mit einer Dummy-Measure („Saldo“).
• Ist die maximale Gliederungstiefe der Hierarchie vorhersehbar, d.h. die Anzahl der Ebenen bekannt, und es existieren nur stellenweise Äste geringerer Tiefe?
  Dann kann das gewünschte Resultat meist einfacher als Ragged Dimension erzielt werden.

Fazit: Ist die Verwendung einer PC-Hierarchie nicht aufgrund spezifischer Anforderungen zwingend erforderlich, dann sollte die Entscheidung im Zweifelsfalle immer für eine Ragged Dimension fallen.