Data Warehouses. Alexander Fehr. 23. Dezember 2002

Transkript

1 Data Warehouses Alexander Fehr 23. Dezember 2002

2 Inhaltsverzeichnis 1 Einführung Motivation Definitionen Abgrenzung von operativen Systemen Historie Einsatzbeispiel Architektur Anforderungen des Data Warehousing Referenzarchitektur Data-Warehouse-Manager Datenquellen Monitore Arbeitsbereich Extraktionskomponente Transformationskomponente Ladekomponente Basisdatenbank Data Warehouse Data Marts Analysewerkzeuge Repository Metadaten-Manager Das multidimensionale Datenmodell Motivation Multidimensionaler Datenwürfel Konzeptuelle Modellierung Umsetzung des multidimensionalen Datenmodells Integration Extraktion, Transformation, Laden Anforderungen an Integration Integrationskonflikte Datenkonflikte Materialisierte Sichten 11 6 Fazit 12 Quellen 13 i

3 Abbildungsverzeichnis 1 Referenzarchitektur von Data-Warehouse-Systemen Multidimensionaler Datenwürfel ii

4 1 Einführung 1.1 Motivation Daten und Informationen sind die Grundlage einer erfolgreichen Abwicklung von Geschäftsprozessen. Jedoch kommen Mitarbeiter oft nicht oder nur teilweise an wichtige Informationen heran, obwohl diese im Unternehmen eigentlich vorhanden sind. Es entstehen ständig Produktionsdaten, die Marketingabteilung analysiert Zielgruppen und beim Verkauf fallen Absatzinformationen an. Für diese Daten ergeben sich, bei entsprechender Integration und Verdichtung, neue Verwendungsweisen. Der Zugriff auf den vorhandenen Datenbestand scheitert aber an mehreren Problemen. Für veraltete Systeme gibt es häufig keine komfortablen Abfragewerkzeuge. So dauert es mehrere Tage einen Report zu erstellen. Desweiteren sind die operativen Systeme meistens so stark ausgelastet, dass keine Ressourcen frei sind, um die aufwendigen Reports zu generieren. Ausserdem ist die EDV-Infrastruktur von Unternehen oft sehr heterogen, sowohl in Bezug auf die Betriebssysteme als auch in Bezug auf die Anwendungen. Es fehlen Werkzeuge um Abfragen über diese verteilten Datenquellen zu erstellen. Letztendlich besteht auf Anwenderseite auch ein Mangel an Analysewerkzeugen zu Generierung entscheidungsrelevanter Informationen. Ein Data Warehouse verspricht die Lösung für all diese Probleme zu sein. Als zentrales Datenlager sammelt es in regelmäßigen Abständen Informationen aus den operativen Systemen, konsolidiert sie, filtert Unwichtiges heraus und zeigt mit Hilfe von Analysewerkzeugen Relevantes an. 1.2 Definitionen Eine offizielle Definition für Data Warehouse gibt es nicht. Die am häufigsten zitierte Definition stammt von Bill Inmon, welcher als Begründer des Data Warehouse-Konzepts gilt: A Data Warehouse is a subject-oriented, integrated, non-volatile, and time variant collection of data in support of managements decisions. Ein Data Warehouse hat also vier wichtige Eigenschaften: Fachorientierung (subject-oriented): Der Zweck der Datenbasis ist die Modellierung eines spezifischen Anwendungsziels. Integrierte Datenbasis (integrated): Es werden Daten aus mehreren verschiedenen Datenquellen (intern und extern) verarbeitet. Nicht-flüchtige Datenbasis (non-volatile): Die Datenbasis ist stabil. Einmal eingebrachte Daten werden im Normalfall nicht mehr entfernt oder geändert. Historische Daten (time variant): Die Daten werden über einen längeren Zeitraum gespeichert. Somit ist ein Vergleich der Daten über die Zeit möglich. 1

5 Da diese Definition in bestimmten Fällen nicht ausreichend ist, wird eine neue notwendig. Ein Data Warehouse ist eine physische Datenbank, welche eine integrierte Sicht auf beliebige Daten ermöglicht. Dafür ist eine Integration von Daten und Schemata aus verschiedenen Quellen nötig. Zusätzlich spielt der Analyseaspekt eine wichtige Rolle. Die Daten müssen in einer vom Anwender gewünschten Form bereitgestellt werden. Dazu ist ein adäquater Modellierungsansatz nötig, was mit Hilfe des multidimensionalen Datenmodells erreicht werden kann. Dieses stellt Strukturen bereit, die schon bei der Modellierung einen Analysekontext schaffen. Eine dabei wichtige Anwendung ist das Online Analytical Processing (OLAP), welches eine interaktive Datenanalyse auf der Grundlage des multidimensionalen Datenmodells darstellt. Ein Data Warehouse ist in ein Data-Warehouse-System eingebettet, welches aus allen für den Data-Warehouse-Prozess notwendigen Komponenten besteht. Hierzu zählen auch die Komponenten für die Integration und die Analyse. Ein Data-Warehouse-System ist also kein monolithisches System, sondern ein komplexes System, bei dem etliche Anwendungen kooperieren. Das Data Warehousing bezeichnet den Data-Warehouse-Prozess, welcher alle Schritte von der Datenbeschaffung, über das Speichern bis zur Analyse umfasst. 1.3 Abgrenzung von operativen Systemen Analytische Systeme, wie z. B. Data-Warehouse-Systeme, stehen im Gegensatz zu klassischen transaktionalen Systemen, welche oft auch als Online Transactional Processing (OLTP) bezeichnet werden. Es existieren vielfältige Unterschiede in mehreren Bereichen. Bei transaktionalen Systemen erfolgen oft kurze Lese- und Schreibtransaktionen und Anfragen betreffen meistens nur wenige Datensätze. Dagegen sind die Anfragen bei analyseorientierten Systemen häufig komplex, was zu langen Lesetransaktionen auf vielen Datensätzen führt. Daten im Data Warehouse sind abgeleitete Daten und stammen aus mehreren Quellen. Sie sind konsolidiert, integriert, stabil und teilweise aggregiert und haben ein Volumen, welches bis in den Terrabyte-Bereich gehen kann. Im transaktionalen Betrieb sind die Daten meist zeitaktuell, nicht abgeleitet, autonom, aus einer Datenquelle und dynamisch. Die Datenvolumina liegen im Mega- oder Gigabyte-Bereich. Die Anwender von transaktionalen Systemen sind typischerweise Sachbearbeiter, welche die Daten in den jeweiligen Abteilungen verarbeiten. Bei Data-Warehouse-Systemen reduziert sich die Anzahl der Anwender auf Manager, Controller und Analysten, welche die verdichteten Daten zur Entscheidungsunterstützung brauchen. Es gibt mehrere Gründe für die Trennung operativer und analytischer Systeme. Eine Analyse auf den operativen Quellsystemen hätte eine schlechte Performance zu Folge. Der Zugriff auf die Daten im Warehouse sollte unabhängig von operativen Datenquellen erfolgen, in welchen auch eine langfristige Speicherung der Daten nicht ohne Weiteres möglich ist. Desweiteren sorgt ein Data- Warehouse-System für die Vereinheitlichung des Datenformats und es gewährleistet die Datenqualität. 2

6 1.4 Historie Die Data-Warehouse-Idee gibt es schon seit Längerem: Entscheidungsträgern sollen im Moment des Informationsbedarfs sämtliche benötigte Informationen zu Verfügung stehen. In den 60er Jahren gab es sogenannte Executive Information Systems (EIS), welche der qualitativen Informationsversorgung von Entscheidern dienten. Die Datenbasis bildeten hierbei kleine, verdichtete Extrakte der operativen Datenbestände und die Informationen wurden in Form statischer Berichte aufbereitet. Diese Systeme liefen auf Mainframes. Im Laufe der 80er Jahre entwickleten sich Management Information Systems (MIS), welche immer noch statische Berichtsgeneratoren waren. Allerdings existierten hier schon Client-Server-Architekturen und Graphische Benutzeroberflächen. Es kam zur Einführung von Hierarchieebenen für die Auswertung von Kennzahlen. Fehlende Voraussetzungen, wie schnelle und flächendeckende Kommunikationstechnologien, ausreichende und schnelle Datenspeicher und kostengünstige und leistungsfähige Prozessoren ließen diese Ansätze damals scheitern. Im Jahr 1992 führte Bill Inmon das Data-Warehouse-Konzeptes ein. Es beinhaltete die redundante Haltung von Daten, losgelöst von Quellsystemen und die Beschränkung des Data Warehouses auf den Analysezweck. E. F. Codd definierte 1993 den Begriff OLAP, welches heute eine der wichtigsten Anwendungen von Data-Warehouse-Systemen bildet. Weiteren Einfluss auf die Entwicklung von Data Warehouses hatte die Verbreitung von geschäftsprozessorientierten Transaktionssystemen (z. B. SAP R/3). Hierdurch war in Unternehmen ein großes Volumen an potenziell entscheidungsrelevanten Informationen vorhanden. 1.5 Einsatzbeispiel Ein typisches Beispiel für die betriebswirtschaftliche Anwendung eines Data Warehouses zeigt die Kaufhauskette Wal-Mart ( welche Marktführer im amerikanischen Einzelhandel ist. Wal-Mart betreibt ein unternehmensweites Data Warehouse mit der Größe von etwa 25 TB. Die im Data Warehouse vorhandene Datenbasis hat einen sehr hohen Detaillierungsgrad. Es erfolgt eine tägliche Auswertung der Daten, was zu etwa Anfragen an das Data Warehouse pro Tag führt. Das Wal-Mart-Data-Warehouse hat mehreren Analyseaufgaben: Überprüfung des Warensortiments zur Erkennung von Ladenhütern oder Verkaufsschlagern Standortanalyse zur Einschätzung der Rentabilität von Niederlassungen Untersuchung der Wirksamkeit von Marketing-Aktionen Auswertung von Kundenbefragungen, Reklamationen bezüglich bestimmter Produkte etc. Analyse des Lagerbestandes Warenkorbanalyse mit Hilfe der Kassenbons 3

7 Eine der vielen Anfragen an das Data Warehouse kann zum Beispiel folgende Form aufweisen: Welche Umsätze sind in den Jahren 2000 und 2001 in den Abteilungen Kosmetik, Elektro und Haushaltswaren in den Bundesländern Sachsen-Anhalt und Thüringen angefallen? 2 Architektur Nachdem im letzten Abschnitt eine Einführung in die Thematik des Data Warehousing gegeben wurde, soll nun die Architektur eines Data-Warehouse-Systems vorgestellt werden. Doch zunächst folgt eine Beschreibung der Anforderungen, die für eine solche Architektur relevant sind. 2.1 Anforderungen des Data Warehousing Die Unabhängigkeit zwischen den Datenquellen und den Analysesystemen spielt eine wichtige Rolle. Die integrierten und abgeleiteten Daten sollen dauerhaft bereitgestellt werden und eine Mehrfachverwendbarkeit dieser muss gewährleistet sein. Es soll weiterhin die Möglichkeit der Durchführung beliebiger Auswertungen bestehen und trotzdem auch Unterstützung individueller Sichten vorhanden sein. Ein vorhandenes Data-Warehouse-System muss beliebig erweiterbar sein, wie es zum Beispiel bei der Integration neuer Quellen der Fall ist. Desweiteren sollen die Abläufe im Data-Warehouse-System weitestgehend automatisiert sein und es muss eine Eindeutigkeit über die Datenstrukturen und Prozesse vorherrschen. Die nun folgende Referenzarchitektur erfüllt diese Anforderungen. 2.2 Referenzarchitektur Bei der vorgestellten Architektur (Abbildung 1) handelt es sich um eine Referenzarchitektur. In der Praxis vorhandene Architekturen können durchaus in verschiedenen Punkten abweichen. Wie anhand der Referenzarchitektur sichtbar wird, besteht das Data Warehousing aus mehreren Phasen. Die Monitore überwachen die Quellen auf Änderungen und in bestimmten Abständen werden die relevanten Daten mittels Extraktion in den temporären Arbeitsbereich kopiert. Dort kommt es zu einer Transformation der Daten. Es erfolgt eine Bereinigung und Integration. Die beteiligten Komponenten bilden den Datenbeschaffungsbereich. Anschließend werden die Daten in die integrierte Basisdatenbank kopiert. Danach erfolgt ein Laden der Daten in das Data Warehouse, welches eine Datenbank für Analysezwecke bildet. Auf den nun vorhandenen Daten können verschiedene Analysen durchgeführt werden. Die Einsicht über den gesamten Data-Warehouse-Prozess schafft das Repositorium, welches durch den Metadaten-Manager verwaltet wird. Dieser versorgt auch die anderen Komponenten mit entsprechenden Metadaten. Die Prozesse des Data Warehousing werden durch den Data-Warehouse-Manager gesteuert. Nachfolgend werden nun die einzelnen Komponenten des Data-Warehouse- Systems genauer vorgestellt. 4

8 Abbildung 1: Referenzarchitektur von Data-Warehouse-Systemen 5

9 2.3 Data-Warehouse-Manager Der Data-Warehouse-Manager ist die zentrale Komponente eines Data-Warehouse- Systems. Er ist für die Initiierung, Steuerung und Überwachung der einzelnen Prozesse zuständig. Der Data-Warehouse-Manager initiiert den Datenbeschaffungsprozesses, indem er die Extraktion von Daten aus den Quellen und die Übertragung in den Arbeitsbereich startet. Das erfolgt in regelmäßigen Zeitabständen, bei Änderung einer Quelle oder auf explizites Verlangen des Administrators. Nach dem Auslösen des Ladeprozesses überwacht der Data- Warehouse-Manager die weiteren Schritte, wie Bereinigung oder Integration. Er koordiniert die Reihenfolge der Verarbeitung. Im Fehlerfall werden die Fehler dokumentiert und es werden Wiederanlaufmechanismen gestartet. Der Data- Warehouse-Manager hat Zugriff auf die Metadaten aus dem Repository. Diese dienen der Steuerung des Ablaufs. 2.4 Datenquellen Die Datenquellen sind die Lieferanten der Daten für das Data Warehouse. Sie gehören nicht direkt zum Data Warehouse und können intern oder extern (z. B. Internet) vorhanden sein. Oft sind sie heterogen bezüglich ihrer Struktur, ihrem Inhalt und ihrer Schnittstellen. Die Auswahl der Quellen und somit die Qualität der Daten ist von besonderer Bedeutung. Faktoren für die Auswahl der Datenquellen sind der Zweck des Data Warehouses, die Qualität der Quelldaten, die Verfügbarkeit aber auch der Preis für den Erwerb der Daten. 2.5 Monitore Die Aufgabe der Monitore ist die Entdeckung von Datenmanipulationen in den Datenquellen. Dazu nutzen sie Trigger-basierte, replikationsbasierte, Logbasierte, zeitstempelbasierte oder Snapshot-basierte Strategien. 2.6 Arbeitsbereich Der Arbeitsbereich ist die zentrale Datenhaltungskomponente des Datenbeschaffungsbereichs. Er bildet einen temporären Zwischenspeicher zur Integration. Auf ihm werden die Transformationen direkt ausgeführt. Ein Laden der transformierten Daten in das Data Warehouse bzw. die Basisdatenbank erfolgt erst nach einem erfolgreichem Abschluss der Transformation. Die Vorteile dieser Methode sind, dass keine Beeinflussung der Quellen oder des Data Warehouses stattfindet und fehlerbehaftete Daten nicht übernommen werden. 2.7 Extraktionskomponente Die Extraktionskomponente sorgt für die Übertragung der Daten aus den Quellen in den Arbeitsbereich. Ihre Funktion ist abhängig von der Monitoring- Strategie. Die Übertragung kann periodisch, auf Anfrage, ereignisgesteuert oder sofort stattfinden. Desweiteren besitzt die Extraktionskomponente Mechanismen zur Fortsetzung im Fehlerfall. 6

10 2.8 Transformationskomponente Mit Hilfe der Transformationskomponente erfolgt eine Vorbereitung und Anpassung der Daten für das Laden. Sie sorgt für die Datenintegration, die Datenbereinigung und die Schemaintegration. Es werden alle Daten in ein einheitliches Format bezüglich Datentypen, Datumsangaben, Maßeinheiten und Kodierungen überführt. Es kommt zur Beseitigung von Verunreinigungen, wie fehlerhaften Werten, Redundanzen oder veralteten Werten (Data Cleaning). Desweiteren kann ein Data Scrubbing, welches domänenspezifisches Wissen zum Erkennen von Verunreinigungen nutzt, erfolgen. 2.9 Ladekomponente Die Ladekomponente überträgt die bereinigten und aufbereiteten Daten in die Basisdatenbank bzw. das Data Warehouse. Dabei werden spezielle Ladewerkzeuge, wie zum Beispiel der SQL*Loader von Oracle, genutzt. Es erfolgt eine Historisierung, was bedeutet, dass Änderung in den Quellen die Data- Warehouse-Daten nicht überschreiben dürfen. Stattdessen kommt es zu einem zusätzlichen Abspeichern der Daten Basisdatenbank Die Aufgabe der Basisdatenbank ist es eine integrierte Datenbasis für verschiedene Analysen zu bilden. Die dort enthaltenen Daten sind noch unabhängig von konkreten Analysen. Sie sind also noch nicht aggregiert. Die Basisdatenbank versorgt das Data Warehouse mit bereinigten (z. B. verdichteten) Daten. In der Praxis wird die Basisdatenbank oft weggelassen Data Warehouse Das Data Warehouse ist die Datenbank für Analysezwecke. Sie orientiert sich in ihrer Struktur an den Analysebedürfnissen. Ihre Basis bilden klassische Datenbank- Management-Systeme. Data Warehouses unterstützen den Ladeprozess mit Hilfe von Massenladern, was zu einem schnellen Laden großer Datenmengen führt. Es erfolgt auch eine Unterstützung des Analyseprozesses durch effiziente Anfrageverarbeitung und das multidimensionale Datenmodell Data Marts Data Marts haben die Aufgabe eine inhaltlich beschränkte Sicht auf das Data Warehouse bereitzustellen, was zum Beispiel für bestimmte Abteilungen sinnvoll ist. Gründe für die Nutzung von Data Marts sind Eigenständigkeit, Datenschutz, Lastverteilung oder auch Datenvolumen. Eine Realisierung der Data Marts erfolgt über die Verteilung der Data-Warehouse-Daten Analysewerkzeuge Durch die Analysewerkzeuge ist eine Präsentation der gesammelten Daten mit interaktiven Navigations- und Analysemöglichkeiten möglich. Die Analysen rei- 7

11 chen von einfachen arithmetischen Operationen bis zu komplexen statistischen Untersuchungen. Es erfolgt eine Aufbereitung der Ergebnisse für die Weiterverarbeitung bzw. für die Weitergabe. Die Informationen werden als Tabellen, Grafiken, Text oder Multimedia-Elemente dargestellt. Die Funktionalität der Werkzeige geht von Data Access, wie Reporting Werkzeugen über OLAP bis zu Data Mining Repository Das Repository speichert die Metadaten des Data-Warehouse-Systems. Die Metadaten beinhalten Informationen, die den Aufbau, die Wartung und die Administration des Data-Warehouse-Systems vereinfachen und die Informationsgewinnung ermöglichen. Beispiele für solche Metadaten sind Datenbankschemata, Zugriffsrechte und Prozessinformationen Metadaten-Manager Der Metadaten-Manager steuert die gesamte Metadatenverwaltung und er sorgt für die Versions- und Konfigurationsverwaltung. Es existieren allgemein einsetzbare und werkzeugspezifische Metadaten-Manager. 3 Das multidimensionale Datenmodell 3.1 Motivation Da die Analyse beim Data Warehousing im Mittelpunkt steht, ist ein Datenmodell nötig, welches auf die Unterstützung dieser ausgerichtet ist. Bei der Datenanalyse stehen betriebswirtschaftliche Kennzahlen, wie Erlöse oder Gewinne, im Mittelpunkt. Es ist nötig die Kennzahlen aus unterschiedlichen Perspektiven (zeitlich, regional, produktbezogen) zu betrachten. Diese Perspektiven stellen die sogenannten Dimensionen dar. Es ist auch möglich die Auswertedimensionen zu unterteilen, wie zum Beispiel nach Jahr, Quartal oder Monat. Somit bilden sich Hierarchien. Um diese Anforderungen zu erfüllen wurde das multidimensionale Datenmodell eingeführt. 3.2 Multidimensionaler Datenwürfel Der Multidimensionale Datenwürfel (Abbildung 2) bildet die Grundlage der multidimensionalen Analyse. Die Kanten des Würfels stellen die Dimensionen dar und die einzelnen Zellen die jeweiligen Kennzahlen. Auf dem Datenwürfel sind verschiedene Operationen möglich um jeweils die entsprechenden Analyseergebnisse zu bekommen. Das Beispiel in Abbildung 2 zeigt einen Datenwürfel, welcher die Anzahl von Kraftfahrzeugzulassungen nach dem Zulassungsort, der Automarke und der Farbe ausweist. Der Benutzer kann mit Hilfe dieser Sichtweise im Datenbestand navigieren. Er kann eine Scheibe herauszuschneiden, indem er eine Kante auf bestimmte Werte einschränkt (z. B. gelbe Autos). 8

12 Abbildung 2: Multidimensionaler Datenwürfel 3.3 Konzeptuelle Modellierung Durch das multidimensionale Datenmodell ist es nicht ohne weiteres möglich konventionelle Entwurfstechniken, wie ER oder UML zu nutzen. Diese Techniken haben eine unzureichende Semantik für das multidimensionales Datenmodell. Deshalb war es notwendig spezielle Entwurfstechniken einzuführen. Eine dieser Techniken ist das ME/R-Modell (Multidimensional Entity/Relationship). Dabei handelt es sich um eine Erweiterung des klassischen ER-Modells um zusätzliche Elemente. Eine vollständig neue Entwicklung für die multidimensionale Datenmodellierung ist ADAPT (Application Design for Analytical Processing Technologies). Hierbei erfolgt eine Beschreibung sämtlicher Metadaten- Objekte. Es gibt noch viele weitere Notationen. Zur Zeit ist aber keine Standard verfügbar. 3.4 Umsetzung des multidimensionalen Datenmodells Eine Möglichkeit der Umsetzung des multidimensionalen Datenmodells ist die Umsetzung auf relationale Strukturen. Hierzu ist das relationale OLAP (RO- LAP) verfügbar. Diese Systeme haben den Vorteil, dass sie sehr reif sind, da das Relationenmodell schon lange Zeit existiert und so entsprechende Produkte verfügbar sind. Für die relationale Speicherung der Daten gibt es mehrere Möglichkeiten, wie das Snowflake- oder das Star-Schema oder auch Mischformen aus beiden. Allerdings ist hierbei zu beachten, dass eine Transformation der multidimensionalen Anfragen in die relationale Repräsentation notwendig 9

13 ist. Eine weitere Möglichkeit stellt die Umsetzung des multidimensionalen Datenmodells auf multidimensionale Strukturen dar. Das geschieht mit Hilfe des multidimensionalen OLAP (MOLAP). Der Vorteil dabei ist der Wegfall der Transformation. Bei der multidimensionalen Speicherung werden unterschiedliche Datenstrukturen für den Datenwürfel und die Dimensionen verwendet. Hier gibt es noch keine Standards und somit sind die Systeme und Strukturen häufig proprietär. 4 Integration Einer der wichtigsten Aspekte beim Data Warehousing ist die Integration von Daten aus verschiedenen Quellen. Dieser Abschnitt geht auf die Integration und die dabei anfallenden Probleme ein. 4.1 Extraktion, Transformation, Laden Der sogenannte ETL-Prozess (Extraktion, Transformation, Laden) ist meistens der aufwendigste Teil des Data Warehousing. Es muss eine Vielzahl von Quellen berücksichtigt werden die häufig heterogen sind und insgesamt ein enormes Datenvolumen aufweisen. Die verschiedenen Transformationen sind oft sehr komplex, da Schema- und Instanzintegration durchgeführt werden und es zusätzlich zu einer Datenbereinigung kommt. Hierfür existiert kaum durchgängige Methoden- und Systemunterstützung, jedoch ist eine Vielzahl von Werkzeugen vorhanden. 4.2 Anforderungen an Integration Das Data Warehousing stellt mehrere Anforderungen an die Integration. Alle relevanten Daten aus den operativen Systemen müssen ins Data Warehouse aufgenommen werden können. Es muss eine Überführung unterschiedlicher Darstellungen semantisch gleicher oder zusammengehöriger Daten aus den Quellsystemen in eine gemeinsame Repräsentation erfolgen. Gleiche Informationen aus mehreren Systemen sollen identifiziert werden um dadurch unerwünschte Redundanzen zu beseitigen, welche die Analyseergebnisse verfälschen können. 4.3 Integrationskonflikte Während der Integration kann es zu verschiedenen Konflikten kommen. Diese kann man in mehrere Kategorien einteilen. Es existieren semantische Konflikte, Beschreibungskonflikte, Heterogenitätskonflikte und strukturelle Konflikte. Diese Einteilung entspricht der oft verwendeten Klassifikation mit vier Klassen. Die Konflikte treten in der Regel kombiniert auf. Zusätzlich treten noch Datenkonflikte auf, welche beim Data Warehousing einen besonderen Stellenwert haben. Deshalb soll auch genauer auf sie eingegangen werden. 10

14 4.4 Datenkonflikte Es existieren verschiedene Arten von Datenkonflikten. In den Datenquellen für das Data Warehouse können falsche Daten gespeichert sein, was auf nicht korrekte Einträge oder veraltete Daten zurückzuführen ist. Desweiteren können unterschiedliche Repräsentationen eigentlich äquivalenter Daten in den verschiedenen Quellsystemen vorhanden sein, was sich in verschiedenen Ausdrücken, verschiedene Einheiten und in unterschiedlicher Genauigkeit einzelner Daten äußert. Beispiele für inkorrekte Einträge sind Tippfehler bei der Eingabe oder falsche Einträge aufgrund von Programmierfehlern in einzelnen Anwendungsprogrammen. Solche Konflikte sind im allgemeinen nicht automatisch behebbar. Beispiele für verschiedene Ausdrücke, welche den gleichen Datentyp besitzen, sind Strings für Adressen: Breitestraße Breitestrasse Breitestr. Breite Straße Breite Strasse Breite Str. Breite-Straße Breite-Strasse Breite-Str. Es gibt mehrere Methoden um Datenkonflikte zu beheben. Eine Möglichkeit ist die explizite Werteabbildung, was zum Beispiel bei unterschiedlichen Aufzählungstypen machbar ist, falls ihre Wertebereiche exakt die gleiche Kardinalität besitzen. Weiterhin ist das Einführen von Ähnlichkeitsmaßen möglich, die Tippfehler ausgleichen. Allerdings kann das dazu führen, dass zu viel oder zu wenig als ähnlich erkannt wird. Eine weitere Möglichkeit ist die Bevorzugung der Werte aus einer lokalen Quelle, falls die daten unterschiedliche Aktualität oder unterschiedliche Vertrauenswürdigkeit aufweisen. Zuletzt bietet sich an, spezielles Hintergrundwissen zu verwenden um Datenkonflikte zu beheben. Dafür werden zum Beispiel Konventionen bezüglich verschiedener Schreibweisen oder Homonyme und Synonyme genutzt. Die Nutzung von Ontologien, also das Wissen über Zusammenhänge von Begriffen und Konzepten im jeweiligen Anwendungsgebiet ist auch eine Möglichkeit. 5 Materialisierte Sichten Eine Vielzahl ähnlicher Anfragen erfolgt häufig auf immer denselben Relationen des Data Warehouses. Deshalb ist es in diesen Fällen sinnvoll zusätzliche Redundanzen, durch Materialisierung von Datenbanksichten, einzuführen. Diese materialisierten Sichten reduzieren den Berechnungsaufwand bei wiederkehrenden Anfrageteilen und somit auch die Anfrageausführungszeit. Das System erkennt dann automatisch Anfrageteile, deren Ergebnisse durch materialisierte Sichten bereits zur Verfügung stehen. Bei der Existenz von materialisierten Sichten muss die transparente Nutzung dieser gewährleistet sein. Die Formulierung von Anfragen darf nicht beeinflusst sein. Die Auswahl materialisierter Sichten erfordert eine Abwägung zwischen dem Speicherbedarf für redundant gehaltene Daten und der zu erwartenden Reduktion von Antwortzeiten. Außerdem muss die Wahl zwischen statischer und 11

15 dynamische Auswahl materialisierter Sichten getroffen werden. Bei statischer Auswahl werden die Sichten zu einer bestimmten Zeit festgelegt und bleiben dann für eine längere Zeit erhalten. Dagegen werden bei der dynamischen Auswahl aktuelle Anfrageergebnisse materialisiert und bis zu ihrer Verdrängung durch neue in einen Cache eingelagert. Durch die Materialisierung ist ein zusätzlicher Verwaltungsaufwand nötig, da die Sichten aktualisiert werden müssen. Hierfür gibt es zwei Möglichkeiten. Erstere besteht in der Rematerialisierung, also der vollständigen Neuberechnung der Sichten, was sehr ineffizient ist und deshalb kaum genutzt wird. Eine bessere Möglichkeit bildet die inkrementelle Aktualisierung. Hierbei werden nur die veränderten Teile der Sicht neu berechnet und anschließend inkrementell integriert. Für die inkrementelle Aktualisierung gibt es mehrere Algorithmen, die jeweils unterschiedliche Mächtigkeit besitzen. Nicht alle Algorithmen unterstützen beispielsweise Joins oder Aggregationen. Beispiele für solche Algorithmen sind der Counting-Algorithmus, Outer-Join-Sichten oder der DRed- Algorithmus. 6 Fazit Der Hype der letzten Jahre um Data Warehouses ist vorbei. Viele groß angelegte Data-Warehouse-Projekte in Unternehmen sind am Anfang gescheitert. Das ist vor allem auf mangelnde Planung einer solch komplexen Infrastruktur, wie es Data-Warehouse-Systeme sind, zurückzuführen. Data-Warehouse-Systeme erfordern auch nach dem Aufbau fortwährende Pflege und Entwicklung. Trotzalldem haben inzwischen mehrere große Unternehmen ein Data-Warehouse- System, welches ihnen in der heutigen Marktsituation durchaus einen Wettbewerbsvorteil verschaft. Mittlerweile werden auch in einigen mittleren und kleineren Unternehmen Data Warehouses aufgebaut. Auch wenn im Gebiet der Data-Warehouse-Systeme bereits ein solides Fundament bereitgestellt ist, so ist dies in Bezug auf neue Anwendungen und neue Basistechnologien nur als erster Schritt zu sehen. In der nächsten Zeit steht die systematische Aufarbeitung verfügbarer Lösungen, sowohl im kommerziellen als auch im akademischen Bereich, an. 12

16 Quellen A. Bauer, H. Günzel. Data-Warehouse-Systeme. dpunkt.verlag, W. Lehner. Datenbanktechnologie für Data-Warehouse-Systeme. dpunkt.verlag, K.-U. Sattler, S. Conrad. Folien zur Vorlesung Data-Warehouse-Technologien. Universität Magdeburg, WS 00/01. J. Bager, J. Becker, R. Munz. Zentrallager. c t 3/97, S U. Chaudhuri and U. Dayal. An Overview of Data Warehousing and OLAP Technology. SIGMOD Record, 26 (1): 65-74, J. Widom. Research Problems in Data Warehousing. 4th International Conference on Information and Knowledge Management, Baltimore, Maryland, J. Hammer, H. Garcia-Molina, J. Widom, W. Labio and Y. Zhuge. The Stanford Data Warehousing Project. IEEE Quarterly Bulletin on Data Engineering; Special Issue on Materialized Views and Data Warehousing, 18 (2): 41-48,