Data Warehouse
1. Überblick
Die Unternehmen sind heute im Besitz einer Vielzahl von Daten. Seit vielen Jahren wurden Datenbanken auf- und ausgebaut, die die Ergebnisse des täglich ablaufenden Geschäftsprozesses dokumentieren. Die Situation ist jedoch gekennzeichnet durch eine steigende Datenflut bei gleichzeitigem Informationsdefizit. Was fehlt, ist die richtige Information zur richtigen Zeit am richtigen Ort. Häufig kostet es mehr, die in den verschiedenen EDV-Systemen gehaltenen Daten zu pflegen und zu warten, als man durch Analyse dieser Daten an Nutzen gewinnt. Seit einiger Zeit bietet die Informationslogistik zur Lösung dieses Problems einen Ansatz, bei dem die Informationen als ein Produktionsfaktor betrachtet werden. Angestrebt wird hierbei eine Art "Informationspool" als Datenzentrum im Unternehmen.
Bereits im Jahre 1988 wurde dieses Konzept des unternehmensweiten Datenpools von der Firma IBM im Rahmen der EBIS-Architektur (European Business Informations Systems) vorgestellt. Mit diesem Konzept sollte der Zugang zu unterschiedlichen Systemen über eine einheitliche Schnittstelle möglich sein. Der zu diesem Konzept gehörende Begriff "Data Warehouse" wurde einige Zeit später insbesondere von dem amerikanischen Berater William Immon geprägt, dessen 1993 veröffentlichtes Buch inzwischen den Ruf eines Standardwerkes hat.
Um die Daten verfügbar zu machen,
werden sie von den operativen Systemen in das Data Warehouse
eingespielt. Von dort können die Informationen über Management
Support Systeme abgerufen werden. Somit beinhaltet das Data
Warehouse-Konzept die Problematik der Informationsversorgung von
Managementunterstützungssystemen. Es soll die Qualität,
Integrität und Konsistenz des zugrundeliegenden Datenmaterials
sicherstellen.
Die Architektur eines Data
Warehouse besteht im wesentlichen aus den folgenden
zusammenwirkenden Komponenten: Das Data Warehouse speichert die
Daten und Informationen zusätzlich zur
Datenhaltung in den operativen Systemen ab. Das ist notwendig,
weil das direkte Zugreifen auf operative Systeme zum Zweck der
Analyse mit einer Reihe von Problemen verbunden ist. Zum einen
sind die Datenmodelle operativer Systeme nicht
fachabteilungsgerecht gestaltet, sondern genügen den
Anforderungen der Transaktionsverarbeitung. Zum anderen führt
eine Datenanalyse in Transaktionssystemen häufig zu erheblichen
Performanceverlusten, so daß aus Informatiker-Sicht die Systeme
für Fachabteilung nicht freigegeben werden. Darüber hinaus sind
operative Systeme für Analysezwecke häufig schon deswegen nur
eingeschränkt nutzbar, weil sie keine historischen Daten
enthalten und aufgrund des operativen Charakters dieser Systeme
keine Reproduzierbarkeit der Analyse gegeben ist (die gleiche
Abfrage zu unterschiedlichen Zeiten führt teilweise auch zu
unterschiedlichen Abfrageergebnissen). Bei der Gestaltung eines Data
Warehouse sollten folgende Gesichtspunkte berücksichtigt werden: Nicht zum Data Warehouse im
engeren Sinne gehören das Data Mart und das virtuelle Data
Warehouse. Ein Data Mart stellt ein
Data Warehouse dar, welches lediglich auf einen Betriebsbereich
oder wenige Betriebsbereiche beschränkt ist. Data Marts können
aber die Vorstufe zu einem unternehmensweiten Data Warehouse
sein, indem für einen Unternehmensbereich ein Data Mart
aufgebaut wird, in das nach und nach andere Unternehmensbereiche
integriert werden. Gegenüber bereichsübergreifenden Lösungen
finden Data Marts oft den Vorzug, da sie in relativ kurzer Zeit
zu vergleichsweise geringen Kosten realisiert werden können. Die
bei der Einführung und beim Betrieb gemachten Erfahrungen werden
gesammelt, und es wird Wissen aufgebaut, das bei
Erweiterungsprojekten zur Verfügung steht. Ein virtuelles Data Warehouse
legt eine Oberfläche über alle Datenbestände der operativen
Systeme und vermittelt hierdurch den Eindruck, die Abfragen
würden an einem anderen System ausgeführt. Hierdurch treten
jedoch häufig Performanceprobleme auf, da die
Auswertungsabfragen das operative System stark belasten. Bei der
Konstruktion eines virtuellen Data Warehouse finden
dementsprechend die beiden Hauptgesichtspunkte, die für die
Errichtung eines Data Warehouse sprechen (Entlastung der
operativen Systeme und Integration mehrerer Datenbasen), keine
Beachtung. Der Vorteil liegt lediglich in der optimierten
Zugriffsmöglichkeit des Endanwenders auf das Datenmaterial der
operativen Systeme. 2. Transformationsprogramme Die unternehmensinternen und
firmenexternen Daten werden durch Transformationsprogramme ins
Data Warehouse übernommen. Die internen Daten stammen dabei fast
ausschließlich aus den operativen Systemen. Da in Unternehmen
häufig mehrere Systeme eingesetzt werden, liegen zum großen
Teil unterschiedliche Datenstrukturen vor, so daß die Daten
zunächst durch eine Transformation in ein einheitliches
Format gebracht werden müssen. Externe Daten werden
beispielsweise von Wirtschaftsverbänden oder
Marktforschungsinstituten zur Verfügung gestellt. Auch hier ist
im allgemeinen der Einsatz von Transformationsprogrammen
erforderlich. Wegen der Vielzahl der heute in
Unternehmen eingesetzten Systeme und der daraus resultierenden
unterschiedlichen Datenformate sind immer aufwendigere
Transformationen erforderlich. Beispielsweise können für das
Attribut Geschlecht die Abkürzungen "m" für männlich
oder "w" für weiblich, aber beispielsweise auch die
Zahlen "0" und "1" verwendet werden. Noch
sehr viel extremer ist diese Problematik, wenn es darum geht,
Datumswerte abzuspeichern. Die Häufigkeit, mit der die Daten
aktualisiert werden, richtet sich nach den
unternehmensindividuellen Anforderungen. Nur wenn tagesaktuelle
Daten benötigt werden, erfolgt die Datenübernahme ebenfalls
täglich (in der Regel nachts), ansonsten wöchentlich oder
monatlich. Unabhängig von diesen regelmäßigen Aktualisierungen
wird bei der Einrichtung eines Data Warehouse ein großer Teil
von Altdaten übernommen, die sich meistens aus bereits
archivierten Datenbeständen zusammensetzen. 3. Metadaten Der Wert des Data Warehouse wird
durch seinen integrierten Datenspeicher repräsentiert. Durch
verschiedene Tools können die Benutzer selbständig auf die dort
gespeicherten Informationen zugreifen und diese analysieren.
Allerdings müssen die Benutzer hierzu wissen, welche
Informationen ihnen zur Verfügung stehen, das heißt, sie
benötigen einen Informationskatalog, in dem die Metadaten,
also die Daten über die Daten, in einer für sie verständlichen
Form beschrieben werden. Der Funktionsumfang eines solchen
Informationskatalogs geht über den eines herkömmlichen Data
Dictionarys weit hinaus, denn er enthält auch diverse
DV-technische und betriebswirtschaftliche Informationen.
Beispielsweise werden durch Metadaten beschrieben: 4. Data Mining Das Data Warehouse stellt die
relevanten Unternehmensdaten mit neutral angelegten Datensätzen
auf relativ niedriger Verdichtungsstufe zur Verfügung und bildet
so die Grundlage für leistungsfähige Instrumente der
Datenanalyse, wie zum Beispiel das Data Mining. Aufgabe
des Data Mining ist die Filterung der Daten, um sie für eine
weitergehende Analyse vorzubereiten. Die einfachste Form der Filter
sind sogenannte Schwellen, die bei starrer Form (starre
Schwellen) feste Werte vorgeben (absolut oder relativ), bei
deren Über- oder Unterschreitung eine Ausgabe oder Meldung
(beispielsweise durch farbliche Kennung) erfolgt. Von variablen
Schwellen wird gesprochen, wenn der Schwellenwert vom Kontext
(beispielsweise Saisonfaktoren) abhängt. Adaptive Schwellen
orientieren sich an der Verteilung der tatsächlich auftretenden
Abweichungen, so daß beispielsweise berücksichtigt wird, daß
eine 10prozentige Umsatzschwankung auf Artikelebene anders zu
deuten ist als eine gleichhohe Schwankung auf Warengruppenebene. Mit Hilfe von Rankings
werden Hilfslisten aufgestellt die nur die n größten
Plan-Ist-Abweichungen anzeigen. Flexible Methoden des Ranking
erlauben das Anzeigen nur der wichtigsten Abweichungen. Eine
Kombination der Filterung mittels Schwellen mit den Methoden des
Ranking erlaubt bereits eine vieldimensionale Navigation in den
vorhandenen Datenbeständen. Mit der Datenmustererkennung
(DME) wird versucht, ohne Einschränkung des Suchraums
wesentliche Auffälligkeiten in den Datenbeständen ausfindig zu
machen. Solche Auffälligkeiten ergeben sich als eine Häufung
von Datensätzen mit ähnlicher Aussage. 5. OLAP- und ROLAP-Technologie Einfache Abfrage-Werkzeuge stoßen
in großen Data Warehouse-Umgebungen sehr schnell an die Grenzen
ihrer Leistungsfähigkeit. Um den Performance- und
Analyseproblemen gerecht zu werden, wurden in der Vergangenheit
von einigen Anbietern spezielle Technologien entwickelt, die für
solche Abfragen optimiert wurden. Heute erleben diese Werkzeuge
unter dem Begriff Online Analytical Processing
einen erneuten Aufschwung gerade im Hinblick auf das Data
Warehousing. Da mit dem Data Warehouse eine
separate Systemarchitektur angestrebt wird, können die
bisherigen Sachzusammenhänge der operativen Daten neu, in
sogenannten Dimensionen (Produkte, Kunden, Regionen, Zeit, ....)
dargestellt werden. Diese Technologie erlaubt eine natürliche
Sicht auf die Daten und damit schnellere und komplexere Abfragen.
Solche Dimensionen stellen den Kernpunkt dessen dar, was man
heute unter OLAP versteht. Letztendlich handelt es sich
beim OLAP um eine Technik, die es dem jeweiligen Anwender
erlaubt, sich mittels eines interaktiven Zugriffs auf eine
Vielzahl von Sichten und Darstellungsweisen von Basisdaten einen
schnellen Einblick zu verschaffen. Durch OLAP bekommt der
Endbenutzer die Möglichkeit, durch die Informationsbasis des
Unternehmens zu navigieren und detaillierte (Drill-Down)
beziehungsweise aggregierte (Roll-Up) betriebswirtschaftliche
Daten zu betrachten. OLAP-Systeme, die als Basis die
multidimensionale Sicht der relationalen Datenbanken verwenden,
werden als Relational-OLAP (ROLAP) bezeichnet. Die
relationalen Tabellen bilden die Dimensionen in ein
denormalisiertes sogenanntes "Star Schema" ab,
dessen Layout sich erheblich von einer für operative Zwecke
modellierten Datenbank unterscheidet. Werden die
Dimensions-Tabellen in kleinere Dimensionen zerlegt, erhält man
ein "Snowflake Schema". Mit Hilfe einer intuitiven
multidimensionalen Schnittstelle hat der Endbenutzer durch
ROLAP-Systeme die Möglichkeit, seine Abfragen ohne detaillierte
EDV-Kenntnisse zu formulieren und an ein ROLAP weiterzuschicken.
Die Abfragen werden in entsprechende SQL-Statements
umgesetzt, die die angeforderten Daten aus dem Data Warehouse
holen und dann in der gewünschten Form zur Verfügung stellen. 6. Technische Realisierung
eines Data Warehouse Es existieren unterschiedliche
Ansichten darüber, welche Größenordnungen ein Data Warehouse
erreichen kann oder sollte. Heute kann ein unternehmensweites
Data Warehouse durchaus den operativen Datenbestand in seiner
Größe übersteigen und auf ein Datenvolumen von mehreren
Terabyte anwachsen. Durch die Leistungssteigerungen
von Client-/Server-Systemen verliert der Mainframe als
Hardware-Plattform weiterhin an Bedeutung. Neben der
Hardwareausstattung sind vor allem die eingesetzten
Betriebssysteme, Datenbanken und Analysetools determinierend für
die Leistungsfähigkeit des Data Warehouse. Weitgehende Einigkeit
besteht darüber, daß der Trend weg von proprietären Systemen
hin zu Standard-Datenbankmanagementsystemen geht, da diese mehr
Flexibilität und damit eine höhere Plattformverfügbarkeit und
Investitionssicherheit bieten. Um Datenanalysen performant
betreiben zu können, ist eine skalierbare, parallele
Datenbankarchitektur erforderlich, die die neuen Generationen
leistungsfähiger symmetrischer Multiprozessor-Systeme (SMP),
lose gekoppelter Cluster-Systeme sowie massiv paralleler Systeme
(MPP) vollständig und skalierbar unterstützt. Zur weiteren
Performancesteigerung können verschiedene Techniken eingesetzt
werden, von denen die Verdichtung/Aggregation und das sogenannte
Sampling als Beispiele kurz vorgestellt werden. 6.1 Verdichtung/Aggregation Bei der Aggregation handelt es
sich um einen Prozeß, bei dem zahlreiche Daten kleinerer
Granularität summiert und in temporären Tabellen als
sogenanntes Aggregat abgelegt werden. Diese verdichteten
Informationen stehen dann allen anderen Anwendern zur weiteren
Bearbeitung zur Verfügung, so daß die entsprechenden Abfragen
nicht mehrfach (für jede einzelne Anfrage erneut) ausgeführt
werden müssen. Auf diese Weise müssen beispielsweise
Monatsreports nicht mehr auf einzelne Tageswerte zugreifen,
sondern können als Datenbasis die temporären Tabellen
verwenden. Selbst bei perfektem Tuning eines
Data Warehouse-Systems benötigt die Summierung von einigen
Millionen Zeilen eine gewisse Zeit, angefangen von reinen
Lesevorgängen von der Platte bis zur Sortierung der
Endergebnisse. Da im allgemeinen aber eine größere Anzahl von
Abfragen summierte Daten verlangt, ist eine vorsummierte
Datenmenge entlang der hierarchischen Ordnung - wie in obiger
Abbildung dargestellt - aus Performanceüberlegungen sehr
hilfreich. 6.2 Sampling Viele Abfragen in einem Data
Warehouse fragen nach bestimmten Informationen, um sich zunächst
einen Überblick über einen bestimmten Sachverhalt zu
verschaffen. Häufig starten solche Abfragen auf sehr hohem
Niveau und betreffen dann mehrere Millionen Datenwerte, die so
gar nicht notwendig wären, um einen "ersten Eindruck von
den Daten" zu bekommen. Beim sogenannten Sampling
werden daher Ausschnitte von Daten kleinerer Granularität
gebildet und in temporären Tabellen als
"Stichprobenmenge", ähnlich einer Wahlprognose,
abgelegt. Diese Sampling-Informationen stehen dann wiederum allen
anderen Applikationen zur weiteren Nutzung zur Verfügung. 7. Zusammenfassung Die Trennung in operatives System
und Data Warehouse entlastet das operative System und bietet die
Möglichkeit, interne und externe Datenquellen zu integrieren.
Durch die Subjektorientierung und Mehrdimensionalität kann bei
Verwendung von entsprechenden Abfragewerkzeugen das Navigieren
durch den Datenbestand des Unternehmens wesentlich erleichtert
werden. Copyright © 2000 Homepage: http://www.mkonetzny.de
Charakteristika
Operative
Datenbanken
Informative
Datenbanken
Transaktionsvolumen
hohes
Volumen
niedriges
bis mittleres Volumen
Antwortzeit
sehr
schnell (im Sekun-denbereich)
normal,
in Einzelfällen bis zu mehreren Minuten
Update
permanent
niedrige
Frequenz, teilweise monatlich
Betrachtungsperiode
aktuelle
Periode
Vergangenheit
bis Zukunft
Umfang
andwendungsintern
anwendungsübergreifend
Aktivitäten
operativ,
detailliert
analytisch
Abfragen
vorhersehbar,
periodisch
unvorhersehbar,
ad hoc
Niveau
der Daten
detailliert
aggregiert,
aufbereitet
Verarbeitungseinheit
Datensatz
(record), eindimensional
Matrizen
(array), multidimensional, sachbezogen
Zeithorizont
1-3
Monate
mehrere
Jahre bis Jahrzehnte
Datenaktualität
permanent
gegeben
nur
nach Updates gegeben