Kürzlich haben wir uns bereits mit den magischen Künsten in unserer Branche befasst und aufgedeckt, wie man aus Kreuztabellen Datensätze zaubert. Im heutigen Artikel wollen wir wieder hinter die Kulissen der meisterhaften Zauberei schauen. Wie jeder „OLAP-Jünger“ weiß, wird jede Basiszelle in einem OLAP-Würfel über die Kombination aller Dimensionselemente (inkl. der entsprechenden Kennzahl) definiert. Möchte man also beispielsweise eine Umsatzzahl entlang bestimmter Dimensionsachsen abbilden, muss für jede Dimension definiert werden, auf welchem Element der Wert gespeichert werden soll. Das ist für Reportinganwendungen in der Regel wunderbar. Im Falle von Simulationsrechnungen stößt man aber schnell an die Grenzen der Technik. Im nachfolgenden Artikel wird ein Weg aufgezeigt, wie ab SQL-Server-Version 2005 Kennzahlenwerte auf Dimensionen dargestellt werden können, die nicht in den Basisdatensätzen definiert sind. Im Gegensatz zu bekannten Magiern, die Objekte verschwinden lassen, lassen wir also welche erscheinen. Lassen Sie uns den Zauberstab schwingen.

Sinnloser Zauber?

Stellen wir uns zunächst die Frage nach dem Anwendungsgebiet eines solchen Zaubers. Üblicherweise wird man in Simulations- und Ratingsystemen mit derartigen Anforderungen konfrontiert. Bestimmte Objekte (Kunden, Immobilien, …) sollen nach bestimmten Kriterien (Umsatz, Marktwert, …) bewertet werden. Je nach Bewertung sollen diese dann in bestimmten Bewertungsklassen (oder neudeutsch „Clustern“) ausgewiesen werden. Anschließend soll beispielsweise analysiert werden, wie viele Objekte in den Klassen enthalten sind oder welcher Umsatz pro Klasse generiert wurde. Die Bewertung der Objekte und die Vergabe der Klassengrenzen werden in der Regel online in einer eingabefähigen OLAP-Datenbank durchgeführt. Ohne ein bisschen Magie wäre die einzige Möglichkeit, diese Anforderung umzusetzen, ein mehrstufiger Ratingprozess:

• Import der Basiswerte (z.B. Umsatz) pro Objekt in die OLAP-Datenbank
• Definition der Klassengrenzwerte
• Bewertung der Objekte (falls nicht automatisch berechnet)
• Export aller automatisch berechneten Werte (z.B. Bewertung der Obj.) in die relationale Datenbank
• Relationale Einordnung der Objekte inkl. ihrer Basiswerte in die einzelnen Klassen
• Import der auf Klassen zugeordneten Basiswerte in die OLAP-Datenbank

Dieser Prozess wird bei den Anwendern nicht unbedingt Freudenschreie auslösen. Für die Auswertung der eingegebenen Parameter ist jedes Mal eine relationale Zwischenverarbeitung mit anschließender OLAP-Aufbereitung notwendig. Will der Anwender also (wie üblich) etwas an den Zahlen „herumspielen“, bis er sein gewünschtes Ergebnis erzielt, muss er jedes Mal die Zwischenschritte durchlaufen und unschöne Wartezeiten in Kauf nehmen. Von daher ist eine „Online-Lösung“ in jedem Fall vorzuziehen. Der Wunschzustand wäre also die unmittelbare Abbildung der Basiswerte, gemäß der hinterlegten Grenzwerte, auf den Klassen.

Die Bühne

Zur Verdeutlichung der Fingerübung dient ein stark vereinfachtes und abstrahiertes Modell, in dem mehrere Objekte den drei Klassen „Top“, „Medium“ und „Flop“ zugeordnet werden sollen. Alle Objekte haben einen bestimmten Objektwert (in einer Echtumgebung beispielsweise deren Umsatz). Dieser Objektwert ist in der MeasureGroup nur der Dimension „Objekt“ zugeordnet. Wir gehen davon aus, dass wir diesen Wert so aus den Quelldaten des Kunden erhalten haben. Als Objektbewertung dient der Anteil des Objektwerts an allen Objekten (z.B. Umsatzanteil). Folgende Grafiken zeigen den Aufbau:

Weiterhin gibt es ein Schema, in dem die Klassengrenzen definiert werden. Für diese Definition wurden zwei Kennzahlen, „Grenzwert_von“ und „Grenzwert_bis“ geschaffen, welche in der Measuregroup lediglich der Dimension „Klasse“ zugeordnet sind. Die Klassengrenzen werden online durch den Anwender verändert. Die graue Hintergrundfarbe verdeutlicht die Eingabefähigkeit:

Das Ziel ist nun, wie oben beschrieben, die Objektwerte auf die Klassen zu übertragen, so dass Analysen über die einzelnen Klassen möglich wären.

Der Trick

Würde man den unkomfortablen, relationalen Weg beschreiten, würde man nun eine weitere Measuregroup anlegen, in der die Dimensionen „Objekt“ und „Klasse“, sowie eine Wert-Kennzahl enthalten sind. In diese Measuregroup würden dann nach der relationalen Zwischenverarbeitung alle umgelegten Werte importiert werden.

Um die Klassenumlage online abbilden zu können, braucht man zunächst exakt das gleiche Grundkonstrukt. Die Ziel-Measuregroup wird mit beiden Dimensionen angelegt und eine neue Kennzahl wird hinzugefügt. Der entscheidende Trick ist nun allerdings, dass die Measuregroup nicht aus einer relationalen Quelle gefüllt wird, sondern leer bleibt. Nun wird sich der Leser des „Trimagischen Anzeigers“ fragen, wie um alles in der Welt dann die Werte dort hineinkommen sollen? Die Antwort: per Scope!

Hier also die Übersicht über alle drei verwendeten Measuregroups:

Die Ziel-Measuregroup wird relational also nicht mit Werten gefüllt, sondern lediglich virtuell über das MDX-Script des Würfels. Innerhalb des Scripts muss lediglich geprüft werden, ob die jeweilige Objektbewertung innerhalb der entsprechenden Grenzwerte liegt oder nicht. Wenn das der Fall ist, wird einfach der Ursprungswert auf der entsprechenden Klasse angezeigt.

Der Vollständigkeit halber wird im nachfolgenden Script auch die Berechnung der jeweiligen Objektanteile dargestellt, aber nicht weiter erläutert:

CALCULATE;

--Schritt 1) Objektanteil bestimen

CREATE MEMBER CURRENTCUBE.[Measures].[WertAnteil]
AS [Measures].[Wert]
/
([Measures].[Wert], [Objekt].[Objekt].[Alle Objekte])
,NON_EMPTY_BEHAVIOR=([Measures].[Wert])
,VISIBLE = 1;

--Schritt 2) Werte auf Klassen übertragen

SCOPE([Objekt].[Objekt].[Objekt].Members
,[Klasse].[Klasse].[Klasse].Members);
[Measures].[WertProKlasse] =
if(

--Prüfung untere Grenze

[Measures].[WertAnteil] > [Measures].[Grenzwert_Von]

--Prüfung obere Grenze

AND [Measures].[WertAnteil] <= [Measures].[Grenzwert_Bis]


--Wenn Objekt in Klassengrenzen liegt wird Ursprungswert übertragen

,[Measures].[Wert]
,NULL
);

NON_EMPTY_BEHAVIOR([Measures].[WertProKlasse]) = ([Measures].[Wert]);

END SCOPE;

Das ist im Wesentlichen schon die ganze Hexerei. Die folgenden beiden Abbildungen zeigen die geschaffene Dynamik, indem die Klassengrenzen „Top – Von“ und „Medium – Bis“ leicht verändert werden. Hier zunächst die obere Klassenuntergrenze von 50%, was dazu führt, dass Objekt 1 in Klasse “Top” landet:

Im zweiten Beispiel wurde die obere Klassenuntergrenze auf 60% erhöht. Damit wird Objekt 1 unmittelbar in Klasse “Medium” ausgewiesen:

Die Grenzen der Zauberei

Das hier gezeigte Vorgehen ist bereits in mehreren Projekten erprobt und erfolgreich produktiv im Einsatz. Dennoch muss man je nach Datenmodell aufpassen, dass dieses Vorgehen auch dem Performanceanspruch des Endanwenders gerecht wird. In gar zu großen Datenmodellen könnte es durchaus zu Laufzeitproblemen kommen. In den bisher umgesetzten Anwendungsfällen ist dies allerdings noch nicht vorgekommen und die Performance war mehr als ausreichend.

Dank an das Publikum

Neben dem dargestellten Beispiel eines Bewertungssystems könnte solch ein Vorgehen auch für die Darstellung von Gesellschaftsanteilen oder Ähnlichem verwendet werden. Die Grundtechnik mit der leeren Ziel-Measuregroup und der Befüllung per Scope entspricht übrigens genau der gleichen Technik, wie bei einem Verteilungszauber in einem Planungssystem (z.B. Monatsverteilung), aber das haben Sie als Mitglied unseres kleinen magischen Zirkels bestimmt ohnehin schon selbst erkannt.

Alle Utensilien, um den Trick zu Hause nachzuzaubern, finden Sie an diesen Lehrgang angehängt. Vielen Dank für Ihr Interesse und frohes Zaubern!

Material

Das Zusatzmaterial zum Download finden Sie auf der Blog-Seite.