Bewertung von Datenqualität 

Dieser Artikel ist Erfahrungsbericht aus einem Projekt zur Beurteilung der Qualität von Kundendatenbanken. Der darin beschriebene Prozess vereint drei automatisierte Audits: ein Audit des Datenbankschemas, ein Audit der Datenbankstruktur und ein Audit des Datenbankinhalts. Das Audit des Datenbankschemas prüft auf Designmängel und Regelverletzungen. Das Audit der Datenbankstruktur misst die Größe, Komplexität und Qualität des Datenbankmodells. Das Audit des Datenbankinhalts verarbeitet die Daten selbst, um ungültige Datenwerte, fehlende Datensätze und redundante Datensätze aufzudecken. Der Zweck dieser Audits ist es, die Qualität der Datenbank zu bewerten und zu bestimmen, ob ein Daten-Reengineering- oder Datenbereinigungsprojekt erforderlich ist.

Sinkende Datenqualität

Die bestehenden Datenbanken der meisten IT-Anwender sind das Produkt einer langen Entwicklung. Sie begann mit ihrer Konzeption durch einen Datenbankdesigner auf der Basis der damals verfügbaren Informationen. Es folgte die Entwicklung oder die automatische Generierung eines Datenbankschemas, das den Entwurf widerspiegelt. Danach wurde die Datenbank installiert und Anwendungen begannen, sie zu nutzen. Als neue Anwendungen hinzukamen, wurde die Struktur geändert oder erweitert, um sie zu berücksichtigen. Diese Strukturänderungen wurden oft ad hoc vorgenommen, so dass die Komplexität der Struktur wuchs und die Qualität sank, ähnlich wie bei Softwaresystemen nach den Gesetzen der Softwareevolution ¹. Zusätzlich zu dieser strukturellen Verschlechterung wurde der Inhalt der Datenbank durch fehlerhafte Programme, die falsche Werte speicherten und wichtige Datensätze löschten, korrumpiert. Bei großen Datenbanken ist eine solche Qualitätserosion schwer zu erkennen, breitet sich aber mit der Zeit wie ein Krebsgeschwür aus und verursacht immer mehr Systemausfälle. So leidet nicht nur die Programmqualität, sondern auch die Datenqualität unter der Erosion ².

Versäumnis, die Datenentwicklung vorherzusehen

Zu Beginn des Lebenszyklus einer Datenbank muss der Designer Annahmen über die Datenmenge und die Art und Weise, wie die Daten verwendet werden, treffen. Er muss auch vorhersehen, wie sich die Daten entwickeln werden. Der Entwurf der Datenbank basiert auf solchen Annahmen. Die gleichen Annahmen werden in ein Datenbankschema übertragen, in dem die Tabellen definiert und durch Fremdschlüssel und Indizes miteinander verknüpft werden. Wenn sich die Annahmen als richtig erweisen, kann sich die Datenbank ohne Probleme weiterentwickeln. Wenn nicht, wird die Datenbankstruktur bald veraltet sein und die Form wird nicht mehr zum Inhalt passen. Außerdem wird es immer schwieriger, sie anzupassen. Wenn das Datenvolumen viel stärker wächst als erwartet und die Datennutzung sich als ganz anders herausstellt als ursprünglich vorgesehen, wird ein Reengineering der Datenbank notwendig ³.

Fehlende Datenunabhängigkeit

Oft genug können Datenbankdesigner weder das tatsächliche Wachstum einer Datenbank vorhersagen, noch können sie absehen, wie sie wirklich genutzt werden wird. Wenn sie die Datenbank zum ersten Mal entwerfen, entwerfen sie sie wahrscheinlich nur aus der Sicht einer einzelnen Anwendung und selten aus einer globalen Sicht aller möglichen Anwendungen. Die Daten sind also von Anfang an nicht unabhängig von den Anwendungen, die sie nutzen. Später muss die Struktur angepasst werden, um mehr und andere Anwendungen unterzubringen, aber je weiter das Design gedehnt wird, desto brüchiger wird es. Irgendwann ist es für keine der Anwendungen mehr geeignet ⁴.

Verstoß gegen die Normalformen

Jeder provisorische Patch an der Datenbankstruktur hat negative Folgen. Anstatt neue Untertabellen zu erstellen, wenn zusätzliche Attribute benötigt werden, fügt der lokale Datenbankadministrator diese einfach zu bestehenden Tabellen hinzu. Dadurch werden die Zeilen der Datenbanken immer länger und schwieriger zu handhaben. Wenn neue Schlüssel benötigt werden, werden sie als Indizes hinzugefügt. Infolgedessen gibt es immer mehr Indizes. Datengruppen werden zu bestehenden Zeilen hinzugefügt, wodurch die zweite Normalform verletzt wird, und Wiederholungen derselben Datenelemente werden vorgenommen, um die Erstellung neuer Untertabellen zu vermeiden, wodurch das Prinzip der ersten Normalform verletzt wird. Es werden zusätzliche Fremdschlüssel hinzugefügt, die die Anzahl der Abhängigkeiten zwischen den Tabellen erhöhen, und es werden Unterschlüssel zum Primärschlüssel hinzugefügt, die sich oft nicht auf die Zeilen als Ganzes beziehen. Dies kommt einem Verstoß gegen das Prinzip der dritten Normalform gleich. Am Ende entspricht die Datenbank nicht mehr den Normalformen für relationale Datenbanken, was zu einem Qualitätsverlust und einer Erhöhung der Komplexität führt ⁵.

Falsche Verwendung von gespeicherten Prozeduren

Ein weiteres Merkmal, das zum Verlust der Portabilität und Datenunabhängigkeit beiträgt, ist die Verwendung von Stored Procedures. Würden Stored Procedures nur für Zugriffsoperationen und zur Sicherstellung der Integrität der Daten verwendet, wäre dies akzeptabel. Sie werden jedoch oft zur Verarbeitung von Logik missbraucht. Anstatt Geschäftsregeln in separaten Regelmodulen unterzubringen oder Prüfroutinen in den Client-Komponenten zu platzieren, verstecken Entwickler sie in den Stored Procedures, wo sie für die Werkzeuge, die die Programme verarbeiten, nicht mehr sichtbar sind. Stored Procedures voller Selektionen und Schleifen, Sets und Deklarationen sind ein eindeutiges Zeichen für Missbrauch. Sie binden die Datenbank an eine bestimmte Anwendung ⁶.

Inkonsistente und falsche Datenaktualisierungen

Der Inhalt einer Datenbank leidet nicht nur unter Fehlern beim Ausführen der Programme, sondern auch unter inkonsistenten Änderungen. So kann es vorkommen, dass der Typ eines Datenattributs, das in zwei verschiedenen Tabellen enthalten ist, in der einen Tabelle geändert wird, in der anderen aber nicht, oder dass der Wert eines Attributs nicht mehr mit dem Typ dieses Attributs im verwendenden Programm kompatibel ist. Die Frankfurter Börse musste einmal für einen halben Tag geschlossen werden, weil ein ungültiger Wert in der Datenbank zu einem Datenausnahmefehler im Verarbeitungsjob führte ⁷. Leider gibt es viel mehr fehlerhafte Daten in bestehenden Datenbanken, als die Anwender annehmen, und diese fehlerhaften Daten können jederzeit zu einem Systemabsturz führen.

Ein weiteres Problem mit dem Inhalt von Datenbanken sind fehlende und redundante Datensätze. Fehlende Datensätze sind solche, auf die noch verwiesen wird, die aber entweder absichtlich oder unabsichtlich gelöscht wurden. Sie können von einer Anwendung gelöscht worden sein, werden aber von einer anderen noch benötigt. Redundante Datensätze sind solche, die eigentlich gelöscht werden sollten, aber aus irgendeinem Grund nicht gelöscht wurden. Sie verbleiben als Leichen in der Datenbank und belegen wertvollen Speicherplatz, obwohl sie nicht mehr verwendet werden ⁸.

Die hier festgestellten Qualitätsmängel sind nur eine Teilmenge der vielen Qualitätsprobleme bei Anwendungsdatenbanken. Geringe Datenbankqualität ist zu einem wichtigen Anliegen der IT-Anwender geworden und ist die Motivation für die drei in diesem Artikel vorgestellten Prüfverfahren:

• Analysieren des Datenbankschemas
• Messen der Datenbankstruktur
• Validierung des Datenbankinhalts

Statische Analyse von Datenbankschemata

Das Datenbankmodell muss statisch analysiert werden, um Qualitätsmängel zu erkennen sowie die Größe, Komplexität und Qualität der Datenbankstruktur zu messen. Dazu ist ein automatisierter Prüfprozess erforderlich.

Der erste Schritt beim Auditg einer Datenbank ist die statische Analyse des Datenbankschemas mit dem Ziel, Regelverletzungen zu erkennen. Genau wie bei Programmcode müssen auch für Datenbankschema-Code Regeln gelten, um eine gute Kodierungspraxis zu erzwingen⁹. Die Regeln sind zum einen auf die Erfüllung bestimmter Datenqualitätsziele wie Sicherheit, Kompatibilität, Performance und Portabilität ausgerichtet. Andererseits sollen sie das Ändern und Erweitern der Datenbank erleichtern.

Um Regelverletzungen unterschiedlich zu gewichten, ist es notwendig, sie zu klassifizieren. Der Datenbankprüfer unterscheidet zwischen großen, mittleren und kleinen Regelverletzungen. Große Regelverletzungen wie die Verletzung der ersten Normalform sind ein großes Hindernis für die Weiterentwicklung und Wiederverwendung der Daten. Sie können auch zu Fehlern führen. Mittlere Regelverletzungen wie das Überschreiten einer vorgegebenen Größengrenze reduzieren die Modularität und Wartbarkeit der Datenbank. Geringfügige Regelverletzungen wie die Verletzung von Namenskonventionen erschweren die Pflege der Daten und deren Konsistenz mit dem Code. Schwere Mängel werden mit 2, mittlere mit 1 und leichte mit 0,5 gewichtet.

Überprüfen der herstellerspezifischen Merkmale

Es gibt viele Funktionen einer Datenbank, die herstellerspezifisch sind, d. h. sie gehören nicht zum Standard-SQL. Sie sollten mit Vorsicht verwendet werden. Einige Optionen sollten verboten werden, weil sie die Leistung beeinflussen oder die Übertragung der Daten behindern. Andere, wie die NULL-Option, sollten aus den gleichen Gründen obligatorisch sein. Es obliegt dem verantwortlichen Datenbankanalysten, zu bestimmen, welche Funktionen verboten und welche obligatorisch sein sollten.

Prüfen der Normalformen

Das Vermeiden von herstellerspezifischen Merkmalen kann die Leistung verringern, aber es macht die Datenbank unabhängiger vom Hersteller, d. h. die Daten werden portabler. Einen Primärschlüssel in jedem Datensatz zu haben, ist vielleicht nicht von der SQL-Sprache gefordert, aber es kann eine Regel sein, die durchgesetzt werden muss. Ein Fremdschlüssel ist ebenfalls nicht erforderlich, aber wenn die Tabelle von einer anderen Tabelle abhängig ist, sollte mindestens einer definiert werden. Auf keinen Fall sollte eine Tabelle wiederholte Daten desselben Typs oder Untergruppen von Daten haben. Solche offensichtlichen Verstöße gegen die Normalformen können mit Hilfe der statischen Analyse erkannt und als schlechte Praxis identifiziert werden ¹⁰.

Grenzen setzen

Es kann auch Grenzen dafür geben, wie viele Attribute in einem Datensatz erlaubt sind und wie lang eine Zeile sein darf. Es ist notwendig zu prüfen, dass diese Grenzen nicht überschritten werden. Außerdem kann es wünschenswert sein, bestimmte Datentypen wie z. B. gepackte Dezimal-, Binär-, Fließkomma- oder Zeitstempeldaten aus Gründen der Kompatibilität mit Datenbanken eines anderen Herstellers zu verbieten. Inkompatible Datentypen sind eine der Hauptursachen für Fehler bei der Datenmigration ¹¹.

Zusammenfassend kann man sagen, dass es eine Reihe von Regeln für das Design von Datenbanken geben sollte und dass diese Regeln durchgesetzt werden sollten. Typische Regelverstöße sind:

• Eindeutiger Bezeichner fehlt in der Tabelle
• Fremdschlüssel fehlt in abhängiger Tabelle
• Tabelle enthält ein wiederholtes Datenattribut
• Tabelle enthält eine Untergruppe
• Tabelle hat keine externe Sicht definiert
• Tabelle hat keine Indizes
• Primärschlüssel enthält zu viele Unterschlüssel
• Die Option NULL fehlt
• Die Option DELETE fehlt
• Tabelle hat einen inkompatiblen Datentyp
• Anzahl der Attribute überschreitet Maximalgrenze
• Länge der Zeile überschreitet die maximal zulässige Länge
• Schema ist unzureichend kommentiert

Es ist die Aufgabe des Schema-Auditing-Werkzeugs, solche Regeln zu prüfen und deren Verletzung zu melden. Es ist dann die Aufgabe des Datenbankadministrators, das Datenbankschema entsprechend zu korrigieren.

Messen der Datenbankstruktur

Um die Architektur einer Datenbank zu bewerten, muss sie zunächst gemessen werden, um die Bewertung auf solide Zahlen zu stützen. Ohne Zahlen ist es nicht möglich zu vergleichen, und ohne vergleichen zu können, ist es nicht möglich zu beurteilen ¹². Die Messungen einer bestehenden Datenbank können mit denen einer Benchmark-Datenbank oder einfach mit denen einer anderen Datenbank verglichen werden. Datenmessungen können einfache Zählungen sein, oder sie können komplexe Metriken für Größe, Komplexität und Qualität sein ¹³.

Metriken zur Datenbankgröße

Wie bei der Regelprüfung wird ein Werkzeug benötigt, um die Messung durchzuführen, die Datenbankattribute zu zählen und die Metriken zu berechnen. Es gibt mehrere Datenbankattribute, die gezählt werden müssen. In einer SQL-Datenbank sind dies u. a.:

• Zeilen von SQL-Code
• Anzahl der Tabellen
• Anzahl der Attribute
• Anzahl der Tasten
• Anzahl der Ansichten
• Anzahl der Beziehungen
• Anzahl der gespeicherten Prozeduren
• Anzahl der gespeicherten Zugriffsvorgänge
• Anzahl der Stored-Procedure-Anweisungen
• Anzahl der Integritätsregeln
• Anzahl der Regeln für gespeicherte Prozeduren
• Anzahl der Testfälle, die erforderlich sind, um die Datenbank abzudecken

Aus diesen Maßen werden zwei Größenmetriken berechnet:

• Funktionspunkte
• Datenpunkte

Die Funktionspunkte einer Datenbank sind entweder 15, 10 oder 5, abhängig von der Anzahl der Attribute und Schlüssel ¹⁴. Datenbanken mit über 50 Attributen oder 2 Schlüsseln erhalten 15 Funktionspunkte, Datenbanken mit 20 bis 50 Attributen oder mehr als einem Schlüssel erhalten 10 Funktionspunkte, Datenbanken mit weniger als 20 Attributen erhalten 5 Funktionspunkte. Die Datenpunkte sind 1 für jedes Attribut, 2 für jeden Schlüssel und Index, und 4 für jede Ansicht ¹⁵. Diese Metriken werden verwendet, um die Kosten von Evolutionsprojekten vorherzusagen, die Änderungen an den Daten beinhalten.

Metriken zur Datenbankkomplexität

Zusätzlich zu den Größenmetriken sollten auch Komplexitäts- und Qualitätsmetriken berechnet werden. Alle Metriken sind Verhältnismetriken, die aus einer Relation einer Menge von Attributen zu einer anderen abgeleitet sind. Sie werden mit Hilfe von Algorithmen berechnet, die tatsächliche Werte mit Benchmark-Werten vergleichen, die auf empirischen Studien ähnlicher Datenbanken basieren. Für jede Komplexitätsmetrik gibt es eine untere und eine obere Grenze. Die mittlere Komplexität ist das geometrische Mittel aus den beiden Grenzwerten. Die sechs berechneten Komplexitätsmetriken sind:

• Inhaltliche Komplexität als das Verhältnis von Datentypen und Datenschlüsseln zur Anzahl der Datenattribute
• View-Komplexität als das Verhältnis von Views zur Anzahl der Tabellen
• Zugriffskomplexität als Verhältnis der Zugriffspfade zur Anzahl der Zugriffsobjekte Views und Tabellen
• Relationale Komplexität als Verhältnis von Tabellen zu Tabellenbeziehungen zur Anzahl der Tabellen
• Strukturelle Komplexität als das Verhältnis von Strukturelementen (Tabellen, Views und Indizes) zur Anzahl der Basiselemente (Attribute und Schlüssel)
• Speicherkomplexität als Verhältnis der gespeicherten Attribute zur Größe des Speicherbereichs in Bytes

Der gewichtete Durchschnitt dieser sechs Komplexitätsmetriken ergibt die Gesamtkomplexität der Datenbank auf einer Verhältnisskala von 0 bis 1. Das Komplexitätsverhältnis sollte so niedrig wie möglich sein ¹⁶.

Metriken zur Datenbankqualität

Die gewünschten Eigenschaften einer Datenbank sind in der Literatur zu diesem Thema propagiert worden, insbesondere von J-L. Hainaut ¹⁷, Peter Aiken ¹⁸ und Michael Blaha ¹⁹. Diese und andere Autoren betonen die Bedeutung von Datenunabhängigkeit, Datenflexibilität, Zugriffsmöglichkeit und Datenportabilität. Eines der größten Hindernisse für die Software-Migration ist die Verflechtung der Geschäftslogik mit der Zugriffslogik. Eines der größten Hindernisse für die Datenevolution ist die Inflexibilität der Datenbankstruktur. In den 1980er Jahren haben sowohl Dominique Warnier ²⁰ und Michael Jackson ²¹ das datengetriebene Softwaredesign propagiert, eine Methode, bei der die Programmstruktur aus der Datenstruktur abgeleitet wird. Das Ergebnis waren Programme, die die aktuellen hierarchischen und vernetzten Datenmodelle widerspiegelten. Als es an der Zeit war, auf relationale Datenbanken umzusteigen, passten die Programmstrukturen nicht mehr. Sie mussten mit hohem Aufwand neu entwickelt werden. Was einst eine gute Idee war, um eine schnelle Lösung zu finden, entpuppte sich als größtes Hindernis für die Modernisierung der Systeme. Noch heute basiert die Struktur vieler relationaler Datenbanken auf den Anforderungen der ursprünglichen Anwendung. Es war nicht vorgesehen, wie die Daten in Zukunft genutzt werden könnten ²².

Die Lösung für das Problem der Datenunabhängigkeit besteht darin, dass jede Anwendung ihre eigenen Sichten auf die Daten haben sollte. Um dies zu ermöglichen, wurden Views definiert ²³. Natürlich erhöht dies die Komplexität der Datenbank, aber es müssen immer Kompromisse eingegangen werden. Hier ist der Kompromiss zwischen Datenbankunabhängigkeit und Datenkomplexität. Das Gleiche gilt für die Datenzugänglichkeit, die mehr Schlüssel und mehr Indizes erfordert, um auf die Daten auf viele Arten zugreifen zu können. Datenflexibilität impliziert, dass die Datenbank leicht geändert und erweitert werden kann. Dafür sollte es eher viele kleinere Tabellen geben als wenige große. Wie bei der objektorientierten Programmierung führt dies jedoch zu mehr Beziehungen zwischen den Tabellen und damit zu einer höheren Komplexität ²⁴. Speichereffizienz bedeutet, mehr Daten auf weniger Platz zu speichern, aber auch das erhöht die Komplexität. Dies zeigt, dass es kaum einen Weg gibt, die Qualität einer Datenbankfunktion zu erhöhen, ohne eine höhere Komplexität zu verursachen oder die Qualität einer anderen Funktion zu opfern. Dies ist ein Dilemma, das Datenbankdesigner lösen müssen. Das Erreichen einer hohen Qualität bei gleichzeitig geringer Komplexität ist ein Optimierungsproblem, das vom Kontext abhängt, in dem die Daten verwendet werden. Wenn Daten in verschiedenen Kontexten verwendet werden, muss ein bestmöglicher Kompromiss gefunden werden.

Für jede Qualitätsmetrik gibt es auch eine untere und eine obere Grenze, die aus dem Vergleich verschiedener Datenbanken abgeleitet werden. Die mittlere Qualität ist das geometrische Mittel aus dem höchsten und dem niedrigsten Qualitätswert. Die sechs berechneten Qualitäten sind:

• Datenunabhängigkeit als das Verhältnis von Datenansichten und Indizes zur Anzahl der Datentabellen
• Datenzugänglichkeit als Verhältnis der Zugriffswege zur Anzahl der gespeicherten Attribute
• Datenflexibilität als Verhältnis von Tabellen, Schlüsseln und Indizes zur Anzahl der Datenattribute
• Datenspeichereffizienz als das invertierte Verhältnis von gespeicherten Attributen zur Größe des Speicherbereichs in Bytes
• Datenkonformität als Verhältnis von Regelverletzungen zur Anzahl der Schemazeilen

Der gewichtete Durchschnitt dieser Qualitätsmetriken ergibt den Qualitätskoeffizienten für die gesamte Datenbank. Er sollte so hoch wie möglich sein. Nach der Qualitätsmessskala der ISO-Norm 9126 sind Werte über 0,8 ausgezeichnet, von 0,6 bis 0,8 gut, von 0,4 bis 0,6 befriedigend und unter 0,4 unbefriedigend ²⁵.

Validieren des Datenbankinhalts

Die Validierung des Inhalts einer gegebenen Datenbank erfordert ein Orakel ²⁶. Es sollte jemanden oder etwas geben, das festlegt, was in den Spalten einer Tabelle im Allgemeinen und in welcher Zeile im Besonderen stehen soll. Dieses Orakel könnte eine Person, ein Programm, eine interpretierbare Spezifikation oder eine andere Datenbank sein. Eine Person könnte die Datenbank durchsuchen und die Werte jeder Zeile oder ausgewählter Spalten oder ausgewählter Zeilen visuell überprüfen. Es gibt Browser, die dies unterstützen, aber es ist eine sehr mühsame und zeitaufwändige Arbeit, selbst mit einem guten Browser. Bei sehr großen Datenbanken ist es praktisch unmöglich. Daher ist ein automatisierter Datenvalidierungsprozess erforderlich.

Validierung des Dateninhalts mit Hilfe eines angepassten Programms

Eine Alternative ist, ein Programm zu schreiben, das die Datenbank liest und den nächsten Datensatz holt oder Datensätze nach bestimmten Suchkriterien auswählt. Dann wird der Inhalt des Datensatzes mit den im Programm kodierten Regeln oder mit dem Inhalt einer anderen Tabelle verglichen, die als Referenz verwendet wird. Diese Methode ist zweckmäßig, erfordert aber Zeit und Aufwand für die Vorbereitung. Das Programm muss von einem Programmierer geschrieben werden, der die Datenbank kennt und weiß, wie man auf sie zugreift. Darüber hinaus kann diese Lösung auch fehlerhaft sein und muss debugged werden.

Validieren von Dateninhalten mit einem Testskript

Eine andere Alternative ist eine interpretierbare Spezifikation – ein Skript -, das von jemandem, der mit den Daten vertraut ist, leicht zusammengestellt werden kann. Im Skript werden Regeln für die Validierung der Regeln ausgewählter Attribute in ausgewählten Datensätzen formuliert. Dies setzt natürlich voraus, dass der Auditor, der das Skript schreibt, weiß, was in der Datenbank sein soll. Zu seiner Unterstützung kann der Auditor eine andere Datenbank als Vergleichsbasis heranziehen, aber der Auditor muss die Verbindungen zwischen zwei Datenbanken herstellen [^27]. Um eine interpretierbare Spezifikation zu schreiben, braucht der Auditor eine Sprache, mit der er das kann:

• geben an, welche Datensätze mit welchen Schlüsseln in einer Tabelle sein sollen. Die Schlüssel können den Fremdschlüsseln zugehöriger Tabellen entnommen werden,
• angeben, welche Datensätze mit welchen Schlüsseln nicht in einer Tabelle sein sollen. Dies kann erreicht werden, indem Tabellen miteinander verglichen werden,
• den Inhalt einer ausgewählten Spalte in einer Tabelle mit dem Inhalt einer entsprechenden Spalte in einer anderen Tabelle vergleichen,
• Spalten der gleichen Tabelle miteinander vergleichen,
• vergleicht die Werte einer Spalte mit einem gegebenen konstanten Wert,
• die Werte einer Spalte mit einem Wertebereich vergleichen, d.h. Grenzwertanalyse,
• die Werte einer Spalte mit einer Menge von erwarteten Werten, d. h. einer Äquivalenzklasse, vergleichen,
• die Werte einer Spalte mit dem Ergebnis eines arithmetischen oder logischen Ausdrucks vergleichen,
• die Werte einer Spalte mit den verketteten Werten der anderen Spalten und Konstanten vergleichen ²⁷.

Alle oben aufgeführten Asserted-Vergleiche können Gegenstand eines logischen Ausdrucks sein, d. h. sie werden nur ausgeführt, wenn diese Bedingung erfüllt ist. Die Bedingung macht die Werte einer Spalte von den Werten einer anderen Spalte oder vom Primärschlüssel abhängig, z. B.

This_Column E RANGE (1:50) if (Mainkey > 1000); 

Die Art und Weise, wie diese Aussagen formuliert werden können, ist vielfältig. Der Prüfer kann sowohl diskrete Werte als auch Wertebereiche und Äquivalenzklassen, Beziehungen zwischen Datenwerten und Ergebnisse von Berechnungen definieren. Die Assertion-Sprache basiert auf den Schematron-Schemavalidierungsregeln, wie sie im ISO/IEC-Standard 19757 definiert sind ²⁸.

Ausführen der Datenvalidierung

Der Datenprüfer formuliert seine Behauptungen über die Daten in einem Behauptungsskript für jede Datenbanktabelle und übergibt es an den Compiler. Der Compiler prüft die Syntax und bestätigt die Datennamen gegen das Datenbankschema. Wenn Fehler gefunden werden, muss der Prüfer das Skript korrigieren. Ist das Skript korrekt, wird ein Zwischencode generiert, in dem die qualifizierten Datennamen und konstanten Werte referenziert sind. Anschließend wird für jede Zieltabelle ein Validierungslauf gestartet. Der Validierungsjob arbeitet die Zieltabelle sequentiell ab und prüft eine Zeile nach der anderen gegen die vorgegebenen Regeln. Fehlt eine Zeile, ist sie redundant oder enthält sie ungültige Werte, wird sie im Validierungsreport nach Schlüsseln aufgelistet, zusammen mit den erwarteten Werten. Mit diesem Bericht kann der Prüfer fehlerhafte Inhalte leicht erkennen und entsprechende Fehlerberichte erstellen. Die Datenkorrektheitsquote ist das umgekehrte Verhältnis der Anzahl der fehlerhaften Attribute zur Gesamtzahl der Attribute in der Datenbank ²⁹.

Zusammenfassung

Die beiden Ansätze zur Bewertung der Datenqualität wurden bereits in mehreren Mess- und Prüfprojekten mit positiven Ergebnissen eingesetzt. Bislang wurden die beiden Ansätze jedoch noch nie zusammen verwendet. Der Datenbewertungsprozess schlägt vor, die statische Schemaanalyse mit der Validierung der Dateninhalte zu kombinieren ³⁰. Zunächst werden gemeinsam mit den Anwendern die Regeln definiert und die Metriken entsprechend der Anwenderziele gewichtet. Zweitens werden die Datenbankschemata statisch analysiert und die Strukturen vermessen. Drittens werden gemeinsam mit dem Kunden die Validierungsskripte zusammengestellt, basierend darauf, was nach Meinung des Kunden die Werte der Spalten sein sollten. Schließlich werden die Datenbankinhalte untersucht und die Ausnahmen dokumentiert. Danach kann ein Bericht über den Stand der Datenqualität erstellt werden.

Das Ergebnis einer Datenqualitätsbewertung hängt in hohem Maße von der Einstellung der Benchmark-Messwerte und der Gewichtung der Metrikwerte ab. Diese können vor der Ausführung der Messjobs angepasst werden. Der Benutzer kann mehr Wert auf die Zugänglichkeit der Daten und weniger auf die Unabhängigkeit der Daten legen, oder er kann die Flexibilität der Daten für wichtiger halten als die Testbarkeit. Auch kann der Anwender mehr oder weniger tolerant gegenüber verbesserten Dateninhalten sein. Für einen Anwender mag eine Korrektheitsquote von 95 % ausreichend sein, für einen anderen ist nichts unter 100 % akzeptabel.

Diese Prozesse beruhen auf praktischen Erfahrungen aus vielen Projekten der letzten Jahre. Aufgrund des Mangels an Werkzeugen zur Bewertung der verschiedenen Aspekte wächst mit diesen Projekten eine Reihe von selbst entwickelten Werkzeugen. So prüfen z.B. die Werkzeuge DLIAudit, ADAAudit und SQLAudit die Regeln für IMS, ADABAS, DB-2, Oracle und MS-SQL Datenbanken. Das Ergebnis ist ein Mängelbericht über Schemaregelverletzungen. SQLAudit zählt außerdem etwa 35 Datenbankattribute und berechnet 6 Komplexitäts- und 6 Qualitätsmetriken. Alle 12 Metriken sind Verhältnismetriken, die aus einer Relation einer Menge von Attributen zu einer anderen abgeleitet sind. Die Datenbankmetriken werden in Form eines Metrikenberichts gesammelt. Zusätzlich werden sie als XML-Datei exportiert, damit sie von jedem verwendet werden können, der sie z. B. in einer Metrikdatenbank speichern oder weiterverarbeiten möchte. Diese Metriken können die Grundlage für einen Benchmark bilden, ohne den man nichts wirklich auswerten kann. Das Tool Datatest bietet eine auf Prädikatenlogik basierende, in Assertionen ausgedrückte Sprache, mit der der Auditor den Dateninhalt spezifizieren kann. Dies wurde oft für die Validierung des Inhalts verwendet.

Unterm Strich ist Qualität relativ. Sie ist relativ zu den gesetzten Qualitätszielen. Deshalb ist das von Basili und Rombach vor langer Zeit aufgestellte Goal-Question-Metric-Modell immer noch gültig ³¹. Der Anwender muss zuerst Ziele setzen, dann muss er fragen, wie deren Erfüllung zu beurteilen ist und drittens kann er Metriken definieren, um den Grad der Erfüllung zu messen. Diese Methode lässt sich ebenso gut auf die Beurteilung der Datenqualität anwenden. Der Datenanalyst muss zunächst Ziele setzen, Ziele wie Portabilität, Erweiterbarkeit und Flexibilität. Dann müssen Metriken definiert werden, um zu messen, inwieweit sie von der aktuellen Datenbank erfüllt werden. Schließlich müssen sie gemessen und ausgewertet werden. Ohne klar definierte, messbare Ziele ist es nicht möglich, irgendetwas zu beurteilen.

1. Belady, L., Lehman, M.: “A Model of Large Program Development“, IBM Systems Journal, Vol. 15, Nr. 3, 1976
2. Blaha, M./ Premerlani, W.: “Observed Idiosyncracies of relational Database Design”, IEEE Proc. of 2nd WCRE, Toronto, July, 1995, p. 116
3. Premerleni, W./ Blaha, M.: “An Approach for Reengineering of relational databases”, Comm. Of ACM, Vol. 37, No. 5, May, 1994, p. 42
4. Tayi, G.-K./Ballou, D.: “Examining Data Quality”, Comm. Of ACM, Vol. 41, No. 2, Feb. 1998
5. Date, C.J.: An Introduction to Database Systems, Addison-Wesley Pub. , Reading Mass., 1975
6. Redman, T.C.: Data Quality for the Information Age, Artech House, Boston, 1996
7. CW: Computer Weekly, Nr. 26, June 1998, p. 1
8. Yong, J.K./Kishore, R./Sanders, G.L.: “From DQ to EQ – Understanding Data Quality in the Context of E-Business Systems”, Comm. Of ACM, Vol. 48, No. 10, Oct. 2005, p. 75
9. Blaha, M.: “A copper Bullet for Software Quality Improvement”, IEEE Computer, Feb. 2004, p. 21
10. Wand, Y./Wang, R.: “Anchoring Data Quality Dimensions in Ontological Foundations”, Comm. Of ACM, Vol. 39, No. 11, Nov. 1996, p. 86
11. Kaplan, D./Krishnan, R./Padman, R./Peters, J.: “Assessing Data Quality in Accounting Information Systems” in Comm. of ACM, Vol. 41, No. 2, Feb. 1998
12. DeMarco, T.: Controlling Software Projects – Management, Measurement & Estimation, Yourdon Press, New York, 1982
13. Kan, S.H.: Metrics and Models in Software Quality Engineering, Addison-Wesley, Boston, 2001
14. International Function-Point User Group – IFPUG: Counting Practices Manual, Release 4.1. IFPUG, Westerville, Ohio, 1999
15. Sneed, H.: Die Data-Point Methode, Online, Zeitschrift für DV, Nr. 5, May 1990, S. 48
16. Card, D., Agresti, W.: “Measuring Software Design Complexity”, Journal of Systems & Software, Vol. 8, 1988, S. 185
17. Hainaut, J-L.: “Strategies for Data Reengineering”, IEEE Proc. of 9th WCRE, Richmond, Oct. 2002, p. 211
18. Aiken, P.: Data Reverse Engineering, McGraw Hill, New York, 1996
19. Blaha, M.: A Manager’s Guide to Database Technology – building and purchasing better Applications, Prentice-Hall, Englewood Cliffs, 2001
20. Orr, K.: “Data Quality and System Theory” in Comm. of ACM, Vol. 41, No. 2, Feb. 1998
21. Jackson, M.: Principles of Program Design, Academic Press, London, 1975
22. Aiken, P./Muntz,A./Richards,R: “DOD Legacy Systems Reverse Engineering Data Requirements”, Comm of ACM, Vol. 37, No. 5, Feb. 1994, p. 26
23. Brathwaite, K.: Systems Design in a Database Environment, McGraw-Hill, New York, 1989, p. 106
24. Wang, R.: “Total Data Quality Management”, in Comm. of ACM, Vol. 41, No. 2, Feb. 1998
25. ISO/IEC: “Software Product Evaluation – Quality Characteristics and Guidelines for their Use” ISO/IEC Standard ISO-9126, Geneva, 1994
26. Howden, W.: “The Theory and Practice of Functional Testing”, IEEE Software, Vol. 2, No. 5, Sept. 1985, p. 6
27. Fewster, M./Graham, D.: Software Test Automation, Addison-Wesley, Harlow, G.B., 1999
28. ISO/IEC: “Rule-based Validation – Schematron”, ISO-IEC Standard 19757, International Standard Organization, Zürich, 2006
29. Sneed, H.: “Testing a Datawarehouse – an industrial challenge”, IEEE Proc. of TAICPART Workshop, Windsor, G.B., August, 2006, p. 203
30. Sneed, H./Baumgartner,M./Seidl,R.: Software in Zahlen, Hanser Verlag, München/Wien, 2010, S. 197
31. Basili, V., Caldiera, C., Rombach, H-D.: “Goal Question Metric Paradigm”, Encyclopedia of Software Engineering, Vol 1, John Wiley & Sons, New York, 1994, S. 5