Olap-Produkte und -Konzepte

Warehousing-Analyse: Relationen oder Dimensionen

12.12.1997

Werkzeuge für das Online Analytical Processing (Olap) bilden das Bindeglied zwischen dem Entscheidungsträger im Unternehmen und den in einem Data-Warehouse gelagerten Informationen. Sie müssen somit einfaches, aber kreatives Arbeiten mit komplexen Analysen ermöglichen. Welches Produkt State of the art ist, evaluierte die bayrische Forschungsgruppe Wissensbasen (Forwiss), München, mit der Studie "Der Olap-Markt. Architekturen, Produkte, Trends".

Allen Olap-Ansätzen gemeinsam ist die logische Sicht auf die Daten. Sie ist multidimensional und unabhängig von der zugrundeliegenden Datenhaltung. Der Einsatz von Olap-Werkzeugen setzt deshalb anders als bei den klassischen Berichtsgeneratoren und Managed Query Environments eine semantische Schicht voraus, die sehr "dick" ist und nur mit IT-Unterstützung aufgebaut werden kann.

Die Hauptkomponenten eines Online-Analyse-Systems sind die Dimensionen. Diese bestehen aus einer Liste von Elementen, die sich aus dem Blickwinkel des Benutzers ähneln. So läßt sich mit Städten und Ländern etwa eine geografische Dimension aufbauen. Die wohl gebräuchlichste Dimension ist die der Zeit, da Zeitreihen, "Time Series", die häufigste Grundlage aller Analysen und Trendbeobachtungen bilden.

Die Dimensionen lassen sich am besten in einem Würfel darstellen. Teilsichten, das sind Ausschnitte aus dem Gesamtkonzept, werden als Subwürfel bezeichnet. In der Regel umfaßt ein derartiger Cube mehr als nur drei Dimensionen. In solchen Fällen spricht der Fachmann von "Hypercubes". Sogenannte "Dimension-Members" unterteilen eine Dimension. Eine Zeitreihe etwa teilt sich in Januar, Februar, März ... oder auch in Stunden, Tage, Wochen. So besteht eine Dimension nicht ausschließlich aus einer Menge gleichartiger Elemente, vielmehr weisen Dimensionen eine hierarchische Struktur auf. Je höher ein Element in der Hierarchie angesiedelt ist, desto verdichteter, aggregierter, liegen die Werte vor. Die Komprimierung kann aufgrund einfacher Zusammenfassung erfolgen oder in anderen Fällen auf der Basis komplexer Berechnungen. Aggregation ist, so die Verfasser der Forwiss-Studie, ein additiver Prozeß, deshalb sollte sie sich auf numerische Werte beschränken. Umgekehrt nimmt der Detaillierungs- beziehungsweise Granularitätsgrad in den tieferen Hierarchieebenen zu.

Der Vorstoß in tiefere Regionen eines Datensystems wird mit "Drill down" bezeichnet. Hierbei werden konsolidierte Daten Schritt für Schritt in die zugrundeliegenden Teilergebnisse zerlegt. Um sich gegebenenfalls einen Überblick zu verschaffen, bedient sich der Anwender des umgekehrten "Roll-up"-Verfahrens.

Zwei ausgewählte Dimensionen ergeben eine Tabelle. Der Anwender erhält einen Querschnitt durch seinen mehrdimensionalen Würfel, der auch als "Slice" oder "Data View" bezeichnet wird. Dieses Ausschneiden gehört zu den wichtigsten Navigationsmethoden eines Olap-Systems.

Häufig wird in einem Atemzug mit dem Slicing-Verfahren das "Data Dicing" genannt. Dabei handelt es sich um das beliebige Vertauschen der ausgewählten Achsen, aus der X- wird dann beispielsweise die Y-Achse.

Im Schnittpunkt aller festgelegten Dimensionen läßt sich eine Zelle identifizieren. Die Zellenwerte werden auch als "Measures", als "Kennzahlen" oder "Variablen" bezeichnet. Wie viele Dimensionen im Einzelfall notwendig sind, um eine Kennzahl zu bestimmen, ist nicht von vornherein festgelegt. So lassen sich etwa Verkaufszahlen durch drei Dimensionen, Produkt, Zeit und Region, bestimmen; der Mehrwertsteuersatz aber nur durch zwei: Produkt und Region. Unabhängig voneinander dimensionierte Measures sind in Molap-Lösungen ein wichtiges Performance-Kriterium.

Molap-Produkten liegt eine multidimensionale Datenbank zugrunde. Sie eignen sich kaum zur Transaktionsverarbeitung, sehr gut aber für die Datenanalysen. Dafür werden viele Abfrageergebnisse vorausberechnet und Musterabfragen erstellt. Die datenbankinterne Semantik strukturiert die Dimensionselemente nach Gleichartigkeit, so daß auch der Benutzer die Datenorganisation verstehen kann (siehe Beispiel).

So können Abfragen in einer multidimensionalen Datenbank sehr schnell beantwortet werden. Durch den dabei entstehenden Overhead sind der Datenbank allerdings Wachstumsgrenzen auferlegt. Auch deshalb zeichnet sich ein Trend zu hybriden Systemen ab, in denen relationale und mehrdimensionale Datenbanktechniken verschmelzen. Bis jetzt gibt es laut Forwiss jedoch noch keine echten Hybridsysteme auf dem Markt.

Anders als bei relationalen Systemen hat sich bei der Speicherung und Verwaltung multidimensionaler Systeme noch kein einheitliches Verfahren herauskristallisiert, auch für Application Programming Interfaces (APIs) gibt es kaum offene Standards.

Mit dem Problem "Sparsity" sehen sich nur Anwender multidimensionaler Datenbanken konfrontiert. Wenn der Füllgrad eines Würfels unter zehn Prozent liegt, also 90 Prozent der Dimensionskombinationen kein Wert zugeordnet werden kann, zum Beispiel weil in einer bestimmten Region dieses oder jenes Produkt nicht verkauft wird, spricht man von "dünn besetzten Daten" oder "Sparsen". In relationalen Tabellen kann es diese Daten nicht geben. Wenn ein Produkt nicht verkauft wird, existiert auch kein Eintrag in der Tabelle. Ideal wäre es, wenn das Molap-System anhand vorliegender Bedingungen eine optimale Datenstruktur ableiten könnte, indem es einen Hypercube in kleinere, gut besetzte Datenwürfel und Ebenen aufteilen würde. Doch das gibt es laut Forwiss kaum. Bestenfalls könnten die Benutzer manuell auf die Datenorganisation Einfluß nehmen. Sparsity tritt auch bei Datenredundanz auf.

Rolap-Architekturen unterstützen eine virtuelle multidimensionale Datenhaltung, wobei ein Re-Design der Daten in ein denormalisiertes Stern- oder Schneeflockenschema notwendig ist. Verantwortlich für die multidimensionale Benutzersicht, die über der relationalen Struktur liegt, ist eine sogenannte Rolap-Engine. Die Abbildungsinformationen werden als Metadaten gespeichert. Maßgeblich für die Eigenschaften des Gesamtsystems inklusive der Hardware-Architektur sind die Strategien, die bei der Erzeugung von SQL-Statements eingesetzt werden.

Um ein Sternschema zu erzeugen, wird die Information über die Dimensionen in spezifischen Tabellen abgelegt. Für jede Dimension existiert eine solche Tabelle. Die Kennzahlen dagegen sind in einer einzigen Faktentabelle zusammengefaßt. Zwischen der Faktentabelle, die normalisiert ist, und jeder Dimensionstabelle, die nicht normalisiert ist, besteht eine Fremdschlüsselbeziehung.

Das Snowflake-Schema entsteht aus einem Sternschema, indem die Dimensionstabellen normalisiert werden. Damit einher- gehen eine mögliche Verbesserung der Antwortzeiten im Zusammenhang mit vorberechneten Aggregationen und eventuelle Einsparungen beim Speicherplatz. Zwar enthalten die Tabellen weniger Einträge als in einem vergleichbaren Sternschema, die Strukturen sind allerdings wesentlich komplexer.