Während Molap-Systeme mit einer mehrdimensionalen Datenbank arbeiten, greift Rolap direkt auf die in relationalen Datenbanksystemen (RDBMS) hinterlegten Daten zu. In einer Rolap-Architektur wird zunächst das Datenmodell für das Data-Warehouse definiert, um anschließend die Daten aus dem Transaktionsverarbeitungs-System in die Datenbank zu laden. Falls es das Datenmodell erfordert, laufen dann Routinen für die Verdichtung der Daten ab.
Wie beim Molap-Modell werden auch bei der relationalen Lösung Indizes für die Verbesserung der Query-Zugriffe erstellt. Die Endanwender führen ihre multidimensionalen Analysen über die Rolap-Engine aus, die die Requests dynamisch in SQL-Abfragen umwandelt. Der SQL-Code wird zur Verarbeitung an das RDBMS weitergeleitet. Die Abfrageergebnisse entstehen im Kreuztabellenverfahren und wandern schließlich als multidimensionale Ergebnismenge zum Benutzer.
Ein Rolap-System kann - falls verfügbar - vorkalkulierte Ergebnisse nutzen, aber auch dynamisch Ergebnisse aus atomaren Daten genieren. Wegen des direkten Zugriffs auf relationale Daten ermöglicht es kurze Antwortzeiten. Zudem unterstützt es spezielle Verbesserungstechniken, zum Beispiel für Batch- Windows-Anforderungen, für die Tabellenpartitionierung auf Anwendungsebene, für die Denormalisierung von Daten oder für beliebig viele Tabellen-Joins.
Die Rolap-Archichtektur ist dreischichtig. Der Datenbank-Layer nutzt das RDBMS für die Datenspeicherung, die Zugriffs- und die Retrieval-Prozesse. Die Rolap-Engine bildet die Schicht der Applikationslogik, indem sie multidimensionale Reports für eine unbegrenzte Anzahl von Nutzern ausführt. Sie läßt sich mit unterschiedlichen Präsentions-Layern verbinden.
Wie bereits geschildert, müssen Olap-Systeme
- anspruchsvolle Analysen vornehmen,
- zahlreiche Dimensionen unterstützen und
- große Rohdatenmengen auswerten können.
Hier haben Rolap- und Molap-Architekturen einen vergleichbaren Grad an Funktionalität zu bieten (multidimensionale Verhältnisse, Vergleiche, Rangreihen etc.). Ein Molap-System löst diese Aufgaben, indem es hauptsächlich auf bereits gespeicherte Metriken zugreift. Rolap-Systeme können diese Metriken auch dynamisch kalkulieren, falls das nötig sein sollte.
Weitere Kriterien für einen Vergleich der beiden Architekturen sind die Dimensionalität (Anzahl orthogonaler Dimensionen) und die Atomizität (Rohdatenvolumen). Diese beiden Attribute definieren die grundlegenden Anforderungen an Olap-Lösungen, nämlich effektives Handling hoch dimensionaler Systeme mit großen Datenvolumen. Anhand der wichtigsten Parameter - Grad der Datenkompilierung ("Datenfluktuation"), Skalierbarkeit und Datenvolumen - lassen sich die Ansätze direkt vergleichen.
Grad der Datenkompilierung: Der signifikanteste Unterschied zwischen den beiden Olap-Architekturen besteht in der Designphilosophie. Indem es RDBMS-Funktionalitäten wie Joins, Star-Joins und Parallelverarbeitung nutzt, verhält sich ein Rolap-System bezüglich der erforderlichen Datenverdichtung eher neutral. Der Systemdesigner entscheidet selbst, inwieweit Query- und Batch-Anforderungen ausbalanciert werden müssen. Die multidimensionalen Datenbanken eines Molap-Systems hingegen bauen stark auf beschleunigten Adreßzugriff (Hashing) und Batch-Konsolidierungen. Gute Durchsatzwerte sollen hier in erster Linie durch die starke Vorverdichtung der Daten erzielt werden. Zwar erlauben einige Molap-Tools auch einen gewissen Grad an Kompilierung, doch die zugrunde liegende Datenbank bietet bei geringer Verdichtung kaum akzeptable Performance. Folglich nutzen die meisten Molap-Architekturen Datenmodelle, de-ren Verdichtungsgrad zwischen 85 und 100 Prozent liegt.
Datenfluktuation: Diese Eigenschaft beschreibt, wie stark sich Daten und Datenstrukturen im Laufe der Zeit verändern. Zeitdaten weisen beispielsweise einen geringen Fluktuationsgrad auf. Hier werden Tage immer zu Monaten und diese wiederum zu Jahren zusammengefaßt. Produkt-, Mitarbeiter- oder operative Daten hingegen unterliegen hoher Fluktuation. Warenhausketten müssen zum Beispiel ihre Produktgruppen teilweise täglich aktualisieren, um die Rentabilität zu erhöhen - und zwar bis hinunter auf die Artikelebene. Hohe Datenfluktuation wirkt sich auf hoch kompilierte multidimensionale Datenbanksysteme (MDDB-Systeme) stärker aus als auf Rolap-Systeme, die ihre Werte zur Laufzeit generieren können, denn immer, wenn sich Elemente des Rohdatenbestands ändern, sind die im Batch-Prozeß vorkalkulierten Daten neu zu berechnen.
Dimensionalität und Skalierbarkeit: Zwei Beispiele sollen zeigen, welchen Einfluß es auf die unterschiedlichen Olap-Architekturen hat, wenn die Dimensionalität des Datenmodells wächst. Bei nur drei Dimensionen werden die Performance- und Verarbeitungsanforderungen im allgemeinen für jedes Design und bei jedem Grad der Kompilierung erreicht. Sofern adäquate Ressourcen zur Verfügung stehen, wäre hier ein hoher Verdichtungsgrad ratsam, um kurze Antwortzeiten zu gewährleisten. Für ein dreidimensionales Datenmodell eignen sich also sowohl Molap- als auch Rolap-Architekturen. Anders sieht es bei zehn oder mehr Dimensionen aus: Hier ist eine 100prozentige Verdichtung nicht mehr erreichbar, denn die Anforderungen an die Verarbeitung der Batch-Prozesse steigt beträchtlich. Ein Datenbank-Design mit 85- bis 95prozentiger Kompilierung ist zwar noch denkbar, birgt aber das Risiko, daß die User-Anfragen den Server in die Knie zwingen. Hier ist eine Rolap-Architektur mit 50- bis 60prozentiger Verdichtung einem Molap-System vorzuziehen, auch wenn letzteres vom technischen Standpunkt ohne weiteres einsetzbar wäre.
Rohdatenvolumen: Abhängig von der Menge der Rohdaten kann sich der Verdichtungsgrad entscheidend auf die Datenbankgröße auswirken. Je mehr dieser atomaren Daten in höhere Aggregationsebenen zu kompilieren sind, desto umfangreicher wird die Datenbank. So liegt beispielsweise der Expansionsfaktor für ein vollständig kompiliertes fünfdimensionales Datenmodell bei 32. Das bedeutet, daß aus einer Datenbank mit einer Rohdatenmenge von 300 MB eine Datenbank mit 9,6 GB beziehungsweise aus 20 GB atomarer Daten eine Datenbank mit 640 GB entsteht. Ein hochverdichtetes Datenmodell, wie es der Molap-Lösung zugrunde liegt, ist bei einer mehr als 10 GB großen Rohdatenmenge kaum noch sinnvoll - vor allem dann, wenn gleichzeitig die Komplexität der Dimensionen zunimmt. Die Kompilierungsneutralität der Rolap-Architektur hingegen erlaubt dem System-Designer die Implementierung eines nur sehr spärlich verdichteten Datenbank-Designs, was zu deutlich kleineren Expansionsfaktoren führt.
Marktbeobachter wie Aberdeen Group, Meta Group oder Gartner Group haben sich in jüngster Vergangenheit verstärkt mit der Olap-Technologie befaßt. Ihrer Ansicht nach ist der relationale Ansatz der multidimensionalen Lösung um einige Nasenlängen voraus. Die Aberdeen Group etwa empfiehlt IT-Verantwortlichen, Rolap als den "nächsten logischen Schritt in der Entwicklung komplexer Decision-Support-Tools" in Betracht zu ziehen, da der Einsatz einer MDDB bei den inzwischen gängigen Datenbankgrößen von 20, 50 oder mehr als 100 GB nicht mehr praktikabel sei.
Angeklickt
Für die schnelle und effektive Analyse von Data-Warehouse-Inhalten gibt es unterschiedliche Techniken. Auf der Grundlage des Online Analytical Processing (Olap) haben sich vor allem zwei konkurrierende Architekturen herausgebildet: die multidimensionale (Molap) und die relationale (Rolap). Im ersten Teil ihres zweiteiligen Beitrags beschäftigte sich Christiane Jacobs* zunächst mit dem Molap-Ansatz und stellt ihn im zweiten Teil dem Rolap-Modell gegenüber.
*Christiane Jacobs ist freie Journalistin in München.