Data Warehouse Technologien

• Automatisierung der Abläufe

Insbesondere das Einspielen neuer Daten, deren Transformation und Be-

reinigung ist ein ständig wiederkehrender Ablauf. Eine händische Steue-

rung derartiger Abläufe ist nicht nur teuer, sondern auch sehr fehleranfäl-

lig.

• Eindeutigkeit über Datenstrukturen, Zugriffsberechtigungen und Prozesse

Analysen sind geschäftskritisch. Um Geschäftsentscheidungen auf Basis

derartiger Analysen zu ermöglichen (und sie bewerten zu können), muss

die Herkunft und Verarbeitung aller Daten offengelegt sein. Die Nachvoll-

ziehbarkeit von Entscheidungen auf Basis von Analysen erfordert eine voll-

ständige Dokumentation und Offenlegung.

Als letzte Anforderung muss das Gesamtsystem am Zweck der Datenanalyse

ausgelegt sein. Mit anderen Worten, wir sind hier nicht an Systemen inter-

essiert, die beliebige Datenverarbeitung unterstützen, sondern an Systemen,

die speziell auf die Datenanalyse zur Entscheidungsunterstützung ausgerich-

tet sind.

2.1.3 Die 12 OLAP-Regeln nach Codd

OLAP (Online Analytical Processing) ist das Paradigma der Data-Warehouse-

Systeme. Bereits 1993 hat Codd, bekannt für seine Anforderungsregeln an re-

lationale Datenbanksysteme [Cod82, SSH13], ebenfalls einen Anforderungska-

talog von 12 Regeln für OLAP veröffentlicht [CCS93].

1. Multidimensionale Sicht

Konzeptionell basiert die Analyse auf der Aggregation und Gruppierung

von Kennzahlen in unterschiedlichen Kontexten, den Dimensionen. Diese

multidimensionale Sicht muss im Data-Warehouse-System konzeptionell

realisiert werden.

2. Transparenz

Der Nutzer benötigt keine Kenntnisse der tatsächlichen Implementie-

rungsentscheidungen und der verwendeten Datenstrukturen. Diese Forde-

rung entspricht der physischen Datenunabhängigkeit in relationalen Da-

tenbankmanagementsystemen (RDBMS).

3. OLAP-Zugriffe

Die Zugriffsschnittstelle ist für den Zweck der OLAP-Analysen zugeschnit-

ten und unterstützt diese adäquat. Sie hängt nicht vom internen logischen

Datenmodell ab. Diese Forderung korrespondiert mit der logischen Daten-

unabhängigkeit in RDBMS.

18 2 Architektur

4. Performanz

Die Leistung des Data-Warehouse-Systems ist unempfindlich gegenüber

der Anzahl der Dimensionen.

5. Skalierbarkeit

Moderne Architekturen der verteilten Datenhaltung können genutzt wer-

den, um die Skalierbarkeit bei sehr großen Datenmengen zu bewahren.

6. Generische Dimensionalität

Unterschiedliche Dimensionen werden gleich behandelt und organisiert.

7. Dünnbesetzte Strukturen

Das Data-Warehouse-System muss die dynamische Handhabung dünnbe-

setzter multidimensionaler Strukturen effizient unterstützen. Dünnbesetz-

te Würfel entstehen, wenn viele Positionen mit einem Nullwert oder der

Zahl Null belegt werden, da ja beispielsweise nicht alle Waren an allen

Tagen in jeder Filiale auch tatsächlich verkauft oder bestellt werden.

8. Mehrbenutzerbetrieb

Das Data-Warehouse-System muss im Mehrbenutzerbetrieb ohne Konflik-

te einsetzbar sein.

9. Uneingeschränkte Operationen

Die dem Datenwürfelmodell zugehörigen Operationen wie Crosstab (siehe

z.B. [GBLP96]) sind uneingeschränkt zu unterstützen.

10. Intuitive Benutzeroberfläche

Die Benutzungsoberflächlich soll intuitiv und an den Zweck und den Mo-

dellen der Analyse angepasst sein. Insbesondere muss eine Navigation ent-

lang der Dimensionshierarchien unterstützt werden.

11. Flexibles Reporting

Beliebige tabellarische, aber auch zwei- oder mehrdimensionale Reports

müssen frei konfigurierbar sein.

12. Beliebig viele Dimensionen und Aggregationsebenen

Es sollten keine Einschränkungen in der Anzahl der Dimensionen oder der

Tiefe der Dimensionshierarchien vorliegen. Praktisch müssen mindestens

20 Dimensionen und eine Tiefe größer 10 möglich sein.

Diese Kriterien sind nicht unumstritten, zumal sie von einem der „Päpste“ der

relationalen Datenbankforschung kommen, dem man Voreingenommenheit un-

terstellen könnte. Codd hat diese Regeln später ergänzt. Die ergänzten Regeln

umfassen die folgenden sechs Punkte:

2.1 Anforderungen 19

1. Datenintegration

OLAP-Anwendungen bedürfen in der Regel der Integration von Daten aus

unterschiedlichen Datenquellen. Ein OLAP-Werkzeug muss einen transpa-

renten Zugriff auf derartige Daten ermöglichen.

2. Unterstützung unterschiedlicher Analysemodelle

in der Entscheidungsunterstützung durch OLAP sind unterschiedli-

che Analysemodelle in der Diskussion. Gefordert wird, dass OLAP-

Anwendungen die folgenden vier Analysemodelle unterstützen:

• Das kategorisches Modell dient der Beschreibung des Ist-Zustands im

Vergleich mit den historischen Daten. Es erfolgt eine reine Bestands-

aufnahme.

• Das exegetische Modell ermittelt die Ursachen für den aktuellen Zu-

stand. Hierzu werden die Schritte nachvollzogen, die zur aktuellen Si-

tuation führen.

• Das kontemplative Modell realisiert Simulationen für vorgegebene

Werte beziehungsweise Abweichungen innerhalb einer Dimension

oder Dimensionskombination.

• Das formelbasierte Modell schließlich dient der Planung: Für vorgege-

bene Anfangs- und Endzustände wird mittels Simulationen ermittelt,

welche Kenngrößen geändert werden müssen, um das angestrebte Er-

gebnis zu erhalten.

Diese vier Analysemodelle unterscheiden sich im Grad der Dynamik (zu-

nehmend in der gegebenen Reihenfolge) und dem Grad der Unterstützung

durch aktuelle Systeme (abnehmend).

3. Trennung der operativen Daten von den Analysedaten

Analytische Daten müssen aufbereitet werden, um fehlerhafte oder unvoll-

ständige Daten zu behandeln. Derartige Daten müssen bereinigt werden,

um die Validität statistischer Analysen nicht zu gefährden. Gleichzeitig

dürfen die Originaldaten der operativen Systeme nicht korrumpiert wer-

den.

4. Trennung der Speicherorte

Die Speicherung der OLAP Daten sollte von den operationalen Daten ge-

trennt erfolgen. Eine derartige Trennung erlaubt die Datenänderung um

Zwecke der qualitativen Aufbereitung der analytischen Daten und erlaubt

eine spezielle performante Organisation der Daten.

20 2 Architektur