Architektur von Datawarehouse – Systemen - Friedrich
Werbung
Architektur von Datawarehouse – Systemen Rico Landefeld Ausarbeitung im Rahmen des Blockseminars „Data Warehousing“ Lehrstuhl für Datenbanken und Informationssysteme Institut für Informatik Friedrich Schiller Universität Jena Lehrstuhl für Datenbanken und Informationssysteme Seite 1 von 18 Architektur von Datawarehouse – Systemen _____________ 1 1 Refererenzarchitektur ___________________________________________________ 4 1.1 Motivation, Begriffe ________________________________________________ 4 1.2 Anforderungen ____________________________________________________ 4 1.2.1 Verfügbarkeit __________________________________________________ 4 1.2.2 Belastbarkeit ___________________________________________________ 4 1.2.3 Unabhängigkeit _________________________________________________ 4 1.2.4 Persistenz ______________________________________________________ 5 1.2.5 Flexibilität _____________________________________________________ 5 1.2.6 Skalierbarkeit __________________________________________________ 5 1.2.7 Individuelle Sichten für Anwender __________________________________ 5 1.2.8 Effizienz ______________________________________________________ 5 1.3 2 Aufbau ___________________________________________________________ 5 Komponenten __________________________________________________________ 6 2.1 Datawarehouse – Manager ___________________________________________ 6 2.2 Datenquelle _______________________________________________________ 7 2.3 Monitor ___________________________________________________________ 7 2.3.1 Realisierung ____________________________________________________ 8 2.4 Extraktionskomponente _____________________________________________ 9 2.5 Arbeitsbereich _____________________________________________________ 9 2.6 Transformationskomponente ________________________________________ 10 2.6.1 Datenintegration _______________________________________________ 10 2.6.1.1 Vereinheitlichung on Datensätzen________________________________ 10 2.6.1.2 Zusammenführung von Datensätzen ______________________________ 10 2.6.1.3 Schlüsselbehandlung __________________________________________ 11 2.6.1.4 Aggregierung und (De)normalisierung ____________________________ 11 2.6.2 Schemaintegration ______________________________________________ 11 2.6.3 Datenbereinigung ______________________________________________ 11 2.7 Ladekomponente __________________________________________________ 11 2.8 Basisdatenbank ___________________________________________________ 12 2.9 Datawarehouse ___________________________________________________ 12 2.9.1 Unabhängige Data Marts _________________________________________ 13 2.9.2 Abhängige Data Marts __________________________________________ 13 2.10 Analyse __________________________________________________________ 14 2.10.1 Data Access ___________________________________________________ 14 2.10.2 OLAP _______________________________________________________ 14 2.10.3 Data Mining___________________________________________________ 14 3 2.11 Repositorium _____________________________________________________ 14 2.12 Metadaten – Manager ______________________________________________ 15 Datenqualität und Cleansing _____________________________________________ 15 Seite 2 von 18 4 3.1 Datenqualität _____________________________________________________ 15 3.2 Cleansing ________________________________________________________ 16 Zusammenfassung _____________________________________________________ 17 Seite 3 von 18 1 Refererenzarchitektur 1.1 Motivation, Begriffe „Mit Architektur kann die strukturell organisierte Beziehung von materiellen wie ideellen Teilen oder Modulen beschrieben werden“[1] 1. Ein Softwaresystem besteht aus Modulen bzw. Komponenten, die über Schnittstellen kommunizieren und innerhalb von Prozessen Aufgaben erledigen. Deshalb ist eine Software – Architektur „eine strukturierte oder hierarchische Anordnung der Systemkomponenten sowie Beschreibung ihrer Komponenten.“ [2] Eine Architektur reduziert durch die Zerlegung in Komponenten Komplexität, abstrahiert immer von der konkreten Umsetzung. Außerdem soll die Architektur eines Softwaresystems Anforderungen wie zum Beispiel Wartbarkeit, Modifizierbarkeit, Sicherheit und Performance, erfüllen und wird anhand dieser Anforderungen bewertet. Eine Referenzarchitektur ist eine idealtypische Architektur für eine Klasse von Systemen. Sie dient der Veranschaulichung, dem Vergleich und der Beschreibung von Systemen und ihren Architekturen. Im folgenden Text soll eine Referenzarchitektur für Datawarehouse – Systeme[3] vorgestellt werden. Diese Referenzarchitektur ermöglicht den Vergleich von Datawarehouse - Systemen und Werkzeugen, dient der Veranschaulichung von konkreten Stärken und Schwächen, oder als Ausgangspunkt einer Implementierung. Der Fokus liegt im Folgendem auf dem Beschreibungsaspekt. Mit Hilfe einer Referenzarchitektur können Begriffe, wie „Datawarehouse“ und „Datawarehousing“, visualisiert und diskutiert werden. Im nächsten Abschnitt soll auf die speziellen Anforderungen des Datawarehousings eingegangen werden. 1.2 Anforderungen In erster Linie muss sich die Architektur nach dem Hauptzweck eines Datawarehouse Systems ausrichten, der Analyse von Daten. Um diese Aufgabe optimal zu erledigen, muss eine Datawarehouse Architektur folgenden Anforderungen genügen. 1.2.1 Verfügbarkeit Ein Datawarehouse - System muss für Anfragen des Anwenders und für evtl. Datenaktualisierungen verfügbar sein. Dabei ist die Wichtigkeit dieser Anforderung je nach Anwendungsgebiet unterschiedlich einzustufen. Intuitiv ist man eher geneigt die Verfügbarkeit weniger wichtig einzuschätzen als bei OLTP Systemen. Bei kritischen Einsatzgebieten wie DSS (Decision Support System) ist Verfügbarkeit jedoch ein wesentlicher Aspekt. 1.2.2 Belastbarkeit Die zum Teil sehr großen Datenmengen die in einem Datawarehouse - System bewegt werden, sowie die unter Umständen komplexen Anfragen der Anwender führen zu einer hohen Belastung. Das System muss robust genug sein um dieser Belastung gewachsen zu sein. 1.2.3 Unabhängigkeit Die Daten in einem Datawarehouse - System werden durch Datenquellen unterschiedlichster Natur bereitgestellt. Auf der einen Seite sollten laufende Datenänderungen in den Datenquellen das Datawarehouse - System nicht beeinträchtigen, auf der anderen Seite müssen Datentransformationen und Anfragen im Datawarehouse - System unabhängig vom Quellsystem ablaufen. Seite 4 von 18 1.2.4 Persistenz Die Daten in einem Datawarehouse - System werden aus verschiedenen Datenquellen integriert und aggregiert. Diese „veredelten“ Daten müssen für Benutzeranfragen dauerhaft im System gespeichert werden. 1.2.5 Flexibilität Es muss die Möglichkeit bestehen auf den integrierten und aggregierten Daten beliebige Auswertungen beliebig oft auszuführen. 1.2.6 Skalierbarkeit Ein Datawarehouse - System muss einfach erweiterbar sein. Neue Datenquellen und neue Anfragestrukturen müssen integrierbar sein ohne bestehende Ablagestrukturen grundlegend ändern zu müssen. Darüber hinaus muss eine einfache Anpassung an gestiegene Auslastung durch Nutzeranfragen oder gestiegene Datenvolumen möglich sein. 1.2.7 Individuelle Sichten für Anwender Unterschiedliche Nutzerkreise haben unterschiedliche Anforderungen an den Inhalt, Struktur und Dauerhaftigkeit von Datenbeständen. Der Inhaltsaspekt kann zum Beispiel unterschiedliche Granularitäten von Zeit und Lokalität umfassen aber auch die Sichtbarkeit von bestimmten Teilen des Datenbestandes. So möchten beispielsweise Mitarbeiter der Marketingabteilung wissen ob sich ihre neue Marketingstrategie in höheren Absatzzahlen im letzten Monat niederschlägt und Mitarbeiter der Finanzabteilung möchten wissen wie viel Umsatz im letzten Quartal erzielt wurde. Das System muss dies berücksichtigen und den einzelnen Benutzergruppen individuelle Sichten zur Verfügung stellen. 1.2.8 Effizienz Alle Arbeitschritte, Prozesse und Abläufe wie Monitoring, Extraktion, Laden und Transformation der Daten sollen weitgehend automatisiert erfolgen. 1.3 Aufbau In diesem Abschnitt soll eine Referenzarchitektur skizziert werden, die sich an den oben behandelten Anforderungen ausrichtet. Die Referenzarchitektur gliedert sich in Komponenten, die durch Kontrollund Datenflüsse verbunden sind. Die Komponenten werde in Operanden und Operatoren unterteilt. Operanden sind die verschiedenen Datenspeicher, Operatoren sind die Komponenten die Daten der Operanden verarbeiten. Die Daten wandern im System von unten, den Datenquellen, bis nach oben, zum Datawarehouse. Auf dem Weg von unten nach oben werden die Daten integriert, bereinigt und aggregiert. Der hellgrau schraffierte Bereich markiert das gesamte Datawarehouse - System, die Datenquellen gehören somit nicht unmittelbar dazu. Abbildung 1: Referenzarchitektur Seite 5 von 18 Die Datenflüsse werden in Primär- und Metadatenflüsse unterteilt. Primärdaten gehen direkt in die Auswertung ein, Metadaten hingegen sind Beschreibungsdaten die insbesondere zur Kontrolle und Steuerung der Datawarehousing - Prozesse benutzt werden. Die Daten werden aus den Datenquellen extrahiert und in den Arbeitsbereich kopiert. Der Monitor unterstützt diesen Prozess indem er Änderungen in den Datenquellen an den Datawarehouse Manager, die zentrale Steuerungskomponente, weitermeldet. Im Arbeitsbereich werden die Daten temporär zwischengespeichert und für die Weiterverarbeitung transformiert. Die beteiligten Komponenten bilden zusammen den Datenbeschaffungsbereich. Die Trennung zwischen einer Basisdatenbank und einer Datawarehouse - Datenbank ist hauptsächlich in der Forderung nach Flexibilität begründet. Analysewerkzeuge benötigen aufbereitete Daten, die speziell auf Anwenderanfragen zugeschnitten sind. Das bedeutet, dass ein Datenspeicher für Analysewerkzeuge ein anwendungsspezifisches Datenmodell benötigt. Soll diese Datenbasis den Anfragen verschiedener Nutzerkreise genügen, kann es zu nicht lösbaren Konflikten bei der Datenmodellierung kommen. Wird diese Datenbasis wiederum aufgespaltet um für jeden Anwenderkreis eine eigene Datenbasis zu schaffen, erschwert dies eine globale Analyse. Ich werde auf diesen Punkt bei der Diskussion von Data Marts tiefer eingehen. Aus den oben genannten Gründen führt man die Basisdatenbank als eine Anwendungsunabhängige, konsolidierte und integrierte Datenbasis ein. Im Gegensatz dazu gibt ein Datawarehouse eine einzelne, anwendungsbezogene Sicht wieder. Das Datenmodell der Datawarehouse - Datenbank ist speziell für bestimmte Anfragen konzipiert. Diese Anfragen werden von der Analysekomponente ausgeführt und deren Ergebnisse als Text, Tabellen oder Grafik präsentiert. Die Analysekomponente steht als Stellvertreter für alle Arten von Analysewerkzeugen, die auf den Daten des Datawarehouses arbeiten. Alle Prozesse des Datawarehouse - Systems werden von einer zentralen Komponente gesteuert, dem Datawarehouse - Manager. Der Datawarehouse - Manager initiiert, kontrolliert und steuert diese Prozesse und sorgt bei Systemausfällen für das richtige Fehlermanagement. Er benutzt zur Steuerung Metadaten die im Repositorium gehalten und vom Metadatenmanager verwaltet werden. 2 Komponenten In diesem Abschnitt werden die einzelnen Komponenten der Referenzarchitektur näher beschrieben. 2.1 Datawarehouse – Manager Der Datawarehouse Manager dient der zentralen Steuerung der Komponenten, er initiiert, steuert und kontrolliert alle Datawarehousing Prozesse. Als eine zentrale Aufgabe muss der Datawarehouse Manager den Datenbeschaffungsprozess koordinieren. Die Wahl der Zeitpunkte wann die Datenbeschaffung angestoßen wird, ist auf der einen Seite abhängig von der Art und Belastung der Datenquellen, auf der anderen Seite von der Bedeutung bzw. Wichtigkeit der Daten. Die Zeitpunkte können in einem festen Intervall liegen, die Datenbeschaffung wird regelmäßig gestartet. Bei sensiblen Daten kann aber auch die Anzahl von Änderungen oder die Überschreitung oder Unterschreitung von Schwellwerten in den Datenquellen als Auslöser für die Datenbeschaffung dienen. Als dritte Möglichkeit bleibt der Anstoß der Datenbeschaffung auf Anfrage eines Anwenders. Ist die Datenbeschaffung gestartet, überwacht der Datawarehouse Manager die korrekte Prozessausführung. Bei Datenabhängigkeiten zwischen Datenquellen ist die Reihenfolge der Ausführung wesentlich. Liegen keine Datenabhängigkeiten vor, können performanzsteigernde Prozesse parallel ausgeführt werden, ansonsten werden sie sequentiell nacheinander ausgeführt. Seite 6 von 18 Naturgemäß werden bei der Datenbeschaffung große Datenmengen bewegt. Kommt es während der Datenbeschaffung zu einem Ausfall des Systems oder einer Komponente, ist es sinnvoll bei einem Neustart des Systems die Datenbeschaffung nicht von Anfang an zu starten, sondern vom Zeitpunkt des Ausfalls an. Der Datawarehouse - Manager muss für diesen Fall Wiederanlaufmechanismen zu Verfügung stellen, den Fehler dokumentieren und gegebenenfalls einen Administrator benachrichtigen. Für die Arbeit des Datawarehouse - Managers sind Beschreibungsdaten (Metadaten) unerlässlich. So kann er anhand von Metadaten Abhängigkeiten zwischen Datenquellen entdecken, die Extraktion je nach Charakteristik der Datenquelle parametrisieren, die Transformation, Integration und Bereinigung der Daten steuern und vieles mehr. Dabei dient der Metadatenmanager als Schnittstelle zum Repositorium. 2.2 Datenquelle Die Datenquelle ist kein direkter Bestandteil eines Datawarehouse - Systems und steht als Vertreter für ein oder mehrere zu integrierende, meist heterogene Datenquellen. Datenquellen sind der Ausgangspunkt des Datenflusses in einem Datawarehouse - Systems. Eine Datenquelle kann ein klassisches Datenbankmanagementsystem sein aber auch ein Altsystem (legacy system) welches die Daten in einem properitären Format speichert und unter Umständen eine eigene Schnittstelle zum Zugriff anbietet. Datenquellen müssen auch nicht innerhalb der Organisation angesiedelt sein, die diese in ein Datawarehouse - System integrieren möchte. Eine Auswahl der Datenquellen richtet sich in erster Linie nach dem Zweck des Datawarehouse - Systems. Über die Anbindung einer Datenquelle entscheidet daneben die Qualität ihrer Daten und ihre technische und organisatorische Verfügbarkeit. Kann zu der Datenquelle keine Netzwerkverbindung aufgebaut werden oder ist die Geschwindigkeit der Verbindung zu gering, dann ist die Anbindung schwierig bzw. unmöglich. Als organisatorische Faktoren spielen insbesondere die rechtlichen Bedingungen eine wichtige Rolle. Bei Personendaten kann der Datenschutz eine Benutzung unterbinden. Es ist aber auch denkbar, dass der Besitzer der Daten kein Interesse hat diese zur Auswertung zur Verfügung zu stellen. Als letztes Auswahlkriterium sind die Kosten der Daten anzuführen. Kosten spielen nicht nur bei externen Datenquellen, wie z.B. kommerziellen Datendiensten, eine Rolle sondern können auch bei betriebsinternen Datenquellen von großer Bedeutung sein. Die technische Natur einer Datenquelle ist für das Monitoring besonders wichtig. 2.3 Monitor Die Monitorkomponente hat die Aufgabe Datenänderungen in den Datenquellen zu beobachten und an den Datawarehouse - Manager zu propagieren. Die Änderungsinformationen werden verwendet um die Extraktion der geänderten Daten zu steuern und die Basisdatenbank und das Datawarehouse aktuell zu halten. Die Änderungsinformationen können entweder alle Angaben enthalten welche Datensätze sich geändert haben oder lediglich die Information, dass sich Datensätze geändert haben. Im ersten Fall übergibt der Monitor eine sogenannte Deltadatei, im letzteren Fall muss die Extraktionskomponente die Änderungen selber aufdecken können. Die Propagierung der Datenänderungen verläuft aus Effizienzgründen inkrementell, nur Änderungen werden übernommen. Wie schon bei der Diskussion der Datenquellen erwähnt wurde, ist die Umsetzung eines Monitors abhängig vom Typ der zu beobachtenden Datenquelle. Das Spektrum der Möglichkeiten reicht vom internen Monitoring, das bedeutet die Datenquelle bringt ausreichend Monitoringtechniken von Haus aus mit, bis zum externen Monitoring, das heißt die Datenquelle muss mit einem speziellen Programm nach Datenänderungen überwacht werden. Ist eine Historisierung der Daten im Datawarehouse notwendig, müssen die Datenänderungen abhängig von der Granularität der Historisierung übernommen werden. Ist das Seite 7 von 18 Überwachungsintervall dieser Granularität angepasst, genügt es nur die Nettoänderungen zu übernehmen. Ist dies nicht der Fall, müssen alle Änderungen eines Datensatzes einzeln übernommen werden. Ein weiterer Implementierungsaspekt ist die Frage ob der Monitor regelmäßig die Datenquelle auf Änderungen kontrolliert (Polling) oder ob der Monitor durch die Datenquelle bei Änderungen benachrichtigt wird. 2.3.1 Realisierung Bietet die Datenquelle Mechanismen um Datenänderungen direkt aufzudecken, spricht man von systemgesteuerten Mechanismen. Fehlen solche Mechanismen, muss die Datenquelle bzw. Anwendungen, die Daten ändern, angepasst werden, damit diese Änderungen nach außen sichtbar werden. In diesem Falle spricht man von anwendungsgesteuerten Mechanismen. Die systemgesteuerten Mechanismen werden von den meisten modernen Datenbankmanagementsystemen unterstützt und umfassen aktive Mechanismen, Replikationsmechanismen und protokollbasierte Mechanismen. Unter aktiven Mechanismen fallen insbesondere Datenbanktrigger die nach dem ECA (Event, Condition, Action) Prinzip arbeiten. Bei jeder Änderung eines Datensatzes wird ein Trigger ausgeführt, der den eingefügten, geänderten oder gelöschten Datensatz in eine spezielle Tabelle schreibt. Bei jeder Extraktion werden diese Änderungstabellen gelesen und anschließend geleert, damit Änderungen nicht doppelt übernommen werden. Beim Einsatz von Replikationsmechanismen dagegen können die geänderten Daten direkt in eine eigene Datenbank geschrieben werden. Die Realisierung ist stark abhängig vom eingesetzten System, es werden jedoch zwei Ansätze unterschieden: die Snapshotbasierte Replikation und die Datenreplikation. Ein Snapshot ist dabei eine Art Sicht auf Daten aus ein oder mehreren Tabellen zu einem bestimmten Zeitpunkt. Snapshot - Daten sind nur lesbar, nicht änderbar. Die Aktualisierung eines Snapshots kann inkrementell erfolgen oder der Snapshot wird komplett neu generiert. Die inkrementelle Aktualisierung ist für das Monitoring besonders interessant, da hier das DBMS die Änderungen eines Snapshots in einem Snapshot – Log festhält. Für das Monitoring müssen somit für alle Tabellen, die relevante Daten enthalten, Snapshots und Snapshot – Logs definiert werden. Aus den Snapshots und den Logs kann eine Deltadatei für die Extraktion erstellt werden. Beherrscht die Datenquelle Datenreplikation, so kann man alle relevanten Tabellen als Quelltabellen auf Zieltabellen replizieren lassen. Wenn die Aktualisierung der Zieltabellen inkrementell erfolgt und die Änderungen entweder durch spezielle Deltatabellen oder Logs auch nachvollziehbar sind, kann die Datenreplikation für das Monitoring eingesetzt werden. Besonders interessant sind hier Lösungen, die Zieltabellen auf anderen Systemen unterstützen. Damit kann die Belastung des Quellsystems durch das Monitoring stark reduziert werden. Werden keine aktiven Mechanismen oder Replikationsmechanismen durch die Datenquelle unterstützt oder ist deren Einsatz im Sinne der Belastung zu teuer, können Datenänderungen anhand des Transaktionslogs aufgespürt werden. Dies ist sicherlich eine aufwendig umzusetzende Technik. Damit diese Technik überhaupt realisierbar ist, muss das Format des Logs bekannt sein, es muss möglich sein von außen auf das Log zuzugreifen und es muss alle nötigen Informationen enthalten. Das Log muss zuerst kopiert werden und dann nach allen Modifikationen der relevanten Daten untersucht werden. Es kann sehr groß sein, der Kopieraufwand ist nicht zu unterschätzen. Dabei müssen die abgebrochenen Transaktionen und die durchgeführten Transaktionen unterscheidbar sein. Sind die systemgestützten Mechanismen nicht anwendbar, müssen die Anwendungen, die Daten einer Datenquelle ändern, so angepasst werden, dass diese Änderungen nach außen Seite 8 von 18 sichtbar werden. Solche Anpassungen können für Altsysteme sehr aufwendig werden, da Altsysteme manchmal schlecht dokumentiert und strukturiert sind und schlimmstenfalls auch in veralteten Programmiersprachen implementiert wurden. Wenn eine Anpassung möglich ist, können Zeitstempel eingeführt werden um Änderungen an Datensätzen zu markieren. Diese Zeitstempel werden wiederum zur Selektion von geänderten Datensätzen genutzt. Beim Löschen von Datensätzen genügt allerdings kein Zeitstempel. Hier ist es erforderlich das die gelöschten Datensätze im System verbleiben, bis die Löschung vom Monitor registriert worden ist. Die letzte Möglichkeit, Änderungen in einer Datenquelle zu entdecken, besteht im direkten Dateivergleich. Dabei wird die komplette Datenquelle zu bestimmten Zeitpunkten in eine (Snapshot-) Datei geschrieben. Diese Dateien werden miteinander verglichen um Datenänderungen aufzuspüren. Von allen angesprochenen Techniken ist dies sicherlich die Aufwendigste, in vielen Fällen aber die einzig Anwendbare. 2.4 Extraktionskomponente Die Extraktionskomponente überträgt die Daten von den Datenquellen in den Arbeitsbereich. Die Realisierung der Extraktionskomponente hängt stark von der Datenquelle und dem Monitor ab. Im Falle, dass der Monitor nur einen Hinweise liefert, dass in einer Datenquelle Änderungen vorliegen, muss die Extraktionskomponente selbst herausfinden welche Daten sich geändert haben im anderen Falle liegen alle Informationen zu den Datenänderungen vor. Zu welchem Zeitpunkt die Extraktion stattfindet, hängt stark von der Semantik der Daten ab. Es wird zwischen periodischer, anfragegesteuerter, ereignisgesteuerter und sofortiger Extraktion unterschieden. Bei der periodischen Extraktion werden die Daten in bestimmten Intervallen extrahiert. Die Länge der Intervalle hängt von der Dynamik der Daten ab und wie aktuell die Daten sein müssen. Der Anstoß der Extraktion erfolgt automatisch. Im Gegensatz dazu wird bei der anfragegesteuerten Extraktion der Prozess von einer Nutzeranfrage ausgelöst. Dieses Vorgehen wird wohl nur in wenigen Fällen Anwendung finden, da eine Datenextraktion normalerweise die Datenquelle und die Netzwerkinfrastruktur stark belastet. Bei sensiblen Daten kann es sinnvoll sein, Datenänderungen direkt an das Datawarehouse System zu propagieren. Da hier ein Ereignis die Extraktion auslöst, spricht man auch von ereignisgesteuerter Extraktion. Das Ereignis kann zudem mit einer Bedingung verknüpft sein. Die Über- oder Unterschreitung von Schwellwerten oder eine bestimmte Anzahl von Änderungen sind Beispiele für solche Bedingungen. Welches Vorgehen gewählt wird, hängt neben der Semantik der Daten auch von weiteren organisatorischen und technischen Voraussetzungen ab. Bei der Extraktion fallen üblicherweise große Datenmengen an. Es ist deshalb sinnvoll Komprimierung einzusetzen um das Datenvolumen zu verkleinern und den Durchsatz zu erhöhen. Wird die Extraktion durch einen Systemabsturz oder ähnliches unterbrochen, ermöglichen Wiederanlaufmechanismen die Wiederaufnahme der Extraktion. Technisch wird die Extraktion durch Netzwerke und Datenbankschnittstellen unterstützt. Aus Effizienzgründen wird oftmals auch zu sogenannten Bulk – Extraktionen gegriffen. Diese Technik wird durch viele DBMS unterstützt. Ein Programm liest, oftmals unter Umgehung des DBMS, die Daten direkt aus dem Datenbankdevice (Datei oder eigene Partition) und schreibt diese Daten in eine Datei. Diese Technologie ist allerdings properitär und in einer heterogenen Systemlandschaft oft nicht einsetzbar. Am Ende der Extraktion stehen die Daten zur weiteren Verarbeitung im Arbeitsbereich zur Verfügung. 2.5 Arbeitsbereich Der Arbeitsbereich fungiert als zentrale Datenhaltungskomponente des Datenbeschaffungsbereiches. Die Extraktoren kopieren geänderte Daten aus den Datenquellen in den Arbeitsbereich, damit diese Daten hier aufbereitet werden können, bevor sie weiter in die Basisdatenbank geladen werden. Dadurch wird der Transformationsprozess entkoppelt Seite 9 von 18 von den Datenquellen und der Basisdatenbank. Eine Beeinträchtigung der Basisdatenbank oder der Datenquellen wird ausgeschlossen. Wenn die Transformation abgeschlossen ist und die Daten in die Basisdatenbank geladen wurden, können die Daten im Arbeitsbereich wieder gelöscht werden. Der Arbeitsbereich ist ein rein temporärer Speicher. 2.6 Transformationskomponente Die Daten im Arbeitsbereich stammen aus unterschiedlichen, heterogenen Datenquellen. Sie haben meist ein unterschiedliches Datenformat und unterschiedliche Schemata. Bevor diese Daten in die Basisdatenbank eingebracht werden können, müssen sie vereinheitlicht und bereinigt werden. 2.6.1 Datenintegration Die Homogenisierung heterogener Datenquellen erfordert auf der Datenebene Maßnahmen zur Vereinheitlichung, Zusammenführung und Schlüsselbehandlung von Datensätzen. 2.6.1.1 Vereinheitlichung on Datensätzen Um die Daten aus heterogenen Quellen vergleichbar zu machen müssen sie in ein einheitliches Format überführt werden. Dazu zählt man die Anpassung von Datentypen, Konvertierung von Kodierungen, Vereinheitlichung von Zeichenketten, Vereinheitlichung von Datumsangaben, Umrechnung von Maßeinheiten und die Kombination und Separierung von Attributwerten. Bei der Anpassung von Datentypen muss der Datentyp eines Quellattributes in den Datentyp des Zielattributes konvertiert werden. Dies ist zum Beispiel der Fall wenn im Quellattribut Datumswerte als String stehen, im Zielattribut jedoch ein Datumsdatentyp benutzt wird. Datumsangaben müssen vereinheitlicht werden da Datumsformate länderabhängig und Datumswerte zeitzonenabhängig sind. Wenn Datumsangaben in den Quellsystemen unterschiedlich abgelegt wurden, müssen diese in ein einheitliches Format überführt werden. Moderne Datenbanksysteme unterscheiden zwischen interner und externer Repräsentation von Daten. Die interne Repräsentation ist statisch, die externe ist frei wählbar. Zur Anpassung der Datumsangaben muss deshalb nur die externe Darstellung angepasst werden. Bei der Vereinheitlichung von Zeichenketten werden beispielsweise Umlaute oder andere sprachspezifische Sonderzeichen durch eine einheitliche Schreibweise ersetzt, Leerzeichen entfernt oder ganze Begriffe ersetzt um ein einheitliches Fachvokabular einzuführen. Dieses Fachvokabular sollte im zentralen Repositorium gespeichert werden. Als weitere Maßnahme der Datenintegration ist die Anpassung unterschiedlicher Modellierungen von Attributen zu nennen. In unterschiedlichen Datenmodellen werden Attribute wie zum Beispiel Name und Vorname einer Person oder Strasse und Hausnummer entweder in einem Attribut zusammengefasst oder als einzelne Attribute modelliert. Diese Modellierungsunterschiede müssen aufgehoben werden. Diese Maßnahme zählt eher in die Schnittmenge aus Daten- und Schemaintegration. 2.6.1.2 Zusammenführung von Datensätzen Unterschiedliche Datenbanken können Datensätze enthalten die ein und dieselbe reale Entität beschreiben. Es müssen zusammengehörige Datensätze erkannt und zusammengefasst werden. Für dieses Problem können charakteristische Attributwerte herangezogen werden, zum Beispiel Artikelbezeichnungen oder ähnliches. Schlüssel können für die Zuordnung nicht verwendet werden, da sie nur lokale Gültigkeit besitzen. Einen allgemeingültigen Weg bieten sogenannte probalistische Record-Linkage Systeme. Dabei werden statistische Verfahren benutzt um ein Gewicht für die Ähnlichkeit zwischen Datensätzen zu berechnen. Liegt das Gewicht oberhalb eines definierten Schwellwertes können zwei Datensätze zugeordnet werden. Häufig auftretende Probleme bei der Zuordnung von Datensätze ist das falsche Zuordnen, sogenannte Homonymfehler und das Nichtzuordnen von Datensätzen, auch Synonymfehler genannt. Seite 10 von 18 2.6.1.3 Schlüsselbehandlung Die Integration verschiedener Datenquellen beinhaltet wie im letzten Abschnitt schon angerissen wurde, die Übernahme und Zusammenführung von Datensätzen. Die Schüssel aus den Datenquellen können hier nicht übernommen werden da sie in den meisten Fällen nicht global eindeutig sind. Deshalb werden die Schlüssel der Quelldatensätze auf künstliche Schlüssel abgebildet, sogenannten Surrogaten. Diese Abbildung wird in Zuordnungstabellen gespeichert, damit nachfolgende Aktualisierungen korrekt ausgeführt werden können und die Zuordnung nachvollziehbar bleibt. Leider besitzen Schlüssel in den Quelldatenbanken oft eine implizite Semantik. Ein Schlüssel eines Artikels könnte beispielsweise das Eingangsdatum enthalten. Diese Information muss gegebenenfalls in ein neu einzuführendes Attribut abgespeichert werden. 2.6.1.4 Aggregierung und (De)normalisierung Die auf Analyse zugeschnittenen Datenstrukturen eines Datawarehouses können sich wesentlich von denen eines Quellsystemes unterscheiden. In vielen Fällen sind die Datenstrukturen in einem Datawarehouse aus Effizienzgründen denormalisiert. Eine Anpassung der Datenstrukturen kann deshalb erforderlich sein. Die Basisdatenbank hat ein analyseunabhängiges Datenmodell, deshalb sind solche Anpassungen in diesem Bereich nicht notwendig. Sind die Daten im Quellsystem nicht normalisiert, kann im umgekehrten Sinne allerdings eine Normalisierung notwendig sein. Die Basisdatenbank enthält üblicherweise historisierte Detaildaten. Liegen die Daten in den Datenquelle allerdings in einen zu hohen Detailierungsgrad vor, müssen die Daten vorher aggregiert werden. 2.6.2 Schemaintegration Die anforderungsspezifische Modellierung von Ausschnitten der Welt bringt es bei der Datenmodellierung mit sich, das Datenmodelle sich unterscheiden obwohl sie die gleichen Dinge abbilden möchten. Diese Differenzen zwischen unterschiedlichen Datenbankschemata gilt es zu überwinden um verschieden Datenmodelle auf ein globales Datenmodell abbilden zu können. Die dabei entstehenden Probleme werden oft auch als Schemakonflikte bezeichnet. Schemakonflikte können bei relationalen Systemen auf Tabellen und auf Attributebene auftreten. Auf beiden Ebenen können Benennungskonflikte und konfligierende Integritätsbedingungen auftreten. Dabei können auf Attributebene unterschiedliche Datenbereichsbeschränkungen, null / not null Beschränkungen oder andere Integritätsregel im Widerspruch stehen. Auf der Tabellenebene hingegen können unterschiedliche Fremdschlüsselbeziehungen konfligieren. Fehlen Attribute in einer Tabelle, spricht man von Strukturkonflikten. Auf Verfahren der Schemaintegration werde ich an dieser Stelle nicht näher eingehen. 2.6.3 Datenbereinigung Die Datenqualität ist für das Datawarehousing ein sehr wichtiger Aspekt. Da die Quelldaten durch fehlerhafte, redundante, veraltete Daten verunreinigt sein können, müssen Maßnahmen ergriffen werden, die verhindern dass Analyseergebnisse durch mangelnde Datenqualität verfälscht werden können. Komponenten zur Datenbereinigung werden in zwei Kategorien eingeteilt. Wird zur Erkennung domänenspezifisches Wissen (z.B. Geschäftsregeln) eingesetzt, spricht man vom Data Scrubbing. Ohne Fachwissen kommen auf Data - Mining basierende Komponenten aus. Dabei wird versucht Zusammenhänge in Daten aufzudecken und daraus Regeln abzuleiten. Ausreißer von diesen Regeln können potentielle Verunreinigungen sein. Diese Fehlerbereinigungsverfahren zählen zum Data Auditing. Das Thema Cleansing und Datenqualität werde ich in einem späteren Abschnitt vertiefen. 2.7 Ladekomponente Ist die Transformationsphase abgeschlossen, befinden sich bereinigte und aufbereitete Daten im Arbeitsbereich. Eine Ladekomponente hat nun die Aufgabe diese Daten in die Seite 11 von 18 Basisdatenbank zu integrieren. Neben der Ladekomponenten, die zwischen dem Arbeitsbereich und der Basisdatenbank arbeitet, gibt es noch eine Ladekomponente zwischen der Basisdatenbank und der Datawarehouse Datenbank. Die Effizienz des Ladens spielt eine große Rolle, da oft beteiligte Systeme während des Ladens nur eingeschränkt oder gar nicht nutzbar sind. Es werden große Datenmengen bewegt die eine hohe Belastung an alle beteiligten Systeme darstellen. Die Basisdatenbank nimmt Daten eher auf der Detailebene auf. Die Daten die in das Datawarehouse geladen werden sind stärker aggregiert, dafür müssen hier die materialisierten Sichten aktualisiert werden. Die Ladephasen unterscheidet man zwischen dem ersten Laden (Initialisierung) und den späteren regelmäßigen Aktualisierungen. Wie auch bei der Extraktion können Bulk Loader die Performanz steigern. Wegen der zu erwartenden eingeschränkten Nutzbarkeit der beteiligten Systeme während des Ladens ist es sinnvoll den Zeitpunkt des Ladens so zu wählen, dass möglichst keine Nutzer zu dieser Zeit an dem System arbeiten, beispielsweise nachts oder am Wochenende. Weitere Möglichkeiten die Belastungsspitzen aufzufangen, bestehen in der Partitionierung und Parallelisierung der Ladeprozesse. Die Materialisierten Sichten, das sind vorberechnete Aggregationen, können inkrementell aktualisiert werden wenn sie selbstwartbar sind. Eine materialisierte Sicht ist selbstwartbar wenn die Änderungen in der Basisrelation und die Materialisierung ausreichen, um die neue Materialisierung zu bestimmen. Die inkrementelle Aktualisierung anstatt der Neuberechnung der materialisierten Sichten reduziert den Ladeaufwand weiter. 2.8 Basisdatenbank Die Basisdatenbank sammelt, integriert und historisiert Detaildaten aus den Datenquellen. Sie dient im Datawarehouse - System als zentrales Datenlager. Die Daten in der Basisdatenbank sind bereinigt und konsolidiert aber nicht oder nur wenig aggregiert. Die Aggregation und „Veredelung“ der Daten wird erst in den Datawarehouse Datenbanken vorgenommen. Die Datawarehouse - Datenbanken werden mit Daten aus der Basisdatenbank versorgt. Aus der Sicht der Datawarehouse Datenbanken hat die Basisdatenbank deshalb eine Distributionsfunktion. Im Gegensatz dazu hat die Basisdatenbank aus der Sicht der Datenquellen eine Sammel und Integrationsfunktion. Diese beiden Sichten werden gut durch die Nabe – Speichen Architektur veranschaulicht. Für Anfragen mit geringer Komplexität kann die Basisdatenbank ebenfalls eingesetzt werden. Abbildung 2: Nabe Speicher Architektur 2.9 Datawarehouse Das Datawarehouse ist eine Datenbank, die ausschließlich zu Analysezwecken aufgebaut wird. Ihre Aufgabe ist es, für die Analysen des Anwenders notwendigen Daten dauerhaft zu verwalten und den Analyseprozessen in geeigneter Form zur Verfügung zu stellen. Datawarehouse Datenbanken werden mit DBMS realisiert. Das Hauptproblem beim Aufbau einer Datawarehouse - Datenbank liegt im Design des geeigneten logischen Schemas. Zur Strukturierung der Daten hat sich für viele Problemstellungen das multidimensionale Datenmodell als zweckmäßig erwiesen. Wie das DBMS dieses Datenmodell intern abbildet, Seite 12 von 18 ob auf ein relationales Datenbankmodell oder auf ein spezielles Datenbankmodell, ist von Hersteller zu Hersteller unterschiedlich. Wenn das multidimensionale Datenmodell unterstützt wird muss das DBMS auch eine geeignete Abfragesprache anbieten. Hier hat sich neben OLAP Erweiterungen für SQL, MDX (Multidimensional Expression Language) von Microsoft etabliert. Neben dieser Zugriffsfunktion muss das DBMS auch Funktionen zur Verarbeitung der Daten anbieten, da Analysewerkzeuge die Daten in einer anderen Form benötigen als sie in der Datenbank vorliegen. Das können zum Beispiel statistische Funktionen oder Aggregationsfunktionen sein. Im Abschnitt Basisdatenbank war oft die Rede von mehreren Datawarehouse - Datenbanken. In der Tat ist es so, das es nicht immer sinnvoll oder überhaupt möglich ist, alle Analysen nur mit einer Datawarehouse - Datenbank zu unterstützen. Auf der einen Seite ist das Datenmodell einer Datawarehouse Datenbank speziell für bestimmte Analysen optimiert, die sich gegenseitig ausschließen können. Auf der anderen Seite ist eine zentralistische Lösung problematisch hinsichtlich der Skalierbarkeit. Unterschiedliche Anwenderkreise benötigen zudem eigene Sichten auf ein Datawarehouse um inhaltlich unterschiedliche Analysen durch zuführen. Diese Probleme greift das Konzept der Data Marts auf. Die grundlegende Idee dabei ist es, einen inhaltlich beschränkten Fokus des Unternehmens oder eine Abteilung als Teilsicht eines Datawarehouses abzubilden. Die Gründe für eine Data – Mart - Lösung sind vielfältig. Aus technischer Sicht bringt eine Data Mart Lösung ein Performanzgewinn durch eine Verteilung der Last und durch einen möglicherweise höheren Aggregationsgrad mit sich. Aus organisatorischer Sicht können Aspekte wie Datenschutz oder eine geforderte Eigenständigkeit (z.B. Mobilität) eine Rolle spielen. Es werden abhängige und unabhängige Data Marts unterschieden. Abhängige Data Marts sind Extrakte aus dem integrierten Datenbestand der Basisdatenbank. Dagegen sind unabhängige Data Marts isolierte Sichten auf die Quellsysteme. 2.9.1 Unabhängige Data Marts Bei der Verwendung unabhängiger Data Marts wird auf eine zentrale Basisdatenbank verzichtet. Dieser Ansatz führt zu einer reduzierten Komplexität des gesamten Datawarehouse - Systemes und macht es damit einfacher und überschaubarer. Der Nachteil liegt auf der Hand: es gibt keine gemeinsame Sicht auf die Datenquellen. Wenn Data – Mart übergreifende Analysen notwendig werden sollten, müssen Data Marts wieder integriert werden. Das kann schwierig werden da auch Data Marts Analyse spezifische Datenmodelle haben. Es gibt Architekturansätze, die ein aus Data Marts gebildetes, virtuelles Datawarehouse vorschlagen. Hier muss darauf geachtet werden, das die Datenmodelle der Data Marts kompatibel, d.h. integrierbar bleiben. Damit gibt man einen Teil der durch Data Marts gewonnenen Flexibilität wieder auf. Im Prinzip werden Konsolidierungs- und Integrationsproblem bei der Anwendung von unabhängigen Data Marts lediglich verschleppt. 2.9.2 Abhängige Data Marts Abhängige Data Marts enthalten nur Extrakte der Basisdatenbank, es werden keine weiteren Normierungen oder Datenbereinigungen durchgeführt. Der Extrakt kann struktureller Natur sein wenn der Data Mart nur einen bestimmten Teil der Basisdatenbank enthält. Handelt es sich um einen inhaltlichen Extrakt wird beispielsweise nur eine bestimmte Zeitschiene oder Lokalität berücksichtigt. Ein aggregierter Extrakt hat hingegen einen niedrigeren Detailierungsgrad als die zugrunde liegenden Daten. Natürlich sind auch beliebige Mischformen denkbar. Abhängige Data Marts sind inhaltlich konsistent mit der Basisdatenbank. Globale Analysen sind im Gegensatz zu unabhängigen Data Marts ohne Probleme möglich. Seite 13 von 18 2.10 Analyse Die Analysekomponente steht in der Referenzarchitektur als Stellvertreter für alle Werkzeuge, die auf den Daten der Datawarehouse Datanbank Analysefunktionen ausführen, um daraus neue Informationen zu generieren. Dabei werden die Analyseergebnisse aufbereitet, verändert und bereitgestellt damit sie von anderen Systemen weiterverarbeitet, oder an andere Personen weitergegeben werden können. Die Analysewerkzeuge, im Marketing Jargon auch Business Intelligence Tools genannt, präsentieren die in einem Datawarehouse - System gesammelten Daten und bieten darüber hinaus die Möglichkeit in diesen Daten interaktiv zu navigieren. Die Ergebnisse der Analysen werden als Grafik, Text oder Tabelle dargestellt. Die Analysefunktionen werden in drei Kategorien eingeteilt: dem einfachen Data Access, OLAP (Online Analytical Processing) und Data Mining. 2.10.1 Data Access Data Access Werkzeuge rufen Daten nur zur unmittelbaren weiteren Präsentation(z.B. Druck, Bildschirm, Excelsheet usw.) ab und verarbeiten diese kaum weiter. Die Komplexität der Abfragen entspricht ungefähr der normaler OLTP (Online Transaction Processing) Abfragen. In diese Kategorie fallen vor allem Berichtswerkzeuge. 2.10.2 OLAP OLAP Werkzeuge erlauben die interaktive Datenanalyse. Die dargestellten Berichte enthalten überwiegend quantitative, verdichtete Werte. Der Benutzer kann dynamisch zwischen verschiedene Detailierungsgraden und Dimensionselementen wechseln (drill down, roll up, drill across) und mit Berechnungs- und Gruppierungsfunktionen Hypothesen prüfen. Darüber hinaus gehende statistische und analytische Funktionen können helfen neue Erkenntnisse zu gewinnen. Das Akronym OLAP ist eng verknüpft mit dem multidimensionalen Datenmodell. OLAP Werkzeuge verwenden multidimensionale Operatoren, Techniken und Datenstrukturen. 2.10.3 Data Mining Im Gegensatz zu OLAP Analysen, wo der Anwender Hypothesen selbst aufstellt und überprüft, können Data - Mining - Werkzeuge selbst Zusammenhänge in Daten erkennen und in logische oder funktionale Beziehungsmuster abbilden. Diese Beziehungszusammenhänge können mit Data - Mining - Techniken in ein Modell abgebildet werden. Es werden verschiedene Data - Mining - Verfahren unterschieden: Die Clusterbildung wird benutzt um Daten in Hinblick auf Merkmalsausbildungen zu Gruppen zusammenzufassen. Die Ursache – Wirkungszusammenhänge zwischen einzelnen Merkmalen aufzudecken kann mit Regressionsverfahren erreicht werden. Außerdem werden Klassifikationsverfahren benutzt um einen Datenbestand vorgegebenen Klassen zuzuordnen. Die Abhängigkeitsentdeckungsverfahren dienen dem Aufspüren von Beziehungszusammenhängen zwischen unterschiedlichen Ausprägungen von Merkmalen. Als letztes seien hier die Verfahren der Abweichungsentdeckung genannt. Mit diesen Verfahren können Ausprägungen von Merkmalen entdeckt werden, die besonders stark von den üblichen Ausprägungen abweichen. 2.11 Repositorium Mit der Analyse endet der Fluss der Primärdaten in der skizzierten Referenzarchitektur. Die beiden noch nicht betrachteten Komponenten spielen aber trotzdem eine wichtige Rolle für die Funktionsweise eines Datawarehouse - Systems. Denn sie sind für die zweite Klasse von Datenströmen verantwortlich, den Metadaten. Metadaten sind alle Informationen, die den Aufbau, die Wartung und die Administration des Datawarehouse - Systems vereinfachen und die Informationsgewinnung aus dem Datawarehouse ermöglichen. Das sind Beschreibungsdaten über Daten aus den Datenquellen, der Basisdatenbank, des Datawarehouses und Informationen über konzeptuelle und logische Datenbankschemata und Seite 14 von 18 Dokumentation sowie physische Speicherinformationen, Zugriffsrechte und Qualitätssicherung. Metadaten sind zusammengefasst, beschreibende Informationen über Inhalt, Struktur, Kontext und Bedeutung von Daten aber auch prozessbezogene Informationen über die Verarbeitung dieser Daten. Mit Hilfe von Metadaten kann die Nachvollziehbarkeit der Herkunft von Daten und zu welchem Zeitpunkt sie in das System geladen wurden, erreicht werden. Auch kann die Qualität und Richtigkeit von Auswertungen überprüft werden. Das Repositorium dient als zentrale Metadatenablage in einem Data Warehouse System. Lediglich der Metadatenmanager greift direkt auf das Repositorium zu. 2.12 Metadaten – Manager Der Metadaten - Manager steuert die Metadatenverwaltung im Datawarehouse - System. Dabei handelt es sich um eine Datenbankanwendung, die Versions- und Konfigurationsmanagement sowie Integrations-, Zugriffs-, Anfrage-, und Navigationsmöglichkeiten für Metadaten bietet. Wenn vollständig ausführbare Spezifikationen (Transformationen, Abbildungen) der Datenverarbeitungsschritte als Metadaten gespeichert werden und diese von Werkzeugen interpretiert und ausgeführt werden, kann der Metadatenmanager den Datawarehouse - Manager auch mit Kontrollinformationen versorgen. Man spricht dann auch von metadatengetriebenen Prozessen. Die Verbreitung metadatengetriebener Werkzeuge ist allerdings gering. Die automatische Aktualisierung der Metadaten ist sinnvoll damit der Datenfluss aus den Datenquellen erhalten bleibt. Eine Schemaänderung in einer Datenquelle kann sonst leicht dazu führen, dass eine Extraktion und Transformation von Daten aus dieser Datenquelle fehlschlägt. In der Praxis verbreitete Lösungen haben im überwiegenden Maße keine zentrale, sondern eine dezentralisierte Metadatenverwaltung. 3 Datenqualität und Cleansing 3.1 Datenqualität Qualität ist die „Gesamtheit von Merkmalen (und Merkmalswerten) einer Einheit bezüglich ihrer Eignung, festgelegte und vorausgesetzte Erfordernisse zu erfüllen.“[4] Die „Einheit“ im Datawarehouse Kontext ist keine wirkliche Einheit sondern die gesamten, aus heterogenen Quellen stammenden Daten. Die erforderlichen Merkmale können in einer Taxonomie dargestellt werden. Problematisch ist allerdings die Quantifizierbarkeit des geforderten Erfüllungsgrades von Anforderungen und der Messbarkeit von Ausprägungen. Datenqualitä t Glaubwürdigkeit Nützlichkeit Interpretierbarkeit Schlüsselintegritä t Korrekthei t Vollständigkeit Einheitlichkei t Schlüsseleindeutigkeit Konsistenz Genauigkeit Eindeutigkeit referentielle Integrität Zuverlässigkei t Zeitnäh e Verständlichkeit Redundanzfreiheit Abbildung 3: Taxonomie der Qualitätsmerkmale Seite 15 von 18 Die Merkmale können sich in der folgenden Art und Weise charakterisieren lassen: Korrektheit: Die Attributwerte eines Datensatzes entsprechen den Merkmalsausprägungen des abgebildeten Objektes aus der Realwelt. Konsistenz: Die Attributwerte sind widerspruchsfrei zueinander, zu anderen Datensätzen oder zu Metadaten. Zuverlässigkeit: Die Attributwerte eines Datensatzes müssen vertrauenswürdig sein, das heißt frei von Unsicherheiten. Genauigkeit: Attributwerte liegen in einem für die jeweilige Anwendung optimalen Detaillierungsgrad vor. Vollständigkeit: Auf der einen Seite dürfen Attributwerte nicht unbekannt sein, auf der anderen Seite müssen alle Entitäten eines modellierten Weltausschnittes im System abgebildet sein. Zeitnähe: Die Attributwerte müssen zu einem Zeitpunkt in einem optimalen Maße der Realwelt entsprechen, d.h. aktuell sein. Redundanzfreiheit: Es dürfen keine Duplikate vorkommen. Es dürfen nicht mehrere Datensätze dieselbe Entität der Realwelt abbilden. Relevanz: Die verwendeten Datensätze müssen in sinnvolle Analysen des Anwenders eingehen. Schlüsseleindeutigkeit: Die Primärschlüssel eines Datenbestandes müssen eindeutig sein. Im relationalen Systemen muss die referentielle Integrität gewahrt bleiben. Die Relevanz der obigen Merkmale ist immer abhängig von der Anwendung und ihre Bewertung ist subjektiv. Die Datenqualität ist für den Erfolg einer Datawarehouse Lösung entscheidend. Es gilt das Prinzip „garbage in, garebage out“. Werden minderwertige Daten eingelesen, werden die daraus resultierenden Analyseergebnisse auch minderwertig sein. Datenqualitätsprobleme können nach [5] in Einzelquellen- und Mehrquellenprobleme unterschieden werden. Abbildung 4: Klassifikation Datenqualitätsprobleme 3.2 Cleansing Cleansing findet während der Transformationsphase im Arbeitsbereich statt. Darunter werden alle Aktivitäten gezählt, die darauf abzielen, Qualitätsmängel der in das Datawarehouse zu integrierenden Daten zu beheben. Seite 16 von 18 Für einige der im letzten Abschnitt eingeführten Qualitätsmerkmale können nur Prozessoptimierungen Verbesserungen bringen. So können Daten beispielsweise nicht durch Transformationen aktueller gemacht werden. Für die Qualitätsmerkmale, für die Verbesserungen erreicht werden können, sollen im Folgenden Maßnahmen vorgestellt werden. Korrektheit: Bei fehlerhaften Werten muss auf die Werte der Realwelt zurückgegriffen werden. Dies ist aber nur stichprobenartig sinnvoll. Ansonsten kann auf Methoden der statistischen Prozesskontrolle zurückgegriffen werden. Dabei werden auf eingehenden Daten statistische Kennzahlen berechnet und protokolliert. Bei starken Abweichungen kann automatisch eine Intervention erzwungen werden. Konsistenz: Die Bewertung der Konsistenz von Daten erfordert Fachwissen. Eine Automatisierung kann durch die Überprüfung von Geschäftsregeln (z.B. Eingangsdatum < Ausgangsdatum), regulären Ausdrücken (z.B. bei Artikelbezeichnungen) oder andere domänenspezifische Funktionen erfolgen. Vollständigkeit: Auch die Vollständigkeit kann nur mittels domänenspezifischen Wissens überprüft werden. Dabei ist darauf zu achten, dass fehlende Werte im System einheitlich repräsentiert werden. Nicht alle fehlenden Werte müssen einen Fehler darstellen. Redundanzfreiheit: Redundanzen können nur erkannt werden wenn die Anzahl der in einem Datenbestand repräsentierten Entitäten der Realwelt bekannt ist und damit die Anzahl der Duplikate im Datenbestand abschätzbar ist. 4 Zusammenfassung Die vorgestellte Referenzarchitektur ist idealtypisch, die Architektur realer System weicht zum Teil stark von ihr ab. Jedoch bietet eine Referenzarchitektur Vergleichs- und Beschreibungsmöglichkeiten. Die hier vorgestellte Architektur unterstreicht den Integrationsaspekt eines Datawarehouses durch die Einführung einer zentralen, konsolidierten und integrierten Basisdatenbank. Der Unterschied zu einer Datawarehouse Datenbank liegt im nicht analysespezifischen Datenmodell. Für den Erfolg eines Datawarehouses ist die Datenqualität wesentlich. Die Qualität der eingehenden Daten bestimmt den Wert der Analyseergebnisse. Unter Cleansing versteht man alle Maßnahmen zu Sicherung der Datenqualität, insbesondere der Korrektheit, Konsistenz, Vollständigkeit und Redundanzfreiheit. Für Bereinigungsmaßnahmen gibt es allerdings nur wenige allgemein anwendbare Methoden. Der Einsatz von domänenspezifischen Wissen ist unabdingbar. Seite 17 von 18 [1] http://de.wikipedia.org/wiki/Architektur, (Letzter Zugriff 25.06.2005). [2] Lehrbuch der Softwaretechnik, von Helmut Balzert, Spektrum Akademischer Verlag (November 2000). [3] Data Warehouse Systeme S. 32, Andreas Bauer und Holger Güntzel, Dpunkt Verlag (2004). [4] DIN 55350-11, 1987-05. [5] Data Cleaning: Problems and current Approaches, Erhard Rahm, Hong Hai Do, Univeristy of Leipzig, Germany. Seite 18 von 18
