Tab. 1: Gegenüberstellung von operativen Systemen und Data Warehouses
Vor 1970 setzten sich Manager und andere Entscheidungsträger kaum selbst mit der Datenbeschaffung auseinander, sondern erhielten diese ausgedruckt auf Stapeln von Papier. Mit der Entwicklung des PC's und den Spreadsheets, als erste datenorientierte Endbenutzeranwendung, und der Entwicklung von relationalen Datenbanksystemen sind die Entscheidungsträger selbständige Benutzer geworden, die nun selbst die Kontrolle über ihre Daten übernahmen.
In den Achtziger Jahren kamen erste Datenmodelierungsmethoden auf. Das erlaubte
die Anforderungen an die Daten und die dazu benötigten Strukturen formal
zu dokumentieren. Man erkannte die Notwendigkeit einer Struktur und Architektur
in bezug auf die Datenbeschaffung um eine gute Übersicht behalten zu können.
Durch die Verallgemeinerung der Datenautomation schwand der Konkurrenzvorteil
allerdings zunehmend. Forderungen nach einer spezifischen Architektur für
die einzelnen Unternehmen wurden laut.
Ende der Achtziger Jahre setzte sich die Unterscheidung zwischen operativen
und analytischen Informationssystemen durch. Die Grenzen zwischen den beiden
Kategorien sind jedoch nicht ganz klar. Operative Systeme unterstützen
typischerweise OLTP Anwendungen mit laufend aktualisierten Daten. Operative
Daten repräsentieren den gegenwärtigen Zustand des Unternehmens. Diese
Systeme, auch OLTP-Systeme genannt, werden eingesetzt bei strukturierten, repetitiven
Aufgaben, die aus kurzen, vordefinierten Transaktionen bestehen. Das sind vor
allem alltägliche, administrative Aufgaben die heute nicht mehr wegzudenken
sind, wie zum Beispiel Auftragseingänge oder Banktransaktionen. OLTP-Systeme
sind primär dazu entworfen um eine schnelle und effiziente Ausführung
einer grossen Anzahl von einfachen, vordefinierten read/write Transaktionen
zu behandeln. Die Maximierung des Transaktionsdurchsatzes ist das grundlegende
Ziel.
In der Regel haben OLTP-Systeme einen Umfang von hunderten von Mega- bis Gigabytes.
Andersartig sind die Charakteristika von analytischen Informationssystemen.
Sie werden, basierend auf historischen Daten, für die Unternehmungsführung
und -kontrolle gebraucht, um eine Sicht der Geschäftslage über eine
Zeitspanne, oder zu einem bestimmten Zeitpunkt zu geben. Sie enthalten konsolidierte,
von mehreren operativen Datenbanken integrierte Daten und sie können durchaus
eine Grösse von einigen hundert Giga- bis Terrabytes erreichen. Sie sind
hauptsächlich entworfen um die Ausführung von komplexen, ad hoc und
meist read-only Anfragen zu unterstützen. Anfragedurchsatz und Antwortzeit
sind hier wichtiger als Transaktionsdurchsatz.
Analytische Informationssysteme sind für on-line analytical processing
geeignet und werden deswegen auch OLAP-Systeme genannt.
Anfangs der Neunziger Jahre erkannte man einerseits, dass die bisher gebräuchlichen Methoden für die Datenbeschaffung nicht robust genug waren, um den zukünftigen Wachstum zu unterstützen. Andererseits war die Benutzbarkeit der Daten durch das Fehlen des Geschäftskontextes geschwächt. Die Industrie war vor neue Anforderungen gestellt. Technologische Einschränkungen, vor allem um Informationen von verschiedenen heterogenen Systemen zusammenzubringen, behinderten die Entwicklung von OLAP-Systemen. Die Data Warehousing Technologie zielt darauf hin, Lösungen für diese Probleme zu liefern.
Unter dem Begriff Data Warehouse wird eine von den operativen DV-Systemen isolierte Datenbank verstanden, die einen effizienten Zugriff auf integrierte Informationen von verschiedenen, im allgemeinen heterogenen Informationsquellen erlaubt und als unternehmensweite Datenbasis für Managementunterstützungssysteme dient.
Inmon, der als "Vater" des Data Warehousing angesehen wird, definiert ein Data Warehouse in [Inmo92] als:
"(...) subject-oriented, integrated, time-varying, non-volatile collection of data that is used primarily in organizational decision making."
Ein Data Warehouse ist demnach durch die vier Merkmale Themenorientierung, Integration, Zeitraumbezug und Nicht-Volatilität gekennzeichnet, die im folgenden kurz erläutert werden.
Ein Data Warehouse orientiert sich an den wichtigsten Sachverhalten eines Unternehmens.
INMON spricht hier von bestimmten "subjects" eines Unternehmens. Beispiele
hierfür sind Kunden, Verkäufe, Regionen, Produkte. Es steht also bei
der Konzeption eines Data Warehouses eine datenorientierte Vorgehensweise klar
im Vordergrund, während innerbetriebliche Abläufe und Funktionen,
die den Fokus klassischer operativer Anwendungssysteme bilden, von untergeordnetem
Interesse sind.
Der Entscheider hat so die Möglichkeit, Unternehmensdaten aus verschiedenen
Blickwinkeln zu betrachten.
In einem Data Warehouse sind alle Daten integriert und zwar ohne Ausnahme, was oftmals als der wichtigste Aspekt eines Data Warehouses angesehen wird. Da diese Daten aus verschiedenen, heterogenen Datenquellen stammen, sind Datenredundanzen und damit Inkonsistenzen kaum vermeidbar. Um trotzdem eine konsistente Datenhaltung im Data Warehouse zu ermöglichen, muß deshalb eine Struktur- und Formatvereinheitlichung erfolgen, die sich unter anderem in konsistenten Namenskonventionen, konsistenten Maßeinheiten für Variablen und konsistenten Datentypen ausdrückt
In operativen Systemen werden jeweils nur die aktuell gültigen Datenwerte gespeichert, d.h. Anfragen auf diese Systeme liefern die "im Augenblick des Zugriffs" gültigen Werte von Datenobjekten zurück. Dagegen sind sämtliche Daten eines Data Warehouses zu einem bestimmten Zeitpunkt gültig bzw. gültig gewesen. Data Warehouses speichern historische Daten (der Zeithorizont beträgt meist mehrere Jahre), die von den Entscheidern benötigt werden, um Trends und Entwicklungen zu erkennen und angemessen darauf reagieren zu können. Deswegen enthalten sämtliche Schlüssel eines Data Warehouses - explizit oder implizit - ein Zeitelement, um die Daten eindeutig über die Zeit hinweg identifizieren zu können.
Der Begriff Volatilität beschreibt den Grad, mit dem sich Daten im Laufe der normalen Nutzung ändern. Während in operativen Systemen laufend Daten eingegeben, gelöscht und geändert werden, werden die Daten in einem Data Warehouse nach der einmaligen Übernahme aus den Quellsystemen normalerweise nicht mehr verändert. Es existieren daher nur zwei grundlegende Operationen auf den Daten in einem Data Warehouse - der initiale Ladevorgang und der ausschließlich lesende Zugriff auf die Daten. Durch diese Nicht-Volatilität lassen sich sämtliche Analysen jederzeit reproduzieren. Ein Data Warehouse wird normalerweise von den operativen Datenbanken getrennt unterhalten. Diese sind auf die Unterstützung von On-line Transaction Processing (OLTP) Anwendungen ausgerichtet, während sich das Data Warehouse Konzept auf On-line Analytical Processing (OLAP) konzentriert.
OLTP-Anwendungen sind auf die transaktionelle Verarbeitung von Daten spezialisiert.
Die Aufgaben, die eine OLTP Anwendung durchführt, sind strukturiert, repetitiv
und bestehen aus kurzen, atomaren und isolierten Transaktionen (ACID-Prinzip).
Diese Transaktionen benötigen detaillierte, aktuelle Daten, auf die sie
lesend und schreibend zugreifen. Im Gegensatz dazu, sind OLAP-Anwendungen auf
eine effektive Datenanalyse ausgerichtet und werden zur Entscheidungsunterstützung
des Managements eingesetzt. Hierbei stehen weniger aktuelle Detaildaten im Mittelpunkt,
als vielmehr historische, aggregierte und integrierte Daten.
Auf diese Daten wird im Normalfall nur lesend zugegriffen. Daher sind eine hohe
Anfrage Performance und eine niedrige Antwortzeit wichtiger als der für
OLTP-Anwendungen entscheidende Durchsatz an (Update-) Transaktionen.
Diese Ausführungen lassen bereits erkennen, daß sich eine Data Warehouse
Umgebung sehr stark von einer herkömmlichen Datenbankumgebung im operativen
Bereich unterscheidet. Die folgende Tabelle gibt deshalb einen Überblick
über die wichtigsten Unterschiede zwischen Data Warehouses und operativen
Anwendungssystemen.
Tab. 1: Gegenüberstellung von operativen Systemen und Data Warehouses
Im Datenbankbereich ist es üblich zwischen der Datenbank einerseits und
dem Datenbanksystem
andererseits zu unterscheiden. Bei der Datenbank handelt es sich dabei um die
eigentliche Datenbasis. Diese Datenbasis wird von einem Datenbankmanagementsystem
(DBMS) verwaltet, welches aus Sicht des ADK-Modells den Datenverwaltungsteil
eines Anwendungssystems realisiert. Das DBMS und die Datenbasis bilden zusammen
ein Datenbanksystem.
Abbildung 1 zeigt die logische Architektur eines Data Warehouse Systems. Deutlich
sind die drei Hauptebenen
- Datenerfassung
- Datenhaltung
- Datenbereitstellung
zu erkennen.
In den folgenden Abschnitten werden die einzelnen Ebenen der Data Warehouse System Architektur, ihre Aufgaben und ihre Komponenten näher erläutert.
Abb. 1: Grundlegende Architektur eines Data Warehouse Systems
Die Datenerfassungsebene umfaßt alle Aufgaben, die mit dem Laden der Daten
in das Data Warehouse zusammenhängen, sowohl beim initialen Ladevorgang
als auch bei der periodischen Aktualisierung. Sie besteht aus einer Vielzahl
von Werkzeugen zur Extraktion, Bereinigung und Transformation der Daten, sowie
Werkzeugen zum Laden der Daten in das Data Warehouse. Dieser Prozeß stellt
die Haupteinflussfaktor für eine erfolgreiche Implementierung Eines Data
Warehouse Systems dar.
Ebenfalls der Datenerfassungsebene zuzuordnen, ist die Festlegung der Aktualisierungsstrategie.
Zum Problembereich der Aktualisierung gehören die Fragen, wann und wie
das Data Warehouse zu aktualisieren ist, d.h. wann und wie der Prozeß
aus Extraktion, Bereinigung / Transformation und Laden anzustoßen ist.
Im allgemeinen wird eine periodische Aktualisierung bevorzugt. Es kann jedoch
auch nötig sein (z. B. wenn OLAP-Anfragen immer aktuelle Daten benötigen),
jede Änderung der Basisdaten zu propagieren.
Extraktionswerkzeuge stellen in der vorgestellten Data Warehouse System Architektur
die Schnittstelle zu den operativen und externen Datenquellen dar. Sie müssen
in der Lage sein, Daten aus den unterschiedlichsten Quellsystemen zu extrahieren,
egal ob sie in relationalen, hierarchischen oder Netzwerk-Datenbanken oder vielleicht
sogar in sequentiellen Dateien gespeichert sind. Dabei sollte sowohl eine komplette
Neuberechnung, als auch eine inkrementelle Aktualisierung des Data Warehouses
möglich sein. Bei der Neuberechnung werden sämtliche Daten des Data
Warehouses
gelöscht und anschließend von Grund auf neu berechnet. Die inkrementelle
Aktualisierung nutzt hingegen Informationen über die Änderungen auf
den Quellsystemen, um die Änderungen für die Daten im Data Warehouse
zu berechnen. Es erfolgt also nur eine Aktualisierung der Daten, die sich tatsächlich
geändert haben. Aus Performancegründen ist die inkrementelle Aktualisierung
eindeutig zu favorisieren.
Da ein Data Warehouse System zur Entscheidungsunterstützung des Managements eingesetzt wird, sind die Anforderungen an die Datenqualität besonders hoch. Die Auswirkungen fehlerhafter Informationen zeigen sich dabei typischerweise sowohl auf der operativen (z.B. Kundenunzufriedenheit), der taktischen (z.B. lange und schlechte Entscheidungsprozesse) und der strategischen Ebene (z.B. Schwierigkeiten bei der Festlegung und Durchsetzung von Strategien). Aber gerade da ein Data Warehouse große Datenmengen aus verschiedenen Quellen integriert, ist die Wahrscheinlichkeit für Fehler und andere Anomalien hoch. Diese Fehler zu entdecken und zu beseitigen, ist die Aufgabe der Extraktions- und Transformationswerkzeuge.
Dabei können grob drei Klassen von Bereinigungstools unterschieden werden:
Data Migration Werkzeuge führen syntaktische Transformationen auf den Daten durch. Ein Beispiel hierfür ist z.B. das Ersetzen der Zeichenkette "männlich" durch "m", um ein einheitliches Format für die Speicherung des Geschlechtes eines Kunden im Data Warehouse zu erreichen.
Data Scrubbing Werkzeuge überprüfen die Semantik der Daten mit Hilfe
domänenspezifischen
Wissens (z.B. Postleitzahlenverzeichnisse). Mit Hilfe dieser Tools kann z.B.
kontrolliert werden, ob die Stadt und die Postleitzahl in der Adresse eines
Kunden zusammenpassen oder ob hier ein Fehler vorliegt.
Data Auditing Werkzeuge erlauben es Beziehungen und Regelmäßigkeiten
in den untersuchten Daten zu entdecken. Auch ist es möglich, Abweichungen
von festgelegten Regeln aufzuzeigen. Aus diesem Grund, wird diese Klasse oft
als Variante von Data Mining Tools bezeichnet.
Nach der Extraktion, Bereinigung und Transformation der Daten, müssen diese
in das Data Warehouse geladen werden. Die folgenden Teilaufgaben können
hierbei identifiziert werden: Überprüfung von Integritätsbedingungen,
Sortierung, Vorverdichtung in Form von Summenbildung und Aggregation, Berechnung
abgeleiteter Daten, Aufbau von Indizes und anderen Zugriffspfaden.
Heute werden meist Stapelverarbeitungsprogramme (Batch Load Utilities) eingesetzt,
um die riesigen Datenmengen in das Data Warehouse zu laden. Ein Hauptproblem
hierbei ergibt sich aus der Tatsache, daß der Ladevorgang geraume Zeit
beanspruchen kann und währenddessen keine Anfragen an das Data Warehouse
möglich sind. Um dieses Problem zu entschärfen, werden zunehmend Verfahren
eingesetzt, die versuchen, die Zeit, die der Ladevorgang beansprucht (das sogenannte
Update Window) zu minimieren.
Die Aufgabe der Datenhaltungsebene ist die Speicherung der Daten im Data Warehouse.
Das Data Warehouse muß in diesem Zusammenhang streng vom OLAP-Speicher
unterschieden werden, der die Daten aus dem Data Warehouse übernimmt und
sie Analyse- und Reportingwerkzeugen zur Verfügung stellt. Während
das Data Warehouse meist relational realisiert wird, sind die Speicherstrukturen
des OLAP-Speichers abhängig von der verwendeten Technologie. Man unterscheidet
hier zwischen relationalem OLAP (ROLAP), multidimensionalem OLAP (MOLAP) und
hybridem OLAP (HOLAP). Diese verschiedenen Möglichkeiten einen OLAP- Speicher
zu realisieren werden erst im nachfolgenden Abschnitt erläutert, da der
OLAP-Speicher Teil der Datenbereitstellungsebene ist.
Die Datenhaltung in Data Warehouses muß, neben zahlreichen anderen, vor
allem zwei Hauptanforderungen genügen. Erstens muß das Data Warehouse
in der Lage sein sehr große Datenmengen zu speichern. Zweitens muß
es so organisiert sein, daß schnelle Antwortzeiten auf OLAP-Anfragen möglich
sind (Die Struktur des Data Warehouses hat Einfluß auf die Struktur des
OLAP-Speichers und somit indirekt auf die Anfrageperformance.).
Die Datenbereitstellungsebene besteht üblicherweise aus einem OLAP-Server, der die Daten des OLAP-Speichers an Front End Tools, wie Analyse-, Anfrage/Report-, und Data Mining- Werkzeuge weiterleitet. Auf diesen Daten muß eine multidimensionale Analyse möglich sein.
Zur Erleichterung der komplexen Analysen und zur Visualisierung der Datenbestände
in OLAP-Systemen, werden diese meist als multidimensionale Würfel (data
cube) modelliert und dargestellt (vergleiche Abbildung 2). Im Mittelpunkt dieses
auch als multidimensionales Modell bezeichneten Ansatzes stehen eine Menge von
numerischen Maßzahlen, die sogenannten Fakten, wie z.B. Verkäufe,
ROI (Return of Investment), Bestände, Forderungen (vgl. Merkmal Themenorientierung).
Jede dieser Maßzahlen ist von einer Menge von Dimensionen abhängig,
welche
ihren Kontext repräsentiert. Unter anderem können z.B. Produktname,
Stadt und Tag des Verkaufs als Dimensionen der Maßzahl Verkäufe angesehen
werden. Die Dimensionen determinieren zusammen eindeutig die zugehörige
Maßzahl. Jede Dimension wird dabei durch eine Menge von Attributen beschrieben.
Die Produkt-Dimension könnte z.B. aus den folgenden drei Attributen bestehen:
Kategorie und Branche des Produktes, sowie das Jahr seiner Einführung.
Diese Attribute können innerhalb einer Dimension miteinander in Beziehung
stehen und so eine Beziehungshierarchie bilden.
Im obigen Beispiel, stehen der Produktname mit der Produktkategorie und diese
wiederum mit der Branche in solch einer hierarchischen Beziehung (siehe Abbildung
2).
Abb. 2: Multidimensionale Daten
Auf einem multidimensionalen Würfel sind neben den normalen Datenbankoperationen noch weitere, für OLAP spezifische Operationen definiert:
Slice-and-Dice: Bestimmte Ausschnitte der Daten können in jeder beliebigen Dimension geschnitten oder gedreht werden. Im Beispiel aus Abbildung 2 können z.B. nur die Verkäufe von Produkt A für verschiedene Tage und Städte betrachtet werden. Dies entspricht einem Schnitt durch den multidimensionalen Würfel.
Drill-Down: Diese Operation erlaubt ein Navigieren entlang der Hierarchien, die für die einzelnen Dimensionen definiert sind. Der Nutzer, der z.B. gerade die Verkäufe auf Landesebene analysiert, kann mittels Drill-Down, die Daten auf Regionen-Ebene herunterbrechen und die Daten so weiter auffächern.
Drill-Up: Hierbei handelt es sich um die inverse Operation zum Drill-Down.
Drill-Through: Mit dieser Operation kann man den zu betrachtenden Datensatz innerhalb einer Hierarchieebene ändern. Der Anwender, der gerade die Daten der Region Nord betrachtet, kann z.B. auf die der Region Süd wechseln.
Das OLAP-Konzept, bestehend aus der multidimensionalen Würfelstruktur
und den dazugehörigen Operationen, kann auf verschiedene Weise realisiert
werden:
Im MOLAP-Ansatz (Multidimensionales OLAP) werden multidimensionale Datenstrukturen
aufgebaut. Die Daten werden hier in einem multidimensionalen Würfel gespeichert
und stehen den multidimensionalen Anfragen der Analyse- und Reportwerkzeuge
ohne Umsetzung zur Verfügung (direct mapping). Dieser Ansatz kann bei sparse
data, wenn nur ein kleiner Prozentsatz der Zellen des Würfels besetzt sind,
zu einer schlechten Speicherauslastung führen. Er hat jedoch den Vorteil,
daß die Zugriffsstrukturen für mehrdimensionale Strukturen optimiert
sind.
Der ROLAP-Ansatz (Relational OLAP) hingegen setzt das multidimensionale Modell und dessen Operationen in Relationen und SQL-Anfragen um. Die Multidimensionalität wird hier - im Gegensatz zum MOLAP-Ansatz - nur virtuell realisiert, da zur Speicherung der Daten relationale Datenbankmanagementsysteme eingesetzt werden, deren Vorteile, wie Skalierbarkeit, Sicherheitskonzepte und Transaktionssynchronisation so genutzt werden können. Dafür muß man eine, im Vergleich zu MOLAP, geringere Anfrageperformance in Kauf nehmen.
Im HOLAP-Ansatz (hybrides OLAP) werden nur die häufig benötigten
Daten in multidimensionalen
Strukturen gespeichert. Weniger oft verwendete Daten werden dagegen in Relationen
gespeichert.
Im folgenden wird lediglich der relationale Ansatz (ROLAP) betrachtet. Es wird gezeigt, wie relationale Datenbankschemata eingesetzt werden, um eine multidimensionale Sicht auf die Daten zu erzeugen. Hierfür wird das in der Praxis häufig eingesetzte Star-Schema, oder eine seiner Varianten, wie das Snowflake-Schema verwendet.
Die grundlegende Prämisse des Star Schemas ist die Klassifikation der Tabellen
des Datenbankschemas in eine Fakttabelle und mehreren Dimensionstabellen - eine
für jede Dimension. In der Fakttabelle werden die numerischen Maßzahlen
gespeichert (z.B. die Verkaufszahlen), also die Daten eines Unternehmens, die
analysiert werden sollen. Die Dimensionstabellen enthalten die Attribute der
jeweiligen Dimension. Abbildung 3 zeigt ein Beispiel für ein Star-Schema.
Deutlich ist zu erkennen, daß die Dimensionstabellen nicht untereinander,
sondern nur mit der Fakttabelle in Beziehung stehen, wodurch eine sternförmige
Struktur entsteht. Gemäß dem Relationenmodell
ist für jede Tabelle ein Primärschlüssel definiert (in Abbildung
3 durch Unterstreichung gekennzeichnet). Die Verknüpfung zwischen Fakttabelle
und Dimensionstabelle wird dadurch erreicht, daß der Primärschlüssel
der Dimensionstabelle als Fremdschlüssel in den Primärschlüssel
der Fakttabelle aufgenommen wird.
Abb. 3: Star Schema
Die Dimensionstabellen sind im Star Schema vollständig denormalisiert, z.B. ist die Tabelle Stadt in Abbildung 3 nicht in dritter Normalform, weil zwischen den Nichtschlüsselattributen Region und Land eine funktionale Abhängigkeit besteht.
Eine komplett normalisierte Datenbank, wie sie in OLTP-Anwendungen verwendet wird, besteht aus hunderten von Tabellen und macht so effiziente Analysen nahezu unmöglich. Denormalisierte Schemata dagegen sind einfach und elegant. Sie entsprechen eher der intuitiven Vorstellung der Benutzer. Die Anzahl der Verknüpfungen, die bei einer durchschnittlichen Anfrage verarbeitet werden, ist bei einem denormalisierten Schema deutlich reduziert, was in einer besseren Anfrageperformance resultiert. Und da die Daten in einem Data Warehouse nach dem einmaligen Ladevorgang normalerweise nicht mehr geändert werden, fallen die Nachteile der Denormalisierung, wie z.B. Anomalien, nicht weiter ins Gewicht.
Beim Einsatz von Star Schemata zur Speicherung multidimensionaler Daten, können sowohl die Fakt- als auch die Dimensionstabellen sehr viele Tupel beinhalten, wodurch die Leistungsfähigkeit und das Antwortzeitverhalten des Systems negativ beeinflußt werden kann. Ein weiteres Problem in Bezug auf Star Schemata, ergibt sich aus der Tatsache, daß diese keine Attributhierarchien unterstützen. Um diese Nachteile abzuschwächen, wurden Varianten des Star Schemas, wie das Snowflake Schema entwickelt, das im folgenden vorgestellt wird.
Um die Anzahl der Tupel in den Dimensionstabellen zu reduzieren und damit die Anfrageperformance zu steigern, kann ein Star Schema durch Normalisierung der Dimensionstabellen in ein Snowflake Schema überführt werden. Durch diese Normalisierung wird außerdem eine Struktur erzeugt, die die Attributhierarchien der Dimensionen explizit repräsentiert . Snowflake Schemata haben jedoch den Nachteil, daß sie deutlich komplexer sind, was die Navigation in einem solchen Schema erschwert.
Parallel zu den Aufgaben der Datenerfassungs-, Datenhaltungs- und Datenbereitstellungsebene
fallen in einem Data Warehouse System vielfältige Überwachungs- und
Administrationsaufgaben an, zu deren Unterstützung zahlreiche Werkzeuge
zur Verfügung stehen. Entwicklungswerkzeuge werden zur Erstellung und Änderung
von Schemata, Regeln, Abfragen und Reports eingesetzt. Zur Kapazitätsplanung
und zur Durchführung von Was-wäre-wenn- Analysen (what-if-analysis)
werden
Plannungs- und Analysewerkzeuge verwendet. Warehouse Management Werkzeuge dienen
zur Überwachung des Data Warehouse Systems und zur Erstellung von Statistiken
über die Data Warehouse Nutzung. Desweiteren werden System- und Netzwerkmanagementwerkzeuge
z.B. zur Messung des Datendurchsatzes zwischen Data Warehouse Servern und operativen
DBMS eingesetzt. Auch Workflow Management Werkzeuge können zur Steuerung
des, aus den Teilprozessen Extraktion, Bereinigung und Transformation, sowie
Laden bestehenden Datenerfassungsprozesses Verwendung finden.
Das zentrale Objekt einer multidimensionalen Struktur wird Würfel (engl.
Cube) genannt. Ein Würfel besteht aus einer Menge von orthogonalen Kanten,
den Dimensionen. Jede Dimension besteht aus einer Anzahl von Elementen bzw.
Mitgliedern, welche aus der Sicht des Betrachters den gleichen Datentyp besitzen.
Ein Würfel aus zwei Dimensionen repräsentiert so eine Tabelle, in
der die Daten in Zeilen und Spalten aufgelistet werden. Eine dreidimensionale
Struktur wird als normaler Würfel angesehen. Zu mehr als drei Dimensionen
gibt es zwar kein physisches Äquivalent, allerdings werden die Daten so
organisiert, wie es aus der Sicht eines Unternehmens denkbar wäre. Bei
mehr als drei Dimensionen spricht man auch von einem Hyperwürfel, bzw.
Hypercube.
Abb. 5: Dreidimensionaler Würfel
Das folgende Beispiel besitzt fünf Dimensionen, welche mit
· Produkt,
· Ort,
· Zeit,
· Szenario,
· Kennzahl,
gekennzeichnet sind. Dadurch wird ein fünfdimensionaler Hyperwürfel
definiert.
Abbildung 4 zeigt einen dreidimensionalen Würfel, der die Dimensionen
Zeit, Produkt und Ort besitzt. Die Dimensionen Kennzahlen und Szenario können
in der Abbildung nicht berücksichtigt werden, da es nicht möglich
ist, den fünfdimensionalen Würfel darzustellen. Es ist jedoch möglich
durch Auswahl von genau einem Mitlied der Dimension Kennzahl und der Dimension
Szenario einen dreidimensionalen Würfel zu betrachten.
Jede Dimension kann, basierend auf einem Eltern-Kind-Verhältnis, organisiert
sein. Dabei repräsentiert ein Elternmitglied die Aggregation oder Konsolidierung
von Mitgliedern, welche die Kinder sind. Das Resultat ist eine Hierarchie, wobei
Mitglieder, die den gleichen Abstand zum obersten Elternteil haben, zu einer
Hierarchiestufe (engl. Level) zusammengefaßt werden.
Die aggregierenden Dimensionen sind in diesem Fall die Dimensionen Produkt,
Ort und Zeit.
Besitzt die Dimension Zeit die Hierarchiestufen (siehe Abbildung 5) Jahr, Quartal
und Monat, dann können die Monate zu Quartalen und die Quartale zu Jahren
zusammengefaßt werden.
Die Hierarchiestufe Monat besitzt die Mitglieder Januar, Februar, etc. bis Dezember.
Abb. 6: Zeit Hierarchie
Aus Januar, Februar und März wird das 1.Quartal aggregiert usw. Das Jahr wiederum ist eine Zusammenfassung der vier Quartale.
Die Dimension Ort wird dabei in die Hierachiestufen
· Land,
· Region und
· Geschäft
eingeteilt.
Alle Geschäfte einer bestimmten Region werden nun auch wieder zusammengefaßt
in einem Mitglied der Hierachie Region. Die verschiedenen Regionen werden dann
zu einem Land gruppiert.
Elemente der Hierarchiestufe Region können sein:
· Nord und Süd
Eine andere Möglichkeit ist die Einteilung nach Bundesländern, also
· Niedersachsen, Bayern, Saarland, etc.
Alle Mitglieder einer Stufe besitzen ein Elternmitglied aus den Mitgliedern
über ihnen und eine Menge von Kindern unter ihnen. Die obersten Mitglieder
besitzen kein Elternteil und die Mitglieder der untersten Stufe haben keine
Kinder. Aggregierende Dimensionen besitzen die Eigenschaft, wie eine Baumstruktur
aufgebaut zu sein (siehe Abbildung 5).
Bei einer Anfrage durch eine multidimensionale Abfragesprache an ein Data
Warehouse werden durch eine relationale OLAP-Maschine multidimensionale Anweisungskonstrukte
in eine Sequenz von Standard-SQL-Befehlen transformiert. Dabei werden Mechanismen
zur Transformation der für die Entscheidungsunterstützung relevanten
mehrdimensionalen Konstrukte bereitgestellt.
Ein Beispiel für diese Transformation zeigen folgende Anweisungen. Die
mehrdimensionale Abfrage (MQL) ist ein Vorschlag wie eine solche Anweisung aussehen
könnte:
mql=
(
id=mql_query1 operation = dicing presentation = cross_tab
// Fakten
Kennzahlen=((fact="Dimensions_Tabelle" attr="Verkaufszahlen"))
selection_criteria=()
// Würfel Dimensionen - Darstellung
display=(
(dim="Geschäft" agg="Region" val=() add="Summe")
(dim="Produkt" agg="Abteilung" val=() add="Summe"))
)
Die obige Abfrage beispielhaft eine mehrdimensionale OLAP-Anfrage an ein einfaches
Data Warehouse, welches auf einem herkömmlichen relationalen Datenbanksystem
basiert und mittels eines "Star Schemas" multidimensional modelliert
ist.
In der ersten Zeile der Abfrage wird ihr eine Identifikationsbezeichnung zugeordnet
sowie die Art der Präsentation und Operation angegeben. Aus der Faktentabelle
des Star Schemas wird die Dimension Verkaufszahlen ausgewählt. Die Verkaufszahlen
werden nun nach Produkt und Geschäft aggregiert und angezeigt. Dabei werden
die Produkte nach Abteilung, in der sie verkauft werden, und die Geschäfte
nach Region, in der sie sich befinden, eingeteilt. Zusätzlich werden noch
Zeilen und Spaltensummen berechnet (add = ''Summe"). Der fertig erzeugte
Datenwürfel wird der Visualisierungsschicht übergeben. Die ROLAP-Engine
erzeugt nun SQL Befehle und führt diese auf dem Data Warehouse durch. Die
gefundenen Basisdaten werden zu einem virtuellen Datenwürfel transformiert.
Analog dazu die SQL-Anweisungen:
select
d1.Abteilung, d2.Region, sum(f1.Verkaufszahl)
from
Dimension_Tabelle f1, Produkt d1, Geschäft d2
Where
d1.Produkt_Schlüssel =f1.Produkt_Schlüssel AND d2.Abteilung_Schlüssel=f1.Geschäft_Schlüssel
GROUP BY
d1.Abteilung, d2.Region
ORDER BY
d1.Abteilung, d2.Region
Während bei relationalem OLAP die multidimensionale Abfragesprache noch
in SQL-Anweisungen übersetzt werden muß, erfolgt bei multidimensionalen
OLAP mit der Eingabe der Befehle die Interpretation und Ausführung der
Berechnungen. Wenn wir wie im vorherigen Beispiel die Verkaufsmenge nach
PRODUKT für jedes
GESCHÄFT(Summe VERKAUFSMENGE für jedes PRODUKT eines GESCHÄFTES)
anzeigen wollen, erfolgt das gewünschte Ergebnis nach folgenden Eingabebefehlen
(einer fiktiven Abfragesprache)
ZEIGE TOTAL(Verkaufsmenge nach PRODUKT GESCHÄFT)
Dieser Befehl kann ebenfalls durch eine grafische Präsentation eines multidimensionalen
Datenmodelles durch Anklicken der entsprechenden Symbole der Benutzeroberfläche
erscheinen.
Das Format des Abfrageergebnisses korrespondiert zur Art und Weise, wie die
Daten gespeichert sind (siehe Tabelle 1). Die Ausgabe ist ein unmittelbarer,
also nicht errechneter Wert. Vergleiche und Tendenzen bzgl. des Absatzes werden
hier leicht zu interpretieren sein.
Das Ergebnis könnte etwa so aussehen:
Tab. 2: Aggregierte Verkaufszahlen
Der Unterschied einer multidimensionalen Abfrage mit SQL bei gleichen Daten
an eine relationale Datenbank führt zu folgenden Abfragen:
SELECT Produkt, Geschäft, SUM(VERKAUFSZAHL)
FROM tabelle
GROUP BY Produkt, Geschäft
ORDER BY Produkt, Geschäft
Dies sind die gleichen Daten und die gleiche Anforderung, aber die relationale
Umgebung der Befehlsstruktur ist komplexer und weniger intuitiv.
Das Ergebnis lautet:
Tab. 3: Relationale Ansicht
Durch Anwendung von Report-Writern unter SQL ist es möglich, die Informationen
ein wenig übersichtlicher zu gestalten. Dennoch sind auch bei Report-Writern
wichtige Informationen nicht immer unmittelbar sichtbar. Außerdem erfordert
diese Verbesserung zusätzliche Arbeit beim Modifizieren der SQL Befehle.
Allgemein können folgende möglichen Einsätze für ein Data
Warehousing aufgezählt werden:
· Management-Informationssystem, Berichtswesen
· Vertriebsinformationssystem, Geschäftsanalyse, Trend
· Marketing-Informationssystem, Marktanalyse
· Kundenanalyse, Portfolioanalyse, Marketing-Optimierung
· Kostenstellenanalyse und Controlling
· Analyse und Optimierung der Geschäftsprozesse
· Programmplanung, Produktplanung
· Einkaufssystem (Global Sourcing)
· Lageroptimierung- und verwaltung
· Serviceoptimierung
Für diese Anwendungsgebiete sind vor allem die nachfolgenden ökonomischen
Vorteile von
Bedeutung, da es sich um Grössen handelt, die grosse Sparpotentiale mit
sich bringen.
Viele Benutzer von Datenbanken verlieren eine Menge Zeit bei der Suche nach
den Daten die
sie benötigen. Dazu kommt, falls sie die Daten endlich gefunden haben,
dass diese zu nutzbaren Informationen aufbereitet werden müssen, was nochmals
eine grosse Zeitinvestition bedeutet. Durch ein Data Warehouse hat jeder Benutzer
einen direkten Zugang zu den Informationen die er braucht und ist nicht auf
andere Personen oder Abteilungen angewiesen.
Dass heute die Entscheidungen verbessert und auch schneller gemacht werden können ist unter anderem auch ein Verdienst des Data Warehousing. Die Historisierung der Daten lässt zu, dass Vergleiche zu früheren Perioden und Prognosen für die Zukunft anhand der Daten gemacht werden können. Mit OLAP wird es für Unternehmungen möglich, Entscheidungen bis zu sechs Monate früher zu fällen und dies auf der Grundlage effektiver, sicherer Daten. Es muss aber auch hier nochmals erwähnt werden, dass die Daten nur so gut sind wie sie auch aufbereitet oder eingelesen werden. Ein Data Warehous System allein, bedingt noch keine höhere Datenqualität.
Eine der wichtigsten Gewinn- und Nutzungsmöglichkeiten durch ein Data Warehousing ergibt sich, wenn die Daten für die Optimierung von Prozessen (zum Beispiel der in der Lageroptimierung, Serviceoptimierung oder Produktionsplanung), und zur Unterstützung bei der strategischen Planung eingesetzt werden (vgl. Abbildung 1). Dies sind aber auch die schwierigsten Einsatzmöglichkeiten, da alle Ebenen der Unternehmung, von der Planung im Top Management über Entscheidung bis hin zur Durchführung in operativen Ebene (z.B. Produktion), einbezogen sind. Es ist nicht nur eine sehr komplexe Angelegenheit, es resultieren daraus nicht selten komplette Reorganisationen. Dies ist ein Grund, dass viele Unternehmen diesen grossen Nutzen eines Data Warehousing oft nicht realisieren, ausnutzen oder scheuen.
Abb. 7: Aufgabe des Data Warehouse
Der Data Warehouse Markt ist definitiv aus seinen Kinderjahren herausgewachsen. Ende 1998 betrug er bereits 8 Billionen US$, und der Trend ist nicht nachlassend. Im Forschungsbereich gilt er als eines der heissesten Themen. Das Data Warehouse ist dynamisch und wird sich kontinuierlich weiterentwickeln. Es wird sich so schnell weiterentwickeln, wie sich die betroffenen Unternehmen weiterentwickeln werden. Deshalb müssen Techniken entworfen werden, die flexibel und anpassbar sind.
Anahory, S.; Murray, D.: Data Warehouse: Planung, Implementierung und Administration
Addison-Wesley, Bonn 1997
Inmon, W. H.: Building the Data Warehouse, John Wiley, New York 1992
Holthuis, J.: Multidimensionale Datenstrukturen: Grundkonzept, Funktionalität, Implementierungsaspekte, Gabler, Wiesbaden 1996
Clausen, N. :OLAP Multidimensionale Datenbanken: Produkte, Markt, Funktionsweisen und Implementierung, Addison-Wesley, Bonn 1998
Oehler, K.: OLAP: Grundlagen, Modellierung und Betriebswirtschaftliche Lösungen
Hanser verlag, 2000 München