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
Herunterladen