Seite 3: Konsistenz und Plausibilität

Inhaltsverzeichnis

Konsistenz und Plausibilität

Bei der Messung der Datenqualität spielen aber auch Konsistenz‐ und Plausibilitätsregeln, die sich aus den aktuell implementierten Geschäftsprozessen ergeben, eine wichtige Rolle. Mit Hilfe von Konsistenzregeln wird im ersten Schritt geprüft, ob Daten innerhalb eines Systems oder systemübergreifend vorhanden und identisch sind. Wenn die Konsistenz gegeben ist, kann man mit Hilfe von Plausibilitätsregeln zusätzlich die inhaltliche Korrektheit der Daten prüfen.

Im Beispiel des Versandhauses müssen Kunden bei ihren Bestellungen eine Zahlungsart – entweder Rechnung oder Lastschrift – angeben. Für Kunden, die sich für das Lastschriftverfahren entschieden haben, muss eine gültige Bankverbindung vorliegen; für Kunden, die per Rechnung zahlen, muss eine gültige Rechnungsadresse existieren.

Konsistenzregeln für das Attribut Zahlungsart könnten also lauten:

1. Wenn (Zahlungsart = Rechnung): Fehler, wenn Rechnungsadresse nicht gefüllt
2. Wenn (Zahlungsart = Lastschrift): Fehler, wenn Bankverbindung nicht gefüllt
3. Wenn (Zahlungsart = nicht gefüllt oder nicht Rechnung oder nicht Lastschrift): Fehler

Einfache Plausibilitätsregeln für die Attribute Rechnungsadresse und Bankverbindung könnten lauten:

1. Rechnungsadresse: Fehler, wenn Postleitzahl keine fünfstellige Zahl ist
2. Bankverbindung: Fehler, wenn Bankleitzahl nicht zwischen 10000000 und 99999999

Sowohl die Konsistenz‐ als auch die Plausibilitätsfehler sollten bei der Datenqualitätsmessung unterschieden und protokolliert werden. Diese können zu Fehlerbildern zusammengefasst werden, die zum Beispiel nach ihren Folgen für Geschäftsprozesse oder nach gleichartigen Bereinigungsmustern zusammengefasst werden können und so die Basis für eine differenziertere Bewertung der aktuellen Datenqualitätslage bilden. Im obigen Beispiel haben beide Plausibilitätsfehler dieselbe Auswirkung – der Kunde kann die bezogenen Waren nicht bezahlen, da er im ersten Fall keine Rechnung erhält und im zweiten Fall eine Abbuchung nicht möglich ist.

Vorgehensmodell für Datenqualitätsmessung

Die vorherigen Abschnitte stellten ein Konzept zur Datenqualitätsmessung vor. Die Abbildung links zeigt, wie eine Umsetzung aussehen kann, und fasst das Vorgehen für den Prozess Datenqualität messen zusammen.

Der erste Schritt stellt den klassischen ETL‐Prozess (Extraction, Transformation, Loading) dar, der in diesem Kontext aus der Extraktion von Daten aus den Produktivsystemen und Homogenisierung der Datenstrukturen innerhalb der Datenqualitätsumgebung besteht. Die Homogenisierung der Datenstrukturen ist ein wichtiger Schritt, da in Unternehmen oft unterschiedlichste Anwendungen und Architekturen zum Einsatz kommen.

So existieren neben dem heute üblichen Einsatz relationaler Datenbank‐Systeme wie Oracle, DB2, MySQL und SQL‐Server vielfach noch Mainframe‐Systeme wie IBMs IMS‐Datenbank, die eine hierarchische Struktur aufweisen. Die Überführung der Daten in eine einheitliche Struktur muss dabei nicht nur logisch korrekt, sondern auch noch hinreichend performant vollzogen werden. Dies kann gerade im Bereich der Datenqualitätsmessungen, in denen ganze Systembestände verglichen werden, aufgrund des hohen Datenvolumens zu einer Herausforderung werden.

Die zweite Aufgabe besteht im Abbilden der Konsistenz‐ und Plausibilitätsregeln als Grundlage für die eigentliche Datenqualitätsmessung. Sind die Daten in einer relationalen Datenbank gespeichert, eignen sich zur Implementierung der Regeln hervorragend SQL‐Statements oder Stored Procedures, da sich die Regeln so fast nahtlos von der fachlichen in die technische Sprache übersetzen lassen und dadurch sehr gut nachvollziehbar und interpretierbar sind.

Im Schritt der eigentlichen Datenqualitätsmessung werden die implementierten Konsistenz‐ und Plausibilitätsregeln auf die Datenbestände angewendet. Das Ergebnis ist die mengenmäßige Verteilung der Fehlerfälle auf die definierten Fehlerbilder, wobei auf die einzelnen Objektinstanzen gleichzeitig mehrere Fehlerbilder zutreffen können. Gleichartige Fehlerkombinationen werden dann in der weiteren Analyse zusammengefasst und die Mengengerüste hierfür ermittelt. Dies ermöglicht zum einen eine Aussage, welche Fehler verstärkt einzeln oder im Verbund mit anderen Fehlern auftreten, was wiederum die Definition von Bereinigungsmaßnahmen erleichtert. Zum anderen können so auch leicht Key Performance Indicators (KPIs) gebildet werden, um zu einer Aussage über den Stand der Datenqualität zu kommen.

Abschließend werden im Reporting die Analyseergebnisse in der gewünschten Form aufbereitet. Bei einer hohen Anzahl an Fehlerkombinationen bieten sich grafische Darstellungen an, die einen schnellen Überblick über die Kernfehler geben. Werden die Datenqualitätsmessungen periodisch – zum Beispiel wöchentlich – ausgeführt, können so sehr schön Zeitverläufe dargestellt werden, aus denen Trends abgeleitet oder Verschiebungen innerhalb der Fehlerbilder erkannt werden können.

Der nachfolgende Proof of Concept stellt dar, wie das hier beschriebene Vorgehen bei einem großen Telekommunikationsunternehmen in der Praxis eingesetzt wurde und was die Herausforderungen in einer realen Projektumgebung sind.