Ziel einer Datenbank ist es, nicht nur die t�glich anfallenden Gesch�ftsdaten aufzuzeichnen; die gesammelten Datenbest�nden sollen auch in mehr oder weniger regelm��igen Abst�nden ausgewertet werden k�nnen. Bei zunehmenden Datenmengen wird es jedoch immer schwierger Informationen aus diesen (operativen) Datenbanken zu gewinnen. Um z.B. den Umsatz des Vormonats feststellen zu k�nnen, ist es notwendig alle Verkauseintr�ge zu addieren. Bei gro�en Datenbest�nden wird das zust�ndige RDBMS stark belastet. Weiters kann es vorkommen, da� bei sochen Abfragen - aus Konsistenzgr�nden - ganze Tabellen gesperrt werden (locking), was in einem operativen Datenbanksystem zu unakzeptablen Wartezeiten bei den Endbenutzern f�hrt. Abhilfe schafft hier ein Data Warehouse.
Data Warehouse Konzept
Das grundlegende Konzept eines Data Warehouse (DWH) besteht in der Trennung der operativen Daten von den Analysedaten. So ist es Aufgabe der operativen Datenbankmanagementsysteme, das Tagesgesch�ft zu bedienen. Typischerweise greift eine gro�e Zahl von Benutzern auf die operativen Datenbanken zu, die sehr h�ufig kurze Transaktionen durchf�hren. Es werden daher sehr hohe Anforderungen an die Verf�gbarkeit von operativen Datenbanken gestellt. Es haben sich die Gr�nde f�r die Trennung von operativen Daten und Analysedaten, trotz gr��er Leistungsf�higkeit der System, seit der Entwicklung des DWH Systems nicht wesentlich ge�ndert. Heutige DWH Systeme unterst�tzen unter anderem aufwendige online- (OLAP) und multi-dimensionale Analysen.
Anforderungen
Als unternehmensweites Instrument soll ein Data Warehouse s�mtliche Entscheidungstr�ger unterst�tzen. Diese sollen auf m�glichst intuitive Weise zu ihren Informationen finden k�nnen. Beim herk�mmliche relationalen Datenbankmodell st��t man hier schnell an die Grenzen des Durchf�hrbaren. Das multidimensionale Modell bietet in Bezug auf schnelle und einfachere Analyse der Daten entscheidende Vorteile. Aufgabe des DWH ist es unter anderen den Aufbau dieser Datenstrukturen zu unterst�tzen. Es ist auch m�glich, da� allein das Warehouse die geforderten Analysem�glichkeiten bew�ltigen kann - d.h. ohne OLAP - Werkzeuge (OnLine Analytical Processing), die auf die vom DWH aufbereiteten Daten zugreifen.
Datenintegration
Ein DWS macht im Prinzip nur Sinn, wenn es Daten aus mehreren operativen System - auch Flat Files - zusammenf�hren und kombinieren kann.
Durch die notwendige Zusammenf�hrung ergeben sich jedoch eine Reihe neuer Probleme:
Problem der Schl�sselvergabe und dadurch entstehenden Inkonsistenzen (speziell beim Laden von Daten aus Flat- Files)
Auftreten von Redundanzen (mehrfach vorkommende Eintr�ge)
Diese Probleme m�ssen ebenfalls vom DWH gel�st werden k�nnen (datacleansing).
Modellbildung
Die Modellbildung ist der wichtigste Teil beim Aufbau eines DWH. Fehler die in dieser Phase gemacht werden, k�nnnen das gesamte Projekt zu Fall bringen.
Das Gesch�ftsmodell
Der erste Schritt besteht in der Entwicklung eines normalisierten ER- Modelles der ben�tigten Information. Das ist das Gesch�ftsmodell. Zu diesem Zeitpunkt sollte man sich keine Gedanken dar�ber machen, wie man zu dieser Information kommt. Die Konzentration sollte nur auf der Bildung der Struktur der Daten liegen; d.h. auf den Attributen und den Relationen zwischen ihnen. Wenn man z.B. ein Verkaufs- und Marketing DWH aufbaut, sind folgende Fragen wichtig:
Wer kauft das Produkt (Kunden und ihre Struktur)
Wer verkauft das Produkt (Verkaufsorganisationen, Einzelhandel, usw.)
Was wird verkauft (Art der Produkte, Produktgruppen)
Wann wird es verkauft (zeitlliche Struktur)
Wie wird es verkauft (Vertreter, Telefon)
Das so erhaltene Model ist in 3NF. Da die Performance f�r die n�tigen Abfragen sehr schlecht ist, wird es notwendig, dieses Gesch�ftsmodell wieder zu denormalisieren.
Multidimensionale Modell
Ein multidimensionale Modell wird so aufgebaut, da� jede Dimension ein unternehmensrelevantes Merkmal enth�lt. Die einzelnen Zellen dieses so entstandenen n-dimensionalen W�rfels (Cubes) entdhalten die Daten (Facts). Die Darstellung des Cubes erfolgt im DWH als sogenanntes Star- Schema.
Das Star Schema
Das klassische Star Schema ist folgenderma�e charakterisiert:
Eine einzelne "Fact Table" enth�lt einen aus den Primary Keys der "Dimension Tables" zusammengesetzten Schl�ssel und zus�tzliche Spalten f�r numerische Werte (Facts). Die Facts k�nnen auch bereits aggregierte Daten enthalten.
Eine Tabelle f�r jede Dimension, mit einem einzigen k�nstlich erzeugten Schl�ssel. Jede Dimensionstabelle ist bereits hochgradig denormalisiert.
Die einzelne Fact Table enth�lt Detail- Daten, wie z.B. den Verkauf f�r eine bestimmte Zweigstelle, f�r ein bestimmtes Produkt, f�r eine gegeben Zeit/Zeitperiode.
Vorteile:
Modell ist sehr leicht zu verstehen
besitzt eine leicht zu definierende Hierachie
reduziert die Anzahl der physikalischen Joins
geringer Wartungsaufwand
sehr einfache Metadaten
Nachteile:
Summieren von Daten in der Fact Table bedingt einen Performaceverlust f�r summierte Ebenen
gro�e Dimensionstabellen k�nnen zu Problemen f�hren
Das Star Schema wird nur aus Gr�nden der Einfachheit und Zugriffgeschwindigkeit ben�tigt. Beim Erzeugen des Star Schemas m�ssen Sie alles vergessen, was Sie �ber relationale Datenbanken gelernt haben. Die Annahme ist, da� das Star Schema statisch ist, d.h. es werden keine Updates online durchgef�hrt.
Data Marts
Ein Data Mart ist ein Data Warehouse, welches lediglich auf einen Betriebsbereich oder wenige Bereiche beschr�nkt ist. Beispielsweise werden Statistiken �ber den Verbrauch von Spezialwerkzeugen nur von den Organisationseinheiten nachgefragt, die sich mit dieser Problematik besch�ftigen und m�ssen nicht unternehmensweit zur Verf�gung stehen. Data Marts k�nnen die Vorstufe des unternehmensweiten Data Warehouses sein, indem f�r einen Unternehmensbereich ein Data Mart aufgebaut wird, in das nach und nach andere Unternehmensbereiche integriert werden.
Physischer Aufbau
Bei einem wirklichen DWH sind die einzelnen Datenquellen und das Warehouse selbst �ber ein Netzwerk verbunden. Die untere Abbildung zeigt eine m�gliche DWH- Umgebung (am Beispiel von Visual Warehouse).
Beispiel DWH
Hier soll nun an einem einfachen Beispiel der Aufbau eines DWH anhand eines einfachen Beispiels erfolgen. Verwendete Software:
UDB DB2, Oracle: als Sourcedatenbanken
Visual Warehouse: als Data Warehouse
Erstellen der Quell- Daten
Der erste Schritt bestand im Erstellen der Sourcen f�r das Visual Warehouse. Um die F�higkeit der Datenintegration deutlich zu machen, wurden die Ausgangsdaten auf verschiedene Datenbanken (auch unterschiedliche Herstellter) verteilt. Die Datenstruktur und der Vorgang des Ladens ist in der unteren Abbildung dargestellt.
Die Tabelle Verkauf wurde mit je ca. 10.000 Datens�tzen gef�llt. Die Daten in den restlichen Tabellen wurde mit den gleichen Datens�tzen gef�llt; das Beispiel sollte nicht zu kompliziert werden.
Der Ladevorgang
Dies ist der wichtigste Teil beim Aufbau einer DWH. Die Fehler die bei diesem Schritt begangen werden, k�nnen sp�ter zum Scheitern des gesamten Projekts f�hren.
Laden der Quelldaten
Dieser, im Grunde nicht sehr einfache Vorgang, reduzierte sich auf das Laden der einzelnen Source- Datenbanken in eine gemeinsame "Target"- Datenbank. Da Visual Warehouse nicht in der Lage ist gleichzeitig auf verschiedene Datenquellen zuzugreifen, mit geeigneten Werkzeugen (Data Joiner) ist auch dies M�glich.
Beim Laden der Source- Daten, kann bereits eine erste Aggregationen der Daten vorgenommen werden, z.B. angleichen der logischen Datenstruktur oder bereits eine erste Summenbildung.
Buisness Views
Das Laden geschieht im Visual Warehouse �ber sogenannte "Buisness Views"; dabei handelt es sich um Tabellen, die in der Target Datenbank angelegt werden. Mit Hilfe dieser Views erfolgt nicht nur das Laden der Daten, sondern auch die sp�tere Zusammenf�hreng und Weiterbearbeitung. In den Buisness Views geschieht auch die Trennung von den operativen Daten und den Analysedaten.
Zusammenf�hren der Quelldaten
Sind alle ben�tigten Daten in einer Datenbank (Target) geladen, so kann in Visual Warehouse auf sie zugegriffen werden. Es werden nun die einzelnen Tabellen - aus den verschiedenen Sourcen - zu jeweils einer einzigen zusammengefa�t. Diese Tabellen sollen dann sp�ter zusammen mit der Fact-Table das Star-Schema ergeben.
Erstellen des Star - Schemas
Nach der erfolgreichen Zusammenf�hrung der Tabellen, wird der Fact-Table erzeugt, der zusammen mit den Dimension-Tables das Star-Schema bildet.
Das erzeugte Star- Schema ist nun Grundlage f�r die Definition eines geeigneten Cubes f�r die Online Analyse.
