Im Alltag eines BI-Consultants trifft man durchaus häufiger auf Anforderungen, die sich, stark vereinfacht, alle auf eine mathematische Formel reduzieren lassen: Eine Summe von Produkten. So sind z.B. alle Währungsumrechnungen mathematisch formulierbar: erst müssen alle Werte durch eine Multiplikation mit Währungsumrechnungen auf eine Währung umgerechnet werden, dann kann man diese summieren.

In einem der Projekte, in denen wir z.Z. arbeiten, gibt es noch einen anderen Fall von ‚Summen von Produkten‘: Das ERP-System des Kunden verwaltet die Geschäfte in einer Reihe von Gesellschaften. Die Auswertungen sollen aber häufig nicht für eine Gesellschaft vorgenommen werden, sondern für einen Fonds. Dabei haben Fonds bestimmte Anteile an den Gesellschaften. D.h. bevor die Aggregation der Werte erfolgen kann, muss der Anteil des Fonds an der entsprechenden Gesellschaft einfließen.

Für solche Szenarien verwenden wir (wieder: grob vereinfacht!) zwei Lösungen:

• Wenn möglich (d.h. wenn dadurch nicht zu viel neue Datensätze entstehen), werden sämtliche Kombinationen relational berechnet und im Würfel zur Verfügung gestellt. Wenn z.B. alle Werte in einer Währung (Konzern-Währung) zur Verfügung gestellt werden müssen, kann jeder Quelldatensatz zweimal in den Würfel geladen werden: einmal in der Ursprungswährung und einmal in der Konzern-Währung. Nachteil dieser Methode ist das Aufblähen der OLAP-Datenbank, schließlich verdoppelt sich in diesem Beispiel der Datenbestand. Soll noch in weitere Währungen umgerechnet werden, entsteht sogar ein Kreuzprodukt, das diese Lösung gänzlich unbrauchbar machen kann.
• Auf der anderen Seite besteht die Möglichkeit, diese Berechnung im serverseitigen MDX-Script durchzuführen. Die Gesellschaft-Fonds-Problematik wurde z.B. auf diese Weise umgesetzt. Hier sind zwei Probleme aufgetreten: Erstens kann solch eine Berechnung äußerst langsam sein und zweitens muss der Platz des entsprechenden Scopes im MDX-Script sorgsam gewählt werden, da bei Scopes die Reihenfolge im MDX-Script wichtig ist, nicht, wie bei Create-Member-Anweisungen, die Solve_Order.

Für solche Situationen wird von Microsoft noch ein weiterer Weg vorgeschlagen, den wir hier skizzieren möchten. Auch wenn dieser Weg auf den ersten (und wohl auch zweiten) Blick recht sperrig wirkt, kann man nur empfehlen, diesen Weg in Betracht zu ziehen. Er kommt ohne größeren zusätzlichen Speicherbedarf aus und die Berechnung ist schneller als die im serverseitigen MDX-Script.

Im Mittelpunkt der Lösung steht die Möglichkeit, beim Erstellen neuer Measures nicht auf eine Spalte der Quelltabelle der Measuregruppe zu verweisen, sondern einen Berechnungsausdruck (measure expression) anzugeben. Dieser Berechnungsausdruck hat aber starke Einschränkungen, die dieses Feature als recht unpraktisch erscheinen lassen:

• Die Berechnung muss eine Multiplikation oder Division sein.
• Es müssen zwei Measures bei der Berechnung verwendet werden.
• Dabei muss eine Measure aus der gleichen Measuregruppe sein.
• Die andere Measure muss von einer anderen Measuregruppe sein.
• Diese andere Measuregruppe muss als ‘Brücken-Measuregruppe’ in einer m:n-Beziehung zwischen einer Dimension und der eigentlichen Measuregruppe eingestellt sein.

Tatsache ist, dass sich aus diesen Bedingungen ergibt, dass die ‘measure expression’ nur für die hier vorgestellten Szenarien sinnvoll ist und tatsächlich auch ausschließlich dafür in SSAS eingebunden wurde.

Beispiel der Implementation

Im Beispiel wird die weiter oben erwähnte Anforderung der Fonds und Gesellschaften (Buchungskreise) auf die ‘measure expression’ – Lösung umgestellt.

1. m:n-Beziehung herstellen.

Ausgangspunkt sind zwei bereits eingestellte Measuregruppen: Werte aus der Finanzbuchhaltung (FIBU_MO) und die Beteiligungsverhältnisse der Gesellschaften an den Fonds (Beteil_Verh). Wie man sieht, gibt es keine Verbindung der Werte aus der Finanzbuchhaltung zu den Fonds. Die FiBu-Werte sind in der Dimension Mietobjekt den Mietobjekten zugeordnet, das Schlüsselelement der Dimension, in der auch die Gesellschaften (Buchungskreise) als höhere Ebene implementiert sind. Die Beteiligungsverhältnisse haben Verknüpfungen zu Fonds und Buchungskreisen.

Diese Situation erfüllt alle Bedingungen, um die FiBu-Werte über eine m:n-Beziehung zu den Beteiligungsverhältnissen an die Dimension Fonds anzubinden.

Durch Klick in das Feld mit den ‚Koordinaten‘ Dimension ‚Fonds‘ und Measuregruppe ‚FIBU_MO‘ erscheint das Fenster ‚Beziehung definieren‘. Hier wird auf Beziehungstyp m:n gestellt und als Zwischenmeasuregruppe ‚Beteil_Verh‘ ausgewählt.

2. Neue Measure erstellen.

Rechter Mausklick auf die Measuregruppe  -> Neues Measure -> Quellspalte der Quellmeasure für die measure-expression – Measure erneut auswählen (also hier: Betrag_MO, obwohl es schon eine Measure Betrag_MO gibt.)

Wir haben die vorhandene Measure in ‚Betrag_MO_ori‘ umbenannt und die neue bekommt den alten Namen ‚Betrag_MO‘. Auf diese Weise wird in DeltaMaster automatisch ab jetzt die neue Measure verwendet. Das ist sinnvoll, wenn die meisten bisherigen Auswertungen auch auf die Fonds-Dimension verweisen. Ansonsten sollte man eher den Namen der originalen Measure beibehalten und die neue vielleicht ‘Betrag_MO_Fonds’ nennen.

In Auswertungen, wo die Dimension Fonds unberücksichtigt bleibt (also auf ‘Alle Fonds’ fest eingestellt wird), ist die originale Measure performanter als die measure-expression Measure.

In den Eigenschaften der neuen Measure in ‚MeasureExpression‘ wird noch die Formel eingetragen. Dies ist ein sehr einfacher Editor, ohne Eingabehilfe. Hier muss also noch selbst getippt werden. Anteil_BUKRS ist eine Measure aus der ‚Brückenmeasuregroup‘, welche den Anteil des BUKRS in einem bestimmten Fonds enthält.

Nach dem Speichern der Änderungen und einem Verarbeitungslauf der beteiligten Measuregroups sind die Measures verfügbar.

Auch folgender Aspekt lässt das Konstrukt sperrig erscheinen: Dieses Vorgehen muss logischerweise mit allen Measures durchgeführt werden, die ‚umgerechnet‘ oder ‚aufgeteilt‘ werden sollen. Das kann in größeren Modellen einiges an Arbeit kosten. Trotzdem: ein Performancegewinn ist spürbar. Man sollte durchaus darüber nachdenken, ob das den Aufwand rechtfertigt.

DeltaMaster Modeler

Der Modeler unterstützt auch bei der Erstellung von measure expressions. Diese können bei den Measures eingestellt werden. Ab Version 212 wird der Modeler auch m:n-Dimensionen unterstützen. Die Einstellung der m:n Beziehungen ist aber nicht viel Arbeit und kann auch schnell manuell vorgenommen werden.

Literaturempfehlung:

Ein weiteres gutes Beispiel zum Erstellen einer measure expression findet man in dem Buch Microsoft SQL Server 2008 Analysis Services UNLEASHED von Irina Gorbach.