Funktionale Prüftechniken für ein OLAP-System

Zunächst muss überprüft werden, ob die Dimensionsladeregeln korrekt implementiert und die Dimensionsstrukturen richtig aufgebaut wurden. Anhand der Dimensionen und der Hierarchieebenen können die zu überprüfenden Äquivalenzklassen ermittelt werden. Am Beispiel der Dimensionen „Zeit“ und „Absatzgebiet“ ergeben sich als Äquivalenzklassen:

Dimension Äquivalenzklassen Repräsentant

Zeit

Deutschland à Thüringen à Erfurt}

Deutschland à Niedersachsen

à Hannover Tabelle 3-12: Äquivalenzklassen zum Testen der Dimensionalität

[Eigene Darstellung]

Kapitel 3 - Testen während der Entwicklung

Bei der Überprüfung ist von Interesse, ob etwa der Pfad Deutschland à Niedersach-sen à Hannover existiert. Angenommen, die geladene Dimension hat die Struktur Land à Hannover à Niedersachsen, so wurden in der Laderegel fälschlicherweise die Spalten der Generationen 2 und 3 vertauscht. Im Folgenden soll dieser Fehler anhand eines Beispiels (implementiert in dem OLAP-System Jedox²²) demonstriert werden. Aus der Tabelle „Dim_Absatzgebiet“ soll die Dimension Absatzgebiet gela-den wergela-den. Diese ist als vollständige Hierarchie abgespeichert:

Abbildung 3-13: Tabelle Dim_Absatzgebiet [Eigene Darstellung]

Die Laderegel wird in Jedox dialoggesteuert implementiert (Abbildung 3-14). Der Entwickler muss den Typ der Hierarchie angeben, in diesem Fall „TreeFH“, wobei das FH für „Full Hierarchy“ (vollständige Hierarchie) steht. Im unteren Bereich wer-den die Ebenen der Hierarchie angegeben. Hier ist es wichtig, dass die Reihenfolge der Ebenen (Land à Bundesland à Region) korrekt eingehalten wird.

Abbildung 3-14: Korrekte Dimensionsladeregel (Jedox) [Eigene Darstellung]

22 Weitere Informationen unter http://www.jedox.de (Abgerufen 01.01.2012)

Kapitel 3 - Testen während der Entwicklung

In einer fehlerhaften Implementierung wurde die Reihenfolge von Bundesland und Region vertauscht:

Abbildung 3-15: Falsche Dimensionsladeregel (Jedox) [Eigene Darstellung]

Abbildung 3-16: Geladene Dimensionen (Jedox) [Eigene Darstellung]

Die Resultate des Ladens müssen anschließend kontrolliert werden. In der Abbildung 3-16 ist auf der linken Seite das korrekte und auf der rechten Seite das falsche Er-gebnis zu sehen. Anhand des Testfalls muss der Pfad Deutschland à Niedersach-sen à Hannover in der Hierarchie gefunden werden, was im rechten Bild nicht der Fall ist. Fraglich ist noch, ob für unvollständige Hierarchien (z.B. das Bundesland Bremen, das keine Region unter sich hat) eigene Äquivalenzklassen zu bilden sind.

Dies ist nicht der Fall, da der Pfad Land à Bundesland eine Teilmenge von Land à Bundesland à Region ist und deshalb beim Testen der vollständigen Hierarchie mit abgedeckt ist. In der gezeigten falschen Implementierung wird beim Laden auch

di-Kapitel 3 - Testen während der Entwicklung

rekt eine Warnung ausgegeben, weil in diesem Fall Bremen einem leeren Knoten zugeordnet werden soll.

Einen weiteren Test für das korrekte Laden von Dimensionselementen nennt Rainar-di. [vgl. Rai08, S. 481] Für jede Hierarchieebene der Dimensionen muss die Anzahl der geladenen Elemente geprüft werden. Wenn beispielsweise die Zeitdimension vier Jahre abbilden soll, dann muss sie auf Jahresebene vier Elemente, auf Monatsebene 48 Elemente und auf Tagesebene 1.460 Elemente besitzen.

Abbildung 3-17: Faktenladeregel (Jedox) [Eigene Darstellung]

Das analoge Beispiel zu der Faktenladeregel in Jedox ist in der Abbildung 3-17 dar-gestellt. Hierbei ist wie schon bei den Dimensionen darauf zu achten, dass die Spal-ten aus der Eingabe (die FakSpal-tentabelle) auf die korrekSpal-ten Dimensionsfelder (1) und Kennzahlen (2) des Würfels verweisen.

1

2

Kapitel 3 - Testen während der Entwicklung

Mittels Berechnungsregeln können aus den elementaren Kennzahlen weitere Kenn-zahlen abgeleitet werden. Oftmals handelt es sich bei den abgeleiteten KennKenn-zahlen um Durchschnitte, Abweichungen oder einfache Additionen/Subtraktionen und Multi-plikationen. Neben den abgeleiteten Kennzahlen werden durch die Berechnungsre-geln auch die Konsolidierungen der Kennzahlen berechnet. Es gilt dabei, dass jede einzelne Berechnungsregel auf korrekte Anwendung der Rechenoperatoren zu prü-fen ist. Im folgenden Listing ist eine einfache Berechnungsregel für Essbase

// Info : Berechnet den Würfel Versicherungsgeschäft // Autor: Renke Hegeler, 01.01.2012

// Ohne intelligentes Berechnungsverfahren SET UPDATECALC OFF;

// Konsolidierung der elementaren Kennzahlen

CALC DIM (Kennzahlen, Zeit, Absatzgebiet, Produkt);

// Berechnung der Kennzahl "Durchschn. Beitrag"

"Durchsch. Beitr." = Beitrag / "Verk. Versicherungen";

Listing 3-6: Berechnungsregel (Essbase) [Eigene Darstellung]

Für das Testen der Faktenladeregeln und der Berechnungsregeln müssen die ein-zelnen Kennzahlen überprüft werden. Aufgrund der verschiedenen Kombinations-möglichkeiten der Dimensionen gibt es sehr viele Kennzahlen, die zu testen sind. Die theoretische Anzahl kann in die Millionen oder gar Milliarden gehen (Formel 3-3).

Hier muss eine Strategie gefunden werden, diese hohe Anzahl auf ein testbares Maß zu begrenzen.

Rainardi [vgl. Rai08, S. 480f] schlägt hierfür ein intuitives Vorgehen vor. Dabei wird pro Dimension mit den konsolidierten Kennzahlen auf höchster Ebene gestartet und dann entlang der Hierarchieebenen die Sicht immer weiter detailliert. Auf unterster Ebene, wo es die meisten Dimensionsausprägungen gibt, muss dann die getestete Elementanzahl eingeschränkt werden. Der Grundgedanke bei diesem Vorgehen ist, dass die konsolidierten Kennzahlen abhängig von den elementaren Kennzahlen sind.

Kapitel 3 - Testen während der Entwicklung

Wenn eine Kennzahl falsch geladen wurde oder eine Berechnungsregel fehlerhaft ist, so ist auch der konsolidierte Wert falsch.

Bei einer Produktdimension mit den Ebenen „Sparte“ à “Produktgruppe“ à „Pro-dukt“ und den drei Kennzahlen „Umsatz“, „Verkaufte Einheiten“ und „Durch-schnittsumsatz“ wird also mit den konsolidierten Ebenen „Sparte“ gestartet. Bei drei Sparten ergeben sich somit bereits neun zu testende Kennzahlen. Bei jeweils drei Produktgruppen je Sparte multipliziert sich die Anzahl der Testfälle auf 27. Auf der untersten Ebene „Produkt“ kann es je Produktgruppe hunderte Ausprägungen geben.

Rainardi schlägt vor, diese Menge mittels Äquivalenzklassen zu verringern. Die Äquivalenzklassenbildung geschieht dabei auf einer fachlichen Betrachtung, bei-spielsweise anhand der Verkaufshäufigkeit (viel, wenig), der Beliebtheit (beliebt, un-beliebt) oder dem Alter (neu, alt) eines Produktes.

Das Erstellen der Laderegeln ist je nach Hersteller des OLAP-Systems unterschied-lich. Häufig geschieht dieses wie in dem gerade genannten Beispiel über einen inte-grierten Dialog bzw. über einen „Wizard“. In diesem Fall können keine strukturorien-tierten Prüftechniken angewendet werden, da die Regeln gekapselt in dem OLAP-System vorliegen.

Für alle Arten von Regeln empfiehlt sich, eine Stilanalyse durchzuführen. Gerade für die unter Umständen komplexen Berechnungen der Kennzahlen in Skriptform muss auf die Vollständigkeit von Kommentaren geachtet werden. Eine syntaktische Kon-vention bei den Berechnungsregeln kann lauten, dass das oben erwähnte intelligente Berechnungsverfahren nicht erlaubt ist und immer abgeschaltet werden muss.

Mit dem multidimensionalen Diagramm aus der Modellierungsphase (Abbildung 3-2) liegt bereits ein erstes visuelles Hilfsmittel für die Übersicht der Würfelstruktur und der Berechnung von Kennzahlen vor. Was diese Modelle jedoch nicht vorsehen, ist eine Visualisierung der Konsolidierungen. Dieser Punkt wurde auch von Herden [vgl.

Her01, S. 19ff] bei den verglichenen Diagrammtypen bemängelt. Eine denkbare Möglichkeit ist hier die Erweiterung des Diagramms um Konsolidierungsvorschriften.

Als mögliche Konsolidierungen können entweder die Grundrechenarten oder aber ein Ausschluss von der Konsolidierung auftreten. In der Abbildung 3-18 wurde das ADAPT-Modell exemplarisch erweitert und die Konsolidierungsvorschriften als

Attri-Kapitel 3 - Testen während der Entwicklung

but zu den Kennzahlen hinzugefügt. Für die Kennzahl der durchschnittlichen Beiträ-ge wurde aufgrund der in Tabelle 3-11 darBeiträ-gestellten Situation die Konsolidierung ausgeschlossen.

Abbildung 3-18: ADAPT-Modell erweitert um Konsolidierungen [Eigene Darstellung]