Unter zunehmendem Wettbewerbsdruck und angesichts unüberschaubar gewordener Datenmengen ziehen immer mehr Unternehmen die Implementierung einer Data-Warehouse-Lösung in Betracht. Bei einer Zuwachsrate von jährlich rund 35 Prozent wird sich laut Gartner Group der Markt für Data-Warehousing bis 1999 auf ein Gesamtvolumen von zirka sieben Milliarden Dollar belaufen.

Doch die Zusammenführung aller relevanten Unternehmensdaten in einen einzigen Datenspeicher ist noch kein Garant für die angestrebten Geschäftsvorteile. Vielmehr muß die Organisation, um ihre Beweglichkeit und Flexibilität am Markt zu erhöhen, eine nahtlose Kommunikationskette zwischen dem Transaktionssystem und ihren Entscheidungsträgern schaffen. Nur Decision-Support-Systeme (DSS), auch als Olap-Systeme bezeichnet, ermöglichen dem "Knowledge Worker" die schnelle, intuitive und flexible Bearbeitung beziehungsweise Analyse operativer Geschäftsdaten und damit die effektive Unterstützung für strategische sowie taktische Entscheidungen.

Geschäftsaktivitäten sind individuell zu bewerten

Anspruchsvolle Analysen ermöglichen Olap-Systeme jedoch nur dann, wenn sie sich flexibel an die jeweiligen Bedürfnisse der Endanwender anpassen lassen. In erster Linie müssen sie daher die Leistungskriterien beziehungsweise die Metriken, nach denen der Anwender die Geschäftsaktivitäten in seinem Umfeld bewertet, in einem individuell gestaltbaren Format zur Verfügung stellen. Dafür gibt es unterschiedliche Möglichkeiten: Entweder der Anwender erhält die Metriken jeweils aus der Transaktionsdatenbank, oder sie sind bereits vorkalkuliert in der Datenbank abgelegt beziehungsweise werden während des Query-Prozesses neu generiert.

Vier der am häufigsten genutzten Metriken

Zu den am häufigsten verwendeten Metriken gehören die vier folgenden:

-Multidimensionale Verhältnisse (Prozent gegenüber Gesamt), zum Beispiel: "Errechne mir den Beitrag zum Wochenumsatz und zum Gewinn, der vom 14. bis zum 18. April 1997 durch alle in der Vertriebsregion Nordost verkauften Artikel vom erzielt wurde."

-Vergleiche (Ist-Soll, aktuelle Geschäftsperiode/Vorjahresperiode), etwa: "Vergleiche die prozentualen Ist-Soll-Abweichungen in den Verkaufszahlen des aktuellen Geschäftsjahres mit den Abweichungen des letzten Jahres, so daß sich Diskrepanzen in der Planung identifizieren lassen."

-Rangreihen und statistische Profile (Top 10, periodisch, prozentual), beispielsweise: "Zeige für meine zehn profitabelsten Vertriebsleute, die zu den oberen zehn Prozent des weltweiten Vertriebsteams gehören, Umsatz, Gewinn und Anzahl der Kundenkontakte pro Tag."

-Individuelle Konsolidierungen (Finanzkonsolidierungen, Marktsegmente, Ad-hoc-Gruppen), so vielleicht: "Stelle mir für die letzten vier Geschäftsquartale für die Vertriebsregion Mitte eine verkürzte Gewinnkalkulation nach Quartalen zusammen."

Manager und Entscheidungsträger analysieren die aus den Abfragen erhaltenen Daten anhand zahlreicher, unterschiedlicher Perspektiven oder "Dimensionen". Im Rahmen dieses Beitrags soll eine Dimension als jedes beliebige Element beziehungsweise jede hierarchische Kombination von Elementen definiert werden, das/die im Datenmodell orthogonal (rechtwinklig) zu anderen Kombinationen von Elementen dargestellt werden kann/können. Soll ein Report etwa den Umsatz pro Woche sowie Sonderaktionen, Verkauf, Lagerbestand und Abteilung enthalten, so entsteht eine vierdimensionale Sicht auf die Daten.

Manche Anwender brauchen Hunderte von Dimensionen

Der Anzahl der Dimensionen in Olap-Systemen dürfen prinzipiell keine Grenzen gesetzt sein, mit anderen Worten: Die Lösung muß dimensionale Skalierbarkeit aufweisen. Eine Direkt-Marketing-Agentur beispielsweise, die eine umfassende Kundendatenbank nach Dutzenden von Charakteristika unterscheiden will, benötigt möglicherweise Hunderte von Dimensionen.

Eine bedeutende Anforderung an Olap-Systeme ist ebenfalls die Unterstützung großer Mengen von Rohdaten, auch atomare Daten genannt. Darunter versteht man die niedrigste Ebene von Datengranularität, wie sie im Rahmen einer effektiven Entscheidungsfindung unabdingbar ist. Für den Manager einer Handelskette kann sich das Kennzeichen "atomar" auf Verkaufsinformationen "nach Filiale,Tag und Artikel" beziehen, für einen Banker sind es Informationen "nach Konto, Transaktion und Zweigstelle".

Viele der Großunternehmen, die Olap-Lösungen implementieren, benötigen Systeme, die zehn, Hunderte oder sogar Tausende von GB dieser atomaren Informationen enthalten. Da das Volumen der Unternehmensdaten mit steigender Data-Warehouse-Nutzung in der Regel weiter zunimmt, gehört die Skalierbarkeit zu einem der bedeutendsten Auswahlkriterien einer geeigneten Olap-Architektur.

In Abhängigkeit von der zugrunde liegenden Architektur unterscheidet man bei Olap-Produkten zwischen multidimensionalen (Molap-) und relationalen (Rolap-)Lösungen. Die Schlüsselkomponente der Molap-Architektur ist eine multidimensionale Datenbank als Basis für die Olap-Analyse. Die Daten sind bereits multidimensional abzulegen, damit der Endanwender sie multidimensional betrachten kann.

In einer gängigen Molap-Architektur werden Informationen aus verschiedenen operativen Systemen durch eine Reihe von Batch-Routinen in eine multidimensionale Datenbank (MDDB) geladen. Batch-Kalkulationen sind die Voraussetzung dafür, daß sich die Informationen in Anlehnung an die orthogonalen Dimensionen verdichten und die Datenfeldstrukturen der MDDB füllen. Beispielsweise werden die Umsatzzahlen aller Geschäftsfilialen einer bestimmten Region addiert und in einer "Regionalumsatz"-Zelle der Datenbank zusammengefaßt.

Nachdem die Array-Strukturen in der Datenbank gefüllt sind, werden die Indizes erstellt. Für die Verbesserung der Query-Zugriffszeiten gibt es "Hashing"-Algorithmen. Nach Abschluß des Kompilierungsprozesses ist die MDDB einsatzbereit. Die Endanwender fordern Olap-Reports über ihre Benutzeroberfläche an, und die Anwendungslogik der MDDB ruft die gespeicherten Daten ab.

Die Molap-Architektur ist sehr verdichtungsintensiv. Grundsätzlich liest sie vorkompilierte Daten. Sie vermag nur in beschränktem Umfang, Aggregationen dynamisch zu erstellen oder Geschäftsmetriken zu berechnen, die nicht bereits vorkalkuliert und hinterlegt worden sind.

Molap ist eine zweischichtige Client-Server-Architektur, in der die MDDB sowohl den Datenbank-Layer als auch die Schicht der Applikationslogik bildet. Auf der Datenbankebene ist das MDDB-System verantwortlich für sämtliche Datenspeicherungs-, Zugriffs- und Retrieval-Prozesse. In der Anwendungslogik führt die MDDB die Olap-Requests aus. Der Präsentations-Layer ist mit der Ebene der Anwendungslogik integriert und stellt das End-User-Interface für die Betrachtung und Abfrage von Olap-Analysen zur Verfügung. Da das System auf einer Client-Server-Architektur basiert, kann eine Vielzahl von Anwendern auf die gleiche, multidimensionale Datenbank zugreifen.

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äftigt 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.