Integration von Unternehmungsdaten über Data Warehouses
Werbung
Institut für Wirtschaftsinformatik Prof. Dr. Michael Breitner Wirtschaftswissenschaftliche Fakultät Universität Hannover Integration von Unternehmungsdaten über Data Warehouses (Konzept, Architektur, Realisierung) Autor: Betreuer: Rahmenthema: Semester: Thorben Sandner Dipl.-Ök. Christian Schubert „Standard- und Individualsoftware: Einsatzmöglichkeiten, Vor- und Nachteile“ Wintersemester 2003/2004 -I- Inhaltsverzeichnis Seite Abbildungsverzeichnis ............................................................................................................ II Abkürzungsverzeichnis......................................................................................................... III 1 Einleitung .......................................................................................................................... 1 2 Konzept eines Data Warehouses..................................................................................... 1 2.1 Begriff ........................................................................................................................ 1 2.2 Charakteristiken ......................................................................................................... 2 3 Architektur eines Data Warehouses............................................................................... 4 3.1 Komponenten eines Data Warehouses ....................................................................... 5 3.2 Datenmodellierung eines Data Warehouses............................................................... 8 3.2.1 Elemente multidimensionaler Datenstrukturen.................................................. 8 3.2.2 Semantische Modellierung............................................................................... 10 3.2.3 Logische Modellierung .................................................................................... 11 4 Einführung eines Data Warehouses ............................................................................. 13 4.1 Vorgehensmodell ..................................................................................................... 13 4.2 Aspekte der Realisierung ......................................................................................... 15 5 Ausblick........................................................................................................................... 16 Literaturverzeichnis............................................................................................................... 17 - II - Abbildungsverzeichnis Seite Abbildung 1: Idealtypische Data Warehouse-Architektur aus Mucksch, Behme [2000, S. 14] ............ 4 Abbildung 2: Verdichtungsebenen der Dimension Zeit aus Totok [2000, S. 113] ................................. 5 Abbildung 3: Drei-Schichten-Modell der Transformationskomponente aus Müller [2000, S. 153]....... 7 Abbildung 4: Dreidimensionale Matrix aus Holthuis [1998, S. 42]........................................................ 9 Abbildung 5: Rotation einer zweidimensionalen Matrix aus Holthuis [1999, S. 46].............................. 9 Abbildung 6: Unterschiedliche Sichtweisen des OLAP-Würfels aus Totok [2000, S. 63]................... 10 Abbildung 7: Star-Schema aus Holthuis [1999, S. 197] ....................................................................... 12 Abbildung 8: Snowflake Schema aus Holthuis [1999, S. 203] ............................................................. 13 Abbildung 9: Das phasenorientierte Vorgehensmodell aus Mucksch, Behme [1998, S. 319]............. 14 - III - Abkürzungsverzeichnis ADAPT CORBA CWM DV DWH EDV ER IBM i. e. S. MER ODBC ODS OLAP OMT PPS SQL WWW WWS Application Design for Analytical Processing Technologies Common Object Request Broker Architecture Common Warehouse Metamodel Datenverarbeitung Data Warehouse Elektronische Datenverarbeitung Entity Relationship International Business Machines Corporation im engeren Sinne Multidimensionales Entity-Relationship Open DataBase Connectivity Operational Data Store On-Line Analytical Processing Object Modeling Technique Produktionsplanungssystem Structured Query Language World Wide Web Warenwirtschaftssystem -1- 1 Einleitung Seit mehreren Jahren ist ein Trend zur Globalisierung und Dynamisierung der Märkte zu beobachten. Veranlasst durch diesen härter werdenden Wettbewerb versuchen viele Unternehmen Informationsvorsprünge und somit Wettbewerbsvorteile zu erlangen. Dadurch werden Informationen zur unternehmerischen Ressource und sind als Wettbewerbs- und Produktionsfaktoren von strategischer Bedeutung. Eine funktionierende Informationsversorgung ist dabei die Voraussetzung, um unternehmerische Entscheidungsprozesse qualitativ verbessern zu können. In der Vergangenheit gab es viele Ansätze, um die Management- und Entscheidungsprozesse durch computerunterstützte Informationssysteme1 zu verbessern. Allerdings erfolgte die Datenübernahme aus der vorhandenen DV-Infrastruktur meist nur mit manuell aufbereiteten Daten, wodurch Qualität und Aktualität stark beeinflusst und die erzielten Ergebnisse nicht zufriedenstellend waren. Folglich ist eine betriebliche Datenintegration2 erforderlich, welche auf horizontaler und vertikaler Ebene angestrebt wird. Die zu erwartende Heterogenität der Daten und die Anzahl der zu integrierenden Systeme, die sich oft über das ganze Unternehmen verteilen, führten zu dem Ziel, eine einheitliche, eigenständige und unternehmensweite Basis für Planungs- und Entscheidungsdaten zu schaffen. Dieses Ziel soll mit dem Data Warehouse Konzept verwirklicht werden. Im Folgenden wird in Kapitel 2 dieses Konzept erläutert, bevor einzelne Komponenten und die Datenmodellierung eines Data Warehouses in Kapitel 3 vertiefend dargestellt werden. In Kapitel 4 wird anschließend ein beispielhaftes Vorgehensmodell und die zu beachtenden Aspekte bei einer Realisierung beschrieben. 2 Konzept eines Data Warehouses 2.1 Begriff Der Begriff Data Warehouse wurde erstmals 1988 von IBM im Zusammenhang mit der Entwicklung eines European Business Information System (EBIS) verwendet. Durchgesetzt hat sich der Begriff jedoch erst 1993 mit der Veröffentlichung „Building the Data Warehouse“ durch William Inmon. Die deutsche Übersetzung des Wortes „Warehouse“ ist zwar „Lagerhaus“, allerdings ist die oft verwendete begriffliche Prägung eines Warenhauses auch inhaltlich zutreffender.3 Das Data Warehouse Konzept wird „[…] als neue Möglichkeit einer durchgängigen, konsistenten und endbenutzerorientierten Informationsbereitstellung für computergestützte Managementunterstützungssysteme auf allen Hierarchienebenen angesehen [...]“4. Um dem Thema dieser Arbeit besser gerecht zu werden, ist die folgende Beschreibung des Data Warehouse Konzepts passender: Es stellt eine Integrationsstrategie „ […] für Managementinformationen dar und soll die Qualität, die Integrität und die Konsistenz des zugrundeliegenden Datenmaterials sicherstellen.“5 Damit wird der Schwerpunkt der Betrachtung auf die Integration von Unternehmungsdaten über Data Warehouses gelegt. Als Integration wird die 1 z. B. Management Information System (MIS); Decision Support System (DSS). Vgl. Mertens u. a. [2001, S. 57] mit dem Thema: Ziele und Voraussetzungen der Datenintegration. 3 Vgl. Mucksch, Behme [2000, S. 5ff.]. 4 Mucksch, Behme [2000, S. 5]. 5 Mucksch, Behme [2000, S. 6]. 2 -2ternehmungsdaten über Data Warehouses gelegt. Als Integration wird die „Wiederherstellung eines Ganzen“ oder speziell in der Wirtschaftsinformatik die „Verknüpfung von Menschen, Aufgaben und Technik zu einem einheitlichen Ganzen“ verstanden.6 In dieser Arbeit werden Unternehmungsdaten, die man für einen Entscheidungs- und Planungsprozess benötigt als betriebswirtschaftliche Kennzahlen interpretiert. Kennzahlen „[…] dienen dazu, betriebliche Sachverhalte in konzentrierter Form wiederzugeben“.7 Das Data Warehouse Konzept wurde von vielen Soft- und Hardwareherstellern Anfang der 90er Jahre als Dienstleistungspaket vermarktet. In den einzelnen Bereichen eines Data Warehouses wie z. B. Extraktion- und Transformation, Datenmodellierung, Datenzugriff und Metadatenverwaltung werden meist Standardsoftwarekomponenten eingesetzt.8 Jedoch geht der manuelle Aufbau von multidimensionalen Datenstrukturen und die oft sehr spezielle Berücksichtigung von betrieblichen Besonderheiten häufig weit über das normale Customizing von Standardsoftware hinaus.9 Unter einem Data Warehouse Konzept ist also keine umfassende Standardsoftware zu verstehen.10 „Mit dem Begriff Data Warehouse i.e.S. wird generell eine von den operationalen DVSystemen isolierte Datenbank umschrieben, die als unternehmensweite Datenbasis für alle Ausprägungen managementunterstützender Systeme dient und durch eine strikte Trennung von operationalen und entscheidungsunterstützenden Daten und Systemen gekennzeichnet ist“11. Damit wird das Data Warehouse zur vertikalen Integrationsbasis und ordnet sich als Middleware zwischen den Administrations- und Dispositionssystemen (untere Ebene) und den Controllinginformationssystemen (obere Ebene) ein.12 Von der Verbesserung der Informationsversorgung durch ein Data Warehouse profitieren nicht nur die Managementunterstützungssysteme, sondern auch weitere Verfahren. So setzen z. B. die Ansätze „Data Mining“ und „On-Line Analytical Processing“ (OLAP) auf der Data Warehouse Datenbasis auf. Steht beim „Data Mining“ „die Suche nach noch nicht entdeckten Zusammenhängen im Vordergrund, so dominiert bei OLAP-Anwendungen die aktive und zielgerichtete Nutzung der Analysewerkzeuge durch den Anwender“13. Vor dem Data Warehouse Konzept wurden diese Ansätze schon intensiv diskutiert, bekamen aber erst durch die Data Warehouse Datenbasis ihr Anwendungsfeld in der unternehmerischen Praxis. Auf beide Ansätze wird in dieser Arbeit nicht weiter eingegangen. Da diese Ansätze nicht der Integration von Daten dienen, sondern eher nachgeschaltete Nutznießer des Data Warehouse Konzeptes sind.14 2.2 Charakteristiken Trotz verschiedenster Umsetzungsmöglichkeiten in der Praxis wird die Datenbasis eines Data Warehouses durch vier Kernbegriffe charakterisiert. Eine häufig zitierte Anforderungsdefinition ist die von Inmon: „A data warehouse is a subject oriented, integrated, non-volatile, and 6 Vgl. Mertens u. a. [2001, S. 82]. Totok [2000, S. 32]. 8 Bei der Komponente ’Transformationsprogramme’ herrscht oft Uneinigkeit über Machen oder Kaufen. 9 Vgl. Totok [2000, S. 241]. 10 Vgl. Holthuis [1999, S. 71f.]. 11 Mucksch, Behme [2000, S. 6]. 12 Vgl. Totok [2000, S. 39f.]. 13 Schelp [2000, S. 129]. 14 Vgl. Schelp [2000, S. 128ff.]. 7 -3time variant collection of data [...]“.15 Da die sprachliche Übersetzung und ihre inhaltliche Definition nicht einheitlich erfolgt orientiert sich der folgende Abschnitt an Mucksch, Behme [2000, S. 9ff.].16 1) Orientierung an den unternehmensbestimmenden Sachverhalten (subject oriented): In operativen DV-Systemen ist das Datenmodell nach Geschäftsprozessen bzw. Anwendungsbereichen wie z. B. Produktion und Vertrieb ausgerichtet. Für die Entwicklung des Data Warehouses hingegen sind die innerbetrieblichen Prozesse des Unternehmens von geringem Interesse. Die Daten werden zweckneutral nach übergeordneten Gesichtspunkten, z. B. Kundenstruktur, Produktstruktur und Zeitstruktur, abgelegt. Aus dieser Themenorientierung kann der Informationsbedarf für oft strategische Abfragen und Analysen zur Unterstützung von Entscheidungen abgeleitet werden. 2) Struktur- und Formatvereinheitlichung (integrated): Bei der Charakterisierung des Data Warehouses wird der Integration eine besondere Wichtigkeit zugewiesen17. Um eine einheitliche und konsistente Datenbasis aus den oft heterogenen und historisch gewachsenen operativen DV-Systemen zu bekommen, müssen Struktur- und Formatvereinheitlichungen vorgenommen werden. Die Strukturvereinheitlichung verhindert, dass im Meta-Informationssystem die Datenfelder mit identischem Inhalt unterschiedlich benannt werden (Synonyme) oder Datenfelder mit unterschiedlichem Inhalt den gleichen Namen (Homonyme) bekommen. Die operativen DV-Systeme speichern oft dasselbe Attribut in verschiedenen Ausprägungen ab z. B. das Merkmal Geschlecht (“m“, “w“; “0“, “1“). Die Formatvereinheitlichung passt diese Datenfelder für die Übernahme in das Data Warehouse auf einen Standard an. Bei Feldern mit unterschiedlichen Werteinheiten (cm; inches) wird dafür eine Basismaßeinheit (cm) als Standard festgelegt. Im Meta-Informationssystem werden daneben noch Umrechnungsfaktoren (100m Draht = 20 kg) und Umsetzungstabellen (verschiedene Währungen) geführt. „Der Zweck derartiger Definitionen liegt in einer exakten Interpretierbarkeit der hinterlegten Dateninhalte durch den Endanwender, um semantischen Missverständnissen bei der freien Navigation zuvorzukommen, die aus der homonymen Verwendung einzelner Geschäftsbegriffe erwachsen können“18. 3) Nicht-Volatilität (nonvolatile): Der Änderungsgrad von Daten in einem bestimmten Zeitraum wird durch die Volatilität beschrieben. In operativen DV-Systemen ist dieser Grad sehr hoch, da die Aktualität des Datenbestandes absolut gehalten werden soll.19 In das Data Warehouse übernommene Daten werden nur geändert, wenn bei der Datenübernahme aus dem Liefersystem Fehler entstanden sind. Dadurch können alle Zugriffe auf das Data Warehouse lesend erfolgen, was die NichtVolatilität gewährleistet. Aufgrund dieser Eigenschaft können auf dieser Datenbasis aufsetzende Berichte und Analysen jederzeit reproduziert und nachvollzogen werden. Unterstützend wirkt, dass die Daten nicht aus dem Data Warehouse gelöscht werden, sondern im Zeitverlauf ihrer Priorität entsprechend ausgelagert werden. Ein weiterer Vorteil besteht in der Senkung der Systembelastung, da das Datenbanksystem durch den nur lesenden Zugriff auf Sperrmechanismen verzichten kann und somit entlastet wird. 15 Inmon [1996, S. 33]. Vgl. Mucksch, Behme [2000, S. 9], Schelp [2000, S. 113], Totok [2000, S. 43 (insbesondere Fußnote 346)]. 17 Vgl. Inmon [1996, S. 33]. 18 Müller [2000, S. 124]. 19 Vgl. Totok [2000, S. 42]. 16 -44) Zeitraumbezug (time variant): Für die Analyse von Entwicklungen und Trends ist ein Zeithorizont von fünf bis zehn Jahren sinnvoll. Dazu werden die zeitpunktgenauen Daten des operativen DV-Systems, mit seinem eingeschränkten Zeithorizont von meist 60-90 Tagen, in eine zeitraumbezogene Betrachtungsweise transformiert. So findet eine Verdichtung der Daten nach verschiedenen Altersstufen statt (s. Kapitel 3.1). Um einen Zeitraumbezug herzustellen, wird der Schlüssel der importierten Datensätze um Zeitmarken erweitert gespeichert. Bei späteren Importen werden so keine Daten überschrieben und es ist z. B. möglich, die Zahlungsmoral eines Kunden über einen längeren Zeitraum hinweg zu analysieren.20 3 Architektur eines Data Warehouses Auswertungstools OLAP-Front End Abfrage- und Berichtssysteme Anwendungs Server Data Mining Data Mart OLAP Server Zentrale DWH-Datenbank ODS Archivierungssysteme Meta-Datenbank Extraktions- und Transformationsprogramme PPS … WWS Administrations- und Dispositionssysteme Externe Daten Abbildung 1: Idealtypische Data Warehouse-Architektur aus Mucksch, Behme [2000, S. 14]. Eine mögliche Umsetzung eines Data Warehouse Konzeptes wird durch Abbildung 1 skizziert. Dabei handelt es sich um eine idealtypische Architektur, da alle möglichen Komponenten implementiert worden sind. Nachfolgend wird kurz die Funktionalität zweier Komponenten erläutert, die im Zusammenhang mit dem Data Warehouse Konzept oft genannt werden, aber für ein weiteres Verständnis dieser Arbeit nicht relevant sind. 20 Vgl. Totok [2000, S. 43]. -5Data Marts werden vorrangig bei sehr großen Datenmengen eingesetzt und enthalten redundante Teilmengen eines Data Warehouses. Diese Teilmengen sind auf die Bedürfnisse der Nutzer zugeschnitten. Das führt dazu, dass mit einer relativ kleinen Datenmenge eine Großzahl der Anfragen bearbeitet werden kann.21 Das Operational Data Store (ODS) wird zum Speichern von operativen Daten zwischen zwei Datenübernahmen oder zur Lieferung von zeitpunktaktuellen Daten direkt an die Auswertungswerkzeuge (s. Kapitel 5) implementiert.22 3.1 Komponenten eines Data Warehouses Die drei folgenden Komponenten sind Grundlage für die Integration von Daten und sind somit Bestandteil jedes Data Warehouses. Datenbasis Der Aufbau und die Gestaltung der unabhängigen Datenbasis richtet sich nach den im Kapitel 2.2 genannten vier Anforderungsdefinitionen. Die Datenbasis stellt damit den eigentlichen Kern des Data Warehouse Konzeptes dar. Die Unabhängigkeit von den meist zuliefernden operativen DV-Systemen begründet sich durch die unterschiedliche Ausrichtung der operativen- und der Data Warehouse Systeme. Die operativen DV-Systeme orientieren sich an den Unternehmensprozessen und zeichnen sich durch eine hohe Anzahl ähnlich gearteter Zugriffe auf meist wenige Datensätze aus. Das Data Warehousesystem hingegen orientiert sich an unternehmensbestimmenden Sachverhalten und ist die Basis für eine flexible Verarbeitung von großen Datenmengen.23 niedrig grob/hoch Detaillierungsgrad Quartal Granularität/ Verdichtungsgrad Monat Tag hoch Konsolidierungspfad Jahr fein/ niedrig Abbildung 2: Verdichtungsebenen der Dimension Zeit aus Totok [2000, S. 113]. Ein wesentlicher Gestaltungsfaktor des Data Warehouses wird durch das Charakteristikum des Zeitraumbezuges (s. Kapitel 2.2) eingebracht. Geprägt durch die zeitraumbezogene Sicht, wird bei der Datenspeicherung die Dimension Zeit als Verdichtungskriterium herangezogen (Abbildung 2). Der Verdichtungsgrad der Daten wird als Granularität bezeichnet und erhöht sich mit zunehmendem Alter der Daten. Diese Verringerung der Datenmenge steigert die Ef- 21 Vgl. Anahory, Murray [1997, S. 69f.]. Vgl. Mucksch, Behme [2000, S. 21f.]. 23 Vgl. Holthuis [1999, S. 80ff.]. 22 -6fizienz des Data Warehouses. Sie kann allerdings auch dazu führen, dass nicht mehr alle Abfragemöglichkeiten zur Verfügung stehen.24 Die Effizienz, im Zusammenhang mit der Granularität, wird erheblich durch die Partitionierung beeinflusst. „Bei Durchführung der Partitionierung wird der gesamte Datenbestand des Data Warehouses in mehrere kleine, physisch selbstständige Partitionen mit redundanzfreien Datenbeständen aufgeteilt.“25 Die Aufteilung in kleinere Datenbestände erweitert die Möglichkeiten der Datenbankverwaltung. So können z. B. leichter Indexe gesetzt, Reorganisationen durchgeführt oder sequenzielle Suchen getätigt werden. Partitionierungen können horizontal oder vertikal durchgeführt werden. Die horizontale Partitionierung richtet sich nach betriebswirtschaftlichen Dimensionen. So könnte eine Partitionierung nach Monaten große Geschwindigkeitsvorteile bringen, wenn die Endbenutzer häufig Umsatzzahlen auf Monatsebene vergleichen müssen. Die vertikale Partitionierung erfolgt nach unternehmensbestimmenden Sachverhalten oder Unternehmensbereichen.26 Ein weiteres geschwindigkeitsförderndes Gestaltungsmerkmal ist die Denormalisierung. Dabei werden Normalformen zurückgenommen oder nicht umgesetzt. Durch die Zusammenfassung von Tabellen auf logischer Ebene, wird die Anzahl der nötigen Datenbankzugriffe gesenkt. Die gestiegene Geschwindigkeit geht zulasten eines erhöhten Speicherbedarfs, der durch die nun auftretenden Redundanzen entsteht. Die Darstellung denormalisierter Daten in mehrdimensionaler Form ist z. B. durch das in Kapitel 3.2.3 angesprochene Star Schema möglich. Das zugrunde liegende Datenbanksystem eines Data Warehouse ist nicht auf eine bestimmte Technologieform wie relational, multidimensional oder objektorientiert festgelegt. Auswahlkriterien für ein Datenbanksystem können die später zuverarbeitenden Datenmengen, Kompatibilität mit zugreifenden Anwendungen und das fachliche Wissen der Systembetreuer sein.27 Transformationsprogramme Nach Inmon wird das Design und die Entwicklung der im Idealfall einzigen Schnittstelle, zwischen den operativen DV-Systemen und dem Data Warehouse, meist zeitlich unterschätzt. Der zum Aufbau benötigte Aufwand kann oft bis zu 80 Prozent des gesamten Data Warehouse Entwicklungsaufwandes einnehmen.28 Die Schnittstelle setzt sich aus mehreren Extraktions- und Transformationsprogrammen zusammen und importiert Daten aus verschiedensten unternehmensinternen und -externen Datenquellen. Unternehmensinterne Daten können trotz ihrer Heterogenität meist ohne Medienbruch (manuelle Eingabe) aus den operativen DVSystemen gewonnen werden.29 Dies kann automatisiert über genormte Schnittstellen wie z. B. ODBC oder CORBA im Computernetzwerk erfolgen.30 Im Gegensatz dazu müssen unternehmensexterne Daten, die oft in unstrukturierter Form (Grafiken, Texte, Videosequenzen) vorliegen, gesondert für das Data Warehouse digitalisiert oder in ihrer ursprünglichen Form archiviert werden. Der Aufwand bei der Gewinnung von unternehmensexternen Daten lässt sich dadurch rechtfertigen, dass Berichte und Auswertungen, die auf unternehmensinternen 24 Vgl. Inmon [1996, S. 45ff.]. Mucksch, Behme [2000, S. 45]. 26 Vgl. Totok [2000, S. 44]. 27 Vgl. Mucksch, Behme [2000, S. 42ff.]. 28 Vgl. Inmon [1996, S. 281]. 29 Vgl. Holthuis [1999, S. 89]. 30 Vgl. Totok [2000, S. 115]. 25 -7Daten beruhen, ihre Aussagekraft oft erst dadurch erlangen, wenn sie mit externen Daten verglichen werden.31 Zentrale Data Warehouse Datenbank Datenbeschaffung Integration Transformation i. e. S. Extraktion Extraktion Operative Vorsysteme Externe Daten Abbildung 3: Drei-Schichten-Modell der Transformationskomponente aus Müller [2000, S. 153]. Die weitere Beschreibung der Transformationskomponente orientiert sich an Müller [2000, S.152 ff.]. Der Aufbau dieser Komponente kann in einem dreistufigen Schichtenmodell (Abbildung 3) dargestellt werden. In der Exportschicht sind zwei Vorgehensweisen bei der Extrahierung der Daten aus den operativen DV-Systemen möglich. Bei dem ersten Verfahren wird eine vollständige Kopie aller relevanten Daten aus den operativen DV-Systemen durchgeführt. Dies geschieht z. B. bei der initialen Bestückung des Data Warehouses, mit der ein grundlegender Datenbestand erzeugt werden soll, oder bei einem hohen Volatilitätsgrad der operativen Datenbasis. Für das zweite Verfahren sind hingegen nur aktualisierte oder neue Daten (Delta) aus dem operativen DV-System relevant, was zu einer inkrementellen Aktualisierung des Data Warehouses führt. Die Wahl des Übernahmeverfahrens ist von der jeweiligen Struktur des operativen Systems, den betriebswirtschaftlichen Bedürfnissen und der DV-technischen Leistungsfähigkeit im Unternehmen abhängig. Die zweite Schicht mit der Transformation im engeren Sinne erfüllt somit die Aufgabe der, von Inmon als Charakteristikum geforderten, Struktur- und Formatvereinheitlichung. In der dritten Schicht erfolgt die eigentliche Datenübernahme der transformierten Daten in die Datenbank des Data Warehouses. Die aus Transformationsprozessen resultierende Datenqualität im Data Warehouse beeinflusst den später zu erreichenden Nutzen der Endanwender, z. B. sind durch die Vermeidung von Redundanzen im Kundenstamm bei späteren Kundenmailings Kosteneinsparungen möglich.32 Metadatenbank „Metadaten sind Daten über Daten“.33 In der operativen Umgebung werden sie, wenn überhaupt vorhanden, oft nur unzureichend gepflegt.34 Im Data Warehouse Konzept hingegen sind diese Informationen, gerade für die oft in EDV-Dingen unerfahrenen Endanwender, erste An- 31 Vgl. Holthuis [1999, S. 90f.]; Inmon [1996, S. 261ff.]. Vgl. Mucksch, Behme [2000, S. 33ff.]; Devlin [1997, S. 214]. 33 Poe [1997, S. 190]. 34 Vgl. Holthuis [1999, S. 98]. 32 -8laufstelle zur Identifizierung der relevanten Daten für ihre Aufgabenstellung.35 Die Metadaten sind Basis für die Schnittstelle zwischen den operativen DV-Systemen und der Data Warehouse Umgebung.36 Poe unterscheidet zwei Gruppen von Metadaten. Die erste Gruppe enthält Informationen über die operativen Quelldatensysteme wie z. B. Datenstrukturen, Informationen über den Transformationsprozess und die anschließende Zieldatenquelle. Die zweite Gruppe bildet eine Abstraktionsschicht zwischen dem Data Warehouse Datenmodell und dem in Dimensionen angelegten Geschäftsprozessmodell. Diese Abstraktionsschicht ist vorteilhaft bei Datenstrukturänderungen im Data Warehouse. Nach einmaliger Aktualisierung der Metadaten stehen die Neuerungen allen zugreifenden Anwendungen zur Verfügung, ohne dass Auswertungen (z. B. Berichte und Analysen) durch Änderungen zum Absturz gebracht werden können. Dies bezieht sich nicht nur auf die Veränderung einzelner Datenbankfelder oder –tabellen, sondern auch auf strukturelle Änderungen. So würde sich eine zugreifende Anwendung „automatisch“ über die Metadaten an neue Unternehmenshierarchien anpassen, wenn z. B. bei einer Umstrukturierung eine Verwaltungsebene wegfallen würde. 37 3.2 Datenmodellierung eines Data Warehouses 3.2.1 Elemente multidimensionaler Datenstrukturen Als Grundlage der managementunterstützenden Systeme soll das Data Warehouse bei entscheidungs- und führungsrelevanten Fragestellungen behilflich sein. Diese betriebswirtschaftlichen Fragestellungen38 werden oft unter Berücksichtigung mehrerer Einflussfaktoren untersucht. Diese Sichtweise gliedert Kennzahlen nach verschiedenen Betrachtungsrichtungen (Dimensionen). Mehrdimensionale Datenstrukturen können im Gegensatz zu relationalen Datenstrukturen die Matrizensichtweise optimal umsetzen. Durch die nun mögliche Abbildung von Kennzahlen kann eine Datenstruktur aufgebaut werden, die sich dem Endanwender intuitiv erschließt und seinen Bedürfnissen bei Analysen entgegen kommt.39 Die Darstellung der multidimensionalen Daten erfolgt meist in Form einer Matrix. Ihr Aussehen wird durch die Anzahl der Dimensionen bestimmt. Der Inhalt der einzelnen Zellen besteht aus quantitativen Werten (s. Kapitel 3.2.3 Faktdaten). In Abbildung 4 sind Produkt, Zeitraum und Verkaufsregion die bestimmenden Dimensionen. Die Zellen enthalten die einzelnen Verkaufsumsatzzahlen.40 Spätere Analysen werden durch den erreichten hohen Organisationsgrad der Daten erleichtert, z. B. lässt sich die Gesamtverkaufszahl von Sekt im Monat Januar durch eine einfache Aufsummierung der Spalte ermitteln. In einem relationalen Datenbanksystem müssen dagegen erst alle Tupel mit der Bedingung „Sekt und Verkaufdatum Januar“ identifiziert werden, bevor eine Aufsummierung erfolgen kann. Dies führt je nach Umfang zu längeren Antwortzeiten.41 35 Vgl. Inmon [1996, S. 185f.]. Vgl. Inmon [1996, S. 186]. 37 Vgl. Poe [1997, S. 190ff.]. 38 z. B. Wie hat sich der Umsatz eines Produktes in einem Verkaufsgebiet innerhalb eines Zeitraums entwickelt? 39 Vgl. Schelp [2000, S. 146f.]. 40 Vgl. Holthuis [1999, S. 42]. 41 Vgl. Holthuis [1999, S. 42f.]. 36 -9Verkaufsumsätze Rotwein on Ve rk au März Februar Januar re gi Br an He de nb s s ur Ni g ed en er sa ch se n Sekt fs Produkt Weißwein Zeitraum Abbildung 4: Dreidimensionale Matrix aus Holthuis [1998, S. 42]. Weitere Geschwindigkeitsvorteile gegenüber einem relationalen Datenbanksystem ergeben sich aus der einfachen Anpassungsmöglichkeit der multidimensionalen Matrix an einen neuen Blickwinkel. So würde eine Abfrage nach „Verkaufsumsatzzahlen nach Produkt und nach Region“ in einem normalisierten, relationalen Datenmodell komplexe Abfragen und Sortierungen mit sich bringen (Abbildung 5).42 Weißwein 3 5 5 4 3 2 Niedersachsen Brandenburg Sekt Brandenburg Hessen Niedersachsen 6 3 4 5 5 3 5 5 2 Sekt 5 Weißwein 5 Rotwein 6 Region Rotwein Hessen Produkt Verkaufsumsätze Produkt Region Rotation 90° Abbildung 5: Rotation einer zweidimensionalen Matrix aus Holthuis [1999, S. 46]. Bei einem multidimensionalen Datenmodell ergibt sich durch eine 90-Grad-Drehung der multidimensionalen Matrix das gewünschte Ergebnis. Diese Rotation wird Data Slicing genannt, da jede Rotation zu einer neuen Sichtweise führt. Die Anzahl der möglichen Blickwinkel steigt exponentiell mit der Anzahl der Dimensionen. Die hier verwendete dreidimensionale Matrix besitzt sechs Betrachtungswinkel, denn jede Dimension ergibt mit den beiden anderen Dimensionen wieder eine mögliche Betrachtungsrichtung.43 42 43 Vgl. Holthuis [1999, S. 46]. Vgl. Holthuis [1999, S. 45f.]. - 10 Durch so genanntes Data Dicing lassen sich einzelne Dimensionen auswählen, um so Teilmengen einer Matrix zu betrachten. Diese Art des schnellen Zugriffs nutzen z. B. die auf dem Data Warehouse aufsetzenden OLAP-Anwendungen (s. Kapitel 2.1). Von multidimensionalen Datensystem unterstützt können einige Anwendungen so die unterschiedlichen Sichtweisen von betrieblichen Entscheidungsträgern problemlos abbilden (Abbildung 6). Die Sicht auf die Absatzergebnisse wird bei der Geschäftsleitung durch Dicing, die der Anderen durch Slicing erreicht.44 Controlling Produktmanager Geschäftsleitung Vertriebsleiter Absatzergebnis Abbildung 6: Unterschiedliche Sichtweisen des OLAP-Würfels aus Totok [2000, S. 63]. Trotz der hier genannten Vorteile der multidimensionalen Datenstrukturen erfolgten bisher die meisten Data Warehouse Implementierungen auf Basis von relationalen Datenbanksystemen. Die multidimensionalen Datenbanksysteme verfügen zwar über ein hohes Maß an systemspezifischer Funktionalität, jedoch fehlen allgemein anerkannte Standards. Aufgrund der noch fehlenden mathematische Basis für eine multidimensionale Algebra ist auch noch keine Standardabfragesprache wie bei den relationalen Systemen mit SQL realisiert worden. Die in Kapitel 3.2.3 beschriebenen Ansätze zur Speicherung von multidimensionalen Datenstrukturen finden oft in relationalen Datenbanken Anwendung. 3.2.2 Semantische Modellierung Aus Sicht der Endanwender werden auf dieser Ebene die Datenobjekte und ihre semantischen (inhaltlichen) Zusammenhänge in einem Datenmodell erfasst. „Die Semantik befaßt sich mit den Beziehungen der Daten zu den Phänomenen der Realität und ermöglicht so deren Interpretierbarkeit“.45 Dies geschieht vor der Implementierung und ist unabhängig von der verwendeten Zieldatenbanktechnologie. Dieser Zwischenschritt vor der eigentlichen Datenmodellierung stellt sicher, dass Sichtweise und Verständnis von Endanwender und Entwickler identisch sind.46 44 Vgl. Totok [2000, S. 62f.]. Holthuis [1999, S. 143]. 46 Vgl. Schelp [2000, S. 153]. 45 - 11 Es gibt eine Vielzahl von Modellierungsansätzen, die grob in drei Kategorien aufgeteilt werden können. Dabei handelt es sich um Entity-Relationship basierte Methoden (MER), speziell für die multidimensionale Modellierung entwickelten Methoden (ADAPT) und objektorientierte Methoden (OMT). Bisher hat sich noch kein (Industrie-) Standard etablieren können.47 Bei einer fast ausschließlichen Nutzung von relationalen Datenbanken für Data Warehouse Implementierungen findet die auf der Entity-Relationship basierende Methode breite Anwendung in der Praxis.48 Die einfach zu verwendende Notation und die häufig direkte Überführbarkeit in relationale Datenbanksysteme tragen als wesentliche Gründe dazu bei. Allerdings erfordern die multidimensionalen Strukturen einige Erweiterungen am ER-Grundmodell. Die bisher für statische Datenmodellierung ausgelegte Notation muss für funktionale und dynamische Sichten um neue Notationselemente ergänzt werden.49 Alle angeführten Ansätze befinden sich noch in der Entwicklung und werden mit Ausnahme des ADAPT Ansatzes für die Modellierung der charakteristischen Dimensionsstrukturen für nur bedingt geeignet gehalten.50 3.2.3 Logische Modellierung Bedingt durch die große Verbreitung von relationalen Datenbanken ist die Überführung von multidimensionalen Konstrukten in das relationale Modell durch logische Modellierung ein häufig auftretender Fall. Die relationalen Datenbanksysteme sind allerdings nicht für die mehrdimensionale Datenanalyse mit verschiedenen Perspektiven und Granularitätsgraden konzipiert worden. Durch den geringen Unterstützungsgrad reagieren die relationalen Abfragewerkzeuge bei den multidimensionalen Strukturen nur sehr langsam.51 Dieser Mangel wird durch die Erweiterung der relationalen Systeme um multidimensionale Funktionalität behoben. Dazu werden die Daten denormalisiert und multidimensionale Funktionen werden über relationale Standardoperatoren abgebildet. Die dabei zu erreichenden Geschwindigkeitsvorteile52 sollen durch Einhaltung bestimmter Strukturen z. B. Star oder Snowflake Schema sichergestellt werden.53 Star Schema Das Star Schema54 basiert auf zwei Arten von Tabellen. Es handelt sich dabei um eine Fakttabelle und mehrere Dimensionstabellen. Zur besseren Visualisierung werden diese Sternförmig angeordnet (Abbildung 7). Die Fakttabelle enthält quantitative Daten, wie z. B. Kennzahlen (Verkaufsumsatz), die auch später im Zentrum der Datenanalyse stehen. Die Dimensionstabellen bestehen aus Attributen (Produkt, Region, Zeitraum, Geschmack) der Faktdaten und beinhalten die einzelnen Dimensionsausprägungen (Rotwein, Brandenburg, Januar, trocken). Für jede aufzuführende Dimension wird eine eigene Dimensionstabelle erstellt, deren Daten in denormalisierter Form vor47 Vgl. Totok [2000, S. 123]. Vgl. Totok [2000, S. 171]. 49 Vgl. Schelp [2000, S. 158ff.]. 50 Vgl. Totok [2000, S. 282]. 51 Vgl. Totok [2000, S. 173f.]. 52 Zur Auflistung von weiteren Vorteilen beim Einsatz des Star Schema: Vgl. Poe [1997, S. 140]. 53 Vgl. Totok [2000, S. 173f.]. 54 Vgl. Kimball [1996, S. 10]. Wird es Dimensional Model genannt. 48 - 12 liegen. Die einzelnen Dimensionstabellen sind nicht miteinander verbunden, sondern weisen nur eine Verknüpfung zur Fakttabelle auf. Die Elemente einer multidimensionalen Matrix lassen sich im Star Schema einfach aufzeigen. Entlang der Dimensionsachse werden die einzelnen Positionen durch die Dimensionsausprägungen der Dimensionstabelle dargestellt. Die einzelnen Zellen der Matrix werden mit den Daten aus der Fakttabelle gefüllt.55 Produkt Region Rotwein Brandenburg Weißwein Hessen Sekt Niedersachsen Produkt Region Geschmack Zeitraum Verkaufsumsatz Geschmack Zeitraum trocken Januar halbtrocken Februar Fakttabelle mild März Dimensionstabelle Abbildung 7: Star Schema aus Holthuis [1999, S. 197]. Wenn die Faktdaten unterschiedliche Dimensionsausprägungen benötigen, müssen entsprechend mehr Fakttabellen angelegt werden. Dies ist bei komplexen Datenmodellen häufiger der Fall. Das sich daraus entwickelnde Schema wird Multi-Fakttabellen-Schema genannt.56 Snowflake Schema Das Snowflake Schema stellt eine Erweiterung des Star Schema dar und zeichnet sich durch eine stärkere Normalisierung (dritte Normalform) der Dimensionen aus. Dieses Schema wird gegenüber dem Star Schema bevorzugt, wenn die Dimensionsebenen ungleichmäßig besetzt sind. Wie in Abbildung 8 zu sehen ist, enthalten einige Dimensionstabellen (Region, Zeitraum) nur noch Daten über Dimensionshierarchien. Ihnen angeschlossen sind die entsprechenden Attributstabellen, welche die beschreibenden Informationen über die Dimensionselemente enthalten. Aufgrund dieser erhöhten strukturellen Komplexität bei der Anordnung der Tabellen lehnt sich der Name des Schemas an der Schneeflocke an. Diese höhere Komplexität erschwert allerdings auch die Navigation in den Datenbeständen, was sich bei den Standardabfragewerkzeugen negativ bemerkbar macht. So ist das Problem der Komplexität auch gegen eventuell zu erzielende Geschwindigkeitsvorteile und Speicherplatzeinsparungen nicht als gering anzusehen und wird nur empfohlen bei großen Dimensionstabellen mit vielen Attributen auf niedriger Ebene.57 55 Vgl. Holthuis [1999, S. 196f.]. Vgl. Holthuis [1999, S. 197]. 57 Vgl. Holthuis [1999, S. 202ff.]. 56 - 13 Bundesland Brandenburg Hessen Niedersachsen Produkt Rotwein Weißwein Sekt Produkt Region Bundesland PLZ-Gebiet Stadt Region Geschmack Geschmack trocken halbtrocken mild Zeitraum Verkaufsumsatz Monat-ID Januar Februar März Zeitraum Monat-ID Woche-ID Tag-ID Tag-ID Montag Dienstag Mittwoch PLZ-Gebiet 0 1 2 3 … Stadt Potsdam Wiesbaden Hannover Woche KW 1 KW 2 KW 3 Abbildung 8: Snowflake Schema aus Holthuis [1999, S. 203]. Ursache für die Problematik der beiden Schemata ist die mangelhafte Unterstützung durch die relationalen Datenbanksysteme. Wird diese Unterstützung hinsichtlich einer besseren und performanteren Zugriffsstruktur weiter ausgebaut, so wird das Star Schema als prinzipiell gut geeignet für die Haltung multidimensionaler Daten im Data Warehouse eingeschätzt.58 4 Einführung eines Data Warehouses 4.1 Vorgehensmodell „Ein Vorgehensmodell beschreibt alle Ereignisse und notwendigen Arbeitsschritte, welche zur Erreichung der definierten Projektziele erforderlich sind“.59 Vorgehensmodelle sind nicht statisch, sondern können auf die jeweilige Situation angepasst oder kontinuierlich verändert werden. Ziel ist es eine Vereinfachung und Komplexitätsreduzierung des Vorgehens vorzunehmen.60 Das Vorgehensmodell des Data Warehouse unterscheidet sich durch die Verschiedenheit der Ziele und Datenstrukturen von dem Vorgehensmodell der klassischen Softwareentwicklung. Die klassische Systementwicklung startet mit Anforderungen und endet mit den gewünschten Daten (Anforderungsorientiert). Die Data Warehouse Entwicklung hingegen ist genau gegensätzlich, es wird mit Daten begonnen und endet mit Benutzeranforderungen (Datenorientiert).61 Das Data Warehouse bildet auch keine operationalen Geschäftsprozesse ab, was eine nachfolgende Prozessmodellierung unnötig macht und Entwicklungsstufen entfallen lässt.62 Die genannten Unterschiede werden in einem traditionellen Vorgehensmodell nur unzureichend berücksichtigt. 58 Vgl. Holthuis [1999, S. 210]. Kurz [1999, S. 292]. 60 Vgl. Kurz [1999, S. 293]. 61 Vgl. Inmon [1996, S. 24f.]. 62 Vgl. Poe [1997, S. 80]. 59 - 14 In der Literatur findet sich kein einheitliches Vorgehensmodell, das einen allgemeinen Rahmen für Data Warehouse Projekte liefert. Die Mehrheit der in der Literatur vorgestellten Vorgehensmodelle ähneln sich in der Reihenfolge der Schritte Analyse, Design, Implementierung und beinhalten iterative Elemente.63 So sind viele Vorgehensmodelle der Produktanbieter, bedingt durch die hohe Bedeutung der Datenbasis des Data Warehouses, angelehnt an die klassische Datenbankentwicklung.64 Die folgende Darstellung eines möglichen Vorgehensmodells erfolgt in Anlehnung an Mucksch, Behme [1998, S. 318ff.]. Das phasenorientierte Vorgehensmodell (Abbildung 9) ist in die drei schon angesprochenen Phasen Analyse, Design, und Implementierung (Produktivsetzung) gegliedert. Es wird nach anwenderbezogenen Aufgaben, die über der Zeitachse liegen und systemtechnischen Aufgaben, die unter der Zeitachse liegen unterschieden. Es ist nicht unbedingt notwendig bei der ersten Phase zu starten, wenn im Unternehmen bereits Voraussetzungen für den Aufbau eines Data Warehouse erfüllt sind. Allerdings ermöglicht das iterative Modell auch zu einer früheren Phase zurückzugehen, wenn nicht alle Voraussetzungen vorhanden sind. Produktivsetzung Design Analyse Anwender- Geschäftszweck bestimmen Anwender werkzeuge schulen auswählen Anwender- Datenstrukturen Anforderungen erheben Start einrichten OK? OK? Datenquellen analysieren werkzeuge modellieren Ziel System- Administrator architektur ausbilden entwerfen Behebung von Datendefiziten Datenpumpe und Datenbank implementieren Abbildung 9: Das phasenorientierte Vorgehensmodell aus Mucksch, Behme [1998, S. 319]. Erste Phase: Analyse des Informationsbedarfs Auf der Anwenderebene müssen die Endanwender den Geschäftszweck des Data Warehouses festlegen und die relevanten operativen Daten bestimmen. Auf der systemtechnischen Ebene werden anschließend die unternehmensinternen und -externen Datenquellen zur Übernahme der Datenlieferung definiert. Zweite Phase: Design der Lösung Die Auswahl von Anwendungswerkzeugen und einer Datenbank wird oftmals durch bereits vorhandene Software eingeengt. Bestehende Software sollte auf Erweiterbarkeit oder Funkti63 64 Vgl. Müller [2000, S. 211f.]. Vgl. Holthuis [1999, S. 219]. - 15 onsübernahme geprüft werden. Neben der Datenmodellierung sind die in Kapitel 3.1 aufgeführten Data Warehouse spezifischen Elemente wie z. B. Zeitraumbezug und Granularität gesondert zu berücksichtigen. Dritte Phase: Produktivsetzung der Lösung Auf der anwendungsbezogenen Ebene werden die Anwenderwerkzeuge eingerichtet. Für die Endanwender werden dabei verschiedene Berichtsarten65 bereitgestellt, an denen sie direkt geschult werden. Mit der Produktivsetzung müssen die Administratoren nun das Leistungsverhalten beobachten. Eventuell sind Tuning-Maßnahmen durchzuführen, neue Benutzeranforderungen umzusetzen, Zugriffsrechte verwalten und datenschutzrechtliche66 Bestimmungen zu überwachen. 4.2 Aspekte der Realisierung Bei der Implementierung eines Data Warehouse Konzeptes soll auf einige beachtenswerte Punkte näher eingegangen werden. Die Realisierung, der im Data Warehouse Konzept geforderten unternehmensweiten, zentralen Datenbasis, wird von einigen Autoren als schwierig bis gescheitert angesehen. Gründe dafür sind die langwierige Umsetzungsdauer, geringe Akzeptanz von Kompromisslösungen und die schwierige Umsetzung des eigentlichen Datenmodells.67 Neben Technischen sind auch betriebswirtschaftliche Gründe anzuführen, wie z. B. in Unternehmen mit einer Konzernstruktur verfügen die Konzerntöchter oft über unabhängige nicht aufeinander abgestimmte DVSysteme.68 So findet sich in der Praxis nur bei 33 v. H. Unternehmen ein unternehmensweites Datenmodell als Basis für die DV-Systeme.69 Dieser Problematik wird durch den Einsatz von individuellen Unternehmensbereichs-Data Marts entgegen gewirkt. Als Einsatzgebiete eines Data Warehouses schlägt Poe vorwiegend Unternehmensbereiche70 vor, die die Einnahmen der Unternehmung fördern und die Wettbewerbsposition verbessern, z. B. Verkaufsanalyse, Finanzen und Marketing. Für eine Erstimplementierung empfiehlt Poe die Finanzabteilung, welche sich aufgrund der beschränkten Datenmenge und der Homogenität der Daten besonders eignet.71 Die Einbindung, der in das Data Warehouse zu integrierenden Daten, ist ein iterativer Prozess, weil die Anwender, nach Kenntnis der Daten, anschließend oftmals weitere Daten anfordern.72 Die Auswahl, der für einen Entscheidungsprozess relevanten Daten, gestaltet sich hingegen komplizierter. Es müssen konkrete Anwender- und Führungskräftebefragungen durchgeführt werden, damit ein Verständnis für die langfristigen betrieblichen Entwicklungen entsteht. Die Komplexität der Einschätzung des betrieblichen Einsatzfeldes wird deutlich, wenn bei einer Data Warehouse-Einführung dieser Aufwand auf mindestens 2/3 des Gesamtaufwandes geschätzt wird.73 65 Vgl. Poe [1997, S. 170f.] z. B. Vordefinierte Berichte, Parametrisierbare Berichte, Flexible Berichte. Vgl. Mucksch, Behme [1997, S. 95ff.]. 67 Vgl. Mucksch, Behme [1997, S. 124f.]. 68 Vgl. Totok [2000, S. 29]. 69 Vgl. Totok [2000, S. 54]. 70 Vgl. Schelp [2000, S. 134] Werden als Einsatzgebiete: Controlling, Geschäftsführung, Marketing etc. genannt. 71 Vgl. Poe [1997, S. 105f.]. 72 Vgl. Poe [1997, S. 119]. 73 Vgl. Mucksch, Behme [1997, S. 84]. 66 - 16 - 5 Ausblick Die Implementierung eines Data Warehouses bringt zahlreiche Nutzenpotenziale mit sich. Diese auszuschöpfen gilt es besonders für Branchen, die in einem starken Wettbewerb stehen und eine kundenzentrierte Ausrichtung haben wie z. B. Handel, Banken, Versicherungen. Als Grundlage dafür dient die unabhängige und im Idealfall unternehmensweite Data Warehouse Datenbasis. Sie hängt maßgeblich von der erfolgreichen Umsetzung zweier Faktoren ab. Die Transformationskomponente und das Datenmodell haben großen Einfluss auf die Datenbasis, ihre spätere Datenqualität und somit auf die Akzeptanz des gesamten Data Warehouse Projektes. Auf technischer Ebene verbessert das Data Warehouse Konzept die horizontale Integration im Unternehmen. Die technische Integration wird unterstützt durch die Integration auf der semantischen Ebene. Diese unternehmensweite Standardisierung von Entscheidungs- und Planungsdaten in einer Datenbasis führt zu einer einfachen und qualitativ hochwertigen Informationsbereitstellung. Auf dieser neuen Qualität der Informationsversorgung aufbauend wird eine sehr große Flexibilität erreicht. Da das Data Warehouse nicht explizit für eine Anforderung erstellt wird, kann es z. B. betriebliche Fragestellungen aus unterschiedlichsten Abteilungen beantworten und ist vermutlich in der Lage, flexibel auf zukünftige, bisher unbekannte Anforderungen zu reagieren. Inzwischen stellen heute Data Warehouses in den Bereichen E-Business und E-Commerce eine technologische Grundlage für eine intelligente Kundenorientierung dar.74 Seit einiger Zeit ist ein starker Trend in Richtung Echtzeitverarbeitung75 von Daten zu beobachten. Dazu werden meist bestehende Data Warehouse Projekte um die Architekturkomponente ODS (s. Kapitel 3) erweitert. Daneben gibt es Bestrebungen, einen Web-basierten Zugang zum Data Warehouse zu ermöglichen, um einheitliche und intuitive Oberflächen im Unternehmen anbieten zu können. Auch für die Zukunft werden dem Data Warehouse Markt große Wachstumsraten vorhergesagt. Weiterhin wären tiefer gehende Bemühungen im Bereich der Metadaten76 und der multidimensionalen Datenmodellierung zur Schaffung von umfassenden anerkannten Standards wünschenswert. Dies würde helfen, weitere Potenziale der Data Warehouse Architektur umzusetzen. Abschließend betrachtet lässt sich der Nutzen eines Data Warehouses für ein Unternehmen nur schwer quantifizieren. Stattdessen sind bei der Bewertung qualitative Aspekte anzuführen. Trotzdem sind es gerade die strategischen Entscheidungen, die oft die langfristige Überlebensfähigkeit eines Unternehmens sichern. Werden diese doch durch die verbesserte Informationsversorgung entscheidend unterstützt. 74 Vgl. Kimball, Merz [2000]. Vgl. http://www.adtmag.com/article.asp?id=8095 . 76 Vgl. http://www.omg.org/cwm/ (The Common Warehouse Metamodel). 75 - 17 - Literaturverzeichnis Anahory, S., Murray, D.: Planung, Implementierung und Administration. Addison-WesleyLongman, Bonn u.a. 1997. Devlin, B.: Data Warehouse from Architecture to Implementation. Addison-WesleyLongman, Reading, Massachusetts u.a. 1997. Holthuis, J.: Der Aufbau von Data Warehouse-Systemen. 2. Auflage, Gabler, Wiesbaden 1999. Inmon, W.H.: Building the Data Warehouse. 2nd Edition, Wiley Computer Publishing, New York u.a. 1996. (aktuellste Auflage: 3. Aufl. von 2002) Kimball, R.: The Data Warehouse Toolkit. Wiley Computer Publishing, New York u.a. 1996. (aktuellste Auflage: 2. Aufl. von 2002) Kimball, R., Merz R.: The Data Webhouse Toolkit. Wiley Computer Publishing, New York u.a. 2000. Kurz, A.: Data Warehousing Enabling Technology. MITP, Bonn 1999. Mertens, P. u. a.: Grundzüge der Wirtschaftsinformatik. 7. Auflage, Springer, Berlin u. a. 2001. Mucksch, H., Behme, W. (Hrsg.): Das Data Warehouse-Konzept: Architektur – Datenmodelle – Anwendungen; mit Erfahrungsberichten. 2.Auflage, Gabler, Wiesbaden 1997. Mucksch, H., Behme, W. (Hrsg.): Das Data Warehouse-Konzept: Architektur – Datenmodelle – Anwendungen; mit Erfahrungsberichten. 4. Auflage, Gabler, Wiesbaden 2000. Müller, J.: Transformation operativer Daten zur Nutzung im Data Warehouse. Gabler, Wiesbaden 2000. Poe, V., Reeves L.: Aufbau eines Data Warehouse. Prentice Hall, München u. a. 1997. Schelp, J.: Modellierung mehrdimensionialer Datenstrukturen analyseorientierter Informationssysteme. Gabler, Wiesbaden 2000. Totok, A.: Modellierung von OLAP- und Data-Warehouse-Systemen. Gabler, Wiesbaden 2000.
