Gesammelte Seminararbeiten

Universität Karlsruhe (TH)
Fakultät für Informatik
Institut für Programmstrukturen und
Datenorganisation (IPD)
Hauptseminar
Imperfektion und erweiterte Konzepte im Data
Warehousing
Gesammelte Seminararbeiten
Sommersemester 2005
Inhaltsverzeichnis
Abbildungsverzeichnis
vii
1 Erweiterte Entwurfskonzepte
1.1
1.2
1.3
1.4
Einführung in DWS . . . . . . . . . . . . . . . . .
1.1.1
Denition DWS . . . . . . . . . . . . . . .
1.1.2
Anwendungsbereich . . . . . . . . . . . . .
Entwurfsgrundlagen für DWS . . . . . . . . . . . .
1.2.1
Konzeptuelle Modellierung - ME/R-Modell
1.2.2
Logische Modellierung . . . . . . . . . . . .
1.2.3
Snowake-Schema . . . . . . . . . . . . . .
1.2.4
Star-Schema . . . . . . . . . . . . . . . . .
Erweiterte Entwurfskonzepte . . . . . . . . . . . .
1.3.1
konformierte Dimensionstabelle . . . . . . .
1.3.2
Erweiterte Dimensionstabelle . . . . . . . .
Zusammenfassung . . . . . . . . . . . . . . . . . .
2 Datenqualität
2.1
2.2
2.3
2.4
2.5
Einleitung . . . . . . . . . . . . . . . . .
Daten . . . . . . . . . . . . . . . . . . .
2.2.1
Daten - Informationen - Wissen
2.2.2
Daten im Verkehrsbereich . . . .
Datenqualität . . . . . . . . . . . . . . .
2.3.1
Denition . . . . . . . . . . . . .
2.3.2
Qualitätskriterien . . . . . . . .
2.3.3
Einuss schlechter Datenqualität
Datenqualitätsmanagement . . . . . . .
2.4.1
Systemorientierter Ansatz . . . .
2.4.2
Produktorientierter Ansatz . . .
2.4.3
Vergeich . . . . . . . . . . . . . .
Fazit . . . . . . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
3 Datenqualität - Der GQM-Ansatz und das DWQ-Projekt
3.1
3.2
Einleitung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
DWQ-Projekt . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.2.1
Die Struktur des DWQ . . . . . . . . . . . . . . . . . . .
1
1
1
2
3
4
6
6
7
10
10
12
16
19
19
19
19
20
21
21
22
24
24
24
26
28
28
29
30
31
31
i
Inhaltsverzeichnis
3.3
3.4
3.5
3.2.2
Schwerpunkte des DWQ-Projekts .
3.2.3
Komponenten eines Data-Warehouse
3.2.4
Bezug zur Datenqualität . . . . . .
DWQ-Rahmenarchitektur . . . . . . . . . .
3.3.1
konzeptionelle Perspektive . . . . .
3.3.2
Logische Perspektive . . . . . . . . .
3.3.3
Physikalische Perspektive . . . . . .
3.3.4
Beziehungen zwischen Perspektiven
Bestimmung Data-Warehouse Qualität . . .
3.4.1
QFD-Quality Function Deployment
3.4.2
GQM-Goal Quality Metric . . . . .
Zusammenfassung . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
Einleitung . . . . . . . . . . . . . . . . . . . . . . . .
Summierbarkeit . . . . . . . . . . . . . . . . . . . .
4.2.1
Ziele . . . . . . . . . . . . . . . . . . . . . . .
4.2.2
Szenario . . . . . . . . . . . . . . . . . . . . .
4.2.3
Bedingungen . . . . . . . . . . . . . . . . . .
4.2.4
Fazit . . . . . . . . . . . . . . . . . . . . . .
Ansatz nach Pedersen, Jensen & Dyreson . . . . . .
4.3.1
Szenario . . . . . . . . . . . . . . . . . . . . .
4.3.2
Prinzip . . . . . . . . . . . . . . . . . . . . .
4.3.3
Vollständigkeit . . . . . . . . . . . . . . . . .
4.3.4
Disjunktheit . . . . . . . . . . . . . . . . . .
4.3.5
Fazit . . . . . . . . . . . . . . . . . . . . . .
Fuzzy-Summierbarkeit . . . . . . . . . . . . . . . . .
4.4.1
Szenario . . . . . . . . . . . . . . . . . . . . .
4.4.2
Benötigte Denitionen . . . . . . . . . . . . .
4.4.3
Prinzip Fuzzy-Dimensionen . . . . . . . . .
4.4.4
Fuzzy-Vollständigkeit und Fuzzy-Disjunktheit
4.4.5
Fazit . . . . . . . . . . . . . . . . . . . . . .
Vergleich . . . . . . . . . . . . . . . . . . . . . . . .
4.5.1
Ansatz . . . . . . . . . . . . . . . . . . . . .
4.5.2
Zusammenfassung . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
4 Fuzzy-Summierbarkeit
4.1
4.2
4.3
4.4
4.5
5 Common Warehouse Metamodel und Imperfektion
5.1
5.2
5.3
ii
Einleitung . . . . . . . . . . . . . . . . . . . . .
Metadaten und Metadatenmanagement . . . .
5.2.1
Bedeutung von Metadaten . . . . . . .
5.2.2
Metadatenmanagement . . . . . . . . .
5.2.3
Umsetzung des Metadatenmanagement
Das Common Warehouse Metamodel (CWM) .
5.3.1
Die Schichten des CWM . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
32
33
33
35
36
38
38
39
39
40
41
43
45
45
45
45
46
47
49
49
49
50
51
51
53
53
53
54
55
56
57
57
57
57
59
59
60
60
61
61
62
64
Inhaltsverzeichnis
5.4
5.5
5.6
5.3.2
Der Austausch von Metadaten im CWM . . . . . .
5.3.3
Erweiterungsmöglichkeiten . . . . . . . . . . . . . .
Imperfektion in Datenbanken . . . . . . . . . . . . . . . . .
5.4.1
Der Begri der Imperfektion . . . . . . . . . . . . .
5.4.2
Theorien und Modelle zur Imperfektion . . . . . . .
Erweiterung des CWM zur Modellierung imperfekter Daten
5.5.1
Erweiterung durch Stereotypes und TaggedValues .
5.5.2
Objektorientierte Erweiterung . . . . . . . . . . . .
Fazit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6 Fuzzy UML
6.1
6.2
6.3
6.4
6.5
Introduction . . . . . . . . . . . . . . . . . .
Basic knowledge . . . . . . . . . . . . . . . .
6.2.1
Fuzzy Set and Possibility Distribution
6.2.2
UML Class Model . . . . . . . . . . .
Fuzzy objects and classes . . . . . . . . . . .
6.3.1
Fuzzy objects . . . . . . . . . . . . . .
6.3.2
Fuzzy classes . . . . . . . . . . . . . .
6.3.3
Fuzzy object-class relationships . . . .
Fuzzy Modeling of Fuzzy Data . . . . . . . .
6.4.1
Fuzzy Class . . . . . . . . . . . . . . .
6.4.2
Fuzzy Generalization . . . . . . . . .
6.4.3
Fuzzy Aggregation . . . . . . . . . . .
6.4.4
Fuzzy Association . . . . . . . . . . .
6.4.5
Fuzzy Dependency . . . . . . . . . . .
Conclusions . . . . . . . . . . . . . . . . . . .
7 Fortgeschrittene OLAP-Analysemodelle
7.1
7.2
7.3
7.4
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
Einleitung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Datenmodelle und Modellierung von Systemen . . . . . . . . . .
7.2.1
Systemmodelle . . . . . . . . . . . . . . . . . . . . . . . .
7.2.2
Datenmodelle . . . . . . . . . . . . . . . . . . . . . . . . .
Klassikation nach Codd . . . . . . . . . . . . . . . . . . . . . .
7.3.1
Kategorisches Modell . . . . . . . . . . . . . . . . . . . .
7.3.2
Exegatives Modell . . . . . . . . . . . . . . . . . . . . . .
7.3.3
Kontemplatives Modell . . . . . . . . . . . . . . . . . . .
7.3.4
Formalisiertes Modell . . . . . . . . . . . . . . . . . . . .
Datenmodelle in der Implementierung . . . . . . . . . . . . . . .
7.4.1
Vorbemerkungen . . . . . . . . . . . . . . . . . . . . . . .
7.4.2
Kategorisches Modell und OLTP-Datenmodelle . . . . . .
7.4.3
Exegatives Modell und Data Warehouses . . . . . . . . .
7.4.4
Kontemplatives Modell für fortgeschrittene Analysefunktionen . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7.4.5
Formalisiertes Modell für abstrakte Analysen . . . . . . .
66
66
68
68
68
70
71
72
75
77
77
79
79
80
82
82
82
83
84
84
84
87
88
91
91
95
95
96
96
97
97
98
98
99
101
103
103
103
104
104
105
iii
Inhaltsverzeichnis
7.5
Fazit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106
8 Visualisierung der Imperfektion in multidimensionalen Daten
8.1
8.2
8.3
8.4
8.5
Einführung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109
8.1.1
Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . 109
8.1.2
Begrie . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109
Visualisierung imperfekter Informationen im Straÿenverkehr . . . 110
8.2.1
Benutzergruppen im Straÿenverkehrsbereich . . . . . . . . 110
8.2.2
Visualisierungstechniken (noch ohne Imperfektion) . . . . 111
8.2.3
Erweiterung der drei vorgestellten Verfahren um Imperfektion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115
8.2.4
Skizzierung des Visualisierungswerkzeugs . . . . . . . . . 119
Datenvisualisierung und Visual Data Mining (VDM) . . . . . . . 119
8.3.1
Einordnung des VDM . . . . . . . . . . . . . . . . . . . . 120
8.3.2
Automatisiertes Data Mining und seine Schwächen . . . . 122
8.3.3
Visuelle Datenexploration . . . . . . . . . . . . . . . . . . 123
8.3.4
Beispiel-Einsatzgebiet für VDM: Kooperatives Data Mining123
8.3.5
Klassizierung visueller Data Mining Techniken . . . . . 127
Einordnung und Vergleich . . . . . . . . . . . . . . . . . . . . . . 127
Zusammenfassung und Ausblick . . . . . . . . . . . . . . . . . . 129
9 Stream Clustering
9.1
9.2
9.3
9.4
9.5
9.6
9.7
iv
109
Einleitung . . . . . . . . . . . . . . . . . . . . . . . . . . .
9.1.1
Praktische Anwendungen . . . . . . . . . . . . . .
9.1.2
Überblick über dieses Kapitel . . . . . . . . . . . .
Grundlagen . . . . . . . . . . . . . . . . . . . . . . . . . .
Stream Clustering . . . . . . . . . . . . . . . . . . . . . .
9.3.1
Eigenschaften von Datenströmen . . . . . . . . . .
9.3.2
Aufgaben von Stream Clustering . . . . . . . . . .
9.3.3
Eignung herkömmlicher Algorithmen . . . . . . . .
9.3.4
Allgemeine Lösungsansätze . . . . . . . . . . . . .
Evolution von Datenströmen . . . . . . . . . . . . . . . .
9.4.1
Mikroclustering . . . . . . . . . . . . . . . . . . .
9.4.2
Pyramidal Time Frame . . . . . . . . . . . . . . .
9.4.3
Makroclustering . . . . . . . . . . . . . . . . . . .
Projected Clustering für hochdimensionale Datenströmen
9.5.1
Projected Clustering . . . . . . . . . . . . . . . . .
9.5.2
HPStream Algorithmus . . . . . . . . . . . . . . .
Bewertung . . . . . . . . . . . . . . . . . . . . . . . . . .
9.6.1
Bewertungskriterien . . . . . . . . . . . . . . . . .
9.6.2
Bewertungsmethoden . . . . . . . . . . . . . . . .
9.6.3
Datenauswahl . . . . . . . . . . . . . . . . . . . .
9.6.4
Bewertung der vorgestellten Algorithmen . . . . .
Zusammenfassung . . . . . . . . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
131
131
132
132
132
133
133
134
134
134
135
135
137
139
139
139
140
141
141
142
142
142
144
Inhaltsverzeichnis
10 Process Mining
10.1
10.2
10.3
10.4
10.5
Einleitung . . . . . . . . . . . . . .
10.1.1
Motivation . . . . . . . . .
10.1.2
Ziel . . . . . . . . . . . . .
10.1.3
Petri- und Workow-Netze
10.1.4
Ordnungsrelationen . . . .
Probleme . . . . . . . . . . . . . .
10.2.1
Versteckte Tätigkeit . . . .
10.2.2
Doppelte Tätigkeit . . . . .
10.2.3
Schleifen . . . . . . . . . .
10.2.4
Verrauschte Daten . . . . .
Algorithmen . . . . . . . . . . . .
10.3.1
α-Algorithmus . . . . . . .
Mining Prozess . . . . . . . . . . .
10.4.1
Pre-Processing . . . . . . .
10.4.2
Processing . . . . . . . . .
10.4.3
Post-Processing . . . . . .
Schluÿbemerkung . . . . . . . . .
Literaturverzeichnis
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
147
147
147
148
148
149
150
150
151
152
152
154
154
155
155
156
156
156
157
v
Abbildungsverzeichnis
1.1
1.2
1.3
1.4
1.5
1.6
1.7
1.8
1.9
1.10
1.11
1.12
1.13
1.14
1.15
1.16
Entwurfsprozess von Datenbanksystemen . . . . .
Grasche Notation der ME/R-Elemente . . . . . .
Kaufhaus-Szenario in ME/R-Notation . . . . . . .
Snowake-Schema . . . . . . . . . . . . . . . . . .
Snowake-Schema-Beispiel . . . . . . . . . . . . . .
Star-Schema . . . . . . . . . . . . . . . . . . . . . .
Star-Schema-Beispiel . . . . . . . . . . . . . . . . .
Speditionsszenario 1 . . . . . . . . . . . . . . . . .
Speditionsszenario 2 . . . . . . . . . . . . . . . . .
Speditionsszenario: konformierte Dimensionstabelle
Many-to-many-Dimension 1 . . . . . . . . . . . . .
Many-to-many-Dimension 2 . . . . . . . . . . . . .
Many-to-many-Dimension 3 . . . . . . . . . . . . .
Role-playing-Dimension 1 . . . . . . . . . . . . . .
Role-playing-Dimension 2 . . . . . . . . . . . . . .
Role-playing-Dimension 3 . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
3
5
6
7
8
9
9
11
11
12
13
13
14
15
16
16
2.1
2.2
2.3
2.4
Daten - Informationen - Wissen . . . . . . . . .
Qualitätskriterien . . . . . . . . . . . . . . . . .
Systemorientierter Ansatz - Informationssystem
Produktorientierter Ansatz - Qualitätszyklus .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
20
22
25
27
3.1
3.2
3.3
3.4
3.5
3.6
Vom OLTP- zum OLAP-Prozess . . . . . . . . . . . . . . . . . . . . .
Beispiel einer Struktur eines Data-Warehouses . . . . . . . . . . . . . .
Qualitätsfaktoren in einem Data-Warehouse . . . . . . . . . . . . . . .
Die Beziehung der Qualitätsfaktoren zu den Data-Warehouse-Aufgaben
Die drei Aspekte einer Data-Warehouse-Architektur . . . . . . . . . .
House of Quality im Quality-Function-Deployment . . . . . . . . . . .
31
34
34
36
37
41
4.1
4.2
4.3
4.4
4.5
4.6
Dimension Kundendaten nach Region . . . . .
Vollständigkeit nicht berücksichtigter Wert . .
Vollständigkeit fehlender Wert . . . . . . . . .
Disjunktheit mehrfach berücksichtigter Wert . .
Dimension eines Krankenhaus-Datenbanksystems
Transformation durch makeCovering . . . . . . .
46
47
47
48
50
51
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
vii
Abbildungsverzeichnis
4.7
4.8
4.9
4.10
4.11
4.12
Transformation durch makeOnto . . . . . . . . .
Transformation durch makeStrict (1. fuse nodes)
Transformation durch makeStrict (2. unlink) . .
vollständige Transformation durch makeStrict . .
Bauplan des Stockwerks aus Beispiel 4.4.1 . . . .
Dimension für Beispiel 4.4.1 . . . . . . . . . . . .
.
.
.
.
.
.
51
52
52
52
53
54
5.1
5.2
5.3
5.4
5.5
5.6
5.7
5.8
Metamodellarchitektur der OMG . . . . . . . . . . . . . . . . . . . . .
CWM-Schichtenmodell . . . . . . . . . . . . . . . . . . . . . . . . . . .
Erweiterung des Objekt-Modells durch Stereotypes und TaggedValues .
Zugehörigkeitsfunktionen a) scharf b) fuzzy . . . . . . . . . . . . . . .
Imperfekte Stereotypes . . . . . . . . . . . . . . . . . . . . . . . . . . .
Beispiel eines imperfekten Table -Objekts . . . . . . . . . . . . . . . . .
Ausschnitt des Core -Pakets . . . . . . . . . . . . . . . . . . . . . . . .
Erweiterung des Core-Paketes um Möglichkeiten der Modellierung von
Imperfektion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
64
64
67
70
71
72
73
6.1
6.2
6.3
6.4
6.5
6.6
6.7
6.8
6.9
6.10
6.11
6.12
6.13
6.14
Database Design Process . . . . . .
Fuzzy set to concept tall person .
The class icon . . . . . . . . . . . .
Simple aggregation relationship . .
Simple generalization relationship .
Simple association relationship . .
Simple dependency relationship . .
A fuzzy class . . . . . . . . . . . .
A fuzzy generalization relationship
A fuzzy aggregation relationship .
Fuzzy association relationships . .
Fuzzy dependency relationship . .
A fuzzy UML data model . . . . .
The denition of a fuzzy class . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
78
79
80
81
81
81
82
84
86
89
89
91
92
93
7.1
7.2
7.3
7.4
Kategorisches Modell .
Exegatives Modell . .
Kontemplatives Modell
Formalisiertes Modell .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. 98
. 99
. 100
. 102
8.1
8.2
8.3
8.4
8.5
8.6
Übersicht der Visualisierungstechniken [For05] . . . . . . . . . . . . . .
Bewertungstabelle Visualisierungstechniken [For05] . . . . . . . . . . .
Beispiel ThemeRiver [SHW02] . . . . . . . . . . . . . . . . . . . . . . .
Prinzip der parallelen Koordinaten [Spe01] . . . . . . . . . . . . . . . .
Inxight Table Lens [IS] . . . . . . . . . . . . . . . . . . . . . . . . . . .
ThemeRiver ohne (li.) und mit (re.) Ergänzung um Ungenauigkeit - auf
beiden Seiten ist die Unschärfe durch linguistische Variablen visualisiert.
[For05] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
viii
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
74
113
113
114
114
115
117
Abbildungsverzeichnis
8.7 Parallele Koordinaten, erweitert um Imperfektion. [For05] . . . . . . .
8.8 Table Lens, erweitert um Imperfektion. [For05] . . . . . . . . . . . . .
8.9 Bewertung der um Imperfektion erweiterten Visualisierungstechniken.
[For05] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
8.10 Paketstruktur im Visualisierungswerkzeug [For05] . . . . . . . . . . . .
8.11 Einordnung des VDM zwischen Data Mining und Informationsvisualisierung [Fay96] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
8.12 VDM im KDD-Prozess [Fay96] . . . . . . . . . . . . . . . . . . . . . .
8.13 Ansätze des visuellen Data Mining . . . . . . . . . . . . . . . . . . . .
8.14 Exemplarischer Entscheidungsbaum [Ank04] . . . . . . . . . . . . . . .
8.15 Der interaktive Mining-Prozess mit DataJewel [Ank04] . . . . . . . . .
8.16 Die Visualisierungstechnik CalendarView [Ank04] . . . . . . . . . . . .
8.17 Klassikation visueller DM-Techniken [Kei01] . . . . . . . . . . . . . .
117
118
9.1
9.2
9.3
9.4
9.5
9.6
9.7
9.8
9.9
9.10
136
136
137
138
138
142
143
143
144
144
Architektur des CluStream Algorithmus . . . . . . . . . .
Mikrocluster Datenstruktur . . . . . . . . . . . . . . . . .
Zustandsdiagramm zum Mikroclustering . . . . . . . . . .
Historie H17 . . . . . . . . . . . . . . . . . . . . . . . . . .
Historie H55 . . . . . . . . . . . . . . . . . . . . . . . . . .
Sum of Square Distances am Beispiel . . . . . . . . . . . .
Qualitätsvergleich (aus [AHWY03]) . . . . . . . . . . . . .
Verarbeitet Datenrate (aus [AHWY03]) . . . . . . . . . .
Qualität von HPStream und CluStream (aus [AHWY04])
Skalierbarkeit und Datenrate (aus [AHWY04]) . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
118
119
120
121
122
124
125
126
127
10.1 Beispiel für versteckte Tasks . . . . . . . . . . . . . . . . . . . . . . . . 151
10.2 Beispiel für doppelte Tasks . . . . . . . . . . . . . . . . . . . . . . . . 151
10.3 Beispiel für problematische Schleifen . . . . . . . . . . . . . . . . . . . 152
ix
Yingzhe Liu
1
Erweiterte Entwurfskonzepte
1.1 Einführung in DWS
Aufgrund der enormen operativen Datenmenge und dem Bedarf für EchtzeitReporting bzw. für die Auswertung durch OLAP (OnLine Analytical Processing)
werden auf der Basis operativer Daten in betrieblichen Informationssystemen Data
Warehouses immer mehr eingesetzt. Die Analyse bzw. Auswertung von umfangreichen Daten aus betrieblichen Informationssystemen stellt sich als Hauptzweck des
Data Warehouse dar. In einem Data-Warehouse-System (DWS) sollen umfangreiche Datenbestände aus vielen verschiedenen Quellsystemen in passender Form zur
Verfügung gestellt werden. Eine der zentralen Themen im Data Warehousing stellt
die Modellierung der Datenstrukturen dar.
In dieser Arbeit werden die Grundlagen auf Modellierungsebene im Data Warehousing, insbesondere die erweiterte konzeptuelle und logische Modellierung, erläutert. Vollständigkeitshalber wird zuerst die Begriichkeit im Bereich von DataWarehouse-Systemen im Kapitel 1 vorgestellt. Kapitel 2 behandelt die grundlegenden Entwurfskonzepte für DWS. Anschlieÿend werden die erweiterten Entwurfskonzepte für DWS in Kapitel 3 vorgestellt. Zum Schluÿ werfen wir einen Blick auf
verwandte Forschungen.
1.1.1 Denition DWS
Data-Warehouse-Systeme repräsentieren ein analyseorientiertes Informationsystem
einer Organisation.
Eine ozielle Denition von Data Warehouse gibt es bis heute nicht. Die am
häugsten zitierte Denition nach Bill Inmon [Imm96] lautet:
1
1 Erweiterte Entwurfskonzepte
Denition 1.1.1 (Data-Warehouse-System) A data warehouse is a subject-
oriented, integrated, time-varying, non-volatile collection of data in support of the
managements decision-making process.
Ein Data Warehouse hat nach dieser Denition also vier Eigenschaften (siehe
[BG01]), die alle der Entscheidungsunterstützung dienen:
• Fachorientierung
Die Datenbasis dient also zur Modellierung eines spezischen Anwendungsziels.
• Integrierte Datenbasis
Die Datenverarbeitung ndet auf integrierten Daten aus mehreren Datenbanken statt.
• Nicht üchtige Datenbasis
Daten, die einmal in das Data Warehouse eingebracht wurden, werden kaum
entfernt oder geändert.
• Historische Daten
Die Daten werden über einen längeren Zeitraum gehalten. Der DW-Prozess,
auch Data Warehousing genannt, beschreibt den dynamischen Vorgang:
Datenbeschaungsprozess → Datenspeichern → Datenanalyse
Ein Data-Warehouse-System enthält Systemkomponenten und einzelne, riesige
Datenbanken. Ein Data Warehouse ist jedoch mehr als die Summe seiner Komponenten, d.h. erst mit dem Data-Warehouse-System kann es seine Aufgaben erfüllen.
1.1.2 Anwendungsbereich
Der Hintergrund für DWS ist die Analysierbarkeit der Daten: eine homogene und
integrierte Datenbasis, um eine eziente und zielorientierte Analyse durchzuführen.
Im Folgenden werden drei häuge Anwendungsbereiche genannt.
• Betriebswirtschaftliche Anwendungsgebiete
Die häugsten Einsatzbereiche benden sich zurzeit hier. Es gibt eigentlich
keinen Bereich eines Unternehmens, in welchem auf Daten und Informationen für eine erfolgreiche Abwicklung der Geschäftsprozesse verzichtet werden kann. In diesem Bereich gibt es die vier Untergebiete: Informationsbereitstellung, Analyse, Planung und Kampagnenmanagement (siehe: [BG01]).
Mit den dargestellten Informationen können qualizierte Anwender Analysen
durchführen und weitergehende Erkenntnisse gewinnen.
2
1.2 Entwurfsgrundlagen für DWS
• Wissenschaftliche Anwendungsgebiete
Aus diesem Bereich stammen auch die technischen Wurzeln der DW-Technologie, vor allem im Hinblick auf die datenbanktechnische Speicherung und
Verarbeitung. Bei wissenschaftlichen, empirischen Untersuchungen fallen oft
groÿe Mengen an Daten, beispielsweise Messwerte, an. Ein beispielhaftes Projekt lautet Earth Observing System [Mic91].
• Technische Anwendungsgebiete
Auch in technisch orientierten Anwendungsfeldern gibt es viele mögliche Verwendungszwecke. Wir erklären es durch ein paar Beispiele. Hier gelten die
Mechanismen, die dem Data Warehousing zugrunde liegen, entsprechend. Eine Fabrik kann beispielsweise eine Sto- oder Materialdatenbank aufbauen,
um die in Produkten verwendeten Materalien zu dokumentieren. So können
die verantwortlichen Lieferanten bei Rückfrufaktionen oder Gewährleistungsfällen festgestellt werden. (siehe auch [BG01] in Kapitel 11.5).
1.2 Entwurfsgrundlagen für DWS
Hier gehen wir zuerst auf den typischen Entwurfsprozess von Datenbanksystemen
ein. Diesen zeigt Abbildung 1.1 .
Abbildung 1.1: Entwurfsprozess von Datenbanksystemen
Im typischen Entwurfsprozess von Datenbanksystemen werden nach der Anforderungsanalyse die konzeptuelle und logische Datenbankmodellierung durchgeführt.
Dabei werden die Anforderungen an das Datenbanksystem zuerst im konzeptuellen
Schema und dann im logischen Schema abgebildet. Aus Sicht der Datenbanktheorie
wird die konzeptuelle Modellierung eher auf einer von Zieldatenmodellen unabhängigen Ebene durchgeführt. Deshalb ist das konzeptuelle Schema unabhängig vom
3
1 Erweiterte Entwurfskonzepte
konkret verwendeten Zieldatenmodell. Demgegenüber wird das logische Schema in
einem konkreten Datenmodell dargestellt. Nach der Entscheidung für ein konkretes
Datenbanksystem wird das interne Schema hergestellt (vgl. [Leh03b]).
Im klassischen relationalen Datenbankenentwurf ndet für die Erstellung des konzeptionellen Schemas meist eine Variante des Entity/Relationship-Modells (E/RModell) Anwendung. Das logische Datenschema wird dann formal im konkreten
relationalen Datenmodell speziziert. Das relationale Datenmodell stellt dazu lediglich Relationen über Attribute als Ausdrucksmittel bereit. Die Schönheit eines
logischen Schemas als Ergebnis des logischen Datenbankenentwurfs wird dabei formal quantizierbar durch den Grad der vorgenommenen Normalisierung bestimmt.
Das interne Schema wird durch die Fähigkeiten des jeweiligen Datenbanksystems
bestimmt (vgl. [BG01]).
Der Entwurf von Data-Warehouse-Systemen wird in der Praxis analog wie der
vorstehende Entwurfsprozess von klassischen Datenbanksystemen vorgehen. Die
Frage hier ist aber, wie das Datenmodell in Data-Warehouse-Systemen aussehen soll und welche konzeptuelle und logische Modellierungsmethode in DataWarehouse-Systemen eingesetzt werden sollen. In dieser Arbeit werden entsprechend folgende Fragen erklärt:
• Welche konzeptuellen Modellierungen von Data-Warehouse-Systemen existieren? Welche logischen Modellierungsschemata nden bei der Modellierung
von Data-Warehouse-Systemen Anwendung?
• Was für erweiterte Konzepte sind in welchen Anwendungsfällen geeignet?
Daraus ergibt sich als Zielsetzung dieses Kapitel, einen Überblick sowohl über die
Grundlagen der konzeptuellen und logischen Modellierung von Data-WarehouseSystemen als auch darüber hinausgehende erweiterte Konzepte zu geben.
1.2.1 Konzeptuelle Modellierung - ME/R-Modell
Die ME/R-Notation (Multidimensional Entity/Relationship, [SBHD99]) wurde
als spezielle Modellierungstechnik für multidimensionale Schemata entwickelt.
Sie stellt eine Erweiterung des bekannten E/R-Ansatzes (Entity/Relationship,
[Che76]) für relationale Schemata dar. Die Grundidee des ME/R-Ansatzes ist wie
folgt: Um eine naturgemäÿe Darstellung der multidimensionalen Semantik zu erlauben, wird das E/R-Modell entsprechend spezialisiert und geringfügig erweitert.
Zuerst sollen alle eingeführten Elemente der ME/R-Notation Spezialfälle der ursprünglichen E/R-Konstrukte sein, damit Leute, die mit dem E/R-Modell schon
erfahren sind, auch das ME/R-Modell verstehen und benutzen können. Die Semantik muss die Unterscheidung zwischen Klassikationsschema, Würfelstruktur und
die hierarchische Struktur der Klassikationen darstellen.
Aus dieser Überlegung führt die ME/R-Notation folgende spezialisierte Konstrukte zusätzlich zur ursprünglichen E/R-Notation ein (siehe Abbildung 1.2):
• Eine spezielle Entitätenmenge Klassikationsstufe
4
1.2 Entwurfsgrundlagen für DWS
• Eine spezielle Entität Fakt
• Eine spezielle binäre Klassikationbeziehung zur Verbindung von Klassikationsstufen.
• Eine aus E/R übernommene Faktbeziehung, um Fakten und Dimensionen zu
verbinden.
Die Klassikationsbeziehung verbindet eine Dimensionsstufe A mit einer Dimensionsstufe B, welche eine höherwertige Abstraktionsebene darstellt. Beispielsweise
werden Städte nach Ländern klassiziert. Aufgrund der speziellen Semantik der
Klassikationsbeziehung dürfen keine Zyklen im so genannten Klassikationsgraphen existieren (vgl. [BG01]).
Abbildung 1.2: Grasche Notation der ME/R-Elemente
Die Faktbeziehung stammt aus einer allgemeinen n-ären Beziehung im E/RModell und wird hier spezialisiert. Durch sie werden n verschiedene Entitäten von
Klassikationsstufen verbunden. Solche Beziehungen stellen ein Fakt der Dimensionalität n dar und bilden einen Würfel. Eine Beschreibung des Fakts verwenden wir
als Name der Menge. Die unmittelbar verbundenen Klassikationsstufen nennen
wir atomare Klassikationsstufen.
Die Faktbeziehung modelliert die inhärente Trennung zwischen Dimension und
Würfelzellen und somit die Struktur des Würfels. Die Attribute der Faktbeziehung
modellieren die Kenngröÿen der Fakten, wogegen die Klassikationsstufen die qualizierenden Daten darstellen (vgl. [BG01]).
Beispiel 1.2.1 Wir betrachten eine Verkaufsanalyse. Kenngröÿen können z. B.
Verkaufszahlen oder der Umsatz sein. Als Dimension dienen Produkt, Geographie
und Zeit. Innerhalb einer Dimension sind auch Alternativpfade der Klassikationsbeziehungen möglich. Abbildung 1.3 zeigt solche Alternativpfade bei der Zeitdimension. Wochen sind somit nicht mehr eindeutig zu Quartalen oder Jahren
zusammengefasst.
5
1 Erweiterte Entwurfskonzepte
Abbildung 1.3: Kaufhaus-Szenario in ME/R-Notation
1.2.2 Logische Modellierung
Nach der konzeptuellen Modellierung ist eine formale Beschreibung des multidimensionalen Datenmodells für Data-Warehouse-Systeme dringend nötig. Zunächst
müssen die verwendeten Basiskonstrukte und deren Beziehungen formal beschrieben werden. Das Pendant im relationalen Datenmodell ist die formale Denition
einer Relation, eines Relationenschemas, einer Domäne etc. Im Falle des multidimensionalen Paradigmas sind die zu formalisierenden Entitäten Datenwürfel, Dimensionen etc. ([BG01]).
In den folgenden zwei Kapiteln werden zwei verschiedene Verfahren, die das
systemunabhängige konzeptuelle Modell in ein logisch eingesetztes Modell verwandeln, vorgestellt. Die Vorgehendsweise ist etwas anders als im relationalen Modell.
Der Hauptunterschied zwischen dem multidimensionalen und relationalen Modell
ist die zusätzliche Semantik, durch die die Beziehungen zwischen den Klassikationsstufen einer Dimension untereinander, zwischen den Würfeln und den Klassikationsstufen seiner Dimensionen sowie zwischen verschiedenen Würfeln zum
Bestandteil des Modells gemacht werden.
1.2.3 Snowake-Schema
Die Klassikationen im ME/R-Modell können direkt in einer relationalen Datenbank umgesetzt werden. Dies realisiert man durch die Zuordnung einer eigenen
Tabelle für jede Klassikationsstufe. Diese Tabelle enthält neben der ID für die
Klassikationsknoten dieser Klassikationsstufe auch die beschreibenden Attribute und Fremdschlüssel der direkt benachbarten höheren Klassikationsstufen.
Abbildung 1.4 verdeutlicht das Snowake-Schema. Die Kenngröÿen eines Datenwürfels werden innerhalb einer Faktentabelle verwaltet. Diese wird nach obigem
Schema konstruiert, d.h., neben einer Spalte für jede Kenngröÿe enthält sie Fremd-
6
1.2 Entwurfsgrundlagen für DWS
schlüsselbeziehungen zu den jeweils niedrigsten Klassikationsstufen der verschiedenen Dimensionen, gemäÿ der Granularität des Datenwürfels. Die Fremdschlüssel entsprechen den Zellkoordinaten in der multidimensionalen Datensicht. Sie bilden daher den zusammengesetzten Primärschlüssel für die Faktentabelle (siehe
[Lin03]).
Abbildung 1.4: Snowake-Schema
Die hierarchischen Klassikationsstufen lassen sich am besten mit einem Beispiel
verdeutlichen. Abbildung 1.5 zeigt eine Umsetzung in einem Speditionsunternehmen nach diesem Muster.
Die Namensgeber vergleichen diese Variante mit dem Kristall einer Schneeocke.
Damit werden n:m-Beziehungen zwischen Hierarchieobjekten besser unterstürtzt,
Aggregate optimal benutzt. Redundanz verschwindet auch. Auf der Schattenseite
entsteht hier ein komplexeres Modell, welches für den Benutzer das Verständnis
erschwert und bei der Anfrage kompliziert erscheint. Wie in Abbildung 1.4 gezeigt,
sind bei Snowake-Schema alle Tabellen in Normalform. Bei einer Anfrage werden
viele Join-Operationen ausgeführt, um viele Tabellen miteinander zu verbinden.
Weil solche Verbindungen besonders zeitaufwändig sind, wird stattdessen in DataWarehouse-Systemen häug das Star-Schema benutzt.
1.2.4 Star-Schema
Im Star-Schema werden alle Dimensionsstufen, die zu einer Dimension gehören
zu einer Dimensionstabelle zusammengefügt. Dies führt zur Denormalisierung der
Dimensionstabelle, um eine schnellere Anfragebearbeitung zu erreichen. Eine Fak-
7
1 Erweiterte Entwurfskonzepte
Abbildung 1.5: Snowake-Schema-Beispiel
tentabelle wird mit N Dimensionen assoziiert. Im Modell ergibt sich dann ein Stern:
die Faktentabelle steht im Mittelpunkt des Sternes, die dazugehörigen Dimensionen
bilden die Strahlen des Sternes, daher kommt der Name Star-Schema. Innerhalb
eines Star-Schemas gibt es für jede Dimension genau eine Dimensionstabelle.
Abbildung 1.6 zeigt den prinzipiellen Aufbau eines Star-Schemas und Abbildung 1.7 repräsentiert das bereits ernannte Beispiel Spedition im Star-Schema.
In Abbildung 1.7 sind die Klassikationsschemata der Zeit-, Produkt- und Geographiedimension dargestellt. Fahrzeug, Spedition, Landkreis, Regierungsbezirk,
Bundesland und Staat werden im Star-Schema zu einer einzigen Dimensionstabelle Fahrzeug zusammengefsst. Die Fremdschlüssel der Faktentabelle sind mit der
niedrigsten Granularität bezeichnet (z. B. FahrzeugID).
In einem Star-Schema ist die Faktentabelle wie im Snowake-Schema normalisiert, demgegenüber sind die Dimensionstabellen nicht normalisiert. Demzufolge
gibt es viele Redundanzen innerhalb der Dimensionstabellen. Die funktionalen Abhängigkeiten zwischen den Klassikationsstufen werden bei dieser Abbildung nicht
sichtbar.
Die Argumentation, wann und warum ein Star-Schema trotzdem dem SnowakeSchema vorzuziehen ist, stützt sich auf folgende Heuristiken über die Charakteristika von Data-Warehouse-Systemen (siehe [Lin03]):
• Schnellere Anfragebeantwortung.
Anfragen werden auf höherer Granularitätsstufe (zum Beispiel Produktkategorie) eingeschränkt. Die aufwändigen Verbindungsopreationen zwischen verschiedenen Tabellen einer Dimension beim Snowake-Schema werden durch
die Denormalisierung gespart.
• Erträglicher Speicheraufwand für Dimensionstabellen.
8
1.2 Entwurfsgrundlagen für DWS
Abbildung 1.6: Star-Schema
Abbildung 1.7: Star-Schema-Beispiel
9
1 Erweiterte Entwurfskonzepte
Das Datenvolumen der Dimensionstabellen mit den Klassikationshierarchien ist relativ gering im Vergleich zum gesamten Volumen der Zellinhalte
(Gröÿe der Faktentabelle). Das Datenvolumen wird somit durch die Denormalisierung insgesamt nicht dramastisch erhöht.
• Wenige Änderungen im Dimensionstabellen.
Die Dimensionenstabellen werden seltener verändert als das Hinzufügen von
neuen Faktendaten. Zusammenfassend besitzt das Star-Schema also folgende
Eigenschaften, die es für Anwendungen geeignet erscheinen lassen:
Einfache Struktur:
Anfragen werden dadurch einfacher und lassen sich leichter formulieren.
Einfache und exible Darstellung von Klassikationshierarchien:
Klassikationshierarchien werden einfach innerhalb von Dimensionstabellen als Spalten angegeben.
Eziente Anfrageverarbeitung innerhalb der Dimensionen:
Die Selektionsprädikate, die höhere Dimensionsstufen zur Einschränkung verwenden, benötigen keine Verbindungsoperationen, um die Menge von Tupeln zu bestimmen, die mit der Faktentabellen verbunden
werden müssen.
Ob die Vorteile des Snowake-Schemas wie z. B. geringerer Speicherplatzbedarf
und bessere Änderungsfreundlichkeit überwiegend oder das Star-Schema besser
geeignet ist, hängt stark von den konkreten Daten- und Anfragecharakteristiken.
1.3 Erweiterte Entwurfskonzepte
Wir werden hier die für das Data Warehousing bedeutendsten erweiterten Entwurfskonzepte: konformierte Dimensionstabelle und erweiterte Dimensionstabelle
verdeutlichen.
1.3.1 konformierte Dimensionstabelle
Der Leser wird sich hier vielleicht die Frage stellen: Was ist denn eine konformierte Dimensionstabelle? Dies stammt aus einem englischen Begri (vgl. Denition 1.3.1).
Denition 1.3.1 A conformed dimension is a dimension that means the same
thing with every possible fact table to which it can be joined.[KRRT98]
Das heiÿt im Allgemeinen, dass eine konformierte Dimension mit allen benötigten Faktentabellen identisch verwendet werden kann. Das erklären wir in einem
einfachen Beispiel.
10
1.3 Erweiterte Entwurfskonzepte
Wir nehmen wieder das obige Szenario aus Abschnitt 1.2.3 in einem Speditionsunternehmen. In der Faktentabelle in Abbildung 1.8 sind die Daten enthalten,
welches Fahrzeug an welchem Tag welche Produkte transportiert hat.
Abbildung 1.8: Speditionsszenario 1
Für die Abteilung, die die Aufträge an die Mitarbeiter verteilt, fügen wir zusätzlich eine Faktentabelle hinzu (siehe Abbildung 1.9). Darin werden die Daten
gespeichert, wer welchen Auftrag mit welchem Fahrzeug ausführt.
Abbildung 1.9: Speditionsszenario 2
Dieselbe Dimension Fahrzeug hat in beiden Fällen unterschiedliche Einträge,
was aufgrund verschiedener Einsatzmöglichkeiten in verschiedenen Abteilungen gerecht ist. Soll es dann zwei Dimensionen Fahrzeug in demselben Unternehmen
geben?
11
1 Erweiterte Entwurfskonzepte
Wir wissen doch, dass die beiden Dimensionen im Unternehmen eigentlich dasselbe meinen. Somit passen wir die Dimension Fahrzeug so an, dass sie in beiden
Fällen eingesetzt werden kann. Abbildung 1.10 stellt die angepasste Dimension
Fahrzeug dar. Alle Attribute werden in einer konformierten Dimension gespeichert.
Abbildung 1.10: Speditionsszenario: konformierte Dimensionstabelle
Diese Vorgehensweise bietet reichlich Vorteile:
• Es ist nur eine einzige Dimension zu pegen und
• sie ist mit jeder Faktentabelle (bei gleicher Granularität) verwendbar.
1.3.2 Erweiterte Dimensionstabelle
In diesem Kapitel beschreiben wir zwei normale Modellierungssituationen, wo eine
spezische Dimensionsstruktur sehr ezient ist.
Many-to-many-Dimension
In vielen klassischen Modellierungssituationen sind die Existenz und die Granularität einer Faktentabelle verständlich und fundamental. Die Zuordnung der Dimensionstabellen zu Faktentabellen sind auch trivial. Aber eine Dimension kann auch
mehrere Werte haben und die Anzahl der möglichen Werte für diese Dimension ist
eventuell unbekannt, wenn die Faktentabelle erstellt wird. Solch eine Dimension
nennen wir Many-to-many-Dimension.
Patientendaten in einer Praxis liefern ein gutes Beispiel (siehe Abbildung 1.11).
Alle Patientendaten inkl. die zugehörigen Personaldaten, Diagnosen und Zeitangaben werden in einer Patient-Faktentabelle abgespeichert. Das Problem ist, was mit
der Diagnosentabelle passiert. Oft hat ein Patient mehrere Diagnosen.
Eine mögliche Lösung zeigt uns die Abbildung 1.12: für jede Diagnose eine eigene
Dimension.
Diese Lösung ist nicht realistisch. Der Grund ist:
12
1.3 Erweiterte Entwurfskonzepte
Abbildung 1.11: Many-to-many-Dimension 1
Abbildung 1.12: Many-to-many-Dimension 2
13
1 Erweiterte Entwurfskonzepte
1. Wir kennen die obere Schranke der Diagnosenanzahl nicht.
2. So ein Schema würde beim Abfragen (zum Beispiel: join) sehr langsam sein.
Eine bessere Lösung ist, zwischen der Faktentabelle und der Diagnose-Dimension
eine Brückentabelle hinzufügen (siehe Abbildung 1.13). In der Brückentabelle generieren wir die originale DiagnoseID in der Faktentabelle zu einer spezialen DiagnoseGruppeID. Die Diagnosengruppe-Tabelle, also unsere Brückentabelle, enthält eine
spezische Menge von Einträgen für jeden Patienten. Jeder Eintrag enthält wieder
die DiagnoseGruppeID, eine individuelle DiagnoseID und einen Gewichtungsfaktor.
In einer gegebenen Diagnosengruppe muss die Summe aller Gewichtungsfaktoren
1,00 sein.
Abbildung 1.13: Many-to-many-Dimension 3
Die Lösung mit einer zusätzlichen Brücktabelle ist nicht perfekt. Mit einem
Beispiel verdeutlichen wir die Schwierigkeiten bei Brückentabellen.
Beispiel 1.3.2 Annahme:
• eine Diagnosentabelle hat 1k Einträge und jeder Eintrag hat 10kByte. Speicheraufwand: 10MB
• eine Faktentabelle hat 100k Einträge und jeder Eintrag hat 1kByte. Speicheraufwand: 100MB
• in einer Brückentabelle hat jeder Eintrag 50Byte. Dann muss man bei einer zusätzlichen Brückentabelle mit folgendem zusätzlichen Speicheraufwand
(siehe Tabelle 1.1) rechnen:
Speicheraufwand = alle Fakten × Diag/Pat. × Gröÿe eines Eintrags
14
1.3 Erweiterte Entwurfskonzepte
Speicheraufwand
50MB
100MB
500MB
Diag./Pat.
10
20
100
Tabelle 1.1: Speicheraufwand der Brückentabelle
Wie gezeigt verursacht die Erhöhung der Diagnosenanzahl einen entsprechend
höheren Speicheraufwand. Deshalb ist die Lösung mit einer Brückentabelle bei
extrem gestiegener Diagnosenanzahl (was zwar selten auftritt, aber nicht ausgeschlossen werden kann) auch nicht mehr akzeptabel.
Role-Playing-Dimension
Eine role in einem Data Warehouse ist eine Situation, wo eine einzelne Dimension
mehrmals in derselben Faktentabelle auftritt. Abbildung 1.14 liefert wieder ein
Beispiel aus einer Klinik.
Abbildung 1.14: Role-playing-Dimension 1
In der Faktentabelle kann das Datum mehrfach auftauchen. Zum Beispiel hat
ein Patient ein Operationsdatum und ein Rechnungsdatum.
Anfrage:
select *
from Patient
where OpZeitID=05.04.2005 and RechZeitID=28.04.2005
Da wir nur eine Zeitdimension haben, versucht SQL in so einem Join alle Daten
gleichzustellen. Das ist aber nicht gewünscht.
Eine mögliche Lösung (siehe Abbildung 1.15) wäre, verschiedene Dimensionen
zu verwenden, da sie ja auch verschiedene Rollen spielen. Diese intuitive Lösung
hat folgende Nachteile:
15
1 Erweiterte Entwurfskonzepte
• Alle Zeitdimensionen werden zwar unterschiedlich benannt. Sie müssen aber
konsistent gehalten werden, weil sie immerhin die gleiche Domäne haben
müssen.
• In einer komplizierten Umgebung (zum Beispiel Telekommunikationsindustrie) müssen mehrere verschiedene partiell überlappende Tabellen gehalten
werden. Hier verursacht obige Lösung extrem hohen Wartungsaufwand.
Abbildung 1.15: Role-playing-Dimension 2
Durch Einsatz von Sichten auf dieselbe Dimension kann eine bessere Lösung
geliefert werden. Es ist zu beachten, dass jede Sicht auf eine Dimension eindeutige
Spaltennamen benötigt. Abbildung 1.16 verdeutlicht die Vorgehensweise.
Abbildung 1.16: Role-playing-Dimension 3
1.4 Zusammenfassung
In dieser Arbeit haben wir gemeinsam die benötigten Grundlagen beim DataWarehouse-Entwurf und anschlieÿend die passenden Techniken in vielen allgemeingültigen Fällen kennengelernt. Hier muss man betonen, dass das Star-Schema aufgrund seiner schnellen Anfragebeantwortung und einfachen Struktur zwar überwiegend verwendet wird, um eine relativ optimale Struktur zu bekommen, aber
16
1.4 Zusammenfassung
in der Praxis fast immer zusätzliche Techniken, sogenannte erweiterte Konzepte,
notwendig sind.
Konformierte Dimensionen sind eine der grundlegenden Techniken. In manchen
Fällen kann man auch analog konformierte Fakten verwenden. Bei Many-to-manyDimension oder Role-playing-Dimension benutzen wir erweiterte Dimensionstabellen. In anderen Fällen zum Beispiel Time-of-Day und Value-Band-Reporting ist der
Einsatz der sogenannten erweiterten Faktentabelle von Vorteil (siehe [KRRT98]).
17
1 Erweiterte Entwurfskonzepte
18
Ingo Beutler
2
Datenqualität
Diese Seminararbeit gibt eine Einführung in die Grundlagen der Datenqualität.
Sie ist in vier Abschnitte eingeteilt. Nach einer kurzen Einleitung wird im zweiten Kapitel auf den Begri Daten eingegangen. Das dritte beschäftigt sich mit
Datenqualität und deren Auswirkungen. Im vierten Kapitel werden zwei Ansätze
vorgestellt, wie Datenqualität erreicht und erhalten werden kann. Die Thematik
wird auf den Verkehrsbereich übertragen und anhand von Beispielen erläutert.
2.1 Einleitung
Bei der Beschreibung der heutigen Zeit besteht allgemeiner Konsens, dass sich
der Begri Informationszeitalter für diese am Besten eignet. In der heutigen Zeit
sind Daten das wichtigste Gut. Beispiele aus dem Verkehrsbereich, welche diese
Aussage unterstreichen, sind die Verkehrsplanung und die Verkehrssteuerung. Ohne
Verkehrsdaten wären diese nicht sinnvoll möglich.
2.2 Daten
2.2.1 Daten - Informationen - Wissen
Zu Beginn werden der Zusammenhang der Begrie Daten, Informationen und Wissen dargestellt. Unter Daten versteht man im allgemeinen Funktionen oder Zeichen.
Informationen sind interpretierte Daten, das heiÿt es kommt Semantik zu den Daten hinzu. Um von Informationen zu Wissen zu kommen, müssen die Informationen
zueinander in Bezug, bzw. in einen Kontext gesetzt werden [Koo04c].
Abbildung 2.1 zeigt den Zusammenhang anhand eines Beispiels. Die Daten sind
50 und MS11. Werden diese Daten interpretiert, so könnten sie zu den Infor-
19
2 Datenqualität
Wissen
Ein Fahrzeug ist mit 50 km/h über Messstelle MS11 gefahren
Kontext
Geschwindigkeit (km/h)
Messstelle
50
MS11
Information
Semantik
Daten
50
MS11
Abbildung 2.1: Daten - Informationen - Wissen
mationen Geschindigkeit 50 km/h und "Messstelle mit Namen MS11 werden.
Setzt man diese Informationen zueinander in Beziehung könnte man das Wissen
erhalten, dass ein Fahrzeug mit 50 km/h über die Messstelle MS11 gefahren ist.
Der Grund, warum die Zusammenhänge dieser Begrie veranschaulicht wurden,
ist folgender: Datenqualität bezieht sich nicht nur, wie man aufgrund des Namens
vermuten könnte, auf Daten. Da sie sich stark am Benutzer orientiert, bezieht sie
sich natürlich auch auf die für den Benutzer interessanten, sich aus den Daten
ergebenden Informationen und auf das daraus resultierende Wissen.
2.2.2 Daten im Verkehrsbereich
Im Verkehrsbereich werden hauptsächlich vier Arten von Daten unterschieden
[Här05]:
1. Verkehrsdaten
Verkehrsdaten werden mit Hilfe von Sensoren gesammelt. Hierunter fallen
beispielsweise Daten über die aktuelle Verkehrssituation.
2. Daten über Verkehrsinfrastruktur
Hier sind Daten gemeint, welche Verkehrsnetze, Parkräume oder auch den
20
2.3 Datenqualität
öentlichen Personennahverkehr beschreiben und deren Strukturen wiedergeben.
3. Daten über Ereignisse und Störungen
Diese Daten sollen Einüsse auf den Verkehrsuss und die Verkehrsinfrastruktur wiedergeben.
4. Verkehrsprognosedaten
Daten, die auf vorhandenen Verkehrsdaten basieren und Vorhersagen zum
Beispiel über zukünftige Verkehrsdaten machen, werden als Verkehrsprognosedaten bezeichnet.
2.3 Datenqualität
Je mehr Informationsverarbeitende Systeme es gibt und je mehr Daten gesammelt
werden, desto wichtiger wird die Qualität der Daten. Pisarski bringt die Problematik auf den Punkt [oPFHA02]:
..we are more and more capable of rapidly transferring and eectively
manipulating less and less accurate information...
Wir können immer besser immer schlechtere Daten verarbeiten, das trit den
Kern der Idee. Um diesen Missstand beheben zu können, muss zwischen guten
und schlechten, bzw. zwischen qualitativ hochwertigen und qualitativ niederwertigen Daten unterscheiden werden. Hier kommt der Begri der Datenqualität
ins Spiel.
2.3.1 Denition
Shawn Tuner denierte im Jahre 2002 den Begri Datenqualität [oPFHA02]:
Data quality is the tness of data for all purposes that require it. Measuring data quality requires an understanding of all intended purposes
for that data.
In dieser Denition orientiert sich die Datenqualität an den Anforderungen der
Benutzer und an der Situation, in der die Daten benutzt werden. Um Datenqualität messen zu können, müssen erst alle möglichen Einsatzmöglichkeiten von Daten
verstanden werden. Leider ist die Denition der Datenqualität sehr allgemein und
schlecht messbar, weshalb diese in verschiedene Bereiche, sogenannte Qualitätskriterien, untergliedert werden muss.
21
2 Datenqualität
2.3.2 Qualitätskriterien
Im folgenden werden zwei Mengen von Datenqualitätskriterien vorgestellt. Die
ersten Kriterien sind sehr allgemein gehalten und beschreiben jede Art von Daten.
Die zweiten Kriterien wurden als besonders relevant für Daten im Verkehrsbereich
befunden.
allgemeine Datenqualitätskriterien
Die meisten Ansätze sehen Datenqualität als multidimensionales Konzept. Im Folgenden werden eine Vielzahl von Kriterien betrachtet, welche Einuss auf die Qualität von Daten haben. Diese Qualitätskriterien sollen aus der Sicht der Benutzer
eine Gliederung der Anforderungen an die Daten wiedergeben [WW96].
Kategorie
Kriterium
intrinsische DQ
Genauigkeit, Objektivität,
Glaubwürdigkeit, Ruf
Erreichbarkeits-DQ Zugriff, Sicherheit
kontextabhängige
DQ
begriffliche DQ
Relevanz, Aktualität, Vollständigkeit,
Mehrwert
Interpretierbarkeit, Verständlichkeit,
präzise Darstellung,
Widerspruchsfreie Darstellung
Abbildung 2.2: Qualitätskriterien
Diese wurden in die folgenden vier Kategorien eingeteilt, wie in Abbildung 2.2
dargestellt. Die erste Kategorie intrinsische Datenqualität beinhaltet Kriterien,
die sich mit der Qualität der Daten an sich beschäftigen. Hier geht es um die Genauigkeit, mit der Daten einen bestimmten Sachverhalt beschreiben. Es werden
auch Objektivität und Glaubwürdigkeit der Daten betrachtet. Möglicherweise besitzen die Daten so etwas wie einen Ruf.
In der zweiten Kategorie Erreichbarkeitdatenqualität sind Kriterien, welche die
Erreichbarkeit der Daten beschreiben. Einerseits wird der Zugri auf die Daten
22
2.3 Datenqualität
betrachtet. Andererseits geht es auch um die Sicherheit der Daten.
Kontextabhängige Datenqualität beschreibt die Qualität der Daten in Bezug auf
den Kontext. Hier geht es um Fragen wie: Wie relevant sind die Daten für die
Situation? Sind die Daten aktuell genug? Sind alle notwendigen Daten vorhanden(Vollständigkeit)? Bringen die Daten einen Mehrwert?
Die vierte Kategorie begriiche Datenqualität bezieht sich auf den Benutzer.
Kann der Benutzer die Daten einfach interpretieren? Sind sie für ihn verständlich?
Ist die Darstellung präzise genug? Oder sind die dargestellten Sachverhalte gar
widersprüchlich?
Datenqualitätskriterien im Verkehrsbereich
Im Verkehrsbereich, genauer für erweiterte Reisendeninformationssysteme, werden
folgende Qualitätskriterien empfohlen [oPFHA02]:
1. Genauigkeit
Genauigkeit wird auch in anderen Bereichen als ein sehr wichtiges Kriterium angesehen. Hier geht es darum, wie genau die Daten den Sachverhalt
wiedergeben.
2. Vertrauen
Ob die Daten vertrauenswürdig sind, soll bei diesem Kriterium überprüft
werden.
3. Verfügbarkeit (Verzögerung)
Die Verfügbarkeit kann beispielsweise durch eine Verarbeitung der Daten
verzögert werden. So bekommt der Benutzer unter Umständen nicht immer
die aktuellsten Daten sofort angezeigt.
4. Verfügbarkeit (Vollständigkeit)
Die Verfügbarkeit kann eingeschränkt werden, wenn eine Messstation ausfällt.
Dann sind die Daten nicht vollständig.
5. Abdeckung (Breite)
Das Kriterium Abdeckung besitzt hauptsächlich zwei Dimensionen. Die erste
bezieht sich zum Beispiel auf die Gröÿe der Fläche, die in den Daten betrachtet wird. Beispiel: Von welchen Straÿen werden Daten gesammelt?
6. Abdeckung (Tiefe)
Die zweite Dimension der Abdeckung betrachtet die Genauigkeit. In welchem
Detail stehen Daten zur Verfügung? Wie weit sind die Messstationen voneinander entfernt?
23
2 Datenqualität
2.3.3 Einuss schlechter Datenqualität
Schlechte Datenqualität kann sich auf verschiedensten Ebenen auswirken. Betrachtet man die zeitliche Dimension lassen sich Auswirkungen auf den drei bekannten
Ebenen (operational, taktisch und strategisch) feststellen [Red98].
• operational
Im Verkehrsbereich, z.B. bei der Verkehrsanalyse, können Daten mit schlechter Datenqualität leicht dazu führen, dass bestehende Staus nicht erkannt
werden.
• taktisch
Soll eine Reiseplanung aufgrund von Daten mit schlechter Datenqualität gemacht werden, dann wird die Qualität des resultierenden Planes darunter
leiden.
• strategisch
Auf der strategischen Ebene könnte die Planung einer Autobahn als Beispiel
herangezogen werden. Basiert die Planung auf Daten mit schlechter Datenqualität, dann könnte es passieren, dass die Autobahn an der falschen Stelle
gebaut wird.
2.4 Datenqualitätsmanagement
Damit die Qualität von Daten gut ist und auch bleibt, ist eine Überwachung und
Steuerung dieser Qualität notwendig. Das heiÿt, es muss ein Management der Datenqualität durchgeführt werden. Hierzu werden im Folgenden zwei Ansätze vorgestellt.
2.4.1 Systemorientierter Ansatz
Das Ziel dieses Ansatzes ist es, dass die Daten mit der widergespiegelten Realität
übereinstimmen. Dies soll über ständige Anpassungen des Informationsystems erfolgen, damit dieses bestmöglich in die Realität und deren Abläufe und Prozesse
passt [Orr98].
Abbildung 2.3 zeigt eine schematische Darstellung eines Informationssystems.
Daten werden an einer Stelle eingegeben (Input). Danach werden sie irgendwie
verarbeitet und gespeichert. Auf der anderen Seite werden die verarbeiteten Daten ausgegeben (Output). Desweiteren ist ein Feedback vom Output zum Input
notwendig, um die Datenqualität überprüfen zu können.
Im Rahmen des Ansatzes haben sich sechs Regeln über Daten und Datenqualität
ergeben:
1. Unbenutzte Daten bleiben nicht sehr lange korrekt.
24
2.4 Datenqualitätsmanagement
Abbildung 2.3: Systemorientierter Ansatz - Informationssystem
2. Datenqualität hängt in einem Informationssystem von der Häugkeit der
Benutzung ab, nicht von der Datenmenge.
3. Datenqualität ist optimal, wenn die Daten fortlaufend genutzt werden.
4. Je älter das System, desto schlechter die Datenqualität.
5. Je geringer die Änderungswahrscheinlichkeit eines Attributs, desto schlimmer
ist es, wenn es sich ändert.
6. Diese Regeln gelten für Daten und Metadaten.
Die Idee hinter den Regeln 1 bis 3 ist, dass unbenutzte Daten wahrscheinlicher
überprüft und aktualisiert werden als unbenutzte Daten. Diese Idee spiegelt sich
auch im nächsten Abschnitt Gebrauchsabhänigige Datenqualität wieder.
Gebrauchsabhänigige Datenqualität (use based data quality)
Es wurden Empfehlungen zur Erzielung hoher Datenqualität aufgestellt und unter
dem Namen Gebrauchsabhänigige Datenqualität zusammengefasst. Diese Empfehlungen umfassen vier Bereiche [Orr98]:
• Audits
Es sollen Befragungen der Benutzer zur Bestimmung der Qualität der aktuellen Daten durchgeführt werden.
• Redesign
Werden Probleme mit der Datenqualität entdeckt, sollte ein Redesign des
Systems durchgeführt werden. Hierbei müssen die kritischen Gebiete identiziert und das System an die Benutzung angepasst werden. Möglicherweise
ist auch eine Reduktion des Datenbestandes notwendig.
25
2 Datenqualität
Eingabe
Ablauf
Ausgabe
Produktherstellung Informationsherstellung
Rohstoe
Flieÿband
Physisches Produkt
Rohdaten
Informationssystem
Informationsprodukt
Tabelle 2.1: Produktorientierter Ansatz - Vergleich Herstellungsprozess
• Training
Benutzer und Manager sollen für mögliche Probleme mit Datenqualität sensibilisiert werden. Sie sollten wissen, dass es soetwas wie Datenqualität gibt
und dass diese sich nicht von alleine verbessert, beziehungsweise auf einem
erreichten Niveau bleibt.
• Continuous Measurement
Das Informationsystem an sich sollte Mechanismen zur Verfügung stellen, die
die Datenqualität ständig überprüfen und somit sichern.
2.4.2 Produktorientierter Ansatz
Der Produktorientierte Ansatz sieht ein Informationssystem als Informationsprodukte herstellendes System. Er versucht Methoden zur Qualitätskontrolle und zur
Qualitätssicherung aus dem Produktherstellungsprozess auf den Informationsherstellungsprozess zu übertragen. Tabelle 2.1 zeigt einen Vergleich zwischen traditioneller Produktherstellung und Informationsproduktherstellung [Wan98] [WZL01].
Das Ziel diese Ansatzes ist es, qualitativ hochwertige Informationsprodukte herzustellen.
Hierfür wurde ein Qualitätszyklus entwickelt, wie er in Abbildung 2.4 dargestellt
ist. Ein Zyklus besteht aus vier Phasen:
1. Denitionsphase
In der Denitionsphase wird die Situation analysiert und deniert. Hier treten Fragen auf wie: Wer ist der Benutzer? Was will der Benutzer? Was sind
die Daten? Wie funktioniert das System?
2. Messphase
In der Messphase müssen die Anforderungen aus der Denitionsphase in
Messkriterien und Messfunktionen, welche die Kriterien überprüfen, umgesetzt werden. Anschliesend werden Messungen durchgeführt.
3. Analysephase
In der Analysephase werden die Messergebnisse analysiert. Wenn mangelhafte Qualität entdeckt wird, muss der Grund dafür gefunden werden.
4. Verbesserungsphase
In der Verbesserungphase soll nun das Problem behoben werden.
26
2.4 Datenqualitätsmanagement
Definieren
Messen
Benutzer
Messkriterien
Daten
Messfunktionen
System
InformationsProdukt
Verbessern
Analysieren
Problem beheben
Wo liegt das Problem?
Abbildung 2.4: Produktorientierter Ansatz - Qualitätszyklus
Beispiel
Der Qualitätszyklus soll an einem vereinfachten Beispiel aus dem Verkehrsbereich
verdeutlicht werden.
• Denitionsphase
Ausgangspunkt ist der Benutzer der von dem Informationsystem den Dienst
Stau melden zur Verfügung gestellt haben möchte. Das Informationsystem
bekommt als Eingabe Geschwindigkeitsmesswerte. Werden zehn Messwerte,
die kleiner als 10 km/h sind, eingelesen, meldet das System einen Stau an
der entsprechenden Stelle.
• Messphase
Das Kriterium, welches in der Messphase überprüft werden soll, ist die Korrektheit. Dafür werden als Messinstrument mobile Staumelder (Autofahrer)
angeheuert, welche an die Orte fahren, an denen das System einen Stau meldet, und somit die Ausgabe des Informationssystems überprüfen.
• Analysephase
Die Ergebnisse der Messphase werden analysiert und es wird entdeckt, dass
27
2 Datenqualität
Systemorientierter Ansatz
Empfehlungen
Anpassung des Systems an Realität
Produktorientierter Ansatz
Vorgehensweise
Sicherstellung qualitativ hochwertiger IP
Tabelle 2.2: Vergleich Ansätze
das System Staus meldet, wenn keine vorhanden sind. Der Grund, der vermutet wird, sei in diesem Beispiel die zu ungenaue Messfunktion.
• Verbesserungsphase
Es wird eine verbesserte Messfunktion im System implementiert. Jetzt sollte
der Zyklus von neuem durchlaufen werden.
2.4.3 Vergeich
Abschlieÿend werden beide Ansätze in Tabelle 2.2 verglichen. Während der Systemorientierte Ansatz allgemeine Aussagen über Daten und Datenqualität macht,
gibt der Produktorientierte Ansatz eine Vorgehensweise vor, wie Datenqualität
überwacht und verbessert werden kann. Das Ziel des Systemorientierten Ansatzes
war es, durch eine Anpassung des Systems an die Realität die Übereinstimmung
von Daten und abgebildetem Sachverhalt zu gewährleisten. Der Produktorientierte Ansatz möchte qualitativ hochwertige Informationsprodukte (IP) mit Hilfe von
Methoden aus der Qualitätssicherung der Produktherstellung liefern. Im Kern weisen beide Ansätze in die gleiche Richtung. Sie wollen ein hohe Datenqualität durch
ständige Anpassungen des Systems erreichen.
2.5 Fazit
Das Gebiet der Datenqualität ist sehr weitreichend und durchdringt sämtliche
Gebiete der Informatik. Dazu ist mangelhafte Datenqualität in fast allen in der
Praxis auftretenden Problemen mit Informationssystemen zu nden. Vereinfacht
gesagt resultiert sie aus dem Einsatzszenario, der Art des Informationssystems und
dessen Benutzung und kann unterschiedlichste Ursprünge haben. Wie alltägliche
Pannen, die aufgrund von mangelhafter Datenqualität zustande kommen, zeigen,
wird dem Problem der Datenqualität noch immer zu wenig Beachtung geschenkt.
Es gibt viele gute Ideen in diesem Bereich, welche Entwicklern und Benutzern von
Informationssystemen das Leben einfacher machen, wenn sie umgesetzt werden.
28
Guy Hermann Ngassa Happi
3
Datenqualität - Der GQM-Ansatz und
das DWQ-Projekt
DWQ ist ein kooperatives Projekt [NRI+ 99], das von der europäischen Gemeinschaft unterstützt wird. Seine Hauptaufgabe ist es die Basis von Data-WarehouseQualität festzulegen, indem ein Zusammenhang zwischen semantischem Modell
einer Data-Warehouse-Architektur mit explizitem Modell einer Datenqualität erstellt wird. Die meisten Datenbankforscher betrachten Data-Warehouses (DW) als
einen Puer der materialisierten Views, die zwischen intensiven Aktualisierungssystemen (OLTP) und intensiven Entscheidungsunterstützungssystemen (OLAP)
vermitteln
Dies vernachlässigt die organisatorische Rolle der Data-Warehouses als eine zentralisierte Informationsusssteuerung. Als Folge können viele Qualitätsaspekte, die
für ein Data-Warehouse relevant sind und nicht mehr mit den gegenwärtigen DWMetamodellen ausgedrückt werden.
Diese Seminararbeit stellt zwei Beiträge vor um diese Probleme zu lösen. Im ersten Beitrag werden die Metadaten über die DW-Architektur durch die detaillierte
Unternehmensmodelle angereichert. Im zweiten Beitrag werden viele sehr unterschiedliche mathematische Techniken für das Messen oder die Optimierung bestimmter Aspekte der DW-Qualität entwickelt. Die Anpassung des GQM (GOALQUESTION-METRIC)-Ansatzes der Software-Qualitätsverwaltung an einer Metadatenverwaltungsumgebung wird dargestellt um diese spezielle Techniken mit
einem generischen konzeptuellen Framework der DW-Qualität zu verbinden.
Der Ansatz ist vollständig auf das ConceptBased-Repository-System [PJ04] implementiert worden und hat einige Untersuchungen-Tests bestätigt, indem man ihn
zur Unterstützung der spezischen qualitätsorientierten Methoden, der Werkzeuge
und der Anwendungsprojekte für ein Data-Warehouse anwendet.
29
3 Datenqualität - Der GQM-Ansatz und das DWQ-Projekt
Eine Übersicht des ProjektZiele wird im Folgenden dargestellt so wie auch eine
Rahmenarchitektur.
3.1 Einleitung
Ein Data-Warehouse ist eine Kollektion von Technologien, die Fachmitarbeitern
erleichtert schneller und besser Entscheidungen zu treen. Es wird die richtige
Information am richtigen Ort zu den richtigen Kosten erwartet. Die Praxis bewies,
dass traditionelle On-Line-Transaktionsverarbeitungs-Systeme (OLTP) nicht für
die Entscheidungshilfe geeignet sind und Hochgeschwindigkeitsnetze nicht durch
sich selbst das Informationszugänglichkeitsproblem beheben können.
Die Data-Warehouse sind heute eine wichtige Strategie geworden um heterogene Informationsquellen in einer Organisationen zu integrieren und um die OLAPProzess (On-Line Analytical Prozess) zu ermöglichen.
Die DW-Bewegung ist das Resultat der Beobachtung von W. Inmon und E.F
Codd am Anfang der 1990er Jahre [Inm93], dass OLAP und OLTP aus zwei Hauptgründen in derselben Datenbankumgebung nicht ezient koexistieren können.
• Dateneigenschaften: OLTP-Datenbanken erhalten gegenwärtige Daten zu ihrem unmittelbaren betrieblichen Gebrauch aufrecht, wohingegen sich OLAP
mit einfacher und häug allgemein angegpasster historischer Daten befasst
und somit viel mehr als gerade die gegenwärtigen Daten abdeckt.Das Mischen
beider Ansatze und stellt die beiden Ursachen komplexen Kompromisse zwischen verschiedenen Graden zusammenund variert die Bedürfnisse für die
Geschichtsinformation.
• Transaktionseigenschaften: OLTP hebt Leistungsfähigkeit der kurzen Aktualisierungstransaktionen hervor, wobei jede einen kleinen Teil der Datenbank
abdeckt, wohingegen OLAP lange Anfragen gut unterstützt, die im allgemeiner einen grossen Teil der Datenbank abdeckt.
Ein DW nimmt in den Cachespeicher ausgewählte Daten von Interesse zu einer
Kundengruppe auf, so dass der Zugang schneller, preiswerter und eektiver wird.
Wegen der Langzeitpuer wird zwischen OLTP und OLAP (siehe Abbildung 3.1)
DW mit zwei wesentlichen Probleme konfrontiert: Wie man den ankommenden
Datenuss von vielfachen heterogenen Quellen in Übereinstimmung bringt? Und
wie fertigt man den abgeleiteten Datenspeicher besonders zu spezischen OLAPAnwendungen? Der Kompromiss, der die Entwurfsentscheidungen bezüglich dieser
zwei Probleme führt, ändert sich stetig mit den Geschäftsbedürfnissen.Deshalb sind
die Entwurfsunterstützung und das Änderungsmanagement von gröÿter Wichtigkeit, wenn man ein DW-Projekt nicht ine Sackgasse führen will. Das ist ein anerkanntes Problem in der Industrie, das ohne verbesserte formale Grundlage nicht
lösbar ist.
30
3.2 DWQ-Projekt
Abbildung 3.1: Vom OLTP- zum OLAP-Prozess
Das Ziel des DWQ-Projekts ist es, semantische Fundamente zu entwickeln, die
es dem Entwerfer von Data-Warehouses ermöglichen, seine Wahl mit tieferen Modellen, reicheren Datenstrukturen, und rigorosen Implementierungstechniken zu
QoS-Faktoren verbinden zu können, so dass der Entwurf, der Betrieb, und am
wichtigsten die Entwicklung von Data-Warehouse-Anwendungen sich verbessern
lassen.
Der Rest diese Seminarabeit wird wie folgt organisiert. Nach einem kurzen Überblick über die Projektziele in dem Abschnitt 2 stellt der Abschnitt 3 eine Rahmenarchitektur für das Data-Warehouse dar, die eine detaillierte Unterscheidung
hinsichtlich des Entwurfs zwischen konzeptuellen, logischen, und physikalischen
Begrien macht und folglich einige Problem verdeutlicht, die sich auf eine DataWarehouse-Qualität beziehen.
3.2 DWQ-Projekt
In diesem Abschnitt wird kurz die Struktur des DWQ-Projekts, die grundlegenden
Komponenten der Data-Warehouse-Lösungen und der Bezug zu formalen Qualitätsmodellen wiederholt.
3.2.1 Die Struktur des DWQ
Das Data-Warehouse-Quality-Projekt (DWQ) ist ein dreijähriges kooperatives Forschungsprojekt (1996-1999), das von der Europäischen Gemeinschaft unter dem
Reactive-Long-Term-Forschungsprogramms nanziert wurde. Die beteiligten Partner waren: Universität Athen, RWTH Aachen, DFKI (Deutsches Forschungszentrum für künstliche Intelligenz), INRIA (Nationales Institut für die Forschung in
Kognitiven Systemen).
Die Zahl und die Komplexität von DW-Projekten zeichnen die Schwierigkeit bei
dem Entwurf eines guten Data-Warehouses aus. Ihre erwartete Dauer verstärkt die
Notwendigkeit für die dokumentierten Qualitätsziele und für das Änderungsmanagement. Die Bewertung der Resultate hinsichlicht der Anforderungen aus einer
31
3 Datenqualität - Der GQM-Ansatz und das DWQ-Projekt
Auswahl von realistischen Anwendungen ist ein wichtiges Ziel von DWQ. Das Projekt arbeitet nah mit der Software AG, einem führenden europäischen Anbieter
von DW-Produkten und -Lösungen zusammen.
3.2.2 Schwerpunkte des DWQ-Projekts
Die Forschungszielsetzungen adressieren drei kritische Bereiche in denen Qualitätsfaktoren eine zentrale Bedeutung für Data-Warehouse einnehmen:
• Beschreibung des Metadaten-Repository mit Hilfe formaler Modelle zur Informationsqualität, um anpassungsfähige und quantitative Designoptimierung
des Data-Warehouses zu ermöglichen.
• Formalisierung der Beschreibung der Informationsquellenmodelle, um zusätzlicher Änderungen und Koniktauösungen zu ermöglichen.
• Erweiterung und Optimierung der Data-Warehouse-Schema, damit Entwerfer und Anfrage-Optimierer den grossen Vorteil der zeitlichen, räumlichen,
und gesamten Natur von DW-daten nutzen können.
Während des Projektes wird das vollständige Spektrum der DW-Modellierung,
des DW-Entwurfs und der DW-Entwicklung untersucht:
• das DWQ-Rahmenarchitektur- und System-Architektur
• die DW-Modellierung und die Entwurfsmethode und -sprache
• die Optimierung
Nach der Entwicklung eines initialen Referenzmodells werden die Ergebnisse
in zwei Schritten geliefert, um wirkungsvoller Projektsteuerung und -kohärenz zu
ermöglichen. Eine Gruppe beschäftigt sich mit einem angereicherten formalen Metamodell für die Beschreibung der statischen Architektur eines DW und demonstriert, wie diese angereichten Grundlagen im DW-Ansatz verwendet werden können.
Die entsprechende Methodologie und Tools umfassen die Architektur, welche die
Modellierung der Einrichtungen mit Fähigkeiten ermöglichen, um DW-spezische
Probleme wie die Auösung von vielfachen Quellen und das Management der aggregierten multidimensionalen Daten lösen zu können, sowie auf Semantik basierenden
Methoden für die Abfrageoptimierung und Datenaktualisierung.
Eine weitere Gruppe konzentriert sich auf die Verbesserung und Optimierung
dieser angereicherten Modelle mit Tools, die die Entwicklung und die Optimierung der DW-Anwendungen unter sich ändernden Qualitätszielen unterstützen. Die
entsprechenden Methodologien und Werzeug bestehen aus der Entwicklung von
Operatoren, welche die Bindung zwischen Designentscheidungen und Qualitätsfaktoren dokumentieren, intelligenten Methoden, welche die View-Denitionen mit
multi-dimensionalen aggregierten Daten analysieren und optimieren und dadurch
eine leistungsfähige Qualitätskontrolle durch Anpassung der Messdaten von den
32
3.2 DWQ-Projekt
neuen Quellen ermöglichen und quantitativen Techniken, welche die selektierten
Datenquellen, die Integrationsstrategien und überüssige View-Materialisierung in
Bezug auf gegebene Qualitätskriterien optimieren, insbesonder Leistungskriterien.
3.2.3 Komponenten eines Data-Warehouse
Das DWQ-Projekt wird eine neutrale Referenzarchitektur zur Verfügung stellen,
welche der Entwurf, die Wartung, das Rüsten, die Operationen, und die Entwicklung eines Data-Warehouse abdeckt [JLV02]. Die Abbildung 3.2 stellt die grundlegenden Komponenten und ihre Beziehungen dar, wie sie in der gegenwärtigen
Praxis existieren. Die benutzten Komponenten sind:
• Quellen: Irgendwelche Datenspeicher, deren Inhalt in einem Data-Warehouse
materialisiert werden soll.
• Das Wrapper für das Laden der Quelldaten in das Daten-Warehouse
• Der Klient: um die Daten anzuzeigen.
• Die Ziels-database: Datamart und kleines Data-Warehouse
• Repository Verwaltung
• Metadaten-Repository: Der Speicher der Information über die anderen Bestandteile, z.B. das Schema des Quelldaten.
Die ausführliche Weiterentwicklung dieser Bestandteile und ihrer Beziehungen
kann gemäÿ dessen zu vielen verschiedenen Benutzeranforderungen und modellierenden Techniken ausgefüllt werden. Die DWQ-Ergebnisse in diesem Bereich
betreen eine allgemeine Rahmenarchitektur, die das Framework modelliert. Die
einfachste Architektur besteht nur aus den Quelldatenbanken, einem zentralen
Data-Warehouse und einiger Klienten. Da die Data-Warehouse-Anwendungen komplizierter werden, lassen sich die Data-Warehouses mit Hilfe der Mehrschichten
Architekture errichten, um Leistung zu erhöhen, d. h. es gibt nicht nur ein HauptData-Warehouse sondern auch Data-marts, welche es ermöglicht, dem Endbenutzer
näheren Daten zu legen.
Das unten dargestellte Bild zeigt eine Architektur eines Data-Warehouses.
3.2.4 Bezug zur Datenqualität
DWQ leistet die Hilfe für den DW-Entwurfs indem ein Bezug der Hauptkomponente einer DW-Architektur zum formalen Modell der Datenqualität hergestellt
wird [Wa96]. Das Modell ist aus der Idee der Quality-Goal-Hierarchie entstanden, die im Buch von Wang et al. (1995) vorgeschlagen wurde und innerhalb des
DWQ-Projektes für den Gebrauch im Data-Warehouse spezialisiert worden ist. Die
Hauptunterschiede zum initialen Modell liegen in der grösseren Betonung der historischen sowie der aggregrierten Daten.
33
3 Datenqualität - Der GQM-Ansatz und das DWQ-Projekt
Abbildung 3.2: Beispiel einer Struktur eines Data-Warehouses
Abbildung 3.3: Qualitätsfaktoren in einem Data-Warehouse
34
3.3 DWQ-Rahmenarchitektur
Das Ziel ist eine Datenqualitätsrichtlinie so wie die Richtung einer Organisation,
die sich um die Datenqualität ihrer Produkt sorgt. Die Datenqualitätsverwaltung
ist die Verwaltungsfunktion, die die Datenqualitätsrichtlinie bestimmt und durchführt.
Die Datenqualitätskontrolle ist eine Reihe betrieblicher Techniken und Tätigkeiten, die verwendet werden, um die für ein Datenprodukt erforderliche Qualität
zu erreichen. Die Datenqualitätssicherung umfasst die ganzen geplanten, systematischen Aktionen, die für die Gewährleistung angemessener Sicherheit notwendig
sind, um zu sichern, dass ein Datenprodukt einen Satz von Qualitätsanforderungen
erfüllt.
Somit ist das Modellieren und das Messen der Qualität eines Data-Warehouses,
das häugste Problem. Da ein Data-Warehouse ein System aus mehreren Subsystemen und Prozessen zusammengesetzt ist, muss es ein Mapping zwischen den
Data-Warehouse-Komponenten und dem Qualitätsmodell geben. Ferner muss das
Ziel untersucht werden, das sich mit der Entwicklung der Manahmen für die Qualitätskennzeichen und einer Methodologie für die Entwurfsqualität für ein spezisches Data-Warehouse beschäftigt. Eine nähere Überprüfung der Hierarchie der
Qualitätsfaktor zeigt mehrere Beziehungen zwischen den Qualitätsparametern und
den Entwurfs-Aspekte eines DW. In der Abbildung 3.4 sind diese Beziehungen dargestellt. Das Ziel des DWQ-Projekts ist es, diese Beziehungen auf systematische
Weise zu untersuchen und formelle Lösungen vorzuschlagen, die im DW-Entwurf
und in der DW-Entwicklung helfen werden.
3.3 DWQ-Rahmenarchitektur
Ein ausführliches Anschauen der Data-Warehouse-Literatur zeigt, dass die Abbildungen 3.1 und 3.2 sich mindestens in drei unterschiedlichen Möglichkeiten interpretieren lassen können [KR05]. Diese werden als die konzeptionelle Perspektive,
die logische Perspektive und die physikalische Perspektive betrachtet. Alle möglichen gegebenen Data-Warehouse-Komponenten können aus allen drei Perspektiven
analysiert werden. Auÿerdem im Design, im Betrieb und insbesondere in der Entwicklung eines Data-Warehouse ist es Wünschenswerte, dass diese drei Perspektiven konsitent miteinander verbunden werden. Schlieÿlich sind die Qualitätsfaktoren
häug mit spezischen Perspektiven oder mit spezischen Verhältnissen zwischen
Perspektiven verbunden.
In der Abbildung 3.5 sieht man entsprechend, dass es 9 Datenspeicherkomponententypen gibt, die durch mindestens 12 Arten von Beziehungen verbunden sind
und durch den DW-Agenten aus dem Metamodell erhalten werden. Es wird jede Perspektive besprochen. Die Diskussion bleibt rein auf Schema-Niveau. Jeder
DW-Bestandteil ist eine Instanz aller drei Perspektiven.
35
3 Datenqualität - Der GQM-Ansatz und das DWQ-Projekt
Abbildung 3.4: Die Beziehung der Qualitätsfaktoren zu den Data-WarehouseAufgaben
3.3.1 konzeptionelle Perspektive
Für die strategische Verwaltung kann ein Data-Warehouse dem Zweck dienen, den
Informationsressourcen und Analyse-Aufgaben einer Organisation eine gesamte Geschäftsperspektive - ein konzeptionelles Unternehmensmodell - aufzuerlegen. Wenn
dieses Unternehmensmodell als eine Klassenstruktur angesehen wird, ist seine Instanz die Organisation, über die das Data-Warehouse Informationen hat, und nicht
ein Teil des DW selbst. Stattdessen ist die DW-Architektur ein Netz von direkten
und abgeleiteten Views (d. h., registrierte Beobachtungen) dieser Realität. Das
Schema von Informationsquellen wird als eine Kollektion von zuvor materialiserten
konzeptionellen Sichten auf dem Unternehmensmodell deniert, nicht umgekehrt!
Diese wichtige Beobachtung ist bereits im Information Manifold Projekt von AT*T
gemacht worden [LRO96].
Auf der Kundenseite können die Interessen von Benutzergruppen (wie Analytiker) auch als konzeptuelle Sichten auf den Unternehmensmodellen beschrieben
werden. Jedoch können diese Kunden-Sichten nicht durch direkte Beobachtung der
Realität befriedigt werden; stattdessen müssen sie sich auf vorhandene materialisierte Views verlassen, d. h. Informationsquellen. Demzufolge hat man das Problem
des Mappings konzeptioneller Kunden-Views auf konzeptionelle KundenquellViews.
Ferner, bei der Betrachtung der Qualitätsfaktoren Leistung und Sicherheit dürfen Kunden-Views häug nicht auf die Quellen direkt zugreifen. Eine Reihe ver-
36
3.3 DWQ-Rahmenarchitektur
Abbildung 3.5: Die drei Aspekte einer Data-Warehouse-Architektur
mittelnder konzeptueller Views auf das Unternehmensmodell wird deshalb häug
aufgebaut - das konzeptuelle Schema des DW. Diese Reihe muss die formellen Eigenschaften haben, die es allen erwarteten Kunden-Views erlauben, Antworten auf
ihre Abfragen zu bekommen, vorzugsweise dieselben, die sie bekommen würden,
wenn sie auf die Quell-Views direkt zugreifen würden [JV97].
In Bezug auf die DW-Qualität deniert das Unternehmensmodell eine Theorie
der Organisation. Aktuelle Beobachtungen (d. h. Informationsquellen) können für
Qualitätsfaktoren wie Genauigkeit, Rechtzeitigkeit und Vollständigkeit in Bezug
auf diese Theorie bewertet werden. Ferner gilt, dass die Tatsache, dass die DataWarehouse-Views zwischen den Kunden-Views und den Quell-Views liegen, sowohl
einen positiven als auch einen negativen Einuss auf der Informationsqualität haben kann. Positiver Einuss wird durch das Verwenden des Unternehmenmodells
für die Datenreinigung und die Evidenz-Integration erreicht. Wahrscheinlich die
wichtigsten einzelnen Beiträge des konzeptuellen Niveaus in der DW-Praxis.
Potenzieller negativer Einuss entsteht durch die Verzögerung im Aktualisieren der materialisierten DW-Views (Rechtzeitigkeit der Information verschlechtert
sich häug im Vergleich mit OLAP-Daten), und durch die Beschränkungen der
Ausdrucksfähigkeit in dem konzeptuellen Modell, das aus Gründen der Entscheidbarkeit beim logischem Denken und der Einfachheit beim Gebrauch nicht alle
sprachwissenschaftlichen Möglichkeiten aller Quellen umfassen sollte [JV97].
37
3 Datenqualität - Der GQM-Ansatz und das DWQ-Projekt
3.3.2 Logische Perspektive
Die logische Perspektive stellt sich ein DW aus der Sicht der aktuellen Datenmodelle vor. Forscher und Praktiker, die dieser Perspektive folgen, sind diejenigen,
die ein DW als eine einfache Kollektion von aufeinanderen aufbauenden Sichten,
welche auf den vorhandenen Informationsquellen basieren.
Auf der Quellseite besteht das Hauptproblem, das in dieser Perspektive adressiert wird, aus dem laden der heterogen dargestellten Datenquellen und die Integration von Daten von mehrfachen Quellen in bestimmten Ansichten.
Insbesondere zu beachten ist, das so genannte wartende Warehouse, in dem das
DW selbst genügende Informationen enthält, um alle seine Ansichten beizubehalten, damit die Änderungen in der Datenbank durchführbar wird.
Auf der Klientseite sind die auf Views basierte Optimierungsabfrage und die
Updateausbreitung die zwei zentralen Fragen. Aber das Thema verschiebt sich,
weil Benutzerdatenmodelle zu den Quelldatenmodellen unterschiedlich sind.
Insbesondere hat die Einleitung von multi-dimensionalen Datenmodellen mit
der Aggregation und der Verdichtung eine starke Auswirkung auf Algorithmen
und materialisierungsstrategien [JV97].
Die Data-Warehouse-Produkte unterscheiden sich, sobald sie die Aufgaben komplexer werden. Während MOLAP-Produkte die DW-Sichten als multi-dimensionale Datenstrukturen bereithalten, benutzen ROLAP-Produkte eine relationale
Datenbank, um die DW-Sichten zu speichern und machen die Umwandlung zu dem
multi-dimensionalen Datensmodell nur für das mapping zu den Klient-Sichten.
Qualitätsfaktoren, die sich auf die logische Perspektive auswirken, decken hauptsächlich die Datenmodelle an der Quelle und der Klientseite ab und stellen folglich einen wichtigen Faktor für die Zugänglichkeit der Informationen sowie der Interpretierbarkeit auf der Klientseite dar. Zusätzliche Logikniveauoptimierung von
Abfragen sowie Aktualisierung haben eine starke Auswirkung auf die Menge der
transportierten Daten und folglich auf die Leistung des Systems.
3.3.3 Physikalische Perspektive
Die physikalische Perspektive interpretiert die Data-Warehouse-Architektur als ein
Netz von Datenspeicher, Datentransformatoren und Nachrichtenkanäle, hinsichtlich der Qualitätsfaktoren Zuverlässigkeit und Leistung im Falle sehr groÿer Mengen sich langsam ändernder Daten.
Auf der Quellseite soll als zentrale Aufgabe die Interferenz mit OLTP-Systemen
minimiert werden und gleichzeitig einer vernünftigen Grad der Aktualität in den
Daten aufrechterhalten. Typische Forschungsfragen umfassen deshalb eine Entwurfsrichtlinie den Wiederanauf abgebrochener Datenaktualisierungen und Entscheidungen, welche Komponente verwenden, um bestimmte Funktionen zu erreichen.
Auf der Kundenseite ist eine Hauptfrage, wie man ein Netz von zuvor materialisierte konguriert für Sivht, um durchschnittliche Antwortzeiten für einen ge-
38
3.4 Bestimmung Data-Warehouse Qualität
gebenen Mix von Aktualisierungen und Abfragen zu minimieren. Wie gezeigt im
Abbildung 3.2 kann das den Gebrauch von maÿgeschneiderten Data-Marts sowie
Haupt-Data-Warehouse involvieren. Es kann auch den kundenseitigen Cachespeicher von Zwischenergebnissen involvieren, um Datenübertragung zu minimieren.
3.3.4 Beziehungen zwischen Perspektiven
Im Allgemeinen ist die physische Perspektive gröÿtenteils durch die Industrie erforscht worden, wohingegen die konzeptionelle Perspektive durch die Forschung
hauptsächlich berücksichtigt wird. Forschung und Praxis treen sich auf der logischen Ebene, aber mit verschiedener Betonung je nachdem, wo sie herkommen. In
Anbetracht der Suche nach der Qualität in einem Data-Warehouse werden diese
Strömungen aus eigenem Interesse sich verschmelzen.
Die Schritte in konzeptuellen über den logischen zum physischen Entwurf sind für
das ganze Datenbankdesign allgemeine Aufgaben, jedoch sind sie für den speziellen
Fall von Data-Warehouse noch nicht gründlich untersucht worden. Grundsätzlich,
wenn man von Konzeptionell bis Logisch geht, enstehen zwei Problemen:
• Das Voranschreiten von einem ergiebigen Begrismodell zu einem vereinfachten Datenmodell wie das relationale Datenmodell;
• Die Fragmentierung eines zusammenhängenden konzeptuellen Schemas in
individuelle logische Datenstrukturen.
In DWQ wird die Hypothese erforscht, dass die Verknüpfung zwischen logisch
und konzeptionell auf eine sehr ähnliche Weise wie die Verknüpfung zwischen
dem konzeptionellen Quellsicht und dem konzeptionelle DW-Schema deniert
werden kann, nämlich durch spezielle Arten von Views auf dem konzeptuellen
Schema.
Der Schritt von Logischen zum Physikalischen erfordert die Verteilung der gekennzeichneten Datenfragmente und der Umwandlungsaufgaben zu einem Netz der
verteilten, zusammenarbeitenden Software-Agenten.
In diesem Schritt müssen Berücksichtigungen für die Zuverlässigkeit und Leistung hinzugefügt werden, während semantische Berücksichtigungen durch Mechanismen indirekt ausgedrückt werden müssen, die sie verstärken. Zur Qualitätssteigerung eines Data-Warehouse werden einzelne Aufgaben analysiert; dabei werden
in der Regel logische, konzeptionelle und physikalische Verfahren eingesetzt.
3.4 Bestimmung Data-Warehouse Qualität
In diesem Abschnitt werden die formalen Aspekte und das Repository-Based Management von DW-Qualitätszielen betrachtet, die in den vorherigen Abschnitten
inhaltlich beschrieben wurden. Zuerst wird der Qualitätsfunktions-DeploymentAnsatz (QFD) als eine Methode für die Qualitätsplanung erläutert und deniert,
39
3 Datenqualität - Der GQM-Ansatz und das DWQ-Projekt
dann die Goal-Question-Metric-Ansatz (GQM) als Methode für die Qualitätseinschätzung in einem Data-Warehouse.
3.4.1 QFD-Quality Function Deployment
Eine erste Formalisierung basiert auf der qualitativen Analyse der Beziehungen
zwischen den Qualitätsfaktoren selbst, z.B, positive oder negative Beziehungen
zwischen Ziel und Subziel oder Beziehungen zwischen Ziel und Mittel. Dadurch
können die Interessenvertreter (Stakeholder) Einschätzungen sowie mögliche Gewichtungen für individuelle Ziele vornehmen und damit die Güte eines Handels
bestimmen.
Diese Vorgehensweise ist in der Industrie weit verbreitet, rmiert unter dem
Namen QFD; das ist eine spezielle Art der Matrixdarstellung und wird 'House
of Quality' genannt [Aka90] (siehe Abbildung 3.6). Das formale Denken in solch
einer Struktur ist beispielsweise in Arbeiten über den Umgang mit nichtfunktionalen Voraussetzungen in der Softwaretechnik [MCN92] untersucht worden. Visuelle
Tools haben einen hohen Beitrag zur Handelsunterstützung unter verschiedensten
Qualitätskriterien [GJS97] geleistet.
Die Methodologie für ein 'House of Quality' umfasst mehrere Schritte. Der erste
Schritt schliesst das Modellieren von Kundenbedürfnissen und Erwartungen ein. In
diesem Schritt wird eine Liste von Zielen erzeugt, oft ausgewiesen als WAS-Fragen
[BBBB95]. Es passiert sehr häug, dass eine Kundenanforderung eher allgemein
und vage formuliert ist; deshalb wird die erste Liste verfeinert und eine zweite,
ausführlichere wird erzeugt. Falls erforderlich kann dieses Verfahren beliebig oft
wiederholt werden. Der zweite Schritt umfasst Vorschläge für die technische Realisierung (WIE-Fragen) für das Problem (Kundenanforderung) aus dem vorhergehenden Schritt. Der dritte Schritt kombiniert die Ergebnisse der zwei vorherigen
Schritte. Das grundlegende Ziel dieses Prozesses ist die Beantwortung der Frage
"Wie können Kundenanforderungen und mögliche technische Lösungen miteinander verknüpft werden?". Im vierten Schritt werden die Wechselbeziehungen der
technischen Aspekte bei der Umsetzung identiziert und miteinander in der Lösung zusammengeführt.
Als nächstes muss eine Wettbewerbsanalyse gemacht werden. Sie beinhaltet ein
Paar von gewichteten Tabellen, die analytisch aufzeigen, wie man produkte von
Wettbewerbern mit den eigenen Produkten vergleicht. Die Wettbewerbsanalyse
wird in zwei Kategorien unterteilt: Kundenbewertung und technische Bewertung.
Der folgende Schritt ist die Priorisierung von Kundenanforderungen. Die priorisierten Kundenanforderungen sind ein Block von Spalten wobei jede Spalte einer
Kundenanforderung entspricht. Des Weiteren enthält der Block auch Spalten für
die Wichtigkeit, Sollwert, Faktor der Skala, Verkaufspreiz und absolutes Gewicht
für jede Kundenanforderung.
Schlieÿlich werden durch priorisierten technischen Deskriptoren deniert. Jede
der vorgeschlagenen technischen Lösungen wird mit dem Grad der technischen
Schwierigkeit, des Zielwerts und der absoluten und relativen Gewichte kommen-
40
3.4 Bestimmung Data-Warehouse Qualität
Abbildung 3.6: House of Quality im Quality-Function-Deployment
tiert.
3.4.2 GQM-Goal Quality Metric
Es gibt bestimmt kein entscheidbare Rahmenstruktur, die alle diese Aspekten in einer Sprache abdecken kann. Bei dem Entwurf der Metadatenbank-Erweiterung für
das Qualitätsmanagement muss man deshalb nach halbautomatischen Lösungen
suchen, die alle Aspekte einer Qualitätsmanagementtechniken (aus den vorherigen
Schritten) aufrechterhalten, aber auch gleichzeitig für das Einbetten spezialisierter
Techniken oen sind.
Die DWQ-Lösung zu diesem Problem baut auf den weit verwendeten GQMAnsatz für das Softwarequalitätsmanagement auf [OLV92]. Die Hauptidee von
GQM ist, dass Qualitätsabsichten gewöhnlich nicht direkt bewertet werden können,
aber ihre Bedeutung durch Fragen umschrieben wird, auf die bei der Qualitätsauswertung geantwortet werden muss. Auf solche Frage kann gewöhnlich wieder nicht
41
3 Datenqualität - Der GQM-Ansatz und das DWQ-Projekt
direkt geantwortet werden, sondern man verwendet Metriken, die entweder auf das
Produkt oder auf den fraglichen Prozess angewandt werden. Techniken wie statistische Prozesssteuerungskarten werden dann angewandt, um die Antwort auf die
Frage aus den Messungen abzuleiten.
Der GQM-Prozess besteht also aus den folgenden Schritten:
1. Das Identizieren der Qualitäts- und/oder Produktivitätsabsichten (Goal)
auf Unternehmens- Abteilungs- oder Projektniveau; z.B verbesserte Kundenzufriedenheit, rechtzeitige Übergabe, verbesserte Leistung
2. Von diesen Absichten und beruhend auf Modellen des untersuchten Objekts,
werden Fragen abgeleitet, die diese Absichten so vollständig wie möglich denieren.
3. Festlegen der Messungen, die gesammelt werden müssen, um diese Fragen zu
beantworten.
4. Das Entwickeln der Datenerfassungsmechanismen einschlieÿlich der Validierung und Analyse-Mechanismen.
Eine Absicht wird in Bezug auf ein Problem (z.B. Rechtzeitigkeit), ein Objekt
(z.B, die Änderungsanforderungsverarbeitung), eine Sicht (z.B.die der Projektbetriebsleiters) und einen Zweck (z.B. Verbesserung) deniert. Das Problem und der
Zweck der Absicht werden durch die Richtlinien und die Strategie der Organisation erhalten (z.B. durch die Analyse des Grundsatzprogramms des Unternehmens,
strategische Pläne und, was noch wichtiger ist, durch das Befragen über relevante Themen in der Organisation). Die Zielkoordinate wird aus einer Beschreibung
des Prozesses und der Produkte der Organisation erhalten, indem Prozess- und
Produktmodelle auf dem bestmöglichen Formalitätsniveau speziziert werden.
Es gibt drei Arten von Fragen:
1. Wie kann man das Objekt (Produkt, Prozess oder Ressourcen) in Bezug
auf die Gesamtabsicht des spezischen GQM charakterisieren? Zum Beispiel:
Was ist die gegenwärtige Geschwindigkeit, mit der Änderungsanforderungen
verarbeitet werden? Oder
Wird der Änderungsanforderungsprozess wirklich ausgeführt?
2. Wie kann man die Attribute des Objekts charakterisieren, die in Bezug auf
das Problem des spezischen GQM-Modells relevant sind? Zum Beispiel,
Wie gross ist die Abweichung der wirklichen Änderungsanforderungsverarbeitungszeit von der geschätzten? Oder
Verbessert sich die Leistung des Prozesses merklich?
3. Wie bewerten wir die Eigenschaften des Gegenstands, die in Bezug auf das
Problem des spezischen GQM-Modells relevant sind? Zum Beispiel, Ist die
gegenwärtige Leistung aus der Sicht des Projektbetriebsleiters zufriedenstellend?
42
3.5 Zusammenfassung
Bei jeder gröÿeren Data-Warehouse-Entwicklung und -Verwaltung ist die Entwicklung der Qualitätsmetrik ein kundenspezischer Prozess, der die Maximierung
des Gebrauches der vorhandenen Datenquellen, die Anwendung von objektiven
Maÿen zu ausgereifteren Messobjekten und eher subjektive Bewertungen von informellen oder instabilen Ojekten zum Ziel haben sollte.
3.5 Zusammenfassung
Zusammenzufassend kann jetzt gesagt werden, dass das DWQ-Projekt Techniken und Werkzeuge entwickelt, um das Design und die Operationen eines DataWarehouses zu unterstützen:
• basieren auf gut denierten Datenqualitätsfaktoren,
• durch einen Ansatz mit vollständiger Semantik
• realisiert bei der Verwendung geeigneter Technologien ineinander,
• demonstriert in einer Prototype-Folge von Design- und Operationen-Tools
und
• validiert in einer Kooperation mit europäischer DW-Verkäufern und Benutzern.
DWQ stellt das Framework und modellierende Formalismen für das DW-Design,
die DW-Entwicklung und Wartung zur Verfügung, die auf besondere Anwendungsgebiete und Niveaus der Qualität abgestimmt werden können. Das Potenzial solch
einer Annäherung ist bereits durch der Gebrauch des ConceptBases metamodeling Tool erfolgreich kommerziell demonstriert worden, das sich im COMPULOGProjekt entwickelt . Die DW-Entwicklungsdauer für ein gegebenes Niveau der Qualität wird bedeutsam reduziert und die Anpassung an sich ändernde Benutzeranforderungen wird erleichtert. Es gibt eine hohe Nachfrage nach dem Entwurfs-Tool
für verteilte Datenbanken, die durch gegenwärtige Produkte nicht erfüllt ist. DWQ
hat das Potenzial, diese Nachfrage für ein zunehmend wichtigeres Marktsegment
zu erfüllen. Auÿerdem, ein Menge der Qualitätsverbesserungsabfrage und Aktualisierungsdienstleistungen kann aus DWQ-Ergebnissen abgeleitet werden. Prototypen von spezischen Modellen und die im DW-Projekt entwickelten Tools werden
mit verschiedenen Industrien und öentlichen Verwaltungseinstellungen experimentiert, um Erfahrungen aus Projektergebnissen zu gewinnen. Die Ergebnisse von
DWQ werden mit einer Reihe von Prototyp-Tools demonstriert, die zusammen
verbunden werden und welche in ein bestehende Umgebung aus kommerzieller
DW-Software eingebettet werden.
Die Entwurfs-Tools sind die Mittel, durch die DW-Entwerfer und -Verwalter Inhalt des Repository modizieren. Der zu bauende Integrator wird verwendet, um
das Schema abzurufen, welches die dem DW zugrundeliegende Quelle beschreibt.
43
3 Datenqualität - Der GQM-Ansatz und das DWQ-Projekt
Es wird zusätzlich mit dem taktweise generierten Integrator gerechnet, so dass ein
DW-Schema entsteht, welches die gültigen Informationen beschreibt. Der DesignOptimierer bestimmt welche Sichten über das integrierte Schema im DW gespeichert werden, um die gebräuchlichen Informationen des Endbenutzers zu erfüllen.
Die Entwicklungsunterstützungswerkzeug ermöglicht die Überwachung von Strukturänderungen des Informationsangebotes und der -nachfrage und das Ausführen
von passenden Handlungen. Es ist sowohl im Stande direkt auf das Repository zuzugreifen, als auch den Ansicht-Integrator und den Design-Optimizer zu verwenden,
um sich optimal der DW-Struktur anzupassen.
Der Updateverbreiter beobachtet Änderungen an den Quellen der Datenebene,
überprüft ihre Konsistenz mit Hilfe von Integritätsnebenbedingungen, entscheidet,
ob sie für das DW relevant sind, und stellt eine leistungsfähige Methode dar, das
Quellupdate in ein DW-Update umwandeln. Alle Komponenten, die bis jetzt beschrieben wurden, müssen Konsistenznebenbedingungen und Abfragen berücksichtigen. Diese können im Wesentlichen auf einen Satz generischer Tasks einschlieÿlich
der Überprüfung auf Übereinstimmung, Eindämmung- und Ansichtbrauchbarkeit
verringert werden. Das DWQ-Projekt produziert auch ein Argumentationsmodul
für eine mächtige Beschreibungslogik, durch die die verschiedenen Arten von Beschreibungen in den Schemata, in den Abfragen und in den Sichten erfasst werden
können. Das Modul macht seine Dienste allen anderen Komponenten zugänglich.
44
Benjamin Hohl
4
Fuzzy-Summierbarkeit
Summierbarkeit erlaubt es uns in einem Informationssystem Aggregationsdaten
weiterzuverwenden. Die dafür notwendigen Kriterien sind aber in modernen Systemen nicht immer erfüllbar. Diese Seminararbeit beschäftigt sich mit Ansätzen, um
in solchen Systemen dennoch eine Form von Summierbarkeit zu ermöglichen.
4.1 Einleitung
Aggregtionsdaten bieten Einblicke in Zusammenhänge, die für den Nutzer nur
anhand der Basisdaten oft nicht ersichtlich wären. Die steigende Menge an verfügbaren Basisdaten in heutigen Datenbanken erhöht den Bedarf an umfassenden
und aktuellen Aggregationsdaten, vergröÿert aber auch deren Berechnungsaufwand.
Summierbarkeit bietet Kriterien für die korrekte und eziente Berechnung dieser
Aggregationsdaten.
Abschnitt 4.2 dieser Seminararbeit behandelt Summierbarkeit im klassischen
Sinn nach [LS97]. In den Abschnitten 4.3 und 4.4 werden zwei Ansätze vogestellt,
um das Konzept von Summierbarkeit zu erweitern. Abschnitt 4.5 stellt abschlieÿend beide Ansätze vergleichend gegenüber.
4.2 Summierbarkeit
4.2.1 Ziele
Bei der Summierbarkeit im Data Warehousing geht es um die Aggregation von Daten entlang einer Dimensionshierarchie. Dabei sind folgende Ziele von Bedeutung:
45
4 Fuzzy-Summierbarkeit
Wiederverwendbarkeit von Zwischenergebnissen
Bei der Menge an Daten, die
heute in vielen Datenbanksystemen verarbeitet wird, ist eine vollständige Neuberechnung bei jeder Änderung oft nicht mehr praktikabel. Wiederverwendung von
Zwischenergebnissen erlaubt es, bei einer Änderung der Quelldaten mit minimalem Aufwand die Aggregationsdaten zu aktualisieren. Zwingend erforderlich wird
die Verwendung von Zwischenergebnissen, wenn die Quelldaten gar nicht für die
Berechnung zur Verfügung stehen, beispielsweise aus Datenschutzgründen.
Konsistenz und Nachvollziehbarkeit
Berechnungen unter Verwendung von Zwischenergebnissen sollen immer die gleichen Ergebnisse liefern wie Berechnungen
auf Basis der Ursprungsdaten, und ein Ergebniss soll unabhängig vom Rechenweg
sein. Zusätzlich ist es wünschenswert, dass die Ergebnisse für einen Nutzer des
Informationssystems nachvollziehbar sind.
4.2.2 Szenario
Der Bedarf an Aggregationsdaten in Datenbanksystemen sei hier kurz anhand eines
Beispiels vorgestellt:
Beispiel 4.2.1 (Kundendaten nach Region) Eine europaweit tätige Firma
verwaltet Kundendaten pro Filiale. Zusätzlich zu Anfragen auf den Basisdaten (wie
Anzahl der Kunden pro Filiale) sind für Marktforschungszwecke auch Aggregationsdaten auf der Ebene der Städte und Bundesländern von Interesse (Anzahl der
Kunden pro Region, Durschnitt der Kunden pro Region, . . . ). Gemeinsam bilden
diese Klassikationen eine Dimension (Abbildung 4.1).
Abbildung 4.1: Dimension Kundendaten nach Region
Da die Basisdaten hier sehr umfangreich sein können, und sich andererseits oft
ändern, ist eine Neuberechnung aller Aggregationsdaten bei jeder Änderung sehr
aufwändig, und eine Wiedervendung von Zwischenergebnissen daher wünschenswert.
Standard-Aggregationsoperatoren
sloppyDie üblicherweise verwendeten Aggregationsopperatoren sind Summe, Anzahl (oder Kardinalität), Durchschnitt, Minimum und Maximum (in SQL reprä-
46
4.2 Summierbarkeit
sentiert durch sum, count, avg, min und max). Weitere Operatoren sind möglich,
im Rahmen dieser Arbeit aber nicht von Bedeutung.
4.2.3 Bedingungen
Um die oben genannten Ziele für Summierbarkeit zu gewährleisten sind nach [LS97]
die folgenden drei Bedingungen hinreichend. Diese sind
• Vollständigkeit (completeness)
• Disjunktheit (disjointness)
• Typverträglichkeit (type compatibility)
Vollständigkeit (completeness)
Unter Vollständigkeit versteht [LS97], dass sich Aggregationsdaten einer Ebene
komplett aus den Daten der darunterliegenden Ebene beziehungsweise aus den
Elementardaten berechnen lassen.
Dies wäre in unserem Beispiel dann verletzt, wenn Kunden einer Filiale auÿerhalb Europas nicht berücksichtigt würden (Abbildung 4.2), oder wenn für Kunden
von Filialen auÿerhalb einer Stadt eine Kategorie auf der Ebene der Städte fehlen
würde (Abbildung 4.3).
Abbildung 4.2: Vollständigkeit nicht berücksichtigter Wert
Abbildung 4.3: Vollständigkeit fehlender Wert
Disjunkheit (disjointness)
Disjunktheit erfordert nach [LS97], dass Daten auf keiner Aggregationsebene mehrfach in die Berechnung eingehen, dass sich die Kategorien einer ebene also nicht
überschneiden.
47
4 Fuzzy-Summierbarkeit
Dies wäre in unserem Beispiel dann verletzt, wenn der gleiche Kunde sowohl
in der Filiale Karlsruhe, als auch in der Filiale Stuttgart aufgeführt wird, in der
Summe aber nur einfach gezählt werden soll (Tabelle 4.1, Abbildung 4.4).
Tabelle 4.1: Kunden pro Stadt
Karlsruhe Stuttgart
Gesamt
3 Kunden 2 Kunden 4 Kunden
Abbildung 4.4: Disjunktheit mehrfach berücksichtigter Wert
Typverträglichkeit (type compatibility)
Auch wenn eine Dimension vollständig und disjunkt ist, ist Summierbarkeit in
Abhängigkeit von den Ausgangsdaten und der Aggregatfunktion nicht immer gewährleistet. Dies wird deutlich in folgendem Beispiel, in dem Lagerbestand und
Verkäufe der Filialen einer Region im Verlauf eines Quartals erfasst werden:
Tabelle 4.2: Lagerbestand und Verkäufe pro Monat
Lagerbestand Verkauf
Januar
30 Stück
5 Verkäufe
Februar 25 Stück
10 Verkäufe
März
15 Stück
5 Verkäufe
Quartal sum = ?
sum = 20
max = 30
max = 10
Wie man in Tabelle 4.2 sieht, wäre es zwar möglich eine Summe der Waren über
die einzelnen Monate zu bilden, aber nicht sinnvoll, da der Warenbestand von
einem Monat sich mit dem Warenbestand aus anderen Monaten überschneiden
kann. Keine Probleme ergeben sich dagegen beim Maximum des Lagerbestands,
oder bei Summe und Maximum der Verkäufe.
Man unterscheidet deswegen die folgenden Arten von Kennzahlen:
• Stock (Zustand zum Zeitpunkt T): Einwohnerzahlen, Lagerbestände, . . .
• Flow (Ereignis zum Zeitpunkt T): Geburten, Verkäufe, . . .
• Value-per-Unit (Eigenschaft zum Zeitpunkt T): Preise, Aktienkurse, . . .
48
4.3 Ansatz nach Pedersen, Jensen & Dyreson
Über Daten vom Typ Value-per-Unit lassen sich grundsätzlich keine Summen
bilden, wärend Daten vom Typ Stock nur entlang einer Zeitdimension (wie im
Beispiel) nicht addiert werden können (siehe Tabelle 4.3, Quelle [Leh03a], mit
Abweichungen gemäÿ [LS97] ).
Tabelle 4.3: Kompatibilität von Datentyp
stock
ow
min
ja
ja
max
ja
ja
sum
nicht zeitlich ja
avg
ja
ja
count ja
ja
und Aggregationsopperator
value-per-unit
ja
ja
nein
ja
ja
Typverträglichkeit lässt sich ohne Meta-Information nicht automatisch erzwingen, in diesem Fall läge die Last beim Nutzer, keine die Typverträgichkeit verletzenden Anfragen zu stellen. Die im Folgenden vorgestellten Ansätze behandeln
Verletzungen der Typverträglichkeit nicht gesondert.
4.2.4 Fazit
Wenn eine Dimension allen Bedingungen für Summierbarkeit (Vollständigkeit, Disjunktheit und Typverträglichkeit) genügt, lassen sich Aggregationsdaten für weitere Berechungen wiederverwenden und es ist gewährleistet, dass alle Ergebnisse konsistent und nachvollziehbar bleiben. In heutigen Informationssystemen sind diese
Bedingungen aber nicht immer erfüllbar. Im folgenden werden zwei Ansätze vorgestellt, die in diesen Fällen dennoch eine Form von Summierbarkeit ermöglichen.
4.3 Ansatz nach Pedersen, Jensen & Dyreson
In [PJD99] befassen sich die Autoren mit Möglichkeiten, die Vorteile von Summierbarkeit auch für Informationssysteme zu nutzen, die nicht den Bedingungen
für Summierbarkeit genügen.
4.3.1 Szenario
Als Beispiel für ein derartiges System sei hier die Datenbank eines Krankenhauses
vorgestellt.
Beispiel 4.3.1 (Krankenhaus) Das Krankenhaus verwaltet eine Datenbank al-
ler Patienten und ihrer Diagnosen. Für einen Arzt oder die Verwaltung sind nun
mehrere Aggregationsebenen von Interesse, wir beschränken uns hier auf die folgenden drei (mit steigender Granularität):
• Patient
49
4 Fuzzy-Summierbarkeit
• Diagnose
• Diagnosegruppe
Abbildung 4.5: Dimension eines Krankenhaus-Datenbanksystems
Auf der Ebene der Patienten haben wir beispielsweise die Patienten Müller, Maier und Schmidt, auf der Ebene der Diagnosen die an den Patienten diagnostizierten Krankheiten wie Armbruch, Beinbruch oder die (erfundene) Grippe Typ
C, die wiederum auf der nächsthöheren Ebene in Gruppen wie Knochenbrüche
oder Grippen aufgeteilt werden.
Wie in Abbildung 4.5 zu sehen ist, ist dieses System weder disjunkt noch vollständig. Die Disjunktheit wird zum Beispiel dadurch verletzt, dass für einen Patienten
mehrere Diagnosen existieren können. Vollständigkeit ist nicht gegeben, da einem
Patienten sowohl eine Diagnosegruppe aber keine Diagnose zugeordnet sein können (Wenn die genaue Diagnose nicht bekannt ist) als auch eine Diagnose aber
keine Diagnosegruppe (Wenn für eine Diagnose keine Diagnosegruppe im System
vorhanden ist).
4.3.2 Prinzip
Die Idee hinter diesem Ansatz besteht darin, eine Dimension, die nicht die Vorraussetzungen für Vollständigkeit und Disjunktheit erfüllt, durch das Einfügen neuer
Kategorien zu transformieren. Die resultierende transformierte Dimension ist sowohl vollständig wie auch disjunkt, enthält aber weiterhin alle Kategorien und
Beziehungen der ursprünglichen Dimension. Um dies zu gewährleisten werden drei
Algorithmen nacheinander angewandt:
• makeCovering (für Vollständigkeit)
• makeOnto (für Vollständigkeit)
50
4.3 Ansatz nach Pedersen, Jensen & Dyreson
• makeStrict (für Disjunktheit)
Für eine genauere Beschreibung dieser Algorithmen sowie den Beweis ihrer Korrektheit siehe [PJD99].
4.3.3 Vollständigkeit
MakeCovering und makeOnto erzeugen aus einem nicht vollständigen Dimensionsgraph einen vollständigen Graphen, der zusätzlich zu allen Knoten des Ursprungsgraphen einige neu generierte enthält (Abbildungen 4.6, 4.7). Im resultierenden
Graph haben alle Pfade von > zu ⊥ die gleiche Länge.
Abbildung 4.6: Transformation durch makeCovering
Abbildung 4.7: Transformation durch makeOnto
4.3.4 Disjunktheit
makeStrict
Der Algorithmus makeStrict erzeugt einen disjunkten und vollständigen Dimensionsgraphen aus einem bereits vollständigen, er setzt also die vorherige Ausführung
von makeCovering und makeOnto voraus.
Die zugrundeliegende Idee ist es, jeweils mehrere Knoten, die gemeinsame KindKnoten besitzen zu verschmelzen (fuse nodes) und die so erzeugten neuen Knoten in die Hierarchie einzufügen (Abbildung 4.8). Die so erzeugten verschmolzenen Kategorien können problemlos zur Berechnung von weiteren Aggregationsdaten verwendet werden, da jeder ihrer Kindknoten genau einen verschmolzenen
Elternknoten besitzt.
Die verschmolzenen Knoten werden auch mit den ursprünglichen Knoten verbunden. Diese Verbindung ist nicht disjunkt, was aber für die Summierbarkeit kein
51
4 Fuzzy-Summierbarkeit
Abbildung 4.8: Transformation durch makeStrict (1. fuse nodes)
Problem darstellt, da verhindert wird dass diese Knoten zur weiteren Berechnung
verwendet werden. Dies wird gewährleistet indem diese Knoten von der Hierarchie
entkoppelt (unlinked) werden (Abbildung 4.9), dass heiÿt diese Knoten werden
nur noch für Benutzeranfragen gebraucht, nicht mehr für die interne Berechnung.
Die verschmolzenen Knoten bleiben dagegen für den Benutzer verborgen.
Abbildung 4.9: Transformation durch makeStrict (2. unlink)
Zu beachten ist, dass der Algorithmus keine neuen Ebenen in der Hierarchie
erzeugt, nur neue Kategorien, und die in jeder Ebene sichtbaren Kategorien den
ursprünglichen Kategorien entsprechen (Abbildung 4.10).
Abbildung 4.10: vollständige Transformation durch makeStrict
52
4.4 Fuzzy-Summierbarkeit
4.3.5 Fazit
Durch Anwendung der drei Algorithmen makeCovering, makeOnto, und makeStrict
kann aus einer nicht summierbaren Dimension eine summierbare erzeugt werden,
die dennoch die wichtigsten Charakteristiken der ursprünglichen Dimension beibehält. Ein Nachteil ist allerdings, dass die Ergebnisse ohne Kenntniss der von
makeStrict errzeugten verborgenen Knoten für einen Nutzer nur bedingt nachvollziehbar sind.
4.4 Fuzzy-Summierbarkeit
Im vorigen Ansatz konnten Kategorien zwar mehrere Elternkategorien besitzen,
jedoch immer nur mit der Zugehörigkeit eins oder null. Wie in Beispiel 4.4.1 gezeigt wird, gibt es Hierarchien in denen Kategorien nur zu einem gewissen Grad
Elternkategorien zugeordnet werden können. Um auch in diesen Fällen eine Wiederverwendung von Zwischenergebnissen zu ermöglichen erweitern die Autoren in
[SBML] (aufbauend auf [SMH04]) das Konzept der Summierbarkeit zur FuzzySummierbarkeit (Fuzzy-Summarizability).
4.4.1 Szenario
In diesem Szenario teilen sich mehrere Firmen (A, B und C) die Räumlichkeiten
auf einem Stockwerk. Das folgende Beispiel befasst sich mit der Messung und
Berechnung des Stromverbrauchs innerhalb dieser Firmen.
account.
A
account.
A
acc.B
logistics B
cust. care
C
cust. care
C
reception
area
log.
Abbildung 4.11: Bauplan des Stockwerks aus Beispiel 4.4.1
Beispiel 4.4.1 (Stromverbrauch) Abbildung 4.11 zeigt den Bauplan des Stockwerks mit den einzelnen Räumen sowie den Abteilungen denen sie zugeordnet sind.
Für uns von Interesse sind hier der Stromverbrauch sowie die daraus resultierenden Kosten innerhalb des Stockwerks auf der Ebene der Stromzähler, Räumen
und Firmen. Die Situation kann mit der Hierarchie in Abbildung 4.12 beschrieben
werden.
53
4 Fuzzy-Summierbarkeit
Aus Kostengründen ist für das ganze Stockwerk nur ein Stromzähler vorhanden.
Dessen gemessener Wert für den Stromverbrauch wird den einzelnen Räumen anteilsmäÿig entsprechend ihrer Grundäche zugeordnet. So nimmt der Empfangsbereich die Hälfte der Fläche des Stockwerks ein, daher hat die Verbindung ziwschen
dem Stromzähler und dem Empfangsbereich den Wert 0,5.
Auf der nächsten Ebene wird der Stromverbrauch dieser Räume den verschiedenen Firmen zugeordnet. Für Räume, die ausschlieÿlich von einer Firma genutzt
werden ist diese Zuordnung eindeutig. Für gemeinsam genutzte Räume wie den
Empfangsbereich wird wieder anteilsmäÿig abgerechnet, wobei die Firmen sich auf
eine Aufteilung von 40% für Firma A und B und 20% für Firma C geeinigt haben.
Die hier gegebene Dimension mit anteilsmäÿigen Zuordnungen kann bereits zur
korrekten Berechnung des Stromverbrauches für die einzelnen Räume und Firmen
verwendet werden. Die Frage ist nun, ob auch hier eine Wiederverwendung von
Zwischenergebnissen möglich ist.
Company A
0.4
Company B
Companies
Company C
0.2
0.4
accounting A reception area accounting B logistics B customer care C
0.15
…
0.5
0.06
Meter 378
0.11
Departments
0.18
…
Meters
Abbildung 4.12: Dimension für Beispiel 4.4.1
4.4.2 Benötigte Denitionen
Fuzzy-Summierbarkeit verwendet Konzepte aus dem Bereich der unscharfen oder
Fuzzy-Mengenlehre. Hier werden die für uns wichtigen Begrie kurz deniert, ausführlichere Erläuterungen bietet unter anderem [Zim91].
Denition 4.4.2 (Fuzzy-Menge) Gegeben sei eine scharfe Menge (Universum)
U , dann sei eine Fuzzy-Menge M U oder kurz M deniert als
M := {(x, µM (x))|x ∈ U }
Mit µM (x) : U → I wobei I ⊂ IR und sup(I) endlich ist. µM (x) wird membership
function oder grade of membership genannt [Zim91].
Im Folgenden wird immer I := [0, 1] verwendet, d.h., I ist das geschlossene
Intervall zwischen 0 and 1 und sup(I) = 1.
54
4.4 Fuzzy-Summierbarkeit
f geschrieben werden mit
Jede scharfe Menge M kann auch als Fuzzy-Menge M
f := (x, µ f(x))|x ∈ U ∧ µ f(x) = 1 wenn x ∈ M
M
M
M
0 sonst
f wird die der scharfen Menge M entsprechende Fuzzy-Menge bezeichnet.
Mit M
Es gibt mehrere Denitionen für Vereinigungs- und Disjunktionsoperatoren von
Fuzzy-Mengen. Für die hier verwendete Version von Fuzzy-Klassikationen wurde
aber ausschlieÿlich die bounded sum für die Vereinigung und die bounded dierence
für die Disjunktion verwendet (siehe [Zim91]).
Denition 4.4.3 c1 und c2 sind unscharfe Mengen. Dann sind die bounded sum
∪ und die bounded dierence ∩ deniert als:
c1 ∪ c2 := {(x, µc1 ∪c2 (x))|x ∈ U ∧ µc1 ∪c2 (x) = min{1, µc1 (x) + µc2 (x)}}
c1 ∩ c2 := {(x, µc1 ∩c2 (x))|x ∈ U ∧ µc1 ∪c2 (x) = max{0, µc1 (x) + µc2 (x) − 1}}
Für die Denition der Fuzzy-Dimension wird auÿerdem die λ-Fuzzy-Menge oder
gewichtete Fuzzy-Menge benötigt.
Denition 4.4.4 Sei λ ∈ [0, 1] und S eine Fuzzy-Menge. Dann ist das Produkt
der Gewichte λ und der Fuzzy-Menge S
λS := {(x, λ · µS (x))|x ∈ U }
wieder eine Fuzzy-Menge (λ-gewichtete Fuzzy-Menge).
4.4.3 Prinzip Fuzzy-Dimensionen
Mit Hilfe dieser Denitionen wird nun in [SBML] der Klassikations- und Dimensionsbegri erweitert, um auch nichtganzahlige Zugehörigkeiten zu ermöglichen:
Denition 4.4.5 Eine Fuzzy-Klassikation oder Dimensionsebene C B
=
{c1 , . . . , cn } ∈ C oder kurz C der Basisdaten B ist eine scharfe Menge von Fuzzye = B)
e .
Mengen c1 , . . . , cn mit ci ∈ C ∧ (ci ∪ B
Denition 4.4.6 Gegeben seien die Fuzzy-Klassikationen C = {c1 , c2 , . . . , cn },
C 0 = {c01 , c02 , . . . , c0m } und die Matrix

λc1 c01 . . . . . .
 ..
..
 .
.
ΛCC 0 = 
 ..
..
 .
.
0
λ c1 cm . . . . . .
λcn c01
..
.
..
.
λcn c0m



 mit λc c0 ∈ [0, 1].
i j


Dann lässt sich C → C 0 als Beziehung zwischen Fuzzy-Klassikationen denieren:
X
C → C 0 ⇔ ∀c ∈ C∀c0 ∈ C 0 ∀x ∈ U : µc0 (x) =
λcc0 µc (x)
c∈C
55
4 Fuzzy-Summierbarkeit
Mit der Beziehung → kann nun eine Fuzzy-Dimension deniert werden.
Denition 4.4.7 Eine Fuzzy-Dimension D besteht aus einer Menge von FuzzyKlassikationen C einschlieÿlich einer Fuzzy-Klassikation C⊥ , und der Beziehung
∗
∗
→ mit ∀C ∈ C : C⊥ → C (wobei → die transitive Hülle von → ist)
D := {C, C⊥ , →}
4.4.4 Fuzzy-Vollständigkeit und Fuzzy-Disjunktheit
Da für Zugehörigkeiten auÿer null und eins die Bedingungen Vollständigkeit und
Disjunktheit nicht anwendbar sind, werden stattdessen die erweiterten Bedingungen Fuzzy-Vollständigkeit und Fuzzy-Disjunktheit eingeführt.
Diese sind für Klassikationen und Dimensionen wie folgt deniert:
Denition 4.4.8 Eine Klassikation C ∈ C ist fuzzy-vollständig genau dann,
wenn
∀x ∈ B :
X
µc (x) ≥ 1.
c∈C
Eine Klassikation C ∈ C ist fuzzy-disjunkt genau dann, wenn
X
∀x ∈ B :
µc (x) ≤ 1.
c∈C
Fuzzy-Disjunktheit and Fuzzy-Vollständigkeit für Klassikationen kann zusammengefasst werden zu
X
∀x ∈ B :
µc (x) = 1.
c∈C
Denition 4.4.9 Eine Dimension D = {C, C⊥ , →} ist fuzzy-vollständig genau
dann, wenn
C⊥ fuzzy-vollständig ist und ∀(C → C 0 ) ∀c ∈ C :
X
λcc0 ≥ 1.
c0 ∈C 0
Eine Dimension D = {C, C⊥ , →} ist fuzzy-disjunkt genau dann, wenn
X
C⊥ fuzzy-disjunkt ist und ∀(C → C 0 ) ∀c ∈ C :
λcc0 ≤ 1.
c0 ∈C 0
Fuzzy-Disjunktheit and Fuzzy-Vollständigkeit für Dimensionen kann zusammengefasst werden zu
X
C⊥ ist fuzzy-disjunkt und fuzzy-vollständig und ∀(C → C 0 ) ∀c ∈ C :
λcc0 = 1.
c0 ∈C 0
Mit Fuzzy-Vollständigkeit und Fuzzy-Disjunktheit kann nun eine der Summierbarkeit aus [LS97] entsprechende Fuzzy-Summierbarkeit deniert werden:
56
4.5 Vergleich
Denition 4.4.10 Eine Dimension ist fuzzy-summierbar, wenn sie fuzzy-vollstän-
dig, fuzzy-disjunkt und in Verbindung mit den verwendeten Aggregatfunktionen typverträglich ist.
Zu beachten ist, dass aus Fuzzy-Sumierbarkeit Summierbarkeit folgt, das heiÿt
eine scharfe Dimension die die Kriterien für Fuzzy-Summierbarkeit erfüllt, ist auch
summierbar nach [LS97] (siehe [SBML]).
4.4.5 Fazit
Fuzzy-Summierbarkeit erweitert das Konzept der Summierbarkeit, so dass auch
für Hierarchien mit nichtganzzahligen Zugehörigkeiten die Wiederverwendung von
Zwischenergebnissen möglich wird. Sofern die Bedingungen Fuzzy-Vollständigkeit,
Fuzzy-Disjunkheit und Typverträglichkeit erfüllt sind, ist auch in diesen Fällen
Konsistenz und Nachvollziehbarkeit gewährleistet.
4.5 Vergleich
4.5.1 Ansatz
Fuzzy-Summierbarkeit erweitert die Bedingungen für Summierbarkeit, um auch in
nicht-summierbaren Informationssystemen eine Wiederverwendung von Zwischenergebnissen in einer Dimension zu ermöglichen. Im Ansatz von Pedersen, Jensen
& Dyreson wird im Gegensatz dazu eine Dimension durch das Einfügen neuer
(teilweise verborgener) Kategorien transformiert, so dass das resultierende System den klassischen Bedingungen für Summierbarkeit nach [LS97] genügt. Die
verwendeten Algorithen setzen dabei in der Ursprungsdimension ganzzahlige Zugehörigkeiten zwischen den Kategorien im Bereich von 0 bis ∞ vorraus, während
Fuzzy-Summierbarkeit reelle Zugehörigkeiten zwischen 0 und 1 verlangt.
4.5.2 Zusammenfassung
Wie gezeigt wurde, erlauben beide Ansätze die konsistente Wiederverwendung von
Zwischenergebnissen auch für nach [LS97] nicht summierbare Informationsysteme.
Unterschiede gibt es dabei aber sowohl im Ergebnis wie auch in den Anforderungen
an das Informationssystem. Die Vor- und Nachteile der Ansätze sind daher von Fall
zu Fall unterschiedlich zu bewerten.
So ist der Stromverbrauch in Beispiel 4.4.1 eine Gröÿe, die sich nachvollziehbar auch anteilsmäÿig den einzelnen Räumen und Firmen zuordnen lässt. Bei den
Patienten des Krankenhauses aus Beispiel 4.3.1 wäre eine derartige anteilsmäÿige Zuordnung zu Diagnosen dagegen nur bedingt nachvollziehbar, was gegen eine
Verwendung von Fuzzy-Summierbarkeit in diesem Fall spricht. Denn da FuzzySummierbarkeit für die Summe der Zuordnungen einer Kategorie den Wert 1 fordert (Denition 4.4.8), ergäben sich für einen Patienten mit mehreren Diagnosen
pro Diagnose Werte kleiner als 1.
57
4 Fuzzy-Summierbarkeit
Der Ansatz von Pedersen, Jensen & Dyreson löst dieses Problem durch die Einführung sichtbarer und nicht-sichbarer Kategorien, wobei die Summe der Zuordnungen der sichtbaren Kategorien auch Werte gröÿer als 1 annehmen kann. Dadurch
wird allerdings auch die Nachvollziehbarkeit eingeschränkt, da dem Nutzer nur
die Werte der sichtbaren Kategorien zur Verfügung stehen, mit diesen aber keine
weitere Aggregatbildung mehr möglich ist.
Fuzzy-Summiebakeit liefert zwar überprüfbare Kriterien, die für die Einhaltung
dieser Kriterien unter Umständen notwendigen Änderungen an einer Dimension
werden aber nicht vorgegeben. Die Algorithmen von Pedersen, Jensen & Dyreson dagegen erforderern keine Entscheidung des Benutzers, um aus einer nichtsummmierbaren Dimension eine summierbare zu erzeugen, dies bietet aber auch
weniger Einussmöglichkeiten auf das Ergebnis.
In vielen Fällen entscheidet schon die Frage, ob nichtganzzahlige Zuordnungen
im betreenden System zulässig oder gar gefordert sind, über den besser geigneteren Ansatz.
Themen für zukünftige Studien gibt es nach [PJD99] und [SBML] viele, beispielsweise ob sich beide Ansätze kombinieren oder jeweils nur auf Teilen einer Hierarchie
anwenden lieÿen, oder ob für einzelne Aggregatsfunktionen wie Minimum und Maximum umfassendere Erweiterungen der Summierbarkeit möglich sind.
58
Christoph Goebel
5
Common Warehouse Metamodel und
Imperfektion
Die vorliegende Arbeit gibt einen Überblick über das Metadatenmanagement im
Data Warehousing und stellt das von der Object Management Group (OMG) propagierte Common Warehouse Metamodel (CWM) vor. Ferner wird am Beispiel
der Modellierung imperfekter Daten im Rahmen des OVID-Projektes der Universität Karlsruhe (TH) konkrekt demonstriert, inwieweit das CWM an neue Anforderungen angepasst werden kann. Dabei wird auf der Grundlage vorangegangener
Arbeiten aufgebaut.
5.1 Einleitung
Für alle Bereiche der Information Supply Chain (ISC) sind Metadaten von herausragender Bedeutung. Durch das Common Warehouse Model (CWM) der Object
Management Group (OMG) ist ein neuer Standard für die Modellierung von Metadaten im Data Warehousing geschaen worden, der das Potential hat, die produktund herstellerübergreifende Integration der ISC entscheidend voranzubringen.
In bestimmten Fällen reichen die grundsätzlichen Modellierungsmöglichkeiten
des CWM jedoch nicht aus, um Metadaten hinreichend genau zu charakterisieren.
Ein Beispiel hierfür ist die Modellierung imperfekter Daten, wie sie im Rahmen des
OVID-Projektes der Universität Karlsruhe (TH) vorliegen. Imperfekte Daten sind
unscharfe, unsichere oder ungenaue Daten, die im konventionellen Datawarehouseprozess gewöhnlich bereits durch die Extraktions-, Transformations- und LadeProzesse (ETL-Prozesse) bereinigt werden. In manchen Anwendungen ist jedoch
der Erhalt der Imperfektion wünschenswert. Daher muss das CWM diesen Anforderungen entsprechend angepasst und erweitert werden.
59
5 Common Warehouse Metamodel und Imperfektion
5.2 Metadaten und Metadatenmanagement
5.2.1 Bedeutung von Metadaten
Der Prozess der Informationsgewinnung aus operativen, transaktionsorientierten
Daten wird oft als Information Supply Chain (ISC) bezeichnet [PCTM03]. Dieser
Begri stellt eine Analogie zum klassischen Forschungsbereich des Supply Chain
Management her, der sich mit einer ezienten Organisation der Lieferkette, die
der Produktion materieller Güter zugrunde liegt, befasst. Diese Analogie ist auch
durchaus berechtigt, denn durch stete Verfeinerung und kontextbezogene Erweiterungen der ursprünglichen Rohdaten entstehen unter anderem durch die ETLProzesse und die gegebenenfalls später durchgeführten Data Mining-Prozesse und
OLAP-Analysen Informationsgüter in Form von strategischen Geschäftsinformationen.
Genau wie im Fall der klassischen Supply Chain ist eine reibungslose Erzeugung
des Endprodukts nur dann möglich, wenn die unterschiedlichen Produktionsstufen
miteinander kommunizieren können. Man stelle sich eine Endmontagelinie für Automobile vor: Es ist ein heiÿer Sommer und das Management beschlieÿt, fortan
nur noch Cabriolets zu produzieren. Das Faltdach kann preiswert von einem polnischen Zulieferer bezogen werden, die polnischen Arbeiter können aber mit den
Computerausdrucken, welche die Faltdachtechnik beschreiben, nicht viel anfangen.
Beim letzten Faltdach-Zulieferer gab es diesbezüglich keine Probleme, da dieser
die gleiche Entwurfssoftware einsetzte. In der Information Supply Chain kann es
zu analogen Problemen kommen.
Typischerweise werden für die verschiedenen Prozesse der ISC Werkzeuge verschiedener Hersteller verwendet. Die verschiedenen Reporting-Tools des einen Herstellers können aber eine vollkommen andere Sprache sprechen als der OLAPServer eines anderen Herstellers. Alle Software-Tools, die Teil der ISC sein sollen,
müssen demnach zunächst auf der Ebene der Metadaten integriert werden, bevor
eine Integration auf Datenebene stattnden kann.
Um die Struktur und semantische Bedeutung von Daten auf verschiedenen Stufen der ISC zu beschreiben, werden Metadaten verwendet. Metadaten sind bekanntlich Daten über Daten, in diesem Fall also jede Art von Information, die
für den Entwurf, die Konstruktion und die Benutzung eines Informationssystems
benötigt wird [BG04]. Sie können grundsätzlich auf drei unterschiedliche Arten
genutzt werden:
• Passiv als konsistente Dokumentation aller Komponenten der Architektur
des Data Warehouse für Anwender, Administratoren und Anwendungsentwickler.
• Aktiv, indem beispielsweise Transformationsregeln gespeichert werden, die
von entsprechenden Werkzeugen interpretiert und ausgeführt werden.
• Semiaktiv, indem Metadaten beispielsweise zur Überprüfung von Strukturmerkmalen wie etwa Tabellendenitionen verwendet werden.
60
5.2 Metadaten und Metadatenmanagement
Hierzu ein sehr einfaches Beispiel aus dem Bereich der relationalen Datenbanken:
Eine Anwender möchte mit Hilfe eines OLAP-Tools die Umsatzentwicklung seines
Unternehmens visualisieren und dazu auf eine relationale Datenbank zugreifen,
in der er die Umsatzdaten der letzte Jahre vermutet. Er weiÿ aber nicht, ob die
Daten wirklich vorhanden sind und wenn ja, wie sie strukturiert sind, insbesondere
Bezeichnung der Relationen und Attribute sowie Datentypen. Zudem hat bereits
ein Kollege vor ihm Berechnungsschemata für einige Umsatzkennzahlen erstellt,
welche er wiederverwenden möchte. Solche Informationen können durch Metadaten
beschrieben und über eine geeignete Kommunikationsinfrastruktur ausgetauscht
werden.
5.2.2 Metadatenmanagement
Das Metadatenmanagement beschäftigt sich mit der Frage, wie Metadaten sinnvoll
beschrieben, gespeichert und verfügbar gemacht werden können. Durch die Integration nicht nur auf der Datenebene, sondern auch auf der Ebene der Metadaten soll
letzlich der Entwicklungs- und Verwaltungsaufwand der ISC reduziert werden.1
Dies kann durch kürzere Entwicklungszeiträume und die verbesserten Möglichkeiten zur Automatisierung von Prozessen erreicht werden. Ein weiterer potentiell
positiver Aspekt eines konsequenten Metadatenmanagements kann die Erhöhung
der Akzeptanz auch der Endanwender sein, da Transparenz und Qualität der Daten
erhöht werden können. In [BG04] wird ferner der immer mehr an Bedeutung gewinnende Sicherheitsaspekt genannt: Benutzerrechte können ebenfalls als Metadaten
abgelegt werden und zentral verwaltet werden. 2
5.2.3 Umsetzung des Metadatenmanagement
Die verschiedenen Werkzeuge, die in der ISC Anwendung nden können, verwenden in der Regel bezüglich Syntax und Semantik heterogene Metadaten, schon
aufgrund der Befürchtungen ihrer Hersteller, durch die Standardisierung Marktanteile zu verlieren [PCTM03]. In der Praxis werden daher oft sogenannte Meta
Data Bridges konstruiert, die eine Art Übersetzungsmechanismus für Metadaten
bei der Kommunikation zwischen jeweils zwei Anwendungen darstellt. Diese Form
der Integration ist sehr aufwendig, da einerseits jede mögliche Kombination zweier
Tools einer solchen Brücke bedarf und andererseits die Übersetzung der Metadaten bidirektional möglich sein muss. Um eine Standardisierung der Metadaten und
deren eektive Verwaltung zu erreichen, muss zunächst die Modellierung von Metadaten vereinheitlicht werden, das heiÿt, für den Austausch von regelmäÿig vorkommenden Metadaten wie etwa Tabellendenitionen relationaler Datenbanken muss
ein anwendungsübergreifendes Konstruktionsschema vorgegeben werden. Ein sol1
2
Betriebswirtschaftlich wird also eine Maximierung des Return on Investment (ROI) angestrebt.
Dieser Aspekt ist auch deshalb bedeutend, da ein Data Warehouse durchaus auch schützenswerte Einzeldaten enthalten kann, deren Aggregat allerdings wieder einem breiteren Publikum
zur Verfügung gestellt werden soll.
61
5 Common Warehouse Metamodel und Imperfektion
cher Standard ist das von der OMG propagierte Common Warehouse Meta Model
(CWM), auf das in Abschnitt 5.3 näher eingegangen werden soll. Ferner ist auch
die Architektur der Speicherung und Verwaltung von Metadaten von Bedeutung.
Weitgehend Einigkeit besteht dahingehend, dass eine physikalische Abtrennung
der Metadaten von den Daten in Form eines Metadaten-Repository Sinn macht.
Für die Gewährleistung des Zugris der verschiedenen Warehouse-Anwendungen
und die Sicherstellung der Konsistenz der vorgehaltenen Metadaten ist ein sogennanter Metadatenmanager verantwortlich. Die Zusammenfassung aller Metadaten
einer ISC in einem einzigen Metadaten-Repository ist allerdings - obgleich häug
vorgeschlagen - aus folgenden Gründen mit Vorsicht zu genieÿen:
• Die verschiedenen Data Warehouse-Komponenten werden in hohem Maÿe
vom einwandfreien Funktionieren der zentralen Schnittstelle abhängig.
• Es wird gleichsam ein künstlicher Flaschenhals bei der Metadaten-Kommunikation geschaen.
• Die Realisierung des zentralen Metadaten-Repository und der entsprechenden Schnittstellen ist sehr aufwändig. 3
Eine komplett dezentralen Lösung, in der jedem Data Warehouse-Werkzeug sein
eigenes Metadaten-Repository zugeordnet wird, birgt dagegen ein hohes Risiko
bezüglich Inkonsistenzen. Zudem sind die einzelnen Repositorys zwar leichter zu
realisieren, jedoch wird die Ausgestaltung der benötigten Kommunikationsinfrastruktur wiederum ungleich schwieriger. Zusammenfassend zeichnet sich also ein
Tradeo zwischen beiden Modellen ab. In der Praxis ist daher oft die sogenannte
föderierte Metadaten-Verwaltung anzutreen: Mehrere Metadatenspeicher werden
unabhängig voneinander betrieben und verwaltet, jeweils auf der Grundlage eines
allgemein gültigen Metadatenmodells wie dem CWM. Diese werden dann direkt
miteinander verbunden. Basieren die Metadatenspeicher auf unterschiedlichen Metadatenmodellen, so stellen diese Verbindungen wiederum Meta Data Bridges dar.
5.3 Das Common Warehouse Metamodel (CWM)
Das CWM stellt den Versuch dar, ein umfassendes Metamodell zur Beschreibung
von Metadaten im Data Warehousing bereitzustellen. Bei der Spezikation des
CWM hat sich die OMG an folgenden Richtlinien orientiert:
• Vollständigkeit
• Unabhängigkeit
• Kompatibilität
3
Insbesondere stellt jede ISC unterschiedliche Anforderungen an eine zentrale MetadatenSpeicherung, das heisst dass diese jeweils individuell konzipiert werden muss. Standardlösungen sind daher oft nicht einsetzbar.
62
5.3 Das Common Warehouse Metamodel (CWM)
• Erweiterbarkeit
• Verfügbarkeit
• Verständlichkeit
Als abstraktes Modell ist das CWM vollkommen plattformunabhängig und kann
so gleichsam als Übersetzungsreferenz für proprietäre Metadatenmodelle dienen
(Unabhängigkeit, Kompatibilität): Sollen also Metadaten zwischen zwei Anwendungen innerhalb der ISC ausgetauscht werden, so kann Anwendung A ihre internen Metadaten in das durch das CWM vorgeschriebene Format übersetzen und
Anwendung B die auf diese Weise standardisierten Metadaten wieder in ihr proprietäres Format rückübersetzen. Diese Übersetzung geschieht auf Anwendungsebene,
das heiÿt die Metadaten-Kommunikation ndet direkt zwischen den verschiedenen
CWM-kompatiblen Anwendungen oder gegebenenfalls durch den Umweg über ein
Metadaten-Repository statt. Dies impliziert einerseits, dass das CWM eine hinreichend groÿe Menge von Konzepten, die im anwendungsübergreifenden Bereich
vorkommen, beschreibt, und andererseits, dass ausreichende Erweiterungsmöglichkeiten bestehen, um semantische Lücken in einer ebenfalls standardisierten Art
und Weise zu schlieÿen (Erweiterbarkeit).
Um eine gewisse Übersichtlichkeit einerseits und auch eine Modularisierung 4
andererseits zu gewährleisten, ist das CWM je nach Art der zu beschreibenden
konzeptuellen Domäne in verschiedene Pakete (die oftmals selbst als Metamodell
bezeichnet werden) unterteilt worden, wobei die Anzahl der Verbindungen eines
Pakets zu den anderen auf ein Minimum reduziert wurde. Jedes dieser Pakete enthält demnach ein Modell für ein Modell (Metamodell), welches zur Beschreibung
von in bestimmten Bereichen der ISC auftretenden Daten verwendet werden kann.
Beispielsweise ist ein Paket Relational entwickelt worden, welches Metakonzepte
wie Table und Column deniert. Um einer Verwirrung ob der vielen Abstraktionsebenen vorzubeugen, sind diese noch einmal in übersichtlicher Art und Weise in
Abbildung 5.1 dargestellt. Wie man sieht, existiert in der Terminologie der OMG
oberhalb des UML- und CWM-Metamodells (M2) noch eine weitere Abstraktionsebene (M3). Auf dieser obersten Abstraktionsebene ist die Meta Object Facility
(MOF) angesiedelt, welche eine gemeinsame abstrakte Sprache zur Spezikation
von Metamodellen deniert. Die MOF ist sowohl Grundlage der UML als auch des
CWM. Alle Metadaten-Modelle nutzen die durch die UML vorgegebenen Notationen (Syntax), wenn auch im Fall der MOF in sehr restriktiver Form. Die Aufteilung
der Modelle auf verschiedene Abstraktionsebenen bezieht sich lediglich auf ihre Semantik. In Abschnitt 5.1 ist auch der Bereich des Datenaustauschs erfasst. Man
sieht, dass sich die Beschreibung der serialisierten Metadaten auf ähnliche Weise
4
Diese Aufteilung kann unter anderem zur Optimierung der Architektur der Metadatenspeicher
nützlich sein. Auf derselben Ebene einer hierarchischen Metadaten-Architektur kann so die
Kommunikation auf bestimmte Pakete des CWM beschränkt werden. Näheres hierzu ndet
sich in [PCTM03].
63
5 Common Warehouse Metamodel und Imperfektion
Abbildung 5.1: Metamodellarchitektur der OMG
Abbildung 5.2: CWM-Schichtenmodell
vollzieht wie die Beschreibung ihrer internen Repräsentation. Auch hier können die
verwendeten Modelle den verschiedenen Abstraktionsebenen zugeordnet werden.
Die Pakete des CWM sind in insgesamt fünf Schichten angeordnet, wobei die
oberen Schichten auf den unteren aufbauen und deren Konzepte gegebenenfalls
erweitern. Eine Modularisierung wird insofern erreicht, als dass der Entwickler einer
ISC nur diejenigen Pakete des CWM benutzen muss, die auch wirklich benötigt
werden. Abbildung 5.2 gibt einen Überblick über die verschiedenen Pakete.
5.3.1 Die Schichten des CWM
Auf der untersten Ebene (Object Model ) werden die grundlegenden Elemente, auf
denen alle Konzepte der höheren Schichten aufbauen, festgelegt. Es ist aus den vier
Paketen Core, Behavioral, Relationships und Instance aufgebaut. Das Core -Paket
enthält die statischen Grundbausteine der UML, beispielsweise die Objekte Ele-
64
5.3 Das Common Warehouse Metamodel (CWM)
ment, Attribute etc. Das Behavioral -Paket ergänzt diese statischen Elemente durch
verhaltensbezogene Elemente wie etwa Methoden. Im Paket Relationships werden
verschiedene Arten von Beziehungen modelliert, die Objekte des CWM eingehen
können, beispielsweise Assoziationen und Generalisierungen. Das Instance -Paket
schlieÿlich enthält Modellelemente, die dazu benutzt werden können, Instanzen
bestimmter Klassen zu repräsentieren. Dieses Paket ist auch deshalb interessant,
weil es später dazu verwendet werden kann, ausnahmsweise auch echte Daten
im CWM zu transportieren. Ein typisches Beispiel für solche Daten wären feste
Wertebereiche der Spalte einer Tabelle.
Auf der nächsten Schicht (Foundation ), die aus den sechs Paketen Business
Information, Data Types, Expressions, Keys and Indexes, Software Deployment
und Type Mapping besteht, werden aufbauend auf den einfacheren Elementen des
Object Model allgemeine Konzepte deniert, die ebenfalls in allen Bereichen des
CWM von Bedeutung sind. Das Paket Business Information bildet die Grundlage
zur Einbeziehung beschreibender Informationen und Ansprechpartner. Durch das
Data Types -Paket werden Elemente im Object Model so erweitert, dass gegebenenfalls neue Datentypen deniert werden können. Das Paket Expressions bietet
die Möglichkeit, Ausdrücke wie sie zum Beispiel auch in Programmiersprachen vorkommen, auf der Modellebene zu beschreiben. Indizes und Schlüssel, die vor allem
im relationalen, aber auch im multidimensionalen Modell eine entscheidende Rolle
spielen, werden im Paket Keys and Indexes beschrieben. Das Paket Software Deployment ermöglicht die Beschreibung von Software aus Komponenten und deren
Betrieb. Das Type Mapping -Paket gibt schlieÿlich die Mittel her, um Mappings
zwischen unterschiedlichen Datentypen zu modellieren. Dies ist oensichtlich sehr
wichtig, da ja gerade die Kompatibilität unterschiedlicher Software-Tools gewährleistet werden soll.
Die nächsthöhere Schicht des CWM (Resource ) enthält Modelle, die typische
Datenquellen einer ISC beschreiben. Das Relational -, Record -, Multidimensional und XML-Paket erweitern jeweils Konzepte der beiden darunterliegenden Schichten und modellieren Metadaten, die unter anderem relationale Datenbanken, multidimensionale Datenbanken und XML-basierte Datenquellen beschreiben. Das Object -Paket ist nur der Vollständigkeit halber in die Resource -Schicht des CWM
aufgenommen worden, denn alle Konzepte, die für die Modellierung einer objektorientierten Datenquelle benötigt werden, sind bereits in den Schichten Foundation
und Object Model vorhanden.
Auf der Analysis -Schicht sind diejenigen Konzepte modelliert worden, die im
OLAP-Bereich und Data Mining Verwendung nden (OLAP, Data Mining, Information Visualization, Business Nomenclature ). Auÿerdem ist hier auch das Paket
Transformation angesiedelt, welches dazu benutzt werden kann, um Quell- und
Zielmappings zu modellieren und entsprechende Transformationsvorschriften zu
beschreiben. Diese Transformationen können sowohl zwischen unterschiedlichen
Datenquellen der darunterliegenden Schicht als auch zwischen der Resource - und
der Analysis -Schicht stattnden. Ein typischer Anwendungsbereich ist die Verschiebung von Datenbeständen von einem Speicherbereich der ISC in einen anderen, bei-
65
5 Common Warehouse Metamodel und Imperfektion
spielsweise das Laden von Daten aus dem Arbeitsbereich in das eigentliche Data
Warehouse.
Die Management -Schicht des CWM beschreibt Möglichkeiten zur Modellierung
von Metadaten, welche die ISC als Ganzes betreen, insbesondere Servicefunktionen des Data-Warehouse-Systems zur Steuerung und Kontrolle des Analyseprozesses. Mit Hilfe des Warehouse Process -Pakets können zum Beispiel die Metadaten
eines typischen ETL-Prozess modelliert werden. Im Paket Warehouse Operation
benden sich Konstrukte zur Dokumentation von Ereignissen im Data WarehouseProzess.
5.3.2 Der Austausch von Metadaten im CWM
Mit diesem gemeinsamen Gerüst zur Beschreibung der in der ISC kursierenden
Metadaten ist der erste Schritt hin zu mehr Eektivität und Ezienz bei der
Datenverarbeitung im Data-Warehouse-Prozess getan. Es muss jedoch auch die
entsprechende Infrastruktur zur Verfügung gestellt werden, die einen tatsächlichen
Austausch der gemäÿ den verschiedenen Metamodell-Paketen konstruierten Metadaten ermöglicht. Hierzu sind im CWM zwei Varianten vorgesehen.
Einerseits können die Metadaten über eine spezielle durch die Interface Denition Language (IDL) denierte Schnittstelle ausgetauscht werden, das heiÿt eine an
der ISC beteiligte Software greift auf die zentral verwalteten Metadaten des CWM
über eine Programmier-Schnittstelle zu. Diese IDL-Schnittstellen beschreiben den
Zugri auf die in den verschiedenen CWM-Paketen enthaltenen Metadatenobjekte.
Andererseits besteht auch die Möglichkeit, Metadaten in Form von XML-Dateien
auszutauschen. Hierzu bietet die OMG ein spezielles XML-basiertes Format zum
Austausch von Metadaten in und zwischen Software-Systemen an, das XML Metadata Interchange (XMI). Dieses Format ist in entsprechenden Document Type Denitions (DTD) bzw. XML-Schemata festgelegt, das heiÿt es wird eine regelbasierte
Erzeugung und Validierung von XMI-Dokumenten ermöglicht. Dabei werden die
Metadaten derart serialisiert, dass jede Metadaten-Instanz als XML-Elementinhalt
innerhalb eines entsprechenden Metamodel-Tags gespeichert wird (siehe auch Abbildung 5.1).
5.3.3 Erweiterungsmöglichkeiten
Das CWM erhebt den Anspruch, einen exiblen Rahmen für Spezikation und
Austausch von Metadaten im Data Warehousing bereitzustellen. Daher sind auch
standardisierte Formen der Erweiterung vorgegeben worden, die es ermöglichen,
das CWM an die Anforderungen bestimmter Anwendungen anzupassen. Das CWM
sieht zwei grundsätzlich verschiedene Erweiterungskonzepte vor: Den Einsatz von
Stereotypes und TaggedValues sowie die objekt-orientierte Erweiterung.
Stereotypes und TaggedValues
Stereotypes sind spezielle Labels, die gleichsam
an Klassen angehängt werden können, um deren Verwendung näher zu beschreiben.
66
5.3 Das Common Warehouse Metamodel (CWM)
Abbildung 5.3: Erweiterung des Objekt-Modells durch Stereotypes und TaggedValues
Ihre Klasse ist in der Vererbungshierarchie des Core -Pakets direkt unterhalb der
zentralen Klasse ModelElement angesiedelt, das heiÿt, alle Klassen des CWM erben
die Eigenschaft, als Anhängsel Stereotype -Objekte haben zu können. Abbildung 5.3
zeigt die Beziehungen zwischen ModelElement, Stereotype und TaggedValue.
TaggedValues sind Name-Wert-Paare, die in beliebiger Anzahl mit einem Stereotype assoziiert werden können. Sie können dazu benutzt werden, anwendungsspezische Attribute zu speichern. Ein gewichtiger Nachteil der TaggedValues ist,
dass sie die in ihnen gespeicherten Werte nur das String -Format besitzen können.
Das bedeutet, dass speziellere Datenformate bei der Metadatenübertragung im
Warehouse-Prozess ohne zusätzliche Kommunikation der Komponenten verloren
gehen.
Objektorientierte Erweiterung Grundsätzlich stehen zur Erweiterung des CWM
auch alle OO-Techniken wie Vererbung, Spezialisierung, das Hinzufügen von Attributen und Assoziationen zur Verfügung. Ein typisches Beispiel hierzu wäre die Modellierung einer eigenen Metaklasse, die von einer Standard-Metaklasse des CWM
erbt. Diese neue Metaklasse kann dann beliebig durch spezielle Attribute erweitert
und mit anderen neuen Metaklassen assoziiert werden.
Dieser Erweiterungsmechanismus erscheint auf den ersten Blick sehr mächtig.
In der Tat kann man das CWM dadurch auf beliebige Art und Weise erweitern,
ohne dabei dessen ursprüngliche Struktur, welche Grundlage des standardisierten
Austauschs von Metadaten ist, zu verändern. Trotzdem sollte man sich vergegenwärtigen, dass alle Metadaten einer Anwendung, die auf einer objekt-orientierten
Erweiterung des CWM basiert, von anderen Anwendungen, auch wenn diese den
CWM-Standard unterstützen, nicht verstanden werden können. Echte Kompatibilität kann dann nur dann erreicht werden, wenn all diese Anwendungen dieselbe
Erweiterung einsetzen. Natürlich reicht es in den Fällen, in denen das erweiterte
Metamodell nur anwendungsintern genutzt wird aus, wenn zum Beispiel Speziali67
5 Common Warehouse Metamodel und Imperfektion
sierungen rückgängig gemacht werden (Upcasting ), also nur das CWM-kompatible
Eltern-Objekt an andere Anwendungen übertragen wird.
Es kann davon ausgegangen werden, dass im Zuge der Umstellung von UML 1.3
auf UML 2.0 auch die Konzeption des CWM angepasst werden wird. Insbesondere
werden davon auch die Erweiterungsmechanismen betroen sein. In UML 2.0 können anwendungsspezische Konstrukte durch das neu eingeführte UML-Proling
modelliert werden. Details hierzu können der Studienarbeit von Nils Hilt [Hil05]
entnommen werden.
5.4 Imperfektion in Datenbanken
Dieser Abschnitt führt kurz in die Problematik von imperfekten Daten deren
Speicherung in Datenbanken ein. Er ist gröÿenteils den Arbeiten von Erik Koop
[Koo04a], Andreas Merkel [Mer04], Alexander Haag [Haa04] und Nils Hilt [Hil05]
entnommen.
5.4.1 Der Begri der Imperfektion
Imperfekte Information ist Information, die einen Sachverhalt nur unvollständig
oder unvollendet beschreibt. In [Koo04a] wird imperfekte Information in drei Kategorien wie folgt eingeteilt.
Unsichere Information
Eine Information ist unsicher, wenn aufgrund der verfügbaren Daten nicht festgestellt werden kann, ob sie wahr oder falsch ist.
Unscharfe Information
Eine Information wird als unscharf bezeichnet, wenn sie
nicht eindeutig klassiziert werden kann. Dies setzt voraus, dass der Übergang
zwischen den denierten Klassen ieÿend sein kann.
Ungenaue Imformation
Eine Information ist ungenau, wenn sie nur mittels eines
Intervalls oder ähnlich grober Klassizierungsarten angegeben werden kann.
5.4.2 Theorien und Modelle zur Imperfektion
Zur Darstellung imperfekter Informationen existieren zwei grundsätzlich verschiedene formale Ansätze: Die klassische Wahrscheinlichkeitstheorie und die etwas
neuere Fuzzy-Theorie.
Wahrscheinlichkeitstheorie Die Wahrscheinlichkeitstheorie hat die Aussagenlogik zur Grundlage, derzufolge eine Aussage nur entweder wahr oder falsch sein
kann bzw. ein bestimmtes Ereignis nur entweder vollständig oder gar nicht eintreten kann, das heiÿt, an der grundsätzlichen Qualität eines Ereignisses wird nicht
gerüttelt. Wirft man eine Münze, so kann man, nachdem die Münze liegengeblieben ist, mit Sicherheit sagen, ob die Aussage Münze zeigt Kopf wahr oder falsch
68
5.4 Imperfektion in Datenbanken
ist. Allerdings wird die Wahrscheinlichkeit des Eintritts eines Ereignisses bzw. der
Grad der Überzeugung, dass eine bestimmte Aussage zutrit, gleichsam separat
durch das sogenannte Wahrscheinlichkeitsmaÿ gemessen. Im Fall der Münze kann
man normalerweise annehmen, dass die Wahrscheinlichkeit für das Ereignis Münze zeigt Kopf bei 50% liegt. Die Wahrscheinlichkeitstheorie eignet sich somit ideal
für die Modellierung von unsicherer Information: Es genügt die Angabe der möglichen Aussagen bzw. Ereignisse und des zugehörigen Wahrscheinlichkeitsmaÿes, um
die unsichere Information hinreichend genau zu charakterisieren.
Fuzzy-Theorie
Die Fuzzy-Theorie setzt in ihrer Charakterisierung einer Aussage
bereits auf der Stufe der tatsächlichen Ausprägung an. Sie erweitert die Aussagenlogik um Zwischenstufen zu wahr und falsch beziehungsweise teilt Ereignisse in
unscharfe Mengen, die sogenannten Fuzzy-Mengen ein [Hil05].
In der klassischen Mengenlehre wird eine Menge durch eine ihr zugeordnete
charakteristische Funktion beschrieben. Für ein beliebiges Element gibt diese gewöhnlich an, ob es zur beschriebenen Menge gehört oder nicht.5 Die Bildmenge der
klassischen charakteristischen Funktion ist also binär. Der Fuzzy-Theorie zufolge
ist die Bildmenge einer normalisierten charakteristischen Funktion zur Denition
einer Fuzzy-Menge das gesamte kontinuierliche Einheisintervall [0,1]. Die FuzzyMenge gibt demnach den Zugehörigkeitsgrad eines Elements zu einer Menge an
[Hil05].
Beispiel:
Bekanntlich kann man aus den drei Primärfarben Gelb, Rot und Blau
alle anderen Farben durch Mischen herstellen. Angenommen wir wollen die Farbächen eines Bildes (farblich) klassizieren, aber wegen der groÿen Anzahl der
möglichen Farben nicht eine Klasse für jeden Farbton bereithalten. Hier könnte
man einfach die drei Primärfarben als Klassen angeben und die ihnen zugeordneten Mengen von Farbächen als Fuzzy-Mengen mit entsprechenden Zugehörigkeitsfunktionen beschreiben. Für eine reine grüne Farbäche würde dann sowohl
die Zugehörigkeitsfunktion der Fuzzy-Menge Gelb als auch die der Fuzzy-Menge
Blau eine Zugehörigkeit von 0,5 ergeben, da sich ein reines Grün aus jeweils gleichen Anteilen der Primärfarben Gelb und Blau zusammensetzt.
Vergleicht man den Begri der unscharfen Information mit den Aussagen der
Fuzzy-Theorie, so kann man sehen, dass sich unscharfe Informationen gut durch
die charakteristische Funktion von Fuzzy-Mengen beschreiben lassen.
Linguistische Variable
Eine linguistische Variable hat als Wertebereich verbale Begrie, sogenannte Terme. Bezeichnet x eine linguistische Variable, T (x) die
Menge der möglichen Ausprägungen von x und e ein bestimmtes Ereignis aus der
Grundmenge U , so kann für jedes Element e ∈ U und jeden Term t ∈ T (x) der
Zugehörigkeitsgrad von e zu t bestimmt werden.
5
Diese Beziehung entspricht dem Begri des Enthaltenseins aus der klassischen Mengenlehre
69
5 Common Warehouse Metamodel und Imperfektion
Abbildung 5.4: Zugehörigkeitsfunktionen a) scharf b) fuzzy
scharf
Äquivalenzklasse
scharfe Klasse
Enthaltensein
scharfe Zugehörigkeitsfunktion
unscharf
Term
unscharfe Klasse
Zugehörigkeit
unscharfe Zugehörigkeitsfunktion
Tabelle 5.1: Gegenüberstellung der korrespondierenden Begrie für scharfe und unscharfe Einteilungen
Bei der Modellierung von ungenauen Informationen mit Hilfe von linguistischen
Variablen kann es grundsätzlich zu zwei Fällen kommmen. Entweder kann man
einen Wert immer genau einem Term zuordnen, d. h. der normalisierte Zugehörigkeitsgrad dieses einen Terms ergibt für diesen Wert 1 und der aller anderen Terme
0. In diesem Fall spricht man auch von scharfen Klassen. Oder der Wert wird
jeweils zu einem gewissen Grad mehreren Termen zugeordnet, das heiÿt die Zuordnung ist unscharf oder fuzzy (unscharfe Klassen ). Die aus [Haa04] entnommene
Abbildung 5.4 zeigt in a) den Fall einer scharfen Zugehörigkeitsfunktion und in b)
eine einfache Fuzzy-Zugehörigkeitsfunktion, die graphisch durch einen Trapezoiden
dargestellt werden kann.
In Tabelle 5.1 werden die in diesem Abschnitt eingeführten Begrie der Übersichtlichkeit zuliebe einander noch einmal direkt gegenübergestellt.
5.5 Erweiterung des CWM zur Modellierung
imperfekter Daten
In diesem Abschnitt sollen kurz die Ergebnisse der Arbeiten von Alexander Haag
[Haa04] und Nils Hilt [Hil05] bezüglich Erweiterungsmöglichkeiten des CWM zur
Modellierung imperfekter Daten zusammengefasst werden. Bezüglich der objektorientierten Erweiterung wird ein auf UML 1.3 basierender Ansatz vorgestellt, der
eine möglichst einfache Modellierung der Imperfektion für alle relevanten Konzepte
70
5.5 Erweiterung des CWM zur Modellierung imperfekter Daten
Abbildung 5.5: Imperfekte Stereotypes
des CWM beschreibt.
5.5.1 Erweiterung durch Stereotypes und TaggedValues
Die Erweiterung durch Stereotypes und TaggedValues hat wie oben beschrieben
den Vorteil, dass sie auch dann erhalten bleibt, wenn bestimmte Anwendungen der
ISC nicht explizit an die Erweiterung angepasst worden sind.
Alexander Haag hat in seiner Arbeit beispielhaft die Klasse Table des Relational -Pakets des CWM als Ansatzpunkt für die Erweiterung herausgegrien. Wie
aus Abbildung 5.3 ersichtlich, müssen neue Stereotypes und TaggedValues im Core Paket modelliert werden. Zunächst wird eine Klasse ImperfectionStereotype erstellt,
von der alle Klassen erben, die im Rahmen der Erweiterung durch imperfekte Daten hinzugefügt werden. Um anzuzeigen, dass eine Tabelle imperfekte Daten erhält
wird sie mit dem Stereotype Imperfect Table gekennzeichnet. Die entsprechende Klasse ist ImperfectTableStereotype. Jede Form der Imperfektion wird jeweils
durch eine Klasse modelliert: die Klassen UncertainStereotype, FuzzyStereotype und
ImpreciseStereotype erben von der Klasse ImperfectionStereotype. Abbildung 5.5
stellt diese Beziehungen graphisch dar.
Abbildung 5.6 zeigt ein Table -Objekt der Relation Verkehrsmeldung, die im Rahmen des OVID-Projekts verwendet werden soll. Die Spalten Start - und Endkilometer sowie Fluss und Störungstyp sind jeweils mit einem Stereotype versehen,
um anzuzeigen, dass die in ihnen abgelegten Daten imperfekt sind. In den angehängten TaggedValues wird auf die jeweiligs anzuwendende Zugehörigkeits- oder
71
5 Common Warehouse Metamodel und Imperfektion
Abbildung 5.6: Beispiel eines imperfekten Table -Objekts
Wahrscheinlichkeitsfunktion verwiesen.
Der Nachteil dieser Methode zur Modellierung von imperfekten Daten liegt auf
der Hand: Die jeweilige Qualität der Imperfektion kann nur in textueller Form
durch die TaggedValues beschrieben werden, eine explizite Modellierung, die auch
eine automatisierte Verarbeitung imperfekter Daten ermöglichen würde, kann mit
diesem Ansatz nicht erreicht werden.
Im folgenden Abschnitt wird daher die Möglichkeit der expliziten Erweiterung
des CWM zur Modellierung von imperfekten Daten untersucht.
5.5.2 Objektorientierte Erweiterung
Erster Schritt in Richtung einer objektorientierten Erweiterung des CWM muss
immer die Spezikation der an die Erweiterung gestellten Anforderungen sein. Die
Modellierung imperfekter Daten soll im gesamten Warehouse-Prozess möglich sein,
da die Imperfektion durchgängig von der Erhebung der Daten bis zur analytischen Auswertung durch OLAP-Tools erhalten bleiben soll. Würde man wie in
[Haa04] als Ansatzpunkt das Relational -Paket wählen, so könnte man Imperfektion
nur im Umfeld relationaler Datenquellen beschreiben. Informationen sind jedoch
imperfekt unabhängig davon, durch welches Datenmodell sie beschrieben werden
[Hil05]. Sucht man nun ausgehend von der Resource -Schicht des CWM nach dem
nächsthöheren Ansatzpunkt zur Beschreibung von Imperfektion, so stöÿt man
durchgängig auf die (Meta-)Klasse Attribute aus dem Core -Paket, welches in Abbildung 5.7 dargestellt ist.
Dies hängt auch mit der systematischen Konstruktion der Resource -Schicht zu-
72
5.5 Erweiterung des CWM zur Modellierung imperfekter Daten
Abbildung 5.7: Ausschnitt des Core -Pakets
sammen: Alle grundlegenden Klassen eines Pakets auf dieser Ebene haben eine
korresondierende Klasse in einem anderen Paket.6
Eine spezielle Anforderung bei der Modellierung von Unsicherheit ist, dass Unsicherheit auf unterschiedlichen Granularitätsstufen auftreten kann. Beispielsweise
kann im Fall einer Staumeldung der Meldung pauschal misstraut werden oder nur
einer einzelnen in ihr enthaltenen Information wie etwa der Staulänge.7 Daher muss
eine objekt-orientierte Erweiterung ausreichend hoch in der Vererbungshierarchie
des Core -Pakets ansetzen, um insbesondere unsichere Daten auf allen Granularitätsstufen der Informationsmodellierung beschreiben zu können. In [Hil05] wird
zunächst die Classier -Klasse des Core -Pakets als höchster Ansatzpunkt für die
Modellierung von Unsicherheit verwendet. Damit soll erreicht werden, dass auch
ganze Tabellen als unsicher eingestuft werden können. Es ist jedoch fraglich, ob dieser Fall in der Realität überhaupt vorkommt, da eine relationale Tabelle lediglich
ein Konstrukt zur Datenhaltung ist und keine Entsprechung in der realen Welt
ndet. Weiter wird die Klasse Datatype des Core -Pakets erweitert, um spezielle
Datentypen zu spezizieren, welche die Speicherung imperfekter Daten ermöglicht.
Beispielsweise korrespondiert die Klasse Table des Relational -Pakets mit der Klasse Dimension
des Multidimensional -Pakets
7
Übertragen auf das relationale Modell bedeutet dies, dass sowohl eine ganzes Tupel als auch
einzelne Attributwerte einer Relation als unsicher angesehen werden können.
6
73
5 Common Warehouse Metamodel und Imperfektion
Abbildung 5.8: Erweiterung des Core-Paketes um Möglichkeiten der Modellierung
von Imperfektion
Es ist beispielsweise denkbar, ungenau Daten gleich in Form von Intervallen zu
speichern. Obgleich dieser Ansatz natürlich sehr interessant ist, unterscheidet er
sich grundsätzlich von dem in [Haa04] dargestellten Vorgehen, wo Daten in herkömmlicher Form abgespeichert werden und gleichsam nachträglich einem semantischen Kontext zugeordnet werden. Der jeweilige Ansatz sollte einer einheitlichen
Modellierung zuliebe konsequent verfolgt werden. In dieser Arbeit soll der von
[Haa04] vorgeschlagene Ansatz weitergeführt werden: Ziel dabei ist es, nicht nur
das Relational -Paket, sondern alle Pakete der Resource -Schicht durch Imperfektion
erweiterbar zu machen. Als allgemeiner Anknüpfungspunkt kommt die Attribute Klasse in Betracht. Im Falle der Unsicherheit beispielsweise eines ganzen Tupels
kann dies durch ein zusätzliches Attribut modelliert werden.
Wie in [Haa04] vorgestellt, kann die Konkretisierung der verschiedenen Formen
der Imperfektion durch die Assoziierung der entsprechenden Klassen (beispielsweise der Column -Klasse im relationalen Datenmodell) mit Funktionen erfolgen. Die
verschiedenen zur Beschreibung imperfekter Daten geeigneten Funktionen müssen
ebenfalls in Form von Klassen modelliert und dem CWM hinzugefügt werden. Es
ergibt sich wiederum eine Hierarchie, die als Ursprung die Klasse ModelElement
des Core -Pakets hat.
Durch die Erweiterung der Attribute -Klasse des Core -Pakets und eine entsprechende Assoziierung mit beschreibenden Funktionen könnte Imperfektion in die
Modellierung aller relevanten Konzepte des CWM miteinbezogen werden. Abbildung 5.8 fasst diese Ideen zusammen. Natürlich müsste die Assoziation DenedByFunction noch mit geeigneten Restriktionen versehen werden, die sicherstellen,
dass beispielsweise ein UncertainAttribute nur durch eine ProbabilityFunction be-
74
5.6 Fazit
schrieben werden kann.
5.6 Fazit
Der Nutzen einer semantischen Integration der Information Supply Chain ist durch
obige Ausführungen umrissen worden. Die OMG propagiert mit dem Common
Warehouse Metamodel und entsprechenden Vorschlägen für die Systemarchitektur
einen potentiell mächtigen Standard für das Metadatenmanagement. Aus obigen
Ausführungen lassen sich jedoch bereits einige Schwachstellen des Entwurfs erkennen. So legt die OMG explizit wert auf die Vollständigkeit der Modellierung. Dieses
Kriterium erscheint deshalb so wichtig, da ein einheitlicher Standard zum Metadatenaustausch erst dann interessant wird, wenn auch möglichst viele Konzepte
durch diesen Standard beschrieben werden können. Eine vollständige und ausgewogene Berücksichtigung aller Konzepte im Data Warehousing ist jedoch äuÿerst
schwierig, da die Anforderungen in diesem Bereich sehr stark variieren und sich
ständig weiterentwickeln. Von Experten wird beispielsweise bemängelt, dass wichtige Bereiche wie Berechtigungen, Semantik von Inhalten, Qualitätsmanagement, Berichtswesen und Unterstützung organisatorischer Prozesse ausspart werden. Auch
im Hinblick auf das Kriterium der Erweiterbarkeit ergeben sich Probleme. Wie
bereits dargestellt ist der einfache Erweiterungsmechanismus basierend auf Stereotypes und TaggedValues nur sehr eingeschränkt einsetzbar. Die objekt-orientierte
Erweiterung dagegen muss von allen an dem entsprechenden Metadatenaustausch
beteiligten Anwendungen implementiert werden. Dies ist insbesondere in solchen
Fällen problematisch, in denen eine bestimmte Semantik den gesamten WarehouseProzess hindurch erhalten bleiben soll, wie beispielsweise die Imperfektion von
Daten. Die im Rahmen des OVID-Projektes der Universität Karlsruhe (TH) thematisierte Imperfektion von Daten ist durch beide Erweiterungsmöglichkeiten des
CWM darstellbar, allerdings erönet lediglich die objekt-orientierte Erweiterung
die Möglichkeit, mit imperfekten Daten zu rechnen, also beispielsweise Aggregationen über Fuzzy-Attributwerte durchzuführen.
75
5 Common Warehouse Metamodel und Imperfektion
76
Wang Lu
6
Fuzzy UML
The UML (Unied Modeling Language) is a set of object-oriented modeling notations and is a standard of the Object Data Management Group (ODMG). It
can be applied in many areas of software engineering and knowledge engineering.
Increasingly, the UML is being applied to data modeling. However, information
in real-world applications is often vague or ambiguous. In this chapter, dierent
levels of fuzziness are introduced into the class of the UML and the corresponding
graphical representations are given. The class diagrams of the UML can hereby
model fuzzy information.
6.1 Introduction
The objective of database design is to capture the essential aspects of some realworld enterprise for which one wishes to construct a database. Figure 6.1 shows a
simplied description of the database design process. Then four major steps are
applied for the database design process, which are the requirements collection &
analysis, conceptual data modeling, logical database model, and physical database
model, respectively [Ma05a].
In the rst step, the database designers collect and analyze the data requirements
from prospective database users.
In the second step, the conceptual data models (e.g., UML) are used to create a
conceptual schema for the database.
In the third step, the logical database model is designed through mapping the
conceptual schema represented by the conceptual data model. The result of this
step is perhaps a relational or object-oriented database model.
Finally, in the fourth step, the physical database model is design.
77
6 Fuzzy UML
Requirements
Collection & Analysis
Conceptual Data
Modeling
Logical Database
Model
Physical Database
Model
Abbildung 6.1: Database Design Process
In real-world applications, information is often imperfect. There have been
some attempts at classifying various possible kinds of imperfect information.
Inconsistency, imprecision, vagueness uncertainty, and ambiguity are ve basic
kinds of imperfect information in database systems.
Inconsistency is a kind of semantic conict when one aspect of the real world
is irreconcilably represented more than once in a database or several dierent
databases. For example, one has married value and single value for Tom's
marital status.
Intuitively, imprecision and vagueness are relevant to the content of an attribute
value, and it means that a choice must be made from a given range of values but
it is not known exactly which one to choose at present. For example, between
20 and 30 years old and young for the attribute Age are imprecise and vague
values, respectively.
Uncertainty is related to the degree of truth of its attribute value, and it means
that one can apportion some, but not all, of our belief to a given value or a
group of values. For example, the sentence that I am 95 percent sure that Tom is
married represents information uncertainty.
The ambiguity means that some elements of the model lack complete semantics,
leading to several possible interpretations.
Vagueness and uncertainty are generally modeled with fuzzy sets and possibility
theory. Many of the existing approaches dealing with imprecision and uncertainty
are based on the theory of fuzzy sets.
The remainder of this chapter is organized as follows. The second section gives the
basic knowledge about fuzzy data and semantic measure as well as knowledge of
78
6.2 Basic knowledge
„Tall Person“
1.0
0.5
1.0
1.5
2.0
Dimension
in m
Abbildung 6.2: Fuzzy set to concept tall person
the UML class model. The fuzzy objects, fuzzy classes and fuzzy object-class relationships are described in the third section. The fuzzy extension to class model in
the UML is presented in the fourth section. The last section concludes this chapter.
6.2 Basic knowledge
6.2.1 Fuzzy Set and Possibility Distribution
The concept of fuzzy sets was originally introduced by Zadeh. Let U be a universe
of discourse. A fuzzy value on U can be characterised by a fuzzy set F in U . A
membership function µF : U → [0, 1] is dened for the fuzzy set F , where µF (u),
for each u ∈ U , denotes the degree of membership of u in the fuzzy set F . Thus,
the fuzzy set F is described as follows [Ma05b]:
F = {µ(u1 )/u1 , µ(u2 )/u2 , . . . , µ(un )/un }
where the pair µ(ui )/ui represents the value ui and its membership degree µ(ui ).
The membership function µF (u) can be interpreted as a measure of the possibility
that the value of variable X is u. A fuzzy set is equivalently represented by its
associated possibility distribution πX :
π = {πX (u1 )/u1 , πX (u2 )/u2 , . . . , πX (un )/un }
Here, πX (ui ), ui ∈ U , denotes the possibility that ui is true. Let πX and F be
the possibility distribution representation and the fuzzy set representation for a
fuzzy value, respectively. It is apparent that πX = F is true.
Beispiel 6.2.1 In the case of the "tall personït concerns a vague concept. This
concept can be elegantly represented by means of a Fuzzy set, as Figure 6.2 shows.
Semantic measure of fuzzy data [MZM04]
Let U = {ui , u2 , . . . , un { be the
universe of discourse. Let πA and πB be two fuzzy data on U based on possibility
79
6 Fuzzy UML
Class name
Attributes
Operations
Abbildung 6.3: The class icon
distribution and πA (ui ), ui ∈ U , denote the possibility that ui is true. Let Res be
a resemblance relation on domain U , α for 0 ≤ α ≤ 1 be a threshold corresponding
to Res. SID(πA , πB ) is then dened by
, n
n
X
X
SID(πA , πB ) =
min (πB (ui ), πA (ui ))
πB (ui ).
i=1
ui ,uj ∈D
i=1
The notion of the semantic equivalence degree of attribute values can by extended to the semantic equivalence degree of tuples. Let ti = hai1 , ai2 , . . . , ain i and
tj = haj1 , aj2 , . . . , ajn i be two tuples in fuzzy relational instance r over schema
R(A1 , A2 , . . . , An ). The semantic equivalence degree of tuples ti and tj is denoted
SE(ti , tj ) = min{SE(ti [A1 ], tj [A1 ]), SE(ti [A2 ], tj [A2 ]), . . . , SE(ti [An ], tj [An ])}.
6.2.2 UML Class Model
UML provides a collection of models to capture the many aspects of a software
system. From the database modeling point of view, the most relevant model is
the class model. The building blocks in this class model are those of classes and
relationships. We briey review these building blocks.
Classes
Being the descriptor for a set of objects with similar structure, behavior,
and relationships, a class represents a concept within the system being modeled.
Classes have data structure and behavior and relationships to other elements. Figure 6.3 shows a class.
Relationships
Another main structural component in the class diagram of the
UML is relationships for the representation of relationship between classes or class
instances. UML supports a variety of relationships:
1. Aggregation and composition: An aggregation captures a whole-part relationship between an aggregate, a class that represent the whole, and a constituent
part.
Figure 6.4 shows an aggregation relationship.
80
6.2 Basic knowledge
Car
Engine
Interior
Chassis
Abbildung 6.4: Simple aggregation relationship
Vehicle
Car
Truck
Abbildung 6.5: Simple generalization relationship
2. Generalization: Generalization is used to dene a relationship between classes
to build taxonomy of classes: one class is a more general description of a set
of other classes.
Figure 6.5 shows a generalization relationship.
3. Association: Associations are relationships that describe connections among
class instances. A role may be assigned to each class taking part in an association, making the association a directed link.
Figure 6.6 shows an association relationship.
4. Dependency: A dependency indicates a semantic relationship between two
installing
CD Player
Car
Abbildung 6.6: Simple association relationship
81
6 Fuzzy UML
Dependent
Employee
Abbildung 6.7: Simple dependency relationship
classes. It indicates a situation in which a change to the target class may
require a change to the source class in the dependency.
Figure 6.7 shows a dependency relationship.
6.3 Fuzzy objects and classes
6.3.1 Fuzzy objects
An objects is fuzzy because of a lack of information. For example, an object representing a part in preliminary design for certain will also be made of stainless steel,
moulded steel, or alloy steel (each of them may be connected with a possibility, say,
0.7, 0.5 and 0.9, respectively). Formally, objects that have at least one attribute
whose value is a fuzzy set are fuzzy objects.
6.3.2 Fuzzy classes
Theoretically, a class can be considered form two dierent viewpoints:
1. an extensional class, where the class is dened by the list of its object instances, and
2. an intensional class, where the class is dened by a set of attributes and their
admissible values.
In addition, a subclass dened from its superclass by means of inheritance mechanism in the OODB can by seen as the special case of (b) above.
Therefore, a class is fuzzy because of the following several reasons. First, some
objects are fuzzy ones, which have similar properties. A class dened by these
objects may be fuzzy. These objects belong to the class with membership degree
of [0, 1]. Second, when a class is intensionally dened, the domain of an attribute
may be fuzzy and a fuzzy class is formed. Third, the subclass produced by a fuzzy
class by means of specialization and the superclass produced by some classes (in
which there is at least one class who is fuzzy) by means of generalization are also
fuzzy.
82
6.3 Fuzzy objects and classes
6.3.3 Fuzzy object-class relationships
In the fuzzy OODB, the following four situations can by distinguished for objectclass relationships.
1. Crisp class and crisp object : the object belongs or not to the class certainly.
2. Crisp class and fuzzy object : the object may be related to the class with the
special degree in [0, 1].
3. Fuzzy class and crisp object : the object may belong to the class with the
membership degree in [0, 1].
4. Fuzzy class and fuzzy object : the object belongs to the class with the membership degree in [0, 1].
The object-class relationships in (b)(d) above are called fuzzy object-class relationships. In fact, the situation in (a) can be seen as the special case of fuzzy
object-class relationships, where the membership degree of the object to the class
is one.
In order to calculate the membership degree of an object to the class in a fuzzy
object-class relationship, it is necessary to evaluate the degrees that the attribute
domains of the class include the attribute values of the object. The attributes play
dierent role in the denition and identication of a class, therefore, a weight w
is assigned to each attribute of the class according to its importance by designer.
Then the membership degree of an object to the class in a fuzzy object-class relationship should be calculated using the inclusion degree of object values with
respect to the class domains and the weight of attributes.
Let C be a class with attributes {A1 , A2 , . . . , An }, o be an object on attribute set
{A1 , A2 , . . . , An }, and let o(Ai ) denote the attribute value of o on Ai (1 ≤ i ≤ n).
In C , each attribute Ai is denoted ID(dom(Ai ), o(Ai )). In the following, we investigate the evaluation of ID(dom(Ai ), o(Ai )).
Let f dom(Ai ) = {f1 , f2 , . . . , fm }, where fj (1 ≤ j ≤ m) is a fuzzy value, and
cdom(Ai ) = {c1 , c2 , . . . , ck }, where cl (1 ≤ l ≤ k) is a crisp value. Then
ID(dom(Ai ), o(Ai )) = max(ID(cdom(Ai ), o(Ai )), ID(f dom(Ai ), o(Ai )))
= max(SID({1.0/ci , 1.0/c2 , . . . , 1.0/ck }, o(Ai )),
max(SID(fj , o(Ai )))),
j
Now,we dene the formula to calculate the membership degree of the object o to
the class C as follows, where w(Ai (C)) denotes the weight of attribute Ai to class
C:
Pn
ID(dom(Ai ), o(Ai )) × w(Ai (C))
Pn
µC (o) = i=1
(6.1)
i=1 w(Ai (C))
83
6 Fuzzy UML
Ph.D. student
ID
Name
FUZZY Age
Office WITH 0.8 DEGREE
µ
Abbildung 6.8: A fuzzy class
6.4 Fuzzy Modeling of Fuzzy Data
We dene three levels of fuzziness:
1. Fuzziness in the extent to which the class belongs in the data model as well
as fuzziness on the content (in terms of attributes) of the class
2. Fuzziness related to whether some instances are instances of a class
3. The third level of fuzziness is on attribute values of the instances of the
class; an attribute in a class denes a value domain, and when this domain
is a fuzzy subset or a set of fuzzy subset, the fuzziness of an attribute value
appears
6.4.1 Fuzzy Class
In order to model the rst level of fuzziness, i.e., an attribute or a class with degree
of membership, the attribute or class name should be followed by a pair of words
WITH mem DEGREE, where 0 ≤ mem ≤ 1. In order to model the third level of
fuzziness, a keyword FUZZY is placed in front of the attribute. In the second level
of fuzziness, an additional attribute (µ) is introduced into the class to represent
instance membership degree to the class, with an attribute domain that is [0, 1]. In
order to dierentiate the class with the second level of fuzziness, we use a dashedoutline rectangle to denote such class. Figure 6.8 shows a fuzzy class Ph.D.student.
6.4.2 Fuzzy Generalization
A new class, called subclass, is produced form another class, called superclass.
• Based on the extensional viewpoint of class :
We can assess fuzzy subclass-superclass relationship by utilizing the inclusion
degree of objects to the class.
Because a subclass is the specialization of the superclass, any one object belonging to the subclass must belong to the superclass. This characteristic can
84
6.4 Fuzzy Modeling of Fuzzy Data
by used to determine if two classes have a subclass-superclass relationship.
A subclass produced from a fuzzy superclass must be fuzzy, the subclasssuperclass relationship is fuzzy too. In other words, a class is a subclass of
another class with membership degree of [0, 1] at this moment. Correspondingly, we have the following method for determining a subclass-superclass
relationship:
We assume that the classes can only have the second level of fuzziness.
1. For an (fuzzy) object, if the membership degree that it belongs to
the subclass is less than or equal to the membership degree, then
it belongs to the superclass.
2. The membership degree that it belongs to the subclass is greater
than or equal to the given threshold.
Formally, let A and B be (fuzzy) classes and β be a given threshold. We
say B is a subclass of A if
(∀e)(β ≤ µB (e) ≤ µA (e))
The membership degree that is a B subclass of A should be
minµB (e)≥β (µB (e)). Here, e is the object instance of A and B in the
universe of discourse, and µA (e) and µB (e) are membership degrees of
e to A and B , respectively.
We consider the situation that classes A or B are the classes with membership degree, namely, with the rst level of fuzziness.
A WITH degree_A DEGREE
B WITH degree_B DEGREE
Then B is a subclass of A if
(∀e)(β ≤ µB (e) ≤ µA (e)) ∧ (β ≤ degree_B ≤ degree_A)
The membership degrees of A and B must be greater than or equal to
the given threshold, and the membership degree of A must be greater
than or equal to the membership degree of B .
Consider a fuzzy superclass A and its fuzzy subclasses B 1, B 2,
. . . , B n with instance membership degrees µA , µB1 , µB2 , . . . ,
and µBn , respectively, which may have the degrees of membership
degree_A, degree_B1, degree_B2, . . . , and degree_Bn, respectively.
Then the following relationship is true:
(∀e)(max(µB1 (e), µB2 (e), . . . , µBn (e)) ≤ µA (e)) ∧ (max(degree_B1,
degree_B2, . . . , degree_Bn) ≤ degree_A)
85
6 Fuzzy UML
Youth
Young Student
Young Faculty
Abbildung 6.9: A fuzzy generalization relationship
• Based on the intensional viewpoint of class :
We can use the inclusion degree of a class with respect to another class to
determine the relationships between fuzzy subclass and superclass.
We assume that classes A and B can only have the second level of
fuzziness.
Formally, let A and B be (fuzzy) classes and the degree that B is the
subclass of A be denoted by µ(A, B). For a given threshold β , we say
B is a subclass of A if
µ(A, B) ≥ β
We consider the situation that classes A or B are the classes with membership degree, namely, with the rst level of fuzziness:
A WITH degree_A DEGREE
B WITH degree_B DEGREE
Then B is a subclass of A if
(µ(A, B) ≥ β) ∧ (β ≤ degree_B ≤ degree_A)
The inclusion degree of a (fuzzy) subclass with respect to the (fuzzy) superclass can be calculated according to the inclusion degree of the attribute
domains of the subclass with respect to the attribute domains of the superclass as well as the weight of attributes(s.formel 6.1 on page 83).
In order to represent a fuzzy generalization relation, a dashed peculiar triangular
arrowhead is applied. Figure 6.9 shows a fuzzy generalization relationship. Classes
young Student and Young Faculty are all classes with the second level of fuzziness.
These classes may have some instances that belong to the classes with membership
degree. These two classes can be generalized into class Youth, a class with the
second level of fuzziness.
86
6.4 Fuzzy Modeling of Fuzzy Data
6.4.3 Fuzzy Aggregation
An aggregation captures a whole-part relationship between an aggregate and a
constituent part.
• Based on the extensional viewpoint of class : Every instance of an aggregate
can be projected into a set of instances of constituent parts. Let A be an
aggregation of constituent parts B1, B2, . . .,and Bn. For e ∈ A, the projection of e to Bi is denoted by e ↓Bi . Then we have (e ↓B1 ) ∈ B1, (e ↓B2 ) ∈
B2, . . . , (e ↓Bn ) ∈ Bn.
A class aggregated form fuzzy constituent parts must be fuzzy, the aggregation is fuzzy too. At this point, a class is an aggregation of constituent parts
with membership degree of [0, 1]. Correspondingly, we have the following
method for determining a fuzzy aggregation relationship:
We assume that the classes can only have the second level of fuzziness.
1. For any (fuzzy) object, if the membership degree to which it belongs
to the aggregate is less than or equal to the membership degree to
which its projection to each constituent part belongs to the corresponding constituent part.
2. The membership degree to which it belongs to the aggregate is
greater than or equal to the given threshold.
The aggregate is then an aggregation of the constituent parts with the
membership degree, which is the minimum in the membership degrees to
which the projections of these objects to these constituent parts belong
to the corresponding constituent parts.
Let A be a fuzzy aggregation of fuzzy class sets B1, B2, . . . , and Bn,
with instance membership degrees that are µA , µB1 , µB2 , . . . , and µBn ,
respectively. Let β be a given threshold. Then,
(∀e)(e ∈ A∧β ≤ µA (e) ≤ min(µB1 (e ↓B1 ), µB2 (e ↓B2 ), . . . , µBn (e ↓Bn )))
The membership degree that A is an aggregation of class sets
B1, B2, . . . , and Bn should be minµBi (e↓Bi )≥β (µBi (e ↓Bi ))(1 ≤ i ≤ n).
Here, e is object instance of A.
We consider the rst level of fuzziness in the classes A, B1, B2, . . . , and
Bn, namely,they are the fuzzy classes with membership degrees.
A WITH degree_A DEGREE,
B1 WITH degree_B1 DEGREE,
B2 WITH degree_B2 DEGREE,
......
Bn WITH degree_Bn DEGREE.
87
6 Fuzzy UML
Then A is an aggregate of B1, B2, . . . , and Bn if
(∀e)(e ∈ A ∧ β ≤ µA (e) ≤ min(µB1 (e ↓B1 ), µB2 (e ↓B2 ), . . . , µBn (e ↓Bn )) ∧
degree_A ≤ min(degree_B1, degree_B2, . . . , degree_Bn)).
• Based on the intensional viewpoint of class :
Let A be a fuzzy aggregation of fuzzy class sets B1, B2, . . . , and Bn, and β
be a given threshold. Also let the projection of A to Bi be denoted by A ↓Bi .
Then,
We assume that the classes A, B1, B2, . . . , and Bn can only have the
second level of fuzziness.
min(µ(B1, A ↓B1 ), µ(B2, A ↓B2 ), . . . , µ(Bn, A ↓Bn )) ≥ β
Here µ(Bi, A ↓Bi )(1 ≤ i ≤ n) is the degree to which Bi semantically includes A ↓Bi . The membership degree to which A is an aggregation of B1, B2, . . . , and Bn is min(µ(B1, A ↓B1 ), µ(B2, A ↓B2
), . . . , µ(Bn, A ↓Bn )).
We consider the rst level of fuzziness in the classes A, B1, B2, . . . , and
Bn, namely, they are the fuzzy classes with membership degrees.
A WITH degree_A DEGREE,
B1 WITH degree_B1 DEGREE,
B2 WITH degree_B2 DEGREE,
......
Bn WITH degree_Bn DEGREE.
Then A is an aggregate of B1, B2, . . . , and Bn if
min(µ(B1, A ↓B1 ), µ(B2, A ↓B2 ), . . . , µ(Bn, A ↓Bn )) ≥ β ∧
degree_A ≤ min(degree_B1, degree_B2, . . . , degree_Bn))
A dashed open diamond is used to denote a fuzzy aggregate relationship. A fuzzy
aggregation relationship is shown in Figure 6.10. A car is aggregated by engine,
interior and chassis. The engine is old, and we have a fuzzy class Old Engine with
the second level of fuzziness. Class Old Car aggregated by classes interior and
chassis and fuzzy class old engine is a fuzzy one with the second level of fuzziness.
6.4.4 Fuzzy Association
Two levels of fuzziness can be identied in the association relationship. The rst
level of fuzziness means that an association relationship fuzzily exists in two associated classes, namely, this association relationship occurs with a degree of possibility.
88
6.4 Fuzzy Modeling of Fuzzy Data
Old Car
Old Engine
Interior
Chassis
Abbildung 6.10: A fuzzy aggregation relationship
CD Player
installing WITH 0.8 DEGREE
Car
(a)
CD Player
installing
Car
(b)
CD Player
installing WITH 0.8 DEGREE
Car
(C)
Abbildung 6.11: Fuzzy association relationships
Also, it is possible that it is unknown for certain if two class instances respectively belonging to the associated classes have the given association relationship,
although this association relationship must occur in these two classes. This is the
second level of fuzziness in the association relationship and is caused because an
instance belongs to a given class with membership degree. It is possible that the
two levels of fuzziness mentioned above may occur in an association relationship
simultaneously.
We can place a pair of words WITH mem DEGREE (0 ≤ mem ≤ 1) after the
role name of an association relationship to represent the rst level of fuzziness in
89
6 Fuzzy UML
the association relationship. We use a double line with an arrowhead to denote
the second level of fuzziness in the association relationship. Figure 6.11 shows two
levels of fuzziness in fuzzy association relationships. In part (a), it is uncertain if
the CD player is installed in the car, and the possibility is 0.8. In part (b), it is
certain that the CD player is installed in the car, and the possibility is 1.0. But
at the level of instances, there exists the possibility that the instances of classes
CD Player and Car may or may not have the association relationship installing.
In part (c), two kinds of fuzzy association relationships in parts (a) and (b) arise
simultaneously.
It has been shown above that three levels of fuzziness can occur in classes.
• Classes with the second level of fuzziness generally result in the second level
of fuzziness in the association, if this association denitely exists.
Let A and B be two classes with the second level of fuzziness. Then, the
instance e of A is one with membership degrees µA (e), and the instance f
of B is one with membership degrees µB (f ). Assume that the association
relationship between A and B , denoted ass(A, B), is one without the rst
level of fuzziness. It is clear that the association relationship between e and f ,
denoted ass(e, f ), is one with the second level of fuzziness, the membership
degree can be calculated by the following:
µ(ass(e, f )) = min(µA (e), µB (f ))
• The classes with the rst level of fuzziness generally result in the rst level
of fuzziness of the association, if this association is not indicated explicitly.
Let A and B be two classes only with the rst level of fuzziness, denoted A
WITH degree_A DEGREE and B WITH degree_B DEGREE, respectively.
Then the association relationship between A and B , denoted ass(A, B), is
one with the rst level of fuzziness, namely, ass(A, B) WITH degree_ass
DEGREE. For the instance e of A and the instance f of B , in which µA (e) =
1.0 and µB (f ) = 1.0, we have:
µ(ass(e, f )) = degree_ass = min(degree_A, degree_B)
• Let us focus on a situation in which the classes are the rst level and the
second level of fuzziness.
Let A and B be two classes with the rst level of fuzziness, denoted A
WITH degree_A DEGREE and B WITH degree_B DEGREE, respectively.
Let ass(A, B) be the association relationship with the rst level of fuzziness
between A and B , which is explicitly indicated with WITH degree_ass DEGREE. Also, let the instance e of A with membership degree µA (e),and the
instance f of B be with membership degrees µB (f ). Then we have:
µ(ass(e, f )) = min(µA (e), µB (f ), degree_A, degree_B, degree_ass)
90
6.5 Conclusions
Dependent WITH 0.5 DEGREE
Employee WITH 0.5 DEGREE
Abbildung 6.12: Fuzzy dependency relationship
6.4.5 Fuzzy Dependency
The dependency relationship is only related to the classes and does not require
a set of instances for its meaning. Therefore, the second-level fuzziness and the
third-level fuzziness in class do not aect the dependency relationship.
Fuzzy dependency relationship is a dependency relationship with a degree of possibility. Assume that the source class is fuzzy, with the rst level of fuzziness. The
target class must be fuzzy, with the rst level of fuzziness. The degrees of possibility
that the target class is decided by the source class are the same as the membership
degrees of source classes. For source class Employee W IT H0.85DEGREE , for
example in gure 6.12, the target class Employee Dependent should be Employee
Dependent W IT H0.85DEGREE . The dependency relationship between Employee and Employee Dependent should be fuzzy, with an 0.85 degree of possibility.
6.5 Conclusions
We present a fuzzy extended UML to cope with fuzzy as well as complex objects in
the real world at a conceptual level. Dierent levels of fuzziness are introduced into
the class diagram of the UML, and the corresponding graphical representations are
developed. In Figure 6.13, we give a simple fuzzy UML data model utilizing some
notations introduced in this chapter. The gure 6.14 shows a simple example for
the denition of a fuzzy class.
91
6 Fuzzy UML
Dependent
Employee
Middle
Employee
Old
Employee
Young
Employee
Car
using
Old Car
New Car
Liking WITH 0.9 DEGREE
Interior
Engine
ID
ID
Turbo
Dashboard
FUZZY Size
Seat
Abbildung 6.13: A fuzzy UML data model
92
Chassis
ID
6.5 Conclusions
CLASS Young Students WITH DEGREE OF 1.0
INHERITS Students WITH DEGREE OF 1.0
ATTRIBUTES
ID: TYPE OF string WITH DEGREE OF 1.0
Name: TYPE OF string WITH DEGREE OF 1.0
Age: FUZZY DOMAIN {very Young, young, old, very old}: TYPE OF integer
WITH DEGREE
OF 1.0
Height: DOMAIN [60, 210]: TYPE OF real WITH DEGREE OF 1.0
Membership_Attribute name
WEIGHT
w(ID) = 0.1
w(Name) = 0.1
w(Age) = 0.9
w(Height) = 0.2
METHODS
...
END
Abbildung 6.14: The denition of a fuzzy class
93
6 Fuzzy UML
94
Jens Kübler
7
Fortgeschrittene
OLAP-Analysemodelle
In dieser Seminararbeit werden die von Codd spezizierten OLAP Datenmodellklassen für unterschiedliche Analysebedürfnisse vorgestellt und mit formalen
Grundlagen in Verbindung gebracht. Hierzu werden Systeme und deren Modellierung herangezogen, um abzugrenzen, welches Informationsbedürfnis der Analyst
befriedigen will. Basierend auf diesen Denitionen wird eine marktübliche Datenbank analysiert und die vorhandenen Operationen den einzelnen Klassen zugeordnet. Abschlieÿend wird eine Bewertung der Operationen vorgenommen, inwiefern
diese die vorangegangenen Denitionen erfüllen.
7.1 Einleitung
Nachdem in den vergangenen Dekaden die performante Speicherung und Abfrage
von Daten in der Forschung groÿe Beachtung fand, entstand darauf aufbauend
der Bedarf, die kumulierten Daten nicht nur für den aktuellen Betrieb zu verwenden, sondern die Datenbestände temporär zu analysieren. Die Begrie Online
Transactional Processing (OLTP) und Online Analytical Processing (OLAP)
identizieren diese Themenbereiche, deren Datentypen, Algebren und respektive
Anfragesprachen durch so genannte Datenmodelle repräsentiert werden.
So hat sich für OLTP überwiegend ein relationales also tabellenbasiertes Modell etabliert, während sich für OLAP auf logischer Datenspeicherebene ein so
genannter Data Cube durchgesetzt hat, der Daten in beliebig vielen endlichen Dimensionen speichert.
Aufgrund des inhärenten Datenumfangs der Data Cubes, ist der Bedarf entstanden, nicht nur Einblick in diese Cubes zu gewinnen, sondern automatisch Informa-
95
7 Fortgeschrittene OLAP-Analysemodelle
tionen aus dem Datenbestand zu extrahieren und für den Benutzer aufzubereiten.
Dieser Vorgang wird als Data Mining bezeichnet, der Ähnlichkeiten mit dem Forschungsgebiet des maschinellen Lernens aufweist, jedoch eine andere Zielsetzung
hat. Aufgrund der automatischen Synthetisierung von Daten zu Informationen
lässt sich Data Mining klar zu OLAP abgrenzen, da bei OLAP bereits Basisinformationen vorhanden sind, die der Analytiker konkretisieren will, während bei
Data Mining keine Informationen, sondern lediglich Daten als Basis vorliegen.
Nachfolgend wird darauf eingegangen, welche Basisinformationen dem Analytiker
bereits vorliegen und welche Informationen er zu extrahieren wünscht.
Die folgende Ausarbeitung beschäftigt sich in Kapitel 7.2 mit der formalen Modellierung von Systemen, die hilft, die in Kapitel 7.3 vorgestellten Analysemodelle,
zu dierenzieren. Weiterhin werden in diesem Kapitel Datenmodelle kurz eingeführt und deren Komponenten erläutert. Kapitel 7.3 stellt die Codd'schen Datenmodellklassen vor und erläutert die unterschiedlichen Anforderungen bezüglich
möglicher Analysen. In Kapitel 7.4 wird ein aktuelles Datenbanksystem hinsichtlich der vorgestellten Datenmodellklassen analysiert. Abschlieÿend wird in Kapitel
7.5 eine Bewertung der vorgestellten Implementierung bezüglich der Denitionen
eingegangen.
7.2 Datenmodelle und Modellierung von Systemen
Die nach [CCS] spezizierten Datenmodellklassen haben keine formale Grundlage,
weshalb im folgenden erst auf Systeme und dann auf Datenmodelle eingegangen
wird. Die folgende Denitionen bezüglich Systemen sind aus [Han05] entnommen.
7.2.1 Systemmodelle
Ein System besteht aus einer Eingabe, einem Modell und einer Ausgabe. Die Eingabe uk ist im Allgemeinen mehrdimensional, wobei k der Zeitpunkt der Eingabe
ist und im Kontext von Datenbanken diskret ist. Das Modell besteht aus der Systemgleichung,
xk = ak (xk−1 , uk , ωk )
(7.1)
die den aktuellen Zustand des Systems aus den vorangegangenen Zustand xk−1 ,
den aktuellen Eingaben uk und den Systemstörungen ωk berechnet. Ist der Zustand eines Systems von auÿen nicht zugänglich, wird eine Messung einer Gröÿe
durchgeführt, die im Allgemeinen nichtlinear von dem Systemzustand abhängt. Die
Messung ist durch
yk = hk (xk , vk )
(7.2)
gegeben, wobei yk das Ergebnis der Messung, xk den aktuellen Systemzustand und
vk die Messstörung beschreibt . Ein Schätzer erhält als Eingaben uk und yk und
rekonstruiert aus diesen den geschätzten Systemzustand xˆk , wobei die Schätzung
sich allgemein nicht auf zukünftige Zustände xk+t , t > 0 beschränkt, sondern auch
vergangene Zustände xk−t , t > 0 als Schätzergebnis haben kann.
96
7.3 Klassikation nach Codd
Von dieser allgemeinen Denition lassen sich einige Spezialfälle ableiten. Die
funktionale Abhängigkeit kann generell in lineare und nicht-lineare Abhängigkeiten unterteilt werden, von denen ein groÿer Teil in Tabelle 7.1 zu nden ist. Des
weiteren kann die Systemgleichung unabhängig von dem letzten Systemzustand
sein wie auch Beispiel 7.3.3 illustriert.
ak (xk−1 , uk , ωk ) = ak (uk , ωk ).
(7.3)
Dies ist als statisches System deniert im Gegensatz zu dynamischen Systemen, bei
denen der aktuelle Systemzustand xk von vergangenen Zuständen xk−t , t > 0 abhängt. Weitere mögliche Spezialfälle sind beispielsweise das Fehlen von Störungen,
die ebenfalls in Beispiel 7.3.3 dargestellt wird.
7.2.2 Datenmodelle
Datenmodelle bestehen aus Datentypen und Operationen. Die Operationen werden über die Datentypen ausgeführt. Datentypen reektieren die mathematische
Struktur eines Datums. Datenoperationen lassen sich zum einen nach ihrem Verwendungszweck in Datendenitionssprache (DDL: CREATE), Datenanfragesprache (DQL: SELECT), Datenmodikationssprache (DML: INSERT, UPDATE, DELETE) und Datenkontrollsprache (DCL: COMMIT, ROLLBACK, SAVEPOINT)
und zum anderen mathematisch in arithmetische, ordnende, mengenbezogene, logische und vergleichende Operationen einteilen. Durch die Denition der einzelnen
Datensprachen ergibt sich die logische Struktur der Speicherung und des Zugris
auf das Datenmodell. Bekannte logische Datenmodelle sind beispielsweise das relationale Datenmodell oder das objektorientierte Datenmodell. Die darunter liegende
physikalische Speicherung der logischen Datenstruktur ist im Rahmen dieser Arbeit
nicht von Bedeutung.
7.3 Klassikation nach Codd
Nach [CCS] wird nach der Synthese von Daten zur Information, die Information
wiederum analysiert. Es existiert eine statische und eine dynamische Analyse, wobei statische Analysen auf historischen Daten beruhen, die keiner Veränderung
bedürfen, während dynamische Analysen Veränderungen und Modellierungen ermöglichen. Grundlage für Analysen in Datenbanken sind nach [CCS] Datenmodelle,
die sich in vier unterschiedliche Kategorien einteilen lassen. Diese Modelle werden
nachfolgend eingehend erläutert und der Bezug zu Systemen wird hergestellt. Weiterhin wird zur Verdeutlichung der Modellklassen eine Zinsrechnung als Beispiel
angeführt. Bei den folgenden Diagrammen wird darauf hingewiesen, dass diese
im Kontext von Datenbanken zu sehen sind, das heiÿt, dass die Eingaben sowie
die Ausgaben, soweit in der jeweiligen Klasse vorhanden, üblicherweise aus einer
Datenbank entstammen oder dort gespeichert werden.
97
7 Fortgeschrittene OLAP-Analysemodelle
7.3.1 Kategorisches Modell
Das kategorische Modell dient der Extraktion eines Datums aus der Datenbank zu
einem bestimmten Zeitpunkt k . Bezogen auf Systemmodelle besteht also das Informationsbedürfnis in Ausgaben yk oder Eingaben uk mit unterschiedlichem aber
festem Zeitschritt k und festen Ein- und Ausgaben. Die Ergebnisse der Anfrage
lassen sich aufgrund ihrer einfachen Dimensionalität als Tabellen darstellen wie die
Abbildung 7.1 verdeutlicht.
Abbildung 7.1: Kategorisches Modell
Anfragen, bei denen einzelnen Eingaben einzelne Ausgaben zugeordnet sind. Für
jedes Tupel der Eingabe, erhält der Analyst ein Tupel der Ausgabe, ohne
Möglichkeit das Systemverhalten aus der Datenbank zu extrahieren.
Beispiel 7.3.1 Gegeben seien als Eingaben uk ein Zinssatz uk1 und ein Startkapital uk2 sowie der resultierende Endbetrag dieser Zinsrechnung als Ausgabe yk . Der
Analytiker ist in diesem Datenmodell nur an den beiden Systemkomponenten Eingaben und Ausgaben interessiert. Eine Denition des zugrunde liegenden Systemmodells ist im Beispiel 7.3.3 zu nden. Die Abfragen gestalten sich in der Form,
das der Analyst einzelne uk und yk aus der Datenbasis extrahiert, was sich im relationalen Modell üblicherweise durch Selektion einzelner Attributwerte realisieren
lässt.
7.3.2 Exegatives Modell
Das exegative Modell erweitert das kategorische Modell um Detaillierungsgrade,
wie in Abbildung 7.2 dargestellt. Diese umfassen einerseits die zeitliche Auösung,
sowie andererseits die Datengranularität. Der Analytiker erhält durch das Datenmodell die Möglichkeit, die Dimensionalität der Eingaben uk sowie der Ausgaben
yk zu erhöhen oder zu reduzieren und dadurch Einsicht in Vorgänge zu erlangen.
Auÿerdem können die zeitlichen Einteilungsschritte k aufgespalten oder zusammengefasst werden, so dass zeitliche Abläufe und Abhängigkeiten in einem höheren
Maÿe nachvollzogen werden können. Dies ist in der Literatur[HK01] unter dem
Begri der Hierarchieebenen bekannt. Operationen, die multidimensionale Sichten aufgrund von einem inhärenten Datenbankschemata dynamisch erzeugen und
98
7.3 Klassikation nach Codd
Hierarchieebenenwechsel durchführen, sind Bestandteil dieses Datenmodells und
erlauben dem Analytiker neue Datenassoziationen zu knüpfen und zu untersuchen.
Diese Operationen grenzen das exegative Modell von dem kategorischen Modell ab.
Die Anfragen zielen dementsprechend auf multidimensionale Mengen von Ein- und
Ausgaben, anstatt auf einzelne Werte im Datenbestand, wie dies im kategorischen
Modell der Fall ist. Die dem System zugrunde liegende Gleichung ak ist in diesem
Datenmodell wie auch im kategorischen Modell nicht Ziel der Anfrage.
Abbildung 7.2: Exegatives Modell
Multidimensionale Abfrage von Ein- und Ausgaben, die auch hier nicht
dargestellte Zerlegungsoperationen und Aggregationen beinhaltet.
Beispiel 7.3.2 Das Beispiel 7.3.1 lässt sich durch marginale Änderungen an die
exegativen Anforderungen anpassen. Die Einführung einer Hierarchieebene für die
Zeit in Form von Tag, Monat und Jahr ermöglicht es dem Analysten zusammen
mit den entsprechenden Hierarchie-Operatoren die Zeitschritte für die Eingaben uk
und die Ausgaben yk dierenziert oder aggregiert darzustellen und so beispielsweise
Einsicht in Zinsveränderungen und resultierende Ergebnisänderungen zu erlangen.
Existieren im Datenbestand mehrere Banken mit unterschiedlichen Zinssätzen, so
lässt sich eine neue Dimension Banken einführen und deren unterschiedliche Zinsentwicklung nachvollziehen. Diese Daten sind im kategorischen Modell nicht gleichzeitig visualisierbar, können im exegativen Modell jedoch dynamisch erzeugt und bei
Bedarf auch materialisiert werden.
7.3.3 Kontemplatives Modell
Das kontemplative Modell besteht aus zwei Kernkomponenten. Dem Analytiker
wird die Möglichkeit gegeben ein System durch Systemgleichungen zu beschreiben
und Modikationen am Eingabevektor vorzunehmen.
Eingabevektor
Dem Eingabevektor können im kontemplativen Modell Varianzen hinzugefügt werden. Für numerische Werte lassen sich beispielsweise Standardabweichungen und
Schwerpunkte denieren, für kategorische Werte kann dies durch Unscharfe Mengen realisiert werden.
99
7 Fortgeschrittene OLAP-Analysemodelle
Systemgleichung
Die Systemfunktion ak (xk−1 , uk , ωk ) unterliegt allgemein zeitlichen Änderungen
(k ) und erzeugt daher zeitlich unterschiedliche Systemverhalten. Weiterhin kann
der Analyst Störungen ωk in der Systemfunktion spezizieren, die beschrieben
durch k ebenfalls zeitlichen Änderungen unterliegen. Die Möglichkeit zur Angabe
multipler Systemfunktionen ak zur Evaluation unterschiedlicher Modelle ist dem
Analysten in diesem Datenmodell zusätzlich gegeben (s. Abbildung 7.3). Der Zustand xk , den die Systemfunktion ak berechnet, ist im Allgemeinen mehrdimensional und beschreibt durch einen Vektor von Zuständen den Systemzustand [Han05].
Ausgaben
Die Ausgaben können Varianzen aufweisen, die durch die Systemgleichungen, den
Eingabevektor oder einer Kombination aus beiden Gröÿen rühren. Im Zentrum der
Analyse stehen somit die Ausgaben, die das gegebene Modell bei gegebenen Eingaben erzeugt. Dieses Datenmodell eignet sich daher insbesondere zur Denition
und Anfrage an Schätzer, die zukünftige Zeitschritte k prädizieren.
Abbildung 7.3: Kontemplatives Modell
Mehrere Modelle werden mit unterschiedlichen Eingaben evaluiert. Die
resultierenden Ergebnisse stehen dem Analysten zur Verfügung.
Beispiel 7.3.3 Das den Beispielen 7.3.1 und 7.3.2 zugrunde liegende Systemmodell ist für feste k durch folgende Systemfunktion (siehe Gleichung 7.1) gegeben.
ak (xk−1 , uk , ωk ) = u1k ∗ u2k + u1k
100
(7.4)
7.3 Klassikation nach Codd
Das Startkapital wird mit dem Zinssatz multipliziert, das Startkapital nochmals addiert und der Endbetrag als neuer Systemzustand xk gesetzt. Da in diesem Beispiel
unterstellt wird, dass das Zinsergebnis nicht von vorangegangen Zinsrechnungen, repräsentiert durch xk−1 , abhängt, kommt dieser Term nicht auf der rechten Seite der
Gleichung vor, da dieser 0 ist. Da weiterhin das System als ungestört angenommen
werden kann, sind die Systemstörungen ωk = 0, wie auch die Messungsstörungen
vk = 0 sind, was in der folgenden Messfunktion (siehe Gleichung 7.1) resultiert.
hk (xk , vk ) = xk
(7.5)
Dadurch entspricht die Ausgabe yk dem Systemzustand xk .
7.3.4 Formalisiertes Modell
Das formalisierte Modell dient der Suche nach möglichen Systemverhalten oder
Eingaben. Die Spezikation nach [CCS] liefert keine exakte Beschreibung dieser
Modellklasse. Die Namensgebung legt nahe, dass das Systemmodell ak formal beschrieben wird und eine mögliche Implementierung gesucht wird. Die Denition
nach [CCS] beschreibt eine Ausgabe y und einen Startpunkt, wodurch der Analytiker Einsicht in Eingaben u und Verhaltensweisen a des Modells gewinnen soll,
jedoch ist der Startpunkt nicht näher deniert. Da sowohl die Eingaben als auch das
Modellverhalten gesucht werden, ist nicht exakt zu schlieÿen, ob der Startpunkt ein
initialer Eingabevektor oder ein initiales Systemverhalten darstellt. Unvollständige
Eingabevektoren oder Systemgleichungen könnten übergeben werden und würden
eine Suche nach möglichen Ergänzungen zur Folge haben, um die spezizierte Ausgabe zu erreichen.
Ohne dass diese explizit in [CCS] genannt werden, erfüllen Regressionsanalysen
[reg] diese Forderungen. Das Ziel von Regressionsanalysen ist es, eine Approximationsfunktion a˜k einer Funktion ak zu nden, die optimal bezüglich eines Gütemaÿes
ist, wobei häug die Methode der kleinsten Quadrate als Gütemaÿ verwendet wird
[reg].
ak = a˜k + R
(7.6)
Die Parameter, die die funktionalen Abhängigkeiten zwischen den Ausgaben yk
und den Eingaben uk konditionieren und als Ergebnis der Regressionsanalyse zur
Verfügung stehen, können als die fehlende Eingaben interpretiert werden, nach
denen der Analytiker unter anderem sucht. Da die funktionalen Abhängigkeiten
der Eingaben und Ausgaben beispielsweise linear, exponentiell, polynominiell oder
logarithmisch sein können, gilt es auch unter der Klasse der möglichen Abhängigkeiten eine optimale Approximation zu nden, was wiederum durch die Minimierung
des Fehlers zu erreichen ist (s. Abbildung 7.4).
Beispiel 7.3.4 Bei der Zinsrechnung aus den Beispielen 7.3.1 und 7.3.2 reduzieren wir den Eingabevektor um den Zinssatz, so dass lediglich unser Startkapital
uk1 und unser Endbetrag yk zur Verfügung stehen. Gegeben seien nun zwei Mengen
101
7 Fortgeschrittene OLAP-Analysemodelle
Abbildung 7.4: Formalisiertes Modell
Vorhandene Ein- und Ausgaben werden verwendet, mehrere Modelle zu
evaluieren aus denen ein optimales Modell bezüglich eines Gütemaÿes hervorgeht.
Ein- und Ausgaben sind beliebig dimensioniert.
von uk1 und yk , die gleich mächtig sind und zwischen denen bei unserem Zinsmodell oensichtlich nur eine Abhängigkeit zwischen gleichen Zeitschritten k besteht.
Wenden wir auf dieses Modell die Regressionsanalyse an, sollte sich im Fall von
gleichbleibenden Zinssätzen eine lineare Approximation der Form
yk = a · uk1 + b
(7.7)
als optimal erweisen, wobei a der fehlende Zinssatz ist und b = 0. . Die Approximation würde sich in diesem Fall auch als tatsächliche Systemfunktion herausstellen,
was einem Fehler in Gleichung 7.6 von R = 0 entspricht.
Das vorangegangene Beispiel oenbart, das aufbauend auf dem gewonnenen Systemverhalten ein Schätzer beschrieben durch die Parameter a und b konstruiert
werden kann, der wiederum im Kontext des kontemplativen Modells zur Anwendung kommt und Ausgaben yk berechnet.
102
7.4 Datenmodelle in der Implementierung
7.4 Datenmodelle in der Implementierung
7.4.1 Vorbemerkungen
Von Codd'schen Modellklassen zur Implementierung
Die Codd'schen Modellklassen sind in der Implementierung nicht exakt voneinander zu trennen, da aus Benutzersicht eine Konvergenz oder sogar eine Inklusion
der Modellklassen zwecks Bedienungskomfort wünschenswert ist. Das Erlernen unterschiedlicher Datentypen mit zugehörigen Anfragesprachen ist für den Benutzer
zu aufwändig, wie auch die Kosten für die Entwicklung klassenkonformer Datenmodelle in keinem Verhältnis stehen.
Implementierungsbeispiel Oracle
Neben Microsoft SQL Server, IBM DB2 oder Informix und Sybase ist Oracle eines der groÿen Enterprise Datenbank Management Systeme (DMBS), das wie die
anderen DBMS mit einem reichhaltigen Angebot an Funktionen aufwartet. Alle
Datenbanksysteme hier bezüglich der implementierten Operationen vorzustellen
übersteigt den Rahmen dieser Ausarbeitung, weshalb lediglich Oracle als Beispielimplementierung nicht zuletzt wegen der umfangreichen einfach zugänglichen Dokumentation näher betrachtet wird. Aufgrund der groÿen Verbreitung des relationalen Modells und produktabhängigen Erweiterungen werden andere Datenmodelle, wie zum Beispiel das objektorientierte, hier nicht nähergehend bezüglich deren
Analyseoperationen betrachtet.
Neben der Datenbank bietet Oracle ein zusätzliches OLAP-Modul, welches auf
der bestehenden Datenbankengine aufsetzt, jedoch zusätzlich ein eigenes Datenmodell implementiert, welches den speziellen Anforderungen für Analysen gerecht
wird. Für die nachfolgenden Abgrenzungen werden soweit nötig nur die Funktionen
der Kern-Datenbankengine nähergehend erläutert, da diese in den Hauptfunktionen quantitativ denen des OLAP-Moduls entsprechen und sich die Komplexität
der Parameter und Optionen nicht so hoch darstellt, wie das im OLAP-Modul
der Fall ist. Lediglich im formalisierten Modell werden Funktionalitäten aus dem
OLAP-Modul vorgestellt, die in der Kerndatenbank nicht zur Verfügung stehen.
Für eine detaillierte Beschreibung des OLAP-Moduls konsultiere man die verschiedenen Oracle OLAP Referenzbücher [Orad].
7.4.2 Kategorisches Modell und OLTP-Datenmodelle
Aufgrund der niedrigen Anforderungen an die Analyse ist dieses Datenmodell inhärent durch bestehende OLTP-Systeme gegeben. ORACLE bietet gängige SQL99 Datentypen wie zum Beispiel INT, DOUBLE und CHAR an und erweitert diese um
einige Spezialdatentypen, wie XMLType, die für Spezialeinsatzgebiete des Transaktionsmodells interessant sind. Die Datenstrukturen sind auf logischer Ebene durch
Tabellen repräsentiert auf denen die DML-Operationen ausgeführt werden. Die zen-
103
7 Fortgeschrittene OLAP-Analysemodelle
tralen Modikationsoperatoren sind INSERT, UPDATE, SELECT und DELETE, die zusammen mit Funktionen und Ausdrücken neben Transaktionsfunktionalitäten auch
kategorischen Analyseansprüchen genügen. Im Kontext dieser Modellklasse bietet
ORACLE Funktionen für Ränge und Perzentile, gleitende Berechnungsfenster sowie Führungs- und Rückstandsanalysen, die ergänzend zu den in SQL üblichen
analytischen Funktionen, wie zum Beispiel Aggregationen (SUM,COUNT,STDDEV), zur
Verfügung stehen. Da die detaillierte Erläuterung dieser Funktionen den Rahmen
dieser Ausarbeitung übersteigt, wird hier nur auf die entsprechende Oracle Dokumentation [Oraa] verwiesen.
7.4.3 Exegatives Modell und Data Warehouses
Die Implementierung des exegativen Modells ist durch Data Warehouses als zugrunde liegendes Datenmodell realisiert. ORACLE setzt hier aufgrund des bestehenden
Datenbanksystem auf ROLAP [HK01], welches die multidimensionale Speicherung
mit Hilfe von Tabellen durchführt. Star- und Snowake-Schemata ermöglichen dem
Analytiker mit den gleichen DML-Operatoren wie im kategorischen Modell, multidimensionale Datenbestände zu erforschen. Die Funktionen ROLLUP und CUBE erlauben dem Analytiker entsprechend über Hierarchieebenen oder über Dimensionen
Aggregationen durchzuführen. Die Sicht auf den multidimensionalen Datenbestand
kann dynamisch erzeugt oder materialisiert werden, wofür die Operation CREATE
MATERIALIZED VIEW zur Verfügung steht [Orab].
7.4.4 Kontemplatives Modell für fortgeschrittene Analysefunktionen
Eingaben und Ausgaben
Da im relationalen Modell die Eingaben sowie die Ausgaben in Relationen abgelegt
sind, lassen sich diese wie bei den anderen Modellklassen über gewöhnliche SQLSELECT -Ausdrücke anfragen. Ist der Wertebereich eines Attributs kontinuierlich,
so lassen sich mit der WHERE-Klausel und entsprechenden Konjunktionen von
Gröÿenvergleichen für Ausgaben Bereichsanfragen stellen. Eine weitere Möglichkeit besteht beispielsweise mit Subqueries Standardabweichungen in der Domäne
des Attributs zu berechnen und das Ergebnis als Bedingung der WHERE-Klausel
zu übergeben. Die Eingaben können im kontinuierlichen Fall durch berechnete
Attributwerte in der Selektion mit Varianzen versehen werden. Diese Funktionalitäten sind in jeder gröÿeren SQL-Datenbank vorhanden, jedoch mangelt es der
ORACLE -Datenbankengine an Anfragemöglichkeiten für unscharfe kategorische
Attribute. Diese Funktionalität wurde für ältere ORACLE -Versionen durch [Gal]
bereitgestellt, was jedoch keine ozielle Erweiterung der Datenbank darstellt. Nach
Angaben des Autors besteht auch die Möglichkeit, die Unschärfe in den einzelnen
Tabellen zu hinterlegen.
104
7.4 Datenmodelle in der Implementierung
Systemmodelle
ORACLE realisiert Systemmodelle neben einer umfassenderen Erweiterung im
OLAP-Modul über den SQL-Befehl MODEL, der auf multidimensionalen Daten operiert und einer SELECT-FROM-WHERE-Klausel folgt. Auf den ausgewählten Daten
können beliebig viele so genannte Regeln angewendet werden, die durch Gleichungen angegeben werden. Dabei können neben den umfangreichen Rechenoperationen
auf den selektierten Daten auch Aggregationen ausgeführt werden. Die Erzeugung
neuer Werte erfolgt wie bei vielen Programmiersprachen durch Zuweisung an eine
entsprechend benannte Variable auf der linken Seite der Gleichung. Weiterhin besteht die Möglichkeit mittels den Zusätzen UPSERT und UPDATE die Erzeugung von
Werten entsprechend zu erzwingen oder nur zu aktualisieren, wenn diese tatsächlich vorhanden sind.
Beispiel 7.4.1 SELECT SUBSTR(country, 1, 20) country,
SUBSTR(product, 1, 15) product, year, sales
FROM sales_view
WHERE country IN ('Italy', 'Japan')
MODEL
PARTITION BY (country) DIMENSION BY (product, year)
MEASURES (sales sales)
RULES
(sales['Bounce', 2002] = sales['Bounce', 2001]
+ sales['Bounce', 2000],
sales['Y Box', 2002] = sales['Y Box', 2001],
sales['All_Products', 2002] = sales['Bounce', 2002]
+ sales['Y Box', 2002])
ORDER BY country, product, year;
Das aus [Orac] entnommene Beispiel illustriert die Verwendung der SQLMODEL-Klausel und berechnet aus den Jahren 2000 und 2001 unterschiedliche
neue Werte für das Jahr 2002 durch einfache Zuweisung.
7.4.5 Formalisiertes Modell für abstrakte Analysen
Das formalisierte Modell ist in der Kerndatenbank von ORACLE nur in Form
einer linearen Regression implementiert. Erweiterte Funktionalitäten wie das automatisierte Suchen von vorliegenden Systemverhalten ak sind jedoch im zusätzlich
verfügbarem OLAP-Modul, welches eine Ergänzung der bestehenden Datenbank
darstellt, in Form von Vorhersagen vorhanden. Die Basis von Vorhersagen sind
Zeitreihenanalysen, denen multidimensionale Regressionsanalysen zugrunde liegen.
ORACLE OLAP unterstützt folgende Regressionsmethoden im Zusammenhang
mit Vorhersagen [Orae]:
Es besteht weiterhin die Möglichkeit, die Anwendung automatisch das beste
Regressionsmodell nden zu lassen.
105
7 Fortgeschrittene OLAP-Analysemodelle
Regressionsmethode
linear
polynominiell
exponentiell
logarithmisch
asymptotisch
mathematische Beschreibung
y =a·x+b
y = c · xa
y = c · eax
y = a · log(x) + b
x
y = a+bx
exponentiell asymptotisch
einfache exponentielle Glättung
doppelte exponentielle Glättung
Holt / Winters Methode
y = cKe (1+cea x)
ax
Tabelle 7.1: Verfügbare Regressionsmethoden in Oracle
Dem Vorhersagemodell von ORACLE können Periodengröÿen übergeben werden, die im Fall der Periodengröÿe p = 1 der einfachen Regressionsanalyse entspricht und in den Fällen von p > 1 eine multidimensionalen Regressionsanalyse
über der Zeit ist. Durch die Angabe der Anzahl zurückliegender Perioden werden
die Eingaben und Ausgaben der Zeitschritte k deniert, aufgrund derer das Systemmodell approximiert wird. Der Schätzer ist direkter Bestandteil von Vorhersagen
und liefert basierend auf der ermittelten funktionalen Abhängigkeiten konkrete
Schätzergebnisse. Ein zusätzliches Kommando erlaubt die ermittelten Systemparameter (im Beispiel 7.3.4 a und b) zu extrahieren.
7.5 Fazit
In Kapitel 7.2 wurde grundlegend auf die einzelnen Bestandteile von Systemen und
Datenmodellen eingegangen. Die in [CCS] nicht formal umschriebenen Datenmodelle wurden in Kapitel 7.3 mit Systemen in Zusammenhang gebracht und anhand
von Beispielen wurden die unterschiedlichen Analysebedürfnisse illustriert. Die verfügbaren Funktionen des Datenbankprodukts ORACLE wurden hinsichtlich dieser
Modellklassen eingeordnet. Die Zusammenhänge zwischen kategorischen, exegativen, kontemplativen und formalisierten Datenmodellen und den entsprechenden
Implementierungen des relationalen Modells, des Data Cubes, der Systemmodellierung und der Regressionsanalyse wurden in Kapitel 7.4 hergestellt.
Zum Zeitpunkt der Veröentlichung von [CCS] existierten laut Autor zwar viele
Datenbankprodukte, die den kategorischen Anforderungen genügten, jedoch waren
nur wenige oder gar keine Produkte am Markt verfügbar, die den gehobenen Modellklassen genügten. Diese Darstellung entspricht nicht mehr den heutigen Gegebenheiten. Es wurde anhand eines marktüblichen Datenbanksystems gezeigt, dass
exegative, kontemplative und formale Anforderungen umfassend erfüllt werden. Die
MODEL-Klausel für kontemplative Analysen ist im Zusammenhang mit der umfangreichen DML eine mächtige SQL-Erweiterung, mit der eine Vielfalt von Analysen
möglich ist. Lediglich die Modellierung und Speicherung von Unschärfe ist nicht in
106
7.5 Fazit
vollem Umfang gegeben. Die Vorhersagefunktion des OLAP-Moduls stellt wichtige
Regressionsverfahren zur Verfügung, die es erlauben Systemparameter zu extrahieren sowie Schätzungen durchzuführen.
107
7 Fortgeschrittene OLAP-Analysemodelle
108
Horst Fortner
8
Visualisierung der Imperfektion in
multidimensionalen Daten
8.1 Einführung
8.1.1 Motivation
Die Visualisierung multidimensionaler Daten verbessert typische Data Mining Anwendungen sowie OLAP-Anwendungen (Online Analytical Processing ) und ermöglicht kooperatives Data Mining, bei dem der Benutzer interaktiv die Datenanalyse
steuert. In dieser Seminararbeit werden zunächst bestehende Visualisierungstechniken daraufhin untersucht, wie sie sich um imperfekte Informationen erweitern
lassen und anschlieÿend bewertet. Weiterhin wird auf die Bedeutung des Visual
Data Mining (VDM) eingegangen und erläutert, welche Rolle die Visualisierung
im VDM spielt. Anschlieÿend werden die vorgestellten Visualisierungstechniken
sowie die VDM-Techniken mittels eines orthogonalen Klassikationsschemas eingeordnet. Das letzte Kapitel fasst die Ergebnisse zusammen und gibt einen Ausblick
auf interessante zukünftige Forschungszweige.
8.1.2 Begrie
Imperfekte Informationen: Es lässt sich eine Grobeinteilung imperfekter Informationen in drei Kategorien durchführen [Koo04b], nämlich in unsichere, unscharfe
und ungenaue Informationen. Unsicher ist eine Information, wenn nicht entschieden werden kann, ob sie wahr oder falsch ist. Unsichere Informationen treten z. B.
in Wettervorhersagen auf, da diese Prognosen nur wahrscheinlich sind, nicht aber
sicher.
109
8 Visualisierung der Imperfektion in multidimensionalen Daten
Unscharf ist eine Information, wenn bei Verwendung von Kategorien für gewisse
Eigenschaften keine eindeutige Grenze gezogen werden kann (linguistische Variablen), z.B. ist nicht scharf abgrenzbar, ob ein Mensch groÿ oder ein Produkt
teuer ist. Ungenau ist eine Information, wenn sie durch Intervalle angegeben wird,
die nicht beliebig genau (bzw. kurz) sein können, z. B. spricht man bei Messungen
in der Physik von Messungenauigkeit.
Visualisierung:
Laut Wikipedia bedeutet Visualisierung, abstrakte Daten in eine angebrachte, verstehbare Form zu bringen. Dabei können Details weggelassen
werden, die im Kontext vernachlässigbar sind. Visualisierte Daten müssen daher
korrekt interpretiert werden. Diese Denition weist schon darauf hin, dass bei
der Visualisierung Imperfektion implizit vorhanden sein kann, da Informationen
(Details) weggelassen werden können. Im Rahmen dieser Seminararbeit bedeutet Visualisierung insbesondere die grasche Darstellung von multidimensionalen
Datenmengen.
Multidimensionale Daten: Dies bedeutet, dass es sich um Daten mit vielen Attributwerten handelt, die sich zu orthogonalen Dimensionen zusammenfassen lassen
und als Ausgangsbasis für Analyseanwendungen dienen.
8.2 Visualisierung imperfekter Informationen im
Straÿenverkehr1
Im Straÿenverkehr treten imperfekte Informationen z.B. bei unsicheren Angaben
von Staulängen, bei ungenauen Baustellenlängenangaben oder auch bei Berechnungen von Radiosendern, die den erwarteten Zeitverlust angeben. All diesen Beispielen ist gemein, dass sie dem Benutzer aber immerhin das ungefähre Ausmaÿ
der zu erwartenden Verspätung aufzeigen. In diesem Kapitel werden zunächst die
Benutzergruppen im Straÿenverkehrsbereich identiziert. Danach werden drei Visualisierungstechniken eingeführt und eine Einschätzung gegeben, wie gut diese
für die Benutzergruppen geeignet sind. Anchlieÿend werden diese Verfahren um
Imperfektion erweitert und schlieÿlich wird das Visualisierungswerkzeug aus der
Studienarbeit [For05] skizziert.
8.2.1 Benutzergruppen im Straÿenverkehrsbereich
Verkehrsteilnehmer On-Trip:
Für den Verkehrsteilnehmer On-Trip sind seine
aktuelle Position und Geschwindigkeit sowie Informationen zum Verkehrsuss besonders wichtig. Wird z. B. eine Straÿe gesperrt, benötigt er zwei Nachrichten: Eine
beim Inkrafttreten der Sperrung und eine bei deren Aufhebung. Des Weiteren sind
das Wetter sowie Baustellen ebenfalls von Interesse für diesen Verkehrsteilnehmer,
1
Die Ausführungen dieses Kapitels basieren auf der Studienarbeit [For05] von Oliver Forster
110
8.2 Visualisierung imperfekter Informationen im Straÿenverkehr
insbesondere wenn sie Einuss auf den Verkehrsuss haben (Eis, Nebel, nur einspurig befahrbare Baustellen etc.).
Verkehrsteilnehmer Pre-Trip:
Dieser Benutzertyp plant seine Route im Vorfeld
und braucht dazu Informationen zum Verkehrsnetz. Im Vorfeld bekannte Störgröÿen für den Verkehrsuss, etwa Langzeitbaustellen oder auch gesperrte Straÿen,
sind für ihn wichtig. Auch das zu erwartende Verkehrsaufkommen (z. B. ein hohes
Aufkommen zur Urlaubszeit) ist ein wichtiger Faktor bei seiner Planung. Das Wetter spielt, insbesondere bei früher Routenplanung, eine ungeordnete Rolle, da z.B.
über eine Woche hinausgehende Wettervorhersagen zu unsicher sind, als dass sie
als Entscheidungskriterium herhalten könnten.
Verkehrsingenieur: Der Ingenieur benötigt alle Arten von Informationen zum
Verkehrsnetz, damit er einen Überblick hat, wenn z.B. Umleitungen empfohlen
werden sollen. Zudem ist der aktuelle Verkehrsuss auf seinem Zuständigkeitsgebiet
(und nicht etwa nur auf einer geplanten Route) von groÿer Bedeutung, da er auf
Störfaktoren z. B. mit Umleitungen und Temporegulierungen reagieren kann und
somit möglichst frühzeitig informiert werden sollte.
Verkehrswissenschaftler:
Für den Wissenschaftler sind vor allem aggregierte und
statistisch nutzbare Daten interessant statt Einzeldaten wie ein Unfall. Je nach
Art der Untersuchung, die er anstellt, können für ihn bestimmte Daten wichtig
und andere irrelevant sein (das gesamte Verkehrsnetz spielt keine Rolle, wenn nur
eine Strecke untersucht wird).
Zusammenfassend lässt sich feststellen, dass verschiedene Informationen für die
besprochenen Benutzergruppen von Bedeutung sind und jede Gruppe daher andere
Anforderungen an die Visualisierung stellt.
8.2.2 Visualisierungstechniken (noch ohne Imperfektion)
Nach der Identikation der beteiligten Benutzergruppen und deren Anforderungen
werden in diesem Abschnitt drei Visualisierungstechniken vorgestellt.
Bewertungskriterien für Visualisierungstechniken im Hinblick auf die
Benutzergruppen
Um die drei vorzustellenden Visualisierungstechniken bewerten zu können, werden in diesem Abschnitt zunächst vier Bewertungskriterien eingeführt, welche eine
qualitative Einordnung der Techniken ermöglichen und Aufschluss darüber geben,
inwieweit sie für die zuvor vorgestellten Benutzergruppen geeignet sind.
Übersichtlichkeit
Dieses Kriterium bringt zum Ausdruck, wie schnell sich der Betrachter einer visualisierten Datenmenge die für ihn interessanten Informationen
herauslesen kann und wie deutlich es erkennbar ist (z. B. auch ohne Expertenwissen,
111
8 Visualisierung der Imperfektion in multidimensionalen Daten
denn deutlich erkennbar ist natürlich subjektiv). Negativ auf die Übersichtlichkeit
wirkt sich eine zu groÿe Detailtreue aus - insofern besteht hier Koniktpotential
bezüglich des Kriteriums der Vollständigkeit. Insbesondere für den Verkehrsteilnehmer ist dieses Kriterium hoch zu bewerten, die anderen Gruppen arbeiten beruich
damit, weshalb ihr Blick geschulter ist beim Erkennen wichtiger Informationen.
Vollständigkeit Um die Vollständigkeit zu erfüllen, muss eine Visualisierungstechnik alle vorhandenen Daten mit in die Darstellung einbeziehen. Fehlen wichtige
Informationen, etwa hohe Windgeschwindigkeiten bei in die Darstellung mit einbezogenem Glatteis, so ist die Darstellung nicht mehr vollständig zu nennen. Vor
allem der Verkehrsingenieur und der Verkehrswissenschaftler fordern die Erfüllung
dieses Kriteriums.
Möglichkeit zur Interaktion
Da der Benutzer nur eine begrenzte Zahl von Daten verarbeiten kann, sollte ihm die Möglichkeit gegeben werden, die Darstellung
interaktiv zu verändern, z.B. durch das Weglassen von Informationen, deren andere Gewichtung oder auch durch die Navigation in Hierarchien. In [Spe01] wird
als Beispiel für sog. Fokus + Kontext-Techniken der Fisheyeview genannt, der
das Hauptaugenmerk auf einen Ausschnitt der Informationen lenkt und den Rest
unscharf erscheinen lässt. Prinzipiell ist die Interaktionsmöglichkeit für alle Benutzergruppen von Interesse.
Anwendbarkeit auf ein Verkehrsszenario
Dieses nur auf den Verkehr bezogene
Kriterium spielt in der Studienarbeit von Oliver Forster eine besondere Rolle, tritt
hier aber in den Hintergrund. Dieses Kriterium bewertet, wie gut eine Technik sich
im Verkehr einsetzen lässt unabhängig von den anderen drei Kriterien.
Kategorien und Verfahren
In Oliver Forsters Studienarbeit werden 18 Verfahren vorgestellt (siehe Abbildung
8.1) und sieben davon um Imperfektion erweitert. An dieser Stelle werde ich drei
dieser Verfahren beschreiben, und zwar ThemeRiver aus der Kategorie Dokumente und Table Lens und Parallele Koordinaten aus der Kategorie Hochdimensionale Daten.
Die restlichen Visualisierungsarten nden sich in Abbildung 8.2, und zwar jeweils
mit Bewertung. Da diese Techniken in [For05] näher vorgestellt werden, verzichte
ich hier auf die genaue Beschreibung aller 18 Verfahren.
ThemeRiver
Der ThemeRiver ist eine Visualisierungstechnik für Dokumente,
die Veränderungen des thematischen Schwerpunkts innerhalb einer Menge Dokumente visualisiert. Der Themenuss wird über die Zeitachse dargestellt, die Themenschwerpunkte werden farblich voneinander abgegrenzt, wobei die Dicke einer
Schicht proportional zur Bedeutung des Themas ist. Von einem Fluss spricht man,
112
8.2 Visualisierung imperfekter Informationen im Straÿenverkehr
Abbildung 8.1: Übersicht der Visualisierungstechniken [For05]
Abbildung 8.2: Bewertungstabelle Visualisierungstechniken [For05]
da zwischen diskreten Zeitpunkten z.B. mittels Splines interpoliert wird. Beim
ThemeRiver sind Interaktion und das Zoomen auf der Zeitachse möglich. Diese
relativ einfache und leicht verständliche Darstellung ermöglicht auch Laien einen
einfachen Zugang. Der Verkehrsteilnehmer On-Trip und Pre-Trip sollte die Schaubilder daher gut verstehen können. In Abbildung 8.3 ist die Häugkeit von Texten
Fidel Castros im Zeitraum von November 1959 bis Juni 1961 dargestellt.
Parallele Koordinaten
Mittels paralleler Koordinaten lässt sich eine Vielzahl von
Dimensionen auf zweidimensionalen Medien wie Papier oder Monitor ausgeben.
Dazu werden alle Achsen (bzw. Variablen oder Attribute) des multidimensionalen Raums nebeneinander parallel angeordnet. Die Länge der parallelen Strecken
113
8 Visualisierung der Imperfektion in multidimensionalen Daten
Abbildung 8.3: Beispiel ThemeRiver [SHW02]
spiegelt dabei den Wertebereich jedes Attributs wider, wobei die eingezeichneten
Attributwerte als Punkte eingezeichnet und schlieÿlich mit einer Linie verbunden
werden (siehe Abbildung 8.4. Eine solche zur besseren Erkennbarkeit oft eingefärbte Linie stellt bei n Attributen ein einzelnes n-Tupel dar. Ein groÿer Vorteil der
parallelen Koordinaten ist, dass die beliebig vielen Attribute alle gleich behandelt
werden.
Interaktion ist dadurch gegeben, dass der Benutzer die Achsen anders anordnen kann, was dem besseren Verständnis der Beziehung zwischen zwei Attributen
dienen kann. Zudem können Attribute (bzw. deren Achsen) auch ausgeblendet werden, was für eine gelterte Darstellung sorgt und dieses Verfahren exibel macht.
Auch Vollständigkeit wird gewährleistet, da alle Attributwerte durch die Verwendung einer eigenen Achse visualisiert werden. Allerdings wird die Darstellung bei
Einbeziehung aller Attribute schnell unübersichtlich, insbesondere wenn viele Tupel vorliegen und sich die Verbindungslinien der Tupel oft überkreuzen oder nah
beieinander liegen.
Experten der Interpretation von parallelen Koordinaten können dieser Visualisierung viele Informationen entnehmen, gerade auch durch die exible Anordnung
der Achsen. Während dem Verkehrsingenieur durch die aggregierte Darstellung der
Blick auf einzelne Teilstrecken erschwert wird, eignet sich diese Technik sehr gut
für den Verkehrswissenschaftler. Für den Pre-Trip Verkehrsteilnehmer erfordert
diese Technik zu viel Einarbeitungszeit auf Grund der ungewohnten Darstellung
mehrerer Achsen nebeneinander und überfordert den On-Trip Verkehrsteilnehmer
völlig.
Abbildung 8.4: Prinzip der parallelen Koordinaten [Spe01]
114
8.2 Visualisierung imperfekter Informationen im Straÿenverkehr
Table Lens
Die Table Lens Technik dient der Daten-Analyse durch den Benutzer,
der diese interaktiv steuern kann. Wie in Abbildung 8.5 zu sehen ist, ist die Ausgabe
tabellarisch aufgebaut. Interessante Bereiche werden mittels der Fokus + KontextTechnik in den Vordergrund gerückt (ähnlich der Fisheye-Sicht), wodurch man
auch in groÿen Datenmengen gezielt Informationen hervorheben kann.
Für On-Trip Verkehrsteilnehmer eignet sich diese Darstellung auf Grund ihrer
Komplexität nicht, ebenso wenig für den Pre-Trip. Für die beiden anderen Gruppen,
Wissenschaftler und Ingenieur, ist die Technik hingegen gut geeignet eben durch
ihre vollständige Darstellung mit Fokussierungsmöglichkeit.
Abbildung 8.5: Inxight Table Lens [IS]
8.2.3 Erweiterung der Verfahren um Imperfektion2
Die Visualisierung der drei Aspekte der Imperfektion (Unsicherheit, Unschärfe,
Ungenauigkeit) ist unterschiedlich einfach zu realisieren. Zudem lassen sich die
drei vorgestellten Techniken nicht immer um alle Aspekte sinnvoll erweitern.
Der ThemeRiver eignet sich für eine Erweiterung um Unschärfe, indem Linienstärke proportional zu einer linguistischen Variablen eingezeichnet wird (z.B.
kein, wenig, viel beim Niederschlag in Abbildung 8.6). Unsicherheit lässt sich
z.B. durch Musterungen wie im rechten Bild in Abbildung 8.6 darstellen, wobei der
schraerte Bereich ein Ungenauigkeitsintervall darstellt, in dem keine eindeutige
Aussage darüber möglich ist, ob die Strecke z.B. frei ist oder ob Staugefahr
herrscht. Ich denke, dass man die schraerten Bereiche auch einfach durch eine
weitere Farbe visualisieren könnte und dieser dann eine neue linguistische Variable
zuweisen könnte, z.B. könnte man Frei/Staugefahr braun einfärben und Staugefahr/Stau orange, wodurch dann fünf statt drei Variablen vorhanden wären. Die in
der Abbildung verwendete Schraur verdeutlicht aber besser den Zusammenhang
2
Vgl. [For05].
115
8 Visualisierung der Imperfektion in multidimensionalen Daten
zwischen sicherer und unsicherer Information, da die voll ausgefüllten Linien einen
sicheren Mindestwert darstellen und die Unsicherheit durch die Schraur schnell
als solche erkennbar ist.
Bei den parallelen Koordinaten in Abbildung 8.7 ist die Unsicherheit im linken
Bild durch den Graustufenwert visualisiert, wobei eine Linie einem Streckabschnitt
der A5 entspricht und die Graustufe der Sicherheit des Datensatzes gemäÿ gewählt
ist. An dieser Stelle möchte ich anmerken, dass man durch diese Darstellung etwas eingeschränkt ist, da man zum Beispiel nicht visualisieren kann, dass auf einem
Streckenabschnitt ganz sicher kein Nebel vorhanden ist, man aber gleichzeitig über
die Rutschgefahr keine Aussage treen kann. Um unterschiedlichen Attributen wie
Nebel und Rutschgefahr verschiedene Sicherheitsgrade zuzuweisen, würde ich hier
eine kleine Erweiterung vorschlagen, und zwar wäre ein Wechsel der Graustufe
innerhalb des Streckenzuges sinnvoll, sodass eine Linie beim Übergang von einem
Attribut zum anderen in der Graustufe (und damit der Sicherheit der Information)
veränderbar ist. Die Ungenauigkeit wird dadurch visualisiert, dass eine Linie vor
einem mit Ungenauigkeit behafteten Attribut aufgespaltet und danach wieder zusammengeführt wird. Dies ist im Beispiel beim Attribut Niederschlag in der Mitte
von Abbildung 8.7 zu sehen. Unschärfe lässt sich bei dieser Visualisierungstechnik
schwieriger visualisieren. Im rechten Bild von Abbildung 8.7 sind die Werte der
Zugehörigkeitsfunktion zu den linguistischen Variablen des Niederschlags, nämlich kein, schwach und stark um 90◦ gedreht zur Zeichenebene angetragen.
Die Linie, die den Streckenabschnitt A5/73 repräsentiert, bedeutet nun, dass die
Zugehörigkeitsfunktion viele Werte der linguistischen Variable kein zuordnet, wohingegen schwach und stark nur wenige Werte auf sich vereinen können, d.h.
insgesamt kann man wohl zu Recht von keinem Niederschlag auf diesem Streckenabschnitt sprechen.
Bei der Table Lens Technik lässt sich die Unsicherheit wie in Abbildung 8.8 auf
der linken Seite zu sehen mittels Graustufen visualisieren, wobei dunklere Graustufen eine gröÿere Sicherheit darstellen. Die Unschärfe wird durch einen für jede
linguistische Variable jeweils anders gefärbten Balken dargestellt, dessen Länge
proportional zu den Werten der Terme eingezeichnet wird. Die rechte Seite von
Abbildung 8.8 kombiniert schlieÿlich Unsicherheit und Ungenaugikeit, indem zur
Graustufen-Färbung der Balken noch ein gepunktetes Segment ans Ende der Balken angehängt wird, welches das Ungenauigkeitsintervall darstellt, d.h. der Anfang
dieses Segments markiert die untere Intervallgrenze, während das Ende des gesamten Balkens die obere Intervallgrenze markiert.
116
8.2 Visualisierung imperfekter Informationen im Straÿenverkehr
Abbildung 8.6: ThemeRiver ohne (li.) und mit (re.) Ergänzung um Ungenauigkeit
- auf beiden Seiten ist die Unschärfe durch linguistische Variablen
visualisiert. [For05]
Abbildung 8.7: Parallele Koordinaten, erweitert um Imperfektion. [For05]
Bewertungskriterien bei der Erweiterung einer Technik um Imperfektion
Bei der Erweiterung von Verfahren um Imperfektion sollten nach [For05] folgende
vier Punkte beachtet werden:
1. Verhältnismäÿigkeit: Die Imperfektion sollte keinen gröÿeren Stellenwert in
der Visualisierung bekommen als die eigentliche Information, d.h. die Imperfektion soll die Hauptinformation nur ergänzen.
2. Imperfektionsabgrenzung: Imperfekte Informationen sollten in der Visualsierung klar von perfekten Informationen unterschieden werden können.
3. Unterscheidbarkeit: Mehrere dargestellte Imperfektionsarten sollten innerhalb einer Visualisierung voneinander unterscheidbar sein.
117
8 Visualisierung der Imperfektion in multidimensionalen Daten
Abbildung 8.8: Table Lens, erweitert um Imperfektion. [For05]
4. Mächtigkeitserhaltung: Die Möglichkeiten einer Visualisierungstechnik sollten durch die Erweiterung um Imperfektion nicht beschnitten werden, insbesondere sollte die erweiterte Technik nicht unübersichtlicher werden.
Bewertung der erweiterten Verfahren
In der Tabelle in Abbildung 8.9 sind alle in der Studienarbeit [For05] um Imperfektion erweiterten Visualisierungstechniken an Hand der vier eingeführten Kriterien
bewertet. Die beiden Techniken für hochdimensionale Daten, Table Lens und Parallele Koordinaten, schneiden in dieser Bewertung in allen Kategorien gut bis sehr
gut ab, womit sie sich für die Imperfektionserweiterung sehr gut eignen.
Abbildung 8.9: Bewertung der um Imperfektion erweiterten Visualisierungstechniken. [For05]
118
8.3 Datenvisualisierung und Visual Data Mining (VDM)
8.2.4 Skizzierung des Visualisierungswerkzeugs
Das von Oliver Forster mit Java-Swing implementierte Visualisierungswerkzeug
"Visualizer"lässt den Benutzer den Typ der zu visualisierenden Information mit
verschiedenen Visualisierungstechniken darstellen. Er implementierte exemplarisch
zwei Techniken, nämlich die erweiterten Balkendiagramme (Teil der Table Lens
Technik) und ThemeRiver. Das Paket Visualizer enthält vier Hauptklassen (siehe
Abbildung 8.10: Paketstruktur im Visualisierungswerkzeug [For05]
Abbildung 8.10 und jeweils in einem gesonderten Paket Klassen, die das Laden
von Information bzw. das Layout betreen. Die Kopplung des Werkzeuges mit
den Visualisierungstechniken erfolgt über die Pakete fuzzyThemeRiver und impChart2d, welche jeweils die Erweiterung einer bereits vorhandenen Software und
deren Anbindung an den Visualizer übernehmen.
Vorhandene Informationen müssen zur Darstellung im Visualizer zunächst über
den DataLoader in ein festgelegtes zentrales Format gebracht werden und werden
danach vom TechniqueLoader in das technikspezische Format für eine Visualisierung umgewandelt. Für neue Informationsarten reicht es aus, eine Klasse zur Erzeugung des festgelegten zentralen Formats zu erstellen; es muss also nicht für jede
Technik eine neue Klasse zur Umwandlung in deren Format geschrieben werden
beim Hinzufügen neuer Informationsarten, wodurch eine einfache Erweiterbarkeit
sichergestellt ist. Das Visualisierungswerkzeug eignet sich für den Verkehrsteilnehmer Pre-Trip und für Teilaufgaben des Verkehrsingenieurs/-wissenschaftlers. Nähere Details zum Visualizer nden sich in [For05].
8.3 Datenvisualisierung und Visual Data Mining (VDM)
Nachdem im letzten Kapitel die Erweiterung von Visualisierungstechniken um Imperfektion auf dem Sektor Straÿenverkehr behandelt wurden, beschäftigt sich dieses
119
8 Visualisierung der Imperfektion in multidimensionalen Daten
Kapitel mit dem in der Literatur beim Thema Visualisierung auftauchenden Begri
des Visual Data Mining (VDM), einem mit der Visualisierung von multidimensionalen Daten in Beziehung stehenden Teilbereich des Data Mining. Zunächst gebe
ich eine Einführung in verschiedene VDM-Ansätze, danach werden das automatisierte Data Mining und seine Schwächen behandelt, die zum Ansatz der Visuellen
Datenexploration geführt haben. Anschlieÿend werden Beispiel-Einsatzgebiete des
Kooperativen Data Mining vorgestellt, nämlich die Kooperative Klassikation und
das Interaktive Temporale Data Mining. Bei jeder vorgestellten Technik werde ich
darauf eingehen, in wie weit bereits Imperfektion in der Technik bereits vorhanden ist und wie sie dargestellt wird, sofern sie überhaupt berücksichtigt wurde.
Schlieÿlich wird noch eine Klassikationsmöglichkeit vorgestellt, an Hand derer
VDM-Techniken entlang orthogonaler Achsen eingeordnet werden können.
8.3.1 Einordnung des VDM
Wie in Abbildung 8.11 zu sehen, bendet sich das Visual Data Mining (VDM)
in der Schnittmenge von Data Mining und Information Visualization, d.h. dass
im VDM Algorithmen aus dem Mining-Bereich eingesetzt werden und Visualisierungstechniken aus dem Bereich des Informationsvisualisierung. Eine Denition
Abbildung 8.11: Einordnung des VDM zwischen Data Mining und Informationsvisualisierung [Fay96]
des VDM gibt Mihael Ankerst in seiner Dissertation: Visuelles Data Mining ist
ein Teil des KDD-Prozesses, der Visualisierung als Kommunikationsmittel zwischen
Mensch und Computer nutzt, um neue und interpretierbare Muster zu erkennen
und Wissen zu generieren. [Ank01]
Ein Überblick darüber, in welchem Bereich das VDM im KDD-Prozess (Knowledge Discovery in Databases) angesiedelt ist, wird im Schema in Abbildung 8.12
gegeben. Das Schema basiert auf der allgemein anerkannten Denition des KDDBegris von Fayyad: Wissensentdeckung in Datenbanken ist der nichttriviale Prozess der Identizierung gültiger, neuartiger, potentiell nützlicher und verständlicher
Muster in (groÿen) Datenbeständen. [Fay96]
Im Grunde geht es beim VDM darum, den Data Mining Schritt und den Interpretationsschritt im ständigen Wechsel durchzuführen und den Menschen bei der
Klassikation oder Mustersuche zu unterstützen bzw. seine Intuition miteinzubeziehen, um schneller zu Ergebnissen zu kommen und redundante Muster zu entfernen.
120
8.3 Datenvisualisierung und Visual Data Mining (VDM)
Damit kombiniert das VDM die letzten beiden Schritte des KDD-Prozesses zu einer
neuen Einheit.
Abbildung 8.12: VDM im KDD-Prozess [Fay96]
Im VDM lassen sich mehrere Ansätze unterscheiden (siehe Abbildung 8.13). Ansatz a) setzt auf klassischen Data Mining Algorithmen auf, deren Ergebnisse (z.B.
erkannte Muster) visualisiert werden. Nachdem die Ergebnisse der Visualisierung
vorliegen, entscheidet der Benutzer, ob der Data Mining-Prozess erfolgreich war
oder ob der Prozess rekursiv beginnend beim Algorithmus mit geänderten Parametern neu gestartet wird. In der Literatur werden auf diesem Ansatz aufbauende
Visualisierungsmethoden auch als Visual Data Mining Tools bezeichnet. Ansatz
b) visualisiert die Zwischenergebnisse; dadurch wird der Benutzer stärker in den
DM-Prozess einbezogen. Es werden Algorithmen verwendet, die nur präprozessierte Zwischenergebnisse liefern, in denen der Benutzer durch Einsatz von Visualisierungstechniken nach aussagekräftigen Mustern sucht. Der Hauptvorteil dieses
Ansatzes ist, dass DM-Algorithmen losgelöst von der Problemstellung verwendet
werden (zur Berechnung der Zwischenergebnisse). Allerdings ist hier im Gegensatz
zu Ansatz a) keinerlei Rekursion integriert, was für mich die Frage aufwirft, wie
mit unzufrieden stellenden Ergebnissen umgegangen wird. Schlieÿlich ist nicht jeder
Versuch, Wissen aus Daten zu gewinnen, von Erfolg gekrönt. Ansatz c) schlieÿlich
visualisiert Rohdaten und verwendet keine klassischen DM-Algorithmen. Es ndet
eine Rekursion zwischen den Benutzereingaben und der Visualisierung statt, wodurch die Interaktionsmöglichkeit hier am gröÿten ist, was auch durch die sofortige
Aktualisierung der Darstellung (durch interaktive Werkzeuge wie z.B. dynamische
Abfragetechniken) unterstrichen wird. Bei diesem Ansatz sprechen Soukup und
Davidson in [TS03] auch von Data Visualization-Techniken.
Besonders Ansatz c) kommt dem Online Analytical Processing (OLAP) sehr nahe, denn einige der zwölf von Edgar F. Codd in [Cod93] aufgestellten Regeln bzw.
Anforderungen an ein OLAP-System werden auch von Ansatz c) erfüllt, darunter
vor allem die zehnte Regel (Intuitive Datenanalyse), aber auch die elfte Regel (Flexibles Berichtswesen, Ergebnisse im Report frei anordbar) und die zwölfte (Unbegrenzte Anzahl von Dimensionen und Konsolidierungsebenen) können von Ansatz
c) erfüllt werden. Andere Regeln von Codd, wie etwa Regel fünf (Client-Server
Archtitektur) oder acht (Mehrbenutzerunterstützung) sind hingegen nicht in dem
VDM-Ansatz c) festgeschrieben, wodurch aus meiner Sicht auch ein OLAP-System
121
8 Visualisierung der Imperfektion in multidimensionalen Daten
Abbildung 8.13: Ansätze des visuellen Data Mining
mit diesem Ansatz beschrieben könnte, allerdings mit der Einschränkung, dass in
Ansatz c) keine so präzisen Regeln wie die von Codd formuliert sind (d.h. Ansatz
c) ist etwas abstrakter gehalten als OLAP).
8.3.2 Automatisiertes Data Mining und seine Schwächen
Data Mining ist ein iterativer Prozess, dessen Ergebnisse im Rahmen der Datenanalyse die Voraussetzung für eine spätere Evaluierung sind. Beim Data Mining,
das auf vorverarbeiteten Daten operiert, soll mittels ezienter Verfahren potentiell
nützliches Wissen in groÿen Datenmengen aufgefunden werden [Ank04] d.h. es sollen Informationen aus Datenmengen gewonnen werden. Heutzutage sind das Data
Mining sowie die gesamte Datenanalyse weitgehend automatisiert, was dazu führt,
dass einige Probleme auftreten, die durch die Automatisierung nur unzureichend
gelöst werden. Erstens ieÿt vorhandenes Wissen in den Köpfen der Menschen
nur schwer oder gar nicht in die Datenanalyse mit ein. Zweitens lassen sich die
Erkenntnisse einer Iteration oft nur schwer in eine verbesserte weitere Iteration
transferieren, sodass letztlich weiter zurückgegangen wird zum Vorverarbeitungsschritt und eine andere Vorverarbeitung der Daten erfolgt, die bessere Ergebnisse
verspricht. Drittens wenden sich heutige Produkte an Experten auf dem Gebiet des
Data Mining, weshalb die Fähigkeit dieser Experten, die gewonnenen Ergebnisse
zu kommunizieren, von zentraler Bedeutung ist - mit anderen Worten ist es denkbar, dass ein Data Mining Projekt auf Grund der (Un-)Fähigkeit des Experten
scheitert, gewonnene Informationen an den oder die Auftraggeber zu vermitteln.
122
8.3 Datenvisualisierung und Visual Data Mining (VDM)
8.3.3 Visuelle Datenexploration
Auf Grund der Schwächen des automatisierten Data Mining schlägt Ankerst in
[Ank04] einen benutzerorientierten Ansatz vor, bei dem der Mensch die Datenanalyse steuert. Bei der visuellen Datenexploration (vgl. [Kei02]) sollen die Kreativität
und das Verständnis des Menschen verbunden werden mit der der hohen Speicherkapazität und Rechenleistung des Computers. Durch die Visualisierung der Daten
kann der Mensch die Struktur der Daten verstehen, Hypothesen aufstellen und diese interaktiv verizieren bzw. falsizieren. Dadurch muss der Benutzer nicht auf
die oft lange dauernden automatischen Berechnungen warten, sondern er bekommt
Zwischenschritte angezeigt und kann den weiteren Verlauf der Exploration damit
in eine neue Richtung lenken. Infolgedessen kann auch ein Rechenlauf frühzeitig
abgebrochen werden, wenn sich bereits bei den Zwischenschritten abzeichnet, dass
mit den gewählten Data-Mining-Parametern keine sinnvollen Ergebnisse zu erwarten sind. Vorteile bietet VDM insbesondere dann, wenn die Explorationsziele nicht
genau speziziert sind und wenn stark inhomogene und verrauschte Daten vorliegen. Da die visuelle Datenxploration einfacher ist (eine Kenntnis von komplexen
Algorithmen ist nicht erforderlich), kann sie auch von Nicht-Spezialisten durchgeführt werden. Weiterhin ist vorteilhaft, dass der Nutzer besser versteht, wie die
gewonnen Informationen zu Stande kamen, da der Nutzer den Explorationsvorgang schlieÿlich mitgelenkt hat. Im Endeekt sind so häug bessere Ergebnissen
erzielbar, gerade in Szenarien, in denen die Automatisierung versagt.
Die visuelle Datenexploration lässt sich gemäÿ dem Information Seeking Mantra [Shn96] in drei Schritte untergliedern: Der Overview-Schritt soll dem Benutzer
einen Überblick über die Daten verschaen. Beim Zoom and Filter-Schritt kann der
Benutzer erkannte Muster selektieren (ltern) und genauer betrachten (zoomen).
Schlieÿlich bietet der Details-on-Demand-Schritt dem Nutzer die Möglichkeit, auf
Details der Daten zuzugreifen.
8.3.4 Beispiel-Einsatzgebiet für VDM: Kooperatives Data Mining
Beim kooperativen Data Mining [Ank04] werden Data Mining Algorithmen und Visualisierungstechniken integriert, sodass bestehende automatisierte Verfahren um
die Möglichkeit bereichert werden, den Benutzer interaktiv am Mining Prozess teilnehmen zu lassen. Das Wort kooperativ wird hier synonym zu interaktiv verwendet. An dieser Stelle sollen zwei konkrete Data-Mining-Verfahren vorgestellt
werden, die kooperative Klassikation und das interaktive temporale Data Mining.
Ein weiteres Verfahren [Hin99], welches hier jedoch nicht näher behandelt wird,
wendet die Idee des kooperativen Data Mining auf hochdimensionale ClusteringAlgorithmen an.
Kooperative Klassikation
Die Klassikation ist eines der zentralen Verfahren des Data Mining. Im ersten
der zwei Schritte der Klassikation werden bereits klassizierte Daten (sog. Trai-
123
8 Visualisierung der Imperfektion in multidimensionalen Daten
ningsdaten) analysiert, sodass ein Modell mit charakteristischen Attributwerten
erstellt werden kann, um im zweiten Schritt der Klassikation neue Daten gemäÿ
diesem Modell in Klassen einzuteilen. Zur Erstellung eines Klassikationsmodells
wird häug ein Entscheidungsbaum-Klassikator verwendet.
Aus den Trainingsdaten wird von der Wurzel beginnend ein Entscheidungsbaum
konstruiert, wobei Knoten eine Teilmenge der Trainingsdaten, Kanten einen Test
auf das Attribut des Vaterknotens und Blätter die Zugehörigkeit zu einer Klasse
bedeuten. Die Sensoren im abgebildeten Baum 8.14 bestimmen das Ausfallrisiko
eines Heizkörpers. Bei der Konstruktion des Baumes wird zuerst derjenige Sensor
gesucht, der die Trainingsdaten am besten in zwei Klassen einteilt. Dies tut Sensor
1, weshalb er zur Wurzel wird. Für die Kinder und deren Kinder wird rekursiv
ebenso solch ein am besten separierender Sensor gesucht, bis alle Knoten einen
ausreichenden Anteil an einer einzigen Klasse haben, was sie zu Blättern werden
lässt. In diesem ausreichenden Anteil steckt bereits ein gewisses Maÿ an Imper-
Abbildung 8.14: Exemplarischer Entscheidungsbaum [Ank04]
fektion, nämlich die Unsicherheit, dass nicht alle Daten, die beim Verfolgen der
Kanten zu einem Blatt (= Risikoklasse) führen, auch berechtigterweise in diese
Risikoklasse eingeordnet werden können, z.B. wenn man den ausreichenden Anteil
auf 95% festlegt, liegen 5% der Daten mit negativem Wert bei Sensor 1 und positivem Wert bei Sensor 5 in der hohen Risikoklasse statt in der niedrigen. Weiterhin
ist die Abgrenzung in positive und negative Messwerte der Sensoren zwar scharf,
doch ist das Ziehen einer Grenze, ab der man Trainingsdaten in eine andere Klasse
einteilt, nicht immer einfach. Es kann nämlich eine Rolle spielen, wie dicht die
Trainingsdaten an der Grenze beieinander liegen, denn viele nur ganz knapp die
Grenze über-/unterschreitende Daten könnten einen Hinweis darauf liefern, dass
die Grenze falsch gezogen wurde. Im Wesentlichen gibt es drei Kritikpunkte der automatischen Entscheidungsbaum-Klassikatoren: Erstens kann der Benutzer sein
vorhandenes Wissen in das Verfahren kaum einieÿen lassen, zweitens wird zur
Laufzeitverkürzung ein Greedy-Verfahren verwendet und drittens werden nicht im
Entscheidungsbaum verwendete Attribute einfach weggelassen. Kritikpunkt zwei
124
8.3 Datenvisualisierung und Visual Data Mining (VDM)
und drei lassen wieder Imperfektion erahnen. So kann das Greedy-Verfahren suboptimale Ergebnisse produzieren und die unterschlagenen Informationen aus Punkt
3 sind zwar nicht imperfekt im Sinne der drei Arten der Imperfektion aus Denition 1.2, jedoch ist der Baum damit unvollständig im Bezug auf die Verwendung
aller über die Daten zur Verfügung stehenden Informationen.
Interaktives temporales Data Mining
Beim interaktiven temporalen Data Mining haben die zu analysierenden Daten
für jeden Datensatz eine zeitliche Information, etwa einen Messzeitpunkt bei einer
Messreihe. Hier soll die Architektur sowohl von DM-Experten als auch von Fachexperten (die aber im DM unerfahren sind) benutzbar sein. Auch bei dieser Variante
hat der Besucher die volle Palette der Zoom-and-Filter Möglichkeiten. Beispielhaft soll hier auf das Mining-System DataJewel und dessen Visualisierungstechnik
CalenderView verwiesen werden. Wie DataJewel arbeitet und welche Interaktionsmöglichkeiten dem Benutzer zur Verfügung stehen, ist in Abbildung 8.15 ersichtlich.
CalendarView in Abbildung 8.16 visualisiert die zeitliche Verteilung von Ereignis-
Abbildung 8.15: Der interaktive Mining-Prozess mit DataJewel [Ank04]
häugkeiten in Kalenderform, was den Vorteil hat, dass die Darstellung zum einen
den meisten Personen schon vertraut ist und zum anderen, dass z.B. Wochenenden oder wöchentliche Wiederholungen von Ereignissen leichter wahrgenommen
werden können. Zudem werden verschiedene Ereignisse auf mit verschiedenen Farben dargestellt, was für Menschen allerdings nur bei einer kleinen Anzahl von
Ereignissen übersichtlich bleibt, da bei einer gröÿeren Anzahl die Ereignisse nicht
mehr unterscheidbar sind. Bei einer gröÿeren Zahl von Ereignissen können daher
125
8 Visualisierung der Imperfektion in multidimensionalen Daten
DM-Algorithmen aufgerufen werden, die in Sekunden zeitliche Muster nden.
Für diese Form des Data Mining müssen bestehende Algorithmen dahingehend
modiziert werden, dass bereits nach einem linearen Durchlauf der Daten ein Zwischenergebnis vorliegt, was interaktives Arbeiten mit der Software ermöglicht. Die
berechneten Ergebnisse der Algorithmen haben dann eine veränderte Farbzuweisung zur Folge, wobei der Benutzer auch alternativ die Farbzuweisung nach seinen
Vorstellungen interaktiv verändern kann und so Teilsysteme, etwa die Triebwerke
eines Flugzeugs betreende Teilsyssteme anders einfärben als solche, die für die
Klimatisierung des Flugzeuginneren zuständig sind.
Abbildung 8.16: Die Visualisierungstechnik CalendarView [Ank04]
Imperfektion im VDM:
Sowohl die kooperative Klassikation als auch das interaktive temporale Data Ming sind inhärent unvollkommen. Denn wie schon oben
erwähnt, ist beim Entscheidungsbaum-Klassikator die Festlegung der Grenze, ab
der bestimmte Daten einer Klasse angehören, teilweise recht schwierig, vor allem
bei diusen, verrauschten Daten. Auÿerdem steckt in der Klasseneinteilung die Unsicherheit, dass nicht alle Daten korrekterweise zu einer Klasse zusammengefasst
werden, sondern dass eben eine festgelegte Schwelle erreicht wurde, sodass ein geringer Prozentsatz in der Klasse eigentlich nicht in diese gehört. Nach auÿen hin
wird diese Art der Imperfektion allerdings nicht repräsentiert, auÿer vielleicht in
einem Bericht, welcher einer Analyse beiliegt und Meta-Informationen enthält,
etwa eben warum gewisse Schwellwerte gewählt wurden, ob die Daten schwer in
Klassen einteilbar waren oder auch ob andere Schwierigkeiten im Zusammenhang
mit Imperfektion auftraten.
Bei der Visualisierungstechnik CalenderView ist die Beschränkung auf einen Tag
als kleinste Einheit grobkörnig gewählt, denn es könnte z.B. eine Rolle spielen, zu
welcher Uhrzeit innerhalb eines Tages ein Wartungsintervall stattndet, etwa bei
Zügen und deren Radreifen. Die Reaktion auf Fehler wäre schneller, wenn die
126
8.4 Einordnung und Vergleich
Routine-Kontrolle früh am Tag erfolgt als Nachts - dieser Unterschied wird aber
nicht visualisiert.
8.3.5 Klassizierung visueller Data Mining Techniken
Die Klassikation in Abbildung 8.17 wurde in [Kei01] eingeführt und ermöglicht
eine orthogonale Einordnung von VDM-Techniken. Damit lassen sich die Visualisierungstechniken, die in dieser Arbeit vorgestellt wurden, in folgendem Koordinatensystem einzeichnen. Der zu visualisierende Datentyp umfasst die verschiede-
Abbildung 8.17: Klassikation visueller DM-Techniken [Kei01]
nen Arten von vorliegenden Daten, von eindimensionalen Daten, wie z.B. mit dem
ThemeRiver visualisierte temporale Daten über multidimensionale Daten etwa aus
relationalen Datenbanken bis hin zu Graphen der Internetstruktur (z.B. SkitterGraph). Die Visualisierungstechniken fangen bei bekannten Techniken wie Säulenoder Kreisdiagrammen an und gehen bis hin zu geschachtelten Visualisierungen,
etwa bei Treemaps.
Mit Interaktions- und Verzerrungstechniken lässt sich das visuelle Data-Mining
vom Benutzer in eine bestimmte Richtung lenken. Hier soll eine Aufzählung von
Verfahren genügen: GrandTour-System (interaktive Projektion), Polaris-System
(interaktive Selektion), spotre-System (interaktives Zooming), Hyperbolic Tree
(interaktive Verzerrung), XGobi System (interakives Linkging and brushing).
8.4 Einordnung und Vergleich
Will man die im zweiten Kapitel vorgestellten Visualisierungstechniken im Verkehrsbereich an Hand der im letzten Kapitel vorgestellten orthogonalen Klassikation einordnen, lassen sich meiner Ansicht nach nur die beiden Achsen zu
visualisierender Datentyp und Visualisierungstechnik genauer eingrenzen, in der
Richtung Interaktions- und Verzerrungstechniken gebe ich nur eine persönliche
127
8 Visualisierung der Imperfektion in multidimensionalen Daten
Einschätzung über nötige und wünschenswerte Interaktionstechniken, da mir diese
Dimension vom Verfahren her nicht eindeutig festgelegt erscheint.
ThemeRiver würde ich in Sachen Interaktions- und Verzerrungstechnik unter
Zoom, bei Datentyp unter eindimensional und bei Visualisierungstechnik unter
Standard 2D/3D Visualisierung einordnen, wobei die Möglichkeit der Interaktion
nicht auf das Zoomen beschränkt sein muss und auch eine Verzerrung nicht ausgeschlossen ist. Zoomen ist aber deshalb wichtig, da es bei groÿen Sammlungen von
Texten erforderlich sein kann, auf der Zeitachse zu zoomen, um damit z.B. kürzere Abschnitte der Schaensphasen eines Schriftstellers oder Politikers genauer zu
analysieren.
Die parallelen Koordinaten müssen mindestens die interaktive Selektion unterstützen, damit die gewünschten Dimensionen ein- und ausgeblendet werden können.
Der Datentyp ist multidimensional und die Visualisierungstechnik ist eine geometrische Transformation. Projektion und Zoom sind bei dieser Technik sinnvolle
Interaktionstechniken - je nach Anwendungszweck und Datenbasis.
Die Table Lens-Technik ist vom Datentyp her multidimensional und als Visualisierungstechnik eine Standard 2D/3D Visualisierung. Als Interaktionstechnik
sollte dem Benutzer auf jeden Fall eine Filter-Möglichkeit an die Hand gegeben
werden, damit er sich z.B. bei sehr vielen Autobahnabschnitts-Daten von verschiedenen Autobahnen nur diejenigen anzeigen lassen kann, die zu der von ihm betrachteten Autobahn gehören. Wie oben schon erwähnt, muss das aber nicht die
einzige Interaktionsmöglichkeit sein; für die Selektion und die Verzerrung sind auch
sinnvolle Anwendungen denkbar, etwa die Auswahl von Strecken, die von Glatteis
betroen sind oder die verzerrte Darstellung z.B. von sehr windigen Streckabschnitten in der Visualisierung, damit sie in der Flut von Streckabschnitten auallen, die
ein Verkehrsingenieur visualisieren lässt.
Die beiden in Kapitel 8.3 vorgestellten VDM-Techniken Kooperative Klassikation und Interaktives temporales Data Mining verwenden beide pixel-basierte
Visualierungstechniken und arbeiten vom Datentyp her mit multidimensionalen
Daten. Die Möglichkeiten zur Interaktion im DataJewel-System (vgl. [Ank04])
sind vielfältig und übersteigen die im Koordinatensystem eingezeichneten Interaktionstechniken sogar. Für beide ist meiner Meinung nach auch eine Anwendung
im Verkehr denkbar. Mit Hilfe der kooperativen Klassikation kann z.B. ein Verkehrswissenschafter Modelle entwickeln an Hand von Daten, die ihm DurchfahrtsMessstellen geliefert haben, um damit bestimmte Stausituationen besser vorhersagen zu können. Auch die Modellierung von sinnvollen Verkehrsregulierungsmaÿnahmen wäre so möglich, z.B. folgendermaÿen: Wenn an einer Messstelle wenige Autos
durchfahren und ihre Geschwindigkeit nahe an der auf diesem Streckenabschnitt
zugelassenen Maximalgeschwindigkeit liegt, könnte man die Geschwindigkeitsbegrenzung aufheben. Wenn allerdings eine bestimmte Schwelle von durchfahrenden
Autos überschritten wird oder auf einem folgenden Abschnitt ein Stau oder ein
Unfall registriert ist, sollte dieses Aufheben unterlassen werden.
Auch das interaktive temporale Data Mining hat meiner Ansicht nach interessante Anwendungsgebiete im Verkehr. Neben der Flugzeugwartung, die bei der
128
8.5 Zusammenfassung und Ausblick
Vorstellung als Beispiel diente, wäre ein solches System auch bei der Auto-Wartung
denkbar, da heutige Fahrzeuge zunehmend komplexer werden und eine Fülle von
Elektronik enthalten, was die Fehlerdiagnose komplexer, durch Einsatz von Computern aber auch automatisierbar macht. Wenn z.B. in der Werkstatt bei einem
Systemcheck bestimmte Fehler aufgedeckt werden, können diese sogleich in einer
Datenbank aufgenommen werden, damit man temporales Data-Mining interaktiv
darauf betreiben kann, um z.B. bestimmte Vermutungen bezüglich des Auftretens
von Störungen oder Pannen zu verizieren oder zu falsizieren. Wenn man etwa den
Verdacht hat, dass eine bestimmte produzierte Serie von Fahrzeugen zu Fehlern
an der Lenksäule neigt, lässt sich durch das interaktive temporale DM feststellen,
ob die Werkstattdaten aller Werkstätten in Deutschland diesen Verdacht erhärten
können, indem der Data-Mining-Benutzer geschickt Modell-Reihe, Serie und betrachtetes Zeitintervall eingrenzt und so eine aussagekräftige Visualisierung erhält,
die Aufschluss über auällige Reparaturhäugkeiten gibt.
8.5 Zusammenfassung und Ausblick
In dieser Seminararbeit wurden zunächst Visualisierungstechniken aus dem Straÿenverkehrsbereich sowie Kriterien für deren Klassikation vorgestellt, mit denen
die Techniken bewertet wurden. Anschlieÿend wurden die um Imperfektion erweiterten Techniken und deren Bewertung vorgestellt. Das dritte Kapitel umfasst die
Einführung in das Visual Data Mining und dessen drei verschiedene Ansätze sowie
die Vorstellung zweier konkreter Techniken des Visual Data Mining und gibt eine
Klassikationsmöglichkeit an, die auf alle in dieser Arbeit besprochenen fünf Techniken angewendet wird, nämlich ThemeRiver, Parallele Koordinaten, Table Lens,
Kooperative Klassikation und Interaktives Temporales Data Mining. Ferner wurde gezeigt, dass den beiden letztgenannten, zum kooperativen Data Mining zählenden VDM-Verfahren, ein gewisses Maÿ an Imperfektion bereits im Verfahren
innewohnt, ohne dass die Imperfektion bewusst in die Verfahren integriert worden
wäre. Spätestens da, wo klare Grenzen werden müssen, die letztlich willkürlich sind,
ndet keine perfekte Abbildung der Wirklichkeit mehr statt, sodass man es mit
unsicheren, unscharfen oder ungenauen Modellen zu tun hat wie beispielsweise mit
der Unschärfe im Falle des Entscheidungsbaumklassikators oder der Ungenauigkeit bei CalendarView. Allerdings erscheint es wiederum notwendig, dass bei der
Abstraktion von den Einzeldaten, wie sie bei der Klassikation durchgeführt wird,
eine Reduktion von Klassen stattndet, welche fast immer mit einem Informationsverlust einhergeht und damit mit Imperfektion. Diesen Preis ist man aber häug
bereit zu zahlen, um Informationen überhaupt erst beherrschbar und überschaubar
zu machen. Den Lerneekt in diesem Seminarthema sehe ich vor allem darin, dass
der Blick darauf geschärft wird, was bei Visualisierungen weggelassen wird und was
in den Vordergrund gerückt wird. Letztendlich ist jede Form der Visualisierung nur
ein Modell, ein Ausschnitt desssen, was an Informationen in einem (multidimensionalen) Datensatz vorhanden ist. Die Erweiterung von bestehenden Techniken um
129
8 Visualisierung der Imperfektion in multidimensionalen Daten
Imperfektion ist daher vor allem sinnvoll, um dem Betrachter von Visualisierungen
vor Augen zu führen, an welchen Stellen bekanntermaÿen unsichere, unscharfe oder
ungenaue Daten visualisiert werden, damit er sich ein fundierteres Bild über den
Informationsgehalt der visualisierten Daten machen kann. Lässt man die Imperfektion bei der Darstellung nämlich auÿer Acht, so kann es den Anschein machen, als
beruhte die Visualisierung auf sicheren Daten, was zu falschen Erkenntnissen beim
Betrachter führen kann.
Die Integration von Data-Mining-Algorithmen und Visualisierungstechniken
beim interaktiven bzw. kooperativen Data Mining lässt auch in Zukunft noch genug Raum für Forschungen, da für interaktive Anwendungen die bestehenden Data
Mining Algorithmen dahingehend umgeformt werden müssen, dass sie in wenigen
Sekunden Zwischenergebnisse liefern, damit für den Benutzer die Verzögerungen
beim Arbeiten akzeptabel bleiben. Diese Verkürzung der Laufzeiten auf der einen
Seite und das Ausloten der Möglichkeiten (und Grenzen) des kooperativen Data
Mining auf der anderen Seiten sind zwei interessante Forschungsfelder auf Gebiet
der Informationsgewinnung.
Das kooperative Data Mining ist heutzutage vor allem deshalb interessant, weil
der menschliche Intellekt beim Aunden von Mustern dem Computer noch einiges voraus hat bzw. weil der Mensch weiÿ, in welche Richtung er die Suche
nach Informationen in einer Unmenge von Daten lenken will. Spannend ist daher
auch die Frage, inwieweit dem Computer diese Zielstrebigkeit beigebracht werden
kann, damit er selbst Informationen in groÿen Datenmengen zu erkennen und zu
verknüpfen vermag - ganz ohne Benutzerinteraktion.
130
Matthias Biehl
9
Stream Clustering
Zahlreiche Anwendungen erzeugen oder verarbeiten groÿe Datenmengen, die in
Form von Datenströmen anfallen. In den meisten Datenströmen gibt es innere
Zusammenhänge zwischen den enthaltenen Daten, die auf den ersten Blick nicht
ersichtlich sind. Analysten haben Interesse daran, solche Zusammenhänge aufzudecken, um diese zur Bewertung und Entscheidungsndung heranzuziehen. So können beispielsweise Finanz-Analysten ihr Kauf- und Verkaufsentscheidungen treen,
nachdem siedie Zusammenhänge in den Transaktionsströmen von Finanzmärkten
analysiert haben.
Stream Clustering Algorithmen können solche Zusammenhänge in Datenströmen erkennen. Zu jedem Zeitpunkt nden sie aktuelle Zusammenhänge der Daten
und bewahren diese für spätere Analysen in einer Historie auf. In diesem Kapitel
beschäftigen wir uns im Detail mit Stream Clustering Algorithmen.
9.1 Einleitung
Wenn wir in Datenströmen nach wertvollen Zusammenhängen zwischen Datenpunkten suchen, setzen wir Clustering als Technik ein. Durch die identizierten
Zusammenhänge können die Daten zu jedem Zeitpunkt in Gruppen von ähnlichen
Datenpunkten partitioniert werden.
Unter den Randbedingungen der Datenströme entstehen neue Herausforderungen für das bekannte Clustering Problem. Die Datenpunkte müssen ezient verarbeitet werden, um jederzeit eine vollständige Gruppierung zur Verfügung zu stellen.
Eine Unterscheidung der Daten nach ihrem Alter ist unabdingbar, um die Aktualität der Gruppierung zu erhalten. Stream Clustering Algorithmen nden auch unter
den Randbedingungen der Datenströme qualitativ hochwertige Gruppen.
131
9 Stream Clustering
9.1.1 Praktische Anwendungen
Das Finden von Zusammenhängen in Datenströmen ist ein Problem aus der Praxis. Es gibt zahlreiche Anwendungen, welche die praktische Relevanz des Problems
verdeutlichen. Wenn sehr viele Daten analysiert werden müssen, die über die Zeit
hinweg anfallen, handelt es sich um eine potentielle Anwendung von Stream Clustering.
Bei der Intrusion Detection werden Muster von Netzwerkverbindungen auf feindseliges Verhalten untersucht. Auf Stream Clustering basierte Intrusion Detection
Systeme sind bereits implementiert [AHWY03]. Eine andere Anwendung wird in
[DH00] vorgestellt: Ein Stream Clustering System zur Analyse von Webseitenzugrien. Weitere Anwendungen liegen in der Analyse von Finanzmarktdaten, im
Marketing, der Astronomie und Medizin.
9.1.2 Überblick über dieses Kapitel
In Abschnitt 9.2 beschreiben wir kurz die Grundlagen für herkömmliches Clustering. Wir analysieren die Eigenschaften von Datenströmen und leiten daraus in
Abschnitt 9.3 allgemeine Lösungsansätze ab. Diese konkretisieren wir in den nächsten Abschnitten 9.4 und 9.5, wenn wir uns beispielhaft mit zwei Stream Clustering
Algorithmen beschäftigen, die ihre Stärken im Umgang mit der Evolution in Datenströmen und in der Verarbeitung von hochdimensionalen Daten haben. Wir
stellen in Abschnitt 9.6 zuerst Bewertungsmethoden vor, führen eine Bewertung
durch und schlieÿen mit einer Zusammenfassung in Abschnitt 9.7.
9.2 Grundlagen
In diesem Abschnitt führen wir einige grundlegende Begrie für herkömmlichen
Clustering ein.
Datenpunkte sind die Vektoren, die wir mit einem Clustering Algorithmus analysieren. Sei K = {K1 , ..., Kn } eine Menge von Datenpunkten. Als Clustering
bezeichnen wir eine Menge von k Teilmengen C = {C1 , ..., Ck } von K mit den
Eigenschaften Konsistenz (9.1) und Vollständigkeit (9.2). Dabei ist jedes Ci ein
Cluster.
∀i, j mit i 6= j, 1 ≤ i ≤ k, 1 ≤ j ≤ k : Ci ∩ Cj = ∅
k
[
Ci = K
(9.1)
(9.2)
i=1
Im Raum der Datenpunkte können wir ein Abstandsmaÿ denieren, durch das
der Abstand d(Ki , Kj ) zweier Punkte Ki und Kj berechnet werden kann. Ein
Beispiel für ein Abstandsmaÿ ist die euklidische Distanz.
132
9.3 Stream Clustering
Das Ziel von Clustering Algorithmen ist es, ein Clustering mit möglichst hoher
Qualität zu nden. Die Qualität wird anwendungsspezisch festgelegt, üblich ist
ein abstandsbasiertes Qualitätsmaÿ. Es deniert hohe Qualität durch minimalen
Abstand der Datenpunkte innerhalb eines Clusters und maximalen Abstand der
Datenpunkte zu anderen Clustern.
Mithilfe einer Turing Reduktion lässt sich beweisen, dass herkömmliches Clustering ein NP-hartes Problem ist [GJ79, S. 281]. Praktisch verwendbare Clustering
Algorithmen garantieren daher keine optimale Lösung, sondern sind Heuristiken.
Es gibt zahlreiche Algorithmen für das herkömmliche Clustering Problem, bekannt
ist etwa der K-Means Algorithmus. Eine Übersicht über weitere Algorithmen ndet
man in [KR90] [Har75] und [JD88].
Eingesetzt werden Clustering Algorithmen, wenn man eine Zerlegung der Datenmenge in Gruppen ähnlicher Datenpunkten erstellen möchte, bzw. Datenpunkte
zu Gruppen zusammenfassen möchte. Die Ziele und Anforderungen der herkömmlichen Clustering Algorithmen gelten auch für Stream Clustering Algorithmen. Letztere werden jedoch wie im nächsten Kapitel beschrieben um weitere Anforderungen ergänzt.
9.3 Stream Clustering
In diesem Abschnitt betrachten wir das Stream Clustering Problem näher und stellen einfache Lösungsansätze vor. Zunächst analysieren wir die Eigenschaften von
Datenströmen, um daraus die Anforderungen an Stream Clustering Algorithmen
zu erarbeiten. Anhand abstrakter Lösungsansätze präsentieren wir die Konzepte,
die Stream Clustering Algorithmen einsetzen, um den Anforderungen unter den
gegebenen Randbedingungen zu genügen.
9.3.1 Eigenschaften von Datenströmen
Datenströmen zeichnen sich vor allem durch ihre zeitliche Dynamik aus. Zu beliebigen Zeitpunkten kann der Datenstrom neue Daten liefern und dadurch das Bild
der gesamten bisher angefallenen Daten verändern. Diese Veränderung der Daten
über die Zeit wird als Evolution bezeichnet. Während die Evolution sich mit der
gegenwärtigen Entwicklung der Daten befasst, ist die Historie ein Rückblick auf
die bisher angefallenen Daten. Man kann dabei sowohl die Historie der Streamdaten als auch die Historie der Cluster betrachten. Analysten verwenden beide
Arten, um die Entwicklung des Datenstroms über einen gewissen Zeithorizont zu
untersuchen.
Da Streamdaten zu einem gewissen Zeitpunkt anfallen, ist der Verarbeitungszeitpunkt der Daten durch den Datenstrom vorgegeben. Auf Streamdaten können
wir nicht wahlfrei zugreifen, sondern nur in der vom Datenstrom vorgegebenen
Reihenfolge.
Die hier betrachteten Datenströme enden nicht in absehbarer Zeit, vielmehr
müssen wir davon ausgehen, dass sie für eine beliebig lange Zeit zu analysierende
133
9 Stream Clustering
Daten liefern. Sammeln wir die anfallenden Daten über die Zeit, um etwa die
Historie abzuspeichern, so erhalten wir groÿe Datenmengen. Die Datenrate des
Stroms bestimmt die Wachstumsgeschwindigkeit der aggregierten Datenmenge.
Die Haupteigenschaft von Streamdaten ist die zeitliche Komponente, verbunden
mit der eingeschränkten Zugfrismöglichkeit und der Kontinuität [OMM+ 02].
9.3.2 Aufgaben von Stream Clustering
Stream Clustering Algorithmen haben zwei Aufgaben zu bewältigen: Zum Einen
müssen sie zu jedem Zeitpunkt ein aktuelles Clustering zur Verfügung zu stellen.
Auÿerdem müssen sie Analysen über die Historie des Datenstroms für einen gegebenen Zeitrahmen unterstützen [AHWY03]. Dazu muss der Stream Clustering
Algorithmus eine sinnvolle Menge historischer Daten speichern.
9.3.3 Eignung herkömmlicher Algorithmen
Würden wir für unsere Aufgaben herkömmliche Algorithmen einsetzen, müssten
alle zu analysierenden Daten zu Beginn des Clustering Vorgangs feststehen, d.h. die
Daten müssten statisch sein. Auÿerdem bestehen die herkömmlichen Algorithmen
oft aus mehreren Iterationen und benötigen wahlfreien Zugri auf die Daten. Die
Speicher und Zeitkomplexität herkömmlicher Algorithmen ist in O(n2 ) und damit
für schnelle Datenströme zu hoch.
All diese Eigenschaften sind für die Verarbeitung von Streamdaten ungeeignet
uns verbieten den Einsatz herkömmlicher Clustering Algorithmen für Datenströme. Somit kann das Stream Clustering Problem nicht durch eine Variante der
herkömmlichen Clustering Algorithmen gelöst werden, sondern erfordert neue Lösungsansätze. [OMM+ 02]
9.3.4 Allgemeine Lösungsansätze
Aus den Eigenschaften der Streamdaten ergeben sich einige allgemeine Lösungsansätze. Diese kann man in unterschiedlicher Ausprägung in vielen Stream Clustering
Algorithmen nden.
Um kontinuierlich ein aktuelles Clustering bereitstellen zu können, muss ein neu
eintreender Datenpunkt ezient verarbeitet werden. Die zur Verfügung stehende
Bearbeitungszeit für das Clustering ist durch die Zeitspanne begrenzt, die zwischen
dem Eintreen aufeinander folgender Datenpunkte liegt, durchschnittlich ist diese
Zeit umgekehrt proportional zur Datenrate des Stroms. Während der naive Ansatz
zu jedem Zeitpunkt ein komplett neues Clustering erstellt, fügen Stream Clustering
Algorithmen den neuen Datenpunkt nur zu einem bestehenden Cluster hinzu. So
kann das Cluster zum Zeitpunkt t durch einfache Operationen und mit geringem
Zeitaufwand aus dem Cluster zum Zeitpunkt t − 1 gebildet werden.
Für die meisten Algorithmen gilt die Annahme, dass nur ein begrenzter Speicher für die aktuellen Cluster zur Verfügung steht. Um Platz für neue Daten zu
134
9.4 Evolution von Datenströmen
schaen, müssen alte Daten aus dem begrenzten Speicher verdrängt werden. Dadurch werden zwei Ziele umgesetzt: Der Bestand an vorhandenen Clustern wird
durch die Verdrängung stets aktuell gehalten, gleichzeitig ist die Speicherkomplexität der beim Clustering berücksichtigten aktuellen Daten konstant. Somit ist auch
die Laufzeit des Einfügens durch eine Konstante beschränkt.
Neben den aktuellen Daten müssen auch die historischen Daten verwaltet werden.
Obwohl die Laufzeit nicht von deren Datenmenge abhängt, muss ihr Wachstum
kontrolliert und auf ein sinnvolles Maÿ beschränkt werden. Dazu werden selektiv
alte Daten aus der Historie vergessen, während die Historie periodisch durch
jeweils aktuelle Einträge fortgeschrieben wird. Ein solches Konzept zum selektiven
Vergessen betrachten wir in Abschnitt 9.4.2 beispielhaft anhand der Pyramidal
Time Frame.
9.4 Evolution von Datenströmen
In diesem Abschnitt beschreiben wir den CluStream Algorithmus, einen Stream
Clustering Algorithmus, der besonders dazu geeignet ist, die Evolution von Datenströmen zu erfassen [AHWY03]. Wir beschreiben im Folgenden zunächst die
Architektur von CluStream wie sie in Abbildung 9.1 dargestellt ist, später gehen
wir auf die Bestandteile im Detail ein.
Die Architektur orientiert sich an den Aufgaben von Stream Clustering (siehe
Abschnitt 9.3.2), und zerlegt den Algorithmus in zwei Komponenten: Eine Online Komponente fasst die Stromdaten kontinuierlich zusammen und bildet kleine
Cluster, sogenannten Mikrocluster. Alle aktuellen Mikrocluster des Systems werden
periodisch als Zwischenergebnisse abgespeichert. Dazu wird der Zustand des Systems in einem Bild festgehalten und als Snapshot gespeichert. Stellt der Analyst
Anfragen an das System, so nutzt er die Oine Komponente mit dem Makroclustering Algorithmus. Dieser verwendet die Snapshots und ist somit vom Datenstrom
entkoppelt.
9.4.1 Mikroclustering
Beim Mikroclustering verarbeiten wir die Daten des Stroms vor, indem wir sie auf
feingranularer Ebene zu Mikroclustern zusammenfassen. Die maximale Anzahl von
Mikroclustern ist beschränkt und wird durch eine Verdrängungsstrategie auf gleich
bleibendem Niveau gehalten.
In der Datenstruktur, die jedes Mikrocluster beschreibt, speichern wir neben
einer ID lediglich statistische Daten des Clusters, die einzelnen Datenpunkte jedoch
nicht (siehe Abbildung 9.2). Für jede Dimension speichern wir die Summe der
entsprechenden Werte der Datenpunkte, ebenso die Summe der Quadrate. Soweit
entspricht die Datenstruktur dem Cluster Feature Vector des BIRCH Algorithmus
[ZRL96]. Zusätzlich nehmen wir im Mikrocluster die Summe der Zeitstempel und
die Summe der Quadrate der Zeitstempel auf.
135
9 Stream Clustering
Abbildung 9.1: Architektur des CluStream Algorithmus
Abbildung 9.2: Mikrocluster Datenstruktur
Durch diesen Aufbau sind die Mikrocluster subtraktiv. Diese Eigenschaft ermöglicht es uns, Änderungen in einem Mikrocluster ausndig machen, indem wir die
Dierenz aus zwei Mikroclustern berechnen.
Die Datenstruktur erlaubt inkrementelle Updates, da ein neuer Datenpunkt mit
einfachen Operationen zu einem bestehenden Mikrocluster hinzugefügt werden
kann. Die Werte des neuen Datenpunktes addieren wir zu den Summen entsprechender Dimension im Mikrocluster.
In Abbildung 9.3 stellen wir den im folgenden beschriebene Algorithmus visuell
dar. Das Mikroclustering ordnet ein neu angekommenes Datum aus den Strom
entweder einem bestehenden Cluster zu oder erstellt ein neues Cluster, abhängig
vom Abstand zwischen Cluster und neuem Datum. Da die Anzahl der Cluster
nach oben begrenzt ist, muss beim Erstellen eines neuen Clusters möglicherweise
ein altes Cluster verdrängt werden. Die Verdrängung wird abhängig von Mittelwert
und Varianz der Zeitangaben im ältesten Cluster durch zwei Arten realisiert: Ist das
136
9.4 Evolution von Datenströmen
Abbildung 9.3: Zustandsdiagramm zum Mikroclustering
durchschnittliche Alter innerhalb gewisser Grenzen, wird das älteste Cluster mit
dem nächsten Cluster verschmolzen, andernfalls wird das älteste Cluster gelöscht.
9.4.2 Pyramidal Time Frame
Es ist Aufgabe des Stream Clustering Algorithmus, eine sinnvolle Menge historischer Daten zu speichern. Dazu erstellen wir periodisch einen Snapshot und reihen
ihn in eine Historie ein.
Würden wir alle historischen Daten abspeichern, könnten wir eine hohe Präzision
erreichen, jedoch würde die Datenmenge linear d.h. zu schnell anwachsen. Würden
wir andererseits nur wenige Daten abspeichern, so würde dies in einer langsamen
Anpassung des Clusterings an einen sich schnell ändernden Datenstrom resultieren.
Die Anpassung des Clusterings erfolgt in diesem Fall verzögert, da historische
Daten das Clustering dominieren.
CluStream löst dieses Problem, indem er nur die Snapshots ausgewählter Zeitpunkte speichert und alle übrigen eliminiert. Die Pyramidal Time Frame bestimmt
für jeden aktuellen Zeitpunkt ti die Menge der historischen Zeitpunkte, deren Daten zum Zeitpunkt ti gespeichert sein sollen. Diese Menge von historischen Zeitpunkten bezwichnen wir als Historie Hti . Sie ist unabhängig von den Daten. An der
beispielhaften Historie H55 in Abbildung 9.5 erkennt man, dass die berechneten
Zeitpunkte in der jeweils jüngsten Vergangenheit sehr dicht und mit zunehmendem
Alter weiter auseinander liegen.
Die Pyramidal Time Frame sorgt dafür, dass die Historie Hti durch Filtern der
Historie Hti−1 entstehen kann. Beim Übergang vom Zeitpunkt ti zu ti+1 werden
keine zusätzlichen Daten aus der Vergangenheit benötigt. Dies kann man anhand
137
9 Stream Clustering
Abbildung 9.4: Historie H17
Abbildung 9.5: Historie H55
der Abbildungen 9.4 und 9.5 nachvollziehen: Die Historie H55 hat im Intervall
[1, 17] nur noch eine Teilmenge der Zeitpunkte ihrer früheren Historie H17 und
keine zusätzlichen Zeitpunkte.
Eine wichtige Eigenschaft der Pyramidal Time Frame ist ihr logarithmisches
Wachstum. Für die Anzahl n der Daten aus dem letzten a + 1 Zeitpunkten gilt
n = |loga (t)| ∗ (a + 1) ∈ O(log(t))
(9.3)
wobei a eine Konstante des Systems ist. Wichtig ist, dass die Historie lediglich
logarithmisch wächst. Verwaltungstechnisch teilen wir die Zeitpunkte der Historie
138
9.5 Projected Clustering für hochdimensionale Datenströmen
in verschiedene Ordnungen o(t) ein. Es gilt
o(t) = maxi (i|(t mod ai ) = 0)
(9.4)
Je höher die Ordnung ist, desto länger bleibt der Zeitpunkt in der Historie.
9.4.3 Makroclustering
Die Snapshots bilden die Schnittstelle zwischen Mikroclustering und Makroclustering. Während sie beim Mikroclustering erstellt werden, können sie beim Makroclustering als Zwischenergebnisse verwendet werden, um ein benutzerdeniertes
Clustering zu erstellen. Für ein benutzerdeniertes Clustering gibt der Anwender
lediglich die Anzahl der Cluster sowie den zu untersuchenden Zeithorizont vor.
Bei einer solchen Anfrage ermitteln wir in einem ersten Schritt die vorhandenen
Snapshots, die möglichst nahe am Anfang und Ende des angefragten Zeithorizonts
liegen. Dabei garantiert die Pyramidal Time Frame, dass eine gute Approximation von Snapshots für das gegebene Zeitintervall gefunden werden kann. Durch
die Subtraktivität der in den Snapshots enthaltenen Mikrocluster und durch die
konsistente Benennung können wir für den angegebenen Zeithorizont sowohl neue
Mikrocluster, als auch Änderungen an bestehenden Mikroclustern ermitteln. Auf
diesen Daten wenden wir ein herkömmliches Clustering Verfahren an, etwa ein KMeans Algorithmus. Dabei erstellen wir aus den feingranularen Mikroclustern ein
Clustering mit benutzerdenierter Granularität.
9.5 Projected Clustering für hochdimensionale
Datenströmen
Der in Kapitel 9.4 vorgestellte CluStream Algorithmus liefert bei hochdimensionalen Daten i.A. nur unzureichende Ergebnisse. Wir stellen im Folgenden den
HPStream Algorithmus, eine Erweiterung von CluStream vor, der auch mit hochdimensionale Datenströmen umgehen kann [AHWY04].
9.5.1 Projected Clustering
Ausgangspunkt der Stream Clustering Algorithmen sind die Datenpunkte des
Stroms. Als Vektoren besitzen die Datenpunkte Werte in mehreren Dimensionen.
Bei einer groÿen Anzahl von Dimensionen kann der Algorithmus die Charakteristika einzelner Datengruppen nicht erkennen, wenn er alle Dimensionen gleichermaÿen berücksichtigt.
Beim Projected Clustering Ansatz [APW+ 99] für statische Daten, wird für jedes
Cluster nur eine Teilmenge aller Dimensionen betrachtet. Die geeigneten Dimensionen werden fortlaufend für jedes Cluster ermittelt, wobei die durchschnittliche
Anzahl der Dimensionen konstant ist.
139
9 Stream Clustering
Der Algorithmus verwendet ein projiziertes Abstandsmaÿ, die Manhattan Segmental Distance MSD. Sie berechnet den Abstand eines Datenpunktes x vom Mittelpunkt m eines Clusters, indem der Abstand für jede der Dimensionen aus der
Menge D separat berücksichtigt wird.
P
(xd − md )
M SD = d∈D
(9.5)
|D|
Der Projected Clustering Ansatz löst zwei Probleme: Das Finden von Clustern
und das Bestimmen der Dimensionen, auf denen die Cluster deniert sind. Im
Folgenden stellen wir einen Projected Clustering Algorithmus für Streamdaten
vor.
9.5.2 HPStream Algorithmus
Das vorgestellte Konzept des Projected Clusterings ist im HPStream Algorithmus
[AHWY04] umgesetzt, der eine Erweiterung des CluStream Algorithmus aus Abschnitt 9.4 ist.
Im Folgenden beschreiben wir detaillierter zwei wichtige Phasen des Algorithmus:
Die Initialisierungsphase und die Schritte bei der Ankunft eines neuen Datenpunktes.
Initialisierungsphase
Im Verlauf des Algorithmus werden Werte unterschiedlicher Dimensionen verglichen. Um den Skalen der unterschiedlichen Dimensionen gerecht zu werden, normiert der Algorithmus die Werte der unterschiedlichen Dimensionen mit Hilfe der
Standardabweichung der jeweiligen Dimension. Diese Normierung wird periodisch
wiederholt, um an die aktuellen Datenpunkte angepasst zu sein.
Schritte bei der Ankunft eines neuen Datenpunktes
Bei der Ankunft eines neuen Datenpunktes aus dem Stream durchläuft der Algorithmus drei Schritte:
1. Bestimme die Dimensionen für jedes Cluster:
Wir fügen den neuen Datenpunkt probeweise zu jedem bestehenden Cluster
hinzu. Für jedes Cluster wählen wir die Dimensionen aus, durch die alle Datenpunkte des Clusters beschrieben werden können und den kleinsten Radius
ermöglichen.
2. Finde das nächste Cluster:
Das nächste Cluster ist dadurch bestimmt, dass der Abstand des Datenpunktes vom Mittelpunkt aller Datenpunkte des Clusters am geringsten ist. Zur
Abstandsberechnung wird die Manhattan Segmental Distance genutzt. Um
den Mittelpunkt zu berechnen, sind die Daten des Mikroclusters ausreichend.
140
9.6 Bewertung
3. Füge zum Cluster hinzu oder erstelle ein neues Cluster:
Nachdem das potentielle Cluster des neuen Datenpunktes feststeht, entschieden wir, ob der Datenpunkt dem Cluster zugeordnet wird oder ein neues
Cluster bildet. Mit Hilfe der statistischen Daten aus dem Mikrocluster berechnen wir den Radius des Clusters mit dem neuen Datenpunkt. Ist der
Radius unterhalb einer Schwelle, fügen wirke den Datenpunkt zum Cluster
hinzu, ansonsten ist der neue Datenpunkt zu weit von den restlichen Datenpunkten entfernt und wir erstellen ein neues Cluster für ihn.
Beim Erstellen eines neuen Clusters müssen wir beachten, dass die Anzahl
der Cluster beschränkt ist. Daher verdrängen wir entweder ein altes Cluster
oder verschmelzen zwei benachbarte Cluster. Entscheidend ist wie weit die
letzten Änderungen ám Cluster zurückliegen; sind sie gröÿer einer Schwelle,
wird verdrängt, ansonsten verschmolzen.
Zusätzlich ersetzen wir die Pyramidal Time Frame durch ein verallgemeinertes
Modell, die Fading Cluster Structure. Sie ordnet jedem Datenpunkt eine über die
Zeit hinweg exponentiell fallende Gewichtungsfunktion zu. In diesem Algorithmus
verwenden wir wie in CluStream die Mikrocluster-Datenstruktur, jedoch ersetzen wir die einfachen Summen durch gewichtete Summen. Die Gewichte bestimmen
wir mit Hilfe der Fading Cluster Structure. Zusätzlich enthält das Mikrocluster
einen Bitvektor, der die projizierten Dimensionen des Clusters angibt.
9.6 Bewertung
Als Heuristiken liefern Stream Clustering Algorithmen eine Näherung an das theoretisch erreichbare, optimale Ergebnis. Es gibt einen Tradeo zwischen der Güte
des Ergebnis und der benötigten Rechenzeit. Beide Gröÿen können wir anhand verschiedener Kriterien messen, zu einander in Beziehung setzen und bewerten. Auf
diese Weise können wir sowohl verschiedene Algorithmen vergleichen, als auch den
selben Algorithmus mit unterschiedlichen Parametern.
In diesem Abschnitt stellen wir zunächst die Infrastruktur zur Bewertung vor:
Bewertungskriterien und gängige Bewertungsmethoden für Stream Clustering. Anschlieÿend zeigen wir beispielhaft eine Bewertungen der in Abschnitt 9.4 und 9.5
vorgestellten Algorithmen CluStream und HPStream.
9.6.1 Bewertungskriterien
Die Bewertung von Stream Clustering Algorithmen erfolgt anhand der Kriterien
Ezienz, Skalierbarkeit und Qualität. Die Ezienzbewertung setzt sich aus der
Bewertung von Speicherplatz und Rechenzeit zusammen. Bei der Skalierbarkeit
betrachtet man die Anzahl der verarbeiteten Datensätze pro Zeiteinheit, um so
die maximal verarbeitbare Datenrate zu ermitteln. Die Qualität des Clusterings
ist das wichtigste und gleichwohl am schwersten zu bewertende Kriterium.
141
9 Stream Clustering
Abbildung 9.6: Sum of Square Distances am Beispiel
9.6.2 Bewertungsmethoden
Für die Qualitätsbewertung stehen zwei grundsätzlich verschiedene Methoden zur
Verfügung: Die Bewertung der Cluster anhand von Maÿen und die manuelle Ergebnisbewertung aus Anwendersicht. Aus Anwendersicht steht die Nützlichkeit der
Cluster im Mittelpunkt. Hier wertet ein Experte die Ergebnisse manuell aus, interpretiert sie und bewertet sie mit Hilfe seines Kontextwissens. Dem gegenüber
bieten Maÿzahlen eine objektive Vergleichsmöglichkeit, da sie berechnet werden.
Die Formeln der Maÿzahlen verwenden Abstandsmaÿe, so z.B. die Sum of Square
Distances (SSQ). Sie bewertet die Dichte der Datenpunkte innerhalb eines Clusters.
Angestrebt wird eine hohe Datendichte im Cluster bzw. eine geringen SSQ.
SSQ =
k X
X
d2 (x, Ki )
(9.6)
i=1 x∈Ni
mit Ni = {x ∈ K|∀j : d(Kj , x) ≤ d(Ki , x)}1
(9.7)
9.6.3 Datenauswahl
Angestrebt wird eine Objektivität der Bewertung. Dafür ist die Auswahl und Breite der untersuchten Daten entscheidend. Man dierenziert zwischen synthetische
Daten und natürlichen Daten. Synthetische Daten werden generiert und können
dadurch steuerbare Eigenschaften haben. So ist es möglich, das korrekte Clustering
der Daten zu kennen und das Ergebnis des Algorithmus mit dieser autoritativen
Referenz zu vergleichen. Ferner werden natürliche Daten verwendet, die aus realen
Anwendungsszenarien stammen. Standardisierte natürliche Daten erlauben einen
Vergleich unterschiedlicher Algorithmen. Für Stream Clustering hat sich ein Datensatz für Intrusion Detection des KDD-CUP'99 [clu] als Quasi-Standard etabliert.
9.6.4 Bewertung der vorgestellten Algorithmen
CluStream
Im Folgenden betrachten wir beispielhaft zwei Bewertungen für den CluStream
Algorithmus.
1
Siehe Variablendeklarationen in 9.2
142
9.6 Bewertung
Abbildung 9.7: Qualitätsvergleich (aus [AHWY03])
Abbildung 9.8: Verarbeitet Datenrate (aus [AHWY03])
In Abbildung 9.7 zeigen wir eine relative Qualitätsbewertung. Hier vergleichen
wir anhand der SSQ Maÿzahl die Ergebnisse von CluStream mit denen des Algorithmus STREAM über unterschiedliche Zeithorizonte. Der vergleichsweise niedrige SSQ Wert von CluStream deutet auf höherwertige Clusteringergebnisse hin.
Die nächsten Bewertung behandelt die Skalierbarkeit. Wir zeigen in Abbildung
9.8 die verarbeitet Datenrate in Abhängigkeit von der Zeit, wiederum im Vergleich
zum STREAM Algorithmus. Die verarbeitete Datenrate des Streams ist nicht konstant, sondern steigt anfangs bis die initialen Mikrocluster erstellt sind und ist
danach nahezu konstant.
Die Autoren von [AHWY03] haben weitere vergleichende Messungen durchgeführt und kommen zu dem Schluss, dass CluStream eine vergleichsweise hohe Clusterqualität liefert, eektiv arbeitet und linear skalierbar ist.
143
9 Stream Clustering
HPStream
Ähnliche Untersuchungen wurden für den HPStream Algorithmus auf den gleichen
Daten durchgeführt.
In Abbildung 9.9 zeigen wir durch einen Vergleich der SSQ Maÿzahl, dass die
Qualität von CluStream durch die von HPStream übertroen wird.
Bei steigender Dimensionalität der Daten, steigt auch der Aufwand des Projected Clusterings. Die in Abbildung 9.10 dargestellte Untersuchung zeigt, dass die
Laufzeit linear von der Dimensionalität abhängt. Der HPStream Algorithmus ist
linear skalierbar in der Anzahl der Dimensionen. Andere Untersuchungen ergaben
auch eine lineare Skalierbarkeit in der Anzahl der Cluster im System.
Abbildung 9.9: Qualität von HPStream und CluStream (aus [AHWY04])
Abbildung 9.10: Skalierbarkeit und Datenrate (aus [AHWY04])
9.7 Zusammenfassung
Stream Clustering ist eine Technik mit der wir Zusammenhänge in schnellen Datenströmen erkennen können. Wir lösen damit zum Einen die Aufgabe, zu jedem
144
9.7 Zusammenfassung
Zeitpunkt ein Clustering zur Verfügung zu stellen, das die Zusammenhänge der
aktuellen Datenpunkte beschreibt. Zum Anderen verwalten wir die historischen
Zusammenhänge für Analysen. In diesem Kapitel haben wir sowohl allgemeine
Lösungsansätze entwickelt, als auch konkrete Stream Clustering Algorithmen vorgestellt und bewertet. Durch diese Algorithmen können wir interessante, neue Anwendungen zur Analyse von Datenströmen realisieren.
145
9 Stream Clustering
146
10
Process Mining
Process Mining (auch: Workow Mining) wird das Verfahren genannt, aus Aufzeichnungen von Arbeitsabläufen (Workow Logs/Process Log) ein Modell des zu
Grunde liegenden Arbeitsprozesses zu erstellen. Das Modell des Arbeitsprozesses
kann unter anderem zur Analyse und Optimierung der Arbeitsprozesse genutzt
werden. Thematisch gehört Process Mining in den Beriech der Business Process
Intelligence (BPI) [vdAvDH+ 03].
10.1 Einleitung
10.1.1 Motivation
In vielen Bereichen der Wirtschaft sind heute viele Personen an einem einzigen Prozess beteiligt. Das Wissen über den Prozess ist auf die vielen Beteiligten verteilt
und daher kann die Prozessstruktur nur aufwendig bestimmt werden. Bisher war
es zum Erstellen von Workow-Netzen üblich die dazu notwendigen Informationen
durch Mitarbeiterbefragungen zu erhalten. Dies ist eine zeitraubende und damit
auch teure Vorgehensweise. Process Mining ist hier ein Hilfmittel, diese Arbeit weitgehend zu automatisieren. Es unterstützt sowohl die Prozessmodellierung als auch
die Prozessanalyse. Auch Process Mining ist noch aufwendig, aber gerade wenn
in regelmäÿigen Abständen aus der gleichen Datenbasis die aktuellen Daten zu einem Workow-Netz verarbeitet werden sollen, um zum Beispiel die Auswirkungen
organisatorischer Maÿnahmen auf die Arbeitsprozesse zu kontrollieren, bietet das
Process Mining einen groÿen Vorteil.
147
10 Process Mining
case id task id
case
case
case
case
case
case
case
1
2
2
1
2
2
1
task
task
task
task
task
task
task
A
A
B
C
B
D
D
Tabelle 10.1: Beispiel eines einfachen Ablaufprotokolls
10.1.2 Ziel
Das Ziel des Process Mining ist ein Modell des Arbeitsprozesses zu erstellen, dass
die Aktivitäten und ihre Abhängigkeiten darstellt. Ausgehend von einem Ablaufprotokoll (Process Log), werden die darin gespeicherten Aktivitäten (Tasks) in
kausale Zusammenhänge gebracht und letztendlich in einem Petri-Netz dargestellt.
Tabelle 10.1 stellt die Minimalform eines Process Log dar. Das Ablaufprotokoll
muss mindestens die Arbeitsschritte samt des dazugehörigen Arbeitsfalls (Case)
speichern. Je nach Mining Algorithmus können weitere Informationen von Interesse sein. Zeitstempel und Informationen über Beginn, Ende, Unterbrechung, Wiederaufnahme oder Abbruch eines Case können zu besseren Mining Ergebnissen
führen. Teilweise werden diese Informationen nicht im Mining Algorithmus selber
verwenden, sondern in einer Pre-Processing-Phase (siehe 10.4.1).
10.1.3 Petri- und Workow-Netze
Wie zuvor angesprochen sollen als Ergebnis des Process-Minings eine Netzdarstellung der Arbeitsabläufe geliefert werden. Van der Aalst benutzt zur Darstellung
eines Workows ein Workow-Netz [vdAWM04], einer Sonderform der Petri-Netze.
Daher folgt nun eine kurze Einführung in die zur Darstellung von Workows verwendeten Strukturen.
Denition Petri-Netz
Ein Petri-Netz ist ein Tripel N = (S,T,F) mit
1. S ist eine endliche Menge von Stellen
2. T ist eine endliche Menge von Transitionen
3. S ∩ T = ∅ und
4. F ⊆ (S × T ) ∪ (T × S) ist die Menge der Verbindungen zwischen Stellen und
Transitionen
148
10.1 Einleitung
Petrinetze, die die Kontrollussdimensionen eines Arbeitsablaufs modellieren,
werden Workow-Netze genannt. Sie sind eine Teilmenge der Petri-Netze und haben genau einen dedizierten Startplatz und genau einen dedizierten Endplatz.
Denition Workow-Netz
wenn gilt
Ein Petri-Netz N=(S,T,F) heisst Workow-Netz,
1. es gibt einen Startplatz s ∈ S mit •s = ∅
2. es gibt einen Endplatz e ∈ S mit e• = ∅
3. für alle anderen Elemente x ∈ T ∪ (P \{s, e}) ist •x 6= ∅ und x• =
6 ∅
Ein Korrektheitskriterium für Workownetze ist die Soundness-Eigenschaft. Erfüllt ein Workow-Netz diese Eigenschat, dann terminiert es immer korrekt. Das
heisst, dass nach einer beliebige Reihenfolge von feuernden Transitionen immer der
Endzustand erreicht werden kann.
Soundness-Eigenschaft
Sei N =(P,T,F) ein Workow-Netz mit der Input-Stelle
i und der Output-Stelle o. N ist genau dann sound, wenn gilt:
• (N,[i]) ist sicher
Ein Petri-Netz ist genau dann sicher, wenn alle Stellen sicher sind.
• für alle Markierungen s∈ [N, [i]i, o ∈ s =⇒ s = [o]
• für jede Markierung s ∈ [N, [i]i, o ∈ [N, si (Abschluss möglich)
• (N,[i]) enthält keine toten Transitionen
Eine Transition heisst tot, wenn sie bei keiner Markierung der Erreichbarkeitsmenge aktiviert ist.
10.1.4 Ordnungsrelationen
Der später näher beschriebene α-Algorithmus arbeitet wie auch andere Algorithmen nicht direkt mit den Einträgen aus dem Process Log, sondern setzt vorraus,
dass in einem ersten Verarbeitungschritt aus dem Process-Log bestimmte Ordnungsrelationen zwischen den einzelnen Tasks extrahiert werden. Diese Ordnungsrelationen sollen nun vorgestellt werden.
Denition Log-basierte Ordnungsrelation
Sei T eine Menge von Tasks, W ein
Workow Log über T, d.h. W ∈ P (T ∗), und a, b ∈ T . Dann sind die vier relevanten
Ordnungsrelationen für Log-basierte Daten wie folgt deniert [vdAWM04].
149
10 Process Mining
1. direkter Nachfolger: a >w b ⇐⇒ ∃σ = t1 t2 t3 ...tn−1 ∃i ∈ {1, ..., n − 2} : σ ∈
W ∧ ti = a ∧ ti+1 = b
2. Kausalität: a →w b ⇐⇒ a >w b ∧ b 6>w a
3. Auswahl: a#w b ⇐⇒ a 6>w b ∧ b 6>w a
4. Parallel: a||w b ⇐⇒ a >w b ∧ b >w a
Die erste Relation gibt an, dass ein Task a in irgendeinem der Log Traces vor dem
Task b vorkommt. Dies ist die grundlegenste Relation, da alle anderen Relationen
auf ihr aufbauen. Die Kausalitätsrelation gibt an, dass wenn Task a und Task b direkt aufeinander folgen immer zuerst Task a kommt. Dies soll garantieren, dass die
Reihenfolge von Task a und Task b nicht beliebig ist. Es bedeutet nicht, dass zwingend nach Task a der Task b ausgeführt wird. Die Auswahl-Relation zeigt an, dass
von zwei Tasks immer nur einer gewählt werden kann, also eine OR-Verzweigung
stattndet. Bei der Parallel-Relation hingegen werden beide Tasks ausgeführt, die
Reihenfolge ist jedoch beliebig. Dies entspricht einer AND-Verzweigung.
10.2 Probleme
Bevor im nächsten Abschnitt ein konkreter Algorithmus zum Erstellen eines Workow-Netzes aus den Daten eines Ablaufprotokolls vorgestellt wird, sollen zunächst
die Probleme dieser Aufghabe vorgstellt werden. Unterschiedliche Algorithmen bietet Lösungen für Teilmengen dieser Probleme. Bislang konnte noch kein Algorithmus entwickelt werden, der für alle Probleme eine Lösung bietet.
Bevor im folgenden auf die Probleme bei der Auswertung der Daten eingegangen
wird, soll zunächst noch auf ein inhärentes Problem des Process Mining hingewiesen werden. Dieses Problem ist die Basierung auf empirischen Daten. Angenommen
10 verschiedene Tasks können parallel ausgeführt werden. Daraus ergibt sich eine
Gesamtzahl von 10! = 3628800 möglichen Alternativen für die zeitliche Abfolge
der Ausführung der Tasks [vdAW04]. Das alle möglichen Alternativen auch ausgeführt wurden und damit deren Aufzeichnung in einem Process Log zur Auswertung verfügbar ist, ist extrem unwahrscheinlich. Insgesamt dürften bei komplexeren
Prozessen sehr viele Pfade des Workow-Netzes unbenutzt geblieben sein, so dass
zahlreiche Abhängigkeiten zwischen Arbeitsschritten nicht erkannt werden können.
Dieses Problem kann auch durch sehr viel aufgezeichnetes Datenmaterial nur im
begrenztem Umfang abgemildert werden.
10.2.1 Versteckte Tätigkeit
Manche Tasks nden sich nicht in den Log-Dateien wieder, da sie zum Beispiel
nur sehr selten ausgeführt werden. In diesem Fall gibt es insbesondere keine Informationen über den Task und seine Abhängigkeiten. Es kann jedoch auch sein,
dass für einen Task keine Aufzeichnungen in den Log-Dateien verzeichnet sind, der
150
10.2 Probleme
Abbildung 10.1: Beispiel für versteckte Tasks
Task aber sehrwohl ausgeführt wurde. Da die verwendeten Process Logs zumeist
nicht für die Verwendung zum Process Mining erstellt wurden, sondern für andere
Funktionen der aufzeichnenden Software gedacht sind, werden die speziellen Anforderungen des Process Minings auch nicht erfüllt. Versteckte Task lassen sich
dann auch nur unter Umständen wiederentdecken. Diese Möglichkeit besteht unter anderem dann, wenn an diesem Task eine AND-Verzweigung oder -Vereinigung
stattndet.
10.2.2 Doppelte Tätigkeit
Dieses Problem ergibt sich, wenn Tätigkeiten auÿerhalb von Schleifen in einem
Arbeitsprozess mehrfach verwendet werden.
Abbildung 10.2: Beispiel für doppelte Tasks
Wenn beispielweise in einem Kreditvergabeprozess einer Bank die Tätigkeit
Stammdaten
prüfendirekt
zu Beginn des Prozesses und kurz vor dem Prozessende
nochmal durchgeführt wird, dann lassen sich die wahren Abhängigkeiten zwischen
mehreren Tasks nur schwer ermitteln.
151
10 Process Mining
10.2.3 Schleifen
Kurze Schleifen der Länge eins oder zwei können nicht oder nur schlecht wiederentdeckt werden. Bei Algorithmen, die auf Basis der Relationen zwischen Tasks
arbeiten, liegt dies an derer grundlegender Arbeitsweise.
Abbildung 10.3: Beispiel für problematische Schleifen
Der α-Algorithmus basiert beispielweise auf der Verarbietung von kausalen Beziehungen. Für eine Schleife der Länge eins müsste also die Relation a →w a
gefunden werden. Dies ist aber nicht möglich, da dies nach der Denition der Kausalität (10.1.4) die beiden Beziehungen a >w a und a 6> a vorraussetzen würde.
Diese beiden Relationen können aber gleichzeitig nicht existieren. Damit fehlt dem
Algorithmus die Grundlage für das Wiederentdecken der Schleife.
10.2.4 Verrauschte Daten
Im Idealfall sind in den Log-Daten keine Fehler enthalten. Die meisten Algorithmen setzen es auch vorraus, dass die Log-Datei fehlerfrei erstellt wurde. In der
Praxis trit dies aber leider oft nicht zu. Für fehlerhafte Aufzeichnungen gibt es
vielfältige Ursachen. Bei der manuellen Erstellung der Aufzeichnungen ist leicht
einzusehen, dass Fehler mit hoher Wahrscheinlichkeit auftreten. Aber auch bei der
automatischen Generierung von Protokollen können Aufzeichnungsfehler geschehen. Dies kann zum Beispiel an Programmierfehlern liegen. Wenn die Fehler in
den Arbeitsaufzeichnungen nicht berücksichtig werden, führt dies dazu, dass auch
das aus den fehlerhaften Daten ermittelte Workow-Netz unkorrekt ist.
Deshalb schlägt van der Wals einen heuristischen Ansatz vor, um bei Nutzung
des α-Algorithmus mit diesen Fehler in den Process Logs umgehen zu können
[vdAvDH+ 03]. Die Idee ist, nicht direkt mit den aus den Logdaten ermittelten Abhängigkeiten zu arbeiten, sondern in einem Zwischenschritt eine neue Abhängigkeitstabelle zu erstellen. Die ursprünglich Abhängigkeitstablle wird um einige Kennzahlen ergänzt und D/F-Tabelle (dependency/frequency-Tabelle) genannt. Aus dieser
Tabelle wird dann die R-Tabelle (relations-Tabelle) erzeugt, die zur Erstellung des
152
10.2 Probleme
Workow-Netzes verwendet wird. Durch das auslagern der Heuristik in einen PreProcessing-Schritt können die vorhandenen Algorithmen weiterverwendet werden.
D/F-Tabelle
Es wird davon ausgegangen, dass die Log-Daten wie in Tabelle 10.1 aus einer
Menge von (Case,Task)-Tupel bestehen. Aus dieser Tabelle werden die Ablauisten
erzeugt. Für das Beispiel aus Tabelle 10.1 würde sich (ACD,ABBD) ergeben. Dabei
wird die Aktivitätsfolge eines Cases (z.B. ACD) Workow Trace genannt. In der
D/F-Tabelle werden nun für jeden Task Einträge mit den folgenden Informationen
abgelegt:
1. #A: Häugkeit von Task a
2. #B<A: Häugkeit von Task a direkt nach Task b
3. #A>B: Häugkeit von Task a direkt gefolgt von Task b
4. #B <<< A: Häugkeit von Task a direkt oder indirekt nach Task b
5. #A >>> B : Häugkeit von Task a direkt oder indirekt gefolgt von Task b
6. #A → B : Maÿ der kausalen Beziehung zwischen Task a und Task b
Die Aussagen der ersten fünf Metriken bedürfen keiner Erklärung. Die Idee der
sechsten Metrik ist, dass wenn kurz nach einem Task a ein Task b folgt, es wahrscheinlich ist, dass Task a das Auftreten von Task b verursacht hat. Gleichzeitig
ist es unwahrscheinlich, dass bei dieser Abfolge Task a die Folge von Task b ist
[vdAvDH+ 03]. Mit der Anzahl der zwischen a und b liegenden Tasks wird die
Wahrscheinlichkeit, dass ein Task den anderen Task kausal bedingt, gewichtet. Insgesamt ergibt sich damit ein Maÿ für die kausale Beziehung zwischen Task a und
Task b.
R-Tabelle
Aus den Daten der D/F-Tabelle kann nun die R-Tabelle berechnet werden. Eine
Relation der Art a →w b wird angenommen, wenn #A → B ≥ N , (#A > B) ≥ θ
und (#B < A) ≤ θ gilt. Dabei gibt N den Rauschfaktor und θ den Schwellwert
×#L)
an, wobei für θ gilt θ = 1 + Round(N
(mit #L = Anzahl der Zeilen in der
#T
Log-Datei und #T = Anazahl unterschiedlicher Tasks).
In die R-Tabelle wurden durch diesen Schritt nur Kausalitäten übernommen, die
der Wahrscheinlichkeit nach nicht auf Protokollierungsfehler beruhen. Sie dient
nun als Datenbasis für den α-Algorithmus.
153
10 Process Mining
10.3 Algorithmen
10.3.1 α-Algorithmus
Zum Erstellen eines Workows-Netzes aus Log-Daten entwickelte van der Aalst
einen Algorithmus [vdAWM04], der ausgehend von Ordnungsrelationen des letzten
Abschnittes, die Stellen, Transitionen des Workow-Netzes und ihre Verbindungen
untereinander nacheinander berechnet.
Die Idee des α-Algorithmus ist es nacheinander die Transitionen, Stellen und
schluÿendlich die Verbindungen zwischen ihnen zu berechnen. Dabei liegt das Problem bei dem korrekten Einfügen der Stellen zwsichen den Transitionen, dass sich
dadurch ergibt, dass manche Stellen mehrere Eingangs- oder Ausgangskanten haben.
Denition α-Algorithmus
Sei T eine Menge von Tasks und W ein Workow-Log
über T. Dann ist α(W ) deniert als:
1. TW = {t ∈ T |∃σ ∈ W : t ∈ σ}
2. TI = {t ∈ T |∃σ ∈ W : t = f irst(σ)}
3. TO = {t ∈ T |∃σ ∈ W : t = last(σ)}
4. XW = {(A, B)|A ⊆ TW ∧ B ⊆ TW ∧ ∀a ∈ A∀b ∈ B : a →W b ∧ ∀a1 , a2 ∈
A : a1 #a2 ∧ ∀b1 , b2 ∈ A : b1 #b2 }
5. YW = {(A, B) ∈ XW |∀(A0 ,B 0 )∈XW A ⊂ A0 ∧ B ⊂ B 0 ⇒ (A, B) = (A0 , B 0 )}
6. PW = {p(A,B) |(A, B) ∈ YW } ∪ {iW , oW }
7. FW = {(a, p(A,B) )|(A, B) ∈ YW ∧ a ∈ A} ∪ {(p(A,B) , b}|(A, B) ∈ YW ∪ b ∈
B} ∪ {(iW , t)|t ∈ TI } ∪ {(t, oW )|t ∈ TO }
8. α(W ) = (PW , TW , FW )
Die Menge TW kann leicht aus dem Process Log extrahiert werden. Ebenso ist
die Berechnung von TI und TO ohne Probleme aus den Log Traces möglich. Hierzu
sind ersten bzw. letzten Elemente eines jeden Traces zu betrachten. Die Elemente
aus TI können dann einfach mit der Start-Stelle iW verbunden werden. Analog
werden die Elemente aus TO mitder Endstelle oW verbunden.
Das Berechnen aller weiteren Stellen und Transitionen gestaltetsich etwas schwieriger. Direkt aus den Abhängigkeiten zwischen den Transitionen (sie repräsentieren
die Tasks) lassen sich nicht die benötigten Stellen ableiten, denn so lieÿen sich keine OR-Verzweigungen bzw. OR-Zusammenführungen erstellen. Daher müssen die
Stellen nicht auf Basis der Abhängigkeiten einzelner Transitionen ermittelt werden,
sondern auf Basis von Mengen zusammengehöriger Transitionen. Dies wird durch
die Berechnung der Mengen XW und YW erledigt. Während XW noch für jedes
154
10.4 Mining Prozess
Element aus XW die Potenzmenge beinhaltet, ist in YW nur noch die gröÿte Menge
enthalten. Das bedeutet, wenn XW ((a), d), ((b), d), ((c), d), ((a, b), d), ((b, c), d),
((a, c), d) und ((a, b, c), d) enthält, dann ist in YW nur noch ((a, b, c), d) enthalten.
Der Sinn dieser Berechnung ist es, dass für eine Auswahl a#w b#w c, der eine Transition d kausal folgt, nur eine einzige Stelle erstellt werden soll, in die a, b und c
münden und die dann in d übergeht.
Eigenschaften
Wenn ein Workow-Netz aus einem Process Log mittels des α-Algorithmus erzeugtwurde, dann existiert ein Task im erzeugten Workow-Netz genau dann, wenn er
in mindestens einem Log Trace vorkommt [dMvdAW03]. Ein Task hat genau dann
eine eingehende Kante, wenn er der erste Task in einem Log 111Trace ist oder wenn
er auf einen anderen Task kausal folgt. Analog dazu hat ein Task genau dann eine
ausgehende Kante, wenn er der letzte Task in einem Log Trace ist oder wenn ein
anderer Task auf ihn kausal folgt. Da für manche Tasks keine kausalen Abhängigkeiten aus den Log Daten ermittelt werden können, kann es sein, dass ein Task zu
keiner Stelle eine Verbindung hat. Dieser Task ist dann mit dem eigentlichen Netz
nicht verbunden.
oene Probleme
Durch geeignete Vorverarbeitungsschritte kann trotz verrauschter Daten mit dem
α-Algorithmus eine gute Lösung gefunden werden (siehe 10.2.4). Auch Netze
mit kurzen Schleifen können durch geschickte Vorverarbeitung mittels des αAlgorithmus entdeckt werden. Es verbleiben jedoch einige der unter 10.2 genannten Probleme ungelöst. Kurze Schleifen und doppelte Tätigkeiten sind ebenso wie
versteckte Tätigkeiten und Nicht-freie Wahl für den α-Algorithmus nicht zu endeckcen.
Für versteckte Tätigkeiten gibt es keine Einträge im Process Log, daher ndet
sich dieser Task dann auch nicht in Tw und wird nicht ins erstellte Workow-Netz
aufgenommen.
10.4 Mining Prozess
Das Process Mining ist ein komplexer Vorgang und vollzieht sich üblicherweise in
mehreren Phasen. Der genaue Ablauf ist für jedes Process Ming Tool unterschiedlich, aber grob lassen sich die folgenden Phasen unterscheiden, wie es zum Beispiel
beim Tool EMiT möglichist ist [vDvdA04].
10.4.1 Pre-Processing
Die Pre-Processing Phase dient zum einen der Auswahl der Daten für die eigentliche Processing Phase. Nicht alle aufgezeichneten Datensätze entsprechen den
155
10 Process Mining
Anforderungen der Algorithmus der Processing Phase. Deshalb ndet in der PreProcessing Phase eine Auswahl der Daten statt. Der α-Algorithmus benötig beispielsweise komplette Aufzeichnungen von Cases. Das heisst alle Aktivitäten von
Beginn bis zum Ende eines Arbeitsfalls müssen aufgezeichnet worden sein. Wurde ein Case abgebrochen bevor er beendet wurde, dann sind die entsprechenden
(Case,Task)-Tupel für den α-Algorithmus unbrauchbar, da sie zu falschen Ergebnissen führen würden.
Zum anderen werden in der Pre-Processing Phase bereits die für den Algorithmus
der Processing-Phase benötigten Daten aus dem Process Log extrahiert. Für den
α-Algorithmus werden aus den Log-Daten die Ordnungsrelationen zwischen den
Tasks ermittelt [vDvdA04].
10.4.2 Processing
Die Processing Phase ist der aufwendigste Teil des Mining Prozesses, denn hier
kommt der eigentliche Mining-Algorithmus zum Einsatz. Dies könnte der αAlgorithmus sein, es existieren aber mehrere Process Mining Tools mit eigenen
Algorithmen.
10.4.3 Post-Processing
Nachdem das Workow-Netz generiert wurde, können aus diesem Netz zusammen
mit dem ursprünglichen Process Log weitere Informationen gewonnen werden. Zum
Beispiel können den einzelnen Kanten Werte zugeordnet werden, die angeben, mit
welcher Wahrscheinlichkeit die Kante genutzt wird. Dazu wird für jeden Arbeitsfall
sein Durchlauf durch das Workow-Netz simuliert und für die benutzten Kanten
werden Zähler inkrementiert. Anschlieÿend kann die Wahrscheinlichkeit für die
Nutzung einer Kante aus den Quotienten von gemessenen Kantennutzungen durch
die Summe dieser Werte für alle ausgehenden Kanten dieses Knotens berechnet
werden.
10.5 Schluÿbemerkung
Es existieren bereits mehrere Process-Mining Tools. Unter anderem sind dies EMiT,
Little Thumb, InWoLvE und Process Miner. Jedes dieser Tools kann mit einer anderen Klasse von Problemen umgehen. Wobei jedoch kein einziges mit versteckten
Tasks und nicht-freier Wahl umgehen kann. Auch haben alle Probleme mit parallelen Aktivitäten und Schleifen. Die Tools können jeweils immer nur bestimmte
Klassen dieser beiden Probleme korrekt verarbeiten.
Das Process Mining hat zwar mittlerweile eine anwendungsfähige Stufe erreicht,
doch es gibt noch viele Probleme zu lösen, bis es ein Standardverfahren in der
Prozessanalyse werden kann.
156
Literaturverzeichnis
[AHWY03]
Charu C. Aggarwal, Jiawei Han, Jianyong Wang, and Philip S. Yu.
A framework for clustering evolving data streams. In Johann Christoph Freytag, Peter C. Lockemann, Serge Abiteboul, Michael J.
Carey, Patricia G. Selinger, and Andreas Heuer, editors, VLDB
2003: Proceedings of 29th International Conference on Very Large
Data Bases, September 912, 2003, Berlin, Germany, pages 8192,
Los Altos, CA 94022, USA, 2003. Morgan Kaufmann Publishers.
[AHWY04]
Charu C. Aggarwal, Jiawei Han, Jianyong Wang, and Philip S. Yu.
A framework for projected clustering of high dimensional data streams. In VLDB, pages 852863, 2004.
[Aka90]
Y. Akao. Quality function deployment: Integrating customer Requirements into Product-Design. Productivity Press, 1990.
[Ank01]
Mihael Ankerst. Visual Data Mining. Dissertation, Ludwig Maximilian Universität München, 2001.
[Ank04]
Mihael Ankerst. Kooperatives data mining: Eine integration von
data-mining-algorithmen und visualisierungstechniken. DatenbankSpektrum, 9, 2004.
[APW+ 99]
Charu C. Aggarwal, Cecilia Procopiuc, Joel L. Wolf, Philip S. Yu,
and Jong Soo Park. Fast algorithms for projected clustering. SIGMOD Record (ACM Special Interest Group on Management of Data), 28(2):61??, 1999.
[BG01]
Andreas Bauer and Holger Günzel.
dpunkt, Heidelberg, 2001.
[BG04]
A. Bauer and H. Günzel. Data Warehouse Systeme. dpunkt.verlag,
2004.
[CCS]
E. F. Codd, S. B. Codd, and C. T. Salley. Providing OLAP to UserAnalysts: An IT Mandate. http://dev.hyperion.com/resource_
library/white_papers/providing_olap_to_user_analysts.pdf
Letzter Zugri: 5. Juni 2005.
Data-Warehouse-Systeme.
157
Literaturverzeichnis
[Che76]
Peter Pin-Shan Chen. The Entity-Relationship ModelToward a
Unied View of Data. ACM Trans. Database Syst., 1(1):936, 1976.
[clu]
Datensatz für Intrusion Detection des KDD-CUP'99 http://kdd.
ics.uci.edu/databases/kddcup99/kddcup99.html.
[Cod93]
S. B.; Salley C. T. Codd, Edgar F.; Codd. Providing olap to useranalysts: An it mandate. Codd & Associates, 1993.
[DH00]
P. Domingos and G. Hulten. Mining high-speed data streams. In
Knowledge Discovery and Data Mining, pages 7180, 2000.
[dMvdAW03] A. de Medeiros, W. van der Aalst, and A. Weijters. Workow mining: Current status and future directions, 2003.
[Fay96]
G.; Smyth P. Fayyad, U. M.; Piatetski-Shapiro. The kdd process
for extracting useful knowledge from volumes of data. Comm. of
the ACM, 39(11):27 34, 1996.
[For05]
Oliver Forster. Visualisierung imperfekter informationen in einem
analyse-werkzeug. Studienarbeit, Universität Karlsruhe (TH), 2005.
[Gal]
J. Galindo. Fuzzy SQL - A Fuzzy Query Language. http://www.
lcc.uma.es/~ppgg/FSQL.html Letzter Zugri: 5. Juni 2005.
[GJ79]
M.R. Garey and D.S. Johnson. Computers and Intractability. W.H.
Freeman, 1979.
[GJS97]
M. Gebhardt, M. Jarke, and S.Jackob. A Toolkit for negotiation
support on multidimensional data. ACM Press New York, NY, USA,
1997.
[Haa04]
A. Haag. Konzeption und Umsetzung einer Erweiterung des Common Warehouse Metamodels (CWM) zur Beschreibung von imperfekten Daten. Studienarbeit, IPD, Universität Karlsruhe (TH).
http://www.ipd.uka.de/~ovid/Public/, 2004.
[Han05]
Uwe D. Hanebeck. Skriptum zur Vorlesung Stochastische Informationsverarbeitung. 2005.
[Har75]
John A. Hartigan. Clustering Algorithms. Wiley, New York, 1975.
[Hil05]
N. Hilt. Anpassung eines Metamodells zur Beschreibung imperfekter Informationen in einem Data-Warehouse-System. Studienarbeit, IPD, Universität Karlsruhe (TH). http://www.ipd.uka.de/
~ovid/Public/, 2005.
[Hin99]
D.A.; Wawryniuk M. Hinneburg, A.; Keim. Hd-eye: Visual mining
of high dimensional data. IEEE Computer Graphics and Applications, 19(5):2231, 1999.
158
Literaturverzeichnis
[HK01]
Jiawei Han and Micheline Kamber. Data Mining: Concepts and
Techniques. Morgan Kaufmann, 2001.
[Här05]
Daniel Härder. Anpassung von data-warehouse-techniken für den
einsatz unsicherer verkehrsdaten. Diplomarbeit, Universität Karlsruhe (TH), Fakultät für Informatik, März 2005.
[Imm96]
W. H. Immon. Building the Data Warehouse. Second Edition. John
Wiley & Sons, New York, 1996.
[Inm93]
W.H. Inmon. Building the Data Warehouse. New York: John Wiley
and Sons, 1993.
[IS]
Inc. Inxight Software. Inxight table lens - the fastest way to put
data into decision.
[JD88]
Anil K. Jain and Richard C. Dubes. Algorithms for Clustering Data.
Prentice Hall, 1988.
[JLV02]
Matthias Jarke, Maurizio Lenzerini, and Yannis Vassiliou. Fundamentals of Data Warehouse. Springer, 2002.
[JV97]
M. Jarke and Y. Vassiliou. Foundations of Data Warehouse Quality:
A Review of the DWQ Project. Massachusetts Institute of Technology, Cambridge, 1997.
[Kei01]
Daniel A. Keim. Visual exploration of large databases. Communications of the ACM, 44(8):3844, 2001.
[Kei02]
Daniel A. Keim. Datenvisualisierung und data mining. DatenbankSpektrum, 2, 2002.
[Koo04a]
E. Koop.
Datenbankunterstützung für imperfekte Daten im
Verkehrsumfeld. Diplomarbeit, IPD, Universität Karlsruhe (TH).
http://www.ipd.uka.de/~ovid/Public/, 2004.
[Koo04b]
Erik Koop. Datenbankunterstützung für imperfekte Daten im Verkehrsumfeld. Diplomarbeit, Universität Karlsruhe (TH), 2004.
[Koo04c]
Erik Koop. Datenbankunterstützung für imperfekte Daten im Verkehrsumfeld. Diplomarbeit, Universität Karlsruhe (TH), Fakultät
für Informatik, Juni 2004.
[KR90]
L. Kaufman and P.J. Rousseeuw. Finding Groups in Data: An
Introduction to Cluster Analysis. Wiley, New York, 1990.
[KR05]
Raphael Kimball and Laura Reever. Le Data Warehouse guide de
conduite. Eyrolle, 2005.
159
Literaturverzeichnis
[KRRT98]
R. Kimball, L. Reeves, M. Ross, and W. Thornthwaite. The Data
Warehause Lifecycle Toolkit. John Wiley & Sons, 1998.
[Leh03a]
Wolfgang Lehner.
Datenbanktechnologie für Data-WarehouseSysteme. dpunkt-Verlag, 2003.
[Leh03b]
Wolfgang Lehner.
Datenbanktechnologie für Data-WarehouseSysteme, Konzepte und Methoden. dpunkt, 2003.
[Lin03]
Kong Ling. Konzeptuelle und logische Modellierung eines DataWarehouse-Systems. Seminararbeit, Seminar: Data Warehousing im
Verkehrsbereich, IPD, Fakultät für Informatik, Universität Karlsruhe (TH), 2003.
[LRO96]
Alon Y. Levy, Anand Rajaraman, and Joann J. Ordille. Querying heterogeneous information sources using source descriptions. In
Proceedings of the Twenty-second International Conference on Very Large Databases, pages 251262, Bombay, India, 1996. VLDB
Endowment, Saratoga, Calif.
[LS97]
Hans-Joachim Lenz and Arie Shoshani. Summarizability in OLAP
and Statistical Data Bases. In Yannis E. Ioannidis and David M.
Hansen, editors, Ninth International Conference on Scientic and
Statistical Database Management, Proceedings, August 11-13, 1997,
Olympia, Washington, USA, pages 132143. IEEE Computer Society, 1997.
[Ma05a]
Zongmin Ma. Fuzzy Database Modeling with XML. Springer, 2005.
[Ma05b]
Zongmin Ma. Fuzzy Information Modeling with the UML. Idea,
2005.
[MCN92]
J. Mylopoulos, L. Chung, and B. Nixon. Representing and using
nonfunctional requirements: a process-centered approach. Software
Engineering, 1992.
[Mer04]
A. Merkel. Konzeption und Umsetzung einer Schemaerweiterung
durch Kontexte unter Berücksichtigung von Aggregierungsanfragen.
Studienarbeit, IPD, Universität Karlsruhe (TH). http://www.ipd.
uka.de/~ovid/Public/, 2004.
[Mic91]
Z. Michalewicz. Statistical and scientic databases. In Series in
Computers and Their Applications. Ellis Horwood, 1991.
[MZM04]
Z. M. Ma, W. J. Zhang, and W. Y. Ma. Extending object-oriented
databases for fuzzy information modeling. Information Systems,
29(5):421435, 2004.
160
Literaturverzeichnis
[NRI+ 99]
NTUA, RWTH, INRIA, DFKI, Uniroma, IRST, and Uman. Dwq foundations of data warehouse quality. nom-journal, 1999.
[OLV92]
M. Oivo, V. Basilli Lenzerini, and Yannis Vassiliou. Representing
software engineering modells:The TAME goal-oriented approach.
Springer, 1992.
[OMM+ 02]
L. O'Callaghan, N. Mishra, A. Meyerson, S. Guha, and R. Motwani. Streaming-data algorithms for high-quality clustering. In Proceedings of IEEE International Conference on Data Engineering, 2002.
[oPFHA02]
Oce of Policy Federal Highway Administration. Dening and Measuring Trac data quality. http://www.itsdocs.fhwa.dot.gov/
JPODOCS/REPTS_TE/13767.html, 2002. Trac Data Quality Workshop - Work Order Number BAT-02-006.
[Oraa]
R Database Data Warehousing Guide,
Oracle Corporation. Oracle
10g release 1 (10.1) edition. Chapter 21: SQL for Analysis.
[Orab]
R Database Data Warehousing Guide,
Oracle Corporation. Oracle
10g release 1 (10.1) edition. Chapter 8: Basic Materialized Views.
[Orac]
R Database Data Warehousing Guide,
Oracle Corporation. Oracle
10g release 1 (10.1) edition. Chapter 22: SQL for Modelling.
[Orad]
R Documentation Library - Books, 10g
Oracle Corporation. Oracle
Release 1 (10.1) edition.
[Orae]
R OLAP DML Reference, 10g Release
Oracle Corporation. Oracle
1 (10.1) edition. Chapter 1.4.5: Forecasting Programs.
[Orr98]
Ken Orr. Data quality and systems theory. Communications of the
ACM, 41(2):6671, 1998.
[PCTM03]
J. Poole, D. Chang, D. Tolbert, and D. Mellor. Common Warehouse
Metamodel, Developer's Guide. OMG Press, 2003.
[PJ04]
Ilia Petrov and Stefan Jablonski. An omg mof based repository
system with querying capability - the irm project. In iiWAS, 2004.
[PJD99]
Torben Bach Pedersen, Christian S. Jensen, and Curtis E. Dyreson. Extending Practical Pre-Aggregation in On-Line Analytical
Processing. Technical Report TR R-99-5004, Computer Science Department, Aalborg University, 1999.
[Red98]
Thomas C. Redman. The impact of poor data quality on the typical
enterprise. Communications of the ACM, 41(2):7982, 1998.
161
Literaturverzeichnis
[reg]
Wikipedia: Regressionsanalyse. http://de.wikipedia.org/wiki/
Regressionsanalyse Letzter Zugri: 5. Juni 2005.
[SBHD99]
C. Sapia, M. Blaschka, G. Höing, and B. Dinter. Extending the
e/r model for the multidimensional paradigm. In Kambayashi Y. et.
Al., editor, Advances in Database Technologies, volume 1552. LNCS
Springer, 1999.
[SBML]
Heiko Schepperle, Philipp Bender, Jutta A. Mülle, and Peter C.
Lockemann. Fuzzy Summarizability for Multi-Dimensional Data
Models. Noch nicht veröentlicht.
[Shn96]
Ben Shneiderman. The eye have it: A task by date type taxonomy
for information visualizations. Visual Languages, 1996.
[SHW02]
L. Nowell S. Havre, B. Hetzler and P. Whitney. Themeriver: Visualizing thematic changes in large document collections. 2002.
[SMH04]
Heiko Schepperle, Andreas Merkel, and Alexander Haag. Erhalt von
Imperfektion in einem Data Warehouse. In Andreas Bauer, Michael
Böhnlein, Olaf Herden, and Wolfgang Lehner, editors, Internationales Symposium: Data-Warehouse-Systeme und Knowledge Discovery,
pages 3342. Shaker, 2004.
[Spe01]
Robert Spence. Information Visualization. Addison-Wesley, 2001.
[TS03]
Ian Davidson Tom Soukup. Visual Data Mining. Wiley, 2003.
[vdAvDH+ 03] W. M. P. van der Aalst, B. F. van Dongen, J. Herbst, L. Maruster,
G. Schimm, and A. J. M. M. Weijters. Workow mining: a survey
of issues and approaches. Data Knowl. Eng., 47(2):237267, 2003.
[vdAW04]
W. M. P. van der Aalst and A. J. M. M. Weijters. Process mining:
a research agenda. Comput. Ind., 53(3):231244, 2004.
[vdAWM04]
W. M. P. van der Aalst, Ton Weijters, and Laura Maruster. Workow mining: Discovering process models from event logs. IEEE
Transactions on Knowledge and Data Engineering, 16(9):11281142,
2004.
[vDvdA04]
B.F. van Dongen and W.M.P. van der Aalst. Emit: A process mining
tool. 25th International Conference on Applications and Theory of
Petri Nets (ICATPN 2004) (to appear), 2004.
[Wa96]
Wang and al. What Data Quality Means to Data Consumers. Journal of Management Information Systems (JMIS), 12(4), 1996.
[Wan98]
Richard Y. Wang. A product perspective on total data quality
management. Communications of the ACM, 41(2):5865, 1998.
162
Literaturverzeichnis
[WW96]
Yair Wand and Richard Y. Wang. Anchoring data quality dimensions in ontological foundations. Communications of the ACM,
39(11):8695, 1996.
[WZL01]
Richard Y. Wang, Mostapha Ziad, and Yang W. Lee. Data quality.
Kluwer, 2001.
[Zim91]
H.-J. Zimmermann. Fuzzy Set Theory and Its Applications. Kluwer
Academic Publishers, 1991.
[ZRL96]
Tian Zhang, Raghu Ramakrishnan, and Miron Livny. Birch: An
ecient clustering method for very large databases. In ACM SIGMOD Workshop on Research Issues on Data Mining and Knowledge
Discovery, pages 103114, Montreal, Canada, 1996.
163