Liebe Datenanalysten,

eine große Stärke von OLAP-Datenbanken ist die Form der Datenmodellierung, die dicht an der betriebswirtschaftlichen Verwendung ist. Das typische Zusammenfassen von Kunden, Materialien, Teams, Kostenstellen usw. in Hierarchien schafft Strukturen, die sich gut in Berichten darstellen und analysieren lassen. So gewinnt man Erkenntnisse zur Steuerung des Geschäfts – und zwar nur so: Nur aus Strukturen kommt Erkenntnis. Daher legt man sich die Daten in der OLAP-Datenbank so zurecht, wie man sie regelmäßig sehen möchte. Manchmal muss man aber davon abweichen und andere Gruppierungen und Teilmengen bilden, etwa, um die Auswirkungen einzelner Maßnahmen zu untersuchen. Solche speziellen Gruppen lassen sich ganz einfach in DeltaMaster definieren, ohne dass Veränderungen an der Datenbank nötig sind. Gut, dass DeltaMaster so dicht am betriebswirtschaftlichen Anwender ist!

Herzliche Grüße
Ihr Team von Bissantz & Company

Manchmal möchte man Kunden, Produkte, Materialien usw. in einer anderen Zusammenstellung untersuchen oder darstellen, als sie in der (OLAP-)Datenbank angelegt sind. Beispielsweise sollen die Verkaufszahlen einer Handvoll Artikel, die man besonders beworben hat, analysiert werden oder man möchte nur bestimmte Kundenregionen auswählen, etwa, weil man es dort mit einem neuen Wettbewerber zu tun hat. Wie trifft man so eine individuelle Auswahl von Elementen – am besten so, dass man sie mehrfach verwenden kann und nicht in jedem Bericht erneut einstellen muss? Dazu bieten sich in DeltaMaster zwei Konstrukte an: benannte Mengen und benutzerdefinierte Hierarchien.

Benannte Mengen

Stellen wir uns vor, unser Referenzbetrieb „Chair“ wolle die Erfolge von Werbemaßnahmen in der Metropolregion Nürnberg untersuchen. Einige Städte, die zu diesem Ballungsraum gehören, sind im Kundenstamm bereits bekannt. Um sie gemeinsam in einer Pivottabelle darzustellen, wählt man sie in der Achsendefinition der Pivottabelle aus – Routine für DeltaMaster-Berichtsredakteure.

Wenn abzusehen ist, dass man diese Auswahl nicht nur einmal benötigt, lässt sie sich als sogenannte benannte Menge speichern, und zwar über das Menü rechts oben in der Achsendefinition.

Über dasselbe Menü lässt sich die Auswahl wieder abrufen, sobald die Menge gespeichert wurde. Angeboten werden dort jeweils alle benannten Mengen, die in DeltaMaster für die betreffende Dimension definiert sind – für die Kundendimension alle benannten Mengen mit Kunden, für die Produktdimension alle benannten Mengen mit Produkten usw.

Der sogenannte Benannte-Mengen-Browser (Menü Modell im Modus Miner) erlaubt es, die Gruppierungen nachträglich zu bearbeiten (Eigenschaften). Auch das Neuanlegen ist möglich. Dazu wird ein Editor benutzt, der eng an die Achsendefinition angelehnt ist. Der einzige Unterschied: In der Achsendefinition ist die Dimension unveränderlich (bzw. von der Berichtsdefinition vorgegeben), im Editor für benannte Mengen lässt sie sich einstellen.

In unserem Beispiel können wir nun also beim Erstellen von Pivottabellen jederzeit die Städte der Metropolregion abrufen. Das spart Bearbeitungszeit, hilft Fehler zu vermeiden und erleichtert die Pflege in der Zukunft: Wenn sich die Liste der Städte einmal ändert, passt man nur einmal die benannte Menge an und schon sind alle Pivottabellen, Berechnungen, Analysen usw., die diese Menge verwenden, automatisch auf dem neuesten Stand. Auch zur Iteration mit Small Multiples können benannte Mengen genutzt werden. Das ermöglicht dynamisch zusammengestellte Berichte, wie in den DeltaMaster clicks! 12/2012 beschrieben.

Falls die Elemente in der benannten Menge untergeordnete Elemente haben, bleibt der Drill-down weiterhin möglich. Die Summe über die Elemente wurde hier als Spaltenaggregation (Kontextmenü) in die Pivottabelle eingeblendet. Sie ist also kein eigenständiges Objekt im Analysemodell von DeltaMaster, sondern eine Berechnung in der gegebenen Tabelle.

In der vorherigen Abbildung ist der Name der benannten Menge in der Pivottabelle angegeben. Dazu wurde in den Tabelleneigenschaften auf der Registerkarte Allgemein die Option aktiviert, dass DeltaMaster den Ebenennamen bzw. die benannte Menge statt des Hierarchienamens anzeigen soll.

Grundsätzlich lassen sich benannte Mengen überall dort einsetzen, wo MDX eingegeben werden kann, beispielsweise in der Achsendefinition, im Editor für berechnete Elemente und im Editor für benutzerdefinierte Analysewerte. Der MDX-Name der Menge wird als Tooltip angezeigt, wenn Sie bei gedrückter Alt-Taste mit der Maus auf den Eintrag im Modellbaum zeigen. Per Doppelklick übernehmen Sie den Namen in das Textfeld für den MDX-Ausdruck.

Über den MDX-Namen können Sie eine benannte Menge sogar im Berichtsserver nutzen: zur automatischen Berichtsverteilung. Um in einem Job sukzessive alle Elemente der Menge zu verarbeiten, geben Sie den MDX-Namen im Berichtsgenerator an, zum Beispiel „[namedset 2]“. Die links davon ausgewählte Hierarchie muss zu der Menge passen.

Benutzerdefinierte Hierarchien

Der zweite Weg, Elemente zusammenzufassen, sind benutzerdefinierte Hierarchien. Sie lassen sich nur im Modus Miner anlegen. Dazu wählen Sie zunächst die gewünschten Elemente im Dimensionsbrowser aus. Anschließend können Sie damit eine benutzerdefinierte Hierarchie erstellen (Menü Ich möchte).

DeltaMaster erstellt daraufhin eine neue Hierarchie, „Kunde (Auswahl)“, und zeigt sie im Dimensionsbrowser an. Die vorher ausgewählten Städte sind jetzt unter einem neuen, virtuellen Element zusammengefasst, dem Klassenelement „Auswahl“. Unterhalb des virtuellen Elements „Restklasse“ finden sich alle übrigen Elemente der betreffenden Hierarchieebene, die Elemente aus dem Gebiet Süd 1 ebenso wie die der anderen Gebiete. Dies ist ein erster Unterschied zu den benannten Mengen: Diese fassen eine bestimmte Gruppe von Elementen zusammen, ohne die restlichen zu beachten. In einer benutzerdefinierten Hierarchie hingegen sind alle Elemente der Dimension aufgehoben, eingeteilt in zwei oder mehr Gruppen (Klassen). Das gilt sogar für Elemente, die später bei einer Aktualisierung der Datenbank hinzukommen, zum Beispiel neue Kunden: Diese werden automatisch in die Restklasse aufgenommen, eine besondere Klasse, die nicht entfernt werden kann.

Die Hierarchie, ihre Ebenen und die virtuellen Elemente lassen sich umbenennen: die Hierarchie über das Menü Ich möchte, die Ebenen und die virtuellen Elemente über ihre jeweiligen Kontextmenüs. Die Restklasse erkennt und verwendet DeltaMaster als solche, auch wenn sie umbenannt wurde.

Über die entsprechenden Einträge im Kontextmenü des Dimensionsbrowsers können Sie Klassenelemente hinzufügen und Elemente verschieben in andere Klassen. Jedes Element ist immer genau einer Klasse zugeordnet. Die Reihenfolge der Klassen lässt sich per Drag-and-drop bei gedrückter Alt-Taste ändern, zum Beispiel, um die Restklasse ans Ende der Liste zu bewegen.

In Analysen und Berichten verhalten sich die virtuellen Elemente so, wie man es von aggregierten Elementen aus der Datenbank kennt. Beispielsweise kann man in Pivottabellen die untergeordneten Elemente ein- und ausblenden („auf- und zuklappen“) und vor allem haben sie eine Summe (bzw. einen aggregierten Wert), der sich als eigenständiges Berichts- und Analyseobjekt verwenden lässt.

Dadurch kann DeltaMaster etwa Sparklines für die Klassenelemente berechnen und Filterelemente mit ihnen erzeugen, die sich wiederum an die Analyseverfahren übergeben lassen.

Wie die Hierarchie und die Klassenelemente benannt sind, hat großen Einfluss auf die Bedienbarkeit der Anwendung und die Verständlichkeit der Ergebnisse. So stehen die benutzerdefinierten Hierarchien auch Anwendern im Modus Viewer zur Verfügung – Anwendern also, die die Zusammenstellung nicht selbst getroffen haben. Ihnen sollte man nicht eine abstrakte „Auswahl“ vorsetzen, sondern durch entsprechende Benennung erklären, wie die Auswahl zustande gekommen ist.

In den Hierarchiemenüs der Analyseverfahren und der Pivotnavigation zeigt DeltaMaster die Namen der Ebenen an – und auch hier macht sich ein deutlicher Name besser als die vorgeschlagenen „Klassen“.

Datenbank oder DeltaMaster?

Nicht nur in DeltaMaster-Analysemodellen können Elemente in mehreren Hierarchien parallel geführt werden, sondern auch in der OLAP-Datenbank. Die Kunden beispielsweise könnte man dort einmal nach Regionen gliedern, einmal nach Branchen, einmal nach Rechtsform, einmal nach ihrer Größenordnung. DeltaMaster kann parallele Hierarchien aus der Datenbank verarbeiten. Sie dort anzulegen, ist aufwändiger als in DeltaMaster. Trotzdem mag es sich lohnen, Zeit in die Modellierung zu investieren, vor allem:

• wenn sehr viele Elemente gruppiert werden sollen (Hunderte, Tausende, nicht nur ein paar ganz bestimmte),
• wenn die parallelen Hierarchien häufig und auf Dauer benötigt werden (nicht nur für ein paar spontane Auswertungen),
• wenn sich alle Elemente auf bedeutungsvolle Gruppen verteilen lassen, die man vergleichend gegenüberstellen möchte (und nicht nur einige wenige Elemente in eine Auswahl gelangen, während alle anderen in eine belanglose Restklasse fallen), und
• wenn die parallelen Hierarchien kreuztabellarisch gegenübergestellt werden sollen (denn das geht nur mit Hierarchien aus der Datenbank, nicht mit benutzerdefinierten).

Bei den ersten beiden Kriterien ist auch an die Abfragegeschwindigkeit zu denken: In der Datenbank angelegte Hierarchien kann der Server vorberechnen und bei Bedarf blitzschnell zur Verfügung stellen. Bei benutzerdefinierten Hierarchien hingegen werden die Aggregationen erst bei einer Abfrage durchgerechnet; das kann länger dauern, wenn es um sehr viele Elemente geht.

Auch benannte Mengen lassen sich in der Datenbank definieren. DeltaMaster übernimmt solche Mengen und zeigt sie ebenfalls im Benannte-Mengen-Browser an (mit dem Scope „Global“). Die Definition lässt sich in DeltaMaster nicht bearbeiten, ansonsten sind die benannten Mengen aus der Datenbank zu verwenden wie die in DeltaMaster angelegten.

Menge oder Hierarchie?

Technisch sind die beiden hier vorgestellten Konstrukte eng verwandt – tatsächlich sind die benutzerdefinierten Hierarchien von DeltaMaster mithilfe von benannten Mengen und berechneten Elementen implementiert. In der Anwendung gibt es jedoch Unterschiede. In der folgenden Tabelle haben wir wesentliche Merkmale gegenübergestellt.

Einige Eigenschaften sind den beiden Ansätzen gemein. So sorgen sie beide für Effizienz durch Wiederverwendung: Sie erzeugen neue Objekte im Analysemodell von DeltaMaster, die sich an einer zentralen Stelle pflegen lassen. Dadurch werden Änderungen automatisch und ohne weiteres Zutun in allen Analysen und Berichten wirksam. Und in beiden Fällen kann man die Elemente auch mithilfe eines MDX-Ausdrucks dynamisch festlegen (anstatt als Aufzählung, wie in unserem Beispiel). Bei Hierarchien kann die Definition sogar auf den Analyseverfahren von DeltaMaster basieren, etwa der ABC-, der Portfolio- oder der Verteilungsanalyse; wir sprechen dann von virtuellen Hierarchien.