Quality first Datenqualität bestimmt Entscheidungen

Transkript

1 Fachhochschule für Technik und Wirtschaft Berlin Quality first Datenqualität bestimmt Entscheidungen Semesterarbeit im Fachbereich Wirtschaftswissenschaften II im Studiengang Wirtschaftsinformatik der Fachhochschule für Technik und Wirtschaft Berlin vorgelegt von: Saim Sert Resul Taner s s Lehrveranstaltung: Komplexe Datenbank-Anwendungen II Dozent: Peter Morcinek, M. Sc. Abgabetermin:

2 Inhaltsverzeichnis Inhaltsverzeichnis Inhaltsverzeichnis... II Abbildungs- und Tabellenverzeichnis... III Abkürzungsverzeichnis... IV 1 Einleitung Problemstellung und Motivation Aufbau der Arbeit Referenzarchitektur eines Data-Warehouse-Systems Datenquelle Verwendungszweck des Data-Warehouse-Systems Verfügbarkeit der Quelldaten Erwerbspreis der Quelldaten ETL-Prozess Extraktionsphase Transformationsphase Ladephase Basisdatenbank Data Warehouse Analyse Datenqualität Datenqualitätsprobleme in der Datenquelle Lösungsansätze für Datenqualitätsprobleme in der Datenquelle Datenqualitätsprobleme in der Transformationsphase Datenintegration Datenbereinigung Lösungsansätze für Datenqualitätsprobleme in der Transformationsphase Datenintegration Datenbereinigung Datenqualitätsprobleme in der Basisdatenbank Lösungsansätze für Datenqualitätsprobleme in der Basisdatenbank Lösung semantischer Konflikte in der Praxis Schemakonflikte nskonflikte Strukturelle Konflikte Konflikte durch Datenrepräsentation Datenkonflikte Widersprüchliche Datenbankinhalte Unterschiedliche Definitionen von Attributen Zusammenfassung und Fazit Literaturverzeichnis... VI II

3 Abbildungs- und Tabellenverzeichnis Abbildungsverzeichnis Abbildung 2.1: Referenzarchitektur eines Data-Warehouse-Systems... 4 Abbildung 2.2: Multidimensionaler Datenwürfel Abbildung 3.1: Datenqualitätsmängel Abbildung 3.2: Datenqualitätsmerkmale Abbildung 4.1: Schemakonflikt Synonyme Abbildung 4.2: Schemakonflikt Homonyme Abbildung 4.3: Schemakonflikt Identitätskonflikte Abbildung 4.4: Schemakonflikt Objektbeziehungen Abbildung 4.5: Schemakonflikt Fehlende Attribute Abbildung 4.6: Schemakonflikt Unterschiedliche Datentypen Abbildung 4.7: Schemakonflikt Unterschiedliche Wertebereiche Abbildung 4.8: Schemakonflikt Null-Werte Abbildung 4.9: Schemakonflikt Default-Werte Abbildung 4.10: Datenkonflikt Redundante Daten Abbildung 4.11: Datenkonflikt Maßeinheiten oder Maßstabsfaktoren Abbildung 4.12: Datenkonflikt Unterschiedliche Definitionen Abbildung 4.13: Datenkonflikt Kategorisierung Tabellenverzeichnis Tabelle 3.1: Surrogat III

4 Abkürzungsverzeichnis Abkürzungsverzeichnis ETL HTTP IBM ISO OLAP OLTP WWW Extraktion, Transformation, Laden Hypertext Transfer Protocol International Business Machines International Organization for Standardization OnLine Analytical Processing OnLine Transaction Processing World Wide Web IV

5 1 Einleitung 1 Einleitung Durch Informationssysteme werden Informationen für Führungskräfte bereitgestellt. Diese aufbereiteten Informationen dienen für eine bessere Entscheidung. Aufgrund dessen muss die Datenqualität immer sichergestellt sein und ist für ein Informationssystem beim Bereitstellen von Informationen von großer Bedeutung. Die Qualitätsmängel bei Daten können zu einer falschen Entscheidung führen und bei manchen Fällen sogar die Existenz des Unternehmens gefährden. 1.1 Problemstellung und Motivation Die Beschaffenheit der sich in den Datenquellen befindenden Daten wirkt sich unmittelbar auf die Beschaffenheit der aus dem Data Warehousing resultierenden Ergebnisse der Analyse aus. Obwohl die technische Umsetzung eines Data- Warehouse-Systems theoretisch keine so großen Schwierigkeiten bereitet, scheitern in der Praxis jedoch viele Projekte. Ein wesentlicher Grund für das Scheitern vieler Projekte ist, dass durch die hohe Motivation um schnell zum Erfolg zu gelangen immer unbereinigte Daten und somit Daten mit schlechter Qualität im Data-Warehouse-System verwaltet werden. 1 Schlechte Daten können auch dafür sorgen, dass ein Unternehmen nach außen hin schlecht repräsentiert wird. Wenn ein Unternehmen z. B. durch den Versand von Werbungen mit fehlerhaften Angaben einen schlechten Eindruck beim Kunden erweckt. Aus diesen Gründen haben die Auswahl der Daten und die Sicherung der Datenqualität eine große Bedeutung beim Erstellen eines Data-Warehouse-Systems gewonnen. 1 Vgl. [CHAMONI98] S. 15 f. 1

6 1 Einleitung 1.2 Aufbau der Arbeit In der vorliegenden Arbeit wird zunächst die Referenzarchitektur eines Data- Warehouse-Systems vorgestellt. Hierbei werden auf die Datenquelle und die einzelnen Komponenten eines Data-Warehouse-Systems, von der Extraktion bis zur Analyse, eingegangen. Im dritten Kapitel werden die Datenqualitätsprobleme und Lösungsansätze in den Bereichen Datenquelle, Transformationsphase und Basisdatenbank besprochen. Neben der Bewahrung und Sicherung der Datenqualität gibt es aber auch Probleme, die nicht lösbar sind, welche im Laufe dieser Arbeit kurz angesprochen werden. Anschließend werden im vierten Kapitel Lösungen semantischer Konflikte dargestellt. Eine Zusammenfassung und das Fazit schließen die Arbeit ab. 2

7 2 Referenzarchitektur eines Data-Warehouse-Systems 2 Referenzarchitektur eines Data-Warehouse-Systems Eine Referenzarchitektur muss wie jede Architektur die ihr gestellten Anforderungen erfüllen können. Sie soll kein dynamisches, sondern ein statisches Konstrukt sein. Die Gültigkeit einer Referenzarchitektur ist so lange, bis sie widerlegt oder eine bessere gefunden ist. Die Referenzarchitektur besteht aus mehreren Komponenten, um eine bessere Übersicht zu schaffen und die Komplexität zu verringern. Die entscheidungsrelevanten Daten werden von den Datenquellen anhand der Extraktion in den temporären Arbeitsbereich kopiert. Dieser Vorgang wird durch den Monitor unterstützt, indem er die entscheidungsrelevanten Daten von den Datenquellen auswählt. Im Arbeitsbereich werden die selektierten Daten transformiert. Von hier aus erfolgt das Laden der transformierten Daten in die Basisdatenbank. Die Komponenten Extraktion bis inklusive dem Laden gehören zum Datenbeschaffungsbereich. Diesem Bereich schließt sich der Auswertebereich an. Die Basisdatenbank, die den Anfang des Auswertebereichs bildet, ist durch die Schema- und Datenintegration aus verschiedenen Quellen gekennzeichnet. Das Bedürfnis nach Zeitstabilität und Unabhängigkeit macht es erforderlich, die Daten getrennt abzulagern. Somit muss auch nicht auf die Datenquellen zurückgegriffen werden. Daraufhin erfolgt das Laden der relevanten Daten in das Data Warehouse. Zusätzlich ist es sinnvoll, den Datenbestand des Data Warehouse durch so genannte Data Marts zu verteilen, um die Performance zu verbessern und um die Komplexität des Datenmodells zu vermindern. Die Referenzarchitektur wird durch die Analyse, die den Hauptzweck des Data Warehousing bildet, abgeschlossen. Im Repositorium, welches vom Metadaten-Manager verwaltet wird, befinden sich die ganzen Metadaten. Über den Metadaten-Manager gelangen die ganzen Metadaten zu den Komponenten des Data-Warehouse-Systems. Für den reibungslosen Ablauf des Data Warehousing ist der Data-Warehouse-Manager verantwortlich. 2 2 Vgl. [BAUER04] S. 31 ff. 3

8 2 Referenzarchitektur eines Data-Warehouse-Systems Auswertebereich Analyse Data-Warehouse-System Data Warehouse Laden Data- Warehouse- Manager Metadaten- Manager Repositorium Basisdatenbank Laden Arbeitsbereich Transformation Datenbeschaffungsbereich Extraktion Monitor Kontrollfluss Datenquelle Datenfluss Abbildung 2.1: Referenzarchitektur eines Data-Warehouse-Systems 3 3 [BAUER04] S

9 2 Referenzarchitektur eines Data-Warehouse-Systems 2.1 Datenquelle Der Ausgangspunkt des Datenflusses ist beim Data Warehousing die Datenquelle. Diese enthält die Daten sowie deren Beschreibungen, die einen Teil der Metadaten bilden. Die Quelldaten, die für das Data-Warehouse-System benötigt werden, müssen identifiziert und selektiert werden. Bei der Auswahl der Quelldaten müssen folgende Punkte beachtet werden: 4 Verwendungsweck des Data-Warehouse-Systems Verfügbarkeit der Quelldaten Erwerbspreis der Quelldaten Qualität der Quelldaten Auf den Punkt Qualität der Quelldaten wird in den Abschnitten 3.1 und 3.2 ausführlich eingegangen Verwendungszweck des Data-Warehouse-Systems Die Auswahl der relevanten Daten hängt von dem Verwendungszweck des Data- Warehouse-Systems ab. Im Data-Warehouse-System kann es aufgrund neuer Anforderungen des Analysevorhabens zu Änderungen im Datenbestand kommen. Diese Änderungen können sich sogar auf die realen Objekte auswirken. Als Beispiel kann hier die Reduzierung des physischen Lagerbestands der Produktpalette des Unternehmens BASF 5 genannt werden. Diese reduzierten nur durch Beseitigung von Datenanomalien und Redundanzen den physischen Lagerbestand ihrer Produktpalette um 27%. 6 4 [BAUER04] S Für Informationen wird auf die folgende Webseite verwiesen: 6 [SOEFFKY98] S

10 2 Referenzarchitektur eines Data-Warehouse-Systems Verfügbarkeit der Quelldaten Das Auffinden der für das Data Warehouse geeigneten Daten heißt nicht, dass diese Daten auch zur Verfügung stehen. Zumindest müssen folgende Bedingungen erfüllt sein: 7 Organisatorische Voraussetzungen Rechtliche Richtlinien müssen beachtet werden: Der Besitzer der Daten muss mit der Nutzung seiner Daten einverstanden sein 8, da diese vertrauliche Informationen enthalten können wie z. B. die Gehaltsangabe. Daten sollten vertraulich behandelt werden, indem sie z. B. nicht an Dritte weitergegeben werden. Die Sicherheit der Daten sollte im Data Warehouse gewährleistet sein, z. B. durch die Vergabe von verschiedenen Zugriffsrechten. Daten sollten immer verfügbar und auf dem aktuellsten Stand sein. Dies ist z. B. in der Börse sehr wichtig, da hier stets aktuelle Daten benötigt werden. Technische Voraussetzungen Schnelle Übertragung der Daten sollte möglich sein. Technischer Zugriff auf die Daten sollte möglich sein Erwerbspreis der Quelldaten Einen wichtigen Punkt beim Erwerb der Quelldaten stellt der finanzielle Aufwand für die Bereitstellung von Daten dar. Die Kosten schwanken hierbei von Unternehmen zu Unternehmen, wobei es auch die Möglichkeit gibt wie z. B. im Internet kostenfrei Daten zu erhalten. Daneben bieten Informationsdienstleister wie z. B. Hoppenstedt 9 oder Marktforschungsinstitute kostenpflichtig Daten an Vgl. [BAUER04] S. 41 f. 8 Für Informationen zum Datenschutz wird auf die folgende Website verwiesen: 9 Für Informationen wird auf die folgende Webseite verwiesen: 10 Vgl. [BAUER04] S

11 2 Referenzarchitektur eines Data-Warehouse-Systems 2.2 ETL-Prozess ETL steht als Abkürzung für Extraktion, Transformation und Laden. Diese drei Komponenten sorgen dafür, dass die entscheidungsrelevanten Daten aus den heterogenen Datenquellen ausgelesen, transformiert und in das Data Warehouse migriert werden. Im Folgenden werden diese drei Komponenten vorgestellt Extraktionsphase In der Extraktionsphase geht es um die Frage, welche Daten von den Datenquellen ausgelesen und in den Arbeitsbereich importiert werden. Bei der Selektion sollte darauf geachtet werden, dass nur entscheidungsrelevante Daten berücksichtigt werden. Bei einer großen Anzahl an Datenvolumina ist es vorteilhaft, die zu transformierenden Daten zu komprimieren. Zunächst ist jedoch zu überprüfen, ob Durchgriffsmöglichkeiten oder Datenexportverfahren aus den operativen Systemen existieren. Hier müssen gegebenenfalls neue Schnittstellen programmiert werden. Weiterhin sind die Zeitabstände, zu denen die Extraktionen stattfinden sollen, zu beachten. 11 Diese können zu unterschiedlichen Zeitpunkten stattfinden. Hierbei werden folgende Vorgehensweisen unterschieden: 12 Periodisch: Die Extraktion erfolgt immer zu einem ganz bestimmten Zeitpunkt, wenn z. B. immer am Monatsende eine Mitarbeiterauswertung durchgeführt werden muss. Anfragegesteuert: Die Extraktion wird durch eine Ad-hoc-Anfrage ausgelöst, wenn z. B. ein neuer Kunde akquiriert wird. Sofort: Die Extraktion erfolgt aufgrund der Aktualitätsanforderung sofort wie z. B. bei Devisenkursen. 11 Vgl. [CHAMONI98] S. 65 f. 12 Vgl. [KIMBALL98]. 7

12 2 Referenzarchitektur eines Data-Warehouse-Systems Transformationsphase In der Transformationsphase werden die extrahierten Daten, bevor sie in die Basisdatenbank geladen werden, in einen geeigneten Zustand gebracht. Die Transformation betrifft nicht nur den strukturellen Aspekt wie die Schemaintegration, sondern auch inhaltliche Aspekte, zu denen die Datenintegration und -bereinigung gehören. In den Abschnitten 3.3 und 3.4 wird auf die Datenintegration und -bereinigung näher eingegangen Ladephase Nach der Transformationsphase können die vereinheitlichten und bereinigten Daten in die Basisdatenbank geladen werden. Für die Weitergabe der Daten aus dem Arbeitsbereich in die Basisdatenbank und von dort in das Data Warehouse sind jeweils die Ladekomponenten verantwortlich. Im Falle, dass keine Basisdatenbank vorhanden ist, existiert nur eine Ladekomponente. Beim Ladeprozess können verschiedene Ladesoftwares verwendet werden. 2.3 Basisdatenbank Die Basisdatenbank liegt zwischen dem Arbeitsbereich und dem Data Warehouse und kann als zentrales Lager der Daten bezeichnet werden. In ihr befinden sich die Daten im notwendigen Detaillierungsgrad. Die Daten, die sich in der Basisdatenbank befinden, können aktualisiert werden. Die Kernfunktion der Basisdatenbank ist, die Versorgung des Analysebereichs mit aufbereiteten Daten. 13 Obwohl die Basisdatenbank eine sehr bedeutende Rolle spielt, wird sie in der Praxis meistens nicht verwendet, da sie sehr kostenintensiv sein kann. 13 Vgl. [MORCINEK06] Folie 2/S. 41, , 20:18 (MEZ). 8

13 2 Referenzarchitektur eines Data-Warehouse-Systems 2.4 Data Warehouse Zum Ende der 80er-Jahre stellte IBM 14 das Konzept des European Business Information Systems auf. Hiermit konnten zum ersten Mal alle im Unternehmen elektronisch existierenden und entscheidungsrelevanten Daten in einer Datenbank zusammengeführt werden. 15 Dieses Konzept wurde von seinem Vordenker INMON als Data Warehouse bezeichnet. 16 Nach INMON wird ein Data Warehouse folgendermaßen definiert (1993): A data warehouse is a subject-oriented, integrated, nonvolatile, and time-variant collection of data in support of management s decisions. 17 Ziel eines Data Warehouse ist es, die entscheidungsrelevanten Daten, die aus verschiedenen Datenquellen stammen können, in einer einheitlichen und zentralen Datenbank zusammenzuführen, welche die Führungskräfte bei den jeweiligen Analysen unterstützen soll. Die bei der Zusammenführung extrahierten Daten werden dauerhaft gespeichert und können später weder verändert noch gelöscht werden. Die Analysen werden mittels Analyseverfahren wie z. B. OnLine Analytical Processing (OLAP) oder Data Mining durchgeführt. Zu den Eigenschaften eines Data-Warehouse-Systems gehören: 18 Auswertungsorientierte Organisation: Es sollten nur die Daten, die für das jeweilige Projekt bzw. die Auswertung entscheidungsrelevant sind, berücksichtigt werden. Integration: Die Daten werden aus unterschiedlichen Quellen extrahiert, bereinigt und dann untereinander zu einer integrierten Datenbasis verknüpft. Keine Aktualisierung durch Benutzer: Die Anwender können die Daten im Data Warehouse weder löschen, ändern noch neu einfügen. Sie haben nur einen Lese-Zugriff. Unter der Kontrolle des Administrators wird die Datenbasis eines Data-Warehouse-Systems periodisch von operativen Quellsystemen mit neuen Daten versorgt. 14 Für Informationen wird auf die folgende Webseite verwiesen: 15 Vgl. [STOCK] S. 1 f. 16 Vgl. [JUNG00] S [INMON02] S Vgl. [LEHNER03] S

14 2 Referenzarchitektur eines Data-Warehouse-Systems Historisierung: Die in ein Data-Warehouse-System eingebrachten Daten werden durch die neu hinzugefügten nicht überschrieben, sondern ergänzt. Somit ist nach einiger Zeit eine Historisierung erreicht. 2.5 Analyse Das Data-Warehouse-System bildet die Grundlage vieler Anwendungssysteme. Prominente Beispiele hierfür sind Data Mining und OLAP. In diesem Abschnitt werden diese Begriffe kurz erläutert. Data Mining Das Ziel des Data Mining ist es, unbekannte Zusammenhänge herauszufinden. Anhand der vorhandenen Daten werden Modelle gebildet, mit der man zukünftige Daten erzeugt. 19 OLAP OLAP ist eine Software-Technologie, die dem Anwender schnelle, vielfältige und interaktive Zugriffe auf die relevanten Daten ermöglicht. 20 Die Erfindung von OLAP geht auf Edgar F. CODD (1993) zurück. Im Unterschied zu OnLine Transaction Processing (OLTP), was transaktionsorientiert ist, lassen sich mit OLAP multidimensionale und dynamische Analysen mit konsolidierten und historisierten Daten durchführen. Die speziellen Abfragetechniken und -operatoren, die den OLAP kennzeichnen, werden mittels eines mehrdimensionalen Würfels dargestellt Vgl. [MORCINEK06] Folie 4/S. 4 f., , 21:52 (MEZ). 20 Vgl. [GLUCHOWSKI97] S Vgl. [CHAMONI98] S

15 2 Referenzarchitektur eines Data-Warehouse-Systems In der Abbildung 2.2 werden die Dimensionen durch Mitarbeiter, Zeit und Kunde und die betriebswirtschaftliche Kenngröße durch den Verkaufswert dargestellt. Abbildung 2.2: Multidimensionaler Datenwürfel [UNICAT06] Punkt 5, , 01:24 (MEZ). 11

16 3 Datenqualität 3 Datenqualität In diesem Kapitel werden auf die Qualitätsmängel in den Bereichen Datenquelle, Transformationsphase und Basisdatenbank und deren Verbesserung bzw. Beseitigung eingegangen. Hierbei gibt es zwei grundsätzliche Ansätze um die Qualitätsmängel bei einem Data-Warehouse-System zu beseitigen: 23 Ursachenorientierter Ansatz: Daten werden bereits in den Quellsystemen verbessert Symptombezogener Ansatz: Daten werden in der Transformationsphase verbessert Bevor über Datenqualitätsprobleme und deren Maßnahmen diskutiert wird, sollte der Begriff Qualität definiert werden. Hierzu gibt es viele Definitionen, wobei eine Definition nach Norm ISO 9000:2000 folgendermaßen lautet: Wahrnehmung des Kunden zu dem Grad, in dem die Anforderungen des Kunden erfüllt worden sind Datenqualitätsprobleme in der Datenquelle Für die Erstellung eines Data-Warehouse-Systems müssen zuerst geeignete Daten gefunden werden. Es kann aber sein, dass die Daten aus technischen, organisatorischen oder rechtlichen Gründen nicht vorliegen oder dass die Quelldaten die definierten Qualitätsanforderungen nicht erfüllen. 25 Einige Qualitätsmängel, die bei Quelldaten auftreten, sind folgende: 26 Unkorrekte Daten, die durch falsche Eingaben verursacht werden; hierzu zählen z. B. falsches Ablesen, mangelnde Motivation etc. Vage bzw. ungenaue Daten Fehlende Daten Redundante Daten 23 Vgl. [STOCK] S [DIN06] Vgl. [STOCK] S Vgl. [HINRICHS02] S. 34 f. 12

17 3 Datenqualität Inkonsistente Daten Für einen bestimmten Wertebereich nicht zulässige Daten 1. Datenquelle Inkonsistenz ID Anrede Geburtsdatum Geschlecht Semesterbeitrag Frau Jürgen Löw 1978 M 241,37 2. Datenquelle Redundanz Uneinheitlichkeit (Datumsangabe) Uneinheitlichkeit (Kodierung) Uneinheitlichkeit (Skalierung) DM 2XYZ J. Löw ,08 Unvollständigkeit Abbildung 3.1: Datenqualitätsmängel 27 Qualitativ mangelhafte Quelldaten können erhebliche Kosten verursachen, so dass es sogar zu einem Scheitern des Data-Warehouse-Systems kommen kann. In diesem Zusammenhang werden von HELFERT folgende Kostenfaktoren identifiziert: 28 Nachträgliche Erkennung und Beseitigung von Qualitätsdefiziten durch zusätzlichen Aufwand Mangelnde Unterstützung der operativen Geschäftsprozesse führt zu Fehlentscheidungen 27 In Anlehnung an [HINRICHS02] S Vgl. [HELFERT00] S

18 3 Datenqualität 3.2 Lösungsansätze für Datenqualitätsprobleme in der Datenquelle Damit sich die Fehleranzahl reduziert, ist es wichtig, schon bei der Datenerfassung umfangreiche Kontrollen durchzuführen. Somit können Fehlerquellen wie z. B. veraltete, fehlende oder ungenaue Attributwerte aufgehoben werden. Qualitätsmerkmale von Daten sollten identifiziert und soweit wie möglich klassifiziert werden. Die Taxonomie von Datenqualitätsmerkmalen nach HINRICHS sieht folgendermaßen aus: Datenqualität Glaubwürdigkeit Nützlichkeit Interpretierbarkeit Schlüsselintegrität Konsistenz Genauigkeit Verständlichkeit Referenzielle Integrität Korrektheit Vollständigkeit Eindeutigkeit Schlüsseleindeutigkeit Zuverlässigkeit Relevanz Einheitlichkeit Zeitnähe Redundanzfreiheit Abbildung 3.2: Datenqualitätsmerkmale 29 Über die in Abbildung 3.2 aufgeführten Datenqualitätsmerkmale können Qualitätsanforderungen an Daten spezifiziert werden. 29 [HINRICHS02] S

19 3 Datenqualität Nun werden auf die, in der Abbildung 3.2, dargestellten Merkmale näher eingegangen: 30 Korrektheit: Die in einer Datenbank vorliegenden Attributwerte eines Datensatzes entsprechen den modellierten Entitäten der realen Welt, wenn z. B. die angegebene Anschrift einer Person auch tatsächlich existiert. Konsistenz: Die Attributwerte der Datensätze weisen keine logischen Widersprüche untereinander auf. Wenn beispielsweise für jemanden, der 26 Jahre alt ist (zum Zeitpunkt: ), in der Datenbank als Geburtsdatum der eingetragen ist. Zuverlässigkeit: Die Daten sind sicher bzw. genau. Hierfür muss aber die Entstehung der Daten nachvollziehbar sein, z. B. indem Informationen über das Unternehmen oder die Organisation, die die Daten liefert, recherchiert werden. Außerdem können Plausibilitätsprüfungen und Verfahrensvorschriften zur Ausschaltung subjektiver Ermessensspielräume definiert werden. Genauigkeit: Detaillierte Beschreibung der Attributwerte eines Datensatzes, z. B. die exakte Beschreibung einer Uhrzeit (Stunden, Minuten, Sekunden). Zeitnähe: Die Attributwerte eines Datensatzes sind nicht veraltet, z. B. werden in der Börse immer mit aktuellen Daten gehandelt. Redundanzfreiheit: In einer Menge von Datensätzen werden keine Duplikate verwendet. Relevanz: Hinsichtlich eines gegebenen Kontextes deckt sich der Informationsgehalt eines Datensatzes mit dem Informationsbedarf einer Anfrage. Einheitlichkeit: Die Attributwerte der Datensätze besitzen eine einheitliche Repräsentationsstruktur, so dass z. B. bei der nsschreibweise der Vorname dem Nachnamen folgt [, Vorname]. Verständlichkeit: Die Attributwerte eines Datensatzes werden so dargestellt, dass die Struktur und Begrifflichkeit für den Anwender verständlich bzw. vorstellbar sind, z. B.: m = männlich und w = weiblich. 30 Vgl. [HINRICHS] S. 30 ff., Beispiele sind eigene Darstellungen. 15

20 3 Datenqualität Schlüsseleindeutigkeit: Eindeutigkeit der Primärschlüssel eines Datenbestands. 31 Referenzielle Integrität: Jeder Fremdschlüssel referenziert einen Primärschlüssel. 32 Eindeutigkeit: Wenn Metadaten mit hoher Qualität vorliegen, können die Datensätze eindeutig interpretiert werden. Vollständigkeit: Die in der modellierten Realwelt vorhandenen Entitäten werden in einer Datenbank dargestellt. Die oben aufgelisteten Charakteristika der Qualitätsmerkmale definieren die Qualitätsanforderungen an die entscheidungsrelevanten Daten. Hierbei muss gesagt werden, dass die Erfüllung einer Anforderung an ein Qualitätsmerkmal bei einem Datenbestand unterschiedlich sein kann. In der Praxis ist ein Erfüllungsgrad von 100% kaum zu erreichen. Deswegen sollte darauf geachtet werden, dass wenigstens die Mindestqualität erreicht wird. 33 Da die Anforderungen je nach Projekt individuell vom Unternehmen gestellt werden, sind diese meistens subjektiv. 3.3 Datenqualitätsprobleme in der Transformationsphase In der Transformationsphase wird versucht, die Daten auf einen einheitlichen Zustand zu bringen. Hierbei können bei der Transformation der Daten Probleme auftreten. In diesem Kapitel werden auf die möglichen Probleme eingegangen, wobei wir uns auf die Punkte Datenintegration und Datenbereinigung konzentrieren Datenintegration Da die auf Analysen zugeschnittenen Datenstrukturen eines Data Warehouse sich sehr von dem des Quellsystems unterscheiden können, ist eine Transformation der Daten aus den Quellstrukturen in die Zielstruktur notwendig. Die Transformationen, die in diesem Abschnitt erläutert werden, bezeichnet man zusammengefasst als Datenmigration. Diese dienen überwiegend der Homogeni- 31 Für ein Beispiel zur Schlüsseleindeutigkeit wird auf die Abbildung 4.3 verwiesen. 32 Für ein Beispiel zur referenziellen Integrität wird auf die Abbildung 4.4 verwiesen. 33 Vgl. [HINRICHS] S

21 3 Datenqualität sierung vorerst heterogener Daten. Typische Transformationen und damit auch mögliche Problembereiche sind: 34 Schlüsselbehandlung Anpassung von Datentypen Konvertierung von Kodierungen Vereinheitlichung von Zeichenketten Vereinheitlichung von Datumsangaben Umrechnung von Maßeinheiten Kombination/Separierung von Attributwerten Berechnung abgeleiteter Werte Aggregierung Datenbereinigung Quelldaten sind häufig durch redundante, fehlerhafte, veraltete oder fehlende Werte verunreinigt. Anhand von Plausibilitätsprüfungen oder Record Linkage- Verfahren können die vorhandenen Verunreinigungen gefunden und auch korrigiert werden. Solche Pflege der Daten wird als Datenbereinigung bezeichnet. Die Softwarekomponenten, die für die Datenbereinigung benötigt werden, können mittels ihrer Funktionalitäten zu einer der beiden Kategorien eingeordnet werden: 35 Data Scrubbing: Durch die Verwendung domänenspezifischer Informationen werden fehlerhafte Daten erkannt und beseitigt. Data Auditing: Hier wird das Data Mining eingesetzt, um vorher nicht bekannte Zusammenhänge der Daten zu erkennen und so die Fehler aufzuheben. 34 [BAUER04] S Vgl. [STOCK05] S

22 3 Datenqualität Zusätzlich zu den aufgeführten Problembereichen können technische Fehlerquellen im Bereich der Datenübertragung, die die Entstehung von Datenqualitätsmängeln auslösen, hinzugefügt werden: 36 Netzwerkfehler Datenträgerdefekte Unzureichende Bearbeitungsprozesse Fehlerhafte Bedienung 3.4 Lösungsansätze für Datenqualitätsprobleme in der Transformationsphase Im folgenden Abschnitt werden Lösungsansätze zur Beseitigung der gegebenenfalls auftretenden Probleme in der Transformationsphase vorgestellt. Zuerst wird mit der Datenintegration begonnen, anschließend folgt die Datenbereinigung Datenintegration In der Datenintegration sind folgende Transformationen möglich: 37 Schlüsselbehandlung Schlüssel von Quelldatensätzen können bei der Übertragung der Quelldaten ins Data-Warehouse-System meistens nicht übernommen werden, da sie global eindeutig sein müssen. Im Laufe der Transformation werden die Quellschlüssel auf Surrogate (künstlich erzeugte Schlüssel) abgebildet. Wenn globale Surrogate identisch sind, handelt es sich um das gleiche Objekt, in dem Falle um denselben Lieferanten. 36 [STOCK05] S [BAUER04] S. 84 ff., Beispiele sind eigene Darstellungen. 18

23 3 Datenqualität Quelle Relation Attribut lokaler Schlüssel globales Surrogat system 1 lieferant lieferanten_nr system 1 lieferant lieferanten_nr system 1 lieferant lieferanten_nr system 2 supplier supplier_id B system 2 supplier supplier_id C system 2 supplier supplier_id Z Tabelle 3.1: Surrogat 38 Ein weiteres Defizit von Quellschlüsseln ist, dass diese häufig eine implizite Semantik besitzen. Diese muss bei der Übernahme ins Data-Warehouse-System berücksichtigt werden. Beispielsweise könnte in den Quellschlüsseln einer Artikeldatenbank das Jahr der Veröffentlichung des neuen Artikels hineinkodiert worden sein ( NEW2001 ). In diesem Fall müssen eventuell, die im Schlüssel zusätzlich vorhandenen Informationen extrahiert und in einzelne Attribute abgelegt werden. Meistens ist in Altsystemen die Semantik von Schlüsseln nicht bekannt. Anpassung von Datentypen Eine Konvertierung der Attributwerte eines Datensatzes ist notwendig, wenn der Datentyp des Quellattributs mit dem des korrespondierten Zielattributs nicht übereinstimmt. Beispiele: Character Number Character Date In Anlehnung an [BAUER04] S

24 3 Datenqualität Konvertierung von Kodierungen Eine Konvertierung ist bei den Attributen, die eine Kodierung besitzen dann notwendig, wenn die Kodierungsstandards in der Quelle und im Ziel unterschiedlich sind. Es kann aber auch vorkommen, dass Klartexte zu kodieren sind oder Codes in Klartexte zurück umgewandelt werden müssen. Beispiele: Kodierung X Kodierung Y m, w 1, 0 Klartext Kodierung Bruttopreis, Nettopreis A, B Vereinheitlichung von Zeichenketten Die Zeichenketten können durch die Transformation vereinheitlicht werden. Ein Beispiel für die Vereinheitlichung von Zeichenketten, ist die Ersetzung von Umlauten durch eine alternative Schreibweise. Bei der alternativen Schreibweise können auch nur Groß- oder Kleinbuchstaben verwendet werden. Beispiele: Datenqualitätsmängel Datenqualitaetsmaengel Datenqualitaetsmaengel DATENQUALITAETSMAENGEL Vereinheitlichung von Datumsangaben Bei manchen Datenbankmanagementsystemen wird bei der Datumsangabe zwischen interner und externer Darstellung unterschieden. Hierbei ist die interne Darstellung statisch und die externe an die jeweiligen Anwenderbedürfnisse anpassungsfähig, z. B. landesspezifisches Datumsformat. Ob eine Konvertierung der Datumsangabe erforderlich ist, hängt von dem Zieldatenbanksystem ab. Beispiel: MM-TT-JJJJ TT.MM.JJJJ 20

25 3 Datenqualität Umrechnung von Maßeinheiten Merkmalsausprägungen, die numerisch sind, besitzen meist eine Maßeinheit. Hierbei kann die Maßeinheit des Attributs im Quellsystem von dem des Zielsystems abweichen. Eine Umrechnung ist aber auf jeden Fall für die Angleichung der Maßeinheit notwendig. Beispiele: 20 km m 30 inch 72,2 cm Kombination/Separierung von Attributwerten In einigen Fällen ist es erforderlich, einen Attributwert einer Quelle in mehrere Attributwerte des Ziels zu zerlegen. Es ist aber auch möglich, mehrere Attributwerte einer Quelle zu einem Attributwert des Ziels zusammenzufassen. Beispiele: Tag = 23, Monat = 05, Jahr = Bezeichnung: Laptop, 3200g Typ = Laptop, Gewicht = 3200 Berechnung abgeleiteter Werte Es ist manchmal sinnvoll, aus bestimmten Attributwerten der Quelle, neue Werte abzuleiten. Diese abgeleiteten Werte werden dann in der Zielquelle gespeichert. Für diesen Vorgang gibt es zwei Gründe: Der erste Grund ist, dass die Quelldaten in ihrer ursprünglichen Form im Ziel nicht benötigt werden. Der zweite Grund ist, dass zu den ursprünglichen Quelldaten die abgeleiteten Werte gespeichert werden, um bei den Auswertungen die Effizienz zu steigern. Beispiele: Markteinführungsdatum Vertriebszeitraum Vertriebszeitraum = aktuelles Datum - Markteinführungsdatum Verkaufspreis Gewinn Gewinn = Verkaufspreis - Einkaufspreis 21

26 3 Datenqualität Aggregierung Die Verwendung von historischen Daten ist ein charakteristisches Merkmal von Data-Warehouse-Systemen. Somit kann die Entwicklung der betrachteten Größe über eine bestimmte Periode beobachtet werden. Die Daten können nach analyserelevanten Kriterien wie Produktgruppe oder Region gruppiert werden. Die am meisten und einfachsten zu verwendete Aggregierung ist die Summierung wie z. B. das Summieren der Gehälter einer Abteilung für einen bestimmten Zeitraum. Weitere Aggregatfunktionen neben der Summierung sind Maximalwert-, Minimalwert- und Durchschnittsermittlung Datenbereinigung Bei der Integration der Daten aus einer oder mehreren Quellen in die Zieldatenbank, müssen die Qualitätsmängel beseitigt werden. Die Verfahren, die zur Beseitigung dieser Mängel dienen, werden zusammengefasst als Datenbereinigung bezeichnet. Bei manchen Daten können die Qualitätsmängel schwer bereinigt werden. Diese Mängel können dann eventuell ursachenorientiert behoben werden, z. B. durch Prozessoptimierung. Dagegen werden einige Qualitätsmerkmale, bei denen eine Bereinigung generell möglich ist, mit ihren Bereinigungsmaßnahmen vorgestellt: 39 Korrektheit Ein im Informationssystem als nicht korrekt beurteilter Wert, muss durch den realen Attributwert in der Diskurswelt ersetzt werden. Da dieser Vorgang in der Regel nicht automatisierbar und bei einer großen Anzahl an Daten nicht praktisch ist, wird eine Bereinigung gewöhnlich strichprobenartig durchgeführt. Ein Beispiel hierfür ist, das Abgleichen der Materialien in einer Datenbank mit dem physischen Lagerbestand. Eine weitere Möglichkeit um Mängel bezüglich Korrektheit zu finden, ist die Anwendung von Konzepten der Statistischen Prozesskontrolle 40 (SPC), die auf Walter A. SHEWHART zurückgeht. 39 [HINRICHS02] S. 71 ff. 40 Für weitere Informationen wird auf [SHEWHART31] verwiesen. 22

27 3 Datenqualität Redundanzfreiheit Wenn die Anzahl der im Datenbestand vorhandenen Entitäten der realen Welt und somit die Anzahl der Duplikate im Datenbestand abschätzbar ist, kann eine Redundanzfreiheit gemessen werden. Bei der Redundanzfreiheit wird im Allgemeinen nicht auf die Realwelt zurückgegriffen. Hier wird anhand der Record Linkage- Verfahren eine Abschätzung durch Attributwertvergleiche im Informationssystem durchgeführt. Wenn eine Zuordnung zweier Datensätze mittels ihres übereinstimmenden Primärschlüssels erfolgt, ist es ideal (schlüsselbasiertes Linkage). Dies ist jedoch in der Praxis kaum möglich, da die Daten aus heterogenen Quellen stammen und keine globalen Primärschlüssel vorhanden sind. Somit kann eine Zuordnung von Datensätzen nur noch auf Basis einer Analyse der ähnlichen Nicht- Schlüssel-Attributwerte erfolgen. Um die Redundanzfreiheit näher darzustellen, wird nun ein bekanntes Record Linkage-Verfahren, nämlich das probabilistische Record Linkage-Verfahren, vorgestellt: Hierbei handelt es sich um ein abweichungstolerantes Verfahren, bei der Gewichte in Abhängigkeit von der Ähnlichkeit der Attributwerte zweier Datensätze vergeben werden. Dann werden für jedes Datensatzpaar die einzelnen Attributgewichte summiert, so dass sich dann eine Wahrscheinlichkeit ergibt, welche einen Aufschluss darüber gibt, inwieweit die beiden Datensätze dieselbe Realwelt-Entität beschreiben und einander zuzuordnen sind. Folglich ergeben sich durch die Anwendung eines Record Linkage-Verfahrens eine Menge von Zuordnungen zwischen Datensätzen. Durch die Bildung dieser Menge können die Duplikate eliminiert und damit auch die Qualität der Daten verbessert werden. Vollständigkeit 41 Bei der Vollständigkeit kann domänenspezifisches Wissen angewandt werden, damit fehlende Werte abgeleiteter Attribute hinzugefügt werden können. Bei den Attributwerten oder Datensätzen, die mittels domänenspezifischen Wissens nicht ausfindig gemacht werden können, müssen die zuständigen Stellen, wo die Daten herkommen, befragt werden. Die fehlenden Werte sollten im Data Warehouse einheitlich dargestellt werden. In modernen Datenbankmanagementsystemen wird 41 [BAUER04] S. 91 f., Beispiele sind eigene Darstellungen. 23

28 3 Datenqualität dem fehlenden Wert der NULL-Wert zugewiesen. Dieser NULL-Wert ist datentypunabhängig, jedoch bedeutet der Wert NULL nicht immer ein Datenqualitätsmangel. Es werden folgende Unterscheidungen bei der Semantik eines NULL-Wertes vorgenommen: (1) In der Realwelt gibt es keinen Wert für das Attribut, z. B. die Haltbarkeitsdauer für einen Taschenrechner. (2) Für das Attribut gibt es in der Realwelt einen Wert, aber dieser war zum Zeitpunkt der Erfassung entweder nicht bekannt oder wurde aus gewissen Gründen nicht erfasst. Beispielsweise wird das Geburtsdatum der Kunden im Quellsystem meistens nicht gespeichert, da sie zu dem Zeitpunkt nicht benötigt werden. Aber bei späteren Analysen könnten diese von Nutzen sein. (3) Es ist in der Realwelt nicht bekannt, ob ein Wert für das Attribut existiert, z. B. hat der Kunde eine Mobiltelefonnummer? Wenn die oben genannten Fälle bezüglich der Qualität bewertet werden sollen, dann kann gesagt werden, dass beim ersten Punkt kein Qualitätsdefizit, wogegen aber beim zweiten Punkt ein Qualitätsdefizit hinsichtlich Vollständigkeit besteht. Über den dritten Fall lässt sich keine Qualitätsaussage machen. Eine Aussage hierzu, kann nur durch die Nutzung von Domänenwissen gemacht werden. Einheitlichkeit Die Verbesserungsmaßnahmen für die Einheitlichkeit der Daten wurden im Abschnitt 3.2 ausführlich diskutiert. 24

29 3 Datenqualität 3.5 Datenqualitätsprobleme in der Basisdatenbank Obwohl die Basisdatenbank einen sehr hohen Stellenwert im Data-Warehouse- System hat, wird sie aufgrund der hohen Kosten- und Pflegeaufwand vernachlässigt. Nur die Erfüllung der Qualitätsanforderungen an die Daten in der Datenquelle reicht nicht aus, um die Qualität der Basisdatenbank sicherzustellen. 42 Es muss nachvollziehbar sein, wie die Daten in die Basisdatenbank gekommen sind und welche Transformationen durchgeführt wurden. Hierfür müssen die organisatorischen und technischen Voraussetzungen vorliegen, um die entscheidungsrelevanten Daten von dem Arbeitsbereich in die Basisdatenbank laden und später auf diese zugreifen zu können. 3.6 Lösungsansätze für Datenqualitätsprobleme in der Basisdatenbank Um die Nachvollziehbarkeit zu verfolgen und die Verfügbarkeit feststellen zu können, werden an die Metadaten der Basisdatenbank folgende Qualitätsanforderungen gestellt: 43 Nachvollziehbarkeit Eindeutige Erklärung der Eingriffsmöglichkeiten in die Transformationen Eindeutige Beschreibung der Transformationen Beschreibung des Datenflusses und der Prozesse von den Quellsystemen bis zum Data Warehouse Es soll nicht unerwähnt bleiben, dass eine Beschreibung von den Analyseergebnissen zu den operativen Systemen, also der umgekehrte Weg, um die Datenherkunft festzustellen, auch durchgeführt werden kann. Dieser Vorgang wird als Data- Lineage bezeichnet Vgl. [STOCK] S Vgl. [BAUER04] S Vgl. [WIKIPEDIA06], , 19:01 (MEZ). 25

30 3 Datenqualität Verfügbarkeit Einhalten der Lieferzeit für die Daten Sicherstellung des Zugriffs auf die Basisdatenbank/Data Warehouse Entscheidungsrelevante Daten liegen mit den dazugehörigen Metadaten im Repositorium 26

31 4 Lösung semantischer Konflikte in der Praxis 4 Lösung semantischer Konflikte in der Praxis Sollen mehrere Datenbanken in einem globalen Datenbankschema wie z.b. des Data Warehouse integriert werden, um mit einem Datenbankzugriff globale Analysen durchführen zu können, müssen die vorhandenen Konflikte ermittelt und Schritte zu deren Lösung durchgeführt werden. Die Schema- und Datenkonflikte werden durch notwendige Integrationsschritte und Datentransformationen behoben. Anhand von Beispielen werden nachfolgend verschiedene Konfliktsituationen und adäquate Lösungsansätze betrachtet Schemakonflikte Nachfolgend werden die aufgeführten Schemakonflikte vorgestellt und erläutert: 46 nskonflikte Strukturelle Konflikte Konflikte durch Datenrepräsentation nskonflikte Bei Synonymen handelt es sich um semantisch äquivalente Objekte, bei denen unterschiedliche Bezeichnungen für Attribute und Relationen verwendet wurden. Dieses Problem wird gelöst, indem man in der Zieldatenbank eindeutige Bezeichner festlegt und diese bei der Transformationsphase den Quelldaten zuweist. Entwurfsansicht Quell-Schema 1 Vorname Nachname Ziel-Schema Vorname Nachname Quell-Schema 2 Vorname Zuname Daten- Vorname Nachname Vorname Nachname Vorname Zuname ansicht Saim Sert Saim Sert Resul Taner Resul Taner Abbildung 4.1: Schemakonflikt Synonyme 45 [LENZ98] S [LENZ98] S. 4ff. 27

32 4 Lösung semantischer Konflikte in der Praxis Homonyme entstehen, wenn semantisch unterschiedliche Objekte gleich bezeichnet werden. Dieses Problem wird gelöst, indem man in der Zieldatenbank zwei eindeutige Bezeichner festlegt und diese bei der Transformationsphase den Quelldaten zuweist. Entwurfsansicht Quell-Schema 1 Vname Vorname Verein Ziel-Schema Quell-Schema 2 Vname Daten- Vname Vorname Verein Vname ansicht Taner Resul Taner Resul null Sert null VfB Britz Sert VfB Britz Abbildung 4.2: Schemakonflikt Homonyme Strukturelle Konflikte Identitätskonflikte treten auf, wenn zwei relativ identische Datenbanktabellen bzw. Inhalte über unterschiedliche Primärschlüssel identifiziert werden. Zum Lösen dieses Problems muss ein Primärschlüssel in der Zieldatenbank festgelegt werden. Entwurfsansicht Quell-Schema 1 ID Vname Ziel-Schema ID Vname Quell-Schema 2 Vname Daten- ID Vname ID Vname Vname ansicht 1 Taner Resul 1 Taner Resul 2 Sert Saim Sert Saim Abbildung 4.3: Schemakonflikt Identitätskonflikte 28

33 4 Lösung semantischer Konflikte in der Praxis Mittels Modellierung von Objektbeziehungen durch eigene Tabellen der Objekte und Referenzierung durch Primär-/Fremdschlüsselbeziehung werden in der Regel 1:n Beziehungstypen abgebildet. Diese Lösung verwendet man, um einer Objektausprägung mehrere Ausprägungen des anderen Objekts zuordnen zu können. Damit ist auch sichergestellt, dass in den Relationen keine funktionalen Abhängigkeiten entstehen. Quell-Schema 1 Ziel-Schema Quell-Schema 2 Entwurfsansicht Tabelle Kunde KNr-ID Tabelle Kunde KNr-ID Tabelle Kunde KundenNr Tabelle Kundendaten KNr-ID KundenNr Tabelle Kundendaten KNr-ID KundenNr Daten- KNr-ID KNr-ID KundenNr ansicht Taner 1 Taner 1 Sert 2 Sert 4712 KNr-ID KundenNr KNr-ID KundenNr Abbildung 4.4: Schemakonflikt Objektbeziehungen Fehlende Attribute müssen in der Zieldatenbank angelegt werden, allerdings ist darauf zu achten, dass Null-Werte erlaubt sind. Wenn es in den Tabellen der Quelldatenbanken Attribute gibt, die nur genau in einer der Quelldatenbanken vorkommen, müssen diese Attribute in der Zieldatenbank geführt werden. Entwurfsansicht Quell-Schema 1 Geburtsdatum Geburtsdatum Ziel-Schema Daten- Geburtsdatum Geburtsdatum ansicht Saim Sert Saim Sert Resul Taner null Quell-Schema 2 Resul Taner Abbildung 4.5: Schemakonflikt Fehlende Attribute 29

34 4 Lösung semantischer Konflikte in der Praxis Konflikte durch Datenrepräsentation Es kommt vor, dass in der Datenbankquelle semantisch äquivalente Attribute mit unterschiedlichen Datentypen abgebildet sind. Für die Zieldatenbank muss ein Datentyp festgelegt werden, der beide repräsentieren kann. Die Quelldaten werden mittels einer Konvertierungsfunktion in die Zieldatenbank migriert. Entwurfsansicht Quell-Schema 1 Ziel-Schema Quell-Schema 2 Tabelle Anschrift Tabelle Anschrift Tabelle Anschrift PLZ int[ ] PLZ int[ ] PLZ int[ ] Ort varchar(20) Ort varchar(20) Ort varchar(20) Strasse varchar(20) Strasse varchar(20) Strasse varchar(20) HausNr int[1-999] HausNr char(4) HausNr char(4) Daten- Strasse HausNr Strasse HausNr Strasse HausNr ansicht Berlinerstr 100 Berlinerstr 100 Wienerstr 10F Wienerstr 10F Abbildung 4.6: Schemakonflikt Unterschiedliche Datentypen Wenn in der Quelldatenbank für gleiche Attribute unterschiedliche Wertebereiche festgelegt sind, muss in der Zieldatenbank die Vereinigung gewählt werden. Entwurfsansicht Quell-Schema 1 Ziel-Schema Quell-Schema 2 Tabelle Anschrift Tabelle Anschrift Tabelle Anschrift PLZ int[ ] PLZ int[ ] PLZ int[ ] Ort varchar(20) Ort varchar(20) Ort varchar(20) Strasse varchar(20) Strasse varchar(20) Strasse varchar(20) HausNr int[1-999] HausNr char(4) HausNr char(4) Daten- PLZ Ort PLZ Ort PLZ Ort ansicht Berlin Berlin 1010 Wien 1010 Wien Abbildung 4.7: Schemakonflikt Unterschiedliche Wertebereiche 30

35 4 Lösung semantischer Konflikte in der Praxis Wenn in einer der Quelldatenbanken für einen Attribut Null-Werte zulässig sind, dann müssen in der Zieldatenbank für dieses Attribut auch Null-Werte zulässig sein. Entwurfsansicht Quell-Schema 1 Ziel-Schema Quell-Schema 2 Religion Religion Religion Daten- Religion Religion Religion ansicht Saim Sert islam Saim Sert islam Resul Taner null Resul Taner null Abbildung 4.8: Schemakonflikt Null-Werte Default-Werte können nicht aus den Quelldatenbanken übernommen werden, wenn nicht für alle semantisch äquivalenten Attribute der gleiche Default verwendet wurde. Entwurfsansicht Quell-Schema 1 Ziel-Schema Religion default[ohne] Religion Daten- Religion Religion ansicht Saim Sert islam Saim Sert islam Resul Taner ohne Resul Taner Quell-Schema 2 Abbildung 4.9: Schemakonflikt Default-Werte 4.2 Datenkonflikte Nachfolgend werden die aufgeführten Datenkonflikte vorgestellt und erläutert: 47 Widersprüchliche Datenbankinhalte Unterschiedliche Definitionen von Attributen 47 [LENZ98] S

36 4 Lösung semantischer Konflikte in der Praxis Widersprüchliche Datenbankinhalte Wenn Daten in den Quelldatenbanken nach unterschiedlichen Konventionen abgelegt sind, können die Quelldatenbanken redundante Daten enthalten. Solche Daten lassen sich weitestgehend maschinell korrigieren. Wenn die widersprüchlichen Datenbankinhalte durch Schreibfehler oder unterschiedliches Verändern repliziert vorliegender Daten entstehen, dann muss in den meisten Fällen manuell eingegriffen werden. Quell-Schema 1 Ziel-Schema Daten- ansicht Sert, Saim Saim Sert Saim Sert Taner, Resul Resul Taner Quell-Schema 2 Abbildung 4.10: Datenkonflikt Redundante Daten Unterschiedliche Definitionen von Attributen Wenn Daten in den Quelldatenbanken auf Grundlagen von Maßeinheiten oder Maßstabsfaktoren gespeichert sind, müssen diese bei der Transformation der Daten in die Zieldatenbank berücksichtigt werden. Für die Zieldatenbank muss eine Maßeinheit und ein Maßstabsfaktor fest definiert werden. Entwurfsansicht Entwurfsansicht Quell-Schema 1 Tabelle Mitarbeiter Gehalt (in $) Ziel-Schema Tabelle Mitarbeiter Gehalt (in ) Quell-Schema 2 Tabelle Mitarbeiter Gehalt (in Mio TL) Daten- Gehalt Gehalt Gehalt ansicht Sert 3.500,00 Sert 2.709,61 Taner 2.707,24 Taner 5,00 Abbildung 4.11: Datenkonflikt Maßeinheiten oder Maßstabsfaktoren 32

37 4 Lösung semantischer Konflikte in der Praxis Semantisch äquivalenten Attributen können unterschiedliche Definitionen zugrunde liegen. In der Zieldatenbank muss zur Lösung der Konflikte, soweit es möglich ist, eine feste Definition für die Attribute festgelegt werden. Quell-Schema 1 Tabelle Mitarbeiter Gehalt (brutto) Ziel-Schema Tabelle Mitarbeiter Gehalt (brutto) Quell-Schema 2 Tabelle Mitarbeiter Gehalt (netto) Daten- Gehalt Gehalt Gehalt ansicht Sert 3.500,00 Sert 3.500,00 Taner 4.500,00 Taner 2.400,00 Abbildung 4.12: Datenkonflikt Unterschiedliche Definitionen Die Kategorisierung von Attributen stellt eine besondere Problematik dar. Die Transformation der Quelldaten ist in solchen Fällen nicht immer oder beschränkt möglich. Entwurfsansicht Entwurfsansicht Quell-Schema 1 Ziel-Schema Tabelle Bevölkerung Tabelle Bevölkerung Kinder [1-12] Kinder [1-12] Jugend [13-17] Jugendliche [??-??] Quell-Schema 2 Tabelle Bevölkerung Children [1-12] Teenager [13-20] Daten- Kinder Jugendliche Kinder Jugendliche Children Teenager ansicht ??? ??? Abbildung 4.13: Datenkonflikt Kategorisierung 33

38 5 Zusammenfassung und Fazit 5 Zusammenfassung und Fazit Die Qualität der Daten haben einen enormen Einfluss auf die Entscheidungen eines Unternehmens. Diese Arbeit hat gezeigt, dass Qualitätsmängel in verschiedenen Bereichen und aus verschiedenen Gründen entstehen. Ein Basisproblem ist die Auswahl der geeigneten Daten für das Data-Warehouse-System. Ein weiteres Problem entsteht bei der Festlegung der Qualitätsanforderungen an die Daten durch den Anwender. Daher sollte die Auswahl der Qualitätskriterien, nach denen die Daten bewertet werden, in den zuständigen Fachabteilungen so früh wie möglich festgelegt werden, was jedoch sehr schwer ist. Einige Qualitätsmängel, die schon im Quellsystem vorhanden sind, sind also auf den Benutzer zurückzuführen. Diese Mängel entstehen z. B. durch inkorrekte Dateneingabe oder mangelnde Motivation. Aber auch das Fehlen von Daten in der Quelldatenbank führt zu unverwertbaren Ergebnissen bei der Analyse. Die für die Analysezwecke notwendigen Daten müssen in der Quelldatenbank ergänzt oder gepflegt werden. Da die Datenpflege für die vorhandenen Datensätze nicht immer möglich ist, müssen diese Attribute der Datensätze mit NULL-Werten belegt werden. Ein weiteres, nicht lösbares Problem entsteht, wenn der Anwender eine falsche Eingabe getätigt hat, welches auch durch domänenspezifisches Wissen nicht herausgefunden und bereinigt werden kann. In vielen Fällen ist es unverzichtbar, Transformationen der Daten aus den Quellstrukturen in die Zielstruktur durchzuführen. Hierbei werden die Daten vereinheitlich und in einen geeigneten Zustand gebracht. In der Transformationsphase wird auch versucht unter anderem veraltete oder fehlerhafte Werte durch Plausibilitätsprüfungen oder Record Linkage-Verfahren zu erkennen und zu korrigieren. Auch von hoher Relevanz ist die Gewährleistung der Nachvollziehbarkeit und der Verfügbarkeit der Daten. Abschließend ist noch festzuhalten, dass die einzelnen Mitarbeiter in den Fachabteilungen für die Daten, die in das Data-Warehouse-System gelangen, sensibilisiert und verantwortlich gemacht werden müssen, um eine bessere Datenqualität zu erhalten. 34

39 6 Literaturverzeichnis 6 Literaturverzeichnis [BAUER04] [CHAMONI98] [DIN06] BAUER, Andreas / GÜNZEL, Holger: Data Warehouse Systeme: Architektur, Entwicklung, Anwendung. 2., überarbeitete und aktualisierte Auflage, Heidelberg: dpunkt-verlag, CHAMONI, Peter / GLUCHOWSKI, Peter: Analytische Informationssysteme: Data Warehouse, On-Line Analytical Processing, Data Mining. Berlin u. a.: Springer-Verlag, N. N.: Qualitätsmanagement DIN EN ISO 9000ff.: Qualitätsmanagementsysteme Grundlagen und Begriffe. Berlin, Beuth-Verlag, [GLUCHOWSKI97] GLUCHOWSKI, Peter / GABRIEL, Roland / CHAMONI, Peter: Management Support Systeme: Computergestützte Informationssysteme für Führungskräfte und Entscheidungsträger. Berlin u. a.: Springer-Verlag, [HELFERT00] [HINRICHS02] [INMON02] [JUNG00] HELFERT, Markus: Massnahmen und Konzepte zur Sicherung der Datenqualität. In: JUNG, Reinhard / WINTER, Robert: Data Warehousing Strategie: Erfahrungen, Methoden, Visionen, Berlin u. a.: Springer-Verlag, HINRICHS, Holger: Datenqualitätsmanagement in Data- Warehouse-Systemen. Dissertation, Carl von Ossietzky Universität Oldenburg, INMON, William H.: Building the Data Warehouse. Third Edition, New York: John Wiley & Sons, JUNG, Reinhard / WINTER, Robert: Data Warehousing Strategie: Erfahrungen, Methoden, Visionen. Berlin u. a.: Springer- Verlag, VI