E. F. Codd, der Urheber des relationalen Datenmodells, schrieb im Jahre 1994 ein White Paper, um den Begriff Online Analytical Processing (OLAP) einzuführen. Er prägte damit einen neuen Begriff im Glossar der Datenbankmodelle. Der Grund für diesen damals neuen Fachbegriff war die Notwendigkeit, die Charakteristika eines OLAP-Systems von denen eines transaktionsorientierten OLTP-Systems zu unterscheiden. Im Laufe der Entwicklung differenzierten sich die OLAP-Produkte in verschiedene Kategorien. Auf der einen Seite standen jene Produkte, die das multidimensionale Datenmodell in relationalen Datenbanken speicherten und Selektion der Daten mittels SQL vornahmen. Die Abkürzung hierfür lautet ROLAP (Relational Online Analytical Processing). Auf der anderen Seite standen die MOLAP-Produkte (Multidimensional Online Analytical Processing), die die Daten tatsächlich in multidimensionalen Formaten speicherten.

Mit der Ankündigung der Version 8.1 des DB2 OLAP Servers kombiniert IBM die Unterstützung für multidimensionale und relationale Analyse in einem transparenten, hybriden Ansatz zur Datenverwaltung (HOLAP, Hybrid Online Analytical Processing).
Dieser Artikel beleuchtet die verschiedenen Ansätze ROLAP, MOLAP und HOLAP. Dabei wird die Implementierung der hybriden Analyse mit Hilfe des DB2 OLAP Servers, Version 8.1 mit ihren Stärken und Schwächen dargestellt.

Multidimensionales OLAP mit dem DB2 OLAP Server

Basierend auf Hyperions Essbase-Technologie speichert der DB2 OLAP Server die aggregierten multidimensionalen Daten in einem proprietären Dateiformat, um den logischen Cube abzubilden. Die Dimensionen und Hierarchien dieses Cubes werden zuvor in einer Outline definiert, anschließend werden die beschriebenen Daten geladen. Die zu ladenden Daten können hier in unterschiedlichen Formaten bereitgestellt werden. Nach dem Laden werden auf Basis der in der Outline hinterlegten Berechnungsformeln die Hierarchien durchgerechnet und abgespeichert.

Während Laden und Berechnen des Cubes als Batch-Prozesse angesehen werden können, erlaubt die Vorausberechnung dem Anwender einen schnellen Zugriff, der das Attribut „online“ verdient. Eine weiteres Merkmal des DB2 OLAP Servers ist die Option, Daten im Cube zu verändern und anschließend den Cube neu zurechnen.
Die Vorteile beim Einsatz von MOLAP liegen in der Anwenderakzeptanz durch schnelle Antwortzeiten und in den anspruchsvollen Berechnungs- und Geschäftsmodellierungsoptionen. Für den Betrieb liegen die Stärken im geringen Aufwand für Einsatz und Wartung sowie in dem gegenüber ROLAP geringeren Ressourcenbedarf. Von Anwendern mit Planungs- und Modellierungsanforderungen – wie z.B. Wenn-Dann-Analysen – wird die Möglichkeit des Zurückschreibens in den Cube geschätzt.

Durch die ausgereifte und offene Essbase-Technolgie besteht ein großes Angebot von Werkzeugen wie auch add-ins für die Platzhirsche im Endbenutzerterrain, gemeint sind Tabellenkalkulationen wie MS Excel und Lotus 1-2-3. Die Methode der Vorausberechnung jeder möglichen Kennzahl kann bei großen Datenbanken und hoher Granularität die Nacht zu kurz werden lassen. Dann ist eine MOLAP-Lösung eventuell nicht praktikabel. Auch kann die Größe des vollberechneten Cubes die Handhabung – wie Sicherung und Wiederherstellung – problematisch werden lassen. Abhängig vom Modell kann die reine Anzahl an möglichen Werten der Kennzahlen den Cube um ein Vielfaches des Volumens der Quellendaten anwachsen lassen. Um die Größe eines Cubes und die Kalkulationszeit zu beeinflussen, besteht die Option, Kennzahlen erst bei der Abfrage zu berechnen. Dies hat jedoch Auswirkungen auf die Antwortzeiten für den Anwender.

Relationales OLAP

Um aufzuzeigen, dass Online-Analyse auch mit relationaler Datenhaltung möglich ist und um die Kundenanforderung nach „nicht noch einer Datenbank“ zu erfüllen, entwickelten sich ROLAP-Produkte. Der Anwender in einer ROLAP-Architektur sieht die Daten weiterhin konzeptionell von der mehrdimensionalen Ebene. Das mehrdimensionale Modell wird hier in Relationen und SQL-Abfragen übertragen, um standardisierte relationale Datenbankmanagementsysteme (DBMS) zu nutzen. Zur mehrdimensionalen Modellierung werden hier gewöhnlich Star- oder Snowflake-Schemata genutzt. Obwohl die standardisierte Abfragesprache SQL aus vielen Werkzeugen heraus generiert werden kann, haben ROLAP-Werkzeuge den Hauch einer proprietären Lösung, da Datenmodell und Endbenutzerschnittstelle wenig Flexibilität zulassen. Immerhin ist die Datenhaltung im relationalen DBMS standardisiert; es können z. B. in der DB2 Universal Database Gruppierungsfunktionen wie CUBE oder ROLLUP genutzt werden.

Für häufig zu erstellende Berichte und befriedigende Laufzeiten von Abfragen werden oftmals vom ROLAP-Werkzeug gewartete, aggregierte Tabellen erstellt oder wie bei DB2 UDB Automatic Summary Tables genutzt. Im Gegensatz zu MOLAP besteht in einer ROLAP-Architektur eine größere Flexibilität für dynamische Gruppierungen und Summierungen, da keine Vorausberechnung erforderlich ist. Weiterhin ist ein ROLAP-Modell nicht davon abhängig, welche Daten in den Cube übertragen wurden. Der Anwender kann mittels SQL auf alle Daten im RDBMS zugreifen.

Eine nicht zu unterschätzende Stärke des ROLAP-Ansatzes liegt in der Unterstützung von nicht numerischen Datentypen – wie z. B. Text, Binary Large Objects (BLOB), Character Large Objects (CLOB) und sogar User Defined Data Types. Federated DBMS-Funktionalität erlaubt (sporadischen) Zugriff auf ferne oder heterogene Datenbanken. Dieser Ansatz lässt die Daten an ihrem Ursprung und ruft Daten nur auf Anforderung ab, anstatt die Daten in einen Cube zu packen, wo sie vielleicht nie abgerufen werden.
Weiterer Nutzen liegt in der unbestrittenen Skalierbarkeit relationaler DBMS – wie z.B. DB2 EHE, der Standardisierung, der Datenintegrität und im Wiederanlauf.
Im Gegensatz zum direkten Dateizugriff in der beschriebenen MOLAP-Architektur führt jede Benutzeraktion in einem ROLAP-Modell zur Generierung von SQL-Anweisungen. Wie man sich aus der Abbildung eines Star-Schemas vorstellen kann, führt jede Abfrage zu mehr oder weniger umfangreichen SQL Joins mit den bekannten Auswirkungen auf Antwortzeit und Ressourcen. Um akzeptable Antwortzeiten zu gewährleisten, ist mit hoher Wahrscheinlichkeit die Erstellung und Überwachung von aggregierten Tabellen erforderlich. Konsolidierungen mittels SQL sind in der Regel auf normale arithmetische Operatoren beschränkt, während die spezialisierten MOLAP Engines weitaus anspruchsvollere Berechnungsformeln bieten. Neuere Entwicklungen bei SQL erlauben auch z.B. die Berechnung eines gleitenden Durchschnitts.

Obwohl es sich nicht um keine Einschränkung des Datenbankmanagementsystems handelt, erlauben viele ROLAP-Werkzeuge zur Wahrung der Datenintegrität kein Zurückschreiben in die Datenbank.

Hybride OLAP-Analysen mit DB2 OLAP Server

Die jüngste Entwicklung im DB2 OLAP Server beziehungsweise in der Essbase-Technologie ermöglicht einen Ansatz, der die Anwendung der besten Funktionalität aus beiden Architekturen erlaubt. Weiterhin sieht der Anwender die mehrdimensionale begriffliche Ebene seiner Aufgabenstellung. Für den Anwender transparent werden bei der Datenspeicherung zwei Technologien eingesetzt. Die oberen Aggregationsebenen werden in einem Cube abgelegt, um die anspruchsvolleren analytischen Möglichkeiten einer MOLAP-Architektur und den schnellen Zugriff auf kumulierte Werte zu nutzen. Die unteren Granularitäten, modelliert in einem Star-Schema, liegen in der relationalen DB2-Datenbank, um den dynamischen Zugriff und die anderen Vorteile eines RDBMS zu nutzen. Benutzeraktionen werden je nach Ebene automatisch zur richtigen Engine geleitet und dort entsprechend in einen direkten Dateizugriff auf den Cube oder in eine SQL-Anweisung umgesetzt.

Die große Zahl an Werkzeugen für DB2 OLAP Server bzw. Essbase sind auch für das hybride Modell voll einsetzbar. Um der Nomenklatur genüge zu tun, sei darauf hingewiesen, dass der DB2 OLAP Server nicht als einziger das Attribut „hybrid“ verdient. Andere Implementierungen können ebenfalls als hybrid bezeichnet werden, so zum Beispiel die wahlweise Speicherung eines Modells in multidimensionaler bzw. in relationaler Datenhaltung oder der Abruf von Daten aus einem relationalem System und temporäre Zwischenspeicherung in einem Cube.

Die Stärken der DB2 OLAP Server-Implementierung liegen in den schnellen Antwortzeiten für die Mehrzahl der Abfragen, kombiniert mit der Skalierbarkeit und Zuverlässigkeit eines relationalen DBMS auf der Detailebene. Potentiell reduzieren sich durch die geringere Granularität sowohl die Kalkulationszeiten als auch die Größe des multidimensionalen Cubes. Dem steht durch die komplexere Struktur der zu ladenden Daten eine möglicherweise erhöhte Ladezeit gegenüber. In der Summe ist eine reduzierte Erstellungszeit zu erwarten, was dem DB2 OLAP Server Einsatzmöglichkeiten in Bereichen eröffnet, wo bisher die Skalierbarkeit nicht ausreichte.

Weitere Information finden Sie unter www.ibm.com/software/data/db2/db2olap. Unter www.ibm.com/software/data/db2/tryolap.html bietet die IBM weiterhin ein „180 Tage Try and Buy“ des DB2 OLAP Servers 7.1 für iSeries-Systeme an.

IBM Deutschland GmbH

D–70569 Stuttgart

Telefon (+49) 0711/785-0

www.ibm.de