Zusammenfassung
Data Warehouse-Systeme können den Zugriff auf Daten aller Art (inner-, außer- und zwischenbetrieblicher Natur) ermöglichen und Funktionen zur Verarbeitung der Daten anbieten. Innerhalb des Systems nimmt das Data Warehouse selbst die Funktionalität einer Datenbank wahr. Unter Einbeziehung der Ausführungen aus dem Kapitel 2.3 ergibt sich die folgende aufgabenorientierte Definition eines Data Warehouse [nach Gluchowski/Gabriel/Chamoni 97, S. 267]:
Ein Data Warehouse hat die Aufgabe, inhaltsorientiert, integriert und dauerhaft Daten zur Unterstützung von Entscheidem zu sammeln, zu transportieren und zu verteilen.
This is a preview of subscription content, log in via an institution to check access.
Access this chapter
Tax calculation will be finalised at checkout
Purchases are for personal use only
Preview
Unable to display preview. Download preview PDF.
Literatur
In Abschnitt 4.2.3 wird auf externe Informationen eingegangen.
Beispiele für betriebliche Dimensionen werden im nächsten Abschnitt aufgeführt.
Kapitel 4.1 geht auf die verschiedenen DWH-Werkzeugarten ein.
In Abschnitt 3.2.2.1 wird anhand eines DWH-Datenmodells eingegangen auf den datenbanktechnischen Aspekt der Ablage von Dimensionen in der Data Warehouse-Datenbank.
In [Bartmann/Grebe/Kreuzer 98] wird auf einen fortschrittlichen Kundensegmentierungsansatz eingegangen, der auch Anregungen zum Aufbau einer geeigneten Hierarchie gibt.
Tabbert geht auf die Problematik der zeitlichen Aggregation und Disaggregation von Bewegungsdaten sehr ausführlich ein und entwickelt eine umfassende und allgemein verwendbare Lösung, die in Form einer umfangreichen C++ Klassenbibliothek umgesetzt wurde [vgl. Tabbert 96].
Nach einer Schätzung von Kimball können Banken diese Frage nur in etwa 80% der Fälle korrekt beantworten [vgl. Kimball 96, S. 110f]. In der jüngsten Vergangenheit haben sich eine Reihe von Unternehmen mit der Problematik des „Data Cleansing“ auseinandergesetzt und bieten in diesem Bereich umfangreiche Dienstleistungen an. Zum Einsatz kommen hier z.B. Verfahren der Fuzzy-Logic.
Konkrete Beispiele zur Verkettung von Dimensionen und Abfrage der Nutzdaten finden sich in Kapitel 4. Dort wird ebenfalls detailliert auf die verschiedenen Möglichkeiten zur Darstellung der Nutzdaten eingegangen.
Der Aufbewahrungsort der DWH-Metadaten wird auch als Data Dictionary oder als Metadaten-Repository bezeichnet [vgl. Bissantz/Hagedorn/Mertens 96, S. 351; Schreier 96, S. 85; Hufford 97].
Die Beschreibungen der Metadaten des DWH werden im Zuge der Festlegung der Inhalte der DWH-Datenbank von DV-Verantwortlichen und späteren Benutzern zusammen formuliert (vgl. Abschnitt 3.3.1.1). Im Zuge der Abstimmung von DV-Spezialisten und fachlichen Anwendern (und auch der fachlichen Anwender untereinander) werden inkonsistente Fachbegriffe gesammelt und in eine untemehmensweit gültige, in sich konsistente Begriffswelt überführt [vgl. Lehmann/Ellerau 97, S. 2].
Metadaten, welche die fachliche Semantik der Daten beschreiben, werden als betriebswirtschaftliche Metadaten bezeichnet. im DWH. Die Metadaten werden im DWH abgelegt und zur Unterstützung des Benutzers bei der Navigation durch die Dimensionen und die Dimensionshierarchien herangezogen. Die Abfragetools des Benutzers stützen sich bei der Navigation durch die Datenbestände in einem DWH ausschließlich auf die Metadaten.
Die im vorigen Abschnitt skizzierte Dimension „Produkte/ Bankmarktleistungen“ kann durch Metadaten noch weiter detailliert werden: Zu den beleglosen Zahlungsverkehrsleistungen gehören beispielsweise der Datenträgeraustausch, Bargeldautomaten und das Homebanking. Zu den Leistungen der Kreditgewährung gehören beispielsweise: Kontokorrentkredit, Diskontkredit, Ratenkredit, Leasing-Kredit und Kreditkarten-Kredit.
Zu den Data Warehousing-Diensten und den typischen Werkzeugen vgl. Kap. 4.
Umfangreiche Beispiele zur Metadatenbeschreibung der DWH-Datenbasis bieten [lnmon/Zachman/Geiger 97, S. 253ff].
Zu den Datenverantwortlichen vgl. Abschnitt 3.3.2.1.
In Kapitel 3.5 werden die verschiedenen Gestaltungsmöglichkeiten von Data Warehouse-Systemen beschrieben. Zur Verdeutlichung werden dort praxisrelevante Softwarearchitekturen dargestellt und klassifiziert.
Die Bezeichnung „OLAP-Server“ (oft auch OLAP-Engine) wird häufig im Zusammenhang mit der Verwendung von multidimensionalen DBMS gebraucht. Bei Verwendung von relationalen DBMS spricht man auch oft von sogenannten „Star-Servern”. Auf die Abgrenzung der unterschiedlichen DBMS wird später ausführlich eingegangen. Im folgenden wird das zugrundeliegende DBMS nicht mehr als Einteilungskriterium herangezogen. Der im weiteren Verlauf dieser Arbeit ausschließlich verwendete Begriff „OLAP-Server“ unterwirft sich nicht der o.e. Einteilung und kennzeichnet eine Systemkomponente, welche sich auch in einem System mit zugrundeliegendem relationalen DBMS wiederfinden kann.
Die Fa. Sybase bietet mit ihrem Produkt „Sybase IQ“ ein auf den DWH-Einsatz hin optimiertes rDBMS an.
Reuter geht detailliert auf die verschiedenen Einsatzfelder von rDBMS und mDBMS ein [vgl. Reuter 96].
Die folgenden Beispiele lehnen sich an die in Abschnitt 3.1.1 vorgeschlagenen Dimensionen an. Tab. 3.1 beschreibt exemplarisch die Dimension „Zeit“ als Datenbankrelation. Die anderen Datenbankrelationen gestalten sich gemäß dem Beispiel 3.1.
Eine Dimension an sich ist nicht „dünn besetzt“ [vergleiche im Gegensatz hierzu Hettler 97, S. 132].
Die Definition von „großen“ Data Warehouse-Datenbanken ist uneinheitlich. Es wird davon ausgegangen, daß ein Datenvolumen von über einem Terabyte von einem mDBMS nicht mehr gehandhabt werden kann. Oft wird die Datenobergrenze einer physischen multidimensionalen Datenbank schon sehr viel früher gezogen [vgl. Schreier 96, S. 88ff]. Die Meta Group sieht beispielsweise die Obergrenze für den Einsatz von M DBMS schon bei einem Volumen von 40 Gigabyte [vgl. o.V. 97g]. Korrekterweise muß angefügt werden, daß solche Äußerungen oft vor unsachlichem Hintergrund getätigt werden oder falsch interpretiert werden. Richtiger ist es, die Größe der umfangreichsten Dimension in ihrem Verhältnis zu den kleinsten Dimensionen im Data Warehouse als Maßstab anzusetzen. Ist die größte Dimension erheblich größer als die kleinste Dimension, ergeben sich im DWH Verzerrungen weg vorn Idealbild des „einigermaßen symmetrischen” Datenwürfels hin zu „flacheren“ Strukturen, die mit der optimierten Technologie eines rDBMS sicher besser gehandhabt werden können. Diese Voraussetzungen sind häufig in sehr großen oder auch sehr spezialisierten DWH erfüllt.
Ausführliche Kritik an der Codd’schen Aussage übt Thomsen 97, S. 497ff.
DWH-Systeme mit solch enger Bindung sind etwa bei Komplettlösungen eines Herstellers zu finden. In Abschnitt 3.5.1 werden die verschiedenen Softwareschichten eines DWH-Systems näher betrachtet.
Data Warehouse-Systeme, die in operative Systeme eingebunden sind, werden unter der Bezeichnung „Second Generation Data Warehouse“ zusammengefaßt. Ein wesentliches Merkmal dieser Systeme ist die Erweiterung der reinen DWH-Datenbank um einen sogenannten Operational Data Store (ODS).
Raden bezeichnet den klassischen read-only-OLAP-Zugriff auf DWH-Daten als „Narrow OLAP“ und grenzt dazu den vor allem im Rahmen mit Data Mart-Lösungen gelegentlich anzutreffenden „Broad-OLAP”-Ansatz ab. Im Vordergrund des „Broad OLAP“ steht dabei nicht die Möglichkeit, Datenveränderungen vorzunehmen, sondern vielmehr die Einbindung von komplexen Methoden der Trendanalyse, Zeitreihenprognose usw. [vgl. Raden 97, S. 209f].
Die Funktionalität des OLAP-Servers ist oft nicht von der DBMS-Funktionalität getrennt.
Beispielsweise für das Marketing oder das Controlling. Architekturrahmen fir Data Marts [vgl. Kapitel 3.5.2.2; Mimno 97, S. 168ff; Inmon/Zachman/Geiger 97, S. 24–37]. Je nach der verwendeten Datenbankmaschine wird in der Literatur das Online Analytical Processing oft in MOLAP (physisch multidimensionales OLAP, auch POLAP) und ROLAP (relationales OLAP) unterteilt. Während diese Unterteilung vor einigen Jahren aufgrund der eingeschränkten OLAP-Tauglichkeit eines auf einem relationalen DBMS basierenden Systems noch ihre Berechtigung gehabt haben mochte, werden heute oft nur noch zu Marketingzwecken die „MOLAPFähigkeiten“ in den Vordergrund geschoben.
Kann bei einer nationalen DWH-Datenbank leicht im Zuge der Nacht oder des Wochenendes ein Update durchgeführt werden, ergibt sich bei Zugriffen aus verschiedenen Zeitzonen meist das Problem eines „zu kleinen“ Zeitfensters. Das Transaktionskonzept verschafft hier den rDBMS-basierten DWH-Systemen gegenüber den mDBMS-basierten Systemen einen Vorteil.
Das Bestandteile des Data Load-Systems werden vielfach auch als ETL-Werkzeuge bezeichnet. ETL steht hierbei für Extraction, Transformation und Load.
ln einer repräsentativen Untersuchung unter Mitarbeitern aus den Fachabteilungen verschiedener Unternehmen ging die Mehrzahl der befragten Personen von der Notwendigkeit eines täglichen Refresh der Data Warehouse-Datenbank aus [vgl. Fasching 95, S. 255–262; Breitner/Herzog 96, S. 46].
Obwohl die Qualität der Daten im DWH unbestreitbar von hohem Wert für die Unternehmung ist, sollte der „Grad der Datenwahrheit“ sich am Kosten- Nutzen-Verhältnis orientieren. Beispielsweise wird ein falscher oder fehlender Fact-Wert in einem Datensatz auf einer niedrigen Hierarchieebene bei einer Abfrage nach aggregierten Daten zumeist keinen „großen” Schaden anrichten. Bei sporadischen Umsatzverläufen gewinnt ein Fehler bei detaillierter Betrachtung dagegen schon sehr an Bedeutung.
Der aufgeführte Data Load beschränkt sich auf den Einsatz in mehrschichtigen Softwarearchitekturen, die in Abschnitt 3.5.1 ausführlich beschrieben werden.
Nach Expertenschätzungen sind heutzutage immer noch mehr als 70 Prozent der Unternehmensdaten in nichtrelationalen Datenbanken auf Legacy-Systemen abgelegt [vgl. Kalakota/Whinston 96, S. 468].
Die ACID-Bedingungen (Atomicity, Consistency, Isolation, Durability) müssen zur Abwicklung von elementaren rücksetzbaren Transaktionen eingehalten werden [vgl. Ferstl/Sinz 93, S. 350f]. blem dar. Sind - wie oben bereits angesprochen - die Quelldatenformate nicht bekannt, so ist der Einsatz von unterschiedlichen aufwendigen Extraktionswerkzeugen erforderlich [vgl. Mimno 97, S. 170ff].
Die Inhalte einer Vielzahl von unterschiedlichen DBMS-Typen abzugleichen bedeutet einen sehr großen Aufwand. Zur Sicherung einer konsistenten DWH-Datenbasis müssen die Attribute jedes einzelnen beteiligten Quellsystems in ihrer Bedeutung abgeglichen und in ihrem Umfang bereinigt werden. Man spricht in diesem Zusammenhang vom „Daten-schrubben“ (Data Scrubbing). Die New York Chase Manhattan Bank hatte beim Start ihres DWH-Projektes die Inhalte von 54 verschiedenen Datenbasen (die zum großen Teil von unterschiedlichen DBMS verwaltet wurden) und Flat Files abzugleichen [vgl. Rother 95, S. 3].
Innerhalb eines Data Warehouse-Projektes wird der Planung und Durchführung der Datenübernahme aus den Quellsystemen mit Abstand der größte zeitliche und damit auch monetäre Aufwand zugerechnet [vgl. Devlin 97, S. 21; Schinzer 97]. wortlichen sind zur zügigen Realisierung des Projektes die Inhalte des DWH festzulegen. In der Regel erfreuen sich DWH-Systeme nach erfolgreicher Implementation eines großen Zuspruchs von seiten der Benutzer. Die neuen Anforderungen bezüglich Ergänzungen und Erweiterungen des Systems müssen gesammelt und regelmäßi§ von einer Institution in die Pläne zum Ausbau des DWH eingearbeitet werden8. Ein DWH lebt von der Akzeptanz seiner Benutzer. Die Inhalte des DWH werden dementsprechend im Zeitablauf ständig angepaßt werden müssen.
Die Einrichtung und auch die laufende Planung der Inhalte eines Data Warehouse müssen einer festen Institution unterliegen. Kimball definiert dazu verschiedene Stellen [vgl. Kimball 96, S. 228f].
In der Praxis wird dies mit der Bezeichnung „User-Centric Warehousing“ umschrieben.
Die in diesem Abschnitt aufgeführten Methoden zur Bestimmung und Auswertung des Informationsbedarfs wurden unter anderem ausgewählt nach einer im Februar 1997 durchgeführten Maillist-Diskussion mit neun Experten im Data Warehouse-Bereich.
Eine der ersten Data Warehouse-Implementationen im europäischen Bankbereich wurde um 1990 von der niederländischen ABN AMRO Bank abgeschlossen. Besonders großer Wert wurde bei der Implementierung auf die Erfüllung der Benutzerbedürfnisse gelegt. Das DWH-System wurde schon vom Start weg gut angenommen und konnte in den Folgejahren eine jährliche Steigerung der Nutzung von ca. 50% verzeichnen [vgl. Devlin 97, S. 13]. ken [vgl. Rockart 79; Heinrich 92, S. 325ff; Bullinger/Niemeyer/Koll 93, S. 56].
Zu den bankinternen operativen Quellsystemen zählen beispielsweise unter anderem die verschiedenen Abrechnungs-und Buchungssysteme, das Personalsystem, Kundenkontaktsysteme, Systeme zur Bereichs-Ergebnisrechnung und zur Kostenstellenrechnung.
Zur Entwicklung und Weiterentwicklung eines Data Warehouse-Systems werden verschiedene spezielle Software Lifecycle-Modelle vorgeschlagen [vgl. B.Devlin, Bullinger et al. 95].
Eine DV-zentrierte Denkweise führte in den siebziger Jahre in die MIS-Krise („Wenn die Fachabteilungen diese Funktionen/Daten haben, werde sie diese schon verwenden“).
Oben wurde bereits diese Bildung von „lokaler DV-Kompetenz“ als eine der Ursachen zur Entwicklung des „Spider Net Environment” erkannt (vgl. Abschnitt 2.3.1).
In Abschnitt 3.2.2.2 wurde darauf hingewiesen, daß physisch multidimensionale DBMS sehr häufig ebenfalls Funkionen eines OLAP-Servers übernehmen und deshalb auch oft einfach als OLAP-Server bezeichnet werden.
Dies ist gleichbedeutend mit dem Übergang vom „Fat Client“ zum „Thin Client” (vgl. Abschnitt 3.5.1). Diese auch als „Client-Server-Systeme“ diskutierten, gemischten Architekturen lassen sich in mehrere Schichten unterteilen [vgl. Gluchowski/Gabriel/Chamoni 97, S. 113ff; SaylorBansal 95, S. 5f; Meyer 93, S. 81ff]
Dies ist regelmäßig bei Programmen unter der graphischen Benutzeroberfläche Windows der Fall.
Eine Aufteilung in drei Schichten bietet große Vorteile bezüglich Administrierbarkeit, Sicherheit, Skalierbarkeit und Leistungsfähigkeit.
In Abschnitt 3.2.2 wurde bereits beispielhaft auf das mDBMS eingegangen. Dieses kann häufig die Trennung zwischen Präsentations-und Applikationsschicht nicht durchgängig aufrechterhalten. Die sich daraus ergebende mangelnde Skalierbarkeit kann Leistungseinbußen nach sich ziehen. Kommt ein relationales Datenbanksystem zum Einsatz, verwendet der OLAP-Server die Sprache SQL zur Anforderungen von Daten aus der DWH-Datenbank. Die Daten werden vom rDBMS als eine Menge von Datensätzen zurückgeliefert. Bei Einsatz von mDBMS wird die Datenanforderung mittels eines proprietären Abfrageprotokolls vorgenommen (vgl. Abschnitt 3.2.2.2). Die Datenlieferung erfolgt meist als multidimensionale Menge von Feldern.
Beispiele zur DWH-Datenmodellierung bei Verwendung eines rDBMS finden sich in Abschnitt 3.2.2.1.
Vgl. Beschreibung des PDES bzw. ETL in Abschnitt 3.2.3.
Devlin spricht in diesem Zusammenhang von „reconciled data“, von „in Einklang” gebrachte Daten [vgl. Devlin 97, S. 69ff].
Die von Devlin vorgeschlagene dreischichtige DWH-Datenarchitektur wird heute noch kaum eingesetzt [vgl. Devlin 97, S. 68]. Die Umsetzbarkeit einer UDM wird vielfach angezweifelt [vgl. Sinz 95].
Ein in einer Bank eingesetztes Data Mart-System zur Analyse von Kreditkartendaten mit einer Datenbankgröße von mehreren hundert Gigabytes wird wegen der extremen funktionalen Fokussierung nicht als Data Warehouse verstanden.
Eingesetzt wurde der Microsoft SQL Server in der Version 6.5.
RMI (Remote Method invocation) ist fester Bestandteil des Java Development Kit (JDK) ab der Version 1.1 und ermöglicht den Aufbau von JAVA-basierten Client-ServerSystemen [vgl. Lipp 98, S. 31 ff].
Die JDBC-Schnittstelle ist im Prinzip vergleichbar mit der ODBC-Schnittstelle der Fa. Microsoft (Open Database Connectivity) und ist standardmäßig ab der Version 1.1 im JDK enthalten [vgl. Lipp 98, S. 34ff].
Author information
Authors and Affiliations
Rights and permissions
Copyright information
© 2000 Springer-Verlag Berlin Heidelberg
About this chapter
Cite this chapter
Gehrke, C. (2000). Das Data Warehouse: Aufbau und Betrieb. In: Informationsagenten im Data Warehousing. Bankinformatik-Studien, vol 7. Physica, Heidelberg. https://doi.org/10.1007/978-3-662-12065-1_3
Download citation
DOI: https://doi.org/10.1007/978-3-662-12065-1_3
Publisher Name: Physica, Heidelberg
Print ISBN: 978-3-7908-1301-2
Online ISBN: 978-3-662-12065-1
eBook Packages: Springer Book Archive