Masterarbeit Regelsysteme zur Datenqualitäts

..
..
....
...........
..
............
...
...
..
Regelsysteme zur Datenqualitätsverbesserung medizinischer
Informationssysteme: Frontend
..
...
....
............
Masterarbeit
Mihael Gorupec
............
....
...
..
Lehrstuhl für Informatik 6
(Datenmanagement)
Department Informatik
Technische Fakultät
Friedrich AlexanderUniversität
Erlangen-Nürnberg
..
.
..
..
..
..
..
..
..
..
...
..
.
...
...
...
...
...
..
....
..
.
.
....
.
...
....
...
....
......
.....
.......
......
........
.......
.
.
.
.
.
.
.........
.
.............
.........
......................................................
Regelsysteme zur Datenqualitätsverbesserung medizinischer
Informationssysteme: Frontend
Masterarbeit im Fach Informatik
vorgelegt von
Mihael Gorupec
geb. 13.03.1987 in München
angefertigt am
Department Informatik
Lehrstuhl für Informatik 6 (Datenmanagement)
Friedrich-Alexander-Universität Erlangen-Nürnberg
Betreuer: Prof. Dr. Richard Lenz
Dipl.-Inf. Gregor Endler
Beginn der Arbeit: 07.03.2013
Abgabe der Arbeit: 31.01.2014
Erklärung zur Selbständigkeit
Ich versichere, dass ich die Arbeit ohne fremde Hilfe und ohne Benutzung anderer als der
angegebenen Quellen angefertigt habe und dass diese Arbeit in gleicher oder ähnlicher
Form noch keiner anderen Prüfungsbehörde vorgelegen hat und von dieser als Teil einer
Prüfungsleistung angenommen wurde. Alle Ausführungen, die wörtlich oder sinngemäß
übernommen wurden, sind als solche gekennzeichnet.
Der Universität Erlangen-Nürnberg, vertreten durch den Lehrstuhl für Informatik 6
(Datenmanagement), wird für Zwecke der Forschung und Lehre ein einfaches, kostenloses, zeitlich und örtlich unbeschränktes Nutzungsrecht an den Arbeitsergebnissen der
Masterarbeit einschließlich etwaiger Schutzrechte und Urheberrechte eingeräumt.
Erlangen, den 31.01.2014
(Mihael Gorupec)
Kurzfassung
Regelsysteme zur Datenqualitätsverbesserung
medizinischer Informationssysteme: Frontend
In dieser Arbeit wurde die Bedeutung von Datenqualität analysiert und untersucht wie
diese gemessen und verbessert werden kann. Dazu wurde auf Basis von TDQM ein
konkretes Konzept herausgearbeitet und hinsichtlich seiner praktischen Umsetzbarkeit
bewertet.
Als Referenz wurde in dieser Arbeit der Kontext medizinischer Versorgungszentren angenommen. Eine Analyse von Referenzunternehmen aus diesem Bereich zeigte erhebliche
Mängel in der Verfolgung effektiver Datenqualitätsstrategien auf. Zur Verbesserung dieses
Zustands wurde prototypisch ein Datenqualitätswerkezug konzipiert, dass Anwendern,
ohne informatischem Fachwissen, ermöglicht eigenständig Datenqualitätsregeln aufzustellen. Das Werkzeug erlaubt die Integrierung von in den Referenzunternehmen bestehenden
sowie die Formulierung von neuen komplexeren Regeln. Es ermöglicht eine kontinuierliche und automatisierte Überprüfung der Datenqualitätsregeln, die Spezifizierung von
Aktionen bei Erfüllung der Regeln sowie die Betrachtung regelverletzender Datensätze.
Durch die fortlaufende Überwachung wird ein erneutes unbemerktes Absinken der Qualität verhindert und eine nachhaltige Verbesserung der Datenqualität ermöglicht. Das
Werkzeug bietet den Anwendern in allen Phasen des TDQM Unterstützung und trägt so
zu einem effektiven Datenqualitätsmanagement bei.
Abstract
Rule systems for data quality improvement of
medical informationsystems: Frontend
This thesis analyzed the importance of data quality and described methods for its
assessment and improvement. A concrete concept for the improvement of data quality
was developed on the basis of TDQM and evaluated according to its practicability.
The context of medical supply centers was assumed as practical reference for this
thesis. Analysis of representative organizations in the mentioned area showed significant
challenges with data quality problems and a lack of effective data quality policies. A
prototypical application was developed as part of this thesis, to propose a solution to
the aforementioned problems in the analyzed medical supply centers. The developed
data quality tool enables users without computer science background to specify data
quality rules. It allows the integration of existing data quality rules in the representative
organizations as well as the specification of more complex new rules. It further allows for
a continuous monitoring of data quality, the definition of actions triggered by violation of
the rules, as well as the inspection of rule-violating data records. This approach prevents
a new unnoticed regression and allows for a sustainable improvement of data quality.
The tool provides support in all phases of TDQM and contributes to an effective data
quality management.
Inhaltsverzeichnis
1 Einführung
1.1 Zielsetzung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.2 Datenqualität in medizinischen Informationssystemen . . . . . . . . . . .
1.3 Methodik . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2 Datenqualität
2.1 Dimensionen . . . . . . . . . . . . . . . .
2.1.1 Genauigkeit . . . . . . . . . . . .
2.1.2 Vollständigkeit . . . . . . . . . .
2.1.3 Konsistenz . . . . . . . . . . . . .
2.1.4 Zeitbezogene Dimensionen . . . .
2.1.5 Weitere Dimensionen . . . . . . .
2.1.6 Zusammenfassung . . . . . . . . .
2.2 Managementansätze . . . . . . . . . . .
2.2.1 Total Data Quality Management
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
3 Regelsysteme
3.1 Business Rules . . . . . . . . . . . . . . . . . .
3.2 Regelbasierte Systeme . . . . . . . . . . . . .
3.2.1 Architektur . . . . . . . . . . . . . . .
3.2.2 Bewertung von regelbasierten Systemen
3.3 Regeln in Relationalen Datenbanken . . . . .
3.3.1 Schlüsselintegrität . . . . . . . . . . . .
3.3.2 Referenzielle Integrität . . . . . . . . .
3.3.3 Typintegrität . . . . . . . . . . . . . .
3.3.4 CHECK-Beschränkungen . . . . . . . .
3.3.5 Assertions . . . . . . . . . . . . . . . .
3.3.6 Aktive Regeln . . . . . . . . . . . . . .
3.4 Regeln in NoSQL Datenbanken . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
1
1
2
3
.
.
.
.
.
.
.
.
.
5
5
6
7
8
8
9
10
11
12
.
.
.
.
.
.
.
.
.
.
.
.
15
15
16
17
19
20
22
22
23
24
24
25
28
I
4 Datenqualitätsverbesserung
4.1 Definition und Messung von Datenqualität . . . . . . . .
4.1.1 Auswahl von Dimensionen . . . . . . . . . . . . .
4.1.2 Metriken zur Messung von Datenqualität . . . . .
4.1.3 Fazit . . . . . . . . . . . . . . . . . . . . . . . . .
4.2 Analyse und Verbesserung von Datenqualität . . . . . . .
4.2.1 Maßnahmen zur Verbesserung von Datenqualität
4.2.2 Verbesserung von Datenqualitätsdimensionen . .
4.3 Zusammenfassung . . . . . . . . . . . . . . . . . . . . . .
5 Entwicklung eines Prototypen
5.1 Anforderungsanalyse . . . . . . . . . . .
5.1.1 Fragebögen . . . . . . . . . . . .
5.1.2 Interviews . . . . . . . . . . . . .
5.1.3 Funktionale Anforderungen . . .
5.1.4 Nicht Funktionale Anforderungen
5.2 Architektur . . . . . . . . . . . . . . . .
5.2.1 Programmiersprache . . . . . . .
5.2.2 Grobarchitektur . . . . . . . . . .
5.2.3 Anfragehandling . . . . . . . . .
5.2.4 Regelerstellung und Verwaltung .
5.2.5 Regelmonitoring und Ausführung
5.2.6 Benutzerschnittstelle . . . . . . .
5.3 Evaluation . . . . . . . . . . . . . . . . .
5.3.1 Funktionsanalyse . . . . . . . . .
5.3.2 Laufzeitanalyse . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
29
29
30
31
39
40
40
48
50
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
53
53
53
55
56
58
59
60
60
63
64
66
70
74
75
77
6 Zusammenfassung und Ausblick
85
Literaturverzeichnis
87
Abbildungsverzeichnis
2.1
Der TDQM-Kreis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
12
3.1
3.2
Architektur eines Regelsystems . . . . . . . . . . . . . . . . . . . . . . .
Ein Fremdschlüsselverweis . . . . . . . . . . . . . . . . . . . . . . . . . .
17
23
4.1
4.2
Maßnahmen Portfolio [Red97] . . . . . . . . . . . . . . . . . . . . . . . .
Das Verbesserungs-Konzept . . . . . . . . . . . . . . . . . . . . . . . . .
47
50
5.1
5.2
5.3
5.4
5.5
5.6
5.7
5.8
5.9
5.10
5.11
5.12
5.13
5.14
5.15
5.16
5.17
5.18
5.19
5.20
5.21
5.22
Vorkommen von Datenqualitätsproblemen . . . . . . . . . .
Auswirkungen von Datenqualitätsproblemen . . . . . . . . .
Eine Regel im medizinischen Versorgungszentrum . . . . . .
Das MVC-Architekturmuster [Wik] . . . . . . . . . . . . . .
Grobarchitektur . . . . . . . . . . . . . . . . . . . . . . . . .
Anfragehandling . . . . . . . . . . . . . . . . . . . . . . . . .
Aufbau von Regeln . . . . . . . . . . . . . . . . . . . . . . .
Regelerstellung . . . . . . . . . . . . . . . . . . . . . . . . .
Regelmonitoring . . . . . . . . . . . . . . . . . . . . . . . . .
Quartzmanagement . . . . . . . . . . . . . . . . . . . . . . .
Benutzerschnittstelle . . . . . . . . . . . . . . . . . . . . . .
Die Formulierung der Kondition . . . . . . . . . . . . . . . .
Das Spezifizieren einer Aktion . . . . . . . . . . . . . . . . .
Ein Validierungsfehler . . . . . . . . . . . . . . . . . . . . .
Regelerstellung . . . . . . . . . . . . . . . . . . . . . . . . .
Laufzeit bei 100 Regeln (SQL-basiert) . . . . . . . . . . . . .
Laufzeit bei 300.000 Tupeln (SQL-basiert) . . . . . . . . . .
Dauer der Faktenbasis-Initialisierung . . . . . . . . . . . . .
Laufzeit bei 100 Regeln (Drools-basiert) . . . . . . . . . . .
Laufzeit bei 10.000 Tupeln (Drools-basiert) . . . . . . . . . .
Speicherauslastung der JVM bei 100 Regeln (Drools-basiert)
Vergleich der Laufzeiten bei 100 Regeln . . . . . . . . . . . .
54
54
56
61
62
63
64
65
66
68
71
72
73
73
74
79
79
80
80
81
82
82
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
III
5.23 Vergleich der Laufzeiten bei 10.000 Tupeln . . . . . . . . . . . . . . . . .
83
Tabellenverzeichnis
2.1
Datenqualitätsdimensionen nach Wang und Strong [WS96] . . . . . . . .
10
4.1
Voraussetzungen für die Messbarkeit von Datenqualitätsdimensionen
. .
39
5.1
5.2
5.3
Vergleichsoperatoren . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Logische Operatoren . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Andere Möglichkeiten bei der Formulierung von Konditionen . . . . . . .
75
76
76
V
Abkürzungsverzeichnis
API
Application Programming Interface
Ajax
Asynchronous JavaScript and XML
ACID
Atomicity, Consistency, Isolation, Durability
DBMS
Datenbankmanagementsystem
ECA
Event-Condition-Action
JVM
Java Virtual Machine
MVC
Model-View-Controller
SMTP
Simple Mail Transfer Protocol
TDQM
Total Data Quality Management
TIQM
Total Information Quality Management
VII
1 Einführung
Elektronische Daten sind heutzutage allgegenwärtig und spielen eine kritische Rolle bei
der Planung von Strategien und dem Treffen von Entscheidungen sowohl in wirtschaftlichen, wissenschaftlichen als auch in staatlichen Bereichen [BCFM09]. Datenqualität
hat weitreichende Bedeutung für die Effizienz und Effektivität von Organisationen und
Unternehmen [BS06]. Damit verbunden ist die zunehmende Bedeutung in der Bewertung
und Sicherstellung von Qualitätsstandards in Zusammenhang mit elektronischen Daten.
Trotz der offensichtlichen Wichtigkeit von elektronischen Daten geht aus einer Studie
der Omikron Data Quality GmbH hervor, dass sich in den Kundendaten der meisten
Unternehmen Fehler im großen Umfang verbergen [Omi07]. An der Studie aus dem
Jahre 2007 nahmen 400 Unternehmen mit mehr als 50 Millionen Euro Jahresumsatz
teil. Die Hälfte der Befragten gab eine Fehlerquote von mindestens 20% an. Bei jedem
sechsten Unternehmen überstieg die Fehlerquote dabei 30%. Nur 7% der Teilnehmer
gaben an, vollständige und fehlerfreie Kundeninformationen zu besitzen. Als Grund
für diesen Zustand wurde an erster Stelle, unter rund 70% der Befragten, mangelndes
Datenqualitätsbewusstsein genannt. An zweiter Stelle lag mit rund 66% Nennungen das
Nichtvorhandensein einer zentralen verantwortlichen Instanz für Datenpflege. Mit 60%
als drittwichtigster Grund wurde das Nichtvorhandensein technischer Lösungen für eine
automatisierte Datenpflege angegeben.
Diese Ergebnisse zeigen, dass große Defizite bei der Einhaltung von Datenqualitätsstandards bestehen. Dabei können Datenqualitätsfehler bedeutende Folgen nach sich
ziehen. Allein in den USA verursachen Datenqualitätsprobleme jährlich Kosten in Höhe
von 600 Milliarden Dollar [Eck02].
1.1 Zielsetzung
Aufgrund der beschriebenen Problematik soll im Rahmen dieser Arbeit ein Konzept zur
Messung und Verbesserung von Datenqualität gefunden werden sowie ein Datenqualitätswerkzeug zur automatisierten Datenpflege entworfen und implementiert werden.
1
1 Einführung
Dabei werden medizinische Informationssysteme als Domäne angenommen. Das Datenqualitätswerkzeug wird daher speziell auf die Anforderung dieses Bereiches angepasst.
Der Bezug auf medizinische Informationssysteme ist allerdings beispielhaft zu verstehen.
Das zu entwickelnde Konzept und das Datenqualitätswerkzeug sollen auch in anderen
Kontexten unter minimalen Anpassungen anwendbar sein.
Die spezifische Problematik der Datenqualität in medizinischen Informationssystemen
soll folgend kurz vorgestellt werden.
1.2 Datenqualität in medizinischen
Informationssystemen
Im Gesundheitswesen besteht der gegenwärtige Trend des Zusammenschließens mehrerer individueller Praxen zu medizinischen Versorgungszentren [HAE09]. Dies hat die
Erhöhung der Konkurrenzfähigkeit zum Ziel. Die Versorgungszentren können durch die
Zusammenlegung von Ressourcen unter anderem Kosten einsparen und Kunden einen
vielfältigeren Service anbieten [EBL13].
Diese Zusammenschlüsse führen zu der Notwendigkeit einer zentralen administrativen Instanz, den Praxismanagern. Praxismanager sind für die Ressourcenplanung
und Unternehmenssteuerung verantwortlich. Außer an das Personal ergeben sich auch
neue Herausforderungen an die informationstechnologische Infrastruktur. Praxismanager benötigen für ihre Aufgaben einen einheitlichen Blick auf alle Daten der einzelnen
Verbundspartner. Durch die Zusammenführung von heterogenen Daten aus unterschiedlichen Quellen ergeben sich aber Herausforderungen bei der Einhaltung von gemeinsamen
Datenqualitätsstandards.
Erschwerend kommt hinzu, dass es in der informationstechnologischen Landschaft
von medizinischen Versorgungszentren zu ständigen Änderungen kommt. Durch die
Hinzunahme von neuen Mitgliedern, durch Änderungen von Budgets und Verträgen oder
durch neue Gesetzgebung müssen Datenqualitätsanforderungen ständig neu evaluiert
und angepasst werden [ELPL11, End12].
Diese speziellen Gegebenheiten müssen im Rahmen dieser Arbeit und im Besonderen
bei der Entwicklung des Datenqualitätswerkzeugs berücksichtigt werden.
2
1.3 Methodik
1.3 Methodik
Die Arbeit ist in einen theoretischen sowie einen praktischen Teil gegliedert.
Im ersten Teil der Arbeit wird die vorliegende Problemstellung aus einem theoretischen Blickwinkel betrachtet. Es wird eine Literaturrecherche durchgeführt, um ein
grundlegendes Verständnis über die Gebiete der Datenqualität und der Regelsysteme zu
schaffen. Basierend auf den durch die Literaturrecherche gewonnenen Erkenntnissen wird
anschließend ein theoretisches Konzept zur Messung und Verbesserung von Datenqualität
beschrieben und bewertet.
Der zweite Teil der Arbeit beschäftigt sich mit dem Entwurf und der prototypischen
Implementierung einer Software-Applikation zur Messung und Verbesserung von Datenqualität in der Domäne medizinischer Versorgungszentren.
Dazu werden anfangs Fragebögen ausgewertet und Interviews mit verantwortlichen
Personen aus Referenzunternehmen geführt, um bestehende Datenqualitätsmängel und
bestehende Maßnahmen zur Behandlung dieser zu identifizieren. Aus den gewonnenen
Informationen werden anschließend funktionale sowie nicht funktionale Anforderungen
an das zu entwickelnde Werkzeug abgeleitet. Nach Ableitung der Anforderungen folgen
der Entwurf sowie die praktische Implementierung des Werkzeugs. Abgeschlossen wird
die Arbeit mit einer Evaluation des entwickelten Werkzeugs.
3
2 Datenqualität
Datenqualität wird oft als fitness for use definiert, d.h. die Eigenschaft einer Datenmenge,
den Ansprüchen ihrer Benutzer zu genügen [WZL01, SMB05]. Datenqualität spielt eine
zunehmend wichtige Rolle sowohl in kommerziellen als auch staatlichen Bereichen. So
wurden von verschiedenen Regierungen zahlreiche Initiativen gestartet, die Datenqualitätsverbesserung im Vordergrund haben, wie die Richtlinie 2003/98/EG des europäischen
Parlaments zur „Weiterverwendung von Informationen des öffentlichen Sektors“ [Eur03]
oder die Verabschiedung des „Data Quality Act“ der US-Amerikanischen Regierung im
Jahre 2002 [Off06, BCFM09, SMB05].
Dies liegt in den hohen Kosten und Problemen begründet, welche durch mangelnde Datenqualität verursacht werden. Fehler, die durch Datenqualitätsprobleme hervorgerufen
werden, reichen von der Verursachung von zusätzlichen Kosten durch das doppelte Zustellen von Werbebriefen, durch Duplikate in einer Kundendatenbank bis zu schwerwiegenden
Katastrophen wie dem Absturz des „Space Shuttle Challenger“ [FK01].
Angesichts dessen ist es offensichtlich, dass die Verbesserung und die Kontrolle von
Datenqualität einen hohen Stellenwert haben. Um Datenqualität verbessern zu können muss es allerdings möglich sein, diese zu messen und effektiv zwischen validen
und invaliden Daten zu unterscheiden. Da Daten allerdings sehr divers sind und in
verschiedenen Formaten und Zusammenhängen vorkommen, ist es oftmals schwierig zu
definieren was Datenqualität ausmacht [Los02]. Verstärkt wird dieses Problem durch den
Trend des vermehrten Zusammenschließens von ehemals monolithischen Datenquellen zu
netzwerkartigen Systemen im Bereich der Informationssysteme [BCFM09, SMB05].
Durch Aufteilung des komplexen Begriffs der Datenqualität in Dimensionen, welche
verschiedene Facetten dieses Begriffs beschreiben, wird dieses Konzept greifbarer und
leichter messbar [CFP04].
2.1 Dimensionen
Forschungen haben gezeigt, dass es sich bei Datenqualität um ein mehrdimensionales
Konzept handelt. Eine Dimension beschreibt eine bestimmte Facette des Datenqualitäts-
5
2 Datenqualität
begriffs [CFP04]. Verschiedene Dimensionen beschreiben verschiedene messbare Bereiche
der Datenqualität [Los10, S.130]. In der Literatur wurden zahlreiche Dimensionen erkannt
und klassifiziert. Allerdings herrscht kein Übereinkommen darüber, welche Dimensionen den Datenqualitätsbegriff definieren sowie über die Definition der Dimensionen
selbst. Durch Betrachtung der Literatur können dennoch grundlegende Dimensionen
erkannt werden, welche von zahlreichen Autoren schwerpunktmäßig behandelt wurden
[BCFM09, SMB05]. Diese sollen im Folgenden vorgestellt und charakterisiert werden.
2.1.1 Genauigkeit
Der Begriff der Datenqualität wird häufig nur auf die Dimension der Genauigkeit reduziert.
Dies sind beispielsweise Schreibfehler oder schlichtweg falsche Daten, wie ein falsches
Geburtsdatum oder eine falsche Adresse. Die Dimension der Genauigkeit alleine reicht
aber nicht aus, um Datenqualität vollständig zu beschreiben [SMB05]. Folgend ein
Überblick über eine Auswahl von Definitionen der Dimension der Genauigkeit:
• „The extent to which data are correct, reliable and certified [WS96].“
• „Data are accurate when the data values stored in the database correspond to
real-world values [BP85].“
• „Measure of the proximity of a data value, v, to some other value, v’, that is
considered correct [Red97].“
Bei den obigen Definitionen lässt sich eine grundlegende Übereinstimmung erkennen.
Im Kontext einer relationalen Datenbank ist Genauigkeit demzufolge der Grad, zu dem
Daten mit ihren Entsprechungen in der realen Welt übereinstimmen.
Genauigkeit kann in zwei verschiedene Kategorien aufgeteilt werden: syntaktische und
semantische Genauigkeit. Syntaktische Fehler sind beispielsweise Tippfehler. Semantische
Fehler hingegen sind schlichtweg falsche Werte, wie etwa eine nicht mehr existierende
Telefonnummer oder ein falsches Alter in einer Tabelle, die Personendaten beschreibt. Ein
Wert kann syntaktisch genau, aber semantisch falsch sein. Dies wäre ein grammatikalisch
genauer Wert für einen Namen, der aber von dem Namen der zu beschreibenden Person
in der realen Welt abweicht, beispielsweise „Franz“ anstatt „Peter“. Genauso kann ein
Wert semantisch genau, aber syntaktisch falsch sein. Dies wäre, um beim obigen Beispiel
zu bleiben, wenn zwar der richtige Name der Person aufgezeichnet wurde, aber ein
Tippfehler bei der Speicherung des Namens unterlaufen ist, dementsprechend „Petr“
anstatt „Peter“.
6
2.1 Dimensionen
2.1.2 Vollständigkeit
Bei der Betrachtung von Definitionen der Vollständigkeit von verschiedenen relevanten
Autoren, kann im Wesentlichen ebenfalls ein Konsens erkannt werden. Folgend ein
Überblick über eine Auswahl von Definitionen:
• „Ability of an information system to represent every meaningful state of a real
world system [WW96].“
• „Degree to which values are included in a data collection [Red97].“
• „Percentage of real-world information entered in data sources and/or the data
warehouse [JLVV03].“
• „Ratio between the number of non-null values in a source and the size of the
universal relation [Nau02].“
Demnach ist Vollständigkeit der Grad, zu dem die zu beschreibende Menge von RealWelt-Objekten eine Entsprechung in der Datenmenge einer bestimmten Datensammlung
hat [BCFM09, S.7].
In relationalen Datenbanken kann Vollständigkeit über das Vorhandensein und die
Bedeutung von NULL-Werten charakterisiert werden. Ein NULL-Wert bezeichnet in einer
relationalen Datenbank einen nicht aufgezeichneten Wert. „NULL“ kann allerdings verschiedene Bedeutungen haben, welche verschiedene Auswirkungen auf die Vollständigkeit
mit sich bringen. Um Vollständigkeit messen zu können, muss verstanden werden, warum
ein gegebener NULL-Wert vorkommt. Ein möglicher Grund für das Nichtvorhandensein
eines Wertes in der Datenbank kann sein, dass schlicht keine Real-Welt-Entsprechung
existiert. So könnte ein NULL-Wert in Kundendaten beispielsweise charakterisieren, dass
ein bestimmter Kunde keine E-Mail-Adresse besitzt. In diesem Fall hat der NULL-Eintrag
keine negative Bedeutung für die Vollständigkeit der Datenbank.
Die zweite Alternative ist, dass ein Wert nicht aufgezeichnet wurde obwohl bekannt ist,
dass dieser in der realen Welt vorhanden ist. Ein solcher Wert repräsentiert mangelnde
Vollständigkeit.
Eine dritte mögliche Interpretation für einen NULL-Eintrag ist, ein Wert für den nicht
bekannt ist, ob er in der realen Welt existiert oder nicht existiert. In diesem Fall kann
keine Aussage über die Vollständigkeit getroffen werden [BCFM09, SMB05].
7
2 Datenqualität
2.1.3 Konsistenz
Konsistenz bezeichnet die Einhaltung von semantischen Regeln, die für eine Datenmenge
definiert wurden. In relationalen Datenbanken geschieht dies durch Integritätsregeln wie
Primärschlüssel, CHECK-Constraints oder Trigger. Konsistenzregeln können aber auch
für nicht-relationale Daten formuliert werden [BCFM09, SMB05]. Auf Regeln wird in
Kapitel 3 näher eingegangen.
2.1.4 Zeitbezogene Dimensionen
Zeitbezogene Dimensionen beschreiben, wie temporale Aspekte die Qualität von Daten
beeinflussen. Die in der Literatur am häufigsten genannten zeitbezogenen Dimensionen
sind Aktualität (eng. currency) und Zeitgerechtigkeit (eng. timeliness). Bei den Definitionen dieser Dimensionen herrscht allerdings keine Übereinstimmung. Aktualität und
Zeitgerechtigkeit werden oft benutzt, um die gleichen Konzepte zu beschreiben [BCFM09,
S.8f].
2.1.4.1 Aktualität
Bei der Definition von Aktualität sind in der Literatur wie folgend dargestellt Diskrepanzen zu erkennen:
• „Currency describes when the information was entered in the sources and/or the
data warehouse [JLVV03].“
• „Currency is a measure of how old the information is, based on how long ago it
was recorded [BSM03].“
• „Currency is the degree to which a datum is up-to-date. A datum value is up-to-date
if it is correct in spite of possible discrepancies caused by time related changes to
the correct value [Red97].“
Ausgehend von den Definitionen von Jarke und Bovee misst Aktualität schlicht das Alter
von Daten. Dazu wird aufgezeichnet, zu welchem Zeitpunkt die letzte Aktualisierung
vollzogen wurde. Bei kritischer Betrachtung dieser Definitionen stellt sich die Frage,
inwiefern es sich dabei um eine Qualitätsdimension handeln kann, da keine Aussage über
den Grad an „fitness for use“ getroffen wird. Redman dagegen definiert Aktualität als
zeitbezogene Genauigkeit. Ein Datum ist aktuell, wenn es genau ist und nicht aktuell,
wenn es bedingt durch zeitliche Veränderung von einem genauen Zustand in einen
8
2.1 Dimensionen
ungenauen Zustand übergegangen ist. Bezieht ein Angestellter beispielsweise anfänglich
ein Gehalt von 20.000€ und wird dieses nach einem Jahr um 1.000€ erhöht, dann ist
21.000€ ein aktueller Wert, während 20.000€ einen inaktuellen Wert darstellt. Alle
anderen Werte, wie etwa 23.000€, sind weder aktuell noch inaktuell, sondern schlichtweg
ungenau.
2.1.4.2 Zeitgerechtigkeit
Die Dimension der Zeitgerechtigkeit ist nötig, um Daten zu beschreiben, die zwar aktuell
sind, aber für bestimmte Zwecke trotzdem nicht brauchbar sind, weil sie nicht rechtzeitig
bereitgestellt wurden. Beispielsweise ist ein Busfahrplan, der veröffentlicht wird, nachdem
alle Busse schon abgefahren sind, nicht zeitgerecht. Er kann aber trotzdem aktuell sein,
wenn noch keine neueren Informationen über Abfahrtszeiten existieren. Nachfolgend eine
Auswahl an Definitionen aus der Literatur:
• „Timeliness is the extent to which the age of data is appropriate for the task at
hand [WW96].“
• „Timeliness is the extent to which data are sufficiently up-to-date for a task [LC02].“
• „Timeliness is the average age of the data in a source [Nau02].“
Liu sowie Wand/Wang definieren Zeitgerechtigkeit als das Ausmaß, in dem Daten für
einen bestimmten Zweck ausreichend aktuell sind. Im Unterschied zur Dimension der
Aktualität ist also ein klarer Zweckbezug zu erkennen. Naumann definiert Zeitgerechtigkeit
als das durchschnittliche Alter von Daten. Die Dimension wird also im Gegensatz zu
den vorherigen Definitionen als multivariat gesehen. Außerdem fehlt ein Zweckbezug.
Im Rahmen dieser Masterarbeit soll daher im Folgenden den Definitionen von Liu und
Wand/Wang der Vorzug gegeben werden.
2.1.5 Weitere Dimensionen
Die bisher vorgestellten Dimensionen stellen den Schwerpunkt in der Datenqualitätsliteratur dar. Allerdings wurden von vielen Autoren noch einige weitere Dimensionen
beschrieben [BS06]. Die meistzitierte Aufstellung von Datenqualitätsdimensionen stammt
von den Autoren Wang und Strong [Nau07]. Wang und Strong beschreiben darin 15
Qualitätsdimensionen, die aus einer Befragung von Datenkonsumenten in größeren Unternehmen destilliert wurden. Sie gruppieren die 15 Dimensionen in vier Klassen [WS96]:
Intrinsische, kontextuelle und repräsentationale Datenqualität sowie Zugriffsqualität,
9
2 Datenqualität
siehe Tabelle 2.1. Intrinsische Datenqualität beschreibt inhärente Merkmale der Daten.
Um diese Dimensionen messen zu können, müssen die Daten selbst untersucht werden.
Kontextuelle Datenqualität hängt mit der Nutzung der Daten zusammen. Ob Daten
ausreichend nutzbar sind, hängt stark vom Ziel einer Aufgabe ab. Repräsentationale
Datenqualität bezieht sich auf die Darstellung der Daten. Zugriffsqualität beschreibt das
Niveau an Sicherheit und die Verfügbarkeit von Daten. Diese Klasse von Dimensionen
ist also systemabhängig und beschreibt Qualitäten des Informationssystems, welches die
Daten verwaltet [BS06, HGHM11, WS96].
2.1.6 Zusammenfassung
Die in der Literatur am häufigsten genannten Dimensionen sind Genauigkeit, Vollständigkeit, Konsistenz sowie die zeitbezogenen Dimensionen Aktualität und Zeitgerechtigkeit.
Dimensionen definieren einzelne Bereiche der Datenqualität und machen sie messbar,
welches es wiederum ermöglicht, die Datenqualität zu verbessern. Die Datenqualitätsdimensionen sind allerdings nicht unabhängig voneinander. Die Bevorzugung einer Dimension kann sich negativ auf eine andere auswirken. Eine Fokussierung auf Aktualität
kann sich so negativ auf die Genauigkeit oder Vollständigkeit von Daten auswirken. Ein
Beispiel dafür wäre die Veröffentlichung von Gerüchten, also Daten, deren Genauigkeit
nicht sicher verifiziert werden kann. In bestimmten Domänen kann die möglichst zeitnahe
Klasse
Intrinsische Datenqualität
Kontextuelle Datenqualität
Repräsentationale Datenqualität
Zugriffsqualität
Datenqualitäts-Dimension
Glaubhaftigkeit
Genauigkeit
Objektivität
Reputation
Mehrwert
Relevanz
Zeitgerechtigkeit
Vollständigkeit
Angemessener Umfang
Interpretierbarkeit
Verständlichkeit
Konsistenz der Darstellung
Knappheit der Darstellung
Zugänglichkeit
Zugriffssicherheit
Tabelle 2.1: Datenqualitätsdimensionen nach Wang und Strong [WS96]
10
2.2 Managementansätze
Bereitstellung von Informationen aber wichtiger sein als die vollkommene Genauigkeit
oder Vollständigkeit der Informationen. Je nach Anwendungsfall muss unterschieden
werden, welche Dimensionen wichtiger sind [SMB05].
2.2 Managementansätze
Um eine nachhaltige und effektive Datenqualitätssteigerung sicherzustellen, ist ein kontinuierliches Datenqualitätsmanagement nötig. Punktuelle Datenreinigungen haben nur
einen kurzfristigen Effekt. Die dadurch erzielten Verbesserungen gehen gerade bei sich
häufig ändernden Daten schnell verloren. Das Thema Datenqualität darf daher nicht
als eine einmalige Aktion betrachtet werden. Um Datenqualität effektiv zu verbessern,
bedarf es ganzheitlicher Methoden, die Daten über ihren gesamten Lebenszyklus hinweg
betrachten, um ein definiertes Niveau an Qualität zu garantieren. In der Literatur wurden
dazu verschiedene Ansätze zur kontinuierlichen Datenverbesserung vorgeschlagen. Ihre
Wurzeln liegen meist in alt-bewährten Methoden des Qualitätsmanagements, die für die
Belange der Datenqualität angepasst und erweitert wurden [HGHM11]. Das von Wang
vorgeschlagene Total Data Quality Management (TDQM) basiert auf der Betrachtung
von Daten ähnlich zu Produkten in der Fertigungsindustrie. Die in diesem Bereich weitverbreitete Qualitätssicherungs-Methodik des Demingkreises [Dem86] wurde dabei auf
Daten übertragen. Der Demingkreis beschreibt eine iterative Problemlösungsmethodik
die aus vier Phasen besteht: Planen, Umsetzen, Überprüfen, Handeln [WZL01].
Ein weiterer iterativer Managementansatz, das Total Information Quality Management
(TIQM), wurde von Larry English vorgeschlagen [Eng99]. Er entwickelte TIQM basierend
auf der im Qualitätsmanagement populären Six-Sigma-Methodik, einem Managementsystem zur Prozessoptimierung unter Anwendung analytischer und statistischer Methoden
[Ten01]. TIQM besteht aus sechs Prozessen, die in drei sich wiederholende Phasen
gegliedert werden können. Die Phasen beschreiben Prozesse zur Erfassung der gegenwärtigen Situation, zur Einleitung von Verbesserungsmaßnahmen und zur Evaluation der
abgeschlossenen Verbesserungen [BCFM09].
Neben diesen Ansätzen existieren noch eine Reihe weiterer. Alle Ansätze haben aber
eine Messungs- und Verbesserungs-Phase gemeinsam. Daraus ist zu schließen, dass diese
beiden Phasen eine zentrale Rolle bei nachhaltiger Datenqualitätsverbesserung einnehmen. In der Messungs-Phase wird das Datenqualitäts-Niveau relevanter Dimensionen
quantifiziert. Die Verbesserungs-Phase beinhaltet die Anhebung der Datenqualität unter
Verwendung verschiedener Strategien und Maßnahmen [BCFM09].
11
2 Datenqualität
In diesem Abschnitt soll ein ausgewählter Managementansatz, Wangs TDQM, näher
vorgestellt werden. TDQM war die erste in der Literatur veröffentlichte ganzheitliche
Datenqualitätsmanagement-Methode und kommt in der Praxis bei Initiativen zur Datenqualitätsverbesserung weitverbreitet zur Anwendung. Eine ausführlichere Übersicht über
weitere verschiedene existierende Managementansätze findet sich in [BCFM09].
2.2.1 Total Data Quality Management
TDQM definiert analog zum Demingkreis vier Phasen, welche kontinuierlich durchlaufen werden müssen, um eine nachhaltige Datenqualitätsverbesserung zu erreichen. Die
Phasen sind in Abbildung 2.1 dargestellt. Es hat eine ganzheitliche Unterstützung des
Datenqualitätsverbesserungs-Prozesses zum Ziel. Der kontinuierliche TDQM-Kreislauf
beinhaltet Phasen der Definition, Messung, Analyse und Verbesserung. Diese Phasen
Bild 2.1: Der TDQM-Kreis
sollen folgend näher beschrieben werden [WZL01, HGHM11]:
1. Definition:
In der Definitions-Phase müssen relevante Datenqualitätsdimensionen
ausgewählt und entsprechende Anforderungen an diese definiert werden.
Die Anforderungen können in Form von Geschäftsregeln (eng. Business
Rules) ausgedrückt werden. Geschäftsregeln sollen im anschließenden
Kapitel 3 ausführlich behandelt werden.
12
2.2 Managementansätze
2. Messung:
Nach der Formulierung der Anforderungen folgt deren Anwendung auf
die Daten. Es wird untersucht, inwiefern die Daten den Anforderungen
genügen. Dies wird mit Hilfe von verschiedenen Metriken quantifiziert.
Mögliche Beispiele sind die absolute Anzahl nicht vorhandener E-MailAdressen in Kundendaten oder der Zeitpunkt der letzten Aktualisierung
bestimmter Daten.
3. Analyse:
In der Analyse-Phase werden Ursachen mangelnder Datenqualität festgestellt. Die Ursachen können vielfältig sein, unter anderem können
fehlerhafte Anwendungen, menschliche Fehler oder schlecht gestaltete
Prozesse verantwortlich sein.
4. Verbesserung:
In der Verbesserungs-Phase sollen die Fehler und deren Ursachen nachhaltig beseitigt werden. Dazu gilt es permanent qualitätssichernde Maßnahmen zu implementieren, wie etwa durch die Umgestaltung von Prozessen.
Einmalige Datensäuberungsmaßnahmen können davor initial zur Anwendung kommen.
Nach Abschluss aller Phasen erfolgt stets eine neue Iteration und die erneute Definition
von Anforderungen. Durch die fortlaufende Überwachung wird ein erneutes unbemerktes
Absinken der Qualität verhindert und eine kontinuierliche und nachhaltige Verbesserung
der Datenqualität ermöglicht.
13
3 Regelsysteme
Im Folgenden Teil der Arbeit sollen Regelsysteme vorgestellt werden. Zuerst soll definiert
werden, was unter Regeln bzw. Geschäftsregeln zu verstehen ist. Anschließend werden
regelbasierte Systeme vorgestellt sowie beschrieben wie Geschäftsregeln in relationalen
Datenbanken und NoSQL-Datenbanken realisiert werden.
Dies ist in Bezug auf Datenqualität relevant, da Anforderungen an Datenqualität in
Form von Geschäftsregeln ausgedrückt werden können, welche wiederum die Grundlage
für die Messung von Datenqualität stellen [HGHM11].
Zur Erfüllung der Anforderungen und dadurch bedingt zur Verbesserung der Datenqualität können Geschäftsregeln ebenfalls eingesetzt werden. In welchem Maße wird im
Kapitel 4 genauer diskutiert.
3.1 Business Rules
„Business Rules“ oder zu Deutsch „Geschäftsregeln“ sind Regeln, welche das Geschäftsverhalten bestimmen. Die Business Rule Group1 definiert Geschäftsregeln folgendermaßen:
„A business rule is a statement that defines or constrains some aspect of the
business. It is intended to assert business structure or to control or influence
the behaviour of the business [Hay00].“
Demnach sollen Business Rules einen bestimmten Teil des Geschäfts einschränken,
um einen vorgegeben Prozessablauf zu garantieren oder das Geschäftsverhalten zu
kontrollieren. Einige Beispiele für Geschäftsregeln sind:
• Eine Auszahlung von über 5.000€ muss vom Filialleiter genehmigt werden
• Das minimale Gehalt eines Abteilungsleiters beträgt 4.000€
• Der Lagerbestand muss aufgefüllt werden, wenn er unter 100 Stück fällt
1
http://www.businessrulesgroup.org
15
3 Regelsysteme
Die Literatur unterscheidet drei verschiedene Arten von Geschäftsregeln [Hay00]:
• Strukturelle Regeln:
Strukturelle Beschränkungen können durch das Entity-RelationshipModell ausgedrückt werden. Eine typische strukturelle Regel wäre z.B.:
„Ein Kunde kann ein oder mehrere Konten haben, aber ein Konto nur
genau einen Kunden.“
• Beschränkungen:
Beschränkungen beschäftigen sich mit den dynamischen Aspekten eines
Geschäfts. Sie beschränken Geschäftsaktionen, so z.B.: „Ein Kunde kann
nur ein Buch ausleihen, wenn er seinen aktuellen Jahresbeitrag schon
gezahlt hat.“
• Derivative Regeln:
Derivative Regeln beschreiben, welche Fakten durch andere Fakten abgeleitet werden müssen, z.B.: „Das Alter einer Person wird berechnet
durch die Subtraktion des Geburtsdatums vom heutigen Datum.“
3.2 Regelbasierte Systeme
Regelbasierte Systeme (eng. Rule-Engine) sind Applikationen die Problemlösungs-KnowHow automatisieren, indem sie Expertenwissen mit Hilfe von Regeln einfangen [HR85].
Regeln bestehen in regelbasierten Systemen aus Wenn-Dann-Sätzen. Dies beruht
darauf, dass menschliche Experten ihre Problemlösungs-Techniken für gewöhnlich in
Form von Situations-Aktions-Regeln ausdrücken. Der Wenn-Teil einer Regel besteht
aus einer Bedingung, welche definiert, wann die Regel ausgelöst wird. Der Dann-Teil
beschreibt die Aktion, welche ausgelöst wird, wenn die Bedingung der Regel erfüllt ist.
Ein Beispiel für eine Regel die Expertenwissen repräsentiert ist:
„WENN der Patient sich über gereizte Augen UND andauerndes Nießen
beklagt UND momentan Pollenflug herrscht DANN unterziehe den Patienten
einer Prüfung auf Pollenallergie.“
Regelbasierte Systeme drücken also domänenspezifisches Expertenwissen als eine Menge
von Wenn-Dann-Regeln aus. Sie lösen automatisiert Probleme, indem sie überprüfen
ob die ihnen zur Verfügung stehende Regelmenge Bedingungen enthält, welche durch
16
3.2 Regelbasierte Systeme
das gegebene Problem erfüllt werden. Danach werden mögliche Konflikte in der Menge
der anwendbaren Regeln gelöst und eine optimale Reihenfolge der Regelausführung
determiniert. Schließlich folgt die Auslösung der Aktionen, welche die Regeln spezifizieren.
[HR85]
3.2.1 Architektur
Regelbasierte Systeme bestehen aus drei Komponenten, einer Regelbasis, einer Faktenbasis
und einer Inferenzmaschine (siehe Abbildung 3.1). Die einzelnen Komponenten agieren
Bild 3.1: Architektur eines Regelsystems
folgendermaßen [SRR+ 07, FH03, Sta07]:
1. Faktenbasis:
Die Faktenbasis enthält die Daten, auf welche die Regeln angewandt
werden. Der Typ der Daten kann je nach Anwendung unterschiedlich
sein, z.B. können Fakten als Java Objekte oder auch als Tupel in einer
relationalen Datenbank repräsentiert werden.
2. Regelbasis:
In der Regelbasis werden alle dem System bekannten Regeln aufbewahrt.
Die Regeln repräsentieren das Wissen, das über die Domäne bekannt
ist. Sie können als einfache Zeichenketten abgelegt werden oder in ein
Format umgewandelt sein, das der Ausführungseinheit eine schnellere
17
3 Regelsysteme
Anwendung erlaubt. Die Regelbasis kann sich physisch sowohl innerhalb
des regelbasierten Systems als auch extern z.B. in einer relationalen Datenbank befinden. Die Anwendung von relationalen Datenbanken erlaubt
die Ausnutzung von inhärenten Funktionalitäten von Datenbankmanagementsystemen, wie unter anderem die Verwaltung von Nutzerrechten,
wodurch die Selektion von Regeln je nach Anwender angepasst werden
kann.
3. Inferenzmaschine:
Die Hauptaufgabe eines regelbasierten Systems ist die Anwendung von
Regeln auf Daten, wofür die Inferenzmaschine zuständig ist. Die Anwendung der Regeln erfolgt iterativ in drei Phasen:
• Zuerst werden in einer Mustererkennungsphase (eng. PatternMatching) alle Regeln mit der Faktenbasis verglichen. Es wird festgestellt, welche Regeln durch die gegebenen Fakten zu aktivieren sind.
Dazu werden die Prämissen aller Regeln evaluiert. Spezielle zu diesem Zweck entwickelte Algorithmen optimieren hierbei den nötigen
Aufwand, indem z.B. Prämissen, die in mehreren Regeln vorkommen
nur einmal evaluiert werden oder bei mehrmaligen Iterationen nur
sich geänderte Fakten neu evaluiert werden. Alle aktivierten Regeln
werden schließlich, nach Abschluss der Bedingungsevaluierung, in
einer sogenannten Konfliktmenge (eng. Conflict Set) gespeichert.
• Anschließend wird in einer Konfliktbehandlungsphase, aus der Menge der aktivierten Regeln, eine Ausführungsreihenfolge ermittelt
(eng. Conflict Resolution). Für die Priorisierung der Regeln bestehen
verschiedene Lösungsstrategien. Die einfachste Möglichkeit ist die
Selektierung nach Zeitstempeln, eine weitere häufig angewandte Option ist die Priorisierung anhand der Komplexität der Bedingungen
der Regeln.
• In der letzten Phase wird die beschriebene Aktion jeder Regel in der
vorher determinierten Reihenfolge ausgeführt. Die ausgeführte Aktion kann die Faktenbasis beeinflussen und ihren Zustand verändern.
Dadurch eingetretene Änderungen müssen re-evaluiert werden. Dies
kann dazu führen, dass vorhergehend deaktivierte Regeln aktiviert
werden oder umgekehrt. Regeln, die innerhalb einer Iteration aus-
18
3.2 Regelbasierte Systeme
geführt wurden, werden dabei aber nicht noch einmal ausgeführt.
Die Inferenzmaschine stellt also sicher, dass keine Zyklen entstehen.
Dieser Prozess wird fortgeführt bis keine Regel mehr gefeuert werden kann. Nach Anwendung aller Regeln beginnt wieder eine neue
Iteration mit dem Vergleich von Regeln und Fakten.
3.2.2 Bewertung von regelbasierten Systemen
Regelbasierte Systeme basieren auf deklarativen Regeln. Im Aktionsteil der Regel wird
dem System mitgeteilt, was es machen soll, aber nicht wie. Dies steht im Gegensatz zu
dem prozeduralen Ansatz, in welchem explizit beschrieben werden muss, welche Schritte
in welcher Reihenfolge durchlaufen werden müssen.
Dank der Deklarativität der Regeln und der Architektur von regelbasierten Systemen
ergeben sich einige Vorteile im Gegensatz zu traditionellen Applikationen mit prozeduraler
Regelformulierung [Los02, SRR+ 07, Bal09]:
• Wiederverwendbarkeit:
Durch die Trennung des Systems in Inferenzmaschine, Faktenbasis und
Regelbasis kann eine größere Wiederverwendbarkeit erreicht werden. Es
ergibt sich die Möglichkeit verschiedene Faktenbasen an einen kompatiblen Regelsatz zu binden oder umgekehrt.
• Fokussierung auf Businesslogik:
Experten können sich auf die Analyse der Domäne und die Formulierung
geeigneter Regeln fokussieren, anstatt auf deren Umsetzung. Denn das
Regelsystem kann die formulierten Regeln dynamisch in ausführbaren
Quellcode übersetzen und auf Daten anwenden.
• Veränderbarkeit:
Die Anforderungen an die Businesslogik ändern sich häufiger als die Anforderungen an die anderen Teile eines Informationssystems. AnforderungsDefinitionen sind selten vollständig und entwickeln sich mit der Zeit
weiter. In prozeduralen Informationssystemen bedingt jede Anforderungsänderung auch eine Änderung des Quellcodes der Applikation, was
zusätzlichen Aufwand bedeutet und die Wahrscheinlichkeit für Fehler
erhöht. Da deklarative Geschäftsregeln vom Ausführungscode getrennt
sind, kann dieses Problem in regelbasierten Systemen umgangen werden
19
3 Regelsysteme
und bestehende Regelsätze von Domänen-Experten leichter erweitert
oder verändert werden.
• Wartbarkeit:
Regelbasierte Systeme verhindern das Vermischen von Ausführungscode
mit Geschäftsregeln, dadurch verbessert sich die Übersichtlichkeit des
Quellcodes und somit die Wartbarkeit des Systems.
• Selbst-Dokumentation:
Die Geschäftsregeln sind in einer festgelegten Syntax formuliert und nicht
in den Quelltext eingebettet. Sie können so leichter analysiert werden und
erlauben Aussagen über den Zweck der Applikation, die sie verwendet.
Einem Regelsatz kann man so z.B. die Ansprüche, die an Datenqualität
gestellt wurden, entziehen.
Die Nachteile von regelbasierten System liegen vor allem im Implementierungsaufwand.
Sie haben ihre Stärken in Domänen mit oft wechselnden Anforderungen und einer großen
Anzahl an Geschäftsregeln. Bei Projekten mit weniger als 20 Regeln oder Umgebungen, in
denen sich die Businesslogik selten ändert, können der nötige Implementierungsaufwand
sowie mögliche Performanceeinbußen durch den gewonnen Nutzen nicht gerechtfertigt
werden [Bal09, S.13].
3.3 Regeln in Relationalen Datenbanken
In diesem Abschnitt soll betrachtet werden, welche interne Sprachkonstrukte Datenbankmanagementsysteme (DBMS) bieten, um die in relationalen Datenbanken gespeicherten
Daten, auf die Einhaltung von Regeln hin zu überprüfen. Die Verwendung von internen
Regelmechanismen ist dazu allerdings nicht die einzige Möglichkeit.
In externen Applikationen mit Datenbankzugriff können beliebige Regeln realisiert
werden. Eine Möglichkeit ist dabei, die Daten in regelmäßigen Abständen auszulesen
und auf Einhaltung der Regeln hin zu überprüfen. Je kürzer die Abstände zwischen
den Auslesungen, desto mehr wird aber die Leistung des Systems beeinträchtigt und je
länger die Abstände, desto später werden Mängel erkannt. Wie festzustellen ist, werden
Regelverletzungen dadurch immer erst nachträglich entdeckt. Die andere Alternative ist
es, in jeder Anwendung, welche die Datenbank modifizieren könnte, Regelüberprüfungen
zu implementieren. Eine derartige Dezentralität beeinträchtigt aber die Skalierbarkeit und
20
3.3 Regeln in Relationalen Datenbanken
bedeutet einen zusätzlichen softwaretechnischen Aufwand bei der Anpassung von Anwendungen. Bei diesem Ansatz besteht außerdem ebenfalls keine Garantie, dass nur Daten in
die Datenbank gelangen, welche die Regeln befriedigen. Es besteht kein Mechanismus um
zu verhindern, dass Anwendungen, welche keine Regelüberprüfung implementieren, oder
diese falsch implementieren, verändernt auf die Datenbank zugreifen, falls Schreibrechte
für den Anwendungsfall nötig sind [HW92, MS02]. Externe Applikationen könne die
Einhaltung von Regeln also nicht erzwingen und eignen sich daher nur zur Evaluierung
des Datenbestands.
Soll eine Einhaltung der Regeln erzwungen werden, muss auf interne Datenbankregeln
zurückgegriffen werden. Das DBMS garantiert die Überprüfung der Regeln bei jeder relevanten Veränderung der Daten. Die Wahrung dieser Bedingungen gehört zu den zentralen
Aufgaben eines DBMS. Im SQL-Standard existiert eine Vielzahl an Sprachkonstrukten,
welche die Formulierung von internen Datenbankregeln ermöglichen. Die Regeln lassen
sich auf verschiedene Weisen klassifizieren, so unter anderem [SH97, S.419]:
• Attributsbezogen, Relational oder Interrelational (Granularität)
• Statisch oder Dynamisch (zeitlicher Kontext)
• Modellinhärent oder Modellunabhängig
Die erste erwähnte Möglichkeit ist die Klassifikation von Regeln anhand ihrem Geltungsbereich. Regeln können entweder nur für einzelne Attribute und Tupel, aber auch für
ganze Tabellen oder über mehrere Tabellen hinweg gültig sein.
Die zweite Möglichkeit ist die Gliederung von Regeln nach ihrem zeitlichen Kontext.
Dynamische Regeln betreffen hier Zustandsübergänge oder langfristige Abläufe (temporale Integritätsbedingungen). Statische Regeln dagegen garantieren korrekte Zustände.
So sind zum Beispiel die Zustände „Ledig“ und „Verwitwet“ beides korrekte Werte für
ein Attribut „Familienstand“, allerdings wäre der Zustandsübergang von „Ledig“ zu
„Verwitwet“ invalide. Ein Beispiel für eine temporale Bedingung wäre z.B. die Miete darf
innerhalb von drei Jahren maximal um 20% erhöht werden [MS02, S.256f.]. In relationalen
Datenbanken können statische Bedingungen beispielsweise über CHECK-Constraints
implementiert werden, während dynamische Bedingungen über Trigger realisiert werden
können.
Die dritte Klassifikationsalternative ist die Kategorisierung von Regeln nach Modellinhärenz bzw. Modellunabhängigkeit. Dabei werden Regeln danach unterschieden, ob
sie aus der Strukturbeschreibung des Datenmodells hervorgehen (modellinhärenz) oder
21
3 Regelsysteme
nicht. Beispiele für modellinhärente Bedingungen sind Typintegrität, Schlüsselintegrität
und referenzielle Integrität.
Folgend sollen die verschiedenen im SQL-Standard definierten Arten von Integritätsbedingungen detaillierter vorgestellt werden.
3.3.1 Schlüsselintegrität
Grundlegende Voraussetzung des relationalen Datenmodells ist, dass jedes Tupel einer
Relation eindeutig identifizierbar sein muss. Es dürfen also keine Tupel mit identischen
Werten in einer Relation vorkommen. Um dies zu realisieren wird für jede Relation ein
Primärschlüssel ausgewählt. Ein Primärschlüssel ist entweder ein Attribut oder eine
Menge von Attributen, deren Felder innerhalb einer Tabelle keine Duplikate enthalten.
Dies könnte beispielsweise eine Personalnummer oder Matrikelnummer sein.
Innerhalb einer Tabelle können mehrere Attribute oder Kombinationen von Attributen vorkommen, die eine eindeutige Identifizierung erlauben. Jede dieser eindeutigen
Attributsmengen wird als Schlüsselkandidat bezeichnet, sofern sie minimal ist. Ein
Schlüsselkandidat ist minimal wenn keine Teilmenge innerhalb des Schlüsselkandidaten
existiert, welche Tupel eindeutig identifiziert.
Aus der Menge der erkannten Schlüsselkandidaten muss anschließend für jede Tabelle
ein Kandidat als Primärschlüssel ausgewählt werden. Das Datenbanksystem garantiert,
dass in den Primärschlüssel einer Tabelle keine Duplikate eingesetzt werden können.
Änderungsoperationen, welche die Integrität des Primärschlüssels verletzen, werden
abgelehnt.
Um vom Datenbanksystem ebenfalls die Eindeutigkeit von Schlüsselkandidaten schützen zu lassen, können diese mit dem Schlüsselwort UNQIUE versehen werden [GMUW09,
S.25] [SH97, S.90] [MS02, S.376ff.].
3.3.2 Referenzielle Integrität
Referenzielle Beschränkungen garantieren, dass Verweise in einer Datenbank zu existierenden Daten führen [MS02, S.379]. Referenzielle Beschränkungen werden in SQL über
Fremdschlüssel realisiert. Fremdschlüssel werden als zusätzliches Attribut in eine Relation
eingefügt. Sie beinhalten die Werte des Primärschlüssels einer fremden Relation. Der
Fremdschlüssel eines Tupels enthält also einen Verweis auf ein anderes Tupel. Betrachtet
man beispielsweise eine Tabelle „Personal“, in der alle personenbezogenen Daten eines
Angestellten gespeichert sind und eine Tabelle „Gehalt“, in der separat alle gehaltsbezo-
22
3.3 Regeln in Relationalen Datenbanken
genen Daten eines Angestellten gespeichert sind, können die beiden Tabellen über einen
Fremdschlüsselverweis zusammengeführt werden, um herauszufinden welcher Angestellte
welches Gehalt bezieht, siehe Abbildung 3.2. Neben Verweisen zwischen Tabellen sind
Bild 3.2: Ein Fremdschlüsselverweis
auch rekursive Verweise möglich, dabei beinhaltet das Fremdschlüssel-Attribut die Werte
des Primärschlüssels der eigenen Relation [GMUW09, S.312]. Fremdschlüssel müssen
immer auf einen Schlüsselkandidaten oder auf einen Primärschlüssel verweisen, um zu
gewährleisten, dass die Referenz eindeutig ist [MS02, S.383].
3.3.3 Typintegrität
Typbeschränkungen bestimmen den Wertebereich, welchen ein gegebenes Attribut annehmen kann. Ein Wertebereich ist eine Menge von atomaren Werten und besteht aus
einem Namen, einem Datentyp und gegebenenfalls einem Format. SQL bietet zahlreiche
Standarddatentypen an, so unter anderem verschiedene Typen zur Darstellungen von
ganzen Zahlen, reellen Zahlen, Währungen oder Zeitdaten. Der Benutzer hat aber auch
die Möglichkeit, eigene komplexe Datentypen zu formulieren [EN94, S.169ff.].
Um beispielsweise IPv4-Adressen in einer Datenbank zu speichern, ist ein Datentyp
nötig, der Ganzzahlen zwischen 0 und 255 zulässt. Das Format wird definiert als vier mit
einem Punkt getrennte Blöcke, die jeweils eine Instanz dieses Datentyps beinhalten, z.B.:
103.0.213.135
Dadurch ergibt sich eine Menge von 4.294.967.296 eindeutigen atomaren Werten, die
diesen Wertebereich bilden. Typbeschränkungen werden immer augenblicklich geprüft.
Ein Attribut kann nie einen Wert annehmen, welcher dem Wertebereich nicht entspricht,
sofern das DBMS Typbeschränkungen implementiert [Dat03, S.267].
23
3 Regelsysteme
Eine besondere Typbeschränkung wird durch das Schlüsselwort NOT NULL definiert,
welches der Attributsdeklaration in einer CREATE TABLE Anweisung folgen kann, z.B.:
CREATE TABLE Person(
...,
Nachname VARCHAR(50) NOT NULL
);
Dadurch wird sichergestellt, dass keine NULL Werte in die Zellen des Attributs eingesetzt
werden können. In dem obigen Beispiel wird durch das Schlüsselwort NOT NULL sichergestellt, dass jede Zeile der Tabelle „Person“ einen Eintrag für das Attribut „Nachname“
besitzt [GMUW09, S.319] [MS02, S.360].
3.3.4 CHECK-Beschränkungen
CHECK-Anweisungen ermöglichen es, eine Reihe verschiedener Bereichseinschränkungen
für Attribute zu formulieren, darunter [KE11, S.162] [MS02, S.365ff.] [GMUW09, S.320ff.]:
• Bestimmung eines Minimal- oder Maximalwerts:
CHECK (birthdate < TODAY)
• Bestimmung eines erlaubten Intervalls:
CHECK (wage BETWEEN (800 AND 2000))
• Aufzählung von erlaubten Werten:
CHECK (type IN (’Programmer’, ’Architect’, ’Manager’))
Dem Schlüsselwort „CHECK“ folgt der Name eines Attributs, gefolgt von der Kondition
welche dieses Attribut einhalten muss. Vor der Materialisierung jeder Änderungsoperation
an dem genannten Attribut wird vom Datenbanksystem sichergestellt, dass die formulierte
Kondition zu TRUE evaluiert. Ansonsten wird die Änderungsoperation zurückgewiesen
[KE11, S.162].
24
3.3 Regeln in Relationalen Datenbanken
3.3.5 Assertions
Assertions erlauben es, CHECK-Anweisungen über mehrere Tabellen hinweg zu definieren.
Assertions werden mit einer CREATE-Anweisung, gefolgt von einer CHECK-Bedingung
definiert. Die boolesche Kondition innerhalb der CHECK-Bedingung muss jederzeit zu
TRUE evaluieren, vom Zeitpunkt der Definition bis zur Entfernung der Assertion. Die
Syntax einer Assertion sieht folgendermaßen aus:
CREATE ASSERTION {Name} CHECK ( {Kondition} );
Innerhalb der CHECK-Bedingung ist eine tabellenübergreifende Unteranfrage erlaubt,
beispielsweise:
CREATE ASSERTION max_klassen_groesse CHECK (
SELECT COUNT(*) FROM Schüler <
SELECT COUNT(*) FROM Lehrer * 30
);
Alle Datenbank-Elemente, die in einer Unteranfrage spezifiziert wurden, werden bei jeder
Änderung auf die Einhaltung der Assertion hin überprüft. Jede Datenbank-Modifikation,
welche die Assertion verletzen würde, wird abgelehnt.
Assertions können theoretisch für denselben Zweck wie attributsbezogene CHECKBeschränkungen eingesetzt werden. Allerdings sind Assertions wesentlich ineffizienter als
diese. Attributsbezogene CHECK-Beschränkungen müssen nämlich nur evaluiert werden,
wenn in das Attribut, auf das sie sich beziehen, neue Werte eingefügt oder bestehende
modifiziert werden. Während Assertions für jede Änderung an der erwähnten Tabelle
ausgewertet werden müssen [GMUW09, S.328]. Daher sollten Assertions ausschließlich
für tabellenübergreifende Bedingungen verwendet werden.
3.3.6 Aktive Regeln
Aktive Regeln können auf Ereignisse in der Datenbank reagieren. Dies können temporale
Ereignisse oder Änderungen an der Datenbank sein, die beispielsweise durch UPDATE-,
DELETE- oder CREATE-Operationen hervorgerufen werden. Seit dem SQL:99 Standard
werden für die Implementierung solcher Regeln Trigger zur Verfügung gestellt.
Eine Abstraktion dieser Regeln kann mit dem ECA-Model (Event-Condition-Action)
erreicht werden. Dieses Model spezifiziert ein Ereignis, eine Bedingung und eine Aktion,
25
3 Regelsysteme
die ausgelöst wird, falls das beschriebene Ereignis eintritt und die Bedingung erfüllt ist
[GMUW09, S.328] [EN94, S.787ff.] [Dat03, S.278]:
• Das Ereignis ist üblicherweise eine Änderungsoperation an der Datenbank. Es
können aber auch temporale oder externe Ereignisse definiert werden.
• Die Bedingung ist ein boolescher Ausdruck, welcher zu TRUE evaluieren muss,
damit die nachfolgende Aktion ausgeführt wird. Ist keine Bedingung spezifiziert,
wird immer zu TRUE evaluiert.
• Die Aktion ist für gewöhnlich eine Prozedur, bestehend aus einer Reihe von
SQL-Anweisungen. Es kann stattdessen aber auch die Ausführung eines externen
Programms veranlasst werden.
3.3.6.1 Trigger
Trigger sind vom Benutzer geschriebene Prozeduren, die in der Datenbank gespeichert
sind und durch die Erfüllung bestimmter Bedingungen ausgelöst werden [KE11, S.167]
[Dat03, S.277].
Trigger bestehen aus einem Ereignis, einer Bedingung und einer Folgeaktion. Daher
gelten Trigger als ECA-Regeln, wie oben beschrieben [Dat03, S.278]. Im Gegensatz zu
ECA-Regeln können Trigger allerdings nur durch Datenbankmodifikationen ausgelöst
werden, während ECA-Regeln auch durch Zeitereignisse (z.B. explizite oder relative
Zeitpunktangaben) oder externe Ereignisse (z.B. Aufrufe von Anwendungsmethoden)
aktiviert werden können [SH97, S.401]. Trigger beziehen sich immer auf eine bestimmte
Relation, die bei ihrer Definition bestimmt werden muss. Sie werden danach ausgelöst,
wenn bestimmte Ereignisse an der spezifizierten Relation eintreten. Die Syntax nach
SQL:1999 sieht folgendermaßen aus:
CREATE TRIGGER {Trigger Name}
{Zeitpunkt der Auslösung} {Ereignis das zur Auslösung führt}
ON {Name der Tabelle} [REFERENCING {Liste von Variablen}]
{Ausgelöste Aktion}
Als mögliche Ereignisse zur Auslösung des Triggers können CREATE, UPDATE und
DELETE-Operationen angegeben werden [KE11, S.168]. Außerdem muss ein Aktivierungszeitpunkt definiert werden, welcher festlegt wann die Aktion des Triggers ausgeführt
26
3.3 Regeln in Relationalen Datenbanken
wird. Die Aktion kann vor (BEFORE), nach (AFTER) oder anstelle (INSTEAD OF) des
eingetretenen Ereignisses ausgeführt werden [Dat03, S.278] [EN94, S.634] [SH97, S.398f.].
In der durch das Ereignis ausgelösten Aktion sind neben den üblichen Konsistenzsicherungsmaßnahmen, wie dem Ablehnen der Änderung an der Relation, auch andere
Nutzungen denkbar. So ist ebenfalls die Formulierung von Aktionen zur Durchführung
von Auditing, Leistungsmonitoring oder Debugging möglich. Eine weitere Alternative
ist beispielsweise das Versenden von Warnungen an einen bestimmten Nutzer, falls eine
bestimmte Kondition eintritt, wie z.B. das Überschreiten eines Schwellwerts [KE11,
S.168] [Dat03, S.277].
3.3.6.2 Kritik an Triggern
In der Literatur wird von zahlreichen Autoren vor der Benutzung von Triggern gewarnt.
Nachfolgend sind die häufigsten in der Literatur beschriebenen Probleme genannt, die
durch die Benutzung von Triggern auftreten können [Dat03, S.277ff.] [KE11, S.168]
[SH97, S.402] [EN94, S.635]:
• Ein Ereignis könnte mehrere Trigger auslösen, deren Ergebnisse sich dann gegenseitig beeinflussen. Dadurch ergibt sich ein Konfluenzproblem:
„Ein Regelsystem ist konfluent, wenn der Effekt auf die Datenbank bei
gleichzeitig aktivierten Regeln immer unabhängig von der Reihenfolge
der Abarbeitung dieser Regeln ist [SH97, S.402].“
• Es können Kettenreaktionen entstehen, Trigger werden durch andere Trigger aktiviert. Ein bestimmter Trigger könnte sich außerdem mehrmals selbst rekursiv
auslösen. Es könnten also Endlosschleifen entstehen. Je mehr Trigger geschrieben werden, desto größer ist die Wahrscheinlichkeit dafür. Dies beschreibt ein
Terminierungsproblem.
• Bei schlechtem Programmierstil können durch Trigger gänzlich andere Ergebnisse eintreten als es der Benutzer erwarten würde. Gerade durch die Anwendung
von INSTEAD-OF-Triggern können ansonsten unabhängigen Datenbankaktionen
aktiviert werden.
Nach Date sollte der Einsatz von Triggern wegen der oben genannten Probleme möglichst
vermieden und komplett darauf verzichtet werden, falls Alternativen existieren [Dat03].
Auf der anderen Seite stellen Trigger strukturiert eingesetzt ein sehr mächtiges Werkzeug
zur Einhaltung von Integritätsregeln dar. Ihr Einsatz ist wünschenswert, wenn die inhärenten Gefahren beherrscht werden können [SH97, S.402]. Dies stellt sich aber schwierig
27
3 Regelsysteme
dar, da zurzeit keine ausreichenden Konzepte zu Analyse, Design, Debugging oder Monitoring zur Verfügung stehen, wodurch ihr Potential erheblich beschränkt wird [SH97,
S.402] [EN94, S.635]. In der Praxis konnten einige dieser Probleme allerdings verringert
werden. Zum Beispiel ist durch die Vergabe von Prioritäten in Oracle-Datenbanken
eine eindeutige Abarbeitungsreihenfolge von Trigger-Aktionen garantiert. Durch diese
Priorisierung wird das Problem der Konfluenz behoben [Stü93].
3.4 Regeln in NoSQL Datenbanken
Seit der Vorstellung des relationalen Datenbankmodells durch Edgar Codd im Jahre
1970 ist dies bis heute der deutlich am weitesten verbreitete Standard im Bereich der
Datenbanken [SI05]. Im Gegensatz dazu stehen NoSQL-Datenbanken. NoSQL ist ein
Sammelbegriff für Datenbanken, die ein nicht-relationales Datenmodell implementieren
und daher keine oder zumindest keine vollkommene Unterstützung für die relationale
Anfragesprache SQL besitzen. Diese Art von Datenbanken sind mit dem Eintreten des
Web 2.0 Zeitalters verstärkt in den Fokus gerückt. Die Hauptanwender von NoSQLDatenbanken sind heutzutage Web 2.0 Unternehmen wie Google, Facebook oder Amazon,
die enorme und ständig wachsende Datenmengen verarbeiten müssen.
NoSQL-Datenbanken legen ihren Schwerpunkt auf hohe Leistung und Skalierbarkeit.
Ihr Hauptvorteil ist neben ihrer Skalierbarkeit und Leistung, dass sie im Gegensatz
zu relationalen Datenbanken, gut mit unstrukturierten Daten wie verschiedenen Dokumenten, E-Mails oder multimedialen Daten umgehen können. Diese Vorteile werden
ermöglicht durch die Verwendung von simplen Datenmodellen, primitiver Anfragesprache, Nichtverfügbarkeit von Integritätssicherungsmechanismen, wie z.B. Fremdschlüsseln
oder mangelnder Unterstützung von Sicherheitsmechanismen auf Datenbank-Niveau.
Außerdem wird zur Erhöhung von Verarbeitungsgeschwindigkeit im Allgemeinen auf die
Wahrung von ACID-Eigenschaften (Atomarität, Konsistenz, Isolation, Dauerhaftigkeit)
verzichtet.
Relationale Datenbanken sowie ihre Alternativen haben Stärken und Schwächen auf
verschiedenen Gebieten. Daher haben sowohl das relationale als auch nicht-relationale Datenbankmodelle ihre Daseinsberechtigung. Es sollte je nach den gegebenen Anforderungen
abgewägt werden, welches Modell am geeignetsten ist [NLIH13] [OGOG+ 11].
Abschließend lässt sich feststellen, dass der Einhaltung von Geschäftsregeln in NoSQLDatenbanken nur eine untergeordnete Rolle zukommt, die Priorität liegt auf der Realisie-
28
3.4 Regeln in NoSQL Datenbanken
rung hoher Leistung über der Wahrung von Konsistenz. Aus diesem Grund soll auf eine
tiefergehende Betrachtung von Regeln in NoSQL-Datenbanken verzichtet werden.
29
4 Datenqualitätsverbesserung
In diesem Kapitel soll untersucht werden wie Datenqualität verbessert werden kann. Die
Betrachtungen sollen dabei auf relationale Datenbanken beschränkt werden. Diese Einschränkung wird getroffen, da das relationale Datenmodell das am weitesten verbreitete
in der Wirtschaft darstellt [SI05] und von den Referenzunternehmen, welche im Rahmen
dieser Masterarbeit analysiert wurden, verwendet wurde. Ausgangsbasis für dieses Kapitel
soll das von Wang vorgestellte Datenqualitätsmanagement-Konzept TDQM sein. Wie
bereits im Abschnitt 2.2 beschrieben, ist kontinuierliches Datenqualitätsmanagement
eine Grundvoraussetzung für eine nachhaltige und effektive Datenqualitätssteigerung.
TDQM besteht aus vier Phasen: Definition, Messung, Analyse, Verbesserung. Folgend
soll untersucht werden wie jede dieser Phasen praktisch umgesetzt werden kann. Es
soll ein konkretes Konzept zur automatisierten Verbesserung von Daten in relationalen
Datenbanken herausgearbeitet werden.
4.1 Definition und Messung von Datenqualität
Messung von Datenqualität ist unverzichtbar, um einschätzen zu können inwieweit Daten
mangelnder Qualität Entscheidungen beeinflussen und um den Erfolg von Verbesserungsmaßnahmen prüfen zu können [Nau07, PLW02]. Auch im Feld der Datenqualität hat die
folgende Aussage des britischen Physikers Lord Thomas Kelvin ihre Gültigkeit [Los10]:
„Was man nicht messen kann, kann man auch nicht verbessern.“
Um eine effektive Messung der Datenqualität durchführen zu können, müssen in der
Definitions-Phase zuerst relevante Dimensionen ausgewählt werden und Anforderungen an Daten in Form von Geschäftsregeln formuliert werden. Von Domänenexperten
muss bestimmt werden, welche Daten was für ein Niveau an Datenqualität in welchen
Dimensionen zu erfüllen haben.
Anschließend muss jede ausgewählte Dimension mit einer oder mehreren konkreten Metriken assoziiert werden, um festzustellen inwieweit die Anforderungen an Datenqualität
erreicht werden [BCFM09, LPFW09].
31
4 Datenqualitätsverbesserung
Die Aufgabe dieses Abschnitts soll es nun sein, geeignete Metriken zur automatisierten
Messung von Datenqualität zu finden. Dazu soll zuerst untersucht werden, welche
Dimensionen dafür grundsätzlich in Frage kommen.
4.1.1 Auswahl von Dimensionen
Nicht alle Dimensionen sind rein technisch messbar, wie etwa unter anderem die „Reputation“ von Daten. Es muss zwischen objektiven und subjektiven Dimensionen unterschieden
werden. Objektive Qualitätsmerkmale sollen an dieser Stelle als technisch Messbar definiert werden, während subjektive Qualitätsmerkmale durch Befragung von Nutzern oder
Experten ermittelt werden müssen. Objektive Dimensionen erlauben die Verwendung
von quantitativen Metriken während subjektive Dimensionen nur qualitativ gemessen
werden können.
Zur Ermittlung qualitativer Messwerte sind einfache Fragebögen oder Kontrollmatrizen
geeignet, welche von Experten auszufüllen sind [Pie04, Nau07]. Die Ermittlung von
subjektiven Messwerten ist unter anderem nützlich, um eventuelle Diskrepanzen im
Vergleich zu objektiv gemessenen Werten festzustellen. Dies erlaubt nützliche Rückschlüsse
über das Niveau an Datenqualität und die Erkennung von verbesserungsbedürftigen
Bereichen [PLW02]. Die Einbindung von qualitativen Dimensionen geht jedoch über
den Rahmen dieser Masterarbeit hinaus. Außerdem ist die Ermittlung von qualitativen
Messwerten nicht automatisierbar.
Daher sollen folgend objektiv messbare Dimensionen zur genaueren Betrachtung
identifiziert werden. Wie bereits in Kapitel 2 diskutiert, gehören Genauigkeit, Konsistenz,
Zeitgerechtigkeit und Vollständigkeit zu den in der akademischen Fachliteratur am meisten
behandelten Dimensionen [SMB05]. Aber auch in der Praxis werden diese Dimensionen
als besonders wichtig erachtet. Sie fanden sich in einer Studie, in der die 25 größten
Unternehmen in Deutschland, Österreich und der Schweiz befragt wurden, unter den 5
am meisten genannten Dimensionen [Hel02]. Alle diese Dimensionen sind zudem objektiv
messbar und sollen daher im Folgenden betrachtet werden.
Eine Dimension für die Messung von Redundanzen wurde bisher noch nicht erwähnt.
Duplikate gehören aber zu den kostspieligsten und wichtigsten Datenfehlern in relationalen Datenbanken [Nau07]. Wegen ihrer Relevanz in relationalen Datenbanken und ihrem
offensichtlichen Einfluss auf die Gesamtqualität der Daten sollen Möglichkeiten zu ihrer
Messung bzw. Erkennung trotzdem angesprochen werden.
Folgend sollen für die ermittelten objektiven Dimensionen Metriken gefunden werden,
um den Datenqualitätsgehalt einer relationalen Datenbank bestimmen zu können. Au-
32
4.1 Definition und Messung von Datenqualität
ßerdem soll diskutiert werden, inwiefern die gefundenen Metriken in dem Kontext einer
relationalen Datenbank automatisierbar und praktisch anwendbar sind.
4.1.2 Metriken zur Messung von Datenqualität
Voraussetzung für die Anwendbarkeit der Metriken ist eine Normalisierung der Ergebnisse.
Dafür bietet sich das Intervall [0,1] an, wobei der Wert 1 das optimale Ergebnis darstellen
soll. Dies ermöglicht sowohl den Vergleich zwischen den Metriken in einer Datenquelle als
auch zwischen verschiedenen Datenquellen. Außerdem ist dies nötig für die Errechnung
von kombinierten oder Gesamtqualitätswerten [Nau07].
Objektive Metriken kommen üblicherweise in drei verschiedenen funktionalen Formen
vor. Diese lauten [PLW02]:
• Einfaches Verhältnis:
Diese Metriken messen das Verhältnis zwischen gewünschten Ergebnissen
und der gesamten Anzahl an Ergebnissen.
• Minimum oder Maximum:
Minimum- oder Maximaloperatoren werden benutzt bei Dimensionen
welche die Aggregation einer Vielzahl an Datenqualitäts-Indikatoren
fordern. Um die Qualität einer bestimmten Dimensionen zu messen, wird
bei dieser Art von Metriken, der Minimal- oder Maximalwert aus allen
gemessenen Einzelwerten ausgewählt.
• Gewichteter Durchschnitt:
Der gewichtete Durchschnitt bietet eine Alternative zur Auswahl eines
Maximal- oder Minimalwertes aus einer Vielzahl von Indikatoren. Diese
Form ist angebracht, wenn ein klares Verständnis über die Wichtigkeit
der einzelnen Indikatoren herrscht.
4.1.2.1 Konsistenz
In relationalen Datenbanken steht Konsistenz für die Einhaltung von Integritätsregeln, die
für bestimmte Felder, Tupel, Attribute oder Relationen definiert wurden. Die spezifizierte
Regelmenge definiert logische Zusammenhänge, welche von der geprüften Datenmenge
eingehalten werden müssen [HGHM11]. Integritätsregeln wurden im Kapitel 3.3 diskutiert.
Das DBMS garantiert jederzeit die Einhaltung der formulierten Integritätsregeln. Daher
33
4 Datenqualitätsverbesserung
ist eine Messung eines Konsistenzgrades nach dieser Prämisse zwecklos, da diese immer
zu 100% erfüllt wäre.
Um aber die Konsistenz von Geschäftsregeln zu messen, die nicht als DatenbankIntegritätsregeln aktiviert sind, kann folgendes Maß verwendet werden [LPFW09]:
Grad an Konsistenz = 1 −
Anzahl der inkonsistenten Einheiten
Anzahl überprüfter Einheiten
Ein Beispiel für eine Geschäftsregel die Konsistenz beschränkt wäre:
„Das Attribut Alter darf nur Integer-Werte zwischen 0 und 120 beinhalten“.
Um den Grad an Konsistenz für diese Regel zu erhalten, müssen alle Felder dieses Attributs
auf die Einhaltung der Regeln hin überprüft werden. Die Anzahl aller konsistenten Felder
dividiert durch die Anzahl der überprüften Felder ergibt dann, von 1 subtrahiert, den
Grad an Konsistenz.
4.1.2.2 Vollständigkeit
Die Dimension der Vollständigkeit kann in relationalen Datenbanken in drei Bereiche
untergliedert werden [PLW02]:
• Tupel-, Attribut- und Relationenvollständigkeit:
Das Ausmaß, in dem Werte in Tupeln, Attributen oder Relationen nicht
enthalten sind.
• Schemavollständigkeit:
Das Ausmaß, in dem benötigte Relationen und Attribute im Schema
nicht enthalten sind.
• Populationsvollständigkeit:
Das Ausmaß, in dem benötige Datensätze im Vergleich zu einer Referenz nicht enthalten sind [BS06], z.B.: Eine Relation die alle Staaten
der Europäischen Union beschreibt, aber keine Einträge für Polen und
Slowenien enthält, besitzt eine mangelnde Populationsvollständigkeit.
Jede der aufgezählten Vollständigkeiten kann mit folgendem einfachen Verhältnis gemessen werden [LPFW09]:
Grad an Vollständigkeit = 1 −
34
Anzahl unvollständiger Einheiten
Anzahl überprüfter Einheiten
4.1 Definition und Messung von Datenqualität
Das Messen von Schemavollständigkeit oder Populationsvollständigkeit, welches einen
Abgleich zu Realweltobjekten erfordern würde, ist in der Regel nicht automatisierbar. Bei
Anwendung auf relationale Datenbanken kann Vollständigkeit aber auch als das Nichtvorkommen von NULL-Werten angesehen werden [BCFM09]. Unter dieser Betrachtung kann
Tupel- oder Attributvollständigkeit am Anteil der NULL-Werten in den beinhalteten
Feldern gemessen werden. Dadurch ergibt sich die folgende angepasste Metrik:
Grad an Tupel/Attributvollständigkeit = 1 −
Anzahl an NULL-Werten
Anzahl überprüfter Felder
Durch entsprechende Aggregation kann zusätzlich die Relationenvollständigkeit ermittelt
werden, siehe Abschnitt 4.1.2.6. Dabei ist zu beachten, dass wie bereits diskutiert,
NULL-Werte verschiedene Bedeutungen haben können. Nicht jedes Vorkommen eines
NULL-Wertes signalisiert automatisch eine Unvollständigkeit. Ein NULL-Wert kann
die Repräsentation für einen Wert sein, der in der Realwelt nicht existiert. In diesem
Fall repräsentiert ein NULL-Wert eine wertvolle Information und keinen fehlenden Wert.
Daher ist eine Voraussetzungen für eine zuverlässige Messung der Vollständigkeit nach
diesem Prinzip, dass in der Realwelt nicht vorkommende Angaben nicht mit NULL-Werten
gekennzeichnet werden, sondern mit eindeutigen, unmissverständlichen Werten. Eine
nicht-existierende Telefonnummer könnte beispielsweise mit der Zeichenkette „Existiert
nicht“ anstatt mit NULL repräsentiert werden [SMB05].
Ein weiteres Problem stellen sogenannte Dummy-Werte dar. Um Eingabekontrollen
oder entsprechende Integritätsregeln zu umgehen, können Nutzer Standard-Werte eintragen, z.B. bei einer unbekannten Telefonnummer „000-0000000“. Ein solcher Dummy-Wert
stellt somit ebenfalls Unvollständigkeit dar [HGHM11].
Die Daten müssen vor der Anwendung einer Vollständigkeitsmetrik auf das Vorhandensein der erwähnten Probleme untersucht werden. Dummy-Werte können entsprechend
markiert werden und in der Metrik als Repräsentation für Unvollständigkeit berücksichtigt werden. NULL-Werte als Repräsentation für Nichtexistenz in der Realwelt sind zu
beseitigen.
4.1.2.3 Genauigkeit
Genauigkeit ist definiert als der Abstand eines in der Datenbank gespeicherten Wertes v
zu einem genauen Wert v’. Häufig ist v’ ein Realweltobjekt, das beschrieben werden soll.
Eine mögliche Metrik, um Genauigkeit zu messen ist:
Grad an Genauigkeit = 1 −
Anzahl ungenauer Einheiten
Anzahl überprüfter Einheiten
35
4 Datenqualitätsverbesserung
Hierbei muss definiert werden, was konkret eine genaue bzw. ungenaue Einheit ausmacht.
Es ist vorstellbar, dass in bestimmten Fällen kleine Abweichung tolerierbar sind und
nicht ein ungenaues Datum bedeuten. Die Metrik ist also kontextabhängig [LPFW09].
Zur Messung der syntaktischen Genauigkeit einzelner Felder kann beispielsweise ein
Distanzmaß verwendet werden, welches beschreibt, wie entfernt das gespeicherte Datum
von seinem genauen Gegenstück ist. Ein mögliches Distanzmaß für die Untersuchung
von Zeichenketten ist beispielsweise der Editierabstand. Mit dem Editierabstand kann
gemessen werden wie viele Löschungen, Verschiebungen oder Ersetzungen nötig sind,
um eine ungenaue Zeichenkette in eine genaue Zeichenkette zu transformieren. Um
beispielsweise die Zeichenkette „Erlangn“ zu korrigieren, ist die Einsetzung eines „e“
nötig, damit beträgt das Distanzmaß „1“.
Bei der Messung von semantischer Genauigkeit macht ein Distanzmaß weniger Sinn,
hierbei ist eine boolesche Aussage angebracht. Stimmt ein Wert mit seinem Gegenstück
nicht überein, ist er schlicht semantisch ungenau [BS06].
Die eindeutige Messung von Genauigkeit fordert also immer einen Abgleich mit einem
genauen Wert, entweder in einer anderen Datenbank oder in der Realwelt. In der Praxis
gestaltet sich dies schwierig. Der Abgleich des gesamten Datenbestands mit Werten in der
Realwelt ist in der Regel zu teuer und aufwendig bzw. gar unmöglich. Eine Alternative
ist die Anwendung von Stichprobenuntersuchungen. Durch Extrapolation kann dann ein
Schätzwert für die Genauigkeit des untersuchten Datensatzes abgegeben werden. Bei
der Annahme, dass Fehler selten sind, kann die Verwendung von Outlier-Analysen eine
Alternative sein. Dabei werden Werte, die sich stark von den durchschnittlichen Werten
unterscheiden, markiert und einem Experten zu weiteren Untersuchen vorgelegt. Dadurch
können unter anderem auch Genauigkeitsprobleme aufgedeckt werden. Diese Methode
kann aber nicht für alle Daten angewandt werden. Daten, die in einer Datenbank in der
Regel eindeutig sind, wie z.B. E-Mail-Adressen oder Telefonnummern, können damit nicht
auf Genauigkeit geprüft werden. Außerdem erfordern beide vorgestellten Alternativen
signifikanten manuellen Einsatz und sind nicht vollständig automatisierbar.
Eine Möglichkeit dennoch zumindest einen Anteil an syntaktischen Genauigkeitsfehlern
automatisch aufzudecken, ist die umfangreiche Anwendung von Integritätsregeln. Diese
können die Einhaltung von bestimmten Formaten verifizieren oder über Bereichseinschränkungen z.B. die Plausibilität von bestimmten Werten überprüfen. Semantische
Fehler sind aber auch über diesen Weg nicht zu erkennen. Daraus folgt, dass eine zuverlässige und automatisierte Überprüfung der Genauigkeit nur möglich ist, wenn eine
Referenzdatenbank mit genauen Werten zum Abgleich zur Verfügung steht.
36
4.1 Definition und Messung von Datenqualität
4.1.2.4 Zeitgerechtigkeit
Zeitgerechtigkeit misst, wie aktuell Daten sind, um für einen bestimmten Zweck brauchbar
zu sein. Ballou et al. bringen Zeitgerechtigkeit in folgenden mathematischen Zusammenhang [BWPT98]:
n
Zeitgerechtigkeit = max
h
1−
Aktualität
Gültigkeitsdauer
ios
,0
Die Metrik enthält drei einzusetzende Variablen:
1. Aktualität:
Aktualität ist hier definiert als das Alter der Daten vom Ermittlungszeitpunkt bis zum Zeitpunkt ihrer Nutzung. Der Ermittlungszeitpunkt
beschreibt den Zeitpunkt des Erhalts von Daten, dieser ist dabei nicht
zwangsläufig derselbe wie der Zeitpunkt der Aufzeichnung der Daten im
System.
2. Gültigkeitsdauer:
Gültigkeitsdauer ist die Zeitspanne in der Daten valide bleiben. Sie beschreibt, wie oft sich Daten ändern. Ein Geburtsdatum hat beispielsweise
eine unbeschränkte Gültigkeitsdauer, da es sich nie ändert - während
Börsenkurse eine sehr kurze Gültigkeitsdauer haben. Zeitgerechtigkeit ist
normalisiert auf das Intervall [0,1], 1 entspricht dem besten während 0
dem schlechtesten Wert entspricht. Daten mit einer niedrigen Gültigkeitsdauer müssen entsprechend eine hohe Aktualität bzw. ein niedriges Alter
aufweisen, um einen hohen Zeitgerechtigkeits-Wert zu erhalten. Je länger
die Gültigkeitsdauer, desto älter bzw. inaktueller können Daten sein. Die
Gültigkeitsdauer ist in der Metrik von Ballou et al. außerdem eine harte
Grenze. Egal, ob das Alter der Daten die Gültigkeitsdauer um 1% oder
100% überschreitet, es ergibt sich stets der niedrigste ZeitgerechtigkeitsWert 0. Die Gültigkeitsdauer kann über empirische Untersuchungen oder
Expertenschätzungen ermittelt werden.
3. s:
Der Exponent s (s ≥ 0) erlaubt eine Einstellung der Sensitivität, er
ist kontextabhängig und muss von einem Domänenexperten festgelegt
werden. Liegt die errechnete Zeitgerechtigkeit beispielsweise bei 0.7, wird
diese unter Anwendung einer Sensitivität von 2 auf 0.49 reduziert. Bei
37
4 Datenqualitätsverbesserung
Anwendung eines Faktors von 0.5 dagegen, wird die Zeitgerechtigkeit auf
0.84 erhöht. Ein höherer Faktor beschreibt also einen schnelleren Verfall
der Daten während eine niedrigerer Faktor bedeutet, dass Daten länger
aktuell bleiben [PLW02].
Die oben vorgestellte Metrik von Ballou et al. ist abhängig von der Aufzeichnung des
Ermittlungszeitpunkts von Daten als Metainformation. Dies stellt einen zusätzlichen
Aufwand an den Nutzer dar und bedingt ein hohes Bewusstsein für die Wichtigkeit von
Datenqualität.
Nicht alle Organisationen und Domänen benötigen aber derart präzise Metriken.
Ist bekannt, dass kein signifikanter Unterschied zwischen Ermittlungszeitpunkt und
Eintragungszeitpunkt besteht, ist die Errechnung der Aktualität der Daten aus Eintragungszeitpunkt und Zeitpunkt der Nutzung ausreichend präzise. Ein Indikator für die
Verfallsdauer könnte aus der Update-Häufigkeit der Daten ermittelt werden. Verändern
sich z.B. Felder in einem Attribut durchschnittlich 10 Mal im Jahr während ein Feld seit
einem Jahr unverändert geblieben ist, ist dies ein Hinweis für eine mögliche Veralterung.
Diese Methode kann allerdings nur angewandt werden, wenn davon ausgegangen werden
kann, dass inaktuelle Daten selten vorkommen. Je größer der Anteil an inaktuellen
Feldern in einem Attribut, desto ungenauer und unbrauchbarer ist diese Methode, um
die absolute Zeitgerechtigkeit ableiten zu können. Der Domänenexperte muss abschätzen
können, welcher Grad an Präzision nötig ist. In einigen Fällen kann auch schon das
einfache Alter der Daten ein ausreichender Indikator für die Zeitgerechtigkeit der Daten
sein [BS06, LPFW09].
Abschließend ist festzuhalten, dass die vorgestellten Vereinfachungen zu der Metrik von
Ballou et al. nur Indikatoren für Zeitgerechtigkeit darstellen können. Um die Zeitgerechtigkeit präzise zu berechnen, muss die Metrik von Ballou et al. mit sorgfältig ermittelten
Werten für Ermittlungszeitpunkt und für die Gültigkeitsdauer angewandt werden.
4.1.2.5 Redundanzfreiheit
Duplikate kommen vor, wenn ein und dasselbe Realweltobjekt mehrmals in einer Datenbank gespeichert wird. Ein typisches Beispiel für zusätzliche Kosten, die mit Duplikaten
verbunden sind, ist das mehrfache Zustellen eines Briefes zum gleichen Kunden für
den fälschlicherweise mehrere Datensätze geführt werden [BS06]. Potentiell kostspieliger
als die Verursachung unnötiger Portokosten für Briefe wäre das doppelte Versenden
von Industriemaschinen oder die Gewährung einer ungewünschten Überziehung eines
Kreditrahmens durch einen Dublettenfehler.
38
4.1 Definition und Messung von Datenqualität
Ein naiver Ansatz zur Duplikatserkennung wäre der paarweise Vergleich aller Tupel in
einer Datenbank. Der damit verbundene quadratische Aufwand wäre nur bei sehr kleinen
Datenbanken tolerierbar. Es bedarf Algorithmen, die dies umgehen [Nau07]. Dies kann
beispielsweise mit einem Sorted-Neighbourhood-Algorithmus erreicht werden. Hierbei
werden Tupel zuerst nach Ähnlichkeit sortiert und danach nur die Tupel miteinander
verglichen, die innerhalb eines bestimmten Maximalabstands zueinander stehen [HS98].
Das Aufspüren von 100% Duplikaten, also Tupeln mit identischen Feldern, ist über
eine einfache SQL-Anfrage realisierbar [LPFW09]:
SELECT COUNT (DISTINCT eMail)
FROM CUSTOMER;
Durch die Differenz zwischen der Anzahl aller Einträge und der eindeutigen Einträge
lässt sich somit die Anzahl der Dubletten ermitteln. Eine entsprechend einfache Metrik
für Redundanzfreiheit ist:
Redundanzfreiheit = 1 −
Anzahl der Dubletten
Anzahl überprüfter Einheiten
In den meisten Fällen ist die Suche nach identischen Feldern allerdings nicht ausreichend.
Nicht alle Dubletten sind auf diese Weise erkennbar, auch leicht abweichende Einträge
können auf Duplikate hinweisen. Dubletten können dasselbe Realweltobjekt repräsentieren
sich aber dennoch in einigen Feldern unterscheiden. Es kann beispielsweise vorkommen,
dass durch Tipp- oder Hörfehler bei Erfassung von Namen, Kunden mehrfach angelegt
werden. Auch das Verwenden von uneinheitlichen Abkürzungen kann zu Dubletten führen,
z.B. „Frankfurt a.M.“ und „Frankfurt am Main“ [HGHM11].
Zur effektiven Erkennung von Duplikaten muss daher ein Ähnlichkeitsmaß bestimmt
werden. Übersteigen zwei Tupel einen Schwellwert an Ähnlichkeit werden sie als potentielles Duplikat markiert. Die Bestimmung eines geeigneten Ähnlichkeitsmaßes ist
stark domänenabhängig und muss von einem Experten vollzogen werden [Nau07]. Ein
mögliches Ähnlichkeitsmaß ist der schon erwähnte Editierabstand.
4.1.2.6 Aggregierung der Metriken
Alle bisher vorgestellten Metriken, bis auf Redundanzfreiheit, können sowohl auf Attributsals auch Tupelebene angewandt werden. Durch entsprechende Aggregierung der Attributsoder Tupelebene können Messwerte für die Relations- und Datenbankebene bestimmt
39
4 Datenqualitätsverbesserung
werden. Die Prüfung auf Dubletten macht nur auf Attributs-, Relations- oder Datenbankebene Sinn.
Das Vorgehen zur Aggregierung soll am Beispiel der Metrik für Zeitgerechtigkeit gezeigt
werden:
n
Zeitgerechtigkeit = max
h
1−
Aktualität
Gültigkeitsdauer
ios
,0
In diesem Fall bezieht sich die vorgestellte Metrik auf ein einzelnes Feld. Durch Summierung der Einzelwerte kann die Zeitgerechtigkeit pro Attribut oder Tupel wie folgt
errechnet werden:
Zeitgerechtigkeit je Attribut/Tupel =
Pn
i=1
M (Fi )
n
Die erwähnte Metrik für Zeitgerechtigkeit je Feld wird hier als M zusammengefasst,
während Fi für ein bestimmtes Feld steht. Um die Zeitgerechtigkeit je Attribut zu
bestimmen, werden hier also die Zeitgerechtigkeits-Werte aller n-Felder eines Attributs
summiert und durch die Anzahl aller Felder im Attribut geteilt. Analog kann auch die
Zeitgerechtigkeit je Tupel errechnet werden.
Die Zeitgerechtigkeit je Relation lässt sich durch Aggregierung der aggregierten Tupeloder Attributszeitgerechtigkeits-Werte wie folgt bestimmen:
Zeitgerechtigkeit je Relation =
Pm
j=1
A(Sj )
m
Hierbei steht A für die Metrik zur Aggregierung von Zeitgerechtigkeit auf Tupeloder Attributsebene und Sj für ein bestimmtes Tupel oder Attribut. Es werden also
alle Attributszeitgerechtigkeits-Werte oder Tupelzeitgerechtigkeits-Werte summiert und
durch die Anzahl der m-Attribute oder Tupel in einer Relation geteilt.
Die Ermittlung der Zeitgerechtigkeit für die gesamte Datenbank erfolgt auf dieselbe
Weise durch Aggregierung der Zeitgerechtigkeits-Werte je Relation. Analog können alle
in diesem Unterkapitel vorgestellten Metriken aggregiert werden.
Zusätzlich dazu kann man bei der Aggregierung jedes Attribut, Tupel oder Relation
mit einem Gewicht zwischen 0 und 1 versehen. Dadurch lässt sich die Relevanz einer jeden
Einheit bestimmen. Bei Untersuchung von Daten für eine telefonische Kundenumfrage
wäre z.B. das Attribut „Telefonnummer“ von höchster Wichtigkeit, dem Nachnamen und
der Anrede des Ansprechpartners würde ebenfalls hohe Relevanz zukommen. Attribute
bezüglich Adressdaten wären dagegen unwichtig.
40
4.1 Definition und Messung von Datenqualität
4.1.3 Fazit
Das Messen von Datenqualität ist unverzichtbare Grundlage für ihre nachhaltige Verbesserung. Die Ergebnisse dieses Abschnitts haben aber gezeigt, dass nicht alle Dimensionen
objektiv erfassbar und quantifizierbar sind. Auch die Messung von objektiven Dimensionen ist nicht immer ohne weiteres möglich und bedarf Voraussetzungen, siehe Tabelle 4.1.
Die Dimension der Genauigkeit ist praktisch am schwierigsten messbar, da das VorhanDimension
Genauigkeit
Zeitgerechtigkeit
Konsistenz
Tupel-, Attribut- und Relationenvollständigkeit
Populations- und Schemavollständigkeit
Redundanzfreiheit
Voraussetzungen
Genaue Referenzdaten
Genaue Metadaten
Vollständiger Regelsatz
Vollständiges Schema und Klarheit über
Bedeutung von NULL-Werten
Genaue Referenzdaten
Genaues Ähnlichkeitsmaß
Tabelle 4.1: Voraussetzungen für die Messbarkeit von Datenqualitätsdimensionen
densein umfangreicher genauer Referenzdaten nicht vorrausetzbar ist. Als Alternative
bleibt die Bewertung durch manuelle Stichprobenuntersuchungen.
Kennzahlen für die Bewertung der Zeitgerechtigkeit sind stark von genauen Metadaten
abhängig, welche das Alter der Daten und ihre Gültigkeitsdauer beschreiben. Je ungenauer
die Metadaten, desto ungenauer ist die sich ergebende Messung.
Die Güte der Messung für Konsistenz hängt von der Vollständigkeit der Regelmenge ab,
welche die logischen Zusammenhänge in den Daten beschreibt. Der Grad der Einhaltung
der Regelmenge ist in relationalen Datenbank aber vollständig automatisiert messbar.
Voraussetzung für die Messung von Populations- oder Schemavollständigkeit ist das
Vorhandensein genauer Referenzdaten, wodurch das automatisierte Messen in der Regel
nicht möglich ist. Unter der Annahme, dass Vollständigkeit als das Vorhandensein
von NULL-Werten betrachtet wird, ist aber die automatische Messung von Tupel-,
Attribut- und Relationenvollständigkeit möglich. Die Güte der Messung ist hierbei vom
Vorhandensein aller nötigen Attribute und Relationen im Schema und einem klaren
Verständnis über die Bedeutung der enthaltenen NULL-Werte abhängig.
Zur Messungen oder Beseitigung von Redundanzen existiert eine Vielzahl von automatisierten Methoden. Ihre Effektivität hängt üblicherweise von der genauen Definition
eines Ähnlichkeitsmaßes ab. Eine vollständige Bewertung der Methoden zur Beseitigung
41
4 Datenqualitätsverbesserung
von Redundanzen geht über den Rahmen dieser Masterarbeit hinaus. Eine umfangreiche
Zusammenfassung aktueller Methoden findet sich in [BS06].
Abschließend ist festzustellen, dass sich zahlreiche Hindernisse für die automatisierte
Messung der ausgewählten Dimensionen ergeben. Allerdings ist nach Redman kein
Messungssystem perfekt. Es existieren immer wichtige Kennzahlen, die nicht erfasst
werden können. Dennoch sind Messungen bei Datenqualitätsprojekten unverzichtbar.
Ein Messungssystem kann eine sachliche Basis für Managemententscheidungen schaffen.
Durch umfangreiches Domänenwissen können Daten aus Messwerten interpretieren und
ergänzt werden. Messungen können Ungewissheiten reduzieren und Domänenexperten
nützliche Hinweise und eine Richtung vorgeben [Red97].
4.2 Analyse und Verbesserung von Datenqualität
Nach der Festlegung von Anforderungen und der Anwendung von geeigneten Metriken gilt
es, die gewonnenen Erkenntnisse zu analysieren. Wurden qualitative Mängel identifiziert,
muss zur Verbesserung dieser gezielt analysiert werden, wodurch die Fehler entstanden
sind. Danach müssen die geeignetsten Maßnahmen, zu deren Beseitigung oder zukünftigen
Verhinderung ausgewählt werden. Eine aktive Verbesserung ist allerdings nicht immer
möglich, wenn z.B. Daten aus externen Quellen stammen und keine volle Kontrolle über
die Daten besteht. Die Alternative ist dann der bewusste Umgang mit Datenmängeln
[Nau07, HGHM11].
Nachfolgend sollen Möglichkeiten zur aktiven Verbesserung der Daten betrachtet
werden.
4.2.1 Maßnahmen zur Verbesserung von Datenqualität
Es existieren zwei verschiedene grundlegende Maßnahmenkategorien zur Verbesserung
von Datenqualität. Unter die erste Kategorie fallen datengetriebene Maßnahmen, welche
die Bereinigung bereits existierender Fehler zum Ziel haben. Die zweite Kategorie dagegen
beinhaltet prozessgetriebene Maßnahmen, welche die Verhinderung zukünftiger Fehler
zum Ziel haben [BCFM09]. Folgend sollen beide Kategorien charakterisiert werden.
42
4.2 Analyse und Verbesserung von Datenqualität
4.2.1.1 Datengetriebene Maßnahmen
Datengetriebene Maßnahmen haben gemeinsam, dass ein Abgleich von Daten zu Referenzobjekten stattfindet, die als korrekt erachtet werden. Daten können mit der Realwelt,
anderen Daten oder Regeln abgeglichen werden [Red97]:
• Vergleich zu Realweltobjekten:
Ein Abgleich von Daten mit ihren Realweltentsprechungen muss zur
Datenqualitätsverbesserung zwangsläufig angewandt werden, wenn es
keine Möglichkeit zur automatischen Ermittlung oder Ausbesserung der
inkorrekten Daten gibt. Werden Datenqualitätsmängel beispielsweise
durch fehlende Kunden-Adressen hervorgerufen, werden diese in den
meisten Fällen über direkte Kontaktaufnahme mit den betreffenden
Kunden beschafft werden müssen. Die Verbesserung von Daten durch
Vergleich zu Realweltobjekten lässt sich schwierig automatisieren und
bringt daher einen relativ großen manuellen Aufwand mit sich.
• Vergleich zu Datenbankobjekten:
Bei dieser Technik werden Datenbankobjekte mit anderen internen oder
externen Datenbankobjekten verglichen, um auf diese Weise Inkonsistenzen ausfindig zu machen.
Der Vergleich mit internen Datenbankobjekten ist vor allem zur Deduplizierung geeignet. Tupel werden hierbei mit anderen Tupeln innerhalb
derselben Datenbank verglichen. Duplikate werden bei diesem Vergleich
mit Hilfe von Ähnlichkeitsmaßen ausfindig gemacht.
Der Abgleich zu externen Datenbankobjekten kann zur generellen
Beseitigung von Mängeln genutzt werden. Hier findet ein Abgleich
zwischen den Objekten in einer Datenbank mit Objekten in einer
Referenzdatenbank statt, welche die gleichen Realweltobjekte beschreibt. Es handelt sich um eine relativ schnelle und effiziente
Methode. Unterscheidet sich ein Eintrag zwischen den Datenbanken kann dieser markiert und später einer genaueren Untersuchung
unterzogen werden oder direkt aus der Referenzdatenbank übernommen werden. Dabei besteht aber das Risiko, dass die Referenzdatenbank möglicherweise ebenfalls Daten mangelnder Qualität speichert.
43
4 Datenqualitätsverbesserung
• Vergleich zu Regeln:
Durch den Abgleich von Daten zu Regeln können vor allem inkonsistente
Daten erkannt werden. Die Möglichkeiten zur Anwendung von Regeln
sind vielfältig. Durch Anwendung von Datenbank-Integritätsregeln und
der Untersuchung von Abhängigkeiten, lassen sich die Korrektheit der
Daten oder die Einhaltung von Geschäftsregeln überprüfen. Es bedarf
Expertenwissens und einer genauen Analyse der Daten, um eine Menge
von Regeln zu entwickeln, welche den Großteil möglicher Fehler abdeckt.
Diese Regeln können sowohl bei prozessgetriebenen als auch bei datengetriebenen Maßnahmen verwendet werden. Bei datengetriebenen
Maßnahmen wird die Regelmenge auf die Daten angewandt, um fehlerhafte Daten zu erkennen und zu markieren. Die markierten Daten
werden dann von Experten betrachtet und korrigiert.
Das Prinzip von datengetriebenen Maßnahmen ist der Vergleich von Daten zu anderen
Objekten. Daten, die beim Vergleich auffallen, werden markiert und anschließend korrigiert. Bei dieser Klasse von Maßnahmen handelt es sich aber immer um eine nachträgliche
Korrektur bestehender Fehler.
4.2.1.2 Prozessgetriebene Maßnahmen
Zur Ergänzung datengetriebener Maßnahmen bietet sich die Kategorie der prozessgetriebene Maßnahmen an. Im Gegensatz zu datengetriebenen Maßnahmen, welche
eine nachträgliche Beseitigung von Fehlern beabsichtigen, beschreiben prozessgetriebene
Maßnahmen Möglichkeiten zur Verhinderung zukünftiger Fehler.
Diese Kategorie beinhaltet Maßnahmen zur Umgestaltung von Prozessen, Verbesserung
von Systemen und den Einsatz von Regeln und Abhängigkeiten [Red97, BCFM09,
HGHM11]:
• Verwendung von Integritätsregeln:
Datenbankregeln und Prozeduren können sicherstellen, dass Daten definierte Geschäftsregeln einhalten. Als Grundlage dafür können dieselben
Datenqualitätsregeln wie zur Datenqualitätsmessung benutzt werden.
Regeln erlauben die Einhaltung von Bedingungen verschiedener Komplexität, darunter:
– Formatsbeschränkungen (z.B. Das Attribut PLZ muss aus 5 Ziffern
bestehen)
44
4.2 Analyse und Verbesserung von Datenqualität
– Bereichsbeschränkungen (z.B. Das Attribut Alter darf nur Werte
zwischen 0 und 120 beinhalten)
– Datenfeldkombinationen und Abhängigkeiten (z.B. Zur Markierung
unwahrscheinlicher Daten wie [Alter=21, Größe=120cm])
Daten welche die formulierte Regelmenge nicht befriedigen, werden vom
DBMS abgewiesen. Daten mangelnder Qualität werden so in der Datenbank gar nicht erst gespeichert. Bei Eingabe von unbefriedigenden Daten
wird der Nutzer dazu aufgefordert seine Eingaben anzupassen oder die
Eingabedaten zu überprüfen. Eine Korrektur ist zu diesem Zeitpunkt
effektiver und kostengünstiger durchzuführen als nachträglich. Der Kontext der Erfassung ist zu diesem Zeitpunkt noch aktuell, welches eine
einfachere Klärung von Zweifeln erlaubt. Besonders wenn zum Zeitpunkt
der Dateneingabe Kundenkontakt besteht, z.B. bei einem telefonischen
Verkaufsgespräch, ist es wesentlich effektiver eventuelle Inkonsistenzen
direkt zu klären als durch eine nachträgliche Recherche.
• Verwendung von Abhängigkeiten:
Aktuell besteht in der Literatur ein gesteigertes Interesse bei der Erforschung von Abhängigkeiten zur Verbesserung von Datenqualität. Resultat
davon ist eine Erweiterung der klassischen funktionalen Abhängigkeiten,
um eine größere Anzahl an Fehlern und Mängeln einzufangen [Fan08].
Funktionale Abhängigkeiten stellen Bedingungen an mögliche gültige
Ausprägungen des Datenbankschemas dar [KE11]. In einer Relation die
beispielsweise Adressen aufzeichnet ist der Name der Stadt funktional
von der Postleitzahl abhängig. Funktionale Abhängigkeiten werden wie
folgt dargestellt:
α→β
Alpha und Beta repräsentieren Mengen von Attributen. Die Werte in einer
Menge von Attributen bestimmen, welche möglichen Ausprägungen die
Werte in der anderen Menge besitzen dürfen. Wenn zwei Tupel identische
Werte in α besitzen, dann müssen auch ihre Werte in β übereinstimmen.
Funktionale Abhängigkeiten sind ein zentrales Konzept in der relationalen
Entwurfstheorie. Die funktionalen Abhängigkeiten in Daten spielen eine
entscheidende Rolle bei Schemaentwurf und der Normalisierung von
Relationen [KE11, GMUW09].
45
4 Datenqualitätsverbesserung
Abhängigkeiten sind auch zum Zwecke der Datenqualitätsverbesserung
hilfreich. Sie erlauben es, die Semantik von Daten deklarativ zu beschreiben. Inkonsistenzen und Fehler können als Verletzungen der Abhängigkeiten erkannt werden [Fan08].
Die oben vorgestellten funktionalen Abhängigkeiten wurden allerdings
hauptsächlich zum Schemaentwurf entwickelt. Sie sind im Kontext von
Datenqualität nicht ausdrucksstark genug und bieten häufig nicht ausreichende Mittel um alle relevanten Probleme zu beschreiben. Im obigen
Beispiel wurde P LZ → Stadt als mögliche funktionale Abhängigkeit
vorgestellt. In Großbritannien bestimmt die PLZ neben der Stadt aber
auch die Straße. Da funktionale Abhängigkeiten für alle Tupel in einer Tabelle gelten, ist diese Abhängigkeit nicht ausdrückbar, falls in
dieser Relation nicht ausschließlich großbritannische Adressen vorkommen. Die Lösung für dieses Problem stellt die Einführung konditionaler
funktionaler Abhängigkeiten dar, diese gelten nur für eine Untermenge
einer funktionalen Abhängigkeit [BFG+ 07]. Dadurch lässt sich die vorher
erwähnte Abhängigkeit nun folgendermaßen ausdrücken:
[P LZ, Land = GB] → [Straße, Stadt]
Auch komplexere Geschäftsregeln wie „Alle Kunden, die für über 100€
einkaufen, bekommen 10% Rabatt“ lassen sich auf diese Weise deklarativ
formulieren:
[Einkauf ssumme > 100€] → [Rabatt = 10%]
Durch Anwendung von konditionalen Abhängigkeiten können Datenmängel erkannt und verhindert werden. Domänenexperten können auf dieser Basis Regeln formulieren die Eingaben von Benutzern einschränken. Offensichtlich inkonsistente Einträge wie
z.B.: [P LZ = 12345] → [Stadt = Erlangen] können direkt abgelehnt werden. Einträge, die unwahrscheinlich sind, wie z.B.:
[Alter = 17] → [Jahresgehalt > 50.000] können als solche markiert und einem Experten zu näheren Untersuchung vorgelegt werden
[CM08]. Diese Abhängigkeiten können in einer relationalen Datenbank
über Trigger implementiert werden. Sie müssen entweder von Domänenexperten erkannt werden oder können über bestimmte Werkzeuge zur
46
4.2 Analyse und Verbesserung von Datenqualität
Datenanalyse ausfindig gemacht werden.
• Erhöhung der Benutzerfreundlichkeit:
Eine weitere Gruppe von Möglichkeiten zur Systemoptimierung sind Maßnahmen zur Verbesserung der Gebrauchstauglichkeit von Eingabeprozeduren. Darunter fällt die Verbesserung von Anwendungsprogrammen
zur Eingabe von Daten oder auch die Vermeidung manueller Eingaben
durch z.B. die Verwendung von Barcode-Lesern. Eine unübersichtliche
Gestaltung der Nutzeroberflächen oder eine unlogische Anordnung von
Eingabefeldern in Anwendungsprogrammen kann zu Datenfehlern beitragen. Fragt ein Eingabedialog zur Aufnahme von Patientendaten zum
Beispiel zuerst den Vornamen und dann den Nachnamen des Patienten
ab, während ein weiterer Eingabedialog im selben System die Namensdaten in umgekehrter Reihenfolge abfragt, kann dies unnötig Fehler
provozieren.
• Prozessoptimierung:
Maßnahmen zur Prozessoptimierung beschäftigen sich mit der Umgestaltung von Prozessen, die zu unbefriedigenden Daten geführt haben. Dazu
gehören unter anderem:
– Die Umgestaltung von Verantwortungen
– Die räumliche Umverteilung von zusammenarbeitenden Organisationseinheiten
– Die Erhöhung der zur Verfügung stehenden Ressourcen
– Die Ergreifung von Schulungsmaßnahmen für Mitarbeiter
Die Optimierung von Prozessen ist die aufwendigste Gruppe von Maßnahmen zur Verbesserung von Datenqualität. Allerdings werden Fehler damit
an ihrer Wurzel beseitigt und es besteht die Chance eine Reihe positiver
Nebenwirkung zu realisieren. Die Prozessoptimierung hat das Potential die Produktivität von Organisationen zu erhöhen, Prozesskosten zu
senken und Durchlaufzeiten zu verbessern.
47
4 Datenqualitätsverbesserung
4.2.1.3 Bewertung der Maßnahmen
Die Anwendung datengetriebener Maßnahmen ist kurzfristig gesehen kostengünstiger als
die Anwendung von prozessgetriebenen Maßnahmen. Die Analyse von möglichen Ursachen
für Fehler, die Umgestaltung von Prozessen sowie der Entwurf eines Regelsatzes, der in
der Lage ist, zukünftige Fehler zu vermeiden, stellen alles Aktivitäten dar, die wesentlich
anspruchsvoller und aufwändiger sind als einmalige punktuelle Reinigungen. Aus diesen
Gründen entstehen durch prozessgetriebene Maßnahmen in der Regel höhere Kosten
als durch datengetriebene Maßnahmen. Prozessgetriebene Ansätze sind im Allgemeinen
dafür deutlich effektiver als datengetriebene Ansätze, da sie das Problem an der Wurzel
angehen. Je nach Art und Weise der Fehler muss abgewägt werden, welche Gruppe von
Maßnahmen am besten geeignet ist.
Für die beschriebenen Maßnahmen können drei verschiedene Vorgehensweise im Management von Datenqualitätsprojekten erkannt werden:
• Proaktives Vorgehen:
Beim proaktiven Vorgehen werden neben einer initialen Bereinigung
von Mängeln auch Maßnahmen zur Verhinderung der Entstehung der
Fehler getroffen. Es findet eine kontinuierliche Überwachung auf mögliche
Mängel statt sowie eine kontinuierliche Ergreifung von Maßnahmen zu
deren Beseitigung und Verhinderung.
• Reaktives Vorgehen:
Reaktives Vorgehen bedeutet die einmalige Bereinigung eines bestimmten
Datenqualitätsproblems. Es werden keine Maßnahmen zur Verhinderung
der Fehler getroffen.
• Laissez-Faire:
Bei der Laissez-Faire Vorgehensweise werden keine besonderen Maßnahmen ergriffen, um Fehler zu beseitigen. Fehler werden unsystematisch
korrigiert wenn sich die Gelegenheit dazu ergibt oder wenn konkrete
Beschwerden eintreffen. Dann werden nur speziell die Fehler beseitigt
welche die Beschwerde hervorgerufen haben [Red97].
Ein proaktives Vorgehen ist offensichtlicherweise die sicherste Methode, um eine hohe Datenqualität zu garantieren. Je nach Art der Fehler können zufriedenstellende Ergebnisse
allerdings auch mit den weniger kostspieligen und aufwendigen reaktiven oder LaissezFaire Vorgehensweisen erreicht werden. Es ist nötig, mögliche Verbesserungsmaßnahmen
48
4.2 Analyse und Verbesserung von Datenqualität
zu bewerten. Die Wahl des optimalen Vorgehens hängt von der Änderungshäufigkeit
der Daten und ihrer Bedeutung für den Nutzer ab, wie in Abbildung 4.1 dargestellt.
Die Bedeutung der Daten wird von den spezifischen Geschäftsprozessen einer Orga-
Bild 4.1: Maßnahmen Portfolio [Red97]
nisation bestimmt. Quantifizieren lässt sich diese z.B. durch die Summe an Kosten,
welche durch eventuelle Qualitätsmängel in diesen Daten hervorgerufen würden. Datenfehler können je nach ihrer Art unter anderem zu Imageschäden, Zusatzaufwänden oder
Fehlentscheidungen führen.
Aus der Änderungshäufigkeit der Daten kann abgeleitet werden, wie lange es dauert
bis Daten nach einer initialen Bereinigung wieder bei dem mangelnden anfänglichen
Datenqualitätsniveau angelangt sind.
Die Abbildung 4.1 zeigt, dass eine proaktive Vorgehensweise umso lohnender ist,
je häufiger sich Daten ändern. Die kumulierten Kosten für punktuelle Bereinigungen
steigen mit der Frequenz von Datenänderungen. Je häufiger diese angewandt werden
müssen, desto geringer ist der dadurch ersparte Zeit- und Kostenaufwand gegenüber
einer proaktiven Vorgehensweise. Wohingegen bei statischen und unkritischen Daten
selbst eine Laissez-Faire-Vorgehensweise ausreichend sein kann.
Die Entscheidung für den Einsatz einer bestimmten Vorgehensweise muss von einem
Domänenexperten getroffen werden, welcher mit den Geschäftsprozessen seiner Orga-
49
4 Datenqualitätsverbesserung
nisation vertraut ist und bewerten kann, in wie fern Qualitätsmängel diese negativ
beeinflussen würden [Red97, BCFM09, Eng99, HGHM11].
4.2.2 Verbesserung von Datenqualitätsdimensionen
Folgend soll untersucht werden wie die in diesem Kapitel beschriebenen Maßnahmen
zur Verbesserung der vorher ausgewählten Dimensionen in relationalen Datenbanken
praktisch umgesetzt werden können.
4.2.2.1 Zeitgerechtigkeit
Um Zeitgerechtigkeit messen und verbessern zu können müssen in der Datenbank Metadaten hinterlegt sein, welche das Alter von Daten beschreiben. DBMS welche den
SQL:2011-Standard erfüllen, bieten dazu interne Sprachkonstrukte an [KM12]. In DBMS
welche diesem neuesten Standard nicht gerecht werden, bleibt die Implementierung
von zeitlichen Aspekten über die Applikationslogik. Sind diese Voraussetzungen erfüllt,
können Daten, die Gefahr laufen obsolet zu werden, durch kontinuierliche Messungen
erkannt und markiert werden. Zur Ausbesserung der markierten Daten bieten sich dann
die Möglichkeiten der Aktualisierung über Vergleiche mit Referenzdatenbanken oder der
Aufnahme von Daten aus der Realwelt.
4.2.2.2 Vollständigkeit
Unter der Annahme, dass Vollständigkeit als das nicht vorkommen von NULL-Werten
betrachtet wird, können zur Verhinderung dieser Integritätsregeln angewandt werden.
Mit der Definition von NOT NULL-Bedingungen können Benutzer dazu gezwungen
werden, Werte für bestimmte Attribute anzugeben. Dies empfiehlt sich aber nur bei
essentiell wichtigen Attributen, ohne die ein Datensatz nutzlos wäre.
Eine andere Möglichkeit bietet sich, falls funktionale oder konditionale Abhängigkeiten
für eine Menge von Attributen existieren. In diesem Fall können die Werte für die
abhängige Menge von Attributen automatisch bestimmt werden.
Können keine Abhängigkeiten erkannt werden, bleibt als Alternative die Vollständigkeit
über Datenermittlung aus der Realwelt oder Referenzdatenbanken auszubessern.
4.2.2.3 Konsistenz
Konsistenz beschreibt logische Zusammenhänge zwischen Daten in einer Datenbank. Die
Sicherung der Konsistenz kann vollständig über Datenbankregeln umgesetzt werden. Die
50
4.2 Analyse und Verbesserung von Datenqualität
Herausforderung hierbei besteht darin, eine Menge von Regeln zu formulieren die alle
Zusammenhänge abdeckt. Dazu ist umfangreiches Expertenwissen nötig.
Sind Integritätsbedingungen bereits vor ihrer Definition verletzt, müssen Daten zuerst gereinigt werden. Dazu eignet sich wiederum das Ausbessern durch Vergleich mit
Realweltobjekten oder Referenzdatenbanken.
4.2.2.4 Genauigkeit
Datenbankregeln können die Genauigkeit von Werten nicht garantieren [Red97]. Ein Wert,
der alle gestellten Formatsvorgaben, Bereichseinschränkungen und Probabilitätsbedingungen erfüllt, kann dennoch ungenau sein. Die Verwendung von Datenbankregeln kann
aber die Wahrscheinlichkeit für das Eintreten ungenauer Werte verringern. Wird z.B. die
Postleitzahl einer Münchner Adresse in eine Relation, die Adressen beschreibt, eingefügt,
kann der Bereich der möglichen genauen Werte durch Anwendung von Datenbankregeln
auf ein Intervall zwischen 80331 und 81929 beschränkt werden. Werden keine Regeln
angewandt, können beliebige Werte eingesetzt werden, womit die Wahrscheinlichkeit für
eine ungenaue Angabe deutlich wächst. Dennoch besteht beim obigen Beispiel auch bei
umfangreicher Anwendung von Regeln die Möglichkeit für die Eingabe von 1597 falschen
Werten.
Ungenaue Werte, die durch Datenbankregeln nicht erkannt werden können, müssen
über den Abgleich mit Referenzdatenbanken oder den Abgleich mit Realweltobjekten
aufgespürt und beseitigt werden.
4.2.2.5 Redundanzfreiheit
Das Einsetzen von Dubletten kann teilweise über den Einsatz von Schlüsselbedingungen
für identifizierende Attribute vermieden werden, beispielsweise durch den Einsatz von
UNIQUE-Bedingungen für eindeutige Attribute wie z.B. E-Mail-Adressen. Ist eine Kombination von Tupeln identifizierend, wie z.B. Vorname, Nachname und Adresse, können
zur Einhaltung der Eindeutigkeit dieser Kombination, Trigger verwendet werden.
Dubletten, die z.B. durch Tippfehler oder inkonsistente Verwendung von Abkürzungen
entstehen, können damit nicht verhindert werden. Zur Bereinigung bereits existierender
Dubletten stehen verschiedene automatische Methoden, wie z.B. das bereits erwähnte
Sorted-Neighbourhood-Verfahren zur Verfügung, welche Tupel unter Verwendung von
Ähnlichkeitsmaßen vergleichen, um mögliche Dubletten zu identifizieren [HS98].
51
4 Datenqualitätsverbesserung
4.3 Zusammenfassung
In diesem Kapitel wurde untersucht, auf welche Weise die Phasen des TDQM zur
Verbesserung der Datenqualität in einer relationalen Datenbank, praktisch angewandt
werden können. Es wurden zuerst Dimensionen identifiziert, die für eine automatisierbare
Messung geeignet sind. Danach wurden quantitative Metriken für die Messung der
Dimensionen gefunden und diskutiert, welche Voraussetzungen erfüllt werden müssen, um
die Metriken praktisch umsetzen zu können. Anschließend wurden mögliche Maßnahmen
zur Verbesserung von Datenqualität vorgestellt und wie diese auf die ausgewählten
Dimensionen anzuwenden sind. Außerdem wurden Vorgehensmodelle zur Implementierung
der Verbesserungsmaßnahmen diskutiert. Es wurde erklärt, wie unter Berücksichtigung
der vorher ermittelten Messwerte zu bewerten ist welches Vorgehensmodell sich in welchen
Fällen am besten eignet.
In Abbildung 4.2 sind die Ergebnisse des Kapitels übertragen auf die Phasen des
TDQM, grafisch dargestellt. In der ersten Phase müssen Dimensionen ausgewählt und
die Anforderungen an ihr gewünschtes Niveau an Datenqualität definiert werden. In der
Bild 4.2: Das Verbesserungs-Konzept
52
4.3 Zusammenfassung
zweiten Phase werden Messungen anhand der ermittelten Metriken durchgeführt und
die Ergebnisse dem Nutzer zur Verfügung gestellt. In der nachfolgenden Phase muss der
Nutzer anhand der Kennzahlen bewerten, welches Vorgehen am geeignetsten ist, um die
Datenqualität der ausgewählten Dimensionen zu sichern. In der vierten Phase werden
die ausgewählten Maßnahmen ausgeführt. Nach Abschluss aller Phasen erfolgt stets eine
neue Iteration.
53
5 Entwicklung eines Prototypen
Nachdem das Thema „Datenqualität“ im bisherigen Verlauf aus einem theoretischen Blickwinkel eingehend beleuchtet wurde, soll im nachfolgenden praktischen Teil dieser Arbeit
eine Applikation zur automatisierten Verbesserung von Datenqualität entwickelt werden.
Der Prototyp im Folgenden auch „ruleDQ“ soll bisher beschriebene Konzepte praktisch
umsetzen. Dafür wird beispielhaft das Szenario von medizinischen Verbundsdatenbanken
angenommen.
Die Idee hinter ruleDQ ist es, Praxismanagern ein Regelsystem zur Verfügung zu
stellen, welches es ihnen ermöglicht, selbständig die Qualität ihrer Daten zu messen und
zu analysieren
5.1 Anforderungsanalyse
In diesem Kapitel sollen nötige Anforderungen an ruleDQ gefunden wurden.
5.1.1 Fragebögen
Ein Jahr vor Anfang dieser Arbeit wurden Fragebögen an Praxismanager von medizinischen Verbünden verschickt. Diese sollen an dieser Stelle analysiert werden, um eine
Ausgangsbasis für die Formulierung von Anforderungen zu schaffen. In den Fragebögen wurden die Praxismanager über Datenqualitätsprobleme in ihrem Verbund und
Maßnahmen zur Messung und Beseitigung dieser befragt.
Die erste Gruppe von Fragen richtete sich an Datenqualitätsprobleme. Darin stellte
sich heraus, dass alle Befragten Praxen häufig auf Datenqualitätsmängel stoßen, siehe
Abbildung 5.1. Wie aus der Abbildung zu erkennen ist, ergaben sich vor allem Probleme
mit unvollständigen und falschen Daten. Probleme mit der Zeitgerechtigkeit von Daten
kamen derweilen seltener vor. Wie in Abbildung 5.2 dargestellt ist, wurden unvollständigen
Daten hierbei größere negative Auswirkungen zugeschrieben als falschen Daten.
Die zweite Gruppe von Fragen richtete sich an bestehende Maßnahmen zur Messung
und Verbesserung von Datenqualität. Zwei der drei Befragten gaben an, keine Messungen
55
5 Entwicklung eines Prototypen
Bild 5.1: Vorkommen von Datenqualitätsproblemen
Bild 5.2: Auswirkungen von Datenqualitätsproblemen
durchzuführen. Bei der Person, die angab Messungen durchzuführen, konnte durch
spätere Nachfrage durch den Autor dieser Arbeit festgestellt werden, dass es sich dabei
um manuelle Überprüfungen nach dem Laissez-Faire Vorgehen handelte. Daraus ergibt
sich, dass bei der Messung von Datenqualität großer Verbesserungsbedarf besteht. Bei
Fragen zu Verbesserungsmaßnahmen gaben alle Befragten an, Mitarbeiterschulungen
und manuelle Verbesserungen durchzuführen.
Die dritte und letzte Kategorie von Fragen richtete sich an das Vorhandensein von
Regeln. Alle Befragten gaben darin an, dass sie daran interessiert wären, ein System
einzusetzen, dass es ihnen erlauben würde, selbstformulierte Regeln automatisch zu
evaluieren. Zwei Drittel der Befragten waren zudem nach eigenen Angaben mit boolescher
Algebra vertraut.
56
5.1 Anforderungsanalyse
Zusammenfassend lässt sich feststellen, dass alle Befragten deutlich von Datenqualitätsmängeln betroffen waren. Sie verfügten über keine Systeme zur automatisierten
Messung von Datenqualität aber gaben an, daran interessiert zu sein.
5.1.2 Interviews
Im Rahmen dieser Arbeit wurden zusätzlich zu den vorher erwähnten Fragebögen Interviews mit drei ausgewählten Verantwortlichen in medizinischen Versorgungszentren
geführt. Die Interviews hatten den Zweck, die Erkenntnisse, die aus den Fragebögen gewonnen wurden, zu vertiefen. Es wurden dabei offene Fragen zu Datenqualitätsproblemen,
bestehenden Maßnahmen zur Behebung dieser sowie zur Entwicklung der Situation seit
Erhebung der Fragebögen gestellt. Besonderer Fokus der Gespräche war die Identifizierung
von bestehenden Regeln und Mustern zur Behandlung von Datenqualitätsproblemen.
Die Interviews konnten die Ergebnisse der Fragebögen bestätigen. Die befragten
Personen gaben an, regelmäßig auf Fehler in ihrem Datenbestand zu stoßen und Fehlerbehebungen nach der Laissez-Faire Vorgehensweise durchzuführen. Es existierten weiterhin
keine automatisierten Systeme zur Überwachung und Messung der Datenqualität. Alle
Befragten gaben an, Interesse an softwaretechnischen Lösungen zur Verbesserung der
Datenqualitätssituation zu besitzen. Es konnte also festgestellt werden, dass sich die
Situation seit Erhebung der Fragebögen in Bezug auf Datenqualitätsmaßnahmen nicht
verbessert hatte.
Zusätzlich zu den Erkenntnissen aus den Fragebögen konnten Regeln erkannt werden,
welche die Praxen regelmäßig auf ihren Datenbestand anwendeten. Im Besonderen
handelte es sich dabei um konditionale und funktionale Abhängigkeiten, die sich aus
gesetzlichen Vorgaben und Verträgen ergaben.
Einer der befragten Praxen setzte eine Praxissoftware ein, die es unter Verwendung
einer grafischen Oberfläche ohne SQL-Wissen erlaubte boolesche Konditionen zu formulieren, aus denen einfache SELECT-Anfragen generiert wurden. Die Praxissoftware
erlaubte die Prüfung auf Gleichheit bzw. Ungleichheit sowie ob ein Wert vorhanden ist
oder nicht. Desweiteren bestand die Möglichkeit der Spezifikation von Anfragezeiträumen
und Klammerung der Vergleiche. Die Vergleiche konnten zudem per UND-Operator oder
ODER-Operator verknüpft werden. Die Praxis erstellte mit Hilfe dieser Funktion eine
Basis von 119 Abfragen, in denen die erwähnten Vorgaben mit Hilfe von booleschen
Konditionen abgebildet wurden. Diese Abfragen dienten zur Überprüfung von Abrechnungen. Die Software erlaubte allerdings keine Formulierung von Aktionen bei Eintreffen
der Konditionen. Die Anfragen mussten einzeln ausgeführt werden und die Ausführung
57
5 Entwicklung eines Prototypen
manuell ausgelöst werden. Eine automatisierte Überprüfung der Datenqualität war damit
nicht möglich.
In Abbildung 5.3 ist eine der verwendeten Anfragen dargestellt. Mit dieser Regel
Bild 5.3: Eine Regel im medizinischen Versorgungszentrum
wurde überprüft, ob die Leistungsziffern 40224 und 40220 von der Leistungsziffer 05230
gefolgt wurden. Die Ziffern 40224 und 40220 stehen für eine Abrechnung von Reisekosten,
während die Ziffer 05230 einen Patientenbesuch codiert. Logischerweise kann ein Patient
nur besucht werden, wenn der Arzt unterwegs war. Diese Abhängigkeit wurde über keine
Integritätsregeln sichergestellt und lediglich über manuelle Ausführung dieser Anfrage
überprüft. Die weiteren Regeln in der Regelbasis waren mit dem Beispiel in der Abbildung
vergleichbar. Es wurde stets sichergestellt, dass bestimmte Leistungsziffer-Kombinationen
in einer Abrechnung vorkommen oder nicht vorkommen. Die Regeln unterschieden sich
dabei nur in ihrer Länge. Die Komplexität der Regeln wurde durch die limitierten
Möglichkeiten der Praxissoftware eingeschränkt.
Aus den gewonnenen Informationen sollen im Folgenden Anforderungen an den zu
entwickelnden Prototypen abgeleitet werden.
5.1.3 Funktionale Anforderungen
Aus den Fragebögen und Interviews ergab sich, dass vor allem Verbesserungspotential
bei der Messung von Datenqualität besteht. Die Befragten sind außerdem an der Verwendung eines Systems zur Evaluierung automatisierter Regeln interessiert. Aus diesen
Gründen wird die Entwicklung einer Rule-Engine zu diesem Zweck als geeignet gesehen.
Rule-Engines sind Applikationen welche sich mit der unabhängigen Verwaltung und Abwicklung von Geschäftsregeln beschäftigen. Diese Art von Applikationen wurden bereits
58
5.1 Anforderungsanalyse
im Abschnitt 3.2 vorgestellt. Sie fordern die Trennung von Regeln, Daten und Prozessen.
Geschäftsregeln werden unabhängig vom Ausführungscode formuliert und verwaltet. Die
Rule-Engine kann diese Regeln dann dynamisch in ausführbaren Quellcode übersetzen
und auf Daten anwenden. Nach [Los02] besteht eine Rule-Engine aus folgenden drei
Modulen:
1. Einem Benutzerinterface zur Erstellung und Verwaltung von Regeln
2. Einer persistenten Regelbasis
3. Einem Modul zur Ausführung von Regeln
Analog zu dieser Definition sollen nun die funktionalen Anforderungen an ruleDQ
formuliert werden:
• Regelerstellung:
Den Benutzern von ruleDQ muss die Möglichkeit gegeben werden, selbständig Datenqualitätsregeln zu erstellen. Dabei sollen Wertsüberprüfungen sowie Formatsüberprüfungen realisiert werden. Der Nutzer soll die
Möglichkeit besitzen, boolesche Ausdrücke beliebiger Länge zu schachteln
und zu konkatenieren. Für den Fall, dass eine Regel zutrifft, muss der
Nutzer die Möglichkeit haben, automatische Aktionen zu spezifizieren.
Im Rahmen dieser Arbeit ist eine Benachrichtigungsfunktion vorgesehen.
In späteren Arbeiten ist die Integrierung von z.B. einer automatischen
Reinigung denkbar.
• Regelverwaltung:
Der Nutzer soll in der Lage sein, eine Sicht auf schon bestehende Regeln
zu erhalten. Er muss die Möglichkeit haben, einzelne Details bestehender
Regeln einzusehen sowie Regeln aus dem System wieder zu entfernen.
• Regelauswertung:
Nachdem Regeln erstellt wurden, muss das System die Möglichkeit bieten,
Regeln sowohl automatisch als auch auf manuellen Befehl hin auszuführen. Die vorher vom Nutzer spezifizierten Aktionen werden dabei nach
der Evaluierung der Regeln ausgeführt, falls die definierte Kondition
erfüllt wurde. Die Ergebnisse der Auswertungen müssen unmittelbar
sichtbar sein, damit Nutzer auf eventuelle Missstände schnell reagieren
können. Neben einem absoluten Messwert soll der Nutzer alle eine Regel
verletzenden Tupel betrachten können.
59
5 Entwicklung eines Prototypen
• Eingabevalidierung:
Da alle Regeln aus Benutzereingaben generiert werden, ist eine Validierung der Eingaben nötig, um sicherzustellen, dass alle Regeln syntaktisch
korrekt sind. Neben Sicherstellung einer höheren Usability ist dies auch
aus Sicherheitsaspekten nötig.
5.1.4 Nicht Funktionale Anforderungen
Als nächstes sollen Anforderungen an die Softwarequalität beschrieben werden. Der
ISO-9126-Standard definiert sechs Qualitätsmerkmale für Softwarequalität (Funktionalität, Zuverlässigkeit, Benutzerfreundlichkeit, Effizienz, Wartungsfreundlichkeit und
Übertragbarkeit) [Bal11, S.468ff.]. Alle diese Merkmale sind wichtige Faktoren für Erfolg
des Datenqualitätswerkzeugs. Im Folgenden sollen aber Benutzerfreundlichkeit, Übertragbarkeit, Änderbarkeit sowie Zuverlässigkeit im Besonderen hervorgehoben werden. Diese
Priorisierung ergibt sich aus der vorgehenden Problemdefinition. Benutzerfreundlichkeit
und Zuverlässigkeit werden fokussiert, da auf Seiten der zukünftigen Benutzer kein
technisches Wissen vorausgesetzt werden kann, während Übertragbarkeit und Änderbarkeit besondere Erwähnung finden, da zukünftig Veränderungen im Einsatzgebiet und
Erweiterungen an der Funktionalität des Werkzeugs zu erwarten sind.
• Benutzerfreundlichkeit:
Es wird davon ausgegangen, dass die zukünftigen Benutzer von ruleDQ
über keine Kenntnisse von Datenbankanfragesprachen oder sonstiges
informatisches Fachwissen verfügen. Dies stellt vor allem eine Herausforderung für die Regelerstellung dar, welche auf einfache und leicht
verständliche Weise gestaltet werden und ohne Fachbegriffe aus dem
informatischen Bereich auskommen muss. Als einzige Voraussetzung
werden Kenntnisse über Umgang mit booleschen Regeln und Grundwissen über den Aufbau der von den Regeln betroffenen relationalen
Daten angenommen, welches unumgänglich ist, um effektiv Regeln
formulieren zu können. Da die Verwendung des zu entwickelnden Datenqualitätswerkzeugs keine Kernaufgabe der zukünftigen Nutzer darstellt,
muss ruleDQ zudem in einer intuitiven und leicht verständlichen Weise
gestaltet sein, um eine möglichst kurze Einarbeitungszeit zu ermöglichen.
60
5.2 Architektur
• Übertragbarkeit:
Das Datenqualitätswerkzeug darf von keinem festen, unveränderbaren
Schema ausgehen. Es muss nahtlos ohne vorherige Anpassungen in verschiedenen Umgebungen einsetzbar sein. Dies liegt darin begründet, dass
zukünftige Veränderungen von Schemata wahrscheinlich sind. Außerdem
ist die Betrachtung von medizinischen Versorgungszentren, wie schon in
der Kapiteleinleitung erwähnt, als beispielhaft zu verstehen. ruleDQ soll
optimalerweise auch in anderen Bereichen einsetzbar sein. Dies macht
Schemaneutralität zu einer wichtigen Voraussetzung.
• Änderbarkeit:
ruleDQ soll einen leicht erweiterbaren modularen Aufbau besitzen, der
zukünftige Funktionserweiterungen und Funktionsanpassungen problemlos ermöglicht. Dies bedarf neben einer entsprechenden Architektur auch
einer ausführlichen Dokumentation der Entwicklung. Vor allem ist dies
eine Bedingung, da davon ausgegangen wird, dass die Entwicklung an
diesem Werkzeug auch nach Abschluss dieser Arbeit fortgesetzt wird.
• Zuverlässigkeit:
Im Zentrum von ruleDQ steht die Erstellung und Ausführung von benutzerdefinierten Regeln. Es kann nicht ausgeschlossen werden, dass dabei
syntaktisch oder semantisch inkorrekte Regeln im System gespeichert
werden. Neben Lücken in der Validierungslogik können ehemals korrekte
Regeln durch Veränderungen und Schema ungültig werden. Die Benutzbarkeit des Systems darf durch vereinzelte eventuell inkorrekte Regeln
nicht beeinträchtigt werden. Der Nutzer ist zudem auf inkorrekte oder
inkorrekt gewordene Regeln hinzuweisen.
5.2 Architektur
In diesem Kapitel wird die Systemarchitektur von ruleDQ dargestellt, welche auf Basis der
vorher formulierten Funktionsanforderungen entworfen wurde. Im ersten Abschnitt wird
ein Gesamtüberblick der Architektur und des Zusammenspiels der einzelnen Komponenten
gegeben. In den nachfolgenden Abschnitten wird jede Komponente für sich im größeren
Detail vorgestellt. Die in diesem Kapitel folgenden Architekturdiagramme stellen die
61
5 Entwicklung eines Prototypen
wichtigsten Elemente der beschriebenen Module dar, erheben aber keinen Anspruch auf
Vollständigkeit.
5.2.1 Programmiersprache
ruleDQ wird in Form einer Webapplikation implementiert. Dies ermöglicht ein hohes Maß
an Plattformunabhängigkeit und setzt beim Endanwender lediglich das Vorhandensein
eines Browser voraus. Dabei wird das Java-Webframework „Grails“1 eingesetzt. Grails
verwendet die dynamische Skriptsprache „Groovy“2 . Groovy läuft auf der Java Virtual
Machine, erlaubt den Einsatz von Java-Bibliotheken und ist mit Java nahtlos integrierbar.
Im Gegensatz zu Java ermöglicht es aber unter anderem die Verwendung einer vereinfachten Syntax und dynamischer Typisierung. Durch den Einsatz dieses Frameworks
verspricht sich der Autor eine gesteigerte Produktivität und Zeiteinsparungen, da im
Gegensatz zu reinem Java unter anderem ein Großteil der Konfiguration, die für diese
Art von Webanwendung nötig wäre, wegfällt.
5.2.2 Grobarchitektur
Wie für Webanwendungen typisch, basiert ruleDQ auf dem Model-View-Controller (MVC)
Architekturmuster, siehe Abb.5.4.
MVC ist hauptsächlich für die Strukturierung der Präsentationsschicht gedacht. Die
Darstellung (View) wird von der Datenhaltung (Model) und der Ablaufsteuerung (Controller) getrennt. Durch Trennung dieser Verantwortlichkeiten wird eine höhere Flexibilität
und Erweiterbarkeit des Systems erreicht.
Views stellen für gewöhnlich die Inhalte eines Modells dar. Im Falle von ruleDQ
entsprechen sie den Servlets aus denen dynamisch HTML-Seiten gerendert werden. Sie
nehmen Benutzereingaben entgegen und leiten diese an Controller weiter.
Das Modell enthält die persistenten Daten, bei ruleDQ sind das vor allem die vom
Benutzer erstellten Regeln.
Zwischen den Daten und den Views steht die Ablaufsteuerung. Die Ablaufsteuerung
wird durch die Controller realisiert. Sie nehmen Benutzereingaben entgegen und leiten
entsprechende Antworten an den Nutzer weiter. Der Benutzer modifiziert für gewöhnlich
1
2
62
http://grails.org
http://groovy.codehaus.org
5.2 Architektur
Bild 5.4: Das MVC-Architekturmuster [Wik]
mit seinen Eingaben die Inhalte der Modelle. Controller setzen Ereignisse in DomänenOperationen um und stellen somit Zustandsmaschinen dar [Sta08, S.246ff.].
Die eigentliche Geschäftslogik ist bei ruleDQ in einer weiteren Schicht implementiert.
Diese ist in Abbildung 5.5 grob dargestellt. Controller und Views sind hier unter dem
Begriff Benutzerschnittstelle zusammengefasst. Auf die Architektur der Benutzerschnittstelle wird in Abschnitt 5.2.6 noch näher eingegangen. Wie in Abbildung 5.5 zu sehen
ist, besteht die Geschäftslogik von ruleDQ im Wesentlichen aus drei Modulen: einem
Modul zur Regelausführung, einem Modul zum Regelmonitoring und einem Modul zur
Regelverwaltung.
Auf der Persistenzebene stehen zwei Datenbanken: eine Applikationsdatenbank, in
der von ruleDQ generierte Daten gespeichert werden und eine Zieldatenbank. Die Zieldatenbank referenziert die Datenbank, auf welche die formulierten Regeln angewandt
werden. Angesprochen wird diese Datenbank über ein Anfragehandling-Modul, welches
SQL-Anfragen ausführt und Anfrageergebnisse in Objekte umwandelt. Bei Applikationsdaten übernimmt diese Aufgabe der im verwendeten Webframework integrierte
Objektrelationale-Mapper Hibernate 1 . Beim Zugriff auf die Zieldatenbank muss auf Hibernate verzichtet werden, da Hibernate von einem festen Model ausgeht. Anforderung
an ruleDQ ist aber komplette Schemaunabhängigkeit. Die eigene Implementierung er-
1
http://hibernate.org/
63
5 Entwicklung eines Prototypen
Bild 5.5: Grobarchitektur
möglicht Informationen zu in der Zieldatenbank vorhandenen Tabellen, dynamisch zur
Laufzeit zu ermitteln.
Im typischen Anwendungsfall greift der Nutzer über die Benutzerschnittstelle auf
das Regelverwaltungs-Modul zu, um eine Regel zu erstellen. Das RegelverwaltungsModul bietet zur Unterstützung bei der Regelerstellung dabei Informationen aus der
Zieldatenbank an. Zu den Informationen gehören Tabellennamen, Spaltennamen und
die Möglichkeit den Inhalt von Tabellen zu betrachten. Ist eine Regel erfolgreich erstellt,
wird sie in der Applikationsdatenbank abgelegt. Daraufhin beantragt der Nutzer über das
Regelmonitoring-Modul die Ausführung der Regel. Das Regelmonitoring-Modul schickt
die ausgewählte Regel an das Regelausführungs-Modul und generiert aus dem Ergebnis
64
5.2 Architektur
einen Evaluationsbericht für den Nutzer. Das aktuellste Ergebnis der Regelausführung
wird zudem ebenfalls in der Applikationsdatenbank persistiert.
5.2.3 Anfragehandling
Alle Zugriffe auf die Zieldatenbanken werden unter Verwendung des QuerymanagementModuls ausgeführt. Zum derzeitigen Entwicklungsstand werden nur Anfragen auf eine
MySQL-Datenbank unterstützt. Da auch die Unterstützung weiterer SQL-Dialekte zu
erwarten ist, wurde sichergestellt, dass alle dieses Modul verwendenden Klassen, vom
in Abbildung 5.6 dargestellten Interface anstatt einer konkreten Implementierung abhängig sind. Dies soll eine hohe Anpassbarkeit gewährleisten. Das Modul ist sowohl
Bild 5.6: Anfragehandling
für die Regelverwaltung als auch für die Regelausführung wichtig. Für die Regelverwaltung stellt es Informationen über in der Datenbank gespeicherte Daten bereit, die
bei der Regelerstellung hilfreich sind. Der Prozess der Regelerstellung ist in Abschnitt
5.2.6.1 näher beschrieben. Das implementierte Regelausführungsmodul evaluiert Regeln
unter der Verwendung von SQL-Anfragen. Diese Anfragen werden ebenfalls über das
Anfragehandling-Modul ausgeführt. Die Ergebnisse der Anfragen werden in geeignete
Objekte umgewandelt und an das Regelausführungsmodul zurückgegeben. Das Parsen
der vom Nutzer erstellten Regeln wurde, bedingt durch die relative Komplexität dieser
65
5 Entwicklung eines Prototypen
Aufgabe, aus der MySQLHandler-Klasse in die Hilfsklasse MySQLRuleParser ausgelagert.
Eine detailliertere Beschreibung der benutzten Anfragen findet sich im Abschnitt 5.2.5.2.
5.2.4 Regelerstellung und Verwaltung
In Abbildung 5.7 ist der Aufbau von Regeln dargestellt. Jede Regel muss sich auf eine
Tabellendefinition beziehen. Dies kann entweder eine gewöhnliche Tabelle oder eine
gejointe Tabelle darstellen. Der Nutzer erhält bei der Definition von Joins von ruleDQ
Unterstützung, indem alle Möglichkeiten für Natural Joins ermittelt werden. In späteren
Versionen ist die Unterstützung für weitere Join-Typen denkbar.
Bild 5.7: Aufbau von Regeln
Des Weiteren enthält jede Regel eine Aktion, die ausgeführt wird, falls die Bedingung
der Regel erfüllt ist. Im Rahmen dieser Arbeit wurde eine Aktion implementiert, die es
dem Nutzer erlaubt, eine E-Mail zu verschicken, falls eine Regel zu einem bestimmten
Grad erfüllt wurde. Wird vom Nutzer keine Aktion ausgewählt, wird eine manuelle
Überwachung von Evaluationsergebnissen und entsprechende Reaktion vorausgesetzt.
66
5.2 Architektur
Zur Realisierung der E-Mail-Aktion wurde das externe Plugin mail 1 angebunden. Das
Plugin stellt die Funktion sendMail zur Verfügung, welche als Parameter eine E-MailAdresse, einen Betreff und den Inhalt der E-Mail in Form von drei Strings erwartet. Zur
Konfiguration des Plugins ist die Angabe von Zugangsdaten zu einem SMTP-Server
erforderlich. Wird keine SMTP-Server Konfiguration angegeben, erwartet das Plugin
das Vorhandensein eines internen Mail-Servers unter Port 25. Regeln besitzen neben
Assoziationen zu Aktionen und Tabellen, die vom Nutzer spezifizierte Kondition, einen
identifizierenden Titel sowie gegebenenfalls, ein Wiederholungsintervall. Dieses ermöglicht
eine automatisierte Ausführung von Regeln zu vom Nutzer spezifizierten Zeitpunkten. Auf
die automatische Ausführung von Regeln wird im folgenden Abschnitt 5.2.5.1 eingegangen.
Aus Abbildung 5.8 wird der Aufbau der Regelerstellungs-Funktionalität deutlich. Die
Bild 5.8: Regelerstellung
Eingaben des Nutzers werden zuerst an die Validierungsklasse RuleValidator übertragen.
Das Ergebnis der Validierung wird innerhalb eines ErrorReport-Objektes zurückgeschickt.
Falls die Validierung fehlschlägt wird der Nutzer zur Korrektur seiner Eingaben aufgefordert. Bei erfolgreichem Durchlauf der Validierung wird innerhalb der RuleFactory
die Regel aus den Benutzereingaben generiert und persistiert. Die Validierung der Nutzereingabe wird mit einer Whitelist realisiert. Die Eingabe des Nutzers wird somit mit
einer Liste erlaubter Ausdrücke verglichen. Befindet sich in der Benutzereingabe ein
Ausdruck, der nicht in der Whitelist vorkommt, schlägt die Validierung fehl. Erlaubt
ist die Eingabe der vorgegebenen Operatoren, Funktionen und Attributsnamen sowie
von Zahlen oder von mit Anführungszeichen eingeschlossenen Strings. Alle anderen
Eingaben lösen einen Validierungsfehler aus. Dies soll auf einer Seite dem Nutzer bei
der Regelerstellung helfen und auf mögliche Eingabefehler hinweisen. Auf der anderen
1
http://grails.org/plugin/mail
67
5 Entwicklung eines Prototypen
Seite stehen Sicherheitsaspekte und die Abwehr von SQL-Injection Angriffen. Trotz der
beschriebenen Vorsichtsmaßnahmen können Fehler und Lücken nicht ganz ausgeschlossen
werden. Deswegen wurde zur zusätzlichen Erhöhung der Sicherheit ruleDQ lediglich
mit Leserechten auf die Zieldatenbank ausgestattet, da Schreibrechte beim derzeitigen
Funktionsumfang nicht notwendig sind.
5.2.5 Regelmonitoring und Ausführung
Das Application Programming Interface (API) des Regelmonitoring-Moduls bietet wie in
Abbildung 5.9 dargestellt zwei Methoden zur Regelausführung. Als Ergebnis der Regelausführung werden zwei verschiedene Berichtsarten angeboten: Report und TupleReport.
Die erste Möglichkeit ist die Generierung eines Berichtes (Report), der verschiedene
einfache Messwerte enthält. Darunter ist vor allem der Grad der Regelerfüllung relevant,
er beschreibt das Verhältnis der Gesamtanzahl der Datensätze in der untersuchten Tabelle
zu der Anzahl an Datensätzen, welche die Regel verletzen. Die zweite Berichtsklasse
beinhaltet zusätzlich die Tupel, welche die Regel verletzt haben und ermöglicht es dem
Nutzer somit das Evaluationsergebnis genauer zu analysieren. Kommt es bei der Regel-
Bild 5.9: Regelmonitoring
68
5.2 Architektur
ausführung zu Fehlern wird den Berichten ein Objekt der ErrorReport-Klasse angehängt,
die Ausführung der Regel gestoppt und der Nutzer über diesen Zustand informiert.
Die Ausführung von diesem Fehler unbetroffenen Regeln wird dadurch nicht beeinflusst.
Regeln können entweder manuell gestartet werden oder unter Verwendung des Submoduls
QuartzManagement in einem bestimmten Wiederholungsintervall automatisch ausgeführt
werden. Das Submodul Quartzmanagement soll nachfolgend beschrieben werden.
5.2.5.1 Quartzmanagement
Das Submodul QuartzManagement dient der Ablaufplanung und automatischen Ausführung von Regeln. Es wurde unter Verwendung des externen Frameworks Quartz 1
realisiert.
Quartz ist ein quelloffenes Framework für die Planung von zeitgesteuerten Aufgaben
(Jobs) in Java-Anwendungen. Jobs können beliebige Java-Klassen sein die das JobInterface implementieren. Das Job-Interface verlangt die Konkretisierung der execute()Methode, welche dann zu den festgelegten Zeitpunkten ausgeführt wird. Trigger dienen
der Definition von Zeitplänen. Es ist möglich, simple Zeitpläne sowohl unter Angabe der
Startzeit und des Wiederholungsintervalls als auch komplexere Zeitpläne zu erstellen, die
es erlauben, präzise Zeitpunkte auszuwählen, an denen Jobs ausgeführt werden sollen.
Es ist z.B. möglich, zu definieren, dass ein Job jeden Mittwoch um 24:00 ausgeführt
werden soll. Der JobScheduler verbindet Trigger mit Jobs und ist für die Ausführung der
Zeitpläne zuständig [Qua14].
Im Falle von ruleDQ implementiert die Klasse JobTemplate das Job-Interface. JobTemplate wird von QuartzService mit einer Referenz auf eine Regel instanziiert und zusammen
mit einem entsprechenden Trigger an den JobScheduler zur Ausführung des Zeitplans
übergeben. Das Job-Interface wurde nicht direkt von der Regel-Klasse implementiert, um
die Regeldaten von der Ausführungslogik zu trennen. Als Ergebnis der Regelausführung
wird ein Bericht an die Benutzerschnittstelle geliefert. Dazu wird ein Objekt der Klasse
QuartzReport instanziiert. Der Unterschied zu der bereits beschriebenen Klasse Report
liegt in zusätzlichen Daten bezüglich Jobs und Triggern. Der Benutzer erhält so zusätzlich
Informationen über den nächsten Ausführungszeitpunkt und den Status (aktiv/inaktiv)
des Jobs.
1
http://quartz-scheduler.org/
69
5 Entwicklung eines Prototypen
Bild 5.10: Quartzmanagement
5.2.5.2 Regelausführung
Zur Implementierung des Regelausführungs-Interfaces wurden zwei verschiedene Alternativen betrachtet. Die erste betrachtete Möglichkeit war die Einbindung der Open Source
Rule-Engine Drools 1 . Rule-Engines wurden im Abschnitt 3.2 diskutiert. Die zweite betrachtete Möglichkeit war eine eigene Implementierung des Regelausführungsmoduls über
direkte Ausführung von SQL-Anfragen. Hauptsächlich aus Performance-Gründen wurde
die Alternative der eigenen Implementierung ausgewählt. Die Verwendung von Drools
würde vor der Evaluierung der Regeln erst den Aufbau einer Faktenbasis erfordern. Dazu
müssten alle relevanten Daten aus der Zieldatenbank in die Java Virtual Machine (JVM)
geladen werden. Neben zeitlichen Verzögerungen und höheren Hardwareanforderungen
kommt es dadurch auch zu einer Erhöhung der Komplexität. Änderungen in der Zieldatenbank müssten mit den Daten in der Faktenbasis synchron gehalten werden. Die
zweite Möglichkeit über die direkte Ausführung von Anfragen an die Datenbank erlaubt
eine erheblich schnellere Evaluierung der Regeln und verlangt nicht die Wartung einer
1
70
http://www.jboss.org/drools/
5.2 Architektur
redundanten Datenbasis in der JVM. Die Performance der beiden Alternativen wurde
im Abschnitt 5.3 quantifiziert.
Für die konkrete Ausführung der Anfragen wird das vorher beschriebene QueryManagement-Modul benutzt, welches eine Abstraktion gegenüber den verschiedenen
SQL-Dialekten bietet. Die vom Nutzer spezifizierte Kondition wird dazu vor jeder Ausführung einer Regel in eine SQL-Anfrage geparst. Dies wurde der einmaligen Generierung
und Speicherung der Anfrage vorgezogen, um eine höhere Flexibilität und Anpassbarkeit
zu ermöglichen. Somit kann der zu verwendende SQL-Dialekt zur Laufzeit ausgetauscht
werden.
Folgend sollen die benutzten Anfragen beschrieben werden. Diese basieren auf dem
MySQL-Dialekt, welcher im Rahmen dieser Arbeit umgesetzt wurde.
Zur einfachen Ermittlung des Erfüllungsgrades einer Regel wird folgende Anfrage
benutzt:
SELECT COUNT(*)
FROM $Tabellendefinition
WHERE $Kondition;
Das Ergebnis der Anfrage wird dabei durch die gesamte Anzahl an Tupeln in der Tabelle
dividiert um den Grad zu berechnen, zu welchem die Regel erfüllt ist. Der Platzhalter
$Tabellendefinition kann entweder für die Selektierung einer einfachen Tabelle stehen
oder für eine Unteranfrage die einen Join durchführt. Der Platzhalter $Kondition steht
für die, in SQL geparste, vom Nutzer definierte Kondition.
Zur Betrachtung der die Kondition erfüllenden Tupel wird folgende Anfrage benutzt:
SELECT *
FROM $Tabellendefinition
WHERE $Kondition
ORDER BY $sortColumn $sortDirection
LIMIT $startRow, $maxRow;
Bei dieser Anfrage ist zu bemerken, dass die Anzahl der zurückgegebenen Tupel über
die zwei Variablen startRow und maxRow beschränkt wird. Die Anzahl wird zum einen
71
5 Entwicklung eines Prototypen
aus technischen Gründen beschränkt, um einen Speicherüberlauf zu verhindern und
zum anderen, um die Ladezeit auf Clientseite möglichst gering zu halten. Falls der
Nutzer weitere Tupel betrachten möchte oder das Ergebnis anderes sortiert haben will,
werden die neuen Daten über eine Ajax-Anfrage nachgeladen. Dank dieser asynchronen
Technologie kann der Nutzer ohne Nachladens der kompletten Seite nahtlos durch den
gesamten Datensatz navigieren, während auf Serverseite Ressourcen geschont werden,
da nur Daten übertragen werden, die vom Nutzer zum gegebenen Zeitpunkt tatsächlich
gebraucht werden.
Will ein Anwender zum Beispiel sicherstellen, dass bestimmte Medikamentengruppen
bei einer Diagnose nicht verschrieben werden, so kann eine Regel zu diesem Zweck etwa wie
folgt ausgedrückt werden: (Diagnose = ’R50.80’) AND (Medikation != ’Placebo’).
Die vollständig geparste Anfrage zur Betrachtung regelverletzender Tupel würde bei
diesem Beispiel folgendermaßen aussehen:
SELECT *
FROM Verschreibungen
WHERE (Diagnose = ’R50.80’) AND (Medikation != ’Placebo’)
ORDER BY Arzt ASC
LIMIT 0, 100;
5.2.6 Benutzerschnittstelle
In den vorherigen Abschnitten dieses Kapitels wurde die Architektur des Backends der
Applikation vorgestellt. Dieser Abschnitt soll nun das Frontend näher vorstellen. In den
bisherigen Klassendiagrammen wurde auf eine volle Darstellung der Benutzerschnittstelle
verzichtet, Abbildung 5.11 schließt diese Lücke. Die Abbildung stellt alle ControllerKlassen mit ihren zugehörigen Views dar. Die Hauptfunktionen der Controller und Views
können logisch in zwei Bereiche eingeteilt werden: Monitoring und Regelverwaltung.
Die Klasse RuleMonitoringController mit den zugehörigen Views ermöglicht die Regelausführung und einen Überblick über den Status aller Regeln (monitor). Des Weiteren
können einzelne Regeln ausgewählt werden (analyze), um das Ergebnis der Regelausführung und die Tupel, welche die Regel verletzen, im Detail zu betrachten (showReport).
72
5.2 Architektur
Bild 5.11: Benutzerschnittstelle
Die übrigen Controller und Views sind für die Regelverwaltung zuständig. Die Regelverwaltung ermöglicht dem Nutzer das Betrachten aller erstellen Regeln (list), die
detaillierte Betrachtung einzelner Regeln (show), das Editieren von bestehenden Regeln
(edit) sowie die Definition neuer Regeln (create). Der Controller TableBrowsing ermöglicht
das Betrachten der in der Zieldatenbank vorhanden Tabellen und stellt somit hauptsächlich eine unterstützende Funktion bei der Erstellung von Regeln dar. Der Controller
TableDefinition unterstützt den Nutzer bei der Definition von Joins, um das Kreieren
von intertabellarischen Regeln zu ermöglichen, damit realisiert dieser Controller ebenfalls
eine unterstützende Funktion bei der Regelerstellung.
5.2.6.1 Erstellung von Regeln
In diesem Unterabschnitt soll die Erstellung von Regeln aus Sicht des Endanwenders
dargestellt werden. Diese Funktion wird mit der View create des Controllers RuleController realisiert (siehe Abbildung 5.11). Beim Entwurf dieser Funktion stand vor allem
die Benutzerfreundlichkeit im Vordergrund, da keine SQL-Kenntnisse auf Seiten des
Nutzers vorausgesetzt werden können. Lediglich Vertrautheit mit boolescher Algebra
73
5 Entwicklung eines Prototypen
wird angenommen. In Abbildung 5.11 ist die Seite in ihrer Gesamtheit dargestellt. Der
Prozess der Regelerstellung ist logisch in drei Schritte aufgeteilt.
Im ersten Schritt müssen allgemeine Informationen über die Regel eingegeben werden.
Dazu gehören der eindeutige Titel der Regel, die Tabelle auf welche sich die Regel bezieht
sowie ob die Regel manuell oder automatisch ausgeführt werden soll.
Der zweite Schritt bezieht sich auf die Formulierung der Kondition der Regel. Dieser
Schritt ist in Abbildung 5.12 dargestellt. Dem Nutzer wird ein frei editierbares Textfeld
Bild 5.12: Die Formulierung der Kondition
zur Verfügung gestellt. Zur Unterstützung des Nutzers werden alle Spalten der Tabelle
aufgelistet. Bei Druck auf den zugehörigen Knopf wird der Name der Spalte in das
Textfeld eingefügt. Des Weiteren werden bestimmte Hilfsfunktionen und alle erlaubten
logischen Operatoren aufgelistet. Als Hilfsfunktion wird die Einbindung von regulären
Ausdrücken angeboten sowie die Funktion today, welche bei der Ausführung von Regeln
das aktuelle Datum bereitstellt. Benutzer können selber reguläre Ausdrücke erstellen oder
vordefinierte Ausdrücke aus einer Drop-Down-Liste auswählen, so z.B. zur Überprüfung
der Anzahl von Zeichen in Strings.
Im letzten Schritt kann eine Aktion spezifiziert werden, welche ausgeführt wird, falls
die vorher formulierte Kondition erfüllt wird. Zum Zeitpunkt der Erstellung dieser
Masterarbeit wird dabei lediglich das Versenden einer E-Mail angeboten. Die Sicht auf
die Formulierung dieser Aktion ist in Abbildung 5.13 dargestellt. Im ersten Feld kann
hierbei eingeschränkt werden, ab welchem Erfüllungsgrad die Aktion auszuführen ist.
Die weiteren Felder sind selbsterklärend und beschreiben die üblichen Informationen, die
74
5.2 Architektur
Bild 5.13: Das Spezifizieren einer Aktion
bei der Erstellung einer E-Mail nötig sind. Sind alle nötigen Informationen eingegeben,
können die Eingaben an den Server geschickt werden. Bevor die Regel erstellt wird, werden
alle Benutzereingaben einer Validierung unterzogen. Besteht eine bestimmte Eingabe die
Validierung nicht, wird der Benutzer zur Korrektur seiner Eingaben aufgefordert, siehe
Abbildung 5.14. Ansonsten wird die Regel persistiert.
Bild 5.14: Ein Validierungsfehler
75
5 Entwicklung eines Prototypen
Bild 5.15: Regelerstellung
5.3 Evaluation
Im bisherigen Verlauf dieses Kapitels wurde die Entstehung von ruleDQ von Anforderungsanalyse bis Architektur beschrieben. In diesem Abschnitt soll das entwickelte
Werkzeug bewertet werden, dazu soll es einer Funktionsanalyse sowie einer Laufzeitanalyse unterzogen werden.
76
5.3 Evaluation
5.3.1 Funktionsanalyse
Wie bereits im Unterabschnitt 5.1.2 erwähnt, setzte eines der befragten Referenzunternehmen eine Praxissoftware ein, die es erlaubte boolesche Regeln zu formulieren
aus denen SELECT-Anfragen generiert wurden. Die Praxis nutzte diese Funktion, um
eine Regelbasis anzulegen, mit Hilfe derer die Einhaltung von vertraglichen Vorgaben
und logischen Abhängigkeiten in Abrechnungen überprüft wurden. Folgend soll ein
Funktionsvergleich zwischen ruleDQ und den Regelformulierungsmöglichkeiten dieser
Praxissoftware stattfinden.
In Tabelle 5.1 sind die in den Systemen zur Verfügung stehenden Vergleichsoperatoren
dargestellt. Wie aus der Tabelle ersichtlich wird, kann bei der Praxissoftware auf Gleichheit bzw. Ungleichheit geprüft werden. Operatoren für Prüfung auf größere bzw. kleinere
Werte existieren nicht.
ruleDQ
=
Praxissoftware
gleich
!=
ungleich
>=
-
<=
-
>
-
<
-
Bedeutung
Überprüft ob die Werte von zwei Operanden gleich
sind
Überprüft ob die Werte von zwei Operanden ungleich sind
Überprüft ob der Wert des linken Operanden größer
gleich dem Wert des rechten Operanden ist
Überprüft ob der Wert des linken Operanden kleiner gleich dem Wert des rechten Operanden ist
Überprüft ob der Wert des linken Operanden größer
als der Wert des rechten Operanden ist
Überprüft ob der Wert des linken Operanden kleiner als der Wert des rechten Operanden ist
Tabelle 5.1: Vergleichsoperatoren
In Tabelle 5.2 werden die logischen Operatoren der beiden Systeme gegenübergestellt.
Beide Systeme verfügen über Operatoren zur logischen Verknüpfung von Konditionen per
UND und ODER sowie Operatoren zur Prüfung auf das Vorhandensein von Datensätzen.
In Tabelle 5.3 werden weitere Möglichkeiten bei der Formulierung von Konditionen
augelistet. Wie aus der Tabelle ersichtlich ist, können sowohl bei der Praxissoftware als
auch bei ruleDQ Zeiträume eingeschränkt werden. Bei der Praxissoftware geschieht dies
durch Angabe des Schlüsselworts „von“, gefolgt vom Anfangsdatum, einem Bindestrich
und der Angabe des Enddatums. Bei ruleDQ kann diese Funktionalität durch Benutzung
77
5 Entwicklung eines Prototypen
ruleDQ
and
or
exists
Praxissoftware
UND
ODER
vorhanden
not-exists
nicht vorhanden
Bedeutung
Logisches Und
Logisches Oder
Ist erfüllt wenn die folgende Kondition mindestens einmal zutrifft
Ist erfüllt wenn die folgende Kondition nie zutrifft
Tabelle 5.2: Logische Operatoren
der Vergleichsoperatoren kleiner, gleich und größer sowie der Nennung von DatumsFeldern abgebildet werden, z.B.: hireDate >= ’12/12/2012’. Bei der Bestimmung von
Konditionen mit Zeitwerten wird von ruleDQ außerdem zusätzlich die Hilfsfunktion today
bereitgestellt, welche bei der Konditionsauswertung das aktuelle Datum einsetzt.
ruleDQ
x >= Anfangsdatum and
x <= Enddatum
matchesRegex(Attribut,
Muster)
today
(x>y or a>b) and c>d
Praxissoftware
Bedeutung
von Anfangsdatum - End- Einschränkung des Gültigdatum
keitszeitraums
Anwendung von regulären
Ausdrücken
Verwendung des aktuellen
Datums
(x>y or a>b) and c>d
Priorisierung durch Klammerung
Tabelle 5.3: Andere Möglichkeiten bei der Formulierung von Konditionen
Der nächste Funktionsunterschied bei der Formulierung von Konditionen ergibt sich
durch die Möglichkeit der Benutzung von regulären Ausdrücken bei ruleDQ. Da nicht
davon ausgegangen wird, dass alle Anwender mit regulären Ausdrücken vertraut sind,
werden den Nutzern folgende vorgefertigte Ausdrücke zur Auswahl angeboten:
• Überprüfung auf einen positiven Ganzzahlwert
• Überprüfung auf eine bestimmte Anzahl von Zeichen
• Überprüfung auf eine Mindestanzahl von Zeichen
• Überprüfung auf eine Anzahl von Zeichen zwischen einem Intervall [x,y]
78
5.3 Evaluation
Die angebotenen regulären Ausdrücke sind dabei für eine Überprüfung von Formaten
gedacht. Daneben besteht ebenfalls die Möglichkeit der freien Formulierung von regulären
Ausdrücken.
Abseits der Spezifikation von Regelkonditionen ergeben sich weitere Funktionsdiskrepanzen. Den Anwendern wird bei ruleDQ die Option der Bestimmung von Wiederholungsintervallen geboten. Die Regeln werden dann, in den spezifizierten Abständen,
automatisch evaluiert. Als Ergebnis der Evaluierung einer Regel wird ein Messwert
zurückgeben welcher angibt, zu welchem Grad die Regel verletzt wird.
Ein weiterer Unterschied ist die Möglichkeit der Auslösung von Aktionen bei ruleDQ. Im
Rahmen dieser Masterarbeit wurde als Aktion die Versendung einer E-Mail implementiert.
Der Nutzer kann einen selbst-definierten Text und eine beliebige Empfangsadresse
hinterlegen. Nach Erreichung eines vom Nutzer spezifizierten Schwellwerts wird die
hinterlegte E-Mail dann versendet, so z.B., wenn 20% der Datensätze die Regel verletzen.
Abschließend kann festgestellt werden, dass Regeln die mit Hilfe der betrachteten Praxissoftware spezifiziert wurden ohne Funktionsverluste nach ruleDQ übertragen werden
können. Zusätzlich dazu bietet sich die Möglichkeit der Formulierung von komplexeren
Konditionen, der Spezifizierung von Wiederholungsintervallen sowie die Möglichkeit der
Bestimmung von Aktionen bei Verletzung der Regeln.
5.3.2 Laufzeitanalyse
In diesem Unterabschnitt soll die Ausführungsgeschwindigkeit und das asymptotische
Verhalten des selbstentwickelten Regelausführungs-Moduls analysiert werden. Die Ergebnisse dieser Analyse sollen anschließend mit der Leistung der Regelausführungseinheit
der quelloffenen Rule-Engine Drools verglichen werden. Während der Entwicklung von
ruleDQ wurde eine eigene Implementierung der Regelausführung der Benutzung von
Drools vorgezogen. Die in diesem Unterabschnitt folgende Analyse rechtfertigt diese
Entscheidung.
5.3.2.1 Testsystem
Die folgenden Tests wurde auf einem System mit Intel Core i7 M 620 Prozessor und 3.7
GB RAM durchgeführt. Der Prozessor verfügte über vier Kerne mit einem Takt von
2.67GHz. Das Betriebssystem war Ubuntu der Version 12.04 (64 Bit) und Linux Kernel
3.5.0. Als Datenbank wurde MySQL der Version 14.14 eingesetzt. Alle Tests der Drools
Rule-Engine wurden mit Drools 5.4.0 Final durchgeführt.
79
5 Entwicklung eines Prototypen
5.3.2.2 Testbeschreibung
Die Tests wurden auf einer Relation mit folgendem Schema ausgeführt:
CREATE TABLE employees (
emp_no
INT
birth_date DATE
first_name VARCHAR(14)
last_name
VARCHAR(16)
gender
ENUM (’M’,’F’)
hire_date
DATE
PRIMARY KEY (emp_no)
);
NOT
NOT
NOT
NOT
NOT
NOT
NULL,
NULL,
NULL,
NULL,
NULL,
NULL,
Alle Messungen stellen einen Durchschnittswert von zehn Testiterationen dar. Dies soll
den Einfluss von Anomalien möglichst gering halten. Alle Tests wurden mit den gleichen,
anfangs zufällig ausgewählten, Regeln durchgeführt.
5.3.2.3 Analyse der entwickelten Regelausführungseinheit
In diesem Unterabschnitt soll das Laufzeitverhalten der selbstentwickelten Regelausführungseinheit beschrieben werden. In Abbildung 5.16 ist das Laufzeitverhalten in
Abhängigkeit zu der Anzahl von Tupeln dargestellt. Die ermittelten Werte stellen die
Laufzeit für die gleichzeitige Evaluierung von 100 Regeln dar. Wie aus der Abbildung
abzulesen ist, erhöht sich die Laufzeit mit steigender Anzahl an Tupeln linear, wodurch
sich eine Komplexität von O(n) ergibt.
Abbildung 5.17 stellt die Laufzeit in Abhängigkeit zu einer steigenden Anzahl von
Regeln dar. Dabei wird eine Relation mit einer Größe von 100.000 Tupel angenommen.
Wie bei steigender Anzahl von Tupeln ergibt sich bei steigender Anzahl von Regeln ein
lineares Laufzeitverhalten.
Die ermittelten Werte beinhalten die Zeit vom Aufruf der Ausführaktion im Controller
durch den Benutzer, dem Parsen der Regeln in SQL, der Ausführung der Regeln in der
Datenbank bis zur Zurückgabe der Ergebnisse an den Controller. Die Ausführung der
Regeln in der Datenbank macht im Durchschnitt 83% der Laufzeit aus.
5.3.2.4 Analyse einer Drools-basierten Regelausführung
Nachdem das Laufzeitverhalten des implementierten auf SQL-basierenden Regelausführungsmoduls beschrieben wurde, soll im Folgenden alternativ eine Drools-basierte
80
5.3 Evaluation
Bild 5.16: Laufzeit bei 100 Regeln (SQL-basiert)
Bild 5.17: Laufzeit bei 300.000 Tupeln (SQL-basiert)
Regelausführung analysiert werden. Bevor Regeln mit Drools ausgeführt werden können,
muss als Erstes eine Faktenbasis in der JVM initialisiert werden. Bei dem in dieser
Masterarbeit angenommenen Szenario von medizinischen Datenbanken, bedeutet dies
das Übertragen von Tupeln aus der Datenbank in Java-Objekte. In Abbildung 5.18
ist die Dauer dieses Vorgangs auf dem Testsystem in Abhängigkeit zur Anzahl von
Tupeln dargestellt. Bei der Übertragung von Tupeln in eine in der JVM verwaltete
81
5 Entwicklung eines Prototypen
Bild 5.18: Dauer der Faktenbasis-Initialisierung
Faktenbasis, stellt sich die Problematik der Synchronisierung mit der Datenbank. Ein
seltenes Neuladen der Tupel verringert die gesamte Laufzeit, aber erhöht das Risiko von
Inkonsistenzen, während ein öfterer Abgleich der Daten die Wartezeiten vervielfacht.
In Abbildung 5.19 ist die Laufzeit der gleichzeitigen Auswertung von 100 Regeln in
Abhängigkeit zu einer steigenden Anzahl von Tupeln dargestellt.
Bild 5.19: Laufzeit bei 100 Regeln (Drools-basiert)
Die Laufzeit bei 10.000 Tupeln und einer steigender Anzahl von Regeln ist aus
Abbildung 5.20 ersichtlich.
82
5.3 Evaluation
Bild 5.20: Laufzeit bei 10.000 Tupeln (Drools-basiert)
Wie aus den beiden Abbildungen deutlich wird, verhält sich die Laufzeit bis zu einer
mittleren Anzahl an Tupeln (bis 100.000) sowie Regeln (bis 1.000) linear. Bei größeren
Mengen erhöhen sich die Laufzeiten unverhältnismäßig.
Die ermittelten Messwerte in den Abbildungen 5.19 und 5.20 beinhalten einzig die
Laufzeit der Regelausführung. Die Zeiten für die Initialisierung der Regel- und Faktenbasis
wurden nicht berücksichtigt.
In Abbildung 5.21 ist die Speicherauslastung der JVM bei einer steigenden Anzahl
an Tupeln und einer stetigen Anzahl von 100 Regeln dargestellt. Für die in diesem
Unterabschnitt ausgeführten Tests wurde die JVM mit dem Argument -Xmx3048M
ausgeführt, um den maximal zur Verfügung stehenden Speicherplatz zu erhöhen. Die
Messwerte stellen den durchschnittlichen Spitzenwert aus 10 Iterationen zum Zeitpunkt
der Regelausführung dar. Wie aus Abbildung 5.21 ersichtlich wird, benötigt die Auswertung von 100 Regeln bei einer Faktenbasis bestehend aus 300.000 Tupeln über 2.000
MB Heap-Speicher. Die Regelauswertung auf dem SQL-basierenden Ausführungsmodul
beanspruchte stets weniger als 256 MB.
5.3.2.5 Vergleich der Alternativen
Wie aus den bisherigen Ausführungen ersichtlich ist, besitzt die SQL-basierte Alternative
das überlegene asymptotische Laufzeitverhalten. In den folgenden Abbildungen 5.22
und 5.23 sind die absoluten Zeitwerte der beiden Alternativen im Verhältnis zu einer
83
5 Entwicklung eines Prototypen
Bild 5.21: Speicherauslastung der JVM bei 100 Regeln (Drools-basiert)
steigenden Anzahl von Tupeln bzw. Regeln gegenübergestellt. Aus den Abbildungen
Bild 5.22: Vergleich der Laufzeiten bei 100 Regeln
ist zu erkennen, dass die Ausführungsgeschwindigkeit des Drools-basierten Moduls bei
einer niedrigen Anzahl von Regeln (<1.000) und Tupeln (<100.000) in geringen Maßen
schneller ist. Wie die vorher ermittelte Komplexität aber erwarten lässt, ist die Laufzeit
des Drools-basierten Moduls bei einer hohen Anzahl von Regeln oder Tupeln um ein
vielfaches höher.
84
5.3 Evaluation
Bild 5.23: Vergleich der Laufzeiten bei 10.000 Tupeln
Die ermittelten Werte berücksichtigen zudem die Initialisierungszeit der Faktenbasis
nicht, wodurch sich erwarten lässt, dass der geringe zeitliche Vorteil bei einer niedrigen
Anzahl von Tupeln oder Regeln in den meisten Anwendungsfällen obsolet gemacht werden
würde.
Die ermittelten Ergebnisse zeigen, dass das Drools-basierte Modul ein schlechteres
Laufzeitverhalten sowie eine höhere Speicherauslastung als das entwickelte SQL-basierte
Modul besitzt. Dazu kommt die erhöhte Komplexität bei der Verwaltung und Synchronisierung der Faktenbasis. Zusammenfassend lässt sich also feststellen, dass die
Bevorzugung eines SQL-basierten Ausführungsmoduls gerechtfertigt ist.
85
6 Zusammenfassung und Ausblick
In dieser Arbeit wurde die Bedeutung von Datenqualität analysiert und untersucht, wie
diese mit Regelsystemen eingehalten werden kann.
Dazu wurden anfangs alle relevanten Begriffe definiert und ein grundlegendes Verständnis der Problematik geschaffen. Es konnte festgestellt werden, dass es sich bei
Datenqualität um ein multidimensionales Konzept handelt. Außerdem wurde neben der
Definition des Begriffs der Geschäftsregeln untersucht, wie Regeln in Rule-Engines sowie
in relationalen und in NoSQL-Datenbanken umgesetzt sind. Nach dieser Schaffung von
Grundlagen wurde analysiert wie Datenqualität praktisch verbessert werden kann. In der
Literatur wurden verschiedene Managementkonzepte und Vorgehensmodelle gefunden,
die eine Betrachtung von Daten über ihren gesamten Lebenszyklus hinweg fordern. Es
konnte festgestellt werden, dass eine kontinuierliche Messung von Datenqualität und
die Verfolgung von passenden Verbesserungsaktionen nötig sind, um eine nachhaltige
Einhaltung definierter Standards zu gewährleisten. Es wurde untersucht wie der von
Wang vorgeschlagene Datenqualitätsmanagement-Ansatz TDQM praktisch umsetzbar ist
und auf dieser Basis ein Konzept zur Verbesserung von Datenqualität herausgearbeitet.
Als Referenz wurde in dieser Arbeit der Kontext medizinischer Versorgungszentren
angenommen. Eine Analyse von Referenzunternehmen aus diesem Bereich zeigte erhebliche Mängel in der Verfolgung effektiver Datenqualitätsstrategien auf. Innerhalb
der Referenzunternehmen konnten zwar bestehende Datenqualitätsregeln identifiziert
werden, allerdings mangelte es an einem System zur automatisierten Überprüfung und
Überwachung der Regeln. Zur Verbesserung dieses Zustands wurde prototypisch ein
Datenqualitätswerkezug konzipiert, welches es Anwendern ohne informatisches Fachwissen ermöglicht eigenständig Datenqualitätsregeln aufzustellen. Das Werkzeug erlaubt
die Integrierung von in den Referenzunternehmen bestehenden sowie die Formulierung
von neuen komplexeren Regeln. Es ermöglicht eine kontinuierliche und automatisierte
Überprüfung der Datenqualitätsregeln, die Spezifizierung von Aktionen bei Erfüllung
der Regeln sowie die Betrachtung regelverletzender Datensätze. Durch die fortlaufende
Überwachung wird ein erneutes unbemerktes Absinken der Qualität verhindert und
eine nachhaltige Verbesserung der Datenqualität ermöglicht. Das Werkzeug bietet den
87
6 Zusammenfassung und Ausblick
Anwendern in allen Phasen des TDQM Unterstützung und trägt so zu einem effektiven
Datenqualitätsmanagement bei.
In zukünftigen Arbeiten besteht vor allem Verbesserungspotenzial in der Erweiterung
der Funktionalitäten des Datenqualitätswerkezugs. Dabei bietet sich die Erweiterung von
Möglichkeiten bei Formulierung von Regelkonditionen und Aktionen sowie die Anpassung
an weitere SQL-Dialekte an. Die Formulierung der Regelkonditionen kann so etwa durch
die Hinzunahme von Metadaten verbessert werden. Damit könnten z.B. zeitliche Aspekte
der Datenqualität überwacht werden. Die bisher implementierten Aktionen beschränken
sich auf das Versenden von Warnungen bei Identifizierung mangelnder Datenqualitätsniveaus. Zukünftig sind erweiterte Aktionen etwa zur direkten Ausbesserung mangelnder
Daten oder Abweisung unzufriedenstellender Eingaben denkbar.
88
Literaturverzeichnis
[Bal09]
Bali, Michal: Drools JBoss Rules 5.0 Developer’s Guide. Packt Publishing,
2009
[Bal11]
Balzert, H.: Lehrbuch Der Softwaretechnik: Entwurf, Implementierung,
Installation und Betrieb. Spektrum Akademischer Verlag GmbH, 2011
[BCFM09]
Batini, Carlo ; Cappiello, Cinzia ; Francalanci, Chiara ; Maurino,
Andrea: Methodologies for Data Quality Assessment and Improvement. In:
ACM Comput. Surv. 41 (2009), Juli, Nr. 3, S. 16:1–16:52
[BFG+ 07]
Bohannon, Philip ; Fan, Wenfei ; Geerts, Floris ; Jia, Xibei ; Kementsietsidis, Anastasios: Conditional Functional Dependencies for Data
Cleaning. In: ICDE, 2007, S. 746–755
[BP85]
Ballou, Donald P. ; Pazer, Harold L.: Modeling Data and Process Quality
in Multi-Input, Multi-Output Information Systems. In: Management Science
31 (1985), Nr. 2, S. 150–162
[BS06]
Batini, Carlo ; Scannapieco, Monica: Data Quality: Concepts, Methodologies and Techniques. Springer, 2006
[BSM03]
Bovee, Matthew ; Srivastava, Rajendra P. ; Mak, Brenda: A Conceptual
Framework and Belief-Function Approach to Assessing Overall Information
Quality. In: Int. J. Intell. Syst. 18 (2003), Nr. 1, S. 51–74
[BWPT98]
Ballou, Donald ; Wang, Richard ; Pazer, Harold ; Tayi, Giri K.:
Modeling Information Manufacturing Systems to Determine Information
Product Quality. In: Manage. Sci. 44 (1998), April, Nr. 4, S. 462–484
[CFP04]
Cappiello, Cinzia ; Francalanci, Chiara ; Pernici, Barbara: Data
Quality Assessment from the Users Perspective. In: IQIS, 2004, S. 68–73
89
Literaturverzeichnis
[CM08]
Chiang, Fei ; Miller, Renée J.: Discovering Data Quality Rules. In: Proc.
VLDB Endow. 1 (2008), August, Nr. 1, S. 1166–1177
[Dat03]
Date, C.J.: An Introduction to Database Systems. 8. Auflage. AddisonWesley, 2003
[Dem86]
Deming, W E.: Out of the Crisis. In: Center for Advanced Engineering
Study (1986), S. 6
[EBL13]
Endler, Gregor ; Baumgärtel, Philipp ; Lenz, Richard: Pay-as-you-go
Data Quality Improvement for Medical Centers. In: Ammenwerth, E.
(Hrsg.) ; Hörbst, A. (Hrsg.) ; Hayn, D. (Hrsg.) ; Schreier, G. (Hrsg.):
Proceedings of the eHealth2013, 2013, S. 13–18
[Eck02]
Eckerson, Wayne: Data Quality and the Bottom Line: Achieving Business Success through a Commitment to High Quality Data / The Data
Warehousing Institute. 2002. – Forschungsbericht
[ELPL11]
Endler, Gregor ; Langer, Michael ; Purucker, Jörg ; Lenz, Richard:
An Evolutionary Approach to IT Support in Medical Supply Centers. In:
(GI), Gesellschaft für Informatik e.V. (Hrsg.): Informatik 2011, 2011
[EN94]
Elmasri, Ramez ; Navathe, Shamkant B.: Fundamentals of Database
Systems. 2. Auflage. Benjamin/Cummings, 1994
[End12]
Endler, Gregor: Data Quality and Integration in Collaborative Environments. In: SIGMOD/PODS (Hrsg.) ; ACM (Hrsg.): Proceedings of the
SIGMOD/PODS 2012 PhD Symposium. New York, NY, USA, 2012, S.
21–26
[Eng99]
English, L.P.: Improving Data Warehouse and Business Information
Quality: Methods for Reducing Costs and Increasing Profits. Wiley, 1999
[Eur03]
Europäische Union: Richtlinie 2003/98/EG des Europäischen Parlaments und des Rates über die Weiterverwendung von Informationen des
öffentlichen Sektors. 2003
[Fan08]
Fan, Wenfei: Dependencies Revisited for Improving Data Quality. In:
Proceedings of the Twenty-Seventh ACM SIGMOD-SIGACT-SIGART Symposium on Principles of Database Systems. New York, NY, USA : ACM,
2008, S. 159–170
90
Literaturverzeichnis
[FH03]
Friedman-Hill, Ernest: Jess in Action: Java Rule-Based Systems. Greenwich, CT : Manning, 2003
[FK01]
Fisher, Craig W. ; Kingma, Bruce R.: Criticality of Data Quality as
Exemplified in Two Disasters. In: Inf. Manage. 39 (2001), Dezember, Nr. 2,
S. 109–116
[GMUW09] Garcia-Molina, H. ; Ullman, J.D. ; Widom, J.: Database Systems. 2.
Auflage. Pearson Prentice Hall, 2009
[HAE09]
Hellmann, W. ; Antwerpes, T. ; Eble, S.: Gesundheitsnetzwerke
managen: Kooperationen erfolgreich steuern. MWV Medizinisch Wiss.
Verlag-Ges., 2009
[Hay00]
Hay, D. ; Healy, K (Hrsg.): Defining Business Rules ~ What Are They
Really? Final Report, 2000
[Hel02]
Helfert, M.: Planung und Messung der Datenqualität in Data-WarehouseSystemen. Universität Strassburg, 2002
[HGHM11]
Hildebrand, Knut ; Gebauer, Marcus ; Hinrichs, Holger ; Mielke,
Michael: Daten- und Informationsqualität. Auf dem Weg zur Information Excellence. 2. Auflage. Wiesbaden : Vieweg + Teubner / Springer
Fachmedien, 2011
[HR85]
Hayes-Roth, Frederick: Rule-Based Systems. In: Commun. ACM 28
(1985), September, Nr. 9, S. 921–932
[HS98]
Hernández, Mauricio A. ; Stolfo, Salvatore J.: Real-World Data is Dirty:
Data Cleansing and The Merge/Purge Problem. In: Data Min. Knowl.
Discov. 2 (1998), Januar, Nr. 1, S. 9–37
[HW92]
Hanson, Eric ; Widom, Jennifer: An Overview of Production Rules in
Database Systems. In: The Knowledge Engineering Review 8 (1992), S.
121–143
[JLVV03]
Jarke, M. ; Lenzerini, M. ; Vassiliou, Y. ; Vassiliadis, P.: Fundamentals of Data Warehouses. Springer, 2003
[KE11]
Kemper, Alfons ; Eickler, André: Datenbanksysteme - Eine Einführung.
8. Auflage. Oldenbourg, 2011
91
Literaturverzeichnis
[KM12]
Kulkarni, Krishna ; Michels, Jan-Eike: Temporal Features in SQL:2011.
In: SIGMOD Record Vol. 41, No. 3 (2012)
[LC02]
Liu, L. ; Chi, L.: Evolutionary Data Quality. In: the 7th International
Conference on Information Quality (ICIQ 02). Boston, MA, 2002
[Los02]
Loshin, David: Rule-Based Data Quality. In: Proceedings of the Eleventh
International Conference on Information and Knowledge Management. New
York, NY, USA : ACM, 2002, S. 614–616
[Los10]
Loshin, David: The Practitioner’s Guide to Data Quality Improvement.
Elsevier Science, 2010
[LPFW09]
Lee, Yang W. ; Pipino, Leo L. ; Funk, James D. ; Wang, Richard Y.:
Journey to Data Quality. The MIT Press, 2009
[MS02]
Melton, J. ; Simon, A.R.: SQL:1999: Understanding Relational Language
Components. Morgan Kaufmann, 2002
[Nau02]
Naumann, Felix: Quality-Driven Query Answering for Integrated Information Systems. Berlin, Heidelberg : Springer-Verlag, 2002
[Nau07]
Naumann, Felix: Datenqualität. In: Informatik Spektrum 30 (2007), Nr. 1,
S. 27–31
[NLIH13]
Nance, Corey ; Losser, Travis ; Iype, Reenu ; Harmon, Gary: NoSQL
vs RDBMS - Why There is Room for Both. In: Proceedings of the Southern
Association for Information Systems Conference, 2013
[Off06]
Office Of Management and Budget: Information Quality Guidelines
for Ensuring and Maximizing the Quality, Objectivity, Utility, and Integrity
of Information Disseminated by Agencies. 2006
[OGOG+ 11] Okman, Lior ; Gal-Oz, Nurit ; Gonen, Yaron ; Gudes, Ehud ; Abramov, Jenny: Security Issues in NoSQL Databases. In: International Joint
Conference of IEEE TrustCom-11/IEEE ICESS-11/FCST-11 (2011)
[Omi07]
92
Omikron Data Quality GmbH: Datenqualität in Unternehmen häufig
mangelhaft. 2007
Literaturverzeichnis
[Pie04]
Pierce, Elizabeth M.: Assessing Data Quality with Control Matrices. In:
Commun. ACM 47 (2004), Februar, Nr. 2, S. 82–86
[PLW02]
Pipino, Leo L. ; Lee, Yang W. ; Wang, Richard Y.: Data Quality
Assessment. In: Commun. ACM 45 (2002), April, Nr. 4, S. 211–218
[Qua14]
Quartz: Quartz Scheduler 2.1.x Documentation, 2014
[Red97]
Redman, Thomas C.: Data Quality for the Information Age. 1. Auflage.
Norwood, MA, USA : Artech House, Inc., 1997
[SH97]
Saake, Gunter ; Heuer, Andreas: Datenbanken: Konzepte und Sprachen.
International Thomson, 1997
[SI05]
Shuxin, Yin ; Indrakshi, Ray: Relational Database Operations Modeling
with UML. In: 2013 IEEE 27th International Conference on Advanced
Information Networking and Applications (AINA) 1 (2005), S. 927–932
[SMB05]
Scannapieco, Monica ; Missier, Paolo ; Batini, Carlo: Data Quality at
a Glance. In: Datenbank-Spektrum 14 (2005), S. 6–14
[SRR+ 07]
Sasikumar ; Ramani ; Raman ; Anjaneyulu ; Chandrasekar: A
Practical Introduction to Rule Based Expert Systems. Narosa Publishing
House, New Delhi, 2007
[Sta07]
Starke, Gernot: Regelbasierte Systeme. In: JavaSPEKTRUM (6/2007),
S. 36–38
[Sta08]
Starke, Gernot: Effektive Software-Architekturen: Ein praktischer Leitfaden. Hanser, 2008
[Stü93]
Stürner: Oracle7 - Die verteilte Datenbank. 2. Auflage. dbms publishing,
1993
[Ten01]
Tennant, G.: Six Sigma: SPC and TQM in manufacturing and services.
Gower Publishing, Ltd., 2001
[Wik]
Wikipedia: Model-View-Controller. http://en.wikipedia.org/wiki/
File:MVC-Process.svg. – [Aufgerufen: 12.01.2014]
93
Literaturverzeichnis
[WS96]
Wang, Richard Y. ; Strong, Diane M.: Beyond Accuracy: What Data
Quality Means to Data Consumers. In: J. Manage. Inf. Syst. 12 (1996),
März, Nr. 4, S. 5–33
[WW96]
Wand, Yair ; Wang, Richard Y.: Anchoring Data Quality Dimensions in
Ontological Foundations. In: Commun. ACM 39 (1996), November, Nr. 11,
S. 86–95
[WZL01]
Wang, Richard Y. ; Ziad, Mostapha ; Lee, Yang W.: Data Quality. Bd. 23.
Kluwer, 2001
94