BI-Datenmanagement (Teil 2): Das Data Warehouse

Das Data Warehouse steht am Ende des ETL-Prozesses. Die dort bereinigten und aufbereiteten operativen Unternehmensdaten werden nach Abschluss in das Data Warehouse (DWH) geladen. Teile des ETL-Prozesses laufen dabei oft schon im Data Warehouse ab. In jedem Fall bildet das DWH eine konsistente, im Idealfall unternehmensweite Datenbasis und stellt große Datenmengen für die Durchführung von Auswertungen und Analysen wie etwa Data Mining bereit.

Im Vordergrund steht beim DWH der Gedanke der Integration und Separation. Die Daten werden aus verteilten, unterschiedlich strukturierten Datenbeständen in ein zentrales Datenlager integriert und ermöglichen so eine globale Sicht auf die Quelldaten. Gleichzeitig werden diese Daten von den operativen, tagesaktuellen Unternehmensdaten separiert und bilden eine eigene, stringente und auf bestimmte Anforderungen hin zugeschnittene Basis.

Oft wird der Begriff des Data Warehouse im Sinn von „Daten-Warenhaus“ verwendet. Dabei steht der Term „Warehouse“ genau genommen für „Lagerhaus“ oder „Speicher“. Dennoch ist das Bild eines Warenhauses oder Handelshauses passend, wenn man den Datenfluss im Unternehmen mit dem Warenfluss im Handel vergleicht.

Der Begriff des Data Warehouses wurde 1993 von dem US-Berater W.H.Inmon geprägt. Er hat DWHs mit den Merkmalen Subjektorientierung, Integration, Zeitraumbezug und Nicht-Volatilität charakterisiert, wie sie bereits im einführenden Artikel erläutert wurden.

Ein konkretes Produkt, etwa eine bestimmte Software, ist ein Data Warehouse nicht. Vielmehr handelt es sich beim DWH eher um ein Konzept. Dessen Umsetzung ist in der Praxis oft ein langwieriger, kontinuierlicher Prozess, der auch als „Data Warehousing“ bezeichnet wird. Als zentrales Erfolgskriterium gilt dabei immer der Nutzen für die Anwender.

Data Warehouse Architektur – Zentral oder dezentral?

Grob gesprochen besteht ein DWH aus einem zentralen Core DWH, einem Meta-Datenbanksystem und den unternehmensinternen und -externen Datenbanken. Das Core DWH bildet die Datenbasis und wird als „DWH im engeren Sinn“ bezeichnet. Dieses Core DWH wird durch die im ETL-Prozess beschriebenen Schritte gebildet.

DWHs sind grundsätzlich entweder zentral oder dezentral ausgerichtet. Im zentralen DWH werden alle Daten punktuell an einem Ort gespeichert und unter der Kontrolle eines einzigen Datenbank-Management-Systems verwaltet. Die Daten müssen jedoch nicht physisch an einem bestimmten Ort gelagert sein, sondern können auch verteilt vorgehalten werden. Ein verteiltes Datenhaltungssystem muss dann aber die zentrale Verwaltung der verteilten Daten übernehmen.

Eine zentrale Lösung hat einige Nachteile. So entstehen beispielsweise oft Skalierbarkeitsprobleme aufgrund der zunehmenden Benutzerzahlen und Datenvolumina, die die Performance des Gesamtsystems beeinträchtigen. Auch ist die grundlegende Konzeption eines zentral angelegten DHWs sehr komplex und fehleranfällig.

Viele Unternehmen bevorzugen deshalb eine dezentrale Ausrichtung. Ein dezentrales DWH besteht aus mehreren isolierten, kleineren DWHs, den Data Marts. Jedes Data Mart besitzt eine eigene Datenhaltung und ist auf die Interessen bestimmter Fachabteilungen zugeschnitten, die auch den Betrieb des Data Marts übernehmen.

Zur Datenhaltung werden oft proprietäre, multidimensionale Datenbanken verwendet, die für den spezifischen Anwendungsbereich performanceoptimiert sind. Allerdings haben auch Data Marts Nachteile. So geht bei dieser dezentralen Ausrichtung die integrierte Sichtweise verloren, was wiederum unternehmensweite Analysen erschwert.

Das Core Data Warehouse

Die zentrale Datenhaltungskomponente und der Kern des DWH ist das Core Data Warehouse mit seiner Datenbasis. Sie enthält die aktuellen und historischen Daten aus allen eingebundenen Unternehmensbereichen in verschiedenen Verdichtungsformen. Hier werden alle Daten zur Weitergabe an eine Vielzahl von Benutzern bereit gestellt.

Vor allem drei Funktionen sollten vom Core DWH erfüllt werden: Erstens, eine Sammel- und Integrationsfunktion. Sie sorgt dafür, dass alle für die Analyse wichtigen Daten in einem zentralen Datenlager bereitgestellt werden. Zweitens, eine Distributionsfunktion. Diese ist dafür zuständig, die Daten eventuell über nachgeschaltete Data Marts zu verteilen. Und drittens eine Auswertungsfunktion. Dabei wird die Datenbasis bereits direkt für Analysen genutzt.

Um diese Funktionen zu erfüllen müssen einige Gestaltungsrichtlinien beachtet und bei der Konzeption festgelegt werden. Dies betrifft vor allem die Datenverdichtung, die Partitionierung und das Datenmodell.

Der Begriff der Datenverdichtung bzw. Granularität wurde bereits des öfteren erwähnt. Daten können in verschiedenen Verdichtungs- bzw. Detallierungsgraden gespeichert werden. Die Speicherung von Summenwerten statt der Einzelwerte führt beispielsweise zu weniger detaillierten Daten. Wenig detaillierte Daten haben eine hohe Granularität, mit steigender Detaillierung wird eine geringere Granularität erreicht.

Aus betriebswirtschaftlicher Sicht ist eine starke Detaillierung der Daten erstrebenswert, da unterschiedliche Analysebedürfnisse bedient werden müssen. Aus IT-Sicht jedoch ist starke Detaillierung nachteilig, da dies IT-Ressourcen wie Speicherbedarf und Verarbeitungsgeschwindigkeit nachteilig beeinflusst.

In der Praxis wird deshalb oft mehrstufige Granularität eingesetzt. Dabei legt man zeitabhängig verschiedene Granularitätsgrade fest. Neuere Daten haben dabei eine niedrige Granularität also eine starke Detailliertheit, ältere Daten eine höhere Granularität bzw. schwächere Datailliertheit. So können mit den aktuellen Daten detaillierte, zeitnahe Auswertungen und Analysen vorgenommen werden. Nach einer bestimmten Zeit, etwa ein oder zwei Monaten, werden die stark detaillierten Daten verdichtet und archiviert.

Core Dataware Warehouse - Partitionierung

Partitionierung oder Fragmentierung ist ein weiteres Merkmal, um die Verarbeitungseffizienz eines DWH zu steigern. Dabei wird der Datenbestand in mehrere kleine, unabhängige Partitionen mit redundanzfreien Daten aufgeteilt. Diese kleinen Partitionen können einfacher verarbeitet werden.

Die Partitionierung kann aus technischer und betriebswirtschaftlicher Sicht erfolgen. Die IT-technische Partitionierung hängt wesentlich vom zu Grunde liegenden Datenbanksystem ab, wobei zwischen Partitionierung auf Systemebene und Partitionierung auf Programmebene unterschieden wird.

Mehr verbreitet ist die betriebswirtschaftliche Aufteilung der Daten. Bei der horizontalen Partitionierung, die vor allem bei der dezentralen Datenhaltung genutzt wird, werden die Unternehmensdaten beispielsweise auf verschiedenen Teilbereiche des Unternehmens oder unterschiedliche Zeiträume aufgesplittet. Dabei sind alle Partitionen durch eine identische Datenstruktur verbunden.

Die vertikale Partitionierung kann in Hinblick auf künftige Auswertungen und Analysen erfolgen und untergliedert beispielsweise die Daten bezüglich unternehmerischer Sachverhalte. Die vertikale Partitionierung entspricht dabei weitgehend den Anforderungen und der Struktur von Analyse-Werkzeugen, wie sie bei der Datenanalyse genutzt werden.

Ob und wie Daten partitioniert werden sollen, muss bereits in der Konzeptionsphase festgelegt werden. In der Praxis weit verbreitet ist die Partitionierung nach Zeiträumen, da so zumindest eine grobe Aufteilung möglich ist.

Core Dataware Warehouse – Datenmodelle und Normalisierung

Ein drittes Merkmal von Core DWHs ist das zugrunde liegende Datenmodell bzw. Datenbanksystem. Meist werden relationale Datenbanksysteme eingesetzt sowie werkzeugunabhängige proprietäre Systeme.

Beide haben ihre spezifischen Vor- und Nachteile. Relationale Systeme sind gut etabliert, weil sie sicher, leistungsfähig und stabil sowie praktisch auf allen Hardware-Plattformen verfügbar sind. Zudem haben sie sich auch bei großen Datenvolumina und hohen Nutzerzahlen in der Praxis bewährt.

Normalerweise strebt man bei relationalen Datenbanken die volle Normalisierung an, also die dritte Codd’sche Normalform (vgl. den Artikel Datenmodelle). Nur so lassen sich Redundanzen und Anomalien vermeiden. Im BI-Kontext werden die Normalitätsstufen aber oft rückgängig gemacht oder gar nicht erst ausgeführt, was als „Denormalisierung“ bezeichnet wird.

Dies hat vor allem praktische Gründe. Mit abnehmender Normalisierung lassen sich nämlich auch die Datenbankzugriffe reduzieren, was zur Entlastung der Hardware und Software führt und das Antwortzeitverhalten verbessert. In Kauf genommen wird dabei ein Anstieg des Speicherplatzbedarf der denormalisierten Daten – Folge der redundanten Daten – sowie ein höherer Aufwand zur Erhaltung der Datenkonsistenz.

In den neunziger Jahren kam auch die vom Erfinder des relationalen Datenmodells, Edgar F. Codd, angestoßene Diskussion auf, ob relationale Systeme das Management generell überhaupt unterstützen können. Codd stand dieser Auffassung skeptisch gegenüber und schlug satt dessen physisch mehrdimensionale Datenhaltungssysteme vor, die eine höherer Performance und Flexibilität böten.

Doch mehrdimensionale Datensysteme sind für große Datenbestände nur in Ausnahmefällen angebracht: Sie sind nicht standardisiert, proprietär und eigenen sich nicht für hohe Nutzerzahlen. Zwar sind sie inzwischen relativ verbreitet, werden aber meist nicht als Infrastruktursysteme im Core DWH eingesetzt. In Data Marts werden sie hingegen häufig eingesetzt, da sie eine werkzeugspezifische, performanceoptimierte Datenhaltung erlauben.

Das dezentrale DWH – Data Marts

Die bereits mehrfache erwähnten Data Marts können als dezentrale DWHs aufgefasst werden, also in kleinere Einheiten zerlegte DWHs. Sie sind gekennzeichnet durch einen engeren Fokus, eine starke Anwendungsorientiertheit und ein deutlich geringeres Datenvolumen im Vergleich zu Core DWHs. Vor allem sind Data Marts auf spezielle Nutzerkreise ausgerichtet.

Data Marts beinhalten damit einen bewusst redundant gehaltenen Ausschnitt des DWH, themenspezifisch zugeschnitten auf eine bestimmte Gruppe. Dadurch erreicht man einen spezifischeren Dateninhalt als im zentralen DWH. Bei diesem Ausschnitt kann es sich zum Beispiel um die Kopie einer speziellen Produktgruppe oder eines bestimmten Zeitabschnitts handeln.

Als dezentral werden Data Marts bezeichnet, weil sie in der jeweiligen Umgebung der Abteilung aufgebaut, verwaltet und genutzt werden können. Die dahinter stehende Technologie ist bei beiden Konzepten freilich die gleiche.

Im Vergleich zu Core DWHs sind Data Marts durch den kleineren Datenbestand leichter zu pflegen. Data Marts werden in der Regel aus den Core DWH befüllt. Bei der Weitergabe sind oft weitere Transformationsprozess erforderlich, bei denen die Daten auf ein höheres Aggregationsniveau verdichtet werden.

Die folgende Tabelle gibt einen Überblick über die wichtigsten Unterschiede zwischen Core DWH und Data Marts.

Core Data Warehouse und Data Marts im Vergleich

Merkmal	Core Data Warehouse	Data Mart
Philosophie	Anwendungsneutral	Anwendungsorientiert
Adressat	Unternehmen	Abteilung
Ziel	Unterstützung aller Entscheider eines Unternehmens	Unterstützung der Entscheider einer Abteilung orientiert an den Analyseanforderungen
Ausrichtung	Zentral, unternehmensweit	Abteilungsbezogen
Anzahl	Eins bzw. wenige	Mehrere
Granularität	Gering aggregierte Daten	Höher aggregierte Daten
Endanwender-Zugriff	Zentraler Betrieb durch IT-Abteilung, Quelldatensystem für Data Marts	Direkter Zugriff
Freiheitsgrade der Analysen	Fexibel, alle Informationen können in die Analyse einfließen	Gering, Anwender ist an Abteilung gebunden
Externe Datenquellen	Hoch, alles verfügbaren externen Quellen werden integriert	Keine oder sehr gering
Datenvolumen	Hoch, 100 GB bis in TeraByte-Bereich	Gering, von ein paar GB bis 100 GB
Datenbanktechnologie	Relational	Multidimensional
Quelle: Nach Kurz (1999), Data Warehouse Enabling Technology, Bonn

Weitere Komponenten eines DWH

Ein DWH umfasst als weitere Komponenten im Bedarfsfall ein Operational Data Store (ODS). Eine ODS enthält aktuelle transaktionsorientierte Daten aus unterschiedlichen Quellsystemen und stellt sie für Analysesysteme bereit. Es kann zur Überbrückung von Zeitspannen, die zwischen zwei Datenentnahmen liegen, genutzt werden.

In ein ODS wird direkt ein kleiner und sehr zeitpunktnaher Teil entscheidungsunterstützender Daten übertragen. Die Daten werden nicht historisiert sondern jeweils durch neue Transaktionen überschrieben. Die Datenstrukturen sind dabei bereits an die Anforderungen der Analysetools angepasst.

Eine weitere Komponente ist die Verwaltung von Metadaten. Die Struktur der gespeicherten DWH-Daten wird in einem separaten Meta-Datenverwaltungssystem beschrieben. Es stellt für alle Anwender eine Art Hilfesystem, bestehend aus Informationskatalog und Navigationsunterstützung bereit. Der Informationskatalog beschreibt die Informationsobjekte in der Terminologie der Endnutzer. Die Navigationshilfe unterstützt ein selbstständiges Navigieren in den Meta-Datenbeständen. Darüber hinaus unterstützt das Meta-Datenbanksystem auch die für den Betrieb des DWH zuständigen Mitarbeiter.

Schließlich bilden Administrations-Schnittstellen einen wichtigen Teil von DWHs, also systemgestützte Zugänge für technische und betriebswirtschaftliche Fachleute. Über die Schnittstellen lassen sich Modifikationen und Erweiterungen im Data Warehouse umsetzen. ODS, Metadaten-Verwaltung und Administrations-Schnittstellen werden in einem eigenen Beitrag weiter behandelt.

Fazit

Die globale Philosophie, die hinter DWHs steckt, ist, Unternehmen besser mit dem Produktionsfaktor Information bzw. Daten zu versorgen. DWHs bilden dabei die Basis, auf die mit analytischen und managementunterstützenden Tools von den Anwendern zugegriffen werden kann.

Zu diesem Zweck speichert ein DWH die im ETL-Prozess aufbereiteten Daten in einem vollständigen, konsistenten Datenbestand. Das Data Warehouse ist dabei strikt von den für das Tagesgeschäft notwendigen operativen Systemen getrennt, die primär für die Verwaltung von Massendaten entwickelt wurden.

Die Speicherung erfolgt entweder zentral oder dezentral. Ein Core DWH hält die Daten zentralisiert vor und verwaltet sie zentral. Es eignet sich vor allem für unternehmensweite Analysen.

Im Gegensatz dazu administrieren Data Marts Daten dezentral. Data Marts unterscheiden sich durch ihren kleineren Fokus vom zentralen DWH und deutlich geringere Datenvolumina. Sie sind zudem auf die sie nutzende Organisationseinheit abgestimmt. (ala)