Datenqualität bei Data Warehouse Projekten

Von Kai Simeth

 

Inhalt

 

Inhalt

Einleitung

1 Definition des Begriffs Datenqualität

2 Ursachen und Auswirkungen schlechter Datenqualität für Data Warehouse Projekte

2.1 Ursachen schlechter Datenqualität

2.2 Auswirkungen schlechter Datenqualität

3 Möglichkeiten zur Verbesserung der Datenqualität

3.1 Verbesserung der Datenqualität in der operativen Datenbasis – Total Data Quality Management

3.2 Datenqualitätssicherung bei Data Warehouse Projekten

3.2.1 Systematische Analyse

3.2.2 Verwendung von Metainformationen

3.2.3 Datenverteilungsnetze und Interactive-Analysis-Server

Literaturverzeichnis

 

 

 

Einleitung

Durch stetig wachsenden Konkurrenzdruck in der globalen Marktwirtschaft sind die Unternehmen stark gefordert bessere Analysen ihrer Märkte und Kunden durchführen zu können. Der daraus resultierende Wettbewerbsvorteil kann dabei von entscheidender Bedeutung sein.

Vor diesem Hintergrund ist in den letzten Jahren das Data Warehouse Konzept sehr publik geworden. Die Kernidee des Data Warehousing ist, "entscheidungsrelevante Daten getrennt von den operativen Datenbeständen in besonders problemadäquaten Representationsformen und integriert vorzuhalten".[4] Es "speichert alle relevanten Geschäftsdaten eines Unternehmens oder einer Behörde in einer einzigen integrierten relationalen Datenbank. Dabei werden nicht nur [...] aktuelle Daten gespeichert, sondern auch vergangene, so daß eine historische Sicht möglich ist. [...] Die Daten werden periodisch in regelmäßigen Zeitabständen zusammengeführt und somit nur zu festen Zeitpunkten aktualisiert." [9]

In diesem Zusammenhang wird der Qualität der Daten oft eine zu geringe Aufmerksamkeit geschenkt. Dabei ist die Sicherstellung einer hohen Datenqualität eine essentielle Voraussetzung bei der Erstellung eines Data Warehouse Projekts. Laut einer Studie der Meta Group erfüllen nur 30 Prozent der Data Warehouse Projekte die an sie gestellten Erwartungen, und 20 Prozent waren komplett zum Scheitern verurteilt. Als Grund wird die mangelnde Datenqualität beim Projekt-Management und der Datenbank angegeben. [7]

 

1. Definition des Begriffs Datenqualität

Datenqualität läßt sich am einfachsten definieren als "geeignet für die Verwendung". Dieses sagt jedoch nichts über die Art der Verwendung aus. Bei einer bestimmten Verwendung könnte die Qualität ausreichend sein, für eine andere aber völlig ungenügend. Daraus folgt, daß Datenqualität ein relativer Begriff ist.

Um die Bestimmung der Datenqualität zu erleichtern, weist man den Daten bestimmte Qualitätsattribute zu, die auch als Qualitätsdimensionen der Daten bezeichnet werden können. Die vier wichtigsten Attribute sind:

Betrachtet man als Beispiel die polizeiliche Datenaufnahme nach einem Kriminaldelikt, bedeutet Genauigkeit, daß alle Daten korrekt gesammelt wurden; Vollständigkeit, daß alle relevanten Daten aufgenommen wurden; Konsistenz, daß sie in einem einheitlichen Format aufgezeichnet wurden und die Beziehungen stimmen; sowie Zeitgenauigkeit, daß die Erfassung direkt nach der Straftat erfolgt ist. [8]

Um eine noch genauere Bewertung durchführen zu können, lassen sich noch eine Vielzahl weiterer Dimensionen festlegen: Objektivität, Glaubwürdigkeit, Verfügbarkeit, Sicherheit, Relevanz, Menge, Interpretierbarkeit, Verständlichkeit und einige mehr. [10]

 

2. Ursachen und Auswirkungen schlechter Datenqualität für Data Warehouse Projekte

 

2.1 Ursachen schlechter Datenqualität

Beim Data Warehousing werden notwendigerweise Daten aus vielen verschiedenen Teilen der im operativen Tagesgeschäft verwendeten Datenbanken und anderer Informationsquellen gesammelt, verknüpft und zentral gespeichert. Bei diesem Vorgang kommt der Semantik und der Syntax (Konsistenz) der Daten eine hohe Bedeutung zu. [2]

Unter Semantik versteht man die Interpretation der jeweiligen Daten. "Konkrete Begriffe haben in verschiedenen Fachbereichen völlig unterschiedliche Bedeutungen, so zum Beispiel das Wort ‚Auftragsbestand‘ aus Sicht des Vertriebs oder der Arbeitsvorbereitung. Auch andere Fachtermini werden nicht einheitlich verwendet. Beispiel: ‚Lagerbestand‘ als mengenmäßige und ‚Hauptbuchkonto‘ als wertmäßige Bezifferung des Lagerbestands. Vieles bleibt vage: Gehören Bestellungen mit dem Status ‚offen‘ noch zu den bewertbaren Forderungen? In einen falschen Kontext geraten auch Fachausdrücke: Viele reden über das vermeintlich gleiche, jeder meint aber letztendlich etwas anderes." [1] In diesem Zusammenhang ist es auch wichtig sich über die Bedeutung des Begriffs ‚Information‘ im klaren zu sein: "Bei ‚Information‘ handelt es sich um kontext- und zweckbezogene Daten. Ein ‚Datum‘ beschreibt einen Sachverhalt und ist [...] objektiv. Information hingegen ist subjektiv, spezifisch bezogen auf die Bedürfnisse der Endbenutzer oder Sachbearbeiter. Durch Interpretation, Erkennung und Evaluation wird sie verstanden und zum ‚Wissen‘ [...] umgewandelt [...]." [9]

Bei der Syntax bzw. Konsistenz der Daten ist primär die Speicherart der Daten gemeint. Wie beispielsweise das verwendete Textsystem (ASCII etc.) aber auch z. B. die unterschiedliche Bedeutung der Aussagen ‚zweimal im Monat‘ und ‚alle zwei Wochen‘.

Ein weiterer Unsicherheitsfaktor wird dadurch erkauft, daß es für Data Warehouse Projekte oftmals sinnvoll oder sogar nötig ist, potentiell unsichere, externe Quellen und sogenannte "soft-datas" mit in das Warehouse zu integrieren. Mit "soft-datas" meint man Daten, die nicht direkt zugreifbar und eindeutig in einer Datenbank gespeichert sind und deshalb nur schwer qualifizierbar sind. Beispielsweise Gründe für eine Managemententscheidung, Briefverkehr oder ähnliches. [2]

Der Zeitgenauigkeit, d.h. der zeitgerechten Speicherung und Wiedergabe der Daten, ist ebenfalls eine große Aufmerksamkeit zu widmen, wenn man nicht Gefahr laufen will, daß die Daten ein niedriges Qualitätsniveau erreichen. Ein Datenbestand kann heute noch vollkommen korrekt sein, aber morgen bereits viele Fehler enthalten. Der Grund dafür ist, daß die Daten in einer konstanten Form, unter Annahme bestimmter Umgebungsbedingungen gespeichert sind. Die "echte Welt" ist im Gegensatz dazu keineswegs konstant, und Bedingungen, die gestern noch gültig waren, können heute bereits überholt sein. Dieses Problem tritt in besonders starker Ausprägung bei Daten auf, die nach ihrer Speicherung nur noch selten oder sogar nie mehr verwendet werden. Die Philosophie ist sehr verbreitet, besser alles gleich zu speichern, unter der Vermutung jemand könnte in Zukunft die Daten benötigen. Bei dieser Vorgehensweise werden aber Probleme bezüglich der Datenqualität regelrecht geschaffen.

Um die Informationen überhaupt wahrheitsgemäß in ein Data Warehouse transferieren zu können, ist die Entwicklung eines geeigneten Datenmodells von grundlegender Voraussetzung. Wenn die Planung dieses Modells nicht sorgfältig ausgeführt wird, findet eine Verzerrung der "echten Welt" statt. Dadurch können dann die auf dieser Basis gewonnenen Erkenntnisse ebenfalls irreal sein. Die gleiche Bedingung gilt selbstverständlich auch für die operative Datenbank. [5]

Grundsätzlich ist als wichtige Ursache mangelhafter Datenqualität neben den beschriebenen Problemen Semantik, Syntax, Zeitgenauigkeit und korrektem Datenmodell die unzureichende Beachtung dieser Thematik anzumahnen. Die meisten Unternehmen erkennen erst dann das Problem, wenn das Kind bereits in den Brunnen gefallen ist. Dabei verhält es sich oft ähnlich wie beispielsweise mit Schutzmechanismen des lokalen Netzwerkes. Erst wenn jemand unerlaubt eingedrungen ist und Schaden verursacht hat, wird ernsthaft über Sicherheitssysteme diskutiert. Die anderen oben genannten Qualitätsattribute wie Genauigkeit und Vollständigkeit sind zumeist nur von der Sorgfalt der Datenerfasser abhängig. [8]

 

2.2 Auswirkungen schlechter Datenqualität

Anders als in der operativen Datenbasis, in der mangelhafte Datenqualität zumeist nur Auswirkungen auf das Tagesgeschäft hat, beeinträchtigt sie bei Data Warehous Projekten die Entscheidungsgüte mittel- und langfristiger Planungen. Zwar ist der Schaden ungenügender Datenqualität im täglichen Geschäft, wie z. B. falsche Adressen, Rechnungen, Lieferungen etc., ebenfalls nicht zu vernachlässigen, aber falsche Managemententscheidungen in der mittel- oder gar langfristigen Planung wiegen doch ungleich schwerer. Obwohl natürlich auch zu berücksichtigen ist, daß die operative Datenbank als Basis für das Data Warehouse dient und sich dadurch eventuell vorhandene Fehler in das Entscheidungssystem fortpflanzen.

Letztendlich bewirkt eine ungenügende Qualität der Daten immer einen Anstieg der Kosten. Studien haben ergeben, daß in einem durchschnittlichen Unternehmen mit einer Kostenerhöhung von 8-12% wegen ungenügender Datenqualität zu rechnen ist. Bei Dienstleistungsunternehmen sogar 40-60%. Insbesondere bei strategischen Planungen kann die Überprüfung der getroffenen Entscheidungen erst sehr viel später erfolgen, so daß eine Korrektur in der Regel nicht mehr möglich ist. Da es sich bei längerfristigen Planungen ohnehin nur um Prognosen handeln kann, ist es wichtig, daß die vorhandenen Daten korrekt sind, schließlich bilden sie die Grundlage der Prognose. Im Extremfall bewirkt eine schlechte Datenqualität in den operativen Systemen, daß ein Data Warehouse Projekt von vornherein zum Scheitern verurteilt ist. [6]

Die vielen Ausprägungen, Ursachen und Auswirkungen mangelhafter Datenqualität machen deutlich, daß es gerade in unserem Informationszeitalter unabdingbar ist, sich mit Methoden zu befassen, die die Datenqualität erhöhen und bewahren. Um ein Data Warehouse erfolgreich implementieren zu können, sind diesbezüglich noch besondere Anstrengungen zu unternehmen.

 

3. Möglichkeiten zur Verbesserung der Datenqualität

 

3.1 Verbesserung der Datenqualität in der operativen Datenbasis – Total Data Quality Management

Es ist offensichtlich, daß eine im operativen Geschäft verwendete Datenbank eine bessere Grundlage für ein Data Warehouse Projekt bietet, wenn sie "gesund" ist. Außerdem werden dadurch die erwähnten täglichen Probleme mit falschen Abrechnungsdaten oder ähnlichem minimiert. Aus diesen Gründen wird im Folgenden eine Möglichkeit aufgezeigt, wie das Qualitätsniveau in den operativen Systemen erhöht werden kann.

Das Total Data Quality Management Konzept orientiert sich stark an den bereits weit verbreiteten Qualitätssicherungsmechanismen in Produktionsbetrieben (Total Quality Management, DIN 9000 ff). Zu diesem Zweck werden Daten als Informationsprodukte betrachtet. Die Grundidee dieses Qualitätssicherungsprozesses ist der Total-Data-Quality-Management-Zyklus: definieren, messen, analysieren und verbessern der Datenqualität. Dabei werden die oben beschriebenen Datenqualitätsdimensionen bzw. –attribute als Qualitätskriterien benutzt. Die einzelnen Zyklusschritte werden im folgenden genauer beschrieben.

Definieren:

Zunächst ist es notwendig, die Charakteristiken des Informationsprodukts zu definieren. Dabei sind die Beziehungen und Typausprägungen gemeint. Zu diesem Zeitpunkt besteht noch kein Unterschied zwischen der üblichen Datenmodelldefiniton und der hier beschriebenen Vorgehensweise. Die Visualisierung kann beispielsweise durch ein Entity-Relationship-Diagramm erfolgen.

Im zweiten Schritt werden die Qualitätsanforderungen bestimmt und dem Modell hinzugefügt. Dabei ist zu beachten, daß verschiedene Benutzer (Erfasser, Empfänger, DB-Organisator, etc.) unterschiedliche Ansprüche an die jeweiligen Qualitätsdimensionen haben. Zunächst werden im ER-Modell die Stellen, bei denen eine Qualitätsprüfung nötig ist, markiert und entweder mit den geforderten Qualitätsattributen oder mit "Ö Inspection" beschriftet (siehe auch Abb. 1). "Ö Inspection" bedeutet, daß weitere Anstrengungen wie Datenverifikation oder ähnliches zur Qualitätssicherung unternommen werden müssen. Anschließend werden die festgestellten Qualitätsanforderungen weiter verfeinert, so daß sie objektiver und leichter meßbar werden (siehe auch Abb. 2).Die entsprechenden Funktionen, die benötigt werden um die Datenqualität zu sichern, müssen in der Dokumentation ausführlich beschrieben werden. Beispiele für derartige Funktionen sind doppelte Dateneingabe oder besondere Update-Beschränkungen.

Abb. 1: ER-Diagramm eines Aktienhandelsystems mit hinzugefügten Datenqualitätsattributen.

Abb. 2: Detailliertes Qualitäts-ER-Diagramm des Aktienhandelsystems

Zuletzt muß noch das Informationsverarbeitungssystem detailliert beschrieben werden. Das heißt, welche Wege die Daten bzw. Informationen in der Datenverarbeitung gehen und an welchen Stellen die jeweiligen Qualitätskontrollen durchgeführt werden müssen. Die oben beschriebenen Qualitätsanforderungen werden also in den Verarbeitungsprozeß eingefügt.

Messen:

Zur Messung der Datenqualität müssen zunächst geeignete Metriken aufgestellt werden. Dazu eignen sich in erster Linie die bereits beschriebenen Qualitätsattribute: Genauigkeit, Vollständigkeit, Konsistenz, Zeitgenauigkeit und diverse weitere. Beispiele für derartige Methoden sind prozentualer Anteil von fehlerhaften Adressen oder Zeitpunkt des letzten Updates. Weiterhin muß überprüft werden inwieweit die "Geschäftsregeln", wie z. B. maximales Kreditlimit eines Kunden eingehalten wurden. Die Anzahl der Datenzugriffe oder Updates, sowie die häufigste Datenquelle o.ä. können weitere interessante Meßkriterien sein.

Analysieren:

In dieser Phase werden die erstellten Messungen analysiert, um Datenqualitätsprobleme auszumachen und deren Ursprünge zu erkennen. Dabei können beispielsweise statistische Auswertungsmethoden oder Simulationen zum Einsatz kommen. Außerdem muß kontrolliert werden, ob die Analysefunktionen selbst passend sind, so daß sie auch korrekte Ergebnisse liefern.

Verbessern:

Wenn Datenqualitätsprobleme oder Diskrepanzen zwischen Informationsfluß bzw. Workflow und dem Informationsverarbeitungssystem erkannt werden, muß in die Definitionsphase zurückgekehrt werden, um die entsprechenden Anpassungen vorzunehmen. Dabei sollte eine Kosten-Nutzen-Analyse vorgenommen werden, um die Rentabilität der Änderung zu bestimmen. [10]

Ein durch diese Methoden unterstütztes System bietet ständig einen hohen Qualitätsgrad, so daß zum einen eine viel geringere Fehlerhäufigkeit bemerkbar ist und es sich auch hervorragend zum Data Warehousing eignet.

 

3.2 Datenqualitätssicherung bei Data Warehouse Projekten

3.2.1 Systematische Analyse

In diesem Abschnitt wird davon ausgegangen, daß ein operatives Datenbanksystem im Einsatz ist, das die Basis für ein Data Warehouse Projekt bildet. Dabei werden keine direkten Veränderungen am operativen System durchgeführt. Lediglich bei der Transformation der Daten in das Data Warehouse werden eventuell qualitätsverbessernde Maßnahmen vorgenommen. In der Planungsphase ist es notwendig das ganze Projekt systematisch zu analysieren.

Als erstes sollte Klarheit darüber herrschen, welche Unternehmensaktivitäten das Data Warehouse unterstützen soll und welche Prioritäten diese besitzen. Unternehmensaktivitäten sind hier beispielsweise Marketingstrategie, Produktionsplanung oder Produkt- und Verkaufsmanagement. Es wird hier angenommen, daß nur beschränkte finanzielle Mittel zur Realisierung des Data Warehouse Projektes zur Verfügung stehen und deshalb eventuell nicht alle theoretisch möglichen Funktionen in das Data Warehouse integriert werden können. Für die Erhöhung der Datenqualität werden dann im Zweifelsfall die Aktivitäten mit höherer Priorität bevorzugt.

Der nächst Schritt ist die Bestimmung der benötigten Datenquellen. Mit Datenquellen sind sowohl Datenbanktabellen und "klassische Dateien" als auch Aggregationen externer Daten jeglicher Art gemeint. Dabei ist es möglich, daß gewisse Daten noch nicht existieren, diese aber mit vertretbarem Aufwand und Kosten erstellt werden können. Weiterhin ist es wichtig zu bemerken, daß eine Datenquelle gleichzeitig mehrere Unternehmensaktivitäten unterstützen kann.

Zuletzt muß eine Bestimmung der Qualitätsmängel erfolgen und zwar sowohl der existierenden, als auch der potentiell möglichen. Zu diesem Zweck bedient man sich wieder der verschiedenen Dimensionen der Datenqualität. Dabei ist auch zu berücksichtigen, daß eine Datenquelle gleichzeitig in mehreren Qualitätsdimensionen Mängel aufweisen kann.

In diesem Zusammenhang ist ein systematisches Vorgehen anzuraten. Folgende Metriken sollen den Entwicklungsprozeß eines Data Warehouses unterstützen:

Diese Metriken werden im Folgenden näher beschrieben. Dabei ist stets zu berücksichtigen, daß ein Projekt zur Qualitätserhöhung sich auf eine Datenquelle und eine bestimmte Qualitätsdimension bezieht. Es ist jedoch nicht ausgeschlossen, daß durch ein Projekt zur Erhöhung des Qualitätsniveaus einer bestimmten Dimension und Datenquelle eine andere Dimension oder Datenquelle positiv oder auch negativ beeinflußt wird. Das heißt, daß eine isolierte Betrachtung der Projekte nicht möglich ist, sondern immer die Auswirkungen auf die anderen Attribute und Datenquellen zu bestimmen ist.

Aktuelle Qualität:

Hierbei sind alle Datenquellen mit den verschiedenen Qualitätsdimensionen zu bewerten. Es handelt sich dabei um den aktuellen Stand, bevor ein Projekt zur Qualitätsverbesserung durchgeführt wurde.

Benötigte Qualität:

Unter Berücksichtigung der gewünschten Unternehmensaktivitäten werden wiederum alle Datenquellen mit den verschiedenen Qualitätsdimensionen bewertet. In diesem Zusammenhang wird allerdings die minimal benötigte Qualität bestimmt, unabhängig von der aktuell existierenden. Das heißt, daß Qualitätsverbesserungen nur dort vorgenommen werden müssen, wo die aktuelle Qualität kleiner der benötigten ist. Ferner kann die Datenqualität - wenn nötig - verringert werden, sollte das bereits vorhandene Qualitätsniveau höher als das geforderte sein.

Erwartete Qualität nach bestimmter Qualitätserhöhungsoperation:

Wiederum werden die verschieden Datenquellen mit ihren Qualitätsdimensionen bewertet. Diesesmal allerdings unter der Annahme, daß ein bestimmtes Projekt für eine Qualitätsverbesserung durchgeführt wird. Daraufhin sind genaue Vergleiche mit der benötigten Qualität möglich.

Priorität der Unternehmensaktivität:

Es ist empfehlenswert, jeder Unternehmensaktivität, die das Data Warehouse unterstützen soll, eine Priorität zuzuweisen. Wenn die anderen Entscheidungsfaktoren keinen eindeutigen Schluß zulassen, ist der Unternehmensaktivität mit der höchsten Priorität der Vorzug zu geben.

Kosten der bestimmten Qualitätserhöhung:

Wenn ein Projekt zur Erhöhung der Datenqualität durchgeführt wird, ist dieses immer mit einem bestimmten Aufwand und somit auch mit Kosten verbunden. Beispiele für derartige Projekte sind etwa Verringerung von semantischen oder syntaktischen Problemen. Alle theoretisch möglichen Projekte werden finanziell bewertet. Dabei ist zu beachten, daß ein Qualitätsniveau von 100% in der Regel nicht, oder nur mit unverhältnismäßig hohem Aufwand zu realisieren ist. Aus diesem Grund sollte stets das minimal benötigte Qualitätsniveau das Ziel darstellen.

Nutzen der bestimmten Qualitätserhöhung:

Dieser Faktor bietet neben den Kosten die eigentliche Entscheidungshilfe, welche qualitätssteigernden Projekte durchgeführt werden sollen. Dabei wird für jede Unternehmensaktivität und dessen Datenquellen mit den entsprechenden Qualitätsdimensionen der Nutzen angegeben, der erzielt würde, wenn ein bestimmtes Projekt zur Erhöhung der Datenqualität durchgeführt werden würde. Der Nutzen kann einen positiven Wert besitzen, wenn das Projekt den Nutzen steigert, aber auch einen negativen, wenn sich der Nutzen verringert. Dadurch werden die Auswirkungen eines Projekts auf alle Unternehmensaktivitäten und sämtliche Qualitätsdimensionen deutlich. In der Regel wirkt sich ein qualitätssteigerndes Projekt aber auf eine sehr begrenzte Anzahl von Aktivitäten oder Qualitätsattributen aus, so daß der Nutzen bei den meisten Elementen Null ist.

Mit Hilfe dieser Bewertungsmethoden kann unter Berücksichtigung des vorhandenen Budgets eine Auswahl getroffen werden, welche qualitätserhöhende Maßnahmen unternommen werden sollten, um das geforderte Qualitätsniveau möglichst preiswert zu erreichen. Bei größeren Data Warehouse Projekten ist es eventuell nötig Verfahren der Linearen Optimierung anzuwenden, um den optimalen "Projekt-Mix" zu erhalten. [2]

3.2.2 Verwendung von Metainformationen

Durch den Einsatz von Metadaten, d.h. Daten oder Informationen über die eigentlichen Daten, können einige Qualitätsprobleme gelöst werden. Dadurch können insbesondere semantische Unstimmigkeiten oder Unklarheiten über die Herkunft der Daten vermieden werden. Um dieses zu erreichen werden die Daten beispielsweise durch Repository-Systeme oder neuerdings mittels XML näher beschrieben. [1]

"Aus archivischer Sicht sollte beim Aufbau und der Verwaltung eines Data Warehouses [...] vor allem bezüglich der Bewertung, Kassation und Aufbewahrung der Informationen Priorität eingeräumt werden. Evidenzwert hat dabei genauso viel Gewicht wie Informationswert; Kontext ebensogroße Bedeutung wie Inhalt. [...] Evidenz kann nicht nachträglich eingebaut werden, sondern muß während des laufenden Arbeits- und Entscheidungsverfahrens einen objektiven und beweisgebenden Niederschlag in Archivdokumenten und Akten finden.[...] Via Metadaten können die Bewertungs- und Kassationsentscheide nicht nur gesteuert, sondern auch bleibend dokumentiert werden. Sie ‚geben unter anderem Auskunft über den Zusammenhang der Daten im zentralen Lagerhaus zu den Originaldaten im Quellsystem sowie über Format, Typ und Speicherort‘. Sie sind die ‚strukturgebenden‘ Elemente und die ‚brückenbildenden‘ Schnittstellen in und zwischen Beständen und Systemen. [...] Metadaten gestatten den aktuellen Zugriff auf die Daten quer durch das interne System hin und ebenso auf Daten außerhalb der eigenen Organisation. Zudem gewähren sie die langfristige Zugänglichkeit der aufzubewahrenden Informationen." [9]

3.2.3 Datenverteilungsnetze und Interactive-Analysis-Server

Ein Versuch die Lösung der beschriebenen Qualitätsprobleme weitesgehend zu automatisieren, ist der Einsatz sogenannter "Interactive-Analysis-Server". Zu diesem Zweck muß man "zunächst ein oder mehrere Datenverteilungsnetze, sogenannte Hubs, errichten, ferner den Zugang zu Data-Marts standardisieren sowie durch Implementierung von Interactive-Analysis-Servern die entscheidende Grundlage für ein Decision-Support-System legen."

Einen Hub kann man als einen "klar definierten Speicher für saubere und konsistente Daten aus einem oder mehreren operationalen Systemen" bezeichnen, der für die Datenbereitstellung im unternehmensweiten Netzwerk zuständig ist. Sie sollen "die Konflikte, die sich aus verschiedenen Datenkonsolidierungen ergeben vergessen machen." Ferner achten sie darauf, "daß Daten an veränderte Geschäftsverhältnisse angepaßt werden können, etwa historische Daten im Kontext einer Reorganisation von Verkaufsregionen [...]". Metadaten, wie oben bereits beschrieben, kommen in den Hubs ebenfalls zum Einsatz.

Der Interactive-Analysis-Server "regelt die Komplexität der Datenanalyse und sorgt dafür, daß jeder Anwender jene Informationen erhält, die er benötigt. Forrester Research rechnet damit, daß diese Softwareklasse in den nächsten drei Jahren von sich reden machen wird." Sie soll in Zukunft vor allem eine große Konkurrenz für Enterprise Resource Planning Werkzeuge (ERP) werden. [1]

Grundsätzlich ist aber zu bemerken, daß es sich dabei nicht um einen vollständigen Ersatz der oben beschriebenen Qualitätssicherungsmethoden handelt, sondern lediglich um ein unterstützendes Werkzeug.

Die gravierenden Auswirkungen mangelhafter Datenqualität – insbesondere auf Data Warehouse Projekte – zeigen, daß dies kein Thema ist, das heutzutage noch vernachlässigt werden darf. Mit den beschriebenen Lösungsmöglichkeiten sollte es möglich sein, ein System mit hohem Qualitätsniveau aufzubauen.

 

Literaturverzeichnis

 

  1. Autor unbekannt: Data Warehouse / Ein Datenfriedhof ist keine Informationsquelle, in Computerwoche 13/99, entnommen aus Online-Archiv: http://www.dv-markt.de

  2. Ballou, D. P. und Tayi, G. K.: Enhancing Data Quality in Data Warehouse Environments, in Communication of the ACM, Vol. 42 No. 1, Jan. 1999, S. 73-78

  3. Henkel, Norbert: Data-Warehouse / Ohne System gleicht strategisches Planen russischem Roulette, in Computerwoche 13/99, entnommen aus Online-Archiv: http://www.dv-markt.de

  4. Müller, Jochen: Transformation operativer Daten zur Nutzung im Data Warehouse, http://www.winf.ruhr-uni-bochum.de/winf/orga/mueller/transformation.htm

  5. Orr, K.: Data Quality and Systems Theory, in Communications of the ACM, Vol. 41 No. 2, Feb. 1998, S. 66-71

  6. Redman, T. C.: The Impact of Poor Data Quality on the Typical Enterprise, in Communications of the ACM, Vol. 41 No. 2, Feb. 1998, S. 79-82

  7. Regler, Gaby: Data-Warehouse / Data-Warehouse auf den Begriff gebracht, in Computerwoche 13/99, entnommen aus Online-Archiv: http://www.dv-markt.de

  8. Tayi, G. K. und Ballou, D. P.: Examining Data Quality, in Communications of the ACM, Vol. 41 No. 2, Feb. 1998, S. 54-57

  9. Toebak, Peter: Das Data Warehouse Konzept und die Archiv- und Dokumentationspraxis. Probleme und Chancen, http://www.trialog.ch/publikationen/datawarehouse.htm

  10. Wang, R. Y.: A Product Perspective on Total Data Quality Management, in Communications of the ACM, Vol. 41 No. 2, Feb. 1998, S. 58-65