Zwischenbericht Teil B. Personalisierung internetbasierter Handelsszenarien

Transkript

1 Zwischenbericht Teil B der Projektgruppe Personalisierung internetbasierter Handelsszenarien DATA IN KNOWLEDGE OUT Tim Brüggemann, Tina Goldau, Christian Lüpkes, Michael Onken, Matthias Pretzer, Christian Reitenberger, Carsten Saathoff, Helge Saathoff, Ralph Stuber, Insa Stührenberg, Oliver Wien, Guido Zendel, Ralf Krause, Heiko Tapken Carl von Ossietzky Universität Oldenburg Fakultät 2 Department für Informatik Abteilung Informationssysteme Prof. Dr. Appelrath

2

3 Prof. Dr. Hans-Jürgen Appelrath Carl v. Ossietzky Universität Department für Informatik Escherweg Oldenburg appelrath@informatik.uni-oldenburg.de erschienen im Jahr 2003

4

5 Inhaltsverzeichnis 1 Einleitung 1 2 Data Warehousing Einführung Vorgehensweise Data Warehouse Definition Stärken und Schwächen eines Data Warehouse Abgrenzung zu OLTP Einsatzgebiete Referenzarchitektur Anforderungen an ein Data Warehousing Die Komponenten eines Data Warehouse Systems Beschreibung einer Referenzarchitektur und Phasen eines Data Warehousing Das multidimensionale Datenmodell Das multidimensionale Datenmodell Vorstellung verschiedener Designnotationen Struktur des multidimensionalen Datenmodells Operatoren des multidimensionalen Modells Versionierung von Dimensionstabellen Umsetzung des multidimensionalen Datenmodells Umsetzungsmöglichkeiten Relationale Speicherung Temporale Erweiterung des relationalen Datenmodells Fazit Beurteilung und Ausblick I

6 Inhaltsverzeichnis 3 Datenanalyse Allgemein Einleitung Datenanalyse: Einordnung und Überblick Data Mining und Datenanalyse in der Evolution der Datenbanksysteme Übersicht über die Allgemeine Datenanalyse Data Mining als Teil des KDD-Prozesses Gegenstand, Ziel und Methoden der Data Mining Verfahren Datenanalyse-Algorithmen Statistik Kennzahlen und Visualisierungsverfahren Nichtgraphische Statistische Verfahren Künstliche Neuronale Netze Teile eines KNN Netzstruktur Lernen Vor- und Nachteile sowie zeitliche Einordnung Self Organizing Maps Einleitung Algorithmus und Beispiel Zusammenfassung Online Analytical Processing (OLAP) Zugriffsmethoden durch OLAP Drei-Ebenen-Konzept OLAP im KDD-Prozess Bewertung Datenanalyse im Rahmen der Projektgruppe Der KDD-Prozess Einleitung Begriffliche Grundlagen Der KDD-Prozess Allgemeine Phasen des Prozess Verwandte Techniken Betrachtete Modelle Darstellung der Prozessschritte am CRISP-DM Aufbau und Grundfunktionalität Prozessphasen Andere Modelle II

7 Inhaltsverzeichnis Modell nach Fayyad Modell nach Brachman und Anand Modell nach Hippner und Wilde Modell SEMMA von SAS Verteiltes Data Mining Wichtige Aspekte für das Projekt Anwendung von Modellen in Softwarewerkzeugen KDD im Projekt Zusammenfassung Data Preprocessing - Datenvorverarbeitungsschritte des Prozessmodelles Einleitung Datenbereinigung (data cleaning) Fehlende Werte (missing values) Verrauschte Daten (noisy data) Inkonsistente Daten (inconsistencies) Nachteile der Datenbereinigung Datenintegration (data integration) Attributformate Probleme bei der Datenintegration Datentransformation (data transformation) Datenreduktion (data reduction) Aggregation (aggregation) Dimensionsreduktion (feature selection) Datenkompression (data compression) Numerische Datenreduktion (numerosity reduction) Diskretisierung und Konzepthierarchiebildung (discretization and concept hierarchy generation) Arten der Diskretisierung und Konzepthierarchiebildung für numerische Daten Arten der Diskretisierung und Konzepthierarchiebildung für kategorische Daten Fazit Einordnung in den Kontext der PG Vorteile der Datenvorverarbeitung im Kontext der PG Nachteile der Datenvorverarbeitung im Kontext der PG III

8 Inhaltsverzeichnis 6 Clustering und Klassifikation Einleitung Clustering Grundlagen Partitionierendes Clustering Hierarchisches Clustering Zusammenfassung Klassifikation Grundlagen Bewertung der Klassifikationsgüte Verfahren Zusammenfassung Fazit Assoziationsanalyse und Konzeptbeschreibung Einleitung Knowledge Discovery in Databases Assoziationsanalyse Motivation Grundlagen und Beispiele Der Apriori-Algorithmus Weitere Arten von Assoziationsregeln Konzeptbeschreibung und Generalisierung Motivation Einschub Generalisierung Unterschiede zwischen OLAP und Konzeptbeschreibung Charakterisierung Klassenvergleich Attributrelevanz Fazit Einordnung in den Projektgruppenkontext Temporale Aspekte des Data Mining Einleitung Motivation Vorgehensweise Grundlagen und Begriffe Data Mining Der Zeitbegriff IV

9 Inhaltsverzeichnis Granularität - Zeitpunkt - Zeitraum Repräsentationsformen Temporale Datenbanken Zeitreihen Äquivalenz von Zeitreihen und temporalen Datenbanken Temporale Muster Sequentielle Muster Zeitliche Assoziationsregeln Kalendarische Muster Intervall-basierende Ereignisse Trends Unusual Movements Temporale Datenanalyse Klassifikation Clustering Analyse sequentieller Muster Analyse zeitlicher Assoziationsregeln Ausblick Schlussbetrachtung Geschäftsmodelle Einleitung Entwicklung und gesetzliche Aspekte Kundenbindungssysteme Allgemeine Funktionsweise von Bonusprogrammen Kundeninformationssysteme von Bonusprogrammen Ausprägungen von Bonusprogrammen Auswirkungen von Bonusprogrammen Die Unternehmensseite Die Mitgliederseite Verschiedene Bonusprogramme Vergleich der Anbieter Verschiedene Vergleichsaspekte Datenweitergabe und Datennutzung Zusammenfassung Ausblick V

10 Inhaltsverzeichnis 10 Datenanalyse im Marketing Einleitung Anwendungsgebiete und angewendete Methoden Klassifikation im Bereich der Bonitätsprüfung Anwendungsgebiete, Motivation und Verfahren der Bonitätsprüfung Diskriminanzanalyse als Verfahren der Bonitätsprüfung in der Bankenbranche Entscheidungsbäume als Verfahren zur Bonitätsprüfung in der Bankenbranche Verfahrensvergleich der Methoden zur Bonitätsprüfung im Versandhandel Fuzzy Logik zur Bonitätsprüfung im Factoring Fazit bezüglich der vorgestellten Verfahren der Bonitätsprüfung Clustering - Praxisbeispiele aus dem Bereich der Kundensegmentierung Allgemeine Vorgehensweise des Clustering Kundensegmentierung in der Bankenbranche Käuferidentifikation im Automobilhandel Werbekampagnenentwurf der Lauda-Air Klassifikation + Clustering am Beispiel einer Kündigerprävention auf dem Mobilfunktmarkt Sortimentsanalyse im Einzelhandel Assoziationsanalyse zur Bildung von Assoziationsregeln im Einzelhandel Clustering zur Aufdeckung der Verbundwirkungen innerhalb eines Warensortiments Anwendung einer modernen Neurocomputing- Methode zur Quantisierung von Warenkorbdaten Prognose zur optimierten Werbeträgerplanung bei Versandhäusern Schlussfogerungen und Bezug zur Projektgruppe Verwendung personalisierter Daten im Web Einleitung Personalisierung Allgemeine Definition Vorteile der Personalisierung Rechtliche Aspekte VI

11 Inhaltsverzeichnis Mögliche Anwendungsgebiete Komponenten der Personalisierung Formen der Personalisieung Einbinden der Informationen Identifikation der Internetbenutzer Personalisierungstechniken Clusteranalyse Recommender Systeme Assoziations und Sequenzanalyse Klassifikationsanalyse Praxisbeispiele Fazit Web Usage Mining Einführung Web Content Mining Web Structure Mining Web Usage Mining Gliederung Grundlagen Das Internet Web Log User Sessions Begriffe Daten-Vorverarbeitung Entfernung irrelevanter Zugriffe Konzepthierarchien Algorithmen g-sequenzen Der Apriori-Algorithmus für g-sequenzen GSM - General Sequence Miner Usage Cluster Analyse der Mining-Ergebnisse Manuelle Analyse Recommendation - Automatisches Verarbeiten der Mining Ergebnisse Fazit Rolle in der PG VII

12 Inhaltsverzeichnis 13 Rechtliche und soziale Aspekte der Datenanalyse Begriffe und Prozesse Rechtliche Aspekte der Datenanalyse Das Bundesdatenschutzgesetz Bewertung der Schritte des Knowledge Discovering in Databases Forschung und Datenschutz Umgehung von Datenschutz Soziale Auswirkungen der Datenanalyse Beispiele des Customer Relationship Management Beispiele im Gesundheitsbereich Beispiele im Unternehmensbereich Lösungsansätze Unternehmenspolitik Forschungsumfeld Einordnung der Projektgruppe Ausblick Zusammenfassung 401 Abbildungsverzeichnis 403 Tabellenverzeichnis 408 Algorithmen 409 Literatur 411 Glossar 439 Index 465 VIII

13 1 Einleitung Dieser Zwischenbericht fasst die Ergebnisse des Projektgruppe Personalisierung internetbasierter Handelsszenarien zusammen, die bis März 2003 erzielt wurden. Der bisherige Zeitraum entspricht in etwa der Halbzeit des Zeitraums, in der die Projektgruppe stattfindet. Die Projektgruppe mit dem selbstgewählten Arbeitstitel DIKO (Data In-Knowledge Out) findet am Department für Informatik der Universität Oldenburg statt und umfasst das Wintersemester 2002/2003 sowie das Sommersemester Dieser Bericht setzt sich aus zwei Teilen zusammen: ˆ Teil A fasst den bisherigen Ablauf und die Ergebnisse der Projektgruppe zusammen. ˆ Teil B enthält die ausgearbeiteten Seminarvorträge aus dem ersten Abschnitt der Projektgruppe. Nach Abschluss der Projektgruppe im Herbst 2003 wird ein Endbericht ebenfalls als interner Bericht erscheinen. Innerhalb der Seminarphase der Projektgruppe wurden insgesamt zwölf Vorträge gehalten, welche die Teilnehmer der Projektgruppe organisatorisch und inhaltlich auf die Projektgruppe vorbereiten sollten. Die schriftlichen Ausarbeitungen der Seminarvorträge werden in diesem Bericht zusammengefasst. Die Beiträge sind in folgende drei Gruppen gegliedert: ˆ 1.Teil: Einführung in die Datenanalyse Data Warehousing Datenanalyse allgemein Der KDD-Prozess ˆ 2.Teil: Technische Aspekte der Datenanalyse 1

14 1 Einleitung Data Preprocessing - Datenvorverarbeitungsschritte des Prozessmodelles Clustering und Klassifikation Assoziationsanalyse und Konzeptbeschreibung Temporale Aspekte des Data Mining ˆ 3.Teil: Datenanalyse in der Praxis Geschäftsmodelle Datenanalyse im Marketing Verwendung personalisierter Daten im Web Web Usage Mining Rechtliche und soziale Aspekte der Datenanalyse 2

15 2 Data Warehousing Insa Stührenberg Die Datenmengen in den Betrieben wachsen stetig. Neben den operativen Datenbanksystemen, die dem operativen Tagesgeschäft dienen, haben sich Data Warehouses als Speicherkomponente etabliert. Ein Data Warehouse stellt eine integrierte und bereinigte Datenbank dar, die eine zeitliche Sicht auf die Daten ermöglicht. Um eine Datenhistorisierung zu gewährleisten, dürfen veränderte Datensätze nicht einfach überschrieben werden. Ein Data Warehouse stellt nur einen Bestandteil eines Data Warehouse Systems dar. Als Data Warehousing wird der gesamte Prozess der Datenbeschaffung, Integration und Analyse bezeichnet. Die wichtigsten Anwendungen sind die interaktive Datenanalyse OLAP sowie Data Mining. Konzeptionell liegt einem Data Warehouse das multidimensionale Datenmodell zugrunde. Dieses Modell verwendet die Datenunterteilung in Fakten und Dimensionen, die in ihrer Kombination einen Würfel bilden. Dimensionshierarchien schaffen einen Verdichtungsgrad, der für die Analyse angemessen ist. Für die Berücksichtigung temporaler Gesichtpunkte werden in einem Data Warehouse Zeitstempel verwendet. Diese können entweder auf Attribut- oder Tupelebene eingeführt werden. Für die Umsetzung des multidimensionalen Datenmodells existieren mehrere Möglichkeiten. Neben der direkten multidimensionalen Abbildung (MOLAP), ist auch eine relationale Umsetzung (ROLAP) der multidimensionalen Konstrukte realisierbar. Wenn Detaildaten in Relationen gespeichert werden und gewisse Verdichtungen multidimensional gehalten werden, wird das hybride OLAP (HOLAP) verwendet. 3

16 2 Data Warehousing 2.1 Einführung Data Warehouses haben aufgrund des enormen Anstiegs des Datenvolumens in den Betrieben an Bedeutung gewonnen. Die Daten stammen aus Quellen vom Point-of-sale bis zum Back-Office-System, aber auch verstärkt aus E-Business-Anwendungen. Der Wunsch wächst, in grossen Datenbeständen die Übersicht zu behalten. Ferner sollen mit möglichst geringem Aufwand interessante Zusammenhänge erkennbar werden. Mit steigendem Interesse wird die Möglichkeit der Analyse und Auswertung von akkumulierten Daten genutzt, um die strategische Unternehmensplanung zu optimieren. Da der Datenbestand oft in unterschiedlichen Formaten und verteilt vorliegt, erweist sich ein zentraler Datenzugang als weniger geeignet. Theoretisch ist es realisierbar, die internen Daten je nach Bedarf unmittelbar aus den Dateien oder Datenbanken zu holen. Die hohe Zugriffszeit und die enorme Aufbereitungszeit der Daten lassen diese Methode allerdings fraglich erscheinen. Effektiver ist es, die gefragten Daten aus den Datenbanken der operativen Anwendungssysteme zu selektieren und zu aggregieren, um sie dann in einer eigenen Datenbank (einem Data Warehouse) zu verwalten und durch OLAP ( On Line Analytical Processing)-Techniken auszuwerten. Die Aufgabenstellung dieser Arbeit lässt sich demnach an zwei Kernfragen verdeutlichen: 1. Wie werden einfliessende Daten verschiedener heterogener Quellen integriert? 2. Welches Datenmodell liegt einem Data Warehouse konzeptionell zu Grunde und wie erfolgt dessen Umsetzung? Daraus ergibt sich als Zielsetzung dieser Arbeit, die Möglichkeiten eines Data Warehousing herauszustellen Vorgehensweise In Kapitel 2.2 erfolgt eine allgemeine Erläuterung eines Data Warehousing, wodurch ein erster Überblick über dieses Konzept gegeben wird. Es wird deutlich, dass Unternehmen durch den Einsatz eines Data Warehouse grosse Produktivitätsverbesserungen und Wettbewerbsvorteile gegenüber Konkurrenten erzielen können. Das nächste Kapitel stellt die Anforderungen und Phasen eines Data Warehousing 4

17 2.2 Data Warehouse vor. Zusätzlich wird die Referenzarchitektur eines Data Warehouse Systems mit den einzelnen Komponenten erläutert. Ferner wird herausgestellt, dass ein Data Warehouse nicht zwingend zentral vorliegen muss. Inhalt des 2.4 Kapitels ist die Vorstellung des multidimensionalen Datenmodells. Dieses eignet sich auf konzeptioneller Ebene am besten für die Modellierung eines Data Warehouse. Es bietet dem Anwender eine Denkweise in Dimensionen und Fakten(vgl. Abschnitt 2.4.3). In Kapitel 2.5 werden Realisierungskonzepte für die Umsetzung des multidimensionalen Datenmodells vorgestellt. Eine Möglichkeit ist die direkte multidimensionale Datenspeicherung multidimensionaler Konstrukte. Die Abbildung des Datenmodells auf das relationale Datenbanksystem stellt eine Alternative hierzu da. Im letzten Kapitel werden die erarbeiteten Erkenntnisse dieser Arbeit zusammengefasst und beurteilt. Zusätzlich wird der Bezug zu unserer Projektgruppe Personalisierung internetbasierter Handelsszenarien hergestellt. 2.2 Data Warehouse In diesem Kapitel wird das Konzept eines Data Warehousing vorgestellt. Nach einer umfassenden Erläuterung des Begriffes Data Warehouse erfolgt eine Gegenüberstellung der Vor- und Nachteile eines Data Warehouse. Im Anschluss werden die OLAP-Anwendungen von den OLTP (On Line Transactional Processing)-Anwendungen abgegrenzt und die Einsatzgebiete eines Data Warehouse benannt Definition In der Literatur gibt es zahlreiche Definitionen für den Begriff Data Warehouse, wodurch die Schwierigkeit einer allgemein zutreffenden Erklärung verdeutlicht wird. A datawarehouse is a copy of transaction data specifically structures for querying and reporting [KRRT98]. Diese Definition von Kimball betrachtet lediglich die verschiedenen Aufgaben eines Data Warehouse. Es vernachlässigt somit die Existenz gespeicherter Daten im Data Warehouse, die nicht für die Abfrage o.ä. gedacht sind. Die etablierteste Definition ist die von Inmon: A Data Warehouse is a subject-oriented, integrated, time-variant and nonvolatile collection of data in support of managements decision and making process (vgl.[man00]). 5

18 2 Data Warehousing ˆ Fachorientierung (subject- oriented): Ein Data Warehouse ist fach- bzw. subjektorientiert, indem es verschiedene Sachverhalte eines Unternehmens ( subjects wie Kunde, Verkäufe) betrachtet. Der Auswertungsaspekt steht beim Data Warehouse deutlich im Mittelpunkt. Innerbetriebliche Abläufe und Funktionen sind hingegen von untergeordnetem Interesse. Das Schema ist also analyseorientiert. ˆ Integration (integrated): Im Vergleich zu operativen Systemen werden in einem Data Warehouse Daten aus verschiedenen Quellen verarbeitet. Sie werden in einer einzigen, allgemeingültigen Form gespeichert. ˆ Nicht- flüchtige Daten (non- volatile): Auf den Datenbestand eines Data Warehouse sind keine Änderungen erlaubt, sondern nur lesende Zugriffe. Daten werden in periodischen Abständen hinzugeladen, aber nicht modifiziert. Sie werden also nach einmaliger Eingabe nicht mehr geändert. Daher besitzt ein Data Warehouse eine persistente und stabile Datenbasis [Man00]. ˆ Historisierte Daten (time-variant): Ein Data Warehouse speichert im Vergleich zu den operativen Systemen auch historisierte Daten. Es bietet durch diese Historisierung der Daten einen Vergleich der Daten und Analysen über einen längeren Zeitraum. Der allgemeine Zeithorizont eines Data Warehouse beträgt etwa 5-10 Jahre (der der operativen Systeme hingegen nur Tage). Ein Data Warehouse stellt somit eine physische Datenbank dar, die eine zeitabhängige Sicht auf beliebige integrierte und bereinigte Daten ermöglicht. Es stellt aber nur ein Bestandteil eines Data Warehouse Systems dar (vgl. Abschnitt 2.3.3). Die einzelnen Komponenten dieses Systems dienen hierbei sowohl der Integration (Bsp. Datenbeschaffung) als auch der Analyse der Daten. Data Warehousing umschreibt den gesamten dynamischen Prozess. Es umfasst alle Schritte der Datenbeschaffung, der Speicherung und der Analyse. Somit beinhaltet es die Integration, Transformation, Konsolidierung, Bereinigung und Speicherung der Daten sowie die Datenbereiststellung für analytische Zwecke und Interpretationen [SAP02]. Ein Data-Warehouse-System ist also mehr als die Summe seiner 6

19 2.2 Data Warehouse Komponenten [BG01]. Erst der Prozess an sich erreicht die Ziele des Systems. Um die Potentiale eines Data Warehouse auszuschöpfen, wird ein Modellierungsansatz für die Analyse benötigt. Oft wird das multidimensionale Datenmodell verwendet. Dieses stellt Strukturen und Auswertungskomponenten bereit, die bereits bei der Modellierung eine Analyse ermöglichen (vgl. Kapitel 2.4). Als wichtigste Anwendungen gelten die interaktive Datenanalyse OLAP sowie das Data Mining, die Suche nach unbekannten Mustern oder Beziehungen in Daten für die Erlangung neuer Informationen Stärken und Schwächen eines Data Warehouse Ein Vorteil eines Data Warehouse ist die verbesserte Datenqualität. Die Daten sind genauer und liegen durch einfache Transformation und Bereinigung in einem konsistenten Zustand vor. Ein Data Warehouse kann die Abfrageperformance beschleunigen, wodurch eine schnellere Informationsbeschaffung ermöglicht wird. Die Historisierung der Daten lässt ferner historische Trends erkennen. Die Leistung, die die Verarbeitung operativer Daten ermöglicht, wird durch den Einsatz eines Data Warehouse zusätzlich besser nutzbar. Nicht zuletzt unterstützt ein Data Warehouse Restrukturierungsmassnahmen und erhöht wegen der geringen Komplexität der Systemarchitektur die Flexibilität. Aus allgemeiner Unternehmenssicht ermöglicht der Einsatz eines Data Warehouse dem Unternehmen eine Verbesserung der Kundenbeziehungen. Durch die Erstellung von Kauf- und Kundenprofilen kann der Anbieter individuell auf die Kundenpräferenzen eingehen (z.b. mit Sonderangeboten). Ein Data Warehouse steigert ferner die Effizienz eines Unternehmens und hilft, Implementierungs- und Wartungskosten eines Data Warehouse zu kontrollieren. Die Potentiale sind allerdings nur erreichbar, wenn ein Data Warehouse professionell eingesetzt wird. Die Verständigung zwischen Anwender, IT-Abteilung sowie Projektmanagement muss dafür vorbildlich und ausgereift sein (vgl. [In 99]). Ferner können Probleme beim Datenmanagement auftreten. Eine effiziente und wartbare Aktualisierung eines Data Warehouse mit neuen Daten ist nicht immer einfach. Da die Datenbeschaffung auf einzelne Komponenten verteilt ist, müssen bei einer Änderung dieses Prozesses alle betroffenen Elemente angepasst sowie ihre technische Zusammenarbeit neu getestet werden. Der Einsatz von Extraktions-Transformation-Lade-Werkzeugen 7

20 2 Data Warehousing hat dieses Problem gemindert (vgl. [HA02]). Eine weitere Schwäche eines Data Warehouse sind die enormen Kosten hinsichtlich Hard-, Software und Personal vor allem in der Anfangsphase eines Data Warehouse. Ebenso muss das Management von dem Einsatz eines Data Warehouse überzeugt werden. Nicht zuletzt ist bei dem Einsatz eines Data Warehouse zu beachten, dass ein Trainingsbedarf für den Endbenutzer hinsichtlich des Datenzugriffes entsteht Abgrenzung zu OLTP Um die Möglichkeiten eines Data Warehouse zu verstehen, ist es zunächst nötig, OLTP-Anwendungen von OLAP-Anwendungen abzugrenzen. OLTP-Anwendungen haben für eine auszuführende Transaktion nur begrenzte Datenmengen zu verarbeiten. Sie operieren immer auf dem aktuellsten Datenbestand. Dadurch eignen sie sich für das operative Tagesgeschäft (Bsp. Flugreservierungssystem). Dabei können die Daten nicht nur gelesen, sondern auch modifiziert werden. Das Schema ist eindeutig anwendungsorientiert. Der Fokus liegt bei diesen Anwendungen auf der Dateneingabe. Die ausschliesslich lesenden OLAP-Anwendungen verarbeiten hingegen grosse Datenmengen und arbeiten vor allem mit historisierten Daten. Daher dienen diese der strategischen Unternehmensplanung (Bsp. zur Beantwortung der Fragestellung: Wie hat sich die Auslastung der Transatlantikflüge über die letzten zwei Jahre entwickelt?). Der Schwerpunkt liegt hier auf der Informationslieferung. Da OLAP-Anfragen komplex sind, beeinträchtigen sie bei paralleler Auswertung mit den einfachen, transaktionalen Anwendungen letztere in ihrer Leistung. Diese Unvereinbarkeit hat zur Entwicklung von Data Warehouse-Systemen geführt [KE97]. Die wichtigsten Unterschiede sind zusammengefasst in Abbildung 2.1 (vgl.[acpt99]) dargestellt. Deutlich wird, dass die Unterschiede zwischen OLAP und OLTP zu einem anderen Benutzerkreis und unterschiedlichen Prioritäten führen. Kimball betont als wichtigsten Unterschied, dass ein Data Warehouse im Gegensatz zu den operativen Systemen die Vergangenheit beschreiben kann [Kim96]. 8

21 2.2 Data Warehouse Merkmal OLTP OLAP Orientierung Transaktion Analyse Nutzer Angestellter, DBA etc. Manager, Analysten etc. Datenbankdesign ER basiert Star/Snowflake Fokus Dateneingabe Informationsausgabe Operationen Index/hash auf Scan Primärschlüsssel Priorität Performance, Flexibilität Verfügbarkeit Summierbarkeit hoch detailliert summiert, konsolidiert Zugang schreibend/lesend lesend Arbeitseinheit kurze, einfache Transaktion komplexe Anfragen Tabelle 2.1: OLTP versus OLAP Einsatzgebiete Der Grundgedanke eines Data Warehouse ist die Datenanalyse. Sobald Daten gespeichert werden, entsteht meistens ebenso das Interesse, diese auch auszuwerten zu können. Daher sind die Anwendungsgebiete eines Data Warehouse breit gefächert. Sie reichen von der Betriebswirtschaftslehre über technische Anwendungen bis hin zu den Wissenschaften. Am häufigsten werden Data Warehouse-Systeme jedoch in der Betriebswirtschaft (v.a. Marketing, Controlling) eingesetzt. Bei informationsorientierten Anwendungen fördern sie insbesondere im Berichtswesen die Kennzahlenerstellung. Ein wichtiges Einsatzgebiet liegt im E-Commerce. Ein Data Warehouse sammelt und archiviert hierbei die Daten über das Kundenverhalten im Internet. Es unterstützt durch die dynamische analytische Informationsauswertung die E-Commerce- Lösungen der einzelnen Abteilungen. Dadurch ermöglicht es die Personalisierung dieser Anwendungen. Da das Beschaffungsverhalten analysierbar wird, werden diese Systeme auch bei der Onlinebeschaffung über Marktplätze oder E-Procurement-Lösungen genutzt. Ebenso ermöglichen sie einen Austausch unterschiedlicher Planungsinformationen, wodurch sie auch bei der Erstellung von Supply-Chains 9

22 2 Data Warehousing eingesetzt werden. In analyseorientierten Anwendungen werden Data Warehouses vor allem in der Kosten- und Leistungsrechnung eingesetzt. Für die Planungsunterstützung eines Unternehmens müssen Data Warehouses neben Ist- auch Plandaten speichern. Dadurch wird ein Plan/Ist- Vergleich möglich, um die Wirtschaftlichkeit eines Unternehmens beurteilen zu können. In kampagnenorientierten Anwendungen liefern Data Warehouses die Daten, um eine Kampagne zu starten. Am Ende dieser ermöglichen sie es zusätzlich, dessen Erfolg zu beurteilen (Bsp. Customer-relationsship-Management-System zur Betrachtung der Kundenbeziehungen auf unterschiedlichen Ebenen) [BG01, Han01b]. 2.3 Referenzarchitektur Dieses Kapitel stellt eine Referenzarchitektur eines Data Warehouse Systems vor. Diese besteht aus verschiedenen Komponenten. Ein Data Warehouse stellt somit nur ein Bestandteil des Systems dar. Der Datenbestand eines Data Warehouse kann dabei auch verteilt vorliegen. Nachdem zuerst auf die Anforderungen an ein Data Warehousing eingegangen wird, werden anschliessend die einzelnen Systemkomponenten erläutert. Hierbei werden die jeweiligen Aufgaben, die Funktionsweise sowie der Zusammenhang dieser Komponente im System beschrieben. Abschliessend erfolgt eine allgemeine Beschreibung einer Referenzarchitektur sowie der Phasen eines Data Warehousing Anforderungen an ein Data Warehousing In diesem Abschnitt werden die Anforderungen an ein Data Warehousing vorgestellt. Wichtig ist eine Unabhängigkeit zwischen Datenquellen und Analysesysteme hinsichtlich Verfügbarkeit (d.h. bei Systemausfällen), Belastung sowie Änderungen in den Quellsystemen. Ferner soll es integrierte und abgeleitete Daten dauerhaft bereitstellen. Diese Daten müssen persistent gespeichert und mehrfach verwendbar sein. Es muss flexibel mit ihnen gearbeitet werden können. Ausserdem fordern Data Warehouses Skalierbarkeit. Erweiterungen sollen möglich sein, die bereits existierende Strukturen nicht verändern und neue Quellen integrieren. Die Prozesse (vgl.abschnitt 2.3.3) müssen möglichst automatisch ablaufen. Ferner muss Eindeutigkeit hinsichtlich Datenstrukturen, Zugriffsrechten und Prozessen herrschen. Nicht 10

23 2.3 Referenzarchitektur zuletzt ist eine Anforderung an ein Data Warehousing die Möglichkeit individueller Nutzersichten (also anwenderspezifische Datenbestände). Die Architektur sollte sich am Ziel dieser ausrichten, d.h. also an der Datenanalyse. Damit die enthaltenen Daten entscheidungsrelevant sind, müssen diese bei der Übernahme aggregiert und verdichtet werden. So interessiert sich ein Manager nicht für die einzelnen Bestellpositionen, sondern eher für die Quartals- und Jahressummen Die Komponenten eines Data Warehouse Systems Die einzelnen Bestandteile eines Data Warehouse Systems werden im folgenden vorgestellt und in Abbildung in ihrer Gesamtheit grafisch dargestellt [BG01]. Der Data-Warehouse-Manager initiiert, lenkt und überwacht die einzelnen Prozesse in allen Phasen. Er muss die Prozesse automatisch ablaufen lassen, indem er die Vorgänge durch Kontrollflüsse steuert. Der Datenbeschaffungsprozess kann dabei regelmässig erfolgen, abhängig von Datenänderungen oder aufgrund ausdrücklichen Verlangens [BG01]. Die Datenquelle (Bsp. interne oder externe Datenbank, flat files, www-seiten) beeinflusst durch die Art der Datenspeicherung die Analysefähigkeit eines Data Warehouse-Systems. Sie stellt einen Bestand von Daten mit Inhalten für die Datenanalyse dar. Hinsichtlich Struktur, Inhalt und Schnittstellen ist sie von heterogener Art. Als Quelldaten werden dabei die Daten in Verbindung mit deren Beschreibungen bezeichnet. Diese können nach verschiedenen Merkmalen klassifiziert werden (Bsp. Herkunft: intern und extern, Zeit: aktuell und historisch). Diese Einteilung ermöglicht eine Strukturierung und verbesserte Übersichtlichkeit der Datenquellen. Bei der Betrachtung der Quelle und deren Auswahl muss sowohl der Verwendungszweck eines Data Warehouse und die Quelldatenqualität (Bsp. Konsistenz, Korrektheit) als auch die Verfügbarkeit (organisatorisch und technisch) und der Preis für den Datenerwerb beachtet werden [BG01]. Monitore sollen Datenmanipulationen in den Quellsystemen aufdecken. Allgemein ist Monitoring die Voraussetzung für die Anpassung eines Data Warehouse an die aktuelle Nutzung. Es gibt meist einen Monitor pro Datenquelle, da seine Funktionsweise von den 11

24 2 Data Warehousing dessen Merkmalen und den Anforderungen der Analysekomponenten abhängt. Es gibt verschiedene Monitoring-Strategien. Eine Variante aktiviert bei Änderungen einen Trigger, der die Änderungen beispielsweise in eine Datei schreibt. Die Methode der Replikation schreibt einen geänderten Datensatz in eine spezielle Tabelle. Eine weitere Strategie arbeitet mit Zeitstempeln. So wird jedem Datensatz ein Zeitstempel zugewiesen, der den Zeitpunkt der Änderung enthält. Bei der Log-basierten Methode werden Änderungen in eine Log-Datei geschrieben. Eine weitere Alternative basiert auf Snapshot- Dateien. Hierbei wird in regelmässigen Abständen der Datenbestand in eine Schnappschussdatei geschrieben. Für die Entdeckung von Änderungen wird dann der aktuelle Datenbestand mit einem Schnappschuss der alten Daten verglichen. Der Arbeitsbereich enthält die Daten des Datenbeschaffungsbereichs (engl. staging area). Der Datenbeschaffungsbereich wiederum enthält alle Komponenten, die funktional zwischen den Datenquellen und der Basisdatenbank liegen. Damit integriert er heterogene Daten. Im Arbeitsbereich werden die Daten temporär zwischengespeichert sowie bereinigt und integriert. Dadurch behindern die Datentransformationen die anderen Komponenten des Systems nicht. Ferner werden die transformierten Daten erst nach erfolgreichem Abschluss der Transformation in ein Data Warehouse geladen. Die Extraktionskomponente dient der Datenübertragung aus einer Datenquelle in den Arbeitsbereich. Sie stellt daher die Verbindung zu den operativen/externen Datenquellen dar. Ferner unterstützt sie die Auswahl der Quellen, die importiert werden sollen (unabhängig von ihrer Speicherform). Daten werden entweder periodisch, auf Anfrage, aufgrund von Ereignissen oder sofort nach Änderungen extrahiert. Die Extraktion wird normalerweise durch Schnittstellen zwischen Netzwerken und Standarddatenbankschnittstellen (Bsp. ODBC) technisch umgesetzt. Das Ermitteln von Datenänderungen erfolgt in Abhängigkeit der gewählten Monitoring- Strategie [Man00]. Die Transformationskomponente: Die relevanten operativen Daten des Arbeitsbereiches unterscheiden sich strukturell (Bsp. Schemaintegration) und inhaltlich (Bsp. Datenbereinigung). Daher ist es notwendig, sie in einen geeigneten Zustand zu bringen. Heterogene Daten brauchen zunächst ein einheitliches Format für ihre Vergleich- 12

25 2.3 Referenzarchitektur barkeit (durch z.b. Teilung/ Kombination von Attributen, Vereinheitlichung von Datumsangaben). Data Migration bezeichnet hierbei die Standardisierungstransformationen, die eine Integration heterogener Daten bewirkt. Data Scrubbing stellt den Prozess der Verbesserung der Datenqualität mit Hilfe von Software-tools dar. Die Datensemantik wird hierbei mit Hilfe von domänenspezifischen Wissen kontrolliert (Bsp. Postleitzahlenverzeichnisse). Data Auditing hat die Entdeckung von Beziehungen und Regelmässigkeiten in den Daten zur Aufgabe [Man00]. Ziel ist es also, die verschiedenen Schemata der einzelnen Datenquellen in das Schema zu transformieren, das dem allgemeinen Datenmodell folgt [Bre01]. Die Ladekomponente: Die transformierten Daten des Arbeitsbereiches sind speicher-ungs- und auswertfähig. Für die Weiterleitung ist eine Komponente notwendig, um die analyseunabhängigen Detaildaten in die Basisdatenbank zu übertragen. Eine andere muss die analysespezifischen Daten aus der Basisdatenbank in ein Data Warehouse transferieren. Wenn ein gespeicherter Datensatz geändert werden muss, darf dieser aufgrund der Forderung nach Datenhistorisierung nicht überschrieben werden. Der geänderte Datensatz muss stattdessen gespeichert werden. Zu unterscheiden sind Online- und Offline-Ladevorgänge. Während beim ersteren auch während des Ladens ein Data Warehouse verfügbar ist, ist dies beim letzteren nicht der Fall. Beim Offline-Ladevorgang sind somit während des Ladens Anfragen an ein Data Warehouse nicht erlaubt. Ein Ladevorgang sollte ferner in einem günstigen Zeitraum stattfinden (Bsp. nachts, Wochenende). Eine grosse Datenmenge zwingt hierbei zu effizienteren Maßnahmen (Bsp. durch Parallelisierung). Die anwendunsgneutrale Basisdatenbank stellt eine integrierte Datenbasis dar. Ihre Aufgabe ist die Sammlung, Integration und Verteilung der Daten. Dies ermöglicht eine Mehrfachverwendung und flexible Datenverwendung. Sie enthält aktuelle sowie historisierte Daten, die bereits bereinigt sind. Ausserdem stellt die Basisdatenbank die Analysebasis dar. Sie hat also ebenso eine Auswertungsfunktion. Die Basisdatenbank wird entweder in Echtzeit aktualisiert, in periodischen Abständen oder in Abhängigkeit einer Änderungsquantität (d.h., wenn eine bestimmte Änderungszahl erreicht wird). Es muss erkennbar sein, um welche Daten es sich handelt und v.a. wie sie im Laufe ihres Weges transformiert worden sind. Zusätzlich muss 13

26 2 Data Warehousing ein Datenzugriff technisch möglich sein. Es werden also verfügbare und nachvollziehbare Daten gefordert. Da der Einsatz einer Basisdatenbank sowohl mit hohem Aufwand als auch enormen Kosten verbunden ist, wird in der Praxis oft auf diese Komponente verzichtet. Grafisch wird die Anordnung der Basisdatenbank als Nabel-Speiche- Architektur dargestellt. Dabei sind die Datenquellen und das Data Warehouse die Speichen und die Basisdatenbank die Nabe. Dies bewirkt eine Reduktion der Schnittstellen, da der Transport der Daten nur indirekt erfolgt [BG01]. Data Warehouse: Indem ein Data Warehouse mit dem Repositorium und der Basisdatenbank verbunden ist, enthält es alle analyserelevanten Daten. Es muss die vom Anwender benutzten und geforderten Daten dauerhaft verwalten und bei Analysen bereitstellen. Somit passt sich die Strukturierung an den Analysebedarf an. Da die Struktur eines Data Warehouse die Struktur des OLAP-Speichers beeinflusst, nimmt sie auch Einfluss auf die Anfrageperformance. Dem Analyseprogramm werden die relevanten Daten bei Bedarf gegeben. Ein Data Warehouse bietet neben diesen Zugriffsfunktionen auch Funktionen der Verarbeitung. Durch diese Schnittstelle kann eine Anwendung formulieren, was gebraucht wird. Tuningparameter und Mechanismen bieten eine effiziente Anfrageverarbeitung (Bsp. Zugriffsstrukturen). Indem die Daten aus der Basisdatenbank geladen werden, werden sie aktualisiert. Da viele Datensätze pro Zeiteinheit in ein Data Warehouse gelangen, besitzen viele Datenbanksysteme zudem einen Massenlader (engl.bulk loader). Indem einige Funktionen für die Ladezeit abgeschaltet sind (Bsp. Mehrbenutzerkoordination), kann die Ladeperformance erhöht werden. Verteilung eines Data Warehouse/Data Marts: Ein Data Warehouse, das haupt-sächlich detaillierte Firmendaten enthält, muss nicht zwingend zentral vorliegen. In der Praxis wird eine Verteilung der Verarbeitungs- und Administrationslast bevorzugt. Dadurch wird ein zentrales Data Warehouse ausgeschlossen. Dieses bietet zwar einerseits Datenintegrität und einen single point of truth, aber andererseits bedeutet es aber auch eine starke Netzwerkbelastung und mangelnde Flexibilität hinsichtlich Skalierbarkeit. Das sogenannte Data Mart-Konzept liefert stattdessen eine inhaltlich beschränkte Sicht auf ein Data Warehouse. Es bildet Extrakte der Data Warehouse-Daten, die für bestimmte Benutzer mit einem homo- 14

27 2.3 Referenzarchitektur genen Informationsbedürfnis ausgerichtet sind. Aus Datenbanksicht entspricht es der Verteilung eines Data-Warehouse-Datenbestandes. Vorteilhaft ist hierbei, dass meist aggregierte und nicht mehr so stark normierte Daten vorliegen. Dadurch ist die Performance der Abfragen höher als bei einem Data Warehouse selbst. Oft wird dieses Konzept auch wegen der Benötigung von Zugriffrechten für den Nutzer eingesetzt. Es ermöglicht ferner die Abbildung der Unternehmensstruktur mit den Verantwortlichkeiten, indem z.b. jede Abteilung ein Data Mart bekommt. Dadurch ist eine Unabhängigkeit der Abteilungen erreichbar. Data Marts können auch den Beginn eines zentralen Data-Warehouse-Entwurfs darstellen. So errichtet jede Abteilung ihr eigenes Data Mart. Diese werden dann unternehmensweit zusammengefügt, wodurch sie dann ein zentrales Data Warehouse bilden. Dieses Verfahren ist zeitsparender und kostengünstiger. Data Marts sind hier als eine Art Prototyp einzusetzen, die die Kontrolle der Anforderungen ermöglichen [Bre01]. Think big, start small : Dieses Vorgehen führt also nur zum Erfolg, wenn bereits zu Beginn des Entwurfs die spätere Zusammenführung der einzelnen Marts mit eingeplant wird. Sonst besteht die Gefahr von Insellösungen. Das Data Mart-Konzept ist ferner sinnvoll, wenn Spezialdaten vorliegen, die nur von bestimmten Benutzergruppen benötigt werden. Eine Speicherung dieser Daten in einem zentralen Data Warehouse wäre hier nicht angebracht. Das übergeordnete Ziel dieses Konzeptes ist demnach die Komplexitätsreduktion sowie die Verringerung des Datenvolumens. Konkret gibt es zwei Ausprägungen: Abhängige Data Marts (vgl. Abbildung 2.1 [BG01]) sind Extrakte aus dem integrierten Datenbestand der Basisdatenbank. Ihnen liegt eine integrierte Datenbasis zugrunde. Dadurch sind Analysenergebnisse auf dessen Datenbestand aufgrund der fehlenden Normierung die gleichen wie die auf ein Data Warehouse. Die Extrakte können strukturell gebildet werden (Beschränkung auf Schemateile Bsp. bestimmte Dimension), inhaltlich (Bsp. letzte Jahresergebnis) oder aggregiert. Bei letzterem wird die Granularität verringert (Bsp. Beschränkung auf Monatsergebnisse. Neben dem geringerem Datenvolumen ermöglichen abhängige Data Marts schnellere Antwortzeiten und eine Zugriffslokalität der Daten. Unabhängige Data Marts (vgl. Abbildung 2.2 [BG01]) sind isolierte Sichten auf die Quellsysteme. Sie stellen kleine Data Warehouses dar, die keine integrierte Datengrundlage besitzen. Daher können sie nur entstehen, wenn keine Basisdatenbank existiert. Eine nachträgli- 15

28 2 Data Warehousing Abbildung 2.1: Abhängige Data Marts che Transformation und Integration in einen übergeordneten Analysekontext ist daher zwingend. Dadurch wird das Integrations- und Transformationsproblem nicht gelöst, sondern nur auf einen späteren Zeitpunkt verschoben. Verschiedene Analysesichten sowie die Konsistenz der Analysen werden aufgrund der zusätzlichen Transformation hierbei zum Problem. Data-Mart-übergreifende Analysen sind nicht realisierbar (Bsp. abteilungsübergreifend). Unabhängige Data Marts bieten zwar ein schnelles Vorgehen, eine Ausfallsicherheit und schnelle Ergebnisse, jedoch sind sie schwer änderbar und unflexibel. Datenintegrität und single point of truth sind hier nicht gegeben. Abbildung 2.2: Unabhängige Data Marts Es gibt auch Architekturen ohne Data Warehouse.Hier liegen stattdessen nur Data Marts vor, die virtuell ein Data Warehouse bilden (vgl.[bg01]). Analyse bezeichnet alle Operationen, die mit den Daten eines Data Warehouse durchgeführt werden, um neue Informationen zu generie- 16

29 2.3 Referenzarchitektur ren (Bsp. Anfrage von Analysefunktionen auf ausgewählte Daten). Durch Analysewerkzeuge können die Anwender die gesammelten Daten mit interaktiven Navigations- und Analysemöglichkeiten präsentieren. Zu den Darstellungselementen gehören neben Tabellen (v.a. Pivottabellen) und Grafiken auch Text sowie multimediale Elemente (Bsp. Videosequenz). Die Werkzeuge sind meist auf die Anwender und Einsatzgebiete zugeschnitten. Zur Realisierung gibt es Standard Reporting Werkzeuge für die Berichtserstellung und -Verteilung sowie Berichtshefte (engl. briefing books), welche als Entwicklungsumgebungen z.b. Tabellen darstellen können. Ausserdem gibt es ad-hoc-queries & Reporting, die Berichte grafisch erstellen und Informationen in Form von Kennzahlen und Dimensionen liefern. Eine eigene Oberfläche für die mehrdimensionalen Datenanalyse und -anfrage bieten Analyse- Clients. Ferner gibt es Spreadsheet Add-ins, die Tabellenkalkulationen um Datenanbindung und Navigation erweitern. Für die Realisierung gibt es ebenso Entwicklungsumgebungen, die die Entwicklung eigener Analyseanwendungen fördern und Operationen auf multidimensionalen Daten liefern. Als eine mögliche Plattform gibt es Fat Clients mit eigenen Speicherund Verarbeitungsmöglichkeiten. Diese Clients führen nahezu die gesamte Verarbeitung ohne Server aus. Eine andere Möglichkeit stellen Thin Clients dar, bei denen fast die gesamte Datenverarbeitung auf dem jeweiligen Server stattfindet. Sie dienen nur der Informationendarstellung. Ferner gibt es noch die aktive Verteilung über Offline- Medien. Hier wird lediglich bei Bedarf eine Verbindung zu einem Data Warehouse hergestellt. Das Repositorium (engl.repository) speichert die Metadaten eines Data Warehouse Systems. Metadaten sind Daten über den Daten. Diese dokumentierenden Daten werden nach ihrem fachlichem Nutzen (für den Endanwender) und den technischen Daten wie z.b. Indizes eingeteilt. Sie liefern z.b. physische Speicherinformationen sowie Informationen über Data-Warehouse-Prozesse, Zugriffsrechte und Schemata. Neben dieser Aufgabe der Informationslieferung dienen sie auch zur Steuerung des Data Warehouse Managers für die verschiedenen Prozesse. Der Metadatenmanager steuert die Metadatenverwaltung. Er stellt 17

30 2 Data Warehousing eine Datenbankanwendung dar, der das Versions- und Konfigurationsmanagement, das Integrations-, die Zugriffs-, die Anfrage- und Navigationsmöglichkeiten der Metadaten anbietet. Ferner liefert er die Schnittstelle für Lese- und Schreibzugriffe auf das Repositorium. Dadurch können Metadaten zwischen den verschiedenen Komponenten erreicht und ausgetauscht werden (Bsp. API). Damit Werkzeuge integriert werden können und das Repositorium steuerbar wird, werden die Metadaten vereinheitlicht. Passende Werkzeuge sind dabei allgemein einsetzbare Metadatenverwaltungssysteme (mit einem einfach zu änderndem Kernschema) und werkzeugspezifischen Metadatenverwaltungskomponenten. Die Praxis zeigt, dass oft ein Austausch zwischen dezentralen Metadaten- Managementsystemen notwendig ist [BG01]. Extraktion Laden Laden Analyse Datenquellen Arbeitsbereich Basisdatenbank Data Warehouse Kontrollfluss Transformation Monitor Data Warehouse Manager Datenfluss Data Warehouse System Metadaten -Manager Repository Abbildung 2.3: Referenzarchitektur eines Data Warehouse Systems Beschreibung einer Referenzarchitektur und Phasen eines Data Warehousing Um die relevanten Daten aus den operativen Systemen in einem Data Warehouse zu integrieren, muss dieses verschiedene Schritte durchlaufen (vgl. Abbildung 2.3 [BG01]). Zunächst werden die Änderungen in den Quellen durch Monitore kontrolliert. Mittels Extraktion werden dann die relevanten Daten aus den operativen Systemen in einen temporären Arbeitsbereich kopiert. Dort finden Datentransformationen (d.h. Integration und Bereinigung) statt. Anschliessend werden die Daten in eine Basisdatenbank 18

31 2.4 Das multidimensionale Datenmodell kopiert, von wo aus sie dann in ein Data Warehouse geladen werden. Diese stellt die Schnittstelle zum Anwender dar und bildet sich durch den jeweiligen Analysezweck. Das Repositorium ist nur mit dem Metadatenmanager verbunden, welcher alle anfallenden Metadaten verwaltet und die restlichen Komponenten mit Metadaten versorgt. Da Unabhängigkeit und zeitliche Stabilität gefragt sind, wird somit auf einen Direktzugriff auf die operativen Daten verzichtet. Stattdessen wird eine separate physische Ablage geschaffen. Die Analyse steht also der Integrationsanforderung gegenüber und lässt mehrere Datenbanken in einer Architektur zu. Die wichtigste Aufgabe eines Data Warehouse ist die laufende Aktualisierung der Daten. Hierbei gibt es zwei Strategien. Beim vollständigen Laden werden Teile der Daten im Data Warehouse gelöscht und neu geladen. Aus Performancegründen ist jedoch die inkrementelle Aktualisierung (engl. inkremental maintenance) effektiver. Hier werden lediglich die Änderungen der operativen Daten in das Data Warehouse eingebracht. Data Warehouses sind meist als Dreischichtenarchitektur realisiert. Auf unterster Ebene befindet sich ein Data Warehouse, das in Verbindung mit dem Repositorium die heterogenen Daten verschiedener Quellen integriert. Es stellt somit die Datenhaltungskomponente dar. Meist liegt ihm ein relationales Datenbanksystem zugrunde. Auf mittlere Ebene befindet sich für die Verarbeitung der OLAP-Server, der für die Analyse multidimensionaler Daten konzipiert worden ist. Er ist meistens als relationales oder multidimensionales OLAP implementiert (vgl. Abschnitt 2.5.2). Die oberste Schicht stellen Front- End Tools dar (Bsp. Analyse-, Anfrage- oder auch Berichtstools). Diese Tools stellen Benutzeranwendungen dar, die insbesondere die Anfragen an den OLAP-Server definieren und Analyseergebnisse angemessen präsentieren sollen (vgl. [HK01]). 2.4 Das multidimensionale Datenmodell Wie im traditionellen Datenbankentwurf werden bei der Erstellung eines Data Warehouses die Phasen der konzeptionellen, logischen und physischen Modellierung unterschieden. Dabei wird zuerst ein konzeptionelles Datenmodell erstellt, um Zusammenhänge ohne Beachtung von Implementierungsdetails zu modellieren. Dieses Kapitel stellt das multidimensionale Datenmodell vor. Nach- 19