Korrektheit der Daten

Die Korrektheit der durch das BIS bereitgestellten Kennzahlen ist essenziell wichtig.

Die Crux hierbei besteht im Erkennen von fehlerhaften Kennzahlen. Im einfachsten Fall erkennen erfahrene Anwender sofort, wenn die Daten nicht stimmig sind, zum Beispiel wenn die Werte plötzlich doppelt so hoch sind wie in den vorherigen Zeit-räumen. Unter Umständen weichen die Kennzahlen nur minimal ab, beispielsweise um wenige Cent. In diesem schwierigen Fall kann der Fehler unentdeckt bleiben. Ein gesondertes Validierungsverfahren vor der Freigabe von Würfeln kann aus diesem Grund gefordert werden.

Die zweite Schwierigkeit besteht in der Lokalisierung der Fehlerquelle. Die Ursache kann eine fehlerhafte Verarbeitung des BIS sein, die beim Testen während der Ent-wicklung nicht gefunden wurde. Aufgrund der genannten Abhängigkeiten zu den Quellsystemen, ist es aber auch nicht auszuschließen, dass unverschuldet falsche Daten in das DWS eingespielt werden.

Kapitel 4 - Testen während des Betriebes

4.3.1. Validierung von Kennzahlen

Bei besonders sensiblen bzw. kritischen Berichten kann ein Test des Würfels nach dem turnusmäßigen Beladen mit neuen Daten gefordert sein, bevor die Freigabe für die Anwender erteilt wird. Ohne einen Freigabetest besteht die Gefahr dass falsche Kennzahlen in Umlauf geraten. Wie oben bereits erwähnt, können die Datenintegra-tionsprozesse selber nicht feststellen, ob die gelieferten Daten fachlich valide sind.

Ein manueller Test ist also unausweichlich. Die Zuständigkeit des Testens fällt dabei auf den fachlich bzw. inhaltlich für den Würfel verantwortlichen Mitarbeiter.

Für die Testdurchführung muss überlegt werden, wie die Kennzahlen validiert wer-den können. Dafür muss definiert sein, was die „Wahrheit“ ist und wo bzw. wie diese gefunden werden kann. Die eigentliche Wahrheit befindet sich natürlich im operati-ven Quellsystem. Aus diesem müssen die Referenzkennzahlen durch spezielle Se-lektionen ermittelt werden. Da aufgrund der hohen Anzahl von Kennzahlen nicht jede einzelne überprüft werden kann, muss der Testumfang auf ein verträgliches Maß be-schränkt werden. So reicht es etwa aus, die ursprünglichen Kennzahlen zu testen.

Die daraus abgeleiteten Kennzahlen können selber nur dann richtig sein, wenn der Ursprung auch richtig ist. Bei der tatsächlichen Testdurchführung kann aus Dimensi-onssicht vom Wurzelelement (dem obersten Element) aus gestartet werden und dann Ebene für Ebene die folgenden Konsolidierungen geprüft werden (vgl. Ab-schnitt 3.3.2.1).

Die Vergleichsselektionen haben einen ähnlichen Aufbau wie das SQL-Statement im Listing 2-1, wobei je nach gerade ausgewählter Sicht mehr oder weniger Dimensio-nen in die GROUP BY Klausel aufgenommen werden. Je mehr Quellsysteme für die Erstellung der Referenzkennzahlen angesprochen werden müssen, desto mehr nimmt auch die Schwierigkeit der Erstellung der Selektionen zu. All die Schemaver-sätze, die durch die Datenintegrationsprozesse vereinheitlicht wurden, müssen in den Statements nachgebildet werden. Das gesamte Freigabeverfahren ist somit ein hoch komplexes und aufwendiges Unterfangen. Das Verfahren kann daher auch nur bei Würfeln angewendet werden, die in einem sehr großen zeitlichen Intervall (mo-natlich oder quartalsweise) erstellt werden. Da das Validieren durchaus eine Woche

Kapitel 4 - Testen während des Betriebes

Zeit in Anspruch nehmen kann, ist es bei Würfeln mit kurzen Intervallen (wöchentlich oder täglich) nicht praktizierbar.

Für Themenbereiche mit einer hohen Aktualisierungsrate muss eine andere (automa-tisierte) Lösung geschaffen werden. Die einzige hierfür Möglichkeit besteht darin, die Qualitätsregeln der Datenintegration zu verschärfen und zu erweitern. Kimball et al.

[vgl. Kim04, S. 144ff] schlagen vor, die Qualitätsregeln um Statistiken zu erweitern.

Jeder Prozess protokolliert dabei pro Datenlieferung statistisch interessante Informa-tionen. Von Interesse sind vor allem die Anzahl der verarbeiteten Datensätze sowie Summen und Durchschnitte der verarbeiteten Kennzahlen. Beim Beispiel des Versi-cherungsgeschäfts von oben protokolliert der Prozess pro Datenlieferung:

• Anzahl der verarbeiteten Datenätze

• Summe Versicherungsbeitrag

• Durchschnittlicher Versicherungsbeitrag

Mit diesen Informationen können dann bei jedem Lauf Abweichungen zu vorherigen Läufen ermittelt werden und gegen Schwellwerte bzw. Regeln geprüft werden. An-genommen es handelt sich um eine tägliche Verarbeitung, so kann eine Regeln Schwankungen der Datensatzanzahl um mehr als ±10% verbieten. Eine zweite Re-gel kann fordern, dass an zwei Tagen hintereinander die Summen und Durchschnitte der Kennzahlen nicht gleich sein dürfen (exakt gleiche Kennzahlen deuten auf eine Doppellieferung hin). Die Instrumente der Statistik bieten einem Entwickler eine Viel-zahl von Stellschrauben, um automatisiert fehlerhafte oder fehlerverdächtige Daten-lieferungen zu identifizieren.

4.3.2. Quality Gates

Wenn ein Anwender beim Freigabetest oder gar nach der Freigabe im Betrieb auf-grund seiner Erfahrung erkennt, dass die Kennzahlen in einem Bericht falsch sind, beginnt die Schwierigkeit des Auffindens der Fehlerquelle. Da die Daten auf dem Weg aus dem Quellsystem bis in den Bericht durch eine Vielzahl von Prozessen auf-bereitet wurden, gibt es auch entsprechend viele potenzielle Fehlerquellen.

Eine Möglichkeit das Validieren der Daten zu vereinfachen, ist die Einführung soge-nannter Quality Gates („Qualitätsstufen“). Die Quality Gates ergeben sich aus den

Kapitel 4 - Testen während des Betriebes

einzelnen Stufen, die während der Datenaufbereitung aus den Quellsystemen bis in den Bericht durchlaufen werden:

• Schnittstelle

• Säuberung (Staging Area)

• Harmonisierung (Staging Area)

• Sternschema

• OLAP-Würfel

Die einzelnen Stufen können dann leichter gegen die erwarteten Werte getestet wer-den und der verantwortliche Prozess iwer-dentifiziert werwer-den.