Das Konzept Online Analytical Processing (OLAP) und die Technologie multidimensionaler Datenbanken existiert seit inzwischen etwa zwei Jahrzehnten und spielt bei Softwarelösungen im Bereich Business Intelligence (BI) in vielen Fällen eine tragende Rolle hinsichtlich der eingesetzten Backends.

Stupide Aggregationsmaschinen

Eine wesentliche Stärke von OLAP-Datenbanken liegt in ihrer Fähigkeit, große Mengen quantitativer Informationen (Measures) entlang praktisch beliebig vieler Merkmale (Dimensionen/Attribute/Hierarchien) bei hoher Abfrageperformance zu aggregieren – je nach Technologieanbieter unter Zuhilfenahme von Vorkalkulations- und weiterer Optimierungsmechanismen. Plakativ betrachtet handelt es sich also um äußerst leistungsfähige, aber im Grunde stupide Additionsmaschinen. Für einen großen Teil der typischen Anwendungsfälle von BI-Systemen vornehmlich in den Gebieten Vertrieb und Marketing ist dies völlig ausreichend, denn beispielsweise Absatz- oder Umsatzzahlen dürfen zumeist über sämtliche denkbare Merkmale addiert werden, um korrekte Resultate zu erzielen.

Sobald jedoch Situationen eintreten, in denen die fachlichen Anforderungen über derartig generische Rechenvorgaben hinausgehen, entsteht die Notwendigkeit, in unterschiedlichem Umfang und Komplexität explizite Regeln zu erfordern: Spezielle Aggregationsvorschriften für einzelne Measures, benutzerdefinierte Kennzahlen und Elemente, Berechnungen mit Gültigkeit nur in Teilbereichen (“Scope-Formeln”) sind nur einige Beispiele. Allen diesen Abweichungen vom OLAP-Normverhalten ist gemein, dass sie initial und fortlaufend zumeist manuell definiert werden müssen und zudem tendenziell negative Auswirkungen auf die Abfrageperformance haben.

Gerade bei umfangreicheren Kennzahlenschemata oder Kontenstrukturen mit komplexeren Zusammenhängen als rein hierarchische Summation ergibt sich ein mitunter beträchtlicher Pflegeaufwand für die entsprechenden Rechenregeln. Konkret kann es hierbei erforderlich sein, in bestimmten Dimensionen für jedes einzelne Element eine eigene Regel zu definieren. In diesem Zusammenhang liefert Microsoft Analysis Services zwei wertvolle Lösungsansätze: unäre Operatoren (“Unary Operators”) und benutzerdefinierte Aggregationsvorschriften (“Custom Rollup Operators”).

Beide Konzepte sind im Zuge der Modellierung sehr einfach anzuwenden. Kurzfristig werden sie auch in DeltaMaster Modeler verfügbar sein (voraussichtlich bereits in Release 2.11). Bis dahin können als Workaround manuell Elementattribute angelegt werden und diese anschließend in Microsoft SQL Server Business Intelligence Development Studio (BIDS) der entsprechenden Eigenschaft eines anderen Attributs zugeordnet werden.

Als Beispiel für die folgenden Ausführungen soll ein einfaches Szenario mit zwei Dimensions- und einer Faktentabelle dienen:

Unary Operators

Unäre Operatoren dienen beispielsweise bei der Modellierung von Kontendimensionen (z.B. innerhalb einer Gewinn- und Verlustrechnung) der Definition des Aggregationsverhaltens der einzelnen Elemente (Konten). Beispielsweise sollen verschiedene Ertragspositionen addiert, Kosten jedoch subtrahiert werden. Beteiligungen könnten nur zu einem definierten Prozentsatz, “Davon-Posten” gar nicht in die Aggregation einbezogen werden.

Die Verwendung ist nur in Parent-Child-Dimensionen möglich. Erlaubte Operatoren sind:

• + Addition (Standard)
• –  Subtraktion
• * Multiplikation
• / Division
• ~ keine Berücksichtigung
• n quotale Berücksichtigung

Der BIDS-Dimensionsbrowser zeigt für alle Elemente mit vorhandenen UnaryOperatorColumns das entsprechende Symbol des Operators an, bei quotaler Berücksichtung zusätzlich zwischen Symbol und Elementtext den angegebenen Wert:

Die Wirkung erfolgt vom Element (Child) aus über dessen Eigenschaft “UnaryOperatorColumn” auf die nächsthöhere Ebene (Parent). Anzugeben ist schlicht der jeweilige Operator für Addition, Subtraktion, Multiplikation oder Division, eine Tilde, wenn der Wert nicht aggregiert werden soll, oder ein beliebiger numerischer Wert in englischer Notation (Dezimalpunkt, z.B. 0.5 für 50%) für eine anteilige Aggregation. Alle Elemente, die keinen Wert für die UnaryOperatorColumn in der Datenquelle aufweisen, werden per Default addiert.

Custom Rollup Operators

Benutzerdefinierte Aggregationsvorschriften eröffnen noch weitaus mehr Flexibilität: Die Verwendung ist generell, also in regulären und in Parent-Child-Dimensionen möglich. Die Wirkung erfolgt im Gegensatz zu unären Operatoren auf das Element, dessen Eigenschaft “CustomRollupColumn” einen Wert aufweist, selbst. Als Syntax für diese Eigenschaft dienen beliebige MDX-Formeln mit Referenz auf Elemente (Member), Tupel etc. Ein Beispiel für das Element “[Konten].[Kontenhierarchie].[Deckungsbeitrag 1]” wäre etwa:

[Konten].[Kontenhierarchie].[Umsatz] – [Konten].[Kontenhierarchie].[Materialkosten]

Wiederum zeigt der BIDS-Dimensionsbrowser für alle Elemente mit vorhandener CustomRollupColumn ein Funktionssymbol an:

Auch hier werden alle Elemente, die keinen Wert für die CustomRollupColumn in der Datenquelle aufweisen, per Default addiert.

Abschließend ein praktischer Hinweis: Beispielsweise können in Excel-Quelldaten die Zellbezugformeln bei Verwendung der Zeilennummern als Element-IDs mit nur wenigen Anpassungen als CustomRollupColumns dienen, wenn in den Excel-Formeln das Gleichheitszeichen entfernt und die Zellbezüge mittels Suchen/Ersetzen durch die MDX-Minimalnotation “[<ElementID>]” ersetzt werden. Hier ein Beispiel:

Das hier gezeigte Beispielszenario für SQL Server Analysis Services 2005 stellen wir auf Anfrage gerne bereit.