Technische Universität München
Fakultät für Informatik
Bewertungsmethoden von Datenqualität
in einem Data Warehouse
Marcus Kühnle
Diplomarbeit in Informatik
Aufgabensteller: Prof. Dr. Florian Matthes
Betreuer: Alexander M. Ernst
Abgabedatum: 15. Juni 2006
Erklärung
Ich versichere, dass ich diese Diplomarbeit selbständig verfasst und nur die angegebenen
Quellen und Hilfsmittel verwendet habe.
München, den 14. Juni 2006
..........................................................
Marcus Kühnle
Danksagung
An dieser Stelle möchte ich mich bei der Firma Loyalty Partner GmbH bedanken, die diese
Diplomarbeit ermöglicht hat. Besonders hervorheben möchte ich meinen Betreuer Carsten
Bomsdorf, der mir während meiner Tätigkeit stets hilfreich zur Seite stand.
Mein Dank richtet sich auch an Prof. Dr. Florian Matthes, der mir die Gelegenheit gegeben
hat, diese Arbeit zu schreiben. Hervorheben möchte ich außerdem Alexander Ernst für die
Betreuung meiner Diplomarbeit seitens der Technischen Universität München und danke für
die zahlreichen wissenschaftlichen Ratschläge, welche fortwährend zur Verbesserung der
Arbeit beigetragen haben.
Zum Schluss möchte ich mich noch bei allen bedanken, die durch ihre persönliche Unter-
stützung zum Gelingen dieser Arbeit beigetragen haben, vor allem bei den zahlreichen ge-
duldigen Korrekturlesern.
Mein größter Dank gilt meiner Mutter.
München, Juni 2006
„Qualität kommt von quälen.“
Felix Magath
Inhaltsverzeichnis I
Inhaltsverzeichnis
Inhaltsverzeichnis ...................................................................................................................I
Abbildungsverzeichnis......................................................................................................... IV
Tabellenverzeichnis............................................................................................................... V
Abkürzungsverzeichnis .......................................................................................................VI
1 Einleitung........................................................................................................................... 1
1.1 Problemstellung .......................................................................................................... 1
1.2 Zielsetzung und Abgrenzung ...................................................................................... 1
1.3 Aufbau......................................................................................................................... 3
2 Motivation ......................................................................................................................... 5
3 Umfeld der Arbeit............................................................................................................. 7
3.1 Loyalty Partner GmbH................................................................................................ 7
3.2 Data Warehouse .......................................................................................................... 8
3.2.1 Data Warehouse Konzept ............................................................................... 8
3.2.2 Unterschied von OLTP- und OLAP-Systemen............................................. 12
4 Datenqualität................................................................................................................... 14
4.1 Qualitätsbegriff ......................................................................................................... 14
4.2 Systematisierungsansatz von Garvin......................................................................... 14
4.2.1 Transzendente Sichtweise............................................................................. 14
4.2.2 Prozessbezogene Sichtweise......................................................................... 15
4.2.3 Produktbezogene Sichtweise ........................................................................ 15
4.2.4 Anwenderbezogene Sichtweise .................................................................... 15
4.2.5 Kosten-Nutzen-bezogene Sichtweise ........................................................... 16
4.3 Ansätze zur Definition von Qualität.......................................................................... 16
4.3.1 Ansatz von Deming ...................................................................................... 16
4.3.2 Ansatz von Juran........................................................................................... 17
4.3.3 Ansatz von Feigenbaum................................................................................ 17
4.3.4 Ansatz von Crosby........................................................................................ 17
4.4 Anwendung des Systematisierungsansatzes von Garvin auf Datenqualität .............. 18
Inhaltsverzeichnis II
4.4.1 Mögliche Sichtweisen auf Datenqualität nach Garvin.................................. 18
4.4.2 Abwandlung von Garvins Sichtweisen nach Helfert .................................... 19
4.4.3 Auswahl einer Sichtweise auf die Datenqualität in einem DWH ................. 20
4.5 Ausgewählte Ansätze zum Begriff der Datenqualität ............................................... 23
4.5.1 Empirische Untersuchung von Wang und Strong......................................... 23
4.5.2 Innere Datenqualität nach Wand und Wang ................................................. 24
4.5.3 Ansatz von Redman...................................................................................... 25
4.5.4 Qualitätsmerkmale nach English .................................................................. 26
4.6 Untersuchungen zur Datenqualität in einem Data Warehouse.................................. 26
4.6.1 Qualitätsfaktoren für Data Warehouse Systeme nach Jarke ......................... 27
4.6.2 Datenqualität in Data Warehouse Systemen nach Helfert ............................ 27
4.7 Folgerung .................................................................................................................. 29
5 Erfassung der relevanten Datenqualitätsmerkmale für das PAYBACK-DWH....... 31
5.1 Aufbau des Fragebogens........................................................................................... 31
5.2 Durchführung der Umfrage....................................................................................... 31
5.3 Auswertung der Umfrage.......................................................................................... 35
5.3.1 Anwendergruppe Management..................................................................... 36
5.3.2 Anwendergruppe Prozessverantwortliche .................................................... 38
5.3.3 Anwendergruppe Datenanalysten ................................................................. 40
5.3.4 Anwendergruppe DWH-Management .......................................................... 41
5.3.5 Zusammenfassung ........................................................................................ 43
5.4 Nicht weiter betrachtete Datenqualitätsmerkmale .................................................... 44
5.5 Datenqualitätsmerkmale dieser Arbeit ...................................................................... 47
6 Definition der Datenqualitätsmerkmale ....................................................................... 48
6.1 Vollständigkeit .......................................................................................................... 49
6.2 Korrektheit ................................................................................................................ 51
6.3 Aktualität................................................................................................................... 53
6.4 Historisierung............................................................................................................ 54
6.5 Widerspruchsfreiheit ................................................................................................. 55
7 Messung von Datenqualität in einem Data Warehouse............................................... 57
7.1 Ressourcen und Kosten............................................................................................. 57
7.2 Vorgehensweise zur Messung................................................................................... 57
7.2.1 Überprüfung der Datenqualität innerhalb des DWH .................................... 58
7.2.2 Systemübergreifende Überprüfung der Datenqualität .................................. 59
Inhaltsverzeichnis III
7.3 Variationen von Abgleichen ..................................................................................... 60
7.3.1 Abgleich des gesamten Datenbestandes ....................................................... 61
7.3.2 Partieller Abgleich des Datenbestandes........................................................ 61
7.4 Einplanen von Datenqualitätsmessungen.................................................................. 63
7.5 Besonderheiten bei der Messung der einzelnen Datenqualitätsmerkmale ................ 64
7.5.1 Messung der Vollständigkeit ........................................................................ 64
7.5.2 Messung der Korrektheit .............................................................................. 66
7.5.3 Messung der Aktualität................................................................................. 67
7.5.4 Messung der Historisierung.......................................................................... 68
7.5.5 Messung der Widerspruchsfreiheit ............................................................... 69
7.6 Grenzen der Messung................................................................................................ 70
8 Darstellung und Bewertung der Messergebnisse ......................................................... 71
8.1 Darstellung der Messergebnisse................................................................................ 71
8.2 Bewertung der Messergebnisse................................................................................. 72
9 Prototypische Umsetzung............................................................................................... 74
9.1 Überprüfung der Vollständigkeit .............................................................................. 75
9.2 Ergebnis der Vollständigkeitsprüfung....................................................................... 76
9.3 Überprüfung der Korrektheit..................................................................................... 77
9.4 Ergebnis der Korrektheitsprüfung............................................................................. 77
10 Zusammenfassung .......................................................................................................... 79
10.1 Fazit........................................................................................................................... 79
10.2 Ausblick .................................................................................................................... 80
Literaturverzeichnis .......................................................................................................... VII
Anhang A: Fragebogen.......................................................................................................XV
Anhang B: Angaben der Anwendergruppen..................................................................XIX
B1: Angaben der Anwendergruppe Management.......................................................... XIX
B2: Angaben der Anwendergruppe Prozessverantwortliche ......................................... XXI
B3: Angaben der Anwendergruppe Datenanalysten................................................... XXIV
B4: Angaben der Anwendergruppe DWH-Management............................................ XXVI
Abbildungsverzeichnis IV
Abbildungsverzeichnis
Abbildung 2.1: Probleme aufgrund unzureichender Datenqualität.......................................... 6
Abbildung 3.1: Zentral organisiertes Data Warehouse.......................................................... 12
Abbildung 4.1: Interpretation von Garvins Sichtweisen auf Qualität nach Helfert ............... 20
Abbildung 4.2: Datengewinnung bei der prozessbezogenen Sichtweise............................... 21
Abbildung 5.1: Die DWH-Nutzer bei Loyalty Partner .......................................................... 32
Abbildung 5.2: Angaben des Managements über existierende Defizite ................................ 36
Abbildung 5.3: Gewichtung der Merkmale durch das Management ..................................... 37
Abbildung 5.4: Angaben der Prozessverantwortlichen über existierende Defizite................ 38
Abbildung 5.5: Gewichtung der Merkmale durch die Prozessverantwortlichen ................... 39
Abbildung 5.6: Angaben der Datenanalysten über existierende Defizite .............................. 40
Abbildung 5.7: Gewichtung der einzelnen Merkmale durch die Datenanalysten.................. 41
Abbildung 5.8: Angaben des DWH-Managements über existierende Defizite ..................... 42
Abbildung 5.9: Gewichtung der einzelnen Merkmale durch das DWH-Management .......... 43
Abbildung 6.1: Die Datenqualitätsmerkmale beim PAYBACK-DWH................................. 48
Tabellenverzeichnis V
Tabellenverzeichnis
Tabelle 3.1: Unterschiedliche Anforderungen an OLTP- und OLAP-Systeme..................... 13
Tabelle 4.1: Datenqualitätsmerkmale nach Wang und Strong............................................... 24
Tabelle 4.2: Innere Datenqualitätsmerkmale nach Wand und Wang..................................... 25
Tabelle 4.3: Datenqualitätsmerkmale nach Redman.............................................................. 25
Tabelle 4.4: Datenqualitätsmerkmale von Datenwerten nach English .................................. 26
Tabelle 4.5: Qualitätsmerkmale nach Jarke ........................................................................... 27
Tabelle 4.6: Qualitätsmerkmale von Datenwerten nach Helfert ............................................ 28
Tabelle 4.7: Unterschiedliche Definitionen des Vollständigkeitsmerkmals .......................... 29
Tabelle 5.1: Übersicht über die Anwendergruppen ............................................................... 32
Tabelle 5.2: Verschickte und beantwortete Fragebögen........................................................ 35
Tabelle 6.1: Die unterschiedlichen Typen der Vollständigkeit.............................................. 50
Tabelle 6.2: Beispiel-Relation für die Vollständigkeit .......................................................... 51
Tabelle 7.1: Beispieltabelle zur Historisierung...................................................................... 69
Abkürzungsverzeichnis VI
Abkürzungsverzeichnis
BI ......................... Business Intelligence
bspw. .................... beispielsweise
BSC...................... Balanced Scorecard
bzw. ..................... beziehungsweise
ca.......................... circa
CRM..................... Customer Relationship Management
DQ........................ Datenqualität
DWH.................... Data Warehouse
etc......................... et cetera
ETL ...................... Extraction Transformation Load
evtl. ...................... eventuell
Hrsg...................... Herausgeber
LP......................... Loyalty Partner GmbH
Mio....................... Millionen
Mrd....................... Milliarden
o.Ä........................ oder Ähnliches
OLAP................... Online Analytical Processing
OLTP ................... Online Transactional Processing
RDBMS ............... Relationales Datenbankmanagementsystem
S. .......................... Seite
sog........................ sogenannte
u.a......................... unter anderem
v.a......................... vor allem
vgl. ....................... vergleiche
z.B. ....................... zum Beispiel
Einleitung 1
1 Einleitung
1.1 Problemstellung
Die Qualität von Daten und Informationen spielt in der heutigen Informationsgesellschaft
eine immer wichtigere Rolle. Immer mehr Entscheidungen basieren auf Auswertungen stän-
dig wachsender Datenbestände bei zunehmend komplexer werdenden Datenstrukturen. Fehl-
entscheidungen, die basierend auf nicht korrekten Daten getroffen werden, können erhebli-
chen unternehmerischen Schaden verursachen. Trotz der negativen Auswirkungen schlechter
Datenqualität auf das gesamte Unternehmen besitzen viele Unternehmen noch keine Strate-
gie, um dieses Problem anzugehen.
Um ein hohes Datenqualitätsniveau langfristig zu sichern, reichen punktuelle Datenbereini-
gungsmaßnahmen von Qualitätsdefiziten, die während des Betriebs entdeckt wurden, nicht
aus. Es gilt, Mechanismen und Methoden einzuführen, welche kontinuierlich die Qualität der
Daten überwachen, damit die Qualität der Information messbar wird. Diese Mechanismen
und Methoden können dann als Frühindikator für etwaige Qualitätsverluste in den Daten
dienen.
1.2 Zielsetzung und Abgrenzung
Für die dauerhafte Etablierung und Nutzung eines DWH-Systems als zentrale Informations-
quelle in einem Unternehmen ist die Qualität der Daten und die Verlässlichkeit daraus abge-
leiteter Aussagen von zentraler Bedeutung. Im Rahmen dieser Arbeit werden Kriterien zur
Identifizierung möglicher Datenqualitätsdefizite in einem DWH1 aufgezeigt werden. Diese
Diplomarbeit bezieht sich auf das PAYBACK Data Warehouse (PAYBACK-DWH2) der
Loyalty Partner GmbH (LP), mit dem Schwerpunkt auf den aus dem PAYBACK Programm
gewonnenen Daten.
1 Durch DWH wird im weiteren Verlauf dieser Arbeit ein beliebiges Data Warehouse bezeichnet.
2 Mit PAYBACK-DWH wird im Folgenden das Data Warehouse bezeichnet, in dem die Daten des PAYBACK Programms vorgehalten werden.
Einleitung 2
Von hoher Bedeutung ist, was einen Datenbestand von hoher bzw. niedriger Qualität aus-
zeichnet. Um eine Aussage über die Qualität von Daten treffen zu können, wird die Beurtei-
lung der Datenqualität hierbei grundlegend auf ein DWH bezogen definiert.
Beispielhaft sind hier einige Qualitätsmerkmale genannt:
• Aktualität (keine veralteten Daten)
• Konsistenz (Widerspruchsfreiheit)
• Korrektheit (Übereinstimmung mit der Realität)
• Vollständigkeit (es fehlen keine Werte)
Diese Arbeit soll Aufschluss darüber geben, wie eine Aussage über die Datenqualität im
vorhandenen PAYBACK-DWH getroffen werden kann. Es werden Kriterien erarbeitet, um
Datenqualitätsdefizite sowohl innerhalb des PAYBACK-DWH als auch im Vergleich zu den
operativen Quellsystemen messen zu können. Ziel ist es, Merkmale zu definieren, anhand
derer die Datenqualität zuverlässig im PAYBACK-DWH überwacht werden kann. Etwaige
daraus resultierende Maßnahmen zur Verbesserung der Qualität dieser Daten werden ebenso
wie die Ursachen mangelnder Datenqualität nicht untersucht. Grundlage sind die im
PAYBACK-DWH vorgehaltenen Basisdaten. Unter Basisdaten sind im Rahmen dieser Ar-
beit Daten zu verstehen, die durch Extraktions-, Transformations- und Ladeprozesse (ETL-
Prozesse) aus den operativen Systemen in das PAYBACK-DWH geladen werden. Ebenfalls
nicht weiter untersucht werden daraus abgeleitete Daten, Aggregationen oder in Auswertun-
gen bzw. Reports dargestellte Daten, die auf Basis der im DWH vorgehaltenen Daten durch-
geführt werden.
Das Datenmodell, nach dessen Schema die Daten im PAYBACK-DWH strukturiert sind,
wird als fest und unveränderbar vorausgesetzt. Mögliche Ergebnisse zur Beseitigung von
Mängeln am Datenmodell können nicht umgesetzt werden, da die Umsetzung einer solchen
Änderungsanforderung aufgrund der hohen Komplexität des PAYBACK-DWH hohe Kosten
nach sich ziehen würde. Deshalb werden in dieser Arbeit auch keine Datenqualitätsmerkma-
le näher betrachtet, die das Datenmodell betreffen bzw. nötige Veränderungen daran zur
Folge hätten. Ein Beispiel dafür ist das Merkmal des „Umfangs“ [Re96], wonach das Da-
tenmodell umfassend genug modelliert sein muss und die laut Anforderung an das DWH
wesentlichen Daten beinhalten muss.
Einleitung 3
Darüber hinaus wird angenommen, dass das System (Server, Netzwerk etc.) fehlerfrei arbei-
tet und Zugriff auf die Daten jederzeit möglich ist. Aus diesem Grund werden im Rahmen
dieser Arbeit keine Datenqualitätsmerkmale behandelt, die das System oder den Zugriff auf
die Datenbank betreffen. Ein Merkmal das den Zugriff betrifft ist nach Helfert [He02a] das
Merkmal „Zugriffsrechte“, welches verlangt, dass die DWH-Nutzer ausreichend Rechte
haben, um die anstehenden Aufgaben zu erfüllen.
Wie bereits erwähnt, bezieht sich diese Arbeit aufgrund der Zusammenarbeit mit Loyalty
Partner auf das PAYBACK-DWH. Um eine Wiederverwendung auch für andere Data Ware-
houses zu ermöglichen, wird bei der Erstellung der Ergebnisse auf Allgemeingültigkeit ge-
achtet. Auf die Gegebenheiten des PAYBACK-DWH wird nur bei Bedarf eingegangen.
1.3 Aufbau
In Kapitel 2 werden Auswirkungen mangelnder Datenqualität anhand einiger Beispiele er-
läutert, um die Bedeutung und Aktualität dieser Problematik zu verdeutlichen.
Das Umfeld dieser Diplomarbeit wird in Kapitel 3 näher beschrieben. Neben einer kurzen
Beschreibung des Unternehmens LP werden die Eigenschaften eines DWH vorgestellt, um
die Unterschiede zu den operativen Systemen zu verdeutlichen.
Einige ausgewählte Ansätze zur Bestimmung von Qualität im Allgemeinen und zur Daten-
qualität im Speziellen werden in Kapitel 4 aufgeführt. Anhand dieser Ansätze soll verdeut-
licht werden, dass schon eine Reihe von wissenschaftlichen Arbeiten zu diesem Thema exis-
tieren. In den vorgestellten Ansätzen zur Bestimmung der Datenqualität werden Merkmale
identifiziert, anhand derer die Datenqualität gemessen werden kann.
In Kapitel 5 wird beschrieben, wie durch eine Umfrage bei LP die relevanten Datenquali-
tätsmerkmale für das PAYBACK-DWH identifiziert werden. Zunächst wird der verwendete
Fragebogen dargestellt, dessen Merkmale auf den in Kapitel 4 vorgestellten Erkenntnissen
basieren. Durch die Auswertung der Umfrage werden die wichtigsten Datenqualitätsmerk-
male für das PAYBACK-DWH ersichtlich.
Die ermittelten Datenqualitätsmerkmale werden in Kapitel 6 genauer definiert. Anhand die-
ser Merkmale kann die Datenqualität im PAYBACK-DWH gemessen werden. Die Notwen-
digkeit einer einheitlichen Definition wird aufgrund des Mangels einer einheitlichen Be-
zeichnung in der wissenschaftlichen Literatur immer wichtiger.
Einleitung 4
In Kapitel 7 wird die Vorgehensweise für die Messung von Datenqualität in einem DWH im
Allgemeinen erläutert. Hierzu werden die wichtigsten Faktoren, die zu beachten sind, her-
vorgehoben. Einige ausschlaggebende Faktoren sind die zur Verfügung stehenden System-
ressourcen, entstehende Laufzeiten der Messungen und evtl. vorhandene konkurrierende
Prozesse.
Eine einfache und übersichtliche Darstellungsmöglichkeit der Messerergebnisse wird in Ka-
pitel 8 aufgezeigt, damit sie für das gesamte Unternehmen zur Verfügung stehen und genutzt
werden können.
In Kapitel 9 wird die prototypische Umsetzung der in dieser Arbeit gewonnen Erkenntnisse
zur Messung von Datenqualität beschrieben und die dadurch gewonnenen Messresultate
erläutert.
Schließlich werden in Kapitel 10 die Ergebnisse dieser Arbeit zusammengefasst und Vor-
schläge für weitere mögliche Vorgehensweisen zur Ermittlung der Datenqualität im
PAYBACK-DWH gegeben.
Motivation 5
2 Motivation
Mangelnde Datenqualität kann schwerwiegende Probleme und sehr hohe Kosten verursachen
[Ec02, TH04]. In der Literatur findet sich eine Vielzahl von Beispielen für die Folgen von
Qualitätsmängeln, wie bspw. bei Eckerson [Ec02], wonach die Industrie und Verwaltung in
den USA jährlich einen Verlust von rund 600 Mrd. USD aufgrund von schlechter Datenqua-
lität erleidet. Als Ursache dieser Kosten werden u.a. zusätzliche Druck- und Portokosten und
ein zu hoher Bestand an Personal, der aufgrund mangelhafter Daten errechnet wurde, ge-
nannt. Auch das Manager Magazin [Th04] weist darauf hin, dass schlechte Datenqualität
Gesamtkosten in Höhe von 8-12 % des Umsatzes eines Unternehmens ausmachen kann. Das
Magazin nennt dazu Beispiele und Projekte aus der Praxis. Eine Studie von SAS3 [Sa03]
kommt zu dem Ergebnis, dass nur 18% der Betriebe ihren Daten vertrauen. Das bedeutet:
Über 80% der Betriebe vertrauen ihren Daten nicht! Laut dieser Studie werden Datenquali-
tätsmängel sehr oft durch Fehler in den Front-Office-Systemen und durch Schwierigkeiten
bei der Systemintegration verursacht. Auch die mangelnde Qualität unternehmensexterner
Daten trägt deutlich zu Datenqualitätsproblemen bei.
Häufig hat man mit den Auswirkungen von Datenqualitätsmängeln auch im täglichen Leben
zu tun, ohne dass die Auswirkung mit der eigentlichen Ursache - der mangelnden Qualität
von Daten - sofort in Verbindung gebracht werden kann [SMB05]. Die Schuld für eine ver-
spätete oder nicht erfolgte Auslieferung eines Briefes wird bspw. oft der Post gegeben, ob-
wohl bei einer näheren Betrachtung meist Mängel in der Adressdatenbank als Ursache iden-
tifiziert werden können. Auf ähnliche Weise kann der mehrfache Versand automatisch er-
zeugter Post häufig auf einen doppelten Datenbankeintrag zurückgeführt werden.
Für eine dauerhafte Etablierung eines DWH in einem Unternehmen ist es nach Wolf [Wo99]
unbedingt notwendig, die Qualität der Daten zu sichern. Eckerson [Ec02] identifiziert durch
eine Umfrage im Rahmen einer Studie des The Data Warehouse Institute die Folgen unzu-
reichender Datenqualität. Wie in Abbildung 2.1 dargestellt, verursachen Datenqualitätsmän-
gel in einem DWH sehr häufig zusätzlichen Zeitaufwand für Abgleiche und die Konsistenz-
erhaltung der Daten, Verlust von Vertrauen in das DWH und Folgekosten, bspw. durch den
mehrfachen Versand von Briefen, aber auch durch den Versand an fehlerhafte Adressen.
Neben der Unzufriedenheit von Kunden identifizierte Eckerson durch die Umfrage auch
3 SAS Institute AG, Schweiz.
Motivation 6
Ertragsverluste, die u.a. aufgrund fehlerhafter Rechnungen verursacht wurden. Auch Prob-
leme bei der Erfüllung der gesetzlichen Auflagen, wie etwa bei der Bilanzerstellung, waren
die Folge unzureichender Datenqualität.
Abbildung 2.1: Probleme aufgrund unzureichender Datenqualität (aus [Ec02])
Trotz dieser Folgen hatten fast 50% der befragten Unternehmen noch keine Strategie, um
dieses Problem anzugehen und nur ca. 10% gaben an, bereits umfassende Maßnahmen ein-
geleitet zu haben, um die Datenqualität zu verbessern. Nur ca. 40% der Unternehmen waren
erst dabei, einen Plan für dieses Problem zu entwickeln oder befanden sich noch in der Phase
der Implementierung.
Da auf Basis der Daten des PAYBACK-DWH sowohl bei LP als auch bei den Partnern des
PAYBACK-Programms strategische Entscheidungen getroffen werden, kommt der Korrekt-
heit der Daten eine besondere Bedeutung zu. Ziel dieser Diplomarbeit ist es, durch die Iden-
tifikation von Merkmalen zur Bestimmung der Datenqualität und das Erarbeiten von Metho-
den zur Messung dieser Merkmale die Qualität der Daten im PAYBACK-DWH messbar zu
machen.
Umfeld der Arbeit 7
3 Umfeld der Arbeit
3.1 Loyalty Partner GmbH
Im Fokus dieser Diplomarbeit steht die Datenqualität des PAYBACK-DWH der Loyalty
Partner GmbH. LP ist Experte für Kundenmanagement und unterstützt damit Unternehmen,
ihre Kunden besser zu verstehen und profitabler zu handeln. Mit PAYBACK betreibt LP das
größte und erfolgreichste Bonusprogramm Deutschlands, für Partner wie OBI, Galeria Kauf-
hof, dm-drogerie markt, real,- und WMF. LP hilft ihnen dabei, Umsätze zu steigern, die
Kundenzufriedenheit zu erhöhen und dadurch die Kundenbindung zu stärken. Als branchen-
übergreifendes Programm bietet PAYBACK seinen Nutzern objektiven Mehrwert beim täg-
lichen Einkauf. Die Konsumenten profitieren von exklusiven Vorteilen bei starken Handels-
partnern.
Das mit PAYBACK gewonnene Know-how stellt LP in seinem zweiten Geschäftsfeld „Out-
sourcing" Großunternehmen für individuelles und intelligentes Kundenbeziehungsmanage-
ment zur Verfügung. Dies betrifft sowohl die Entwicklung neuer Kundenbindungsprogram-
me als auch die Abwicklung bereits laufender CRM-Prozesse. So wickelt Loyalty Partner
zum Beispiel „bahn.comfort - das Serviceprogramm für Vielfahrer“ und „bahn.bonus. - das
Prämienprogramm für Bahnfahrer“ der Deutschen Bahn AG ab4.
Das PAYBACK-DWH von LP basiert auf einer relationalen Datenbank und enthält mehr als
2,8 Mrd. Transaktionsinformationen in über 1.700 Tabellen. Es hat ein Datenbankvolumen
von über 1,5 Terabyte. Als zentrale Informationsquelle im Unternehmen enthält es aufberei-
tete Kunden- und Partnerdaten und ist Grundlage für strategische Entscheidungen, sowohl
für das Unternehmen LP, als auch für dessen Partner. Der Bereich Business Intelligence (BI)
ist bei LP der Bewirtschafter des Data Warehouse und trägt die Verantwortung dafür.
4 Ausführliche Informationen zu LP können im Internet unter http://www.loyaltypartner.com abgeru-fen werden.
Umfeld der Arbeit 8
3.2 Data Warehouse
3.2.1 Data Warehouse Konzept
Inmon [In96] definiert ein DWH folgendermaßen:
„A Data Warehouse is a subject oriented, integrated, non-volatile
and time variant collection of data in support of management´s de-
cisions.”
Die vier Hauptmerkmale werden im Hinblick auf diese Arbeit im Folgenden näher erläutert:
„Subject oriented“: Eine Ansammlung von Daten in einem DWH soll auf ein bestimmtes
Ziel ausgerichtet sein. Dieses Ziel ist in der Regel die Orientierung an unternehmensrelevan-
ten Sachverhalten [Be96], also die Analyse und Auswertung von Unternehmensdaten zur
Unterstützung von Entscheidungen der Unternehmensleitung. Das setzt eine Neuorientierung
operativer Daten voraus, denn operative Daten beziehen sich immer auf einzelne betriebliche
Funktionen [BS02].
„Integrated”: Mit dem Konzept eines DWH wird die unternehmensweite Integration von
Daten in einem einheitlich gestalteten System angestrebt [MB00]. Die Integration erfordert
eine Vereinheitlichung der Datenstrukturen, -formate und -bezeichnungen der unternehmens-
internen und -externen Datenquellen. Hierzu ein Beispiel: Wird als Abkürzung für das Ge-
schlecht in einem Quellsystem „m“ und „w“ verwendet, in einem anderen „0“ und „1“, dann
müssen diese Ausprägungen vor der Integration in das DWH vereinheitlicht werden.
„Non-volatile“ 5: Durch die Forderung nach einem Verbot von Änderungen [Ba03] darf auf
ein DWH nur durch Lese- und Einfügeoperationen zugegriffen werden. Bereits integrierte
Daten dürfen demnach nicht verändert werden. Im Rahmen dieser Arbeit kann dieser Defini-
tion nur bedingt zugestimmt werden, weil es möglich sein muss, Daten nach der Integration
aus den operativen Systemen zu korrigieren, falls im Rahmen von Datenqualitätsprüfungen
Fehler im Datenbestand entdeckt werden [Be96].
5 „Volatile“ beschreibt den Grad, mit dem sich Daten im Laufe der Nutzung ändern [Be96].
Umfeld der Arbeit 9
„Time variant“: Im Gegensatz zu operativen Systemen, bei denen eine Betrachtung der
Daten zu einem genauen Zeitpunkt im Mittelpunkt steht, steht bei Auswertungen im DWH
ein Zeitraumbezug im Vordergrund, bspw. bei einer Trendanalyse [Be96]. Dazu wird der
Datenbestand im DWH periodisch mit aktuellen Daten ergänzt und nach Zeitintervallen ver-
dichtet [HW05], um einen historisierten Datenbestand zu erhalten.
Ein Data Warehouse System ist kein Produkt, sondern ein Konzept. Es besteht aus der ei-
gentlichen Data Warehouse Datenbank und allen Komponenten, die zur Integration und Dar-
stellung von Daten notwendig sind [BG01, Qu03]. Ein Data Warehouse dient als separate,
redundante und historisierte Sammlung quantitativer Daten mit dem einen Zweck, entschei-
dungsrelevante Kennzahlen bereitzustellen, die aus den verschiedensten Quellsystemen
stammen und integriert gespeichert werden [Ba03, HA01]. Diese Ausrichtung eines Systems
an der Analyse von Daten wird auch mit dem Begriff On-Line Analytical Processing
(OLAP) bezeichnet, der von Codd geprägt wurde [CCS93].
Entscheidungsunterstützende Daten und Systeme werden beim Data Warehouse Konzept
von operativen Systemen getrennt6. Operative Systeme sind sog. Online Transactional Pro-
cessing Systems (OLTP-Systeme), die das operative Geschäft eines Unternehmens unterstüt-
zen [HW05]. Die Daten der operativen Systeme werden in themenorientierte und entschei-
dungsunterstützende OLAP-Syteme (DWH) übertragen [Se95]. Operative Systeme sind die
wichtigsten Quellen von Daten im DWH [RH96]. Daten können darüber hinaus aus beliebi-
gen, auch unternehmensexternen Datenquellen in das DWH geladen werden, was aber we-
gen deren uneinheitlicher Struktur problematisch ist. Bei den Quellsystemen des
PAYBACK-DWH handelt es sich ausschließlich um interne operative Systeme, externe
Quellsysteme sind nicht vorhanden7.
Zur Befüllung eines DWH werden Daten aus den als Quelle dienenden operativen Systemen
extrahiert, den Geschäftsregeln entsprechend transformiert und abschließend in das DWH
geladen. Zusammengefasst werden diese Vorgänge im Rahmen dieser Arbeit als die Extrak-
tions-, Transformations- und Ladeprozesse (ETL-Prozesse) oder auch als Befüllungsprozes-
6 Entscheidungsunterstützende Systeme werden auch dispositive Systeme bzw. analytische Systeme genannt [HW05].
7 Externe Daten wie bspw. von Dienstleistern und Partnern werden zunächst in interne operative Sys-teme integriert und von dort in das PAYBACK-DWH geladen.
Umfeld der Arbeit 10
se bezeichnet. Beim PAYBACK-DWH werden die ETL-Prozesse periodisch8 angestoßen.
Entsprechend den durch die Geschäftsregeln festgelegten Zeitabständen werden die Befül-
lungsprozesse gestartet. Für diese Arbeit wird vorausgesetzt, dass die ETL-Prozesse perio-
disch durchgeführt werden.
In der Regel wird ein DWH aus mehreren Datenquellen befüllt. Diese liegen dort häufig mit
überschneidendem Inhalt in unterschiedlichen Darstellungsformaten vor. Daher müssen die-
se Daten, bevor sie in das DWH geladen werden können, in ein einheitliches Format ge-
bracht werden. Das erfolgt innerhalb der Transformationsprozesse. Dazu gehört auch die
stufenweise Verdichtung der Daten, wobei bspw. Produkte zu Produktgruppen und die Pro-
duktgruppen wiederum zu Hauptproduktgruppen aggregiert werden [Be96]. Allgemein wer-
den diese einzelnen Stufen der Verdichtung mit dem Begriff der Granularität beschrieben
[In96]. Durch den abschließenden Ladeprozess werden die konsolidierten Daten in analyse-
orientierte Strukturen des DWH übertragen, wo sie für Auswertungen zur Verfügung stehen.
Das multidimensionale Datenmodell hat sich im Hinblick auf die Analyseorientierung eines
DWH für viele Problemstellungen bewährt [TKS01]. In der gängigen Praxis erfolgt die Imp-
lementierung multidimensionaler Schemata meistens auf einem relationalen Datenbankma-
nagementsystem (RDBMS). Multidimensionale Strukturen müssen dazu auf relationale
Strukturen abgebildet werden, wozu z.B. das Sternschema verwendet wird [HW05].
Beim Sternschema9, auf dem die meisten OLAP-Datenmodelle basieren [Th03], wird zwi-
schen quantifizierenden und identifizierenden Attributen unterschieden [Oe00]. Die quantifi-
zierenden Attribute sind die zu analysierenden managementrelevanten Größen und werden
Fakten genannt10. Sie repräsentieren die zentralen betrieblichen Erfolgsgrößen, sind meist
numerische Attribute und stehen im Zentrum der Analysen von Anwendern [Th03]. Die
Fakten werden in einer sog. Faktentabelle vorgehalten, die sich im Mittelpunkt des Stern-
schemas befindet [Nu98]. Einzig durch die Fakten kann keine bedeutende Information gelie-
fert werden. Um z.B. die Information über den Umsatz beurteilen zu können ist es notwendig
zu wissen, in welchem Zeitraum, durch welche Abteilung, durch welche Produkte etc. dieser
8 Genaueres zu periodisch und anderen möglichen Steuerungen in [Ki98] .
9 Genaueres zum Sternschema z.B. in [Th03].
10 Oft werden sie auch als Kennzahlen bezeichnet.
Umfeld der Arbeit 11
erwirtschaftet wurde. Durch die identifizierbaren (beschreibenden) Attribute werden diese
Informationen geliefert. Sie werden Dimensionen genannt. Im Gegensatz zu den Fakten ent-
halten die Dimensionen die Kriterien, welche die Auswahl, Zusammenfassung und Naviga-
tion der Fakten ermöglichen [Lu01]. Nach Humm und Wietek sind Dimensionen Filter- und
Auswertungskriterien für Kennzahlen [HW05]: „Dimensionen spannen einen mehrdimensi-
onalen Faktenraum auf und bilden somit das Koordinatensystem zur Navigation durch die
Daten“. Die Dimensionen werden in sog. Dimensionstabellen gespeichert, die im Stern-
schema als „Satellitentabellen“ um die Faktentabelle im Mittelpunkt angeordnet sind [Nu98].
Kimball bezeichnet die Dimensionstabellen als „slowly changing“, da sie sich im Gegensatz
zu Faktentabellen selten ändern [Ki96]. Im Allgemeinen sind beim Sternschema die Daten in
den Dimensionstabellen denormalisiert11 vorgehalten [Gl97].
Die Architektur eines DWH wird durch unterschiedliche organisatorische und technische
Einflussfaktoren bestimmt. Dabei steht die Frage im Vordergrund, ob eine zentrale oder
dezentrale Lösung gewählt werden soll. Beim PAYBACK-DWH handelt es sich um ein
zentral organisiertes DWH, das sich insbesondere für Unternehmen eignet, in denen „zentra-
le Informationsversorgungsstrukturen“ wie bei einem Rechenzentrum, vorhanden sind
[Ba03]. Wie in Abbildung 3.1 dargestellt, werden Daten in einem zentral organisierten DWH
aus internen und externen Quellen in ein zentrales Datenbank-System geladen und verwaltet
[Ba03]. Die unterschiedlichen Datenquellen sind über ein Netzwerk angebunden. Üblicher-
weise ist eine Extraktions-, Transformations- und Lade-Schicht zwischen dem DWH und
den Datenquellen eingefügt, um die Daten vor der Speicherung im DWH zu transformieren
oder auch um sie in einen bereinigten und konsistenten Zustand zu bringen. Der Zugriff auf
die im DWH vorgehaltenen Daten erfolgt durch unterschiedliche Client-Werkzeuge über das
Netzwerk. Oft wird dabei auf die Internet-Technologie zurückgegriffen12.
11 Der Begriff Denormalisierung beschreibt das Vorgehen, aus Gründen der Praktikabilität den Über-gang in die nächst höhere Normalform wieder Rückgängig zu machen oder diesen zu verhindern [Ho99]. Durch die Denormalisierung sollen u.a. die im Rahmen von Auswertung bzw. Analysen anfallenden Datenbankzugriffe reduziert und eine Verbesserung der Antwortzeiten beim DWH er-reicht werden [St95]. Neben dem erhöhten Aufwand zur Erhaltung der Datenkonsistenz und der referentiellen Integrität wird auch in Kauf genommen, dass denormalisierte Daten aufgrund ent-stehender Redundanzen einen höheren Speicherplatzbedarf haben [Bi94].
12 Eine ausführliche Beschreibung zentral organisierter Data Warehouses und auch weiterer Architek-turvarianten finden sich u.a. in [SBM99, BG01].
Umfeld der Arbeit 12
Abbildung 3.1: Zentral organisiertes Data Warehouse (In Anlehnung an [Ba03])
3.2.2 Unterschied von OLTP- und OLAP-Systemen
Wesentliche Unterschiede zwischen OLTP- und OLAP-Systemen sind in Tabelle 3.1 zu-
sammengefasst. Dabei wird die Orthogonalität dieser beiden Systemvarianten vorausgesetzt,
wie sie in der wissenschaftlichen Literatur häufig zu finden ist.
Einige Quellen weisen jedoch darauf hin, dass die „Welt in Wirklichkeit nicht so schwarz-
weiß ist“ [ZS99]. Man wird in der Praxis auf operative Systeme treffen, die nicht vollständig
normalisiert13 sind oder die eine Speicherung von historisierten Daten erfordern [Hi02]. E-
benso können Anwendungsszenarien eine Manipulation des Datenbestandes in einem DWH
erfordern. Auf die einzelnen Unterschiede wird in dieser Arbeit nicht näher eingegangen.
Genaueres zu den Differenzen zwischen OLTP- und OLAP-Systemen ist bspw. in [Ba03,
BG01] zu finden.
13 Genaueres zum Begriff der Normalisierung bspw. in [KE06].
Umfeld der Arbeit 13
Anforderung OLTP OLAP Anfragen transaktionsorientiert analyseorientiert
Übliche Operationen Lesen, Ändern, Einfügen, Löschen Lesen, periodisches Hinzufügen, in kontrollierten Bereichen auch Schreiben
Übliche Transaktionsart Kurze Lese- und Schreiboperationen Lange Leseoperationen
Datenmenge / Transaktion relativ klein groß Datenquellen in der Regel eine mehrere Datenvolumen Megabyte - Gigabyte Gigabyte - Terabyte Datenaktualisierung prozessorientiert periodisch „Alter“ der Daten aktuell historisch, aktuell, projiziert Ansicht der Daten vorgegeben (tabellarisch) frei wählbar (multidimensional) Niveau der Daten detailliert detailliert, verdichtet, aufbereitet Normalisierung sehr wichtig weniger wichtig Abfragekomplexität niedrig hoch
Arbeitsweise sich wiederholend; abgeschlossener definierter Zugriff auf Einzeltupel
unplanbar, spontan; iterativer Ana-lyseprozess mit Bereichsanfragen
Vorherrschende Datenbank-technologie
Relationale Datenbankmanagement-systeme (RDBMS)
(Very Large) RDBMS und Multi-dimensionale Datenbankmanage-mentsysteme (MDBMS)
Tabelle 3.1: Unterschiedliche Anforderungen an OLTP- und OLAP-Systeme (in Anlehnung an [Ba03])
Datenqualität 14
4 Datenqualität
4.1 Qualitätsbegriff
Der Begriff Qualität ist aufgrund seiner Abstraktheit nicht auf eine einfache Definition redu-
zierbar. Es existiert eine Vielzahl von Versuchen, diesen Begriff zu definieren und zu inter-
pretieren (z.B. [Cr90, En99, Re96, Ga84, Wa01, WS96, Pi74]). Eine eindeutige und allge-
mein anerkannte Definition dieses Begriffs existiert jedoch bisher nicht. In der Literatur be-
steht nur darüber Einigkeit, dass der Begriff Qualität ein komplexer und schwer in Worte
fassbarer Begriff ist. So wird der Begriff der Qualität u.a. durch DIN ISO 8402 folgender-
maßen definiert [DI90]:
„Qualität ist die Gesamtheit von Eigenschaften und Merkmalen ei-
nes Produktes oder einer Dienstleistung bezüglich ihrer Eignung,
festgelegte oder vorausgesetzte Erfordernisse zu erfüllen.“
Garvin [Ga84] hat anhand der vielen existierenden wissenschaftlichen Arbeiten erkannt, dass
Qualität aus unterschiedlichen Sichtweisen betrachtet und danach klassifiziert werden kann.
4.2 Systematisierungsansatz von Garvin
Garvin [Ga84] hat fünf Sichtweisen auf Qualität identifiziert, in die sich wissenschaftliche
Ansätze zur Qualität einordnen lassen. Seither wird der Systematisierungsansatz in der Lite-
ratur sehr häufig zur Klassifizierung der Sichtweise auf die Qualität angewendet (z.B.
[He02a, HH03, Bu03]). Daher auch in dieser Arbeit angewandt und zunächst vorgestellt.
Nach Garvin [Ga84] existieren die folgenden fünf unterschiedlichen Sichtweisen auf die
Qualität.
4.2.1 Transzendente Sichtweise
Diese Sichtweise kennzeichnet Qualität als angeborene Vortrefflichkeit, Einzigartigkeit oder
Superlativ. Die Qualität wird hier als ein Synonym für hohe Standards und Ansprüche gese-
hen. Die transzendente Sichtweise folgt der abstrakt philosophischen Auffassung, dass Qua-
lität nicht exakt definiert werden kann, sondern nur erfahrbar sei. Ein Beispiel für diese
Sichtweise ist Platons Erörterung des Begriffs der Schönheit [Bu48].
Datenqualität 15
4.2.2 Prozessbezogene Sichtweise
Bei der prozessbezogenen Sichtweise, auch herstellungsbezogene Sichtweise genannt, wird
Qualität durch die Einhaltung von Spezifikationen und Abwesenheit von Fehlern („Do it
right the first time“) bestimmt. Im Mittelpunkt stehen dabei die Erfüllung von Anforderun-
gen an das Produkt und die auf die Einhaltung der Spezifikationen ausgerichteten Kontroll-
prozesse. Ein Produkt muss innerhalb bestimmter Toleranzgrenzen produziert worden sein.
Bei der Herstellung eines Produkts wird nach jedem Prozessschritt geprüft, ob das Ergebnis
den Spezifikationen entspricht. Bei der Produktion eines Autokotflügels bspw. wird nach
dem Pressvorgang des Blechs überprüft, ob Dicke und Form den Vorgaben entsprechen.
Nach dem nächsten Produktionsprozess, z.B. dem Bohren der Löcher für die Montage, wird
geprüft, ob alle erforderlichen Löcher vorhanden und richtig positioniert sind und ob ihr
Durchmesser den Vorgaben entspricht.
4.2.3 Produktbezogene Sichtweise
Hier bestimmen materielle Produkteigenschaften die Qualität. Bei dieser Sichtweise ist Qua-
lität präzise messbar und eine inhärente Eigenschaft des Produktes selbst. Angenommen, ein
Sportwagen soll immer mit einem leistungsstarken Motor ausgestattet sein. Falls er aber mit
einem (qualitativ hochwertigen) Kleinwagenmotor ausgeliefert wird, ist dies nach dieser
Sichtweise einem Qualitätsmangel, denn dieser Sportwagen kann mit diesem Motor die zu-
gesicherte Produkteigenschaft „Spitzengeschwindigkeit“ oder „Beschleunigung“ nicht ein-
halten.
4.2.4 Anwenderbezogene Sichtweise
Nach der anwenderbezogenen Sichtweise wird Qualität durch die subjektive Einschätzung
des Produktbenutzers festgelegt. Demzufolge ist eine hohe Qualität vorhanden, wenn es dem
Zweck der Benutzung durch den Kunden dient. Nicht das Produkt selbst, sondern die indivi-
duellen Bedürfnisse des Anwenders bzw. Endnutzers bestimmen dabei die Qualität. Ver-
sucht bspw. ein Autohersteller anhand einer Umfrage unter potenziellen Käufern festzustel-
len, welche Anforderungen diese an einen neuen Fahrersitz haben und berücksichtigt diese
Wünsche bei der Konzeption und Herstellung, entspricht dies der anwenderbezogenen
Sichtweise.
Datenqualität 16
4.2.5 Kosten-Nutzen-bezogene Sichtweise
Bei der Kosten-Nutzen-bezogenen Sichtweise, auch wertbezogene Sichtweise genannt, wird
unter Berücksichtigung von Kosten- und Nutzenaspekten Qualität bestimmt. Stehen Kosten
und Nutzen in einem akzeptablen Verhältnis, liegt ein Produkt hoher Qualität vor. Nach
Garvin entspricht ein 500$ teuerer Laufschuh, egal wie gut er produziert wurde, nicht einem
Qualitätsprodukt, wenn sich keine Käufer für diesen Schuh finden lassen.
Zusammenfassend lässt sich sagen, dass die Systematisierung nach Garvin verdeutlicht, dass
es „eine“ bzw. „die“ Qualität nicht gibt. Qualität hängt davon ab, aus welcher Sicht sie be-
trachtet wird. Die in der Literatur existierenden Ansätze zur Definition des Qualitätsbegriffs
lassen sich nach Garvin vielmehr in eine oder mehrere der aufgeführten Sichtweisen einord-
nen.
4.3 Ansätze zur Definition von Qualität
In diesem Unterkapitel werden zunächst einige bedeutende und häufig zitierte wissenschaft-
liche Ansätze zur Definition von Qualität exemplarisch aufgeführt, um die Komplexität des
Begriffs der Qualität zu verdeutlichen (z.B. [En99, HE02a, HM01, Re96, WS96]). Damit
soll untermauert werden, dass es keine eindeutige Definition von Qualität gibt. Die vorge-
stellten Ansätze beziehen sich auf beliebige materielle Produkte oder beliebige Leistungen
bzw. Dienstleistungen. Sie sollen einen Überblick über die verschiedenen Zielsetzungen der
wissenschaftlichen Ansätze zum Begriff der Qualität geben. Dazu werden die Ansätze kurz
erläutert und entsprechend dem Systematisierungsansatz von Garvin [Ga84] klassifiziert.
4.3.1 Ansatz von Deming
Nach Deming [De82], der auch „als Vater des modernen Qualitätswesens“ [Wo99] bezeich-
net wird, soll sich Qualität an den gegenwärtigen und zukünftigen Wünschen des Kunden
orientieren. Er formuliert 14 Punkte zur Verbesserung der Qualität, die darauf basieren, dass
die kontinuierliche Verbesserung von Produkten bzw. Dienstleistungen Ziel der Unterneh-
menspolitik ist. Er geht davon aus, dass Qualität in allen Bestrebungen und Prozessen eines
Unternehmens inhärent enthalten sein muss. Obwohl der Prozess als die prägende Größe für
Produktqualität gilt, orientiert sich die Qualität primär an den Bedürfnissen der Kunden.
Qualität entsteht nach Deming aus der Wechselwirkung der Einflussgröße Kunde (als Pro-
duktnutzer), Produkt und die durch das Produkt erzielten Leistungen. Das Qualitätskonzept
Datenqualität 17
von Deming kann der anwenderbezogenen Sichtweise nach Garvin zugeordnet werden, da
die Bedürfnisse der Kunden im Vordergrund stehen.
4.3.2 Ansatz von Juran
Dem Ansatz von Juran [Ju74] liegt ebenfalls die anwenderbezogene Sichtweise zugrunde.
Demnach wird Qualität als „fitness for use“ [Wo99] über die Tauglichkeit und den Gebrauch
aus Kundensicht bestimmt. Aus den individuellen Bedürfnissen der Kunden wird die Beur-
teilung der Qualität abgeleitet. Ebenso wie Deming wendet sich Juran mit seinem Konzept
vor allem an die Führungskräfte. Er unterscheidet zwischen sporadischen und dauerhaften
Qualitätsproblemen. Während sporadische Probleme durch die Mitarbeiter zu beseitigen
sind, hat das Management für die Lösung dauerhafter Probleme zu sorgen, da sie ca. 80%
der gesamten Qualitätsdefizite ausmachen. Daher ist nach Juran ein höheres Qualitätsniveau
nur durch Anstrengungen des Managements zu erreichen. Sein umfangreiches Konzept um-
fasst Methoden der Statistik und Methoden der Arbeitsstrukturierung wie z.B. Arbeitsplatz-
wechsel oder die Erweiterung des Handlungsspielraums, Selbstkontrolle und detaillierte
Schulungsprogramme.
4.3.3 Ansatz von Feigenbaum
Ähnlich wie Deming und Juran orientiert sich Feigenbaum [Fe91] an den Bedürfnissen der
Kunden, betrachtet aber über die Qualität hinaus noch den Preis. Nach [He02b] kann er als
Vertreter der anwenderbezogenen Sichtweise unter Berücksichtigung von Kosten- und
Nutzen-Aspekten aufgefasst werden (näheres in Kapitel 4.4.2). Feigenbaum entwickelte das
Konzept des Total Quality Control [Fe61]. Dabei wird Qualität nicht nur durch die Bereiche
Produktion und Fertigung beeinflusst, sondern es sind alle Mitarbeiter und beteiligten Berei-
che des Unternehmens, also vom Top Management bis zur Basis, für die Qualität verant-
wortlich.
4.3.4 Ansatz von Crosby
Crosby [Cr90] leitet die Anforderungen an die Qualität nicht von den Bedürfnissen der An-
wender ab, sondern Qualität wird durch die Einhaltung der Spezifikationen definiert. Nach
der Devise „Do it right the first time“ sollen unnötige Fehler und damit verbundene Kosten
vermieden werden. Durch diese vorbeugenden Maßnahmen kann er daher der prozessbezo-
genen Sichtweise nach Garvin zugeordnet werden. Die Beteiligung der Mitarbeiter ist dabei
geringer als bei den anderen Ansätzen.
Datenqualität 18
4.4 Anwendung des Systematisierungsansatzes von Garvin auf Da-
tenqualität
Bisher wurden wissenschaftliche Ansätze vorgestellt, die den Begriff der Qualität aus unter-
schiedlichen Sichtweisen und Zielsetzungen definieren. Um diese Ansätze zu klassifizieren,
wurde der Systematisierungsansatz von Garvin [Ga84] mit seinen fünf Sichtweisen auf Qua-
lität vorgestellt, der sich vor allem auf materielle Eigenschaften von Produkten bezieht.
Bei Daten bzw. Informationen handelt es sich jedoch um immaterielle Produkte [Wi72], die
keine materiellen Produkteigenschaften aufweisen. Daher wird in diesem Unterkapitel nun
untersucht, ob sich die fünf Sichtweisen mit dem Schwerpunkt auf der Qualität von materiel-
len Gütern auch für die Betrachtung von Qualität immaterieller Güter wie Daten bzw. Infor-
mationen eignen.
4.4.1 Mögliche Sichtweisen auf Datenqualität nach Garvin
Nach der transzendenten Sichtweise kann Qualität nicht exakt definiert werden, sondern ist
nur erfahrbar. Da es die Betrachtung von Datenqualität in einem Unternehmen allerdings
verlangt, dass Qualität exakt definiert wird, ist diese Sichtweise ungeeignet und wird nicht
weiter verfolgt.
Bezieht man die prozessbezogene Sichtweise auf Daten, stehen die Kontrollprozesse im
Mittelpunkt [He02a], die eine Fehlerfreiheit bei der Gewinnung bzw. Erfassung der Daten
sichern sollen und somit die Einhaltung der Spezifikationen überwachen. Durch den Endnut-
zer definierte Anforderungen an die Qualität bleiben unberücksichtigt.
Der produktbezogenen Sichtweise liegt zu Grunde, dass inhärente materielle Produkteigen-
schaften die Qualität bestimmen. Laut Wimmer [Wi72] sind Daten bzw. Informationen je-
doch ein immaterielles Gut. Sie sind mannigfaltig und existieren in den unterschiedlichsten
Ausprägungen, was eine Definition von materiellen Produkteigenschaften von Daten er-
schwert. Daher wird auch diese Sichtweise zur Betrachtung von Datenqualität nicht weiter
verfolgt.
Bei der anwenderbezogenen Sichtweise werden die Bedürfnisse und Anforderungen des
Endnutzers der Daten in den Vordergrund gestellt. Dabei werden die Informationen selbst
betrachtet und nicht die Prozesse, die diese generieren. Hohe Datenqualität liegt dann vor,
wenn Daten in ihrem Kontext für den Anwender während des Gebrauchs von Nutzen sind.
Datenqualität 19
Bei der Kosten-Nutzen-bezogenen Sichtweise stehen die durch Qualitätsmessungen entste-
henden Kosten und der Nutzen im Vordergrund. Die Kosten zur Messung von Datenqualität
lassen sich bestimmen. Dabei werden in dieser Arbeit v.a. Rechenkapazitäten, Laufzeiten,
Entwicklungskosten etc. als Kosten gesehen und berücksichtigt. Im Gegensatz dazu ist es
allerdings wesentlich komplexer, den daraus gewonnenen Nutzen auf einen exakten Wert zu
reduzieren. Nach Potthof [Po98] ist es schwierig, Nutzeffekte von Investitionen in die In-
formationsverarbeitung vollständig und gut zu messen. Nutzeffekte treten demnach zum
einen verteilt im Unternehmen auf, weshalb sie sich kaum noch zuordnen bzw. messen las-
sen, zum anderen fallen sie zeitlich auseinander, womit die Wahl der Messzeitpunkte und
daher auch die Messung selbst erschwert wird. Da also der Nutzen von Datenqualitätsmes-
sungen nicht eindeutig und nur schwer bestimmt werden kann, eignet sich eine ausschließ-
lich Betrachtung von Datenqualität unter Kosten- und Nutzen-Aspekten nicht und wird in
dieser Arbeit nicht weiter berücksichtigt.
Zusammenfassend lässt sich feststellen, dass sich die prozessbezogene und anwenderbezo-
gene Sichtweisen eigenen, um Datenqualität zu betrachten. Während bei der prozessbezoge-
nen Sichtweise die Kontrollprozesse bei der Datengewinnung im Vordergrund stehen, um
Datenqualität zu sichern, sind es bei der anwenderbezogenen Sichtweise die Anforderungen
der Nutzer. Aufgrund der aufgeführten Gründe eignet sich weder die transzendente, noch die
produktbezogene Sichtweise, noch die ausschließliche Berücksichtigung von Kosten-
Nutzen-Aspekten für die Betrachtung von Datenqualität.
4.4.2 Abwandlung von Garvins Sichtweisen nach Helfert
Helfert [He02b] erweitert den Systematisierungsansatz von Garvin [Ga84]. Er ordnet die
Kosten-Nutzen-bezogene Sichtweise orthogonal zur prozessbezogenen, produktbezogenen
und anwenderbezogenen Sichtweise ein, wie in Abbildung 4.1 dargestellt. Wie schon in Ka-
pitel 4.4.1 erläutert, lassen sich Nutzeffekte nur schwierig messen und nicht richtig zuord-
nen. Ressourcen in einem DWH sind jedoch begrenzt und die Bereitstellung von weiteren
Ressourcen ist mit Kosten verbunden (genaueres hierzu in Kapitel 7). Entstehende Kosten
sind bei der Vorgehensweise zur Bestimmung der Datenqualität daher zu berücksichtigten
und werden in dieser Arbeit bei der Betrachtung der Datenqualität mit einbezogen.
Datenqualität 20
Abbildung 4.1: Interpretation von Garvins Sichtweisen auf Qualität nach Helfert (in Anlehnung an [HE02b])
4.4.3 Auswahl einer Sichtweise auf die Datenqualität in einem DWH
In den vorherigen Abschnitten wurde der Systematisierungsansatz von Garvin [Ga84] vorge-
stellt. Die fünf Sichtweisen dieses Systematisierungsansatzes wurden daraufhin untersucht,
ob sie sich für die Betrachtung von Datenqualität eignen. Dabei wurde festgestellt, dass sich
dafür sowohl die prozessbezogene als auch die anwenderbezogene Sichtweisen eignen. Zu-
dem ist es sinnvoll, die durch die Bestimmung der Datenqualität entstehenden Kosten zu
berücksichtigen. Diese Sichtweisen werden nun daraufhin untersucht, ob sie sich auch für
die Betrachtung der Qualität von Daten eignen, die in einem DWH vorgehalten sind.
Bei der prozessbezogenen Sichtweise ist gefordert, dass Fehlerfreiheit bei der Gewinnung
von Daten gewährleistet ist. Sind die betroffenen Daten in einem DWH vorgehalten, muss
bei dieser Sichtweise eine Unterscheidung getroffen werden, was als Gewinnung von Daten
angesehen wird. Werden die Daten und ihre Gewinnung als Ganzes über die Grenzen des
Data Warehouse hinaus gesehen, entspricht die Eingabe der Daten in die Quellsysteme der
Gewinnung (siehe gestrichelte Pfeile in Abbildung 4.2, Fall I). Ein Beispiel für die Gewin-
nung von Daten ist das Scannen von Artikeln an der Kasse im Supermarkt. Erst wenn ent-
sprechende Daten in einem oder mehreren operativen Systemen gespeichert sind, können sie
durch die fest definierten Extraktions-, Transformations- und Ladeprozesse (ETL-Prozesse)
in ein DWH geladen werden. Diese ETL-Prozesse und etwaige damit verbundene Kontroll-
prozesse haben keinen bzw. einen nur sehr beschränkten Einfluss auf die Fehlerfreiheit bei
der Datengewinnung. Beim Scannen von Artikeln an der Supermarktkasse kann z.B. nicht
Datenqualität 21
beeinflusst werden, ob die einzelnen Artikel an der Kasse korrekt eingescannt wurden. Die
eingelesenen Daten können nicht kontrolliert werden, da Vergleichsmöglichkeiten (Refe-
renzdaten) nicht vorhanden sind. Erschwerend kommt beim speziellen Fall von LP hinzu,
dass diese Daten von den Partnern des PAYBACK-Programms geliefert werden und es LP
daher meistens nicht möglich ist, die Qualität dieser Daten zu beeinflussen. Somit ist die
prozessbezogene Sichtweise zur Betrachtung der Datenqualität in diesem Fall nicht anwend-
bar. Man geht daher davon aus, dass die Daten korrekt sind, die den Ladeprozessen in den
operativen Systemen zur Verfügung stehen.
Abbildung 4.2: Datengewinnung bei der prozessbezogenen Sichtweise (eigene Darstellung)
Betrachtet man das DWH isoliert, so entspricht das Laden der Daten aus den angebundenen
Quellsystemen der Gewinnung von Daten (siehe durchgezogene Pfeile in Abbildung 4.2,
Fall II). Nach der Definition dieser Sichtweise stehen Kontrollprozesse im Mittelpunkt, die
eine Einhaltung der Fehlerfreiheit bei der Datengewinnung sichern sollen. Bei einem DWH
entspricht das einer Überwachung der ETL-Prozesse. Somit wird angenommen bzw. voraus-
gesetzt, dass die Daten der Quellsysteme „der Wahrheit“ entsprechen. Steht die Überwa-
Datenqualität 22
chung von ETL-Prozessen im Mittelpunkt zur Bestimmung der Datenqualität, ist diese
Sichtweise für ein DWH geeignet.
Bei der anwenderbezogenen Sichtweise wird nach Garvin [Ga84] Datenqualität ganzheit-
lich und prozessübergreifend betrachtet. Bei dieser Sichtweise sind neben den Bedürfnissen
der Anwender auch unternehmensweite Anforderungen mit einzubeziehen. Dazu gehören
nach Garvin auch die Anforderungen des operativen Managements, da auch diese als An-
wender zu betrachten sind. Die anwenderbezogene Sichtweise eignet sich daher sehr gut für
die Betrachtung der Datenqualität in einem DWH. Indirekt werden beim Vorgehen nach
dieser Sichtweise in einem gewissen Rahmen auch die ETL-Prozesse überwacht. Denn sind
die im DWH vorgehaltenen Daten korrekt, kann daraus geschlossen werden, dass auch die
ETL-Prozesse, die das DWH laufend mit Daten befüllen, korrekt verlaufen sind.
Für diese Arbeit wird die anwenderbezogene Sichtweise unter Berücksichtigung der ent-
stehenden Kosten für die Betrachtung von Datenqualität gewählt. Wie im vorherigen Ab-
schnitt erwähnt, berücksichtigt die anwenderbezogene Sichtweise unternehmensweite An-
forderungen. Entscheidend für die Akzeptanz eines DWH in einem Unternehmen ist u.a.,
dass die Nutzer auf die für sie relevanten Daten zugreifen können, dass sie sicher sein kön-
nen, dass die Daten korrekt sind und sie somit den Daten vertrauen können. Da die Einfüh-
rung und Bewirtschaftung eines DWH Kosten verursacht und der Nutzen von Daten in vie-
len Fällen nur durch den Anwender bestimmt wird, sollte nicht nur das operative Manage-
ment zur Bestimmung der Anforderungen an die Datenqualität herangezogen werden, son-
dern es sollten auch die Anforderungen der Nutzer mit einbezogen werden. Wie im vorheri-
gen Abschnitt erwähnt, sind die durch die Überprüfung von Datenqualität entstehenden Kos-
ten zu berücksichtigen14. Da Ressourcen in einem DWH begrenzt sind und die Bereitstellung
von weiteren Ressourcen mit Kosten verbunden ist (mehr dazu in Kapitel 7.4), ist der Einbe-
zug der Kosten zur Betrachtung der Datenqualität notwendig.
Die prozessbezogene Sichtweise wird für diese Arbeit nicht gewählt, da nicht untersucht
werden soll, ob Datenerfassungsprozesse erfolgreich ablaufen. Es soll ermittelt werden, ob
die Daten im DWH, unter Berücksichtigung der vorgenommenen Transformationen beim
Ladevorgang, mit denen der Quellsysteme übereinstimmen und ob sie innerhalb des DWH
keine Fehler aufweisen.
14 Als Kosten werden in dieser Arbeit Rechenkapazitäten, Laufzeiten, Entwicklungskosten etc. gese-hen.
Datenqualität 23
4.5 Ausgewählte Ansätze zum Begriff der Datenqualität
Im bisherigen Verlauf der Arbeit wurden einige Ansätze zur Qualität von Produkten bzw.
Dienstleistungen im Allgemeinen erläutert und nach dem Systematisierungsansatz von Gar-
vin [Ga84] der entsprechenden Sichtweise zugeordnet. Aus den fünf Möglichen wurde die
anwenderbezogene Sichtweise unter Berücksichtigung von Kostengesichtspunkten als die
geeignete Sichtweise auf Datenqualität für diese Arbeit identifiziert.
Nach Wallmüller [Wa01] gibt es schon eine Reihe von Versuchen, insbesondere auch durch
Normierungsinstitutionen (z.B. [DI90]), den Begriff der Datenqualität zu definieren. Die
meisten dieser Ansätze stimmen dahingehend überein, dass Datenqualität anhand des Bei-
trags zum Erreichen der Bedürfnisse der Datenempfänger bestimmt wird. Damit folgen sie
weitgehend der anwenderbezogenen Sicht nach Garvin, nach der in dieser Arbeit die Daten-
qualität betrachtet wird. Im Folgenden werden nun ausgewählte wissenschaftliche Ansätze
verschiedener Autoren zur Betrachtung von Datenqualität im Speziellen aufgeführt. Damit
soll die Relevanz dieser Thematik im wissenschaftlichen Bereich verdeutlicht werden. Um
Datenqualität zu definieren werden in den erläuterten Ansätzen basierend auf Literatur rele-
vante Kriterien durch Expertenwissen bzw. Erfahrungen erarbeitet oder durch empirische
Untersuchungen erfasst und voneinander abgegrenzt. Diese Qualitätskriterien, auch Quali-
tätsmerkmale oder auch nur Merkmale genannt, sind notwendig, um im Rahmen von Soll-
Ist-Vergleichen eine Aussage über die Qualität zu ermöglichen [Wo99]. Die Merkmale Ak-
tualität, Widerspruchsfreiheit, Korrektheit und Vollständigkeit, die in der Literatur haupt-
sächlich vorkommen, werden zwar genannt, es lässt sich aber keine Übereinstimmung bei
deren Terminologie und Beziehungsstruktur erkennen. Daher werden die einzelnen Ansätze
und deren Qualitätsmerkmale nur kurz erläutert und nicht umfangreich erklärt. Ausführliche-
re Übersichten über die verschiedenen Ansätze sind u.a. in [Wa95, EW00] zu finden.
4.5.1 Empirische Untersuchung von Wang und Strong
Die von Wang und Strong [WS96] durchgeführte umfangreiche empirische Erhebung von
Datenqualitätsmerkmalen dient als Grundlage vieler Forschungsarbeiten (u.a. [NR99, JV97,
KSW97]). Zunächst sollten in einer ersten Umfrage ca. 140 Endanwender der Industrie so-
wie Studenten großer US-amerikanischer Universitäten Merkmale für Datenqualität anhand
einer offenen Frage nennen. Anschließend wurden die Teilnehmer gebeten, zu einer Krite-
rienliste weitere Datenqualitätsmerkmale hinzuzufügen. Dadurch konnten fast 180 Merkmale
für Datenqualität erfasst werden.
Datenqualität 24
Aufbauend auf dieser Untersuchung sollte bei einer zweiten Umfrage die Relevanz der ein-
zelnen Qualitätsmerkmale auf einer Skala von eins bis neun angegeben werden. Die einzel-
nen Merkmale wurden dabei nicht näher erläutert. Nach der Analyse von 355 ausgefüllten
Fragebögen konnten 20 Merkmale für die Datenqualität identifiziert werden. In einer dritten
Untersuchung wurden diese 20 Merkmale auf 15 reduziert und den vier Kategorien innere
Datenqualität, kontextabhängige Datenqualität, Darstellungsqualität und Zugangsqualität
zugeordnet. Diese Zuordnung ist Tabelle 4.1 zu entnehmen.
Kategorie Datenqualitätsmerkmale
Innere Datenqualität Glaubwürdigkeit, Genauigkeit, Objektivität, Vertrau-enswürdigkeit
Kontextabhängige Datenqualität
Zusatznutzen, Relevanz, Aktualität, Vollständigkeit, angemessenes Datenvolumen
Darstellungsqualität Interpretierbarkeit, Verständlichkeit, konsistente Darstellung, knappe Darstellung
Zugangsqualität Zugriffsmöglichkeit, Zugriffssicherheit
Tabelle 4.1: Datenqualitätsmerkmale nach Wang und Strong (In Anlehnung an [WS96])
4.5.2 Innere Datenqualität nach Wand und Wang
Der Ansatz von Wand und Wang [WW96] bezieht sich nur auf die Entwicklung und den
Betrieb eines Informationssystems. Der Fokus liegt dabei auf der konzeptionellen und intrin-
sischen (internen) Ebene eines Informationssystems. Nach diesem Ansatz werden Zustände
der realen Welt auf das Informationssystem abgebildet. Jedem Zustand der realen Welt soll
mindestens ein Zustand im Informationssystem entsprechen und jeder Zustand im Informati-
onssystem soll auf den korrekten Zustand in der realen Welt bezogen werden können. Treten
Inkonsistenzen zwischen der Sicht auf das Informationssystem und der realen Welt auf, führt
dies zu Datenqualitätsmängeln. Aus diesen Abweichungen leiten Wand und Wang die vier
intrinsischen Datenqualitätsmerkmale vollständig, eindeutig, bedeutungsvoll und korrekt ab.
Die Fehlerarten und Ursachen dieser Merkmale sind in Tabelle 4.2 dargestellt. Die funktio-
nalen Anforderungen an das Informationssystem durch den Endnutzer, die sog. externe Ebe-
ne, lässt dieser Ansatz unberücksichtigt.
Datenqualität 25
Merkmal Fehlerart Ursache
Vollständig Ungenaue Abbildung: Fehlender Zustand im Informationssystem
Entwurf
Eindeutig Ungenaue Abbildung: Mehrere Realwelt-Zustände beziehen sich auf den gleichen Informationssystem-Zustand
Entwurf
Bedeutungsvoll Abbildung auf einen bedeutungslosen Infor-mationssystem-Zustand
Entwurf / Betrieb
Korrekt Abbildung auf den falschen Informationssys-tem-Zustand
Betrieb
Tabelle 4.2: Innere Datenqualitätsmerkmale nach Wand und Wang (In Anlehnung an [WW96])
4.5.3 Ansatz von Redman
Beim Ansatz von Redman [Re96] wird grundlegend zwischen der Datendefinition und den
konkreten Datenwerten unterschieden. Dabei werden die Qualitätskriterien für die Bereiche
konzeptionelle Sicht, Dateninhalte und Datenrepräsentation aufgelistet, wie in Tabelle 4.3
dargestellt. Die konzeptionelle Sicht bezieht sich auf die Qualitätsanforderungen im Daten-
schema. Aufbauend auf dem Datenschema sollen die Dateninhalte korrekt, vollständig, aktu-
ell und konsistent sein. Der dritte Bereich Datenrepräsentation bezieht sich auf die Darstel-
lung der Daten durch Formate und deren physikalische Speicherung.
Bereich Bezugspunkt Qualitätskriterium Inhalt Relevanz, Zugriff, Klarheit der Definitionen Umfang Umfassend, Wesentlich Detaillierungsgrad Attributgranularität, Domaingenauigkeit
Struktur Natürlich, Identifizierbar, Homogen, Minimum an Redundanz
Konsistenz Semantische Konsistenz, Strukturelle Konsistenz
Konzeptionelle Sicht
Reaktionen auf Ver-änderungen
Stabil, Flexibel
Dateninhalte Korrekt, Vollständig, Konsistent, Aktuell
Formate Angemessen, Formatgenauigkeit, effiziente Spei-chernutzung, Interpretierbarkeit, Formatflexibilität, Übertragbarkeit, Fähigkeit Nullwerte abzubilden Datenrepräsentation
Physikalische Spei-cherung
Darstellungskonsistenz
Tabelle 4.3: Datenqualitätsmerkmale nach Redman (In Anlehnung [an Re96])
Datenqualität 26
4.5.4 Qualitätsmerkmale nach English
English [En99] unterscheidet grundsätzlich zwischen der Datendefinitions- und der Archi-
tekturqualität, der Qualität der Datenwerte und der Datenrepräsentation. In Tabelle 4.4 sind
die für Datenwerte definierten Qualitätsmerkmale aufgeführt, die in innere und pragmatische
Datenqualitätskriterien unterteilt sind. Unter den inneren Datenqualitätskriterien sind allge-
meingültige, von der Datenverwendung unabhängige Merkmale zu verstehen. Im Gegensatz
dazu hängen pragmatische Datenqualitätsmerkmale von der Verwendung der Daten ab. Es
wird eine große Anzahl an Qualitätsmerkmalen aufgelistet, ohne das näher auf Beziehungen
der Merkmale untereinander und Überschneidungen eingegangen wird.
Kriterium Datenqualitätsmerkmal Übereinstimmung mit der Datendefinition Vollständigkeit der Datenwerte Plausibel und mit den Geschäftsregeln übereinstimmend Genauigkeit zu Referenzdaten (Vergleichsdaten) Genauigkeit zur Realität Granularität der Datenwerte Eindeutigkeit (keine Duplikate) Übereinstimmung von redundanten und verteilten Datenbe-ständen Zeitliche Übereinstimmung von redundanten und verteilten Datenbeständen
Innere Daten-qualitäts-kriterien
Allgemeine Zugriffsfähigkeit Aktualität und Pünktlichkeit Klarheit / Interpretierbarkeit für den Datenanwender
Übereinstimmung zwischen abgeleiteten (berechneten) Daten und den Ursprungsdaten
Nützlichkeit
Pragmatische Datenqualitäts-kriterien
Vollständigkeit bezogen auf den Informationsbedarf
Tabelle 4.4: Datenqualitätsmerkmale von Datenwerten nach English (In Anlehnung an [En99])
4.6 Untersuchungen zur Datenqualität in einem Data Warehouse
In diesem Kapitel werden zwei weitere Ansätze behandelt, die Qualitätsmerkmale für Daten
definieren, die in einem Data Warehouse vorgehalten sind. Abschließend wird erläutert, wa-
rum der im Folgenden vorgestellte Ansatz von Helfert [He02a] zur Betrachtung von Daten-
qualität in einem DWH für diese Arbeit ausgewählt wird.
Datenqualität 27
4.6.1 Qualitätsfaktoren für Data Warehouse Systeme nach Jarke
Jarke [JV97, Ja99] schlägt in seinen Arbeiten eine prozessorientierte Gliederung von Daten-
qualitätsmerkmalen in einem DWH vor. Er identifiziert vier Typen von Aufgaben bzw.
Funktionen der Benutzer im Zusammenhang mit einem DWH:
• Der Decision Maker trifft anhand von Datenauswertungen Entscheidungen.
• Der DWH-Administrator betreibt und verwaltet das DWH und spürt u.a. anhand von
Fehler-Reportings und Metadaten Probleme auf.
• Der DWH- Designer entwickelt das DWH und auch das Datenmodell.
• Die Programmierer von DWH-Komponenten implementieren u.a. die Lade- und Ag-
gregationsprozesse.
Aus den Anforderungen dieser vier Typen identifiziert Jarke Prozesse für Design und Ver-
waltung, Softwareimplementierung und Datennutzung, nach denen er die Anforderungen an
die Datenqualität gliedert.
Prozess Betrifft Qualitätsmerkmale Datenschema und Datenqualität
Korrektheit, Vollständigkeit, Minimalität, Interpretierbarkeit, Datenrückverfolgung Design und Ad-
ministration Metadaten-Evolution
Software-implementierung
Funktionalität, Zuverlässigkeit, Nützlichkeit, Software-Effizienz, Wartbarkeit, Portabilität
Zugriffsfähigkeit Systemverfügbarkeit, Transaktionsverfügbar-keit, Datensicherheit
Datennutzung Nützlichkeit
Interpretierbarkeit, Antwortverhalten, Aktua-lität
Tabelle 4.5: Qualitätsmerkmale nach Jarke (In Anlehnung an [Ja99])
4.6.2 Datenqualität in Data Warehouse Systemen nach Helfert
Durch eine empirische Untersuchung identifiziert Helfert [He02a] einige relevante Quali-
tätskriterien für praktische Problemstellungen. Er ermittelt die Relevanz der Datenqualitäts-
merkmale und hebt diejenigen hervor, die sich besonders für die Beschreibung der Qualität
von Daten in einem DWH eignen. Auch er unterscheidet dabei zwischen Qualität von Daten-
schema und Datenwerten (vgl. [En99, Re96, JV97, Ja99]). Wie jedoch in Kapitel 4.4.3 erläu-
tert, wird in dieser Arbeit die Qualität des Datenschemas nicht betrachtet. Daher sind in
Tabelle 4.6 nur die Datenqualitätsmerkmale für Datenwerte mit einer kurzen Beschreibung
Datenqualität 28
aufgeführt, die Helfert anhand einer Umfrage identifiziert hat. Die Datenqualitätsmerkmale
sind nach den Kategorien Glaubwürdigkeit, zeitlicher Bezug, Nützlichkeit und Verfügbarkeit
gegliedert.
Kategorie Merkmal Beschreibung
Korrektheit Die Daten stimmen inhaltlich mit der Datendefinition überein und sind empirisch korrekt.
Datenherkunft Die Datenherkunft und die vorgenommenen Datentransformationen sind bekannt.
Vollständigkeit Alle Daten sind gemäß Datenmodell erfasst.
Widerspruchs-freiheit
Die Daten weisen keine Widersprüche zu Integritätsbedingungen (Ge-schäftsregeln, Erfahrungswerte) und Wertebereichsdefinitionen auf (innerhalb des Datenbestands, zu anderen Datenbeständen, im Zeitver-lauf).
Syntaktische Korrektheit
Die Daten stimmen mit der spezifizierten Syntax (Format) überein.
Glaub-würdigkeit
Zuverlässigkeit Die Glaubwürdigkeit der Daten ist konstant.
Aktualität Datenwerte bezogen auf den gegenwärtigen Zeitpunkt sind erfasst.
Zeitliche Konsis-tenz
Alle Datenwerte bzgl. eines Zeitpunktes sind gleichermaßen aktuell. Zeitlicher Bezug
Nicht-Volatilität Die Datenwerte sind permanent und können zu einem späteren Zeit-punkt wieder aufgerufen werden.
Relevanz Die Datenwerte können auf einen relevanten Datenausschnitt be-schränkt werden. Nützlich-
keit Zeitlicher Bezug Die Datenwerte beziehen sich auf den benötigten Zeitraum. Zeitliche Ver-fügbarkeit
Die Daten stehen rechtzeitig zur Verfügung.
System-verfügbarkeit
Das Gesamtsystem ist verfügbar.
Transaktions-verfügbarkeit
Einzelne benötigte Transaktionen sind ausführbar, die Zugriffszeit ist akzeptabel und gleich bleibend.
Verfüg-barkeit
Zugriffsrechte Die benötigten Zugriffsrechte sind ausreichend.
Tabelle 4.6: Qualitätsmerkmale von Datenwerten nach Helfert (in Anlehnung an [He02a])
Für die Befragung wurde im Jahr 2001 ein neun Fragen umfassender Fragenkatalog an 110
Mitarbeiter großer Firmen verschickt. Mittelständische und kleine Unternehmen wurden
nicht berücksichtigt, da eine zu geringe Komplexität der DWH-Systeme angenommen wur-
de. Für knapp 30% der Befragten stellt Datenqualität kein besonderes Problem dar. Im Ge-
gensatz dazu gaben fast 70% der Teilnehmer der Umfrage an, dass Datenqualität in ihrem
Unternehmen ein großes bzw. sehr großes Problem darstellt. Auf die Frage nach vorhande-
nen Datenqualitätsprüfungen im DWH gaben 76% der Befragten an, dass eine Qualitätsprü-
fung bei der Datenanlieferung (ETL-Prozesse) durchgeführt wird. 68% gaben an, dass die
Datenqualität 29
Qualität durch die Endanwender bei der Datenbereitstellung geprüft wird. Bei 60% der Teil-
nehmer wird im Unternehmen die Qualität des Datenbestandes im DWH anhand statistischer
Methoden, Data Mining und Integritätsbedingungen analysiert.
4.7 Folgerung
Wie in diesem Kapitel dargestellt, lässt sich Datenqualität auf unterschiedliche Art und Wei-
se charakterisieren. Die betrachteten Ansätze zur Datenqualität haben als Ergebnis eine Liste
von meist ca. 15 Merkmalen, anhand derer die Qualität der Daten bestimmt werden kann.
Die Ergebnisse sind teilweise unterschiedlichen Kategorien zugeordnet und unterschiedlich
benannt. Ähnliche bzw. gleich benannte Merkmale unterscheiden sich in ihrer Bedeutung. In
Tabelle 4.7 sind beispielhaft die unterschiedlichen Definitionen des Merkmals Vollständig-
keit der vorgestellten Ansätze aufgeführt. Sie stimmen jedoch dahingehend überein, dass es
unbedingt notwendig ist, für eine spätere Messung Merkmale zu definieren, anhand derer
Datenqualität gemessen werden kann.
Verfasser Beschreibung der Vollständigkeit
Wang & Strong [WS96] Die Fähigkeit eines Informationssystems, jeden sinnvol-len Zustand der repräsentierten realen Welt darzustellen.
Wand & Wang [WW96] Die Daten liegen in ausreichendem Umfang für die vor-liegende Aufgabe vor.
Redman [Re96] Der Grad mit dem Werte in einer Datensammlung vor-handen sind.
English [En99] Die Eigenschaft, dass alle erforderlichen Werte in den Datenfeldern vorhanden sind.
Jarke [Ja99, JV97] Der prozentuale Anteil der Real-Welt-Information, der in den Quellen und/oder dem Data Warehouse vorhan-den ist.
Helfert [He02a] Alle Daten sind gemäß Datenmodell erfasst.
Tabelle 4.7: Unterschiedliche Definitionen des Vollständigkeitsmerkmals (in Anlehnung an [SMB05])
Wie in Kapitel 4.4.3 beschrieben, erfolgt die Betrachtung der Datenqualität im Rahmen die-
ser Arbeit aus Anwendersicht und unter Berücksichtigung der entstehenden Kosten. Die
meisten der vorgestellten Ansätze folgen ebenfalls der Ansicht, dass die Qualität der Daten
hinsichtlich ihres Beitrags zur Erreichung der durch die Datennutzer definierten Ziele be-
stimmt wird. Da bereits viele wissenschaftliche Arbeiten zur Identifizierung von Datenquali-
tätsmerkmalen allgemein und auch in Bezug auf ein DWH im Speziellen existieren, ist es
nicht notwendig, in dieser Arbeit erneut Datenqualitätsmerkmale zu erarbeiten. Die von Hel-
fert [He02a] aus Anwendersicht erarbeiteten Qualitätsmerkmale für Datenwerte in einem
Datenqualität 30
DWH in Tabelle 4.6 bilden die Grundlage für die weiteren Untersuchungen. Basierend auf
seinen Ergebnissen wird ein Fragebogen erstellt, mit dessen Hilfe die Qualitätsanforderun-
gen und bereits bestehende Qualitätsmängel der Daten des PAYBACK-DWH erfasst wer-
den. Der Fragebogen und das Vorgehen bei der Umfrage wird in Kapitel 5 erläutert.
Erfassung der relevanten Datenqualitätsmerkmale für das PAYBACK-DWH 31
5 Erfassung der relevanten Datenqualitätsmerkmale für
das PAYBACK-DWH
Wie im vorherigen Kapitel erläutert, findet in dieser Arbeit die Betrachtung der Datenquali-
tät aus Sicht der Anwender unter Berücksichtigung der entstehenden Kosten statt. Basierend
auf den Ergebnissen von Helfert [He02a] wurde ein Fragebogen erstellt, mit dem bei LP die
Anforderungen der Anwender an die Datenqualität ermittelt wurden. Durch die Umfrage
werden die für das Unternehmen Loyalty Partner relevanten Merkmale erfasst.
5.1 Aufbau des Fragebogens
Zur Erfassung der Anforderungen an die Datenqualität bei LP wurde ein Fragebogen erstellt
(siehe Anhang A). Da es sich bei den Befragten zum größten Teil um fachfremde Endan-
wender handelt, die kein bzw. wenig technisches Hintergrundwissen haben, wurden die Fra-
gen zur Qualität entsprechend formuliert. Basis dieses Fragebogens ist die Liste von Merk-
malen, die aus den Ergebnissen der in Kapitel 4.7 erläuterten Arbeit von Helfert [He02a]
abgeleitet wurde. In die Umfrage wurden bewusst auch diejenigen von Helfert identifizierten
Merkmale zur Messung der Datenqualität einbezogen, welche nicht nur die Datenwerte,
sondern z.B. auch die Verfügbarkeit des Systems oder die Darstellung der Daten in den
Auswertungen bzw. Reports betreffen. Die aus der Auswertung dieser Merkmale resultie-
renden Ergebnisse werden von LP verwendet, um Informationen über weitergehende Anfor-
derungen an die Datenqualität zu erkennen und Verbesserungspotentiale bei der Verfügbar-
keit oder den Analysetools zu identifizieren. Sie werden hier nicht näher erläutert, stehen
aber im Anhang B zur Verfügung.
5.2 Durchführung der Umfrage
Für die Befragung wurde der Fragebogen an alle Mitarbeiter der Bereiche des Unternehmens
von LP verschickt, die auf die im PAYBACK-DWH vorgehaltenen Daten für die unter-
schiedlichsten Zwecke zugreifen. Diese Bereiche bzw. Personengruppen sind in Abbildung
5.1 dargestellt.
Erfassung der relevanten Datenqualitätsmerkmale für das PAYBACK-DWH 32
Abbildung 5.1: Die DWH-Nutzer bei Loyalty Partner (eigene Darstellung)
Neben den Anwendern ist auch der Betreiber des DWH, die Abteilung Business Intelligence,
in die Umfrage mit einbezogen. Wie in Kapitel 4.4.3 erwähnt, ist nach [Ga84] das operative
Management bei der Betrachtung der Qualität aus Anwendersicht ebenfalls zu berücksichti-
gen.
Für die Auswertung der Umfrage wurden Bereiche und Personen mit ähnlichen Aufgaben zu
Anwendergruppen zusammengefasst, um eine nach Anwenderaufgaben gegliederte Anforde-
rung an die Datenqualität zu erreichen. Welche Bereiche bzw. Personen zu Anwendergrup-
pen zusammengefasst wurden, ist der Tabelle 5.1 zu entnehmen. Die einzelnen Anwender-
gruppen werden im folgenden Abschnitt näher erläutert.
Anwendergruppe Bereiche / Personen Management Geschäftsführung, Bereichsleitung, Controlling
Prozessverantwortliche Callcentermanagement, Partnermanager, Prozess-verantwortliche, Prämienshop
Datenanalysten Marketingspezialisten, Marktforscher, Analysten
DWH-Management Business Intelligence
Tabelle 5.1: Übersicht über die Anwendergruppen (eigene Darstellung)
Erfassung der relevanten Datenqualitätsmerkmale für das PAYBACK-DWH 33
Management
Die Anwendergruppe Management enthält neben der Geschäftsführung und Bereichsleitung
das Controlling. Das Controlling bei LP sorgt dafür, dass dem Management steuerungsrele-
vante Informationen zur Verfügung stehen. Dabei sind die zentralen Aufgaben die Koordina-
tion und Überwachung der Mehrjahres- und Budgetplanungen, regelmäßige Hochrechnun-
gen und das monatliche Berichtswesen an die Geschäftsführung und die Bereichsverantwort-
lichen.
Für diese Anwendergruppe sind unternehmensweite Finanz- und Prozessdaten von Interesse,
um die verschiedenen Bereiche des Unternehmens zu steuern. Sie greifen entweder selbst
mit Hilfe der Balanced Scorecard15 (BSC) auf die Daten zu oder die Daten werden ihnen mit
Hilfe von Reports zur Verfügung gestellt, die zum großen Teil regelmäßig und automatisiert
erstellt und verschickt werden. Von einigen Personen dieser Anwendergruppe werden Aus-
wertungen auf dem DWH auch selbst durchgeführt, wie bspw. vom Controlling. Mangelnde
Datenqualität kann hier weit reichende Folgen haben. Nicht nur, dass bspw. der Status von
Prozessen falsch eingeschätzt werden könnte, es ist auch möglich, dass Planungen oder die
Geschäftsstrategie auf Basis von Daten mit Qualitätsdefiziten festgelegt werden. Prozesse
bei LP sind bspw. der Druck der Anmeldeformulare, die Herstellung der Karten oder auch
das Einlösen von PAYBACK-Punkten für Prämien.
Prozessverantwortliche
In dieser Anwendergruppe sind alle diejenigen Personen zusammengefasst, welche die Ver-
antwortung für die verschiedensten Prozesse im Unternehmen haben. Dieser Gruppe gehören
die Partnermanager, die Callcentermanager und die Verantwortlichen für den Prämienshop
an. Hauptaufgabe der Partnermanager ist es, die langfristigen und profitablen Geschäftsbe-
ziehungen mit bestehenden Partnern zu sichern und die Programmattraktivität von
PAYBACK durch neue Partnerschaften und Kooperationen im Bereich Produkte und Servi-
ces auszubauen. Dadurch sollen die PAYBACK Erfolgsfaktoren für den Endkunden gesi-
chert werden. Die Callcentermanager steuern das Callcenter, das sich um die Bedürfnisse
der PAYBACK Kartenbesitzer kümmert. Sie steuern die Kundenkontakte bei Service- und
Beschwerdeanliegen, tragen Anregungen und Beschwerden der „Außenwelt“ in die Organi-
15 Mit Hilfe der Balanced Scorecard sollen die wesentlichen Dimensionen eines Unternehmens abge-bildet und die für die Steuerung des Unternehmens benötigten Informationen verfügbar gemacht werden [KN96].
Erfassung der relevanten Datenqualitätsmerkmale für das PAYBACK-DWH 34
sation und geben auf umgekehrtem Weg PAYBACK Aktionen an die Agenten im Callcenter
weiter. Darüber hinaus vermitteln sie an die Agenten Partnerinformationen, Sprachregelun-
gen und Bearbeitungsleitfäden für Kundenanliegen. Die Verantwortlichen des Prämienshop
steuern die im Zusammenhang mit der Einlösung von PAYBACK-Punkten stehenden Pro-
zesse. Sie sind dafür verantwortlich, dass vom Einlösevorgang der Punkte bis zum Versand
der Prämien alles gemäß den Geschäftsregeln abläuft.
Die Prozessverantwortlichen sind an allen Daten der Prozesse interessiert, für die sie die
Verantwortung tragen, um sie entsprechend zu steuern und schnell auf Veränderungen rea-
gieren zu können. Das am häufigsten gebrauchte Instrument zur Beobachtung des Verlaufs
von Prozessen ist für diese Anwendergruppe die BSC, mit deren Hilfe Prozessverläufe in
übersichtlicher, häufig auch graphischer Form dargestellt sind. Auch hier kann mangelnde
Datenqualität weit reichende Folgen haben. Prozesse könnten falsch beurteilt und gesteuert
werden, unnötige oder zu umfangreiche Anpassungen, bspw. von Hardware, können die
Folge sein.
Datenanalysten
Zur Anwendergruppe der Datenanalysten gehören die Marketingspezialisten, die Marktfor-
scher und Analysten. Aufgabe der Marketingspezialisten ist es, neben der Führung der Mar-
ke PAYBACK Werbeaktionen und Kampagnen zu entwickeln, die in diversen Kommunika-
tionskanälen (TV-Spots, Postsendungen etc.) umgesetzt werden. Die Marktforscher befassen
sich mit der Weiterentwicklung des PAYBACK Programms. Ziel ist es, anhand von Konsu-
mentenwünschen und der Marktentwicklung neue Ertragsfelder für PAYBACK zu erschlie-
ßen, sowie neue Produktideen zu entwickeln und damit zur Erhöhung der Kundenbindung
und der Emotionalisierung des Programms beizutragen. Zur Gruppe der Analysten zählen
alle Personen, die für die verschiedensten Zwecke Daten im DWH analysieren. Sie führen im
Auftrag der PAYBACK-Partner und des LP-Managements spezielle, einmalige und komple-
xe Analysen durch, die nicht standardisiert sind.
Die Datenanalysten nutzen die im DWH vorgehaltenen Daten in erster Linie zur Kunden-
segmentierung16 oder zur Berechnung von Punkteübersichten für die Kunden. In erster Linie
sind für sie Kunden- und Transaktionsdaten von Interesse, um auf deren Basis bspw. das
16 Unterteilung der Kunden in Kundengruppen.
Erfassung der relevanten Datenqualitätsmerkmale für das PAYBACK-DWH 35
Käuferverhalten zu analysieren. Sie benutzen dazu entweder Analysetools oder greifen direkt
mit Hilfe von SQL-Statements auf den Datenbestand des PAYBACK-DWH zu.
DWH-Management
Das DWH-Management bei LP wird von der Abteilung Business Intelligence übernommen.
Es ist verantwortlich für die Konsolidierung von programm-, prozess- und abteilungsüber-
greifenden Unternehmensdaten, die im DWH gesammelt, historisiert und aufbereitet sind. BI
stellt sicher, dass die im PAYBACK-DWH vorgehaltenen und aufbereiteten Informationen
durch die verschiedenen Analysetools, standardisierte Reports und die BSC abgerufen wer-
den können. Darüber hinaus nimmt BI Anpassungen der Analysetools vor, damit die Mitar-
beiter der Fachabteilungen ohne spezielle Datenbankkenntnisse einfach und schnell auf den
Datenbestand im DWH zugreifen können.
5.3 Auswertung der Umfrage
Insgesamt wurden zur Erfassung der Qualitätsansprüche der Anwender bei LP 59 Fragebö-
gen per E-Mail verschickt. Von den angeschriebenen Personen antworteten 27, was einer
Rücklaufquote von ca. 46% entspricht, deren Antworten für die Auswertung zur Verfügung
standen. In Tabelle 5.2 ist aufgeführt, wie viele Fragebögen pro Anwendergruppe verschickt
und beantwortet wurden und welcher Rücklaufquote das entspricht. Die Menge der zur Ver-
fügung stehenden Personen der einzelnen Anwendergruppen ist relativ gering und es müssen
daher Schlüsse aus einer kleinen Anzahl von Befragten gezogen werden. Es ist möglich, dass
das Ergebnis nicht repräsentativ ist, jedoch spiegelt es die subjektive Wahrnehmung der Um-
frageteilnehmer wieder.
Anwendergruppe verschickte Fragebögen
beantwortete Fragebögen
Rücklauf-quote
Management 15 5 ~33%
Prozessverantwortliche 29 13 ~45%
Datenanalysten 8 5 ~63%
DWH-Management 7 4 ~57%
Tabelle 5.2: Verschickte und beantwortete Fragebögen (eigene Darstellung)
Im Folgenden werden die Ergebnisse der Umfrageauswertung kurz erläutert. Eine detaillierte
Auswertung der Angaben der einzelnen Anwendergruppen befindet sich im Anhang B. Für
eine einheitliche Darstellung werden alle Ergebnisse der Umfrageauswertung im Folgenden
Erfassung der relevanten Datenqualitätsmerkmale für das PAYBACK-DWH 36
in Prozent angegeben. Zu jedem Diagramm ist zusätzlich die Anzahl der ausgewerteten Fra-
gebögen vermerkt, z.B. „n = 13“ für 13 analysierte Fragbögen.
5.3.1 Anwendergruppe Management
Aus der Anwendergruppe des Managements haben 5 von 15 Personen den Fragebogen aus-
gefüllt und zurückgeschickt. Dies entspricht einer Rücklaufquote von ca. 33%. Die Umfrage-
teilnehmer gaben an, häufig auf Datenqualitätsmängel zu treffen. Dazu wurde von 60% der
Umfrageteilnehmer das Vorkommen von widersprüchlichen und der Vollständigkeit als häu-
fig eingestuft. Auch Defizite bei der Korrektheit der Daten und Dubletten17 werden von 20%
bis 40% der Umfrageteilnehmer als häufig eingeschätzt. In Abbildung 5.2 ist das Ergebnis
der Fragebogenauswertungen dieser vier Merkmale dargestellt.
0%
20%
40%
60%
80%
100%
Widersprüche Vollständigkeit Korrektheit Dubletten
n = 5
nie selten häufig sehr häufig keine Angaben
Abbildung 5.2: Angaben des Managements über existierende Defizite (eigene Darstellung)
Die Umfrageteilnehmer dieser Benutzergruppe gaben an, dass der Aktualität eine wichtige
Bedeutung zukommt und dass der Datenbestand auf einem möglichst hohen aktuellen Stand
gehalten werden soll, was beim PAYBACK-DWH dem Stand der operativen Systeme vom
Vortag entspricht. Unterschiedliche Angaben haben die Teilnehmer zur als insgesamt wich-
tig eingestuften Historisierung gemacht. Während es für fast die Hälfte der Umfrageteilneh-
17 Mehrfaches Vorkommen von Daten (Duplikate).
Erfassung der relevanten Datenqualitätsmerkmale für das PAYBACK-DWH 37
mer genügt, Daten nur ein Jahr im DWH vorzuhalten, benötigt etwas mehr als die Hälfte von
ihnen alle jemals erfassten Daten seit dem Programmstart von PAYBACK im Jahr 2000. Die
ständige Systemverfügbarkeit und eine kurze Laufzeit von Auswertungen ist dieser Benut-
zergruppe überwiegend wichtig bzw. sehr wichtig. Die Gewichtung dieser Merkmale durch
die Teilnehmer der Umfrage ist in Abbildung 5.3 dargestellt.
0%
20%
40%
60%
80%
100%
Aktualität Historisierung System-verfügbarkeit
Laufzeit
n = 5
sehr wichtig wichtig weniger wichtig unwichtig keine Angaben
Abbildung 5.3: Gewichtung der Merkmale durch das Management (eigene Darstellung)
60% der Teilnehmer gab in der Umfrage ohne nähere Angabe von Gründen an, nicht auf alle
für die eigenen Aufgaben benötigen Daten zugreifen zu können. Eine Nachfrage nach den
Gründen hat ergeben, dass die Befragten damit mehrheitlich Daten der operativen Systeme
gemeint haben, auf die sie keinen Zugriff zu Auswertungszwecken bekommen.
Im Freitextfeld zur Datenqualität wurden von den Befragten dieser Anwendergruppe die
folgenden Anforderungen an die Datenqualität angegeben18:
• Überprüfung der Daten vor der Kommunikation / Höhere Zuverlässigkeit in der Be-
reitstellung
18 Hier werden nur die auf Datenqualität bezogenen Angaben aufgeführt. Im Anhang B sind alle von den Umfrageteilnehmern gemachten Angaben in Freitextfeldern aufgeführt.
Erfassung der relevanten Datenqualitätsmerkmale für das PAYBACK-DWH 38
• Pünktlichkeit in der Bereitstellung der Daten
• Keine Dubletten im Datenbestand
5.3.2 Anwendergruppe Prozessverantwortliche
An die Anwendergruppe der Prozessverantwortlichen wurden 29 Fragebögen verschickt, von
denen 13 ausgefüllt und zurückgeschickt wurden. Das entspricht einer Rücklaufquote von ca.
45%. Die Umfrageteilnehmer gaben an, überwiegend wenige Datenqualitätsmängel vorzu-
finden. Während Qualitätsdefizite bei der Vollständigkeit und Korrektheit der Daten meis-
tens als selten eingestuft wurden und auch Dubletten nur in seltenen Fällen auftauchen, wur-
den Widersprüche der Daten von ca. 30% der Umfrageteilnehmer als häufig eingeschätzt.
Diese Widersprüche sind auf die verschiedenen eingesetzten Analysetools zurückzuführen,
deren Analysen nicht einheitlich aufgebaut sind. Dies war den Kommentarfeldern des Frage-
bogens zu entnehmen. Das Ergebnis der Auswertung zu diesen vier Merkmalen ist in
Abbildung 5.4 dargestellt.
0%
20%
40%
60%
80%
100%
Widersprüche Vollständigkeit Korrekheit Dubletten
n = 13
nie selten häufig sehr häufig keine Angaben
Abbildung 5.4: Angaben der Prozessverantwortlichen über existierende Defizite (eigene Darstellung)
Die Umfrageteilnehmer dieser Anwendergruppe gaben an, dass es für die Steuerung von
Prozessen notwendig ist, auf einen möglichst aktuellen Datenbestand zugreifen zu können.
Ca. 85% halten Daten mit der maximal möglichen Aktualität für wichtig bzw. sehr wichtig.
Für die restlichen ca. 15% genügt der Aktualitätsstand der Vorwoche. Ebenfalls 85% der
Teilnehmer gaben an, dass die Historisierung der Daten wichtig bzw. sehr wichtig ist und
Erfassung der relevanten Datenqualitätsmerkmale für das PAYBACK-DWH 39
dass es zur Erledigung ihrer Aufgaben ausreicht, Daten ein bis zwei Jahre im PAYBACK-
DWH vorzuhalten. Die verbliebenen 15% benötigen die Daten bis zu drei Jahre historisiert
vorgehalten. Jeweils ca. 70% gaben an, dass ihnen eine ständige Systemverfügbarkeit und
möglichst kurze Laufzeiten wichtig bis sehr wichtig sind. Die Gewichtung dieser Merkmale
durch die Umfrageteilnehmer ist in Abbildung 5.5 dargestellt.
0%
20%
40%
60%
80%
100%
Aktualität Historisierung System-verfügbarkeit
Laufzeit
n = 13
sehr wichtig wichtig weniger wichtig unwichtig keine Angaben
Abbildung 5.5: Gewichtung der Merkmale durch die Prozessverantwortlichen (eigene Darstellung)
Zusätzlich wurden im Freitextfeld zur Datenqualität von den Befragten dieser Anwender-
gruppe folgende Datenqualitätsanforderungen angegeben:
• 100% Übereinstimmung mit den Daten der operativen Systeme unter Berücksichti-
gung der durch die Geschäftsregeln definierten Zeitpunkte der ETL-Prozesse
• Vollständigkeit des Datenmodells (alle für die Auswertungen wesentlichen Attribute
der operativen Systeme müssen auch im DWH vorhanden sein)
• Einhaltung von Geschäftsregeln
• Überprüfung der Daten vor der Kommunikation
• Höhere Pünktlichkeit in der Bereitstellung
Erfassung der relevanten Datenqualitätsmerkmale für das PAYBACK-DWH 40
5.3.3 Anwendergruppe Datenanalysten
An die Datenanalysten wurden acht Fragebögen versandt, von denen fünf ausgefüllt zurück-
geschickt wurden. Dies entspricht einer Rücklaufquote von 63%. Die Umfrageteilnehmer
gaben an, während ihrer umfangreichen Analysen schon auf diverse Datenqualitätsprobleme
gestoßen zu sein. Dabei wurde das Vorkommen von Widersprüchen und Problemen mit der
Vollständigkeit bzw. der Korrektheit überwiegend als selten eingestuft. Auf Dubletten sind
die Analysten kaum gestoßen. Das Ergebnis der Fragebogenauswertung der zu diesen
Merkmalen gemachten Angaben ist in Abbildung 5.6 dargestellt.
0%
20%
40%
60%
80%
100%
Widersprüche Vollständigkeit Korrekheit Dubletten
n = 5
nie selten häufig sehr häufig keine Angaben
Abbildung 5.6: Angaben der Datenanalysten über existierende Defizite (eigene Darstellung)
Die Anwendergruppe der Datenanalysten schreibt der Aktualität eine wichtige Rolle zu und
würde gerne immer auf einem höchst möglichen aktuellen Datenbestand arbeiten. Der Histo-
risierung kommt eine ähnliche Bedeutung zu. Alle Befragten halten die Historisierung für
wichtig bzw. sehr wichtig, wobei die Mehrheit fordert, dass alle Daten seit dem Programm-
start von PAYBACK ständig verfügbar sein sollten. Zur Erledigung ihrer Aufgaben sollte für
die Datenanalysten das System ständig verfügbar und die Laufzeit der Auswertungen mög-
lichst kurz sein. In Abbildung 5.7 sind die Gewichtungen dieser Merkmale durch die Umfra-
geteilnehmer veranschaulicht.
Erfassung der relevanten Datenqualitätsmerkmale für das PAYBACK-DWH 41
0%
20%
40%
60%
80%
100%
Aktualität Historisierung System-verfügbarkeit
Laufzeit
n = 5
sehr wichtig wichtig weniger wichtig unwichtig keine Angaben
Abbildung 5.7: Gewichtung der einzelnen Merkmale durch die Datenanalysten (eigene Darstellung)
Die Befragten dieser Anwendergruppe gaben im Freitextfeld zur Datenqualität die folgenden
Anforderungen an die Datenqualität an:
• Eindeutigkeit
• Zugriffsrechte auf alle notwendigen Tabellen
• Zuverlässigkeit
• Einhaltung von Geschäftsregeln
5.3.4 Anwendergruppe DWH-Management
An die kleinste Benutzergruppe, die des DWH-Managements, wurden sieben Fragebögen
versandt. Davon wurden vier ausgefüllt und zurückgeschickt. Das entspricht einer Rücklauf-
quote von ca. 57%. Die Umfrageteilnehmer gaben an, bei ihrer täglichen Arbeit überwiegend
selten auf Dubletten bei den Daten zu stoßen. Auf Korrektheitsprobleme und Vollständig-
keitsdefizite trafen 25% der Teilnehmer häufig und widersprüchliche Daten sind sogar 50%
der Teilnehmer häufig aufgefallen. Das Ergebnis der Fragebogenauswertungen zu diesen
vier Merkmalen ist in Abbildung 5.8 aufgezeigt.
Erfassung der relevanten Datenqualitätsmerkmale für das PAYBACK-DWH 42
0%
20%
40%
60%
80%
100%
Widersprüche Vollständigkeit Korrekheit Dubletten
n = 4
nie selten häufig sehr häufig keine Angaben
Abbildung 5.8: Angaben des DWH-Managements über existierende Defizite (eigene Darstellung)
Die Aktualität wurde von 75% der Teilnehmer als weniger wichtig beurteilt und ein Stand
der Vorwoche genügt 50% der Umfrageteilnehmer. Einstimmig wurde die Historisierung als
weniger wichtig für die eigenen Aufgaben beurteilt und eine Historisierung für ein bis drei
Jahre von allen als ausreichend bezeichnet. Eine ständige Verfügbarkeit des Systems wurde
von 75% der Teilnehmer als sehr wichtig beurteilt und eine möglichst kurze Laufzeit ist nur
für 50% wichtig. Die Gewichtung dieser Merkmale durch die Umfrageteilnehmer ist in
Abbildung 5.9 dargestellt.
Erfassung der relevanten Datenqualitätsmerkmale für das PAYBACK-DWH 43
0%
20%
40%
60%
80%
100%
Aktualität Historisierung System-verfügbarkeit
Laufzeit
n = 4
sehr wichtig wichtig weniger wichtig unwichtig keine Angaben
Abbildung 5.9: Gewichtung der einzelnen Merkmale durch das DWH-Management (eigene Darstellung)
Zusätzlich wurden von den Befragten dieser Anwendergruppe folgende Anforderungen an
die Datenqualität im Freitextfeld angegeben:
• Einhaltung der Geschäftsregeln
• Keine Dubletten
• Eindeutigkeit
5.3.5 Zusammenfassung
Zusammenfassend lässt sich sagen, dass die Anwendergruppen durchaus unterschiedliche
Angaben zur Datenqualität gemacht haben. Das Auftreten von Widersprüchen wird durch
die Anwendergruppen unterschiedlich bewertet. Während zwei der Anwendergruppen das
Auftreten von Widersprüchen vorwiegend als selten bezeichnen, wird es von den restlichen
beiden Gruppen als häufig angesehen. Datenqualitätsdefizite beim Merkmal der Vollstän-
digkeit werden nur vom Management als überwiegend häufig angesehen, während die restli-
chen drei Anwendergruppen das Auftreten als eher selten bezeichnet. Defizite der Korrekt-
heit werden mehrheitlich als selten bis häufig angesehen, wobei die Beurteilung als selten
bei zwei Gruppen überwiegt. Das Auftreten von Dubletten wird nur vom Management als
häufig bis selten angesehen. Die restlichen drei Gruppen bewerten das Vorkommen als selten
bis nie.
Erfassung der relevanten Datenqualitätsmerkmale für das PAYBACK-DWH 44
Die Systemverfügbarkeit und eine möglichst kurze Laufzeit bei Abfragen ist für alle An-
wendergruppen von ähnlich hoher Bedeutung. Die Aktualität und die Historisierung von
Daten bewerten alle Anwendergruppen, außer dem DWH-Management, überwiegend als
wichtig bis sehr wichtig. Mehrheitlich wird von ihnen ein höchst möglicher Grad an Aktuali-
tät gefordert, während sich jedoch die Angaben darüber, wie lange die Daten historisiert
vorgehalten werden sollten, unterscheiden.
Die Datenanalysten fordern einstimmig alle jemals erfassten Daten vorzuhalten und die Pro-
zessverantwortlichen tun dies mehrheitlich ebenfalls. Die anderen beiden Anwendergruppen
machten hier hingegen sehr unterschiedliche Angaben. Die Befragten des DWH-
Managements stufen die Aktualität und Historisierung mehrheitlich als weniger wichtig ein.
5.4 Nicht weiter betrachtete Datenqualitätsmerkmale
Die vorherigen Abschnitte zeigen auf, welche Merkmale von den Anwendern der verschie-
denen Anwendergruppen als wichtig erachtet werden und welche nicht. In diesem Abschnitt
werden die Kriterien aufgeführt, die daher in dieser Arbeit nicht weiter berücksichtigt wer-
den.
Die von Helfert [He02a] als Datenherkunft bezeichnete Datentransparenz beschreibt er
folgendermaßen: „Die Datenherkunft und die vorgenommenen Datentransformationen sind
bekannt.“ Wie in Kapitel 4.4.3 beschrieben, wird im Rahmen dieser Arbeit die Befüllung des
DWH durch die ETL-Prozesse als die Datengewinnung gesehen. Alle Quellen der Daten des
DWH sind ausschließlich operative Systeme die bekannt sind und deren Daten als „richtig“
vorausgesetzt werden. Für die regelmäßige und korrekte Befüllung des DWH sind die ETL-
Prozesse zuständig, wie in Kapitel 3.2.1 erläutert. Durch die Geschäftsregeln sind sie eindeu-
tig definiert und es ist festgelegt, aus welchen operativen Systemen die Daten stammen und
welche Transformationen an ihnen vorgenommen werden. Deshalb wird dieses Merkmal
nicht weiter untersucht.
Helfert [He02a] versteht unter dem Merkmal der Zuverlässigkeit, dass „die Glaubwürdig-
keit der Daten konstant ist“. Nach [Br80] kann die Zuverlässigkeit als ein Maß der Überein-
stimmung von Erwartung und „möglichen Fähigkeiten“ gesehen werden und auch, ob Daten
die Anforderungen der Benutzer erfüllen bzw. mit der Realität übereinstimmen [AA87].
Nach [WW96] kann die Zuverlässigkeit als Korrektheit interpretiert werden. Dieses Merk-
Erfassung der relevanten Datenqualitätsmerkmale für das PAYBACK-DWH 45
mal wird nicht weiter gesondert betrachtet, da es im Rahmen der Korrektheit bereits berück-
sichtigt ist, das in Kapitel 6.2 näher erläutert wird.
Helfert [He02a] versteht unter dem Merkmal der zeitlichen Konsistenz, dass „alle Daten-
werte bzgl. eines Zeitpunktes gleichermaßen aktuell sind“. Beim PAYBACK-DWH kann die
Aktualität der Daten nur zum aktuellen Betrachtungszeitpunkt festgestellt werden. Aufgrund
des vorhandenen Datenmodells sind keine Informationen über die Aktualität zu einem Zeit-
punkt in der Vergangenheit vorhanden. Daher kann das Merkmal der zeitlichen Konsistenz
auch nicht überprüft werden und wird in dieser Arbeit nicht weiter behandelt.
Die Anforderungen durch das Merkmal der Relevanz, dass „Datenwerte auf einen relevan-
ten Datenausschnitt beschränkt werden können“ [He02a] ist in der Designphase des Daten-
modells zu berücksichtigen. Gleichermaßen verhält es sich mit dem Merkmal des zeitlichen
Bezugs, durch das gefordert ist, dass sich „die Datenwerte auf den benötigten Zeitraum be-
ziehen“. Denn schon zum Zeitpunkt der Erstellung des Datenmodells eines DWH muss fest-
stehen, zu welchem Zweck und über welchen Zeitraum die im DWH vorgehaltenen Daten
später analysiert werden (siehe Kapitel 3.2.1) und daher auch, wie die Daten selektiert bzw.
eingeschränkt werden sollen.
Das Merkmal der zeitlichen Verfügbarkeit wurde von einigen wenigen Umfrageteilneh-
mern der Anwendergruppen des Managements und der Prozessverantwortlichen im Freitext-
feld der Anforderungen an die Datenqualität erwähnt und als „höhere Pünktlichkeit in der
Bereitstellung der Daten“ bezeichnet. Dieses Merkmal, bei dem nach Helfert gefordert ist,
dass „die Daten rechtzeitig zur Verfügung stehen“ [He02a], ist eine Anforderung an den
operativen Betrieb. Denn durch regelmäßige und fehlerfreie ETL-Prozesse wird gewährleis-
tet, dass die Daten zum festgelegten Zeitpunkt in das DWH gelangen und dort zur Verfügung
stehen. Es wird deshalb nicht weiter behandelt, da sich dieses Merkmal nicht auf die Qualität
der Datenwerte bezieht.
Das Merkmal der Systemverfügbarkeit, das Helfert [HE02a] mit „das Gesamtsystem ist
verfügbar“ beschreibt, wurde von allen Anwendergruppen mehrheitlich als wichtig bis sehr
wichtig beurteilt. Da dieses Merkmal nicht die Datenwerte betrifft und, wie in Kapitel 1.3
erwähnt, für diese Arbeit vorausgesetzt wird, dass das System (Netzwerk, Datenbank etc.)
immer verfügbar ist, wird es nicht weiter berücksichtigt.
Die Transaktionsverfügbarkeit beschreibt Helfert folgendermaßen: „Einzelne benötigte
Transaktionen sind ausführbar, die Zugriffszeit ist akzeptabel und gleich bleibend“ [He02a].
Erfassung der relevanten Datenqualitätsmerkmale für das PAYBACK-DWH 46
Sie wurde in der Umfrage auf den Begriff der Laufzeit reduziert und wurde von ca. 20% bis
50% der Umfrageteilnehmer aller Anwendergruppen als sehr wichtig eingestuft. Allerdings
bezieht sich dieses Merkmal auf die Verfügbarkeit und Last des DWH, des gesamten Sys-
tems und des Netzwerks und wird daher nicht weiter untersucht.
Obwohl die Anwendergruppen des Managements und der Prozessverantwortlichen bei der
Umfrage mehrheitlich angegeben haben, nicht auf alle Daten Zugriff zu haben, wird auch
das Merkmal Zugriffsrechte nicht weiter untersucht. Dieses Merkmal, bei dem gefordert ist,
dass „die benötigten Zugriffsrechte ausreichend sind“ [He02a], betrifft nicht die Datenwerte
im DWH, sondern betrifft die Rechte, die durch die Administratoren der Datenbank bzw. der
Analysetools vergeben werden.
Die Mehrheit der Anwendergruppen schätzt das Auftreten von Dubletten als nie bis selten
ein. Hinzu kommt die Vorgabe für das PAYBACK-DWH, dass der Datenbestand mit dem
der operativen Systeme übereinstimmen soll (unter Beachtung der bei den Befüllungsprozes-
sen durchgeführten Transformationen). Daher werden Dubletten im Rahmen dieser Arbeit
nicht weiter untersucht. Falls Dubletten in den operativen Systemen vorhanden sind, sollen
diese laut den Befüllungsregeln auch in das PAYBACK-DWH übernommen werden.
Die Eindeutigkeit der Daten, die von einigen Umfrageteilnehmern als Datenqualitätsmerk-
mal angegeben wurde, ist durch die operativen Systeme zu gewährleisten. Durch die Vorga-
be, dass alle Daten der operativen Systeme unter Berücksichtigung der vorgenommenen
Transformationen bei den Befüllungsprozessen in das DWH zu übernehmen sind, werden
auch nicht eindeutige Daten geladen. Aus diesem Grund wird die Eindeutigkeit nicht weiter
behandelt.
Die Forderungen von einigen Umfrageteilnehmern nach der „Einhaltung von Geschäftsre-
geln“ ist eine Forderung an eindeutige, zweifelsfreie und unbedingt einzuhaltende Geschäfts-
regeln. Dies ist, wie auch die Forderung, bei „wiederholten Ladevorgängen eine Vervielfa-
chung (Duplikate) der Daten zu vermeiden“ eine Anforderung an den operativen Betrieb und
wird nicht weiter behandelt.
Ähnliches gilt für die Anorderung, dass „alle für die Auswertungen wesentlichen Attribute
der operativen Systeme auch im DWH vorhanden sein müssen“. Sie betrifft das Datenmodell
und wird nicht weiter behandelt.
Erfassung der relevanten Datenqualitätsmerkmale für das PAYBACK-DWH 47
5.5 Datenqualitätsmerkmale dieser Arbeit
Nachdem die Anforderungen der verschiedenen Anwendergruppen erfasst und ausgewertet
wurden, erfolgt die Auswahl der für LP relevanten Qualitätsmerkmale, die in dieser Arbeit
weiter behandelt werden. Von Bedeutung sind diejenigen Merkmale, welche die im
PAYBACK-DWH vorgehaltenen Datenwerte betreffen und die mehrheitlich durch die An-
wendergruppen als bedeutend erachtet werden bzw. bei denen schon Defizite der Datenqua-
lität aufgefallen sind.
Das Merkmal der Widerspruchsfreiheit, dessen Verletzung von 20% bis 60% der Teilneh-
mer aller Anwendergruppen als häufig eingestuft wurde, wird für diese Arbeit übernommen,
ebenso wie das Merkmal der Vollständigkeit, dessen Verletzung 20% bis 60% von drei der
Anwendergruppen als häufig angesehen wurde. Ähnlich wurden auch Defizite bei der Kor-
rektheit der Daten eingestuft. Ca. 15% bis 25% der Umfrageteilnehmer aller Anwender-
gruppen stufen das Vorkommen von Defiziten bei der Korrektheit als häufig und ca. 15% bis
75% als selten ein. Deshalb wird auch dieses Merkmal zur Bestimmung der Datenqualität in
diese Arbeit mit einbezogen.
Der Aktualität wird von allen Anwendergruppen hohe Bedeutung zugesprochen. Ca. 25%
bis 60% der Umfrageteilnehmer aller Gruppen halten die Aktualität der Daten für wichtig
und sogar ca. 30% bis 40% der Umfrageteilnehmer von drei der vier Anwendergruppen für
sehr wichtig. Das Merkmal der Historisierung wird von ca. 46% bis 60% der Umfrageteil-
nehmer von drei der vier Anwendergruppen für wichtig, von ca. 20% bis 40% sogar für sehr
wichtig gehalten. Aufgrund dieser Beurteilung werden auch diese Merkmale zur Bestim-
mung der Datenqualität übernommen.
Diese Auswahl wird auch durch die Angaben in den Kommentarfeldern der ausgewerteten
Fragebögen bestätigt. Dort war ebenfalls häufig zu entnehmen, dass die Datennutzer die
Erfüllung dieser Datenqualitätsmerkmale für wichtig erachten. Diese Merkmale werden im
folgenden Kapitel nun genauer untersucht, um sie klar voneinander abzugrenzen und im
Rahmen dieser Arbeit zu definieren.
Definition der Datenqualitätsmerkmale 48
6 Definition der Datenqualitätsmerkmale
Mit der im vorherigen Kapitel beschriebenen Auswertung der Umfrage wurden die für LP
relevanten Datenqualitätsmerkmale ermittelt, die in diesem Kapitel genauer beschrieben
werden. Wie in Kapitel 4.1 erwähnt, gibt es keine eindeutige und klare Vorgabe für die De-
finition und Bezeichnung von Qualitätsmerkmalen in der Literatur. Auch die in Kapitel 4
erwähnten Arbeiten definieren und bezeichnen die identifizierten Merkmale nicht einheit-
lich. Da die Werke zu Datenqualität höchstens eine, wenn überhaupt, sehr ungenaue Be-
schreibung der einzelnen Merkmale enthalten, ist es notwendig, diese Merkmale genau zu
beschreiben. Hinzu kommt, dass sich die Datenhaltung in einem Data Warehouse von der
Datenhaltung in einem operativen System unterscheidet (siehe Kapitel 3.2.2). Daher werden
nun die in Abbildung 6.1 dargestellten Datenqualitätsmerkmale im Sinne dieser Arbeit - auf
ein DWH bezogen - genau definiert.
Abbildung 6.1: Die Datenqualitätsmerkmale beim PAYBACK-DWH (eigene Darstellung)
Die Definition der einzelnen Qualitätsmerkmale bezieht sich nicht ausschließlich auf das
PAYBACK-DWH von Loyalty Partner, sondern auf Data Warehouses im Allgemeinen, die
dem PAYBACK-DWH ähnlich sind. Damit sind DWHs gemeint, die auf einer zentral orga-
Definition der Datenqualitätsmerkmale 49
nisierte Architektur und einem relationalen Schema basieren und deren Datenbestand nicht
in „realtime“19 bzw. „righttime“ 20 befüllt wird (z.B. nur einmal täglich). Falls es die genaue
Definition eines Datenqualitätsmerkmals erfordert, wird jedoch in dieser Arbeit auf Details
des PAYBACK-DWH eingegangen und das Merkmal in Bezug auf das PAYBACK-DWH
definiert.
6.1 Vollständigkeit
Nach Helfert [He02a] ist das Vollständigkeitskriterium erfüllt, wenn „alle Daten gemäß dem
Datenmodell erfasst sind“. Bei der Definition der Vollständigkeit ist zu unterscheiden, ob im
Datenmodell Null-Werte zugelassen sind oder nicht [SMB05]. Da sie beim PAYBACK-
DWH zugelassen sind, wird die Vollständigkeit im Rahmen dieser Arbeit auf vorhandene
Null-Werte im Datenmodell definiert. Bei vorhandenen Null-Werten im Datenmodell sollen
die Ursachen für die fehlenden Werte ergründet werden. Drei Gründe für das Fehlen von
Attributwerten wurden dazu identifiziert [SMB05]. Liegen in einer Tabelle die Namen von
Personen vor, und sind nur zu einigen die E-Mail-Adressen vorhanden, dann hat eine Person
entweder keine E-Mail-Adresse (dann existiert kein Wert für dieses Attribut) oder es exis-
tiert eine, die aber nicht bekannt und somit nicht in der Tabelle gespeichert ist oder es ist
nicht bekannt, ob eine E-Mail-Adresse existiert. Da in dieser Arbeit Ursachen von Datenqua-
litätsmängeln und damit einhergehend auch Ursachen von Null-Werten nicht behandelt wer-
den (siehe Kapitel 1.2), sind sie nicht Thema dieser Arbeit.
Um die Definition von Helfert zu konkretisieren, ist eine genauere Betrachtung der Vollstän-
digkeit nötig. Es existieren fünf verschiedene Typen der Vollständigkeit, die in Tabelle 6.1
aufgeführt sind und die im Folgenden näher erläutert werden [SMB05].
19 Informationen sollen möglichst schon zum Zeitpunkt des Entstehens nicht nur in den operativen Systemen, sondern auch im DWH zur Verfügung stehen [Ch04].
20 Die richtige Information, im richtigen Format und zur richtigen Zeit liefern. Dazu muss eine Zweck-Mittel-Relation für jeden Einzelfall bestimmt werden, also situationsabhängig jeweils die „richtige Zeit“ unter Berücksichtung von Risiken und Kosten definiert werden [Wi06].
Definition der Datenqualitätsmerkmale 50
Typ Beschreibung
Wert-Vollständigkeit Alle als relevant definierten Attributwerte eines Tupels sind vorhanden.
Tupel-Vollständigkeit Alle Attributwerte eines Tupels sind vor-handen.
Attribut-Vollständigkeit
Alle Werte eines Attributes (einer Spalte) sind vorhanden.
Relation-Vollständigkeit
Alle Werte in der gesamten Relation sind vorhanden.
Tupel-Relation-Vollständigkeit
Alle Tupel sind in der Relation vorhanden.
Tabelle 6.1: Die unterschiedlichen Typen der Vollständigkeit (in Anlehnung an [SMB05])
Die Tupel-Vollständigkeit ist erfüllt, wenn alle Attributwerte eines Tupels vorhanden sind.
In der Tabelle 6.2 erfüllen die Tupel mit der Matrikelnummer 6754, 1325 und 1258 die Tu-
pel-Vollständigkeit. Die Tupel mit den Matrikelnummern 8562 und 4785 sind dagegen nicht
vollständig, da ein bzw. zwei Werte fehlen. Die sog. Wert-Vollständigkeit ist eine etwas
abgeschwächte Form der Tupel-Vollständigkeit. Dabei wird zwischen relevanten und nicht
relevanten Attributwerten unterschieden. Die Wert-Vollständigkeit ist erfüllt, wenn die vor-
her als relevant definierten Attributwerte eines Tupels vorhanden sind. Definiert man das
Attribut Prüfungstag in Tabelle 6.2 als nicht relevant, würde das Tupel mit der Matrikel-
nummer 8562 die Wert-Vollständigkeit erfüllen.
Falls alle Werte eines Attributes (einer Spalte), in der gesamten Tabelle vorhanden sind, ist
die Attribut-Vollständigkeit erfüllt. In der Tabelle 6.2 erfüllen diese die Attribute Matrikel-
nummer, Vorname und Nachname. Im Gegensatz dazu fehlen bei den Attributen Punkte und
Prüfungstag ein bzw. zwei Werte, bei denen die Attribut-Vollständigkeit somit nicht erfüllt
ist. Bei der Relation-Vollständigkeit werden fehlende Werte in der gesamten Relation un-
tersucht. Dabei spielt es keine Rolle, bei welchem Tupel bzw. welchem Attribut der Wert
fehlt. Demnach sind in der Tabelle 6.2 insgesamt drei Null-Werte vorhanden und daher ist
die Relation-Vollständigkeit nicht erfüllt. Bei der Tupel-Relation-Vollständigkeit ist gefor-
dert, dass alle Tupel in der Relation vorhanden sind. Fehlt also ein ganzes Tupel, so ist die
Tupel-Relation-Vollständigkeit nicht erfüllt. In der als Beispiel dienenden Tabelle 6.2 wäre
das der Fall, wenn das zum Studenten Elmar Jürgens gehörende Tupel in der Relation fehlt.
Definition der Datenqualitätsmerkmale 51
Matrikelnummer Vorname Nachname Punkte Prüfungstag 6754 Michael Köpf 26 23.03.2006 8562 Mario Ullrich 12 4785 Juliane Schneider 1325 Karl Groß 32 17.04.2006 1258 Kathrin Schmidt 29 28.02.2006
Tabelle 6.2: Beispiel-Relation für die Vollständigkeit (eigene Darstellung)
Im Rahmen dieser Arbeit gilt die Vorgabe, dass im PAYBACK-DWH alle durch die Ge-
schäftsregeln definierten Daten aus den operativen Systemen vorgehalten sein sollen. Hinzu
kommt, dass beim PAYBACK-DWH Null-Werte zugelassen sind. Daher konzentriert sich
diese Arbeit auf die Wert- und Tupel-Relation-Vollständigkeit.
Wert-Vollständigkeit: Die Wert-Vollständigkeit gilt im Sinne
dieser Arbeit bei einem DWH als erfüllt, wenn alle diejenigen Att-
ributwerte eines Tupels befüllt sind, die auch in den durch die Ge-
schäftsregeln definierten, als Quelle dienenden Feldern der opera-
tiven Systeme befüllt sind.
Tupel-Relation-Vollständigkeit: Die Tupel-Relation-Vollständig-
keit gilt im Sinne dieser Arbeit als erfüllt, wenn alle nach den Ge-
schäftsregeln im DWH zu bildenden Tupel auch wirklich vorhan-
den sind. Zur Erfüllung dieses Merkmals ist es irrelevant, ob die
Wert-Vollständigkeit erfüllt ist.
Vollständigkeit: Ist sowohl die Wert-Vollständigkeit als auch die
Tupel-Relation-Vollständigkeit erfüllt, gilt der Datenbestand einer
Relation im DWH im Sinne dieser Arbeit als vollständig. Das
heißt, dass alle Datensätze vollständig gemäß den Geschäfts- und
Transformationsregeln aus den operativen Systemen geladen wor-
den sind und somit alle Daten im DWH zur Verfügung stehen.
6.2 Korrektheit
Das Qualitätsmerkmal Korrektheit bezieht sich auf den Inhalt der einzelnen Datensätze. Hel-
fert [He02a] beschreibt das Qualitätsmerkmal der Korrektheit folgendermaßen: „Die Daten
Definition der Datenqualitätsmerkmale 52
stimmen inhaltlich mit der Datendefinition überein und sind empirisch korrekt.“ Es bleibt zu
definieren, was „korrekt“ im Sinne dieser Arbeit bedeutet. Beim PAYBACK-DWH gilt die
Vorgabe, dass ein Datensatz dann korrekt ist, falls er (unter Berücksichtigung der vorge-
nommenen Transformationen bei der Befüllung) mit den Daten der Quellsysteme überein-
stimmt. Die von Helfert erwähnte „empirische Korrektheit“ wird daher nicht berücksichtigt.
Anhand der in den Geschäftsregeln eindeutig definierten Transformationsregeln ist festge-
legt, aus welchen Quellen ein Attributfeld im DWH befüllt wird. Wenn im DWH einer Bank
bspw. das Gesamtvermögen eines Kunden vorgehalten wird, ist durch die Geschäftsregeln
festgelegt, dass sich dieser Wert z.B. aus dem Kontostand der Girokontos, dem aktuellen
Wert der im Depot befindlichen Wertpapiere und anderen Vermögenswerten oder Schulden
zusammensetzt. Bei einer Überprüfung der Korrektheit muss jede einzelne dieser Berech-
nungen nach den festgelegten Transformationsregeln erneut durchgeführt werden, um das
jeweilige Ergebnis mit den im DWH gespeicherten Attributwerten vergleichen zu können21.
Korrektheit: Ein Datensatz gilt im Sinne dieser Arbeit als korrekt,
wenn alle seine Attributwerte exakt nach den in den Geschäftsre-
geln festgelegten Transformationsregeln befüllt worden sind. Die
einzelnen Attributfelder müssen bei „1:1-Transformationen“
(Transformationen, bei denen Attributwerte aus den operativen
Systemen unverändert in das DWH kopiert werden) exakt mit den
Werten der operativen Systeme übereinstimmen. Bei komplexen
Transformationen, bei denen Attributwerte im DWH aus einem
oder mehreren Werten der operativen Systeme berechnet werden,
müssen diese Berechnungen korrekt durchgeführt worden sein. Ei-
ne Relation gilt als korrekt, wenn alle darin enthaltenen Datensätze
korrekt befüllt sind.
In der Literatur tauchen auch die Begriffe der syntaktischen bzw. semantischen Korrektheit
im Zusammenhang mit Datenqualität auf [SMB05]. Helfert [He02a] verlangt zur Erfüllung
des Merkmals der syntaktischen Korrektheit, „dass die Daten mit der spezifizierten Syntax
(Format) übereinstimmen“. Darunter wird bspw. die falsche Schreibweise eines Attributwer-
21 Auch ein aus dem operativen System in das DWH „1:1“ kopierter Attributwert entspricht einer (sehr einfachen) Transformationsregel. In diesem Fall genügt es, die Attributwerte direkt zu ver-gleichen.
Definition der Datenqualitätsmerkmale 53
tes verstanden. Eine Verletzung der syntaktischen Korrektheit liegt dann vor, wenn z.B. statt
des richtigen Attributwerts „Roman“ der Attributwert „Rman“ vorhanden ist. Die semanti-
sche Korrektheit ist dann nicht erfüllt, wenn ein Attributwert zwar syntaktisch korrekt ist,
aber ein falscher Wert zugeordnet ist. Das ist der Fall, wenn zu einem Roman bspw. der fal-
sche Autor gespeichert ist. Diese Definitionen werden nicht übernommen, da im Rahmen
dieser Arbeit die Korrektheit dann erfüllt ist, wenn ein Datensatz mit den Einträgen in den
Quellsystemen22 übereinstimmt.
6.3 Aktualität
Nach der Definition von Helfert [He02a] besteht die Aktualität darin, „dass Datenwerte auf
den gegenwärtigen Zeitpunkt erfasst sind“. In dieser Arbeit wird jedoch davon ausgegangen,
dass die Befüllung des DWH nicht in „realtime“ bzw. „righttime“ durchgeführt wird, son-
dern z.B. nur einmal täglich. Deshalb kann der Datenbestand im DWH bestenfalls dem Stand
der operativen Systeme entsprechen, der den ETL-Prozessen zum Zeitpunkt des Starts des
letzten Befüllungsprozesses zur Verfügung stand.
Die meisten Informationen werden bei LP in den operativen Systemen tagesaktuell vorgehal-
ten, jedoch ist das nicht bei allen der Fall. Aus unterschiedlichsten Gründen werden einige
Daten nur wöchentlich oder monatlich in die operativen Systeme geladen, wie z.B. die Daten
einiger Partner oder Dienstleister, die nur wöchentlich bzw. monatlich an LP übergeben
werden. Daher ist durch die Geschäftsregeln definiert, das alle Daten in den operativen Sys-
temen, die bis zum Start der Ladeprozesse vorhanden sind, zu Beginn des folgenden Ge-
schäftstags in das DWH geladen sein müssen. Wenn diese Ladeprozesse fehlschlagen oder
falls sie deaktiviert werden, genügt der Datenbestand des DWH nicht den Aktualitätsanfor-
derungen.
Aktualität: Die Anforderung an die Aktualität für diese Arbeit ist,
dass alle zugreifbaren bzw. geänderten Daten in den operativen
Systemen, die bis zum Zeitpunkt des Starts des letzten durch die
Geschäftsregeln definierten Ladeprozesses dort vorhanden sind
bzw. geändert wurden, auch im DWH vorhanden und geändert sein
sollen.
22 Unter der Berücksichtigung der vorgenommenen Transformationen.
Definition der Datenqualitätsmerkmale 54
In diesem Zusammenhang muss auch erwähnt werden, dass die durch die Geschäftsregeln
definierten Anforderungen an die Aktualität in einigen Fällen bewusst verletzt werden. Das
ist bspw. der Fall, wenn die für jeden Abend23 eingeplanten Ladeprozesse deaktiviert wer-
den, die das DWH mit den neuen und aktualisierten Daten der operativen Systeme befüllt.
Das geschieht, wenn andere Prozesse mit einer höheren Priorität anstehen, die sämtliche
Ressourcen des Systems bzw. der Systeme beanspruchen, um innerhalb eines vorgegebenen
Zeitraums zu terminieren. Beispiele für solche Prozesse sind Aggregationen für die Berech-
nung von Punkteständen oder für Kundensegmentierungen. Sie benötigen einen hohen Anteil
der zur Verfügung stehenden Ressourcen, haben eine Laufzeit von ca. zwei Tagen und er-
lauben keine weiteren intensiven Aggregations- oder Befüllungsprozesse. In Kapitel 7.4 wird
darauf näher eingegangen.
6.4 Historisierung
In einem DWH werden Daten der operativen Systeme historisiert vorgehalten (siehe Kapitel
3.2.1). Dafür ist eine überschneidungsfreie und lückenlose Speicherung der Daten notwen-
dig. Um das zu realisieren, führt bei LP jede Änderung an einem Datensatz im Quellsystem
zur Erzeugung eines neuen Datensatzes im PAYBACK-DWH24. Solch ein neu erzeugter
Datensatz im DWH entspricht dem aktuellen Datensatz im operativen System25.
Es muss erwähnt werden, dass eine mehrfache Veränderung eines Datensatzes in einem ope-
rativen System zwischen zwei aufeinander folgenden Befüllungsprozessen evtl. nur als eine
Veränderung erkannt wird und deshalb auch nur das Resultat der letzen Veränderung in das
DWH geladen werden kann. Wie in Kapitel 3.2.1 erwähnt, wird das PAYBACK-DWH ein-
mal täglich am Ende eines Geschäftstages befüllt. Bei einer mehrfachen Veränderung eines
Datensatzes im operativen System innerhalb eines Geschäftstages kann nur das Ergebnis der
letzten Veränderung in das DWH übernommen werden.
23 „Jeden Abend“ ist hier nur ein Beispiel. Durch die Geschäftsregeln kann ein Unternehmen bzw. der Betreiber eines DWH beliebig festgelegen, in welchen Zeitabständen ein DWH befüllt werden soll.
24 In den operativen Systemen bei LP findet weitestgehend keine Historisierung statt. Bei einem Up-date auf dem operativen System werden existierende Attributwerte überschrieben.
25 Aktuell bezieht sich im Sinne dieser Arbeit auf den Zustand des operativen Systems zum Zeitpunkt des Starts des letzten Befüllungsprozesses.
Definition der Datenqualitätsmerkmale 55
Helfert [HE02a] bezeichnet das Merkmal der Historisierung als „Nicht-Volatilität“ und ver-
langt damit, dass „alle Datenwerte permanent sind und zu einem späteren Zeitpunkt wieder
aufgerufen werden können“. Um dies zu konkretisieren, wird das Merkmal der Historisie-
rung wie folgt definiert:
Historisierung: Das Merkmal der Historisierung gilt im Sinne die-
ser Arbeit als erfüllt, wenn Daten und Änderungen der operativen
Systeme lückenlos und überschneidungsfrei historisiert vorgehal-
ten sind, die Daten permanent gespeichert sind und zu einem späte-
ren Zeitpunkt abgerufen werden können.
Beim PAYBACK-DWH ist die Historisierung wie folgt gelöst: Zur Kennzeichnung des Gül-
tigkeitszeitraums eines Datensatzes stehen im DWH die zwei Attribute „ValidFrom“ und
„ValidTo“ zur Verfügung. Der aktuelle Datensatz hat dabei immer einen offenen Attribut-
wert „ValidTo“. Der Attributwert „ValidTo“ des ab diesem Zeitpunkt nicht mehr aktuellen
Datensatzes wird im Rahmen der Befüllung auf den Zeitpunkt des Updates des Datensatzes
im operativen System gesetzt. Durch die zwei Attribute „ValidFrom“ und „ValidTo“ ist es
möglich, alle Änderungen der Daten im Quellsystem lückenlos und überschneidungsfrei zu
historisieren. Zusätzlich existiert eine zweite Eigenschaft in den meisten Tabellen des
PAYBACK-DWH, um historisierte Daten zu kennzeichnen. Dabei handelt es sich um ein
Flag-Attribut, dessen Ausprägung „valid“ den aktuell gültigen Datensatz und die Ausprä-
gung „invalid“ alle nicht mehr aktuellen (historischen) Datensätze ein und des selben Daten-
satzes im operativen Systems kennzeichnet. Zu einem Datensatz im operativen System muss
im PAYBACK-DWH immer exakt ein einziger mit „valid“ gekennzeichneter Datensatz und
beliebig viele (oder auch keiner) mit „invalid“ gekennzeichneten Datensätze existieren.
6.5 Widerspruchsfreiheit
Helfert [He02a] definiert die Widerspruchsfreiheit folgendermaßen: „Die Daten weisen kei-
ne Widersprüche zu Integritätsbedingungen (Geschäftsregeln, Erfahrungswerte) und Werte-
bereichsdefinitionen auf (innerhalb des Datenbestands, zu anderen Datenbeständen, im Zeit-
verlauf)“. Widersprüche können bei einem DWH sowohl innerhalb des DWH, als auch zu
anderen Datenbeständen, den operativen Systemen auftreten. Im Rahmen dieser Arbeit gilt,
dass die Daten der operativen Systeme „der Wahrheit“ entsprechen und diese unter Berück-
sichtigung der durch die Geschäftsregeln definierten Transformationen (auch historisiert) im
PAYBACK-DWH vorgehalten werden sollen. Daher spielen die von Helfert beschriebenen
Definition der Datenqualitätsmerkmale 56
Integritätsbedingungen und Wertebereichsdefinitionen zu anderen Datenbeständen hier keine
Rolle. Die Widerspruchsfreiheit der Daten im DWH zu den Daten der operativen Systeme
wird in dieser Arbeit durch das Merkmal der Korrektheit abgedeckt, das in Kapitel 6.2 be-
schrieben ist.
Wie in Kapitel 3.2.1 erläutert, werden in einem DWH Daten oft bewusst redundant gespei-
chert. Das ist auch bei LP der Fall, wo alle redundanten Daten im PAYBACK-DWH gemäß
den Geschäftsregeln erzeugt werden. Daher wird dieses Merkmal wie folgt definiert:
Widerspruchsfreiheit: Im Sinne dieser Arbeit müssen zur Ge-
währleistung der Widerspruchsfreiheit die redundant gespeicherten
Daten im DWH in einem konsistenten26 Zustand vorgehalten sein.
Bei der Gewährleistung der überschneidungsfreien Historisierung ist es ebenfalls notwendig,
Widersprüche zu vermeiden. Zu einem Widerspruch würde bspw. führen, wenn in einer Re-
lation im DWH zwei oder mehr Datensätze für ein und denselben Zeitpunkt gültig sind. Dies
ist ein Widerspruch im Zusammenhang mit der Historisierung und wird in Kapitel 7.5.4 be-
handelt, da dort auf die Besonderheiten bei der Überprüfung der Historisierung eingegangen
wird. Findet außerdem, wie bei LP üblich, keine Historisierung in den operativen Systemen
statt und handelt es sich hierbei um Datensätze, die in einem Zeitraum in der Vergangenheit
gültig waren, lässt sich u.U. nicht mehr bestimmen, welcher dieser beiden Datensätze der
korrekte ist. Diese Problematik wird ebenfalls in Kapitel 7.5.4 näher betrachtet.
26 Zu Konsistenz siehe z.B. [KE06].
Messung von Datenqualität in einem Data Warehouse 57
7 Messung von Datenqualität in einem Data Warehouse
In den vorangegangenen Kapiteln wurden für diese Arbeit Datenqualitätsmerkmale identifi-
ziert und näher beschrieben. Es ist nicht möglich, eine aussagekräftige Messung von Daten-
qualität durchzuführen, ohne die relevanten Merkmale vorher klar zu definieren [Ma05].
Thema dieses Kapitels ist es, wie und unter welchen Umständen bei einem DWH Messgrö-
ßen für die erarbeiteten Merkmale ermittelt werden können. Dies wird möglichst allgemein
vollzogen, um das Ergebnis bei einem beliebigen DWH anwenden zu können. Es wird hier
nicht näher darauf eingegangen, wie die einzelnen SQL-Statements zu erstellen sind, um die
Daten zur Überprüfung der Qualität zu selektieren und abzugleichen, denn eine explizite
Erläuterung wäre zu spezifisch für das PAYBACK-DWH.
7.1 Ressourcen und Kosten
Wie in Kapitel 4.4.2 erwähnt, sind bei der Ermittlung der Datenqualität die entstehenden
Kosten zu berücksichtigen. Neben den Entwicklungskosten für die Messroutinen sind damit
in erster Linie Ressourcen des DWH und der operativen Systeme gemeint. Die Ressourcen
eines DWH und der operativen Systeme sind begrenzt. Eine Überprüfung der Datenqualität
kann deshalb nicht zu jedem beliebigen Zeitpunkt erfolgen, sondern es müssen die Ressour-
cen der beteiligten Systeme beachtet werden. Aus diesem Grund sind die Messungen ent-
sprechend der vorhandenen Prozesse und der Last auf den Systemen eingeplant. Sind keine
Ressourcen verfügbar, kann unter Umständen eine Qualitätsmessung nicht durchgeführt
werden. Durch Investitionen, bspw. in die Erweiterung der Hardware, könnten weitere Res-
sourcen geschaffen werden. Allerdings ist im Rahmen dieser Arbeit eine Vorgehensweise
zur Messung der Datenqualität zu entwickeln, die unter den gegebenen Vorraussetzungen
und somit unter der zur Verfügung stehenden Auslastung der Systeme, durchgeführt werden
kann. Deswegen werden in dieser Arbeit die benötigten Ressourcen als Kosten angesehen,
die bei der Einplanung und Durchführung von Datenqualitätsmessungen zu berücksichtigen
sind.
7.2 Vorgehensweise zur Messung
Vor dem Start einer Datenqualitätsprüfung zur Ermittlung einer oder mehrerer Messgrößen,
muss überprüft werden, ob der Datenbestand im DWH auch dem durch die Geschäftsregeln
definierten Stand entspricht. Dazu muss sichergestellt sein, dass die zum maßgeblichen Zeit-
punkt durch die Geschäftsregeln definierten Ladeprozesse beendet und fehlerfrei abgeschlos-
Messung von Datenqualität in einem Data Warehouse 58
sen worden sind. Sollten die Ladeprozesse noch nicht beendet sein und wird der Datenbe-
stand im DWH zum momentanen Zeitpunkt noch mit Daten aus den operativen Systemen
befüllt, ist das DWH noch nicht auf dem als aktuell definierten Stand, der für Datenquali-
tätsprüfungen notwendig ist. Eine Überprüfung der Datenqualität während der Befüllung
durch die ETL-Prozesse könnte evtl. Datensätze der operativen Systeme identifizieren, die
im DWH fehlen, die aber erst noch im Verlauf des aktuellen Befüllungsprozesses in das
DWH geladen werden.
Um eine Aussage über die Qualität eines Datenbestandes treffen zu können, ist es nach der
Überprüfung eines beliebigen Datenqualitätsmerkmals notwendig zu wissen, wie viele Daten
bzw. Datensätze fehlerhaft sind und wie viele Datensätze dazu untersucht wurden. Denn mit
diesen zwei Messgrößen und dem Wissen über das vorliegende Qualitätsproblem lässt sich
in einem weiteren Schritt eine Aussage über den Zustand des Datenbestandes treffen. Ange-
nommen es werden 1000 von 5000 existierenden Datensätzen als fehlerhaft identifiziert,
wäre ein ernsthaftes Datenqualitätsproblem vorhanden. Sind aber 1000 Datensätze von 100
Mio. fehlerhaft, wäre das Qualitätsdefizit weitaus geringer einzuschätzen. Daher ist es not-
wendig, die Anzahl der insgesamt überprüften Datensätze zu ermitteln. Auf die Bewertung
der Messergebnisse wird in Kapitel 8 näher eingegangen.
Es ist auch sinnvoll, die fehlerhaften Datensätze oder auch nur deren Primärschlüssel für
eine eindeutige Identifikation zu selektieren und in Form einer Kopie in einer separaten Ta-
belle zu speichern. Damit sind sie für weitere Schritte wie z.B. Untersuchungen der Ursa-
chen oder etwaige spätere Korrekturen dieser Datensätze bereits identifiziert und müssten
nicht erneut ermittelt werden27.
Bei der Ermittlung der Datenqualität im PAYBACK-DWH kann zwischen zwei Verfahren
zur Messung unterschieden werden. Diese werden im Folgenden beschrieben.
7.2.1 Überprüfung der Datenqualität innerhalb des DWH
Der Messvorgang zur Ermittlung der Datenqualität findet ausschließlich innerhalb des DWH
statt. Dabei werden nur Dimensions- bzw. Faktentabellen des DWH bei der Überprüfung der
Datenqualität herangezogen. Die operativen Systeme spielen bei dieser Art der Überprüfung
27 Mögliche Ursachen oder Korrekturmöglichkeiten von fehlerhaften Daten werden in dieser Arbeit nicht näher behandelt.
Messung von Datenqualität in einem Data Warehouse 59
keine Rolle und daher müssen für die Einplanung von Datenqualitätsprüfungen nur die Ka-
pazitäten des DWH beachtet werden. Ein Beispiel für die Messung von Datenqualität inner-
halb des DWH ist die Überprüfung der Widerspruchsfreiheit.
7.2.2 Systemübergreifende Überprüfung der Datenqualität
Bei einer systemübergreifenden Überprüfung wird der Datenbestand im DWH mit Referenz-
daten abgeglichen, um Mängel der Datenqualität zu ermitteln. Diese Referenzdaten sind bei
einem DWH die operativen Systeme, aus denen es durch die ETL-Prozesse befüllt wird und
für die im Rahmen dieser Arbeit angenommen wird, dass sie „der Wahrheit“ entsprechen.
Damit diese als Referenzdaten herangezogen werden können ist es unbedingt notwendig,
dass die benötigten Zugriffsrechte auf alle involvierten operativen Systeme eingeräumt wer-
den. Diese Form der Überprüfung ist weitaus komplexer als die Messung der Datenqualität
innerhalb des DWH, da neben der Kapazität des DWH auch die Kapazitäten des bzw. der
betroffenen operativen Systeme beachtet werden müssen. Je mehr operative Systeme für eine
Datenqualitätsprüfung herangezogen werden müssen, um so schwieriger wird es, Zeiträume
zu identifizieren, in denen alle operativen Systeme und das DWH freie Kapazitäten haben.
Wie auch bei LP gilt oft die Vorgabe, dass die Belastung der operativen Systeme durch Ab-
fragen bzw. Auswertungen auf ein Minimum reduziert werden soll. Neben dem Optimieren
von SQL-Statements zur Performanzsteigerung, auf die hier nicht näher eingegangen wird28,
stehen weitere Möglichkeiten zur Verfügung, um die Belastung der operativen Systeme zu
reduzieren. Die für die Qualitätsprüfung notwendigen Daten der operativen System könnten
z.B. vor dem eigentlichen Abgleich in eine bzw. mehrere temporäre Tabellen des DWH ge-
laden werden. Für den Abgleich nicht benötigte Attribute der betroffenen Datensätze müssen
dabei nicht in der temporären Tabellen gespeichert werden29. Die Erfahrung bei LP hat ge-
zeigt, dass ein „1:1“-Ladevorgang schneller ist als ein Abgleich derselben Menge von Daten
mit Referenzdaten. Dadurch wird die Zugriffszeit auf die operativen Systeme verringert, da
der eigentliche Abgleich dann nur auf dem DWH stattfindet und keine weiteren Systeme
belastet. Dies bietet sich allerdings bei sehr großen Datenmengen nicht an, da es evtl. zu
Kapazitäts- und Performanzproblemen führen könnte. Da nach dem Kopieren der Daten der
28 Näheres zur Optimierung von SQL-Statements bei Oracle-Datenbanken ist in [Ni99] zu finden.
29 In die temporären Tabellen müssen mindestens alle diejenigen Attribute übernommen werden, die entweder überprüft werden oder die zur eindeutigen Identifizierung der Datensätze notwendig sind.
Messung von Datenqualität in einem Data Warehouse 60
eigentliche Abgleich in diesem Falle dann nur auf dem DWH stattfindet, kann es als eine
Überprüfung der Datenqualität innerhalb des DWH angesehen werden, die im vorherigen
Abschnitt erwähnt wurde. Dabei ist zu beachten, dass das Kopieren von Daten in ein anderes
System immer eine potentielle Fehlerquelle darstellt und zu falschen Messergebnissen füh-
ren kann.
Ein Problem bei einer systemübergreifenden Überprüfung ist, dass sich der Datenbestand in
den operativen Systemen im Zeitraum zwischen dem letzten Befüllungsprozess und dem
Start der Überprüfung der Datenqualität geändert haben könnte. Es empfiehlt sich daher, im
direkten Anschluss an die Befüllungsprozesse die Datenqualität zu kontrollieren. Gänzlich
ausschließen lässt sich dadurch allerdings nicht, dass Veränderungen in dem, wenn auch nur
sehr kleinen, Zeitraum zwischen diesen beiden Prozessen stattgefunden haben. Eine andere
und auch sicherere Möglichkeit ist es, neu eingefügte oder geänderte Daten der operativen
Systeme entsprechend einzuschränken, so dass diejenigen Daten bei einem Datenqualitäts-
abgleich ausgeschlossen werden, die nach dem letzten Befüllungsprozess in die operativen
Systeme eingefügt oder dort geändert wurden. Bei LP stehen zur Identifizierung dieser Da-
tensätze die Attribute „Inserteddate“ und „Updateddate“ in den operativen Systemen zur
Verfügung. Während sich dadurch alle neu eingefügten Daten ausschließen lassen, ist es bei
geänderten Daten allerdings immer noch möglich, dass ein Datensatz bei einer Überprüfung
der Datenqualität aus einem operativen System nicht herangezogen wird, der aber beim letz-
ten Befüllungsprozess in das DWH geladen wurde. Hierzu ein Beispiel: Wurde ein Datensatz
im operativen System nach dem letzten und vor dem Start eines erneuten Befüllungsprozes-
ses geändert, wird dieser Datensatz als geändert erkannt und die Veränderung im DWH
nachvollzogen bzw. historisiert gespeichert. Angenommen die Befüllung startete um 21:00
Uhr und eine Datenqualitätsprüfung findet sofort nach Beendigung dieses Befüllungsprozes-
ses um 23:00 Uhr statt, wird genau dieser Datensatz nicht in die Überprüfung mit einbezo-
gen, falls er zwischen 21:00 und 23:00 Uhr erneut geändert wurde.
7.3 Variationen von Abgleichen
Es kann zwischen drei Arten von Datenabgleichen zur Messung der Datenqualität unter-
schieden werden. Das gilt sowohl bei Abgleichen innerhalb des DWH, als auch bei system-
übergreifenden Überprüfungen. Es wird entweder der gesamte Datenbestand, nur ein Teil
des Datenbestandes einer Überprüfung unterzogen, oder es werden nur neue und aktualisier-
te Datensätze der operativen Systeme überprüft. Unter der Bezeichnung Datenbestand ist
Messung von Datenqualität in einem Data Warehouse 61
hier und im Folgenden der Inhalt einer Dimensions- oder Faktentabelle im DWH zu verste-
hen.
7.3.1 Abgleich des gesamten Datenbestandes
Beim Abgleich des gesamten Datenbestandes wird der Inhalt einer ganzen Relation über-
prüft. Dies ist die aufwendigste Form eines Abgleichs der vorgenommen werden kann. Auf-
grund der sehr großen Datenbestände ist es häufig nicht möglich solche Abgleiche durchzu-
führen, da sie zu viele Ressourcen für sich beanspruchen. Dies ist vor allem dann der Fall,
wenn Prozesse mit höherer Priorität die Kapazitäten des DWH beanspruchen. Im Falle einer
systemübergreifenden Messung der Datenqualität, bei der zusätzlich die Ressourcen einer
oder mehrerer operativer Systeme berücksichtigt werden müssen, gestaltet es sich als
schwierig, Zeiträume zu identifizieren, in denen bei einer anstehenden Überprüfung in allen
betroffenen Systemen freie Kapazitäten vorhanden sind. Während es bei einem DWH oft
noch möglich ist, während der Geschäftszeit aufgrund freier Kapazitäten Überprüfungen
durchzuführen, ist ein Zugriff auf operative Systeme zu dieser Zeit oft nur in Ausnahmefäl-
len und dann auch nur für kurze Zeit möglich. Auf diese Problematik wird in Kapitel 7.4
noch näher eingegangen.
Die Überprüfung des gesamten Datenbestandes ist allerdings nicht immer möglich. Falls z.B.
ältere Daten im DWH oder auch in den operativen Systemen archiviert werden, stehen diese
evtl. nicht mehr für eine Überprüfung zur Verfügung.
7.3.2 Partieller Abgleich des Datenbestandes
Um eine Aussage über die Datenqualität eines sehr großen Datenbestandes treffen zu kön-
nen, der aufgrund von Ressourcenknappheit nicht durch einen einzigen Abgleich überprüft
werden kann, stehen zwei Möglichkeiten zur Auswahl. Falls es für die Überprüfung der Da-
tenqualität genügt, nur einen Teil der Daten zu überprüfen, um damit auf die Qualität des
gesamten Datenbestandes zu schließen, können geeignete Verfahren gewählt werden, um
den Datenbestand auf einen repräsentativen Teil der Daten zu beschränken. Zur Selektion
eines Teils der Daten können geeignete Auswahlverfahren gewählt werden, um mit dem
Ergebnis der Überprüfung dieser Daten auf den Zustand des gesamten Datenbestandes
schließen zu können. Auf die verschiedenen Möglichkeiten, wie repräsentative Daten aus-
gewählt werden können, wird in dieser Arbeit nicht näher eingegangen. Es ist hier evtl. auch
zu berücksichtigen, ob neuere Daten aufgrund von Beseitigungen von Fehlern im System
o.Ä. bereits in einem qualitativ besseren Zustand vorliegen als ältere Daten.
Messung von Datenqualität in einem Data Warehouse 62
Sollte es jedoch nicht ausreichen, nur einen Teil der Daten zu untersuchen, um damit auf den
Zustand des gesamten Datenbestandes zu schließen, sondern notwendig sein, die gesamten
Daten zu überprüfen, kann der Datenbestand für die Überprüfung der Datenqualität evtl. in
kleinere „Blöcke“ aufgeteilt werden, um sie nacheinander abzugleichen. Die Überprüfung
eines dieser „Blöcke“ beansprucht weniger Ressourcen, vor allem auch weniger Laufzeit, die
unter Berücksichtigung von anderen Prozessen leichter eingeplant werden kann. Falls ein
Attribut „Inserteddate“ mit dem Datum der Erzeugung eines Datensatzes vorhanden ist,
könnte der Datenbestand anhand dieses Datums unterteilt werden. So könnte man bspw.
zuerst alle Datensätze des Jahres 2004 überprüfen, danach die des Jahres 2005 und dann alle
des Jahres 2006.
Eine weitere Form des partiellen Abgleichs von Daten ist die regelmäßige Überprüfung der
ETL-Prozesse, durch die ein DWH befüllt wird. Beim PAYBACK-DWH werden sog. „inc-
remental loads“ durchgeführt. Das sind Befüllungsprozesse, welche die seit dem letzten La-
devorgang neu in die operativen Systeme eingefügten oder dort aktualisierten Daten in das
DWH laden. Dazu müssen die Relationen der operativen Systeme ein oder mehrere Attribute
enthalten, die diese Datensätze entsprechend kennzeichnen, um zu erkennen, dass sie neu
eingefügt oder modifiziert wurden. Das könnten, wie schon in Kapitel 7.2.2 erwähnt, die
zwei Attribute „Inserteddate“ und „Updateddate“ sein, in die das Datum des Einfügens bzw.
der Änderung eingetragen wird. Falls bei Datensätzen einer Relation eine (oder beide) dieser
Datumsangaben größer ist als das Datum des Starts des letzen Ladevorgangs, wurden die
betroffenen Datensätze erst nach dem letzen Ladevorgang im operativen System eingefügt
oder modifiziert. Anhand dessen können die betroffenen Datensätze identifiziert und beim
nächsten Ladevorgang in das DWH geladen werden.
Falls diese zwei Attributwerte in den operativen Systemen, bspw. bei manuellen Operatio-
nen30, mit dem falschen oder keinem Datum versehen werden, kann es vorkommen, dass die
betroffenen Datensätze beim Ladevorgang nicht als neu oder modifiziert identifiziert und
somit auch nicht in das DWH geladen werden. Daher kann der Datenbestand schon direkt
nach dem Befüllungsvorgang nicht vollständig sein. Es ist möglich, dass auch regelmäßige
Datenqualitätsabgleiche zur Überprüfung der Befüllungsprozesse diese Daten aufgrund des
falschen Eintrags im Datumsfeld ebenfalls nicht identifizieren können. Deshalb ist es not-
30 Manuell im Sinne von direktem Zugriff (Änderung bzw. Einfügen) auf die Datenbank.
Messung von Datenqualität in einem Data Warehouse 63
wendig, nicht nur regelmäßig die ETL-Prozesse zu überprüfen, sondern es sollte in größeren
Zeitabständen der gesamte Datenbestand kontrolliert werden.
7.4 Einplanen von Datenqualitätsmessungen
Auf dem Data Warehouse bei LP werden unternehmensweit Auswertungen während der
Arbeitszeit und darüber hinaus durchgeführt. Zusammengenommen produzieren all diese
Auswertungen und Aggregationen eine große Last auf dem System. Um zu gewährleisten,
dass diese Prozesse ohne lange Wartezeiten ablaufen, darf die Performanz des Systems nicht
über ein gewisses Maß zusätzlich belastet werden. Daher können Auswertungen bzw. Ab-
gleiche auf dem DWH nicht zu jedem beliebigen Zeitpunkt und in beliebigem Umfang
durchgeführt werden. Fast jeden Abend werden bspw. die ETL-Prozesse in Gang gesetzt, die
das PAYBACK-DWH mit den aktuellsten Daten aus den operativen Systemen befüllen. Wie
bereits in Kapitel 7.2 erwähnt ist darauf zu achten, dass Datenabgleiche während der Befül-
lungsprozesse nicht stattfinden dürfen. Neben den Befüllungsprozessen existiert noch eine
Vielzahl anderer Prozesse, denen eine hohe Priorität eingeräumt wird. Ein Beispiel dafür
sind die bereits in Kapitel 6.3 erwähnten Aggregationen für die Berechnung von Punktestän-
den oder zu Kundensegmentierungszwecken.
Auch bei der Einplanung der Datenqualitätsmessungen muss unterschieden werden, ob die
Überprüfung der Datenqualität innerhalb des DWH oder systemübergreifend stattfinden soll.
Welche Art der Überprüfung vorgenommen werden muss, hängt vom jeweiligen Datenquali-
tätsmerkmal und vom Zweck der Messung ab. In Kapitel 7.5 wird darauf näher eingegangen.
Bei der systemübergreifenden Messung der Datenqualität, bei der Datenbestände zwi-
schen einem oder mehreren Quellsystemen und dem DWH abgeglichen werden müssen,
können unter Umständen nur sehr wenige und sehr kleine Zeitfenster zur Verfügung stehen,
in denen ein Abgleich überhaupt möglich ist. Es ist daher für die Einplanung von Abgleichen
notwendig, schon vorher die Laufzeiten entweder abzuschätzen, zu berechnen oder anhand
von Erfahrungswerten zu bestimmen. Der riesige Datenbestand in einem DWH kann zu e-
normen Laufzeiten führen, welche die Größe der freien Zeitfenster bei weitem übersteigen
können. Das gilt es unbedingt zu vermeiden, denn es könnte die Systeme selbst oder auch
höher priorisierte Prozesse auf den Systemen nachhaltig zu stark beeinflussen. In Kapitel 7.2
und 7.3 wurde bereits darauf eingegangen, auf welche Weise Laufzeiten beeinflusst bzw.
verkürzt werden können.
Messung von Datenqualität in einem Data Warehouse 64
Falls eine Relation im DWH nur mit Daten aus einer einzigen Relation eines operativen Sys-
tems befüllt wird, kann die Messung der Datenqualität durch einen direkten Abgleich dieser
beiden Tabellen überprüft werden. Dann sind freie Ressourcen und gemeinsame Zeitfenster
von zwei Systemen (DWH und ein operatives System) zu beachten. Das ist auch der Fall,
wenn mehrere Relationen eines operativen Systems die Quelle einer Relation im DWH sind.
Dort müssen dann zwar mehrere Tabellen abgeglichen werden, aber es sind nur zwei Syste-
me am Abgleich beteiligt, bei denen gleichzeitig freie Ressourcen identifiziert werden müs-
sen.
Stammen die Quelldaten für die Attribute jedoch aus mehreren operativen Systemen, müssen
die Ressourcen und die gemeinsamen freien Zeitfenster all dieser Quellsysteme berücksich-
tig werden, aus denen Daten gemäß den Geschäftsregeln in das DWH geladen werden. Es ist
durchaus möglich, dass es sich als sehr schwierig gestaltet, freie Ressourcen aller beteiligten
Systeme zu einem Zeitpunkt zu identifizieren. Evtl. ist es gar nicht möglich, alle diese Attri-
bute durch einen einzigen Abgleich zu überprüfen, weil die beteiligten operativen Systeme
nicht gemeinsam zur Verfügung stehen. Es muss daher auch in Betracht gezogen werden,
dass eine Messung der Datenqualität zu umfangreich ist und evtl. in mehrere „kleinere“
Messungen aufgeteilt werden muss, bei denen bspw. nur ein oder ein Teil der Attribute ü-
berprüft wird, die nur aus einem oder wenigen operativen Systemen stammen.
Bei einer Messung der Datenqualität innerhalb des DWH hingegen, bei der keine Daten
weiterer Systeme betrachtet werden, müssen nur die freien Ressourcen des DWH betrachtet
werden.
7.5 Besonderheiten bei der Messung der einzelnen Datenqualitäts-
merkmale
Nachdem in Kapitel 6 alle Merkmale, die im Rahmen dieser Arbeit betrachtet werden, näher
beschrieben wurden, wird in diesem Kapitel nun erläutert, wie diese Merkmale bei einem
DWH gemessen werden können.
7.5.1 Messung der Vollständigkeit
Wie in Kapitel 6.1 erläutert, sind für diese Arbeit die Wert- und Tupel-Relation-
Vollständigkeit von Bedeutung. Die Wert-Vollständigkeit kann sowohl innerhalb eines
DWH überprüft werden als auch systemübergreifend. Sollte Bedarf bestehen, im DWH Da-
tensätze mit bestimmten fehlenden Attributwerten zu identifizieren, unabhängig davon, wel-
Messung von Datenqualität in einem Data Warehouse 65
che Werte in den Quellsystemen vorhanden sind, kann die Wert-Vollständigkeit innerhalb
des DWH überprüft werden. Durch eine Überprüfung der relevanten Attribute auf Null-
Werte lassen sich die betroffenen Datensätze identifizieren. Beim PAYBACK-DWH besteht
jedoch kein Bedarf, diese Form der Vollständigkeiten innerhalb des DWH zu untersuchen.
Denn wie bereits in Kapitel 6.1 erwähnt, gilt beim PAYBACK-DWH die Vorgabe, dass die
Daten vorgehalten werden sollen, die in den operativen Systemen vorhanden sind und laut
den Geschäftsregeln in das PAYBACK-DWH zu laden sind. Daher muss die Wert-
Vollständigkeit systemübergreifend überprüft werden. Diese Form der Vollständigkeit gilt
als erfüllt, wenn all diejenigen Attribute im DWH vorhanden sind, die auch in den durch die
Geschäftsregeln festgelegten Quellsystemen vorhanden sind bzw. genau diejenigen im DWH
fehlen, die auch in den Quellsystemen nicht vorhanden sind.
Für die Überprüfung der Tupel-Relation-Vollständigkeit ist eine systemübergreifende Mes-
sung erforderlich. Denn es wird eine Referenz benötigt, um beurteilen zu können, ob ein
gesamtes Tupel fehlt oder nicht. Durch einen Vergleich einer Relation im DWH mit dem
bzw. den als Quelle dienenden operativen Systemen können die Tupel identifiziert werden,
die in den Quellsystemen vorhanden sind, aber im DWH fehlen.
Falls in einigen oder mehreren Relationen alle Attribute als Pflichtfelder deklariert und daher
auch keine Null-Werte zugelassen sind, erfüllt eine Relation auf jeden Fall alle in Kapitel 6.1
definierten Typen der Vollständigkeit, außer der Tupel-Relation-Vollständigkeit. Somit kann
in einem solchen Fall nur die Tupel-Relation-Vollständigkeit verletzt sein und es reicht aus,
diese Form der Vollständigkeit zu überprüfen.
Für die Datenqualitätsprüfungen muss auch der Fall in Betracht gezogen werden, dass Daten
in einem DWH vorhanden sind, die in den operativen Systemen „fehlen“, es also „übervoll-
ständig“ ist. Ein solches „Fehlen“ wäre z.B. dadurch zu erklären, dass durch manuelles Lö-
schen Daten auf den operativen Systemen entfernt werden und dieser Löschvorgang im
DWH31 nicht nachvollzogen wird. Ein Grund, warum ein Löschvorgang im DWH nicht
nachvollzogen wird, wäre mangelnde Kommunikation innerhalb eines Unternehmens. Ein
anderer wäre, wenn eine mögliche Geschäftsregel verletzt wird, die vorschreibt, dass in ope-
rativen Systemen keine Daten gelöscht werden dürfen. Da der Datenbestand im PAYBACK-
31 Ein Löschvorgang im DWH würde die Vorgabe der Historisierung von Daten verletzen (siehe Kapi-tel 2.2). Wie mit solchen Löschvorgängen auf operativen Systemen im DWH umgegangen wird, muss durch die Geschäftsregeln eines Unternehmens festgelegt werden.
Messung von Datenqualität in einem Data Warehouse 66
DWH mit seinen durch die Geschäftsregeln definierten Quellen in den operativen Systemen
übereinstimmen soll, ist es notwendig, betroffene Datensätze zu identifizieren, damit sie für
etwaige Anpassungen korrigiert werden können. Sie lassen sich durch eine systemübergrei-
fende Überprüfung der Datenqualität ermitteln und zwar auf ähnliche Weise wie oben be-
schrieben, allerdings muss in diesem Fall „umgekehrt“ vorgegangen werden. Man sucht also
nach Attributwerten bzw. Tupeln, die im DWH vorhanden sind und in den operativen Sys-
temen fehlen.
7.5.2 Messung der Korrektheit
Zur Bestimmung der Korrektheit der im DWH vorgehaltenen Daten ist in erster Linie eine
systemübergreifende Überprüfung notwendig. Wie in Kapitel 6.2 erwähnt, gilt ein Datensatz
als korrekt, wenn all seine Attributwerte exakt mit den Daten befüllt sind, die in den Quell-
systemen vorgehalten sind und unter Beachtung der Transformationen bei der Befüllung in
das DWH geladen worden sind. Für die Korrektheitsprüfung muss bi den Attributwerten der
Tupel einer Relation überprüft werden, ob sie mit den Daten des bzw. der Attributwerte der
Quellsysteme übereinstimmen, und das unter Beachtung der vorgenommenen Transformati-
onen bei der Befüllung des DWH.
Im Rahmen einer Überprüfung der Korrektheit müssen auch die bei der Befüllung des DWH
vorgenommenen, z.T. sehr komplexen Berechnungen bzw. Aggregationen erneut vorge-
nommen werden, um die Daten im DWH auf ihre Korrektheit zu überprüfen. Diese Berech-
nungen können aufgrund ihrer Komplexität viele Ressourcen beanspruchen und auch zu
hohen Laufzeiten führen. Evtl. ist es gar nicht möglich, alle Attributwerte durch einen einzi-
gen Abgleich zu überprüfen, weil dies zu viele Ressourcen beansprucht oder weil die betei-
ligten operativen Systeme nicht alle zur selben Zeit zur Verfügung stehen.
Da in den operativen Systemen weitestgehend keine Historisierung der Daten vorgenommen
wird, kann in den meisten Fällen nur die Korrektheit der als aktuell gültig markierten Daten
im DWH überprüft werden. Wenn keine historisierten Daten in den operativen Systemen
vorgehalten werden, existieren damit auch keine Referenzdaten, mit denen historisierte Da-
ten im DWH abgeglichen und auf ihre Korrektheit überprüft werden können. Neben einer
lückenlosen und überschneidungsfreien Historisierung ist es notwendig, auch die Korrektheit
historisiert gespeicherter Daten zu gewährleisten. Dazu sollte in direktem Anschluss an jeden
Befüllungsprozess eine kontinuierliche Korrektheitsprüfung durchgeführt werden. Dadurch
lassen sich zwar bereits historisiert gespeicherte Daten im DWH nicht überprüfen, aber ab
dem Zeitpunkt des Starts einer kontinuierlichen Korrektheitsprüfung im Anschluss an jeden
Messung von Datenqualität in einem Data Warehouse 67
Befüllungsprozess kann die Korrektheit eines jeden Datensatzes überprüft werden, der ab
diesem Zeitpunkt in das DWH geladen wird.
Auch wenn nach jedem Ladevorgang eine Überprüfung der Korrektheit durchgeführt wird,
ist es dennoch möglich, dass im Zeitraum zwischen dem Start der Befüllung und dem Ende
der Korrektheitsprüfung ein Datensatz im operativen System bereits wieder geändert wird
und damit nicht mit dem entsprechenden Datensatz im DWH übereinstimmt. Sollte dieser
Umstand eintreten, würde der von einer Überprüfung der Korrektheit betroffene Datensatz
irrtümlich als fehlerhaft im DWH identifiziert werden. In diesem Fall liegt aber keine Ver-
letzung der Korrektheit vor, weil eine derartige Veränderung eines Datensatzes einer „kor-
rekten“ Aktualisierung im operativen System entspricht, die durch den folgenden Befül-
lungsprozess zu einer historisierten Speicherung dieser Änderung im DWH führen würde.
7.5.3 Messung der Aktualität
Wie in Kapitel 6.3 erläutert, ist bei LP durch die Geschäftsregeln definiert, dass das DWH
genau dann das Aktualitätskriterium erfüllt, wenn alle zu Beginn des Befüllungsprozesses
am Vorabend zugreifbaren und geänderten Daten in den operativen Systemen auch im DWH
vorhanden sind bzw. die Änderungen historisiert wurden.
Sollte der Letzte durch die Geschäftsregeln definierte Befüllungsprozess nicht stattgefunden
haben oder durch einen Fehler abgebrochen worden sein, wäre damit das Aktualitätskriteri-
um bereits verletzt. Eine Überprüfung der Aktualität ist in diesem Fall nicht notwendig, denn
der DWH-Datenbestand ist dadurch bereits nicht auf dem definierten aktuellsten Stand.
Auch falls die Befüllung durch Performanzprobleme oder aus anderen Gründen weitaus län-
ger dauert und nicht im vorgegeben Zeitrahmen beendet wird, ist das Aktualitätskriterium
verletzt.
Da im Datenmodell des DWH keine Informationen über die Aktualität vorhanden sind, kön-
nen zur Überprüfung der Aktualität nur die Metainformationen der ETL-Prozesse betrachtet
werden. Diese enthalten Informationen über die Dauer und den Zeitpunkt der Befüllungspro-
zesse, darüber, ob sie noch laufen oder ob sie fehlerfrei beendet wurden. Falls während der
Befüllungsprozesse Fehler auftreten, geben die Metainformationen evtl. auch Aufschluss
über die Ursachen. Kann aufgrund dieser Daten festgestellt werden, dass alle notwendigen
Befüllungsprozesse stattgefunden haben und diese fehlerfrei verlaufen und beendet worden
sind, erfüllt der Datenbestand im DWH im Sinne dieser Arbeit das Kriterium der Aktualität.
Durch die Geschäftsregeln muss auch festgelegt werden, ob eine Verletzung der Aktualität
Messung von Datenqualität in einem Data Warehouse 68
vorliegt, falls, wie schon in Kapitel 6.3 erwähnt, Prozesse mit höherer Priorität eine Deakti-
vierung der Ladeprozesse erfordert haben.
Je nach Auslegung kann auch der in Kapitel 6.4 erwähnte, durch ein Flag-Attribut markierte
„aktuelle Datensatz“ dem Merkmal der Aktualität zugeordnet werden. In dieser Arbeit wird
dies jedoch als Bestandteil der Historisierung gesehen und im Rahmen der Historisierung im
nächsten Kapitel behandelt.
7.5.4 Messung der Historisierung
Die Historisierung der im DWH vorgehaltenen Daten kann durch eine Überprüfung der Da-
tenqualität innerhalb des DWH gemessen werden. Operative Systeme müssen dafür nicht
herangezogen werden. Wie schon in Kapitel 6.4 erwähnt, stehen bei den Relationen im
PAYBACK-DWH die beiden Merkmale „ValidFrom“ und „ValidTo“ zur Verfügung, um
den Gültigkeitszeitraum eines Datensatzes zu kennzeichnen. Anhand dieser Attribute können
alle zu einem Datensatz im operativen System32 gehörenden historisierten Daten33 dahinge-
hend überprüft werden, ob die Historisierung lückenlos und überschneidungsfrei ist. In
Tabelle 7.1 ist die Historisierung von Punkteständen eines Kontos beispielhaft dargestellt.
Während alle drei Datensätze des Kontos 123 lückenlos und überschneidungsfrei gespeichert
sind und daher das Kriterium der Historisierung erfüllen, weist u.a. die Historisierung der
Daten zum Konto 456 mehrere Fehler auf. Eine Verletzung der Lückenfreiheit liegt vor, weil
kein Punktestand für den 20.05.2006 existiert. Der Datensatz mit der ID 3 ist nur bis zum
19.05.2006 gültig und der Datensatz mit der ID 4 gilt erst ab dem 21.05.2006. Eine Über-
schneidung der Gültigkeit liegt bei den Datensätzen mit den IDs 2 und 3 vor, denn am 24.
und 25.05.2006 gelten laut Tabelleneintrag beide Datensätze.
32 Um den Sachverhalt besser erläutern zu können wird angenommen, dass ein DWH-Datensatz aus einem Datensatz eines operativen Systems besteht.
33 Auch wenn im DWH nur ein einziger (gültiger) Datensatz zu einem Datensatz im operativen Sys-tem vorhanden ist und keine weiteren historisierten vorhanden sind, werden die Daten des gültigen Datensatzes hier als historisierte Daten bezeichnet.
Messung von Datenqualität in einem Data Warehouse 69
ID Konto Punkte ValidFrom ValidTo ValidFlag 8 223 598 26.05.2006 0 7 123 7591 23.05.2006 1 6 123 6852 12.04.2006 22.05.2006 0 5 123 5228 02.03.2006 11.04.2006 0 4 456 8685 21.05.2006 1 3 456 6589 24.03.2006 19.05.2006 0 2 456 5265 02.03.2006 25.03.2006 0 1 456 5265 08.02.2006 01.03.2006 1
Tabelle 7.1: Beispieltabelle zur Historisierung (eigene Darstellung)
Wie bereits in Kapitel 6.4 erwähnt, existiert im PAYBACK-DWH ein Flag-Attribut zur
Kennzeichnung des aktuell gültigen Datensatzes. Unter der Annahme, dass die bereits er-
wähnten Attribute „ValidFrom“ und „ValidTo“ lückenlos und überschneidungsfrei sind,
kann das Flag-Attribut überprüft werden34. Im Beispiel in Tabelle 7.1 liegt es als Attribut
„ValidFlag“ vor, dessen Ausprägungen „1“ einen gültigen und „0“ einen ungültigen Daten-
satz kennzeichnen. Beim Konto 456 sind durch das „ValidFlag“ die beiden Datensätze mit
der ID 1 und 4 als gültig gekennzeichnet. Daher liegt hier eine Verletzung der Vorgabe vor,
dass immer nur ein Datensatz als gültig gekennzeichnet sein darf. Wie erwähnt kann hier
anhand der zwei Attribute „ValidFrom“ und „ValidTo“ der Datensatz mit der ID 1 identifi-
ziert werden, der fälschlicherweise als gültig gekennzeichnet ist. Zum Konto 223 existiert
nur der Datensatz mit der ID 8, der als ungültig gekennzeichnet ist. Dieser verletzt die Vor-
gabe, dass immer ein Datensatz als gültig gekennzeichnet sein muss.
7.5.5 Messung der Widerspruchsfreiheit
Die Überprüfung dieses Merkmals kann durch eine Messung der Datenqualität innerhalb des
DWH durchgeführt werden, um redundant gespeicherte Daten auf Widersprüche zu untersu-
chen. Daher müssen nur die Ressourcen des DWH berücksichtigt werden und operative Sys-
teme spielen bei der Einplanung einer Überprüfung der Widerspruchsfreiheit keine Rolle.
Bei Widersprüchen von redundant gespeicherten Daten kann es evtl. problematisch sein, den
"richtigen" Wert für weitere Schritte wie z.B. Korrekturmaßnahmen zu identifizieren. Wenn
34 Man könnte die Verifizierung dieses Flags auch unter dem Merkmal der Korrektheit einordnen. Da es jedoch in Zusammenhang mit der Historisierung von Daten steht, wird es in dieser Arbeit unter dem Historisierungsmerkmal geführt.
Messung von Datenqualität in einem Data Warehouse 70
nur eine Aussage darüber getroffen werden kann, wie viele Daten sich widersprechen bzw.
welche sich widersprechen, ist noch nicht bekannt, welche evtl. korrigiert werden müssen
bzw. es kann bei weitergehenden Maßnahmen die Suche nach der Ursache erschweren.
Auch wenn Aggregationen, wie in Kapitel 1.1 erwähnt, in dieser Arbeit nicht näher behan-
delt werden, bleibt zu erwähnen, dass Widersprüche aggregierter Daten innerhalb des DWH
ebenfalls durch dieses Merkmal überprüft werden können. Falls redundante Daten nicht
schon durch die Befüllung des DWH erzeugt werden, sondern durch Aggregationen, die
ausschließlich auf Basis von bereits im DWH befindlichen Daten berechnet und gespeichert
werden, besteht die Möglichkeit, zuerst durch einen systemübergreifenden Abgleich die
Korrektheit der ins DWH geladenen Daten zu überprüfen. Denn sind die im DWH befindli-
chen Daten, die den Aggregationen zu Grunde liegen, korrekt, können sie als Referenzdaten
verwendet werden, um Widersprüche zu bzw. zwischen aggregierten Daten im DWH zu
überprüfen.
7.6 Grenzen der Messung
In diesem Kapitel wurden Möglichkeiten aufgezeigt, wie zur Durchführung von Messungen
der Datenqualität Messvorgänge eingeplant und durchgeführt werden können. Es wurde
erläutert, wie man die aufgrund des sehr großen Datenbestandes entstehenden teilweise e-
normen Laufzeiten verkürzen kann, um auch sehr umfangreiche Messungen durchführen zu
können. Trotz all dieser Versuche ist es durchaus möglich, dass eine Überprüfung der Da-
tenqualität in einigen Fällen nicht möglich ist. Das wäre bspw. der Fall, wenn für eine Mes-
sung unbedingt benötigte Systeme nie zur selben Zeit zur Verfügung stehen oder auch wenn
der Zugriff auf ein oder mehrere Systeme nicht erlaubt oder möglich ist.
Ein Data Warehouse, das unter Beachtung der vorgenommenen Transformationen bei den
Befüllungsprozessen genau die Daten enthalten soll, welche in den operativen Systemen
gespeichert sind (wie es beim PAYBACK-DWH der Fall ist), kann keinen qualitativ höheren
Datenbestand vorhalten, als in den Quellsystemen vorhanden ist. Wird das DWH also durch
Daten mangelnder Qualität befüllt, ist eine Messung der Datenqualität unter dem Gesichts-
punkt der zukünftigen Verbesserung der Datenqualität fraglich, auch wenn die Verbesserung
der Datenqualität nicht Bestandteil dieser Arbeit ist.
Darstellung und Bewertung der Messergebnisse 71
8 Darstellung und Bewertung der Messergebnisse
In den vorherigen Kapiteln wurden Merkmale für die Messung von Datenqualität identifi-
ziert und näher beschrieben. Es wurde untersucht, ob und wo die einzelnen Merkmale ge-
messen werden können und wie dabei vorzugehen ist. Abschließend wird erläutert, wie die
Ergebnisse von Messungen der Datenqualitätsmerkmale dargestellt werden können, damit
sie für eine Bewertung zur Verfügung stehen.
8.1 Darstellung der Messergebnisse
Wie in Kapitel 7.2 bereits erwähnt, ist es bei einer Datenqualitätsprüfung notwendig zu wis-
sen, wie viele Daten bzw. Datensätze fehlerhaft sind und wie viele Datensätze dazu unter-
sucht werden. Daraus lässt sich der Quotient bzw. der prozentuale Anteil der fehlerhaften
Daten berechnen, mit dessen Hilfe eine Aussage über den Anteil der fehlerhaften Daten im
Vergleich zum gesamten Datenbestand getroffen werden kann.
Bei LP sollen die Ergebnisse der regelmäßigen Datenqualitätsprüfungen in der BSC darge-
stellt werden. Um die Ergebnisse der Messungen und auch die Entwicklung der Datenquali-
tät über einen längeren Zeitraum betrachten zu können, reicht es nicht aus, für jedes unter-
suchte Datenqualitätsmerkmal die Anzahl der untersuchten und die Anzahl der als fehlerhaft
identifizierten Datensätze zu bestimmen. Es ist erforderlich, weitere Metainformationen zu
den Messergebnissen zu speichern. Dazu gehören Informationen über den Zeitpunkt der
einzelnen Datenqualitätsprüfungen, über die betrachteten Relationen und den Typ des Ab-
gleichs. Außerdem muss festgehalten werden, ob eine Überprüfung einer gesamten Relation
oder ob nur ein partieller Abgleich stattgefunden hat. Im Falle eines partiellen Abgleichs
sind Angaben über die Auswahl der überprüften Daten notwendig. Wird z.B. die Befüllung
neuer Daten überwacht, wäre es sinnvoll, den Zeitraum anzugeben, in dem die überprüften
Daten erstellt worden sind.
Abhängig vom Merkmal, das überprüft wird, müssen noch weitere Informationen zur Verfü-
gung stehen. Falls bspw. die Ergebnisse einer Prüfung der Korrektheit dargestellt werden
sollen, muss neben den Messergebnissen und den genannten Informationen auch gespeichert
werden, was als „korrekt“ angesehen wird und welche Attribute der Daten überprüft werden.
Darstellung und Bewertung der Messergebnisse 72
8.2 Bewertung der Messergebnisse
Wie in Kapitel 4.5 erläutert, existieren zahlreiche wissenschaftliche Ansätze zur Bestim-
mung der Datenqualität. Bisher konnten jedoch keine Kriterien festegelegt werden, um die
aus Datenqualitätsmessungen resultierenden Ergebnisse objektiv zu bewerten [Ca97]. For-
mal betrachtet ist eine Messung die Festlegung von Merkmalsausprägungen zu einem
Merkmal [RM02]. Diese Ausprägungen, die Ergebnisse von Datenqualitätsmessungen, wer-
den in der Praxis häufig durch Kennzahlen dargestellt [Bo97, Pf96]. Während über den Beg-
riff der Kennzahl in der Literatur wenig Einigkeit herrscht [z.B. Bo97, Si98, Re95], stimmen
die meisten Ansätze nach Mutscheller [Mu96] dahingehend überein, dass Kennzahlen der
Operationalisierung von Unternehmenszielen dienen, welche die Überprüfung von Zielerrei-
chungen unterstützen.
Unternehmen müssen sich neben den subjektiven Wahrnehmungen der Datennutzer auch mit
der objektiven Messungen der Datenqualität befassen [HLW99]. Datenqualität kann sowohl
subjektiv durch die Datennutzer beurteilt, als auch objektiv auf Basis von Qualitätsmerkma-
len gemessen und beurteilt werden. Bei der objektiven Qualitätseinschätzung wird Datenqua-
lität anhand quantifizierbarer und objektiver Variablen gemessen. Beispiele für diese Variab-
len sind die in dieser Arbeit behandelten Datenqualitätsmerkmale. Zwar wurden sie durch
die subjektive Beurteilung anhand der in Kapitel 5 beschriebenen Umfrage identifiziert, an-
hand dieser Merkmale kann die Datenqualität im DWH jedoch durch objektive Messungen
nun ermittelt werden. Bei einer objektiven Messung von Datenqualität lassen sich zwei Ar-
ten von Metriken35 unterscheiden [HLW99]:
Bei aufgabenunabhängigen Metriken wird Datenqualität unabhängig von einer vorhandenen
Aufgabe anhand quantifizierbarer und objektiver Variablen gemessen. Diese Metriken sind
leicht wieder verwendbar und können zur Bewertung für unterschiedliche Datenbestände
herangezogen werden. Diese basieren meist auf etablierten Kontrollen wie referenziellen
Integritäten und Constraints36 bei der Eingabe von Daten. Ein Beispiel für eine derartige
Kontrolle ist ein Attribut, das wegen eines Constraints nur mit den Werten „0“ und „1“ be-
legt werden darf.
35 Eine Metrik dient zur schnellen Beurteilung von Situationen und als Entscheidungshilfe [Eb04].
36 Näheres zu den Begriffen referenzielle Integrität und Constraints z.B. in [KE06].
Darstellung und Bewertung der Messergebnisse 73
Bei aufgabenabhängigen Metriken wird Datenqualität anhand von quantifizierbaren und
objektiven Variablen die Datenqualität gemessen, die jedoch vom Kontext und der Anforde-
rung der vorhandenen Aufgabe abhängt. Bei der Messung der in dieser Arbeit behandelten
Datenqualitätsmerkmale handelt es sich um aufgabenabhängige Metriken. Bei der Bewer-
tung der Korrektheit z.B. ist der Kontext ausschlaggebend, was als „korrekt“ angesehen wird
und was nicht.
Aus diesem Grund kann das Ergebnis von Messungen der Datenqualität nur in Zusammen-
hang mit den Unternehmenszielen bewertet werden. Die durch diese Ziele bestimmten An-
forderungen müssen vorher ermittelt werden, um Messergebnisse von Datenqualität ab-
schließend bewerten zu können. Es ist jedoch nicht das Ziel dieser Arbeit, Ergebnisse zu
bewerten, sondern überhaupt Merkmale zur Messung aufzuzeigen und diese Messung exem-
plarisch umzusetzen, weshalb dieser Punkt hier nicht weiter behandelt wird.
Prototypische Umsetzung 74
9 Prototypische Umsetzung
Zur prototypischen Umsetzung der Ergebnisse dieser Arbeit wurden zwei Datenqualitätsprü-
fungen prototypisch implementiert. Mit Hilfe von PL/SQL37 wurden zwei „Stored Procedu-
res“ (im Folgenden als Prozeduren bezeichnet) entwickelt, die eine Überprüfung der Tupel-
Relation-Vollständigkeit (im Folgenden als Vollständigkeit bezeichnet) und der Korrektheit
durchführen38.
Aufgrund des begrenzten Zugriffs auf die operativen Systeme und wenigen freien Kapazitä-
ten hat man sich bei beiden Überprüfungen dafür entschieden, die benötigten Daten der ope-
rativen Systemen zunächst in eine temporäre Tabellen des PAYBACK-DWH zu kopieren,
um die Systemlast und Zugriffszeit auf dem operativen System zu minimieren. Diese Vorge-
hensweise wird in Kapitel 7.2.2 näher erläutert. Die Verantwortlichen bei LP sind sich dabei
bewusst, dass bei diesem Kopiervorgang Fehler in den Daten verursacht werden könnten,
aber man schätzt das Auftreten von Fehlern hier als äußerst gering ein. Da der Abgleich der
Daten deshalb nur auf dem DWH durchgeführt wird, entspricht dies der in Kapitel 7.2.1
beschriebenen Überprüfung der Datenqualität innerhalb des DWH.
Diese Prozeduren gleichen jeweils eine einzige operative Relation (eine Relation des opera-
tiven Systems) mit einer einzigen DWH-Relation (eine Relation im DWH) ab. Sie können
zur Überprüfung einer beliebigen DWH-Relation herangezogen werden, zu der eine operati-
ve Relation als Referenz angegeben werden kann. Für die ausgewählte DWH-Relation muss
folgende Vorgabe für die Befüllungsprozesse gelten. Falls in der ausgewählten operativen
Relation ein Tupel eingefügt wird, muss der Primärschlüssel (ID) dieses Tupels durch die
Befüllungsprozesse in die ausgewählte DWH-Relation übernommen werden. Diese ID darf
nur aus einem Attribut bestehen39.
Damit die Prozeduren zur Überprüfung verschiedener DWH-Relationen herangezogen wer-
den können, ohne dabei deren Code manuell anpassen zu müssen, wurde für jeweils eine
37 PL/SQL ist die prozedurale Erweiterung für SQL von Oracle. Genauere Informationen z.B. in [Or02].
38 Die Skripten dieser Prozeduren dürfen Aufgrund der Vorgabe von LP nicht veröffentlicht werden.
39 Im DWH dient diese ID nicht als Primärschlüssel.
Prototypische Umsetzung 75
Tabelle erstellt, anhand deren Einträge die entsprechende Prozedur ein SQL generiert. Dazu
müssen zu einem Messvorgang alle relevanten Daten wie die Bezeichnungen der beteiligten
Datenbanken, Relationen, Attributbezeichnungen der IDs etc angegeben werden40. Ebenfalls
notwendig sind Angaben darüber, welche Art von Abgleich dabei durchgeführt werden soll.
Falls es sich bspw. um einen partiellen Abgleicht handelt, bei dem Daten eines bestimmten
Zeitraums untersucht werden sollen, muss dieser Zeitraum angegeben werden.
Neben der Anzahl der überprüften Datensätze und der Anzahl der Datensätze, die ein Daten-
qualitätskriterium verletzen, werden zur Dokumentation der Fehler auch die betroffenen
Datensätze ermittelt und ihre ID in einer separaten Ergebnistabelle gespeichert. Dies wurde
ursprünglich deshalb gemacht, um korrekte Funktionsweise der Prozeduren zu überprüfen.
Danach wurden die Ergebnisse von BI verwendet, um die Ursachen der Datenqualitätsdefizi-
te zu ermitteln und um etwaige Fehlerbehebungen zu diskutieren und durchzuführen.
9.1 Überprüfung der Vollständigkeit
Um eine Aussage über die Vollständigkeit der neu geladenen Daten im DWH treffen zu
können, wurde ein Mechanismus entwickelt, der die vollständige Befüllung einer Relation
im DWH durch die ETL-Prozesse wöchentlich überprüft. Dies entspricht einem in Kapitel
7.3.2 beschriebenen partiellen Abgleich des Datenbestandes. Dazu wurde eine Prozedur in
PL/SQL erstellt, die automatisiert an jedem Wochenende aufgerufen wird.
Die neu eingefügten Daten im operativen System werden anhand des Attributes „Insertedda-
te“ identifiziert. Durch die Metainformationen der Befüllungsprozesse kann bestimmt wer-
den, bis zu welchem Zeitpunkt Daten in das DWH geladen worden sind. Da die Überprüfung
der Vollständigkeit wöchentlich durchgeführt wird und zu den vergangenen Abgleichen
Metainformationen gespeichert sind, steht hier u.a. auch die Information zur Verfügung, bis
zu welchem Zeitpunkt die Vollständigkeit der Daten bereits geprüft wurde. Somit können die
Daten exakt eingegrenzt werden, die seit der letzten Vollständigkeitsprüfung in das DWH zu
laden waren und deren Existenz im DWH zu überprüfen ist. Die IDs dieser Daten werden
durch die Prozedur in eine temporäre Tabelle des DWH kopiert und die vollständige Befül-
40 Eine detaillierte Erläuterung der benötigten Daten und eine ausführliche Beschreibung der Vorge-hensweise kann nicht erfolgen, da diese Daten auf Anweisung von LP nicht veröffentlicht werden dürfen.
Prototypische Umsetzung 76
lung der DWH-Relation durch die letzten ETL-Prozesse kann anhand dieser Referenzdaten
überprüft werden.
9.2 Ergebnis der Vollständigkeitsprüfung
Zum Zeitpunkt der Erstellung dieser Arbeit werden die Befüllungsprozesse von vier DWH-
Relationen auf ihre Vollständigkeit einmal pro Woche überwacht. Die Laufzeit der Messung
beträgt jeweils ca. drei Stunden, wovon ca. 50 Minuten auf das operative System zugegriffen
wird, um die Daten temporär in das DWH zu laden.
Anfangs identifizierte die Prozedur bei einigen Überprüfungen irrtümlich Vollständigkeits-
defizite. Hauptursache waren neu eingefügte Datensätze in der operativen Relation, die zwi-
schen Beginn und Ende der Befüllungsprozesse eingefügt wurden. Bei den anfänglichen
Überprüfungen der Vollständigkeit wurden diese Daten jedoch in die Messung mit einbezo-
gen, was zu den falschen Ergebnissen führte. Nach genaueren Anpassungen der Messungen
an die Befüllungsprozesse konnte diese Fehlerquelle beseitigt werden. Bei LP wurde erwar-
tet, dass nach diesen Anpassungen die Überprüfung der Befüllungsprozesse ergeben würde,
dass alle Daten immer in das DWH geladen werden. Weitestgehend entsprach das Ergebnis
diesen Erwartungen. Allerdings wurden sporadisch Vollständigkeitsdefizite im Promillebe-
reich ermittelt. Manuelle Überprüfungen der ermittelten IDs bestätigten dies. Oft wurden
aber diese ermittelten Tupel beim folgenden Befüllungsprozess in das DWH übernommen41,
was aber nicht immer der Fall war.
Bei zwei Messungen, die Vollständigkeitsdefizite ermittelten, wurden die Daten auch bei den
darauf folgenden Befüllungsprozessen nicht in das DWH geladen. Hier konnten Prozesse als
Ursache identifiziert werden, die nur sporadisch und in großen Zeitabständen ausgeführt
werden und Daten in das operative System einfügen. Die eingefügten Tupel waren aber mit
einem veralteten „Inserteddate“ markiert, weshalb der folgende Befüllungsprozess diese
nicht als neu erkannt hatte. Somit kann bereits die prototypische Implementierung der Voll-
ständigkeitsprüfung als Erfolg gewertet werden.
41 Es kommt in seltenen Fällen vor, dass ein neu eingefügter Datensatz ein „Commit“ erst zu einem viel späteren Zeitpunkt erhält.
Prototypische Umsetzung 77
9.3 Überprüfung der Korrektheit
Die Überprüfung der Korrektheit wird zum Zeitpunkt der Erstellung dieser Arbeit noch nicht
regelmäßig genutzt. Sie wurde zur Überprüfung eines bekannten Defizits der Datenqualität
eingesetzt. Dazu sollte der gesamte Datenbestand einer DWH-Relation überprüft werden.
Jedoch befanden sich mehr als 1,7 Mrd. Datensätze in dieser Relation, die aufgrund der zu
erwartenden langen Laufzeit nicht durch einen einzigen Abgleich überprüft werden konnten.
Um dennoch die Korrektheit des gesamten Datenbestand zu ermitteln, wurden durch mehre-
re partielle Abgleiche, die in Kapitel 7.3.2 genauer beschrieben sind, sequenziell die gesamte
Relation überprüft. Dazu wurden jeweils die Daten eines Kalenderjahres bzw. -halbjahres
überprüft.
Die Korrektheitsprüfung wurde dahingehend entwickelt, dass die Korrektheit eines einzigen
Attributes einer DWH-Relation überprüft werden kann. Wie in Kapitel 6.2 erläutert, ist ein
Attributwert im DWH dann korrekt, wenn er unter Beachtung der vorgenommenen Trans-
formationen mit dem bzw. den Werten des Quellsystems übereinstimmt, mit denen er befüllt
wurde. Zum Zeitpunkt der Erstellung dieser Arbeit können nur „1:1“-Transformationen ü-
berprüft werden. Die Prozedur kann jedoch entsprechend weiter entwickelt werden, um so-
wohl komplexere Transformationen zu überprüfen, als auch mehrere Attribute gleichzeitig
durch einen Abgleich auf ihr Korrektheit zu untersuchen. Anhand des Attributes „Insertedda-
te“ im operativen System werden die Daten eines Kalenderjahres bzw. -halbjahres für jeden
Abgleich selektiert. Die ID und das zu überprüfende Attribut werden in eine temporäre Ta-
belle des DWH kopiert, wo sie nun innerhalb des DWH als Referenzdaten zur Verfügung
stehen, um die Korrektheit der Daten in der DWH-Relation zu überprüfen. Anhand der ID
eines jeden Datensatzes der temporären Tabelle wird der entsprechende Datensatz in der
DWH-Relation ermittelt und das Attribut auf Übereinstimmung überprüft.
Diese Korrektheitsprüfung schließt auch eine Vollständigkeitsprüfung mit ein. Falls eine ID
in den Referenzdaten nicht in der DWH-Relation vorhanden ist, wird dieser Datensatz als
„fehlend“ erkannt und (mit einem entsprechenden Kommentar) in der Ergebnistabelle ge-
speichert.
9.4 Ergebnis der Korrektheitsprüfung
Bei der Korrektheitsprüfung wurde gezielt nach dem Ausmaß einer bekannten Verletzung
der Korrektheit eines Attributes gesucht. Es lag keine Information darüber vor, welche und
wie viele Datensätze betroffen waren. Mit Hilfe der Korrektheitsprüfung konnten die IDs
Prototypische Umsetzung 78
aller Datensätze ermittelt werden, bei denen die Korrektheit dieses Attributes verletzt wurde.
Von den über 1,7 Mrd. Datensätzen haben jedoch nur ca. 5000 Datensätze das Merkmal der
Korrektheit verletzt und 17 Datensätze, die in der operativen Relation vorhanden waren,
fehlten in der DWH-Relation.
Die Laufzeiten der sechs durchgeführten Abgleiche betrugen zwischen sechs und acht Stun-
den. Bei jedem Abgleich wurden 200 bis 350 Mio. Datensätze abgeglichen. Das operative
System war jeweils zwischen 1,5 und 3,5 Stunden belastet worden, um die Daten in die tem-
poräre Tabelle des DWH zu kopieren. Insgesamt benötigte die sechs Überprüfung der Kor-
rektheit ca. 38 Stunden. Auch die prototypische Implementierung der Korrektheitsprüfung
kann daher als Erfolg gewertet werden.
Zusammenfassung 79
10 Zusammenfassung
10.1 Fazit
In der vorliegenden Arbeit wurde eine Vorgehensweise zur Messung der Datenqualität in
einem Data Warehouse konzipiert und dargestellt. Dazu wurden Merkmale erarbeitet, an-
hand derer die Datenqualität objektiv gemessen werden kann. Die dargestellte Herange-
hensweise ermöglicht es, die Messungen für die Datenqualität gemäß der aktuellen Ressour-
censituation der Systeme zu skalieren, durchzuführen und die Messergebnisse für eine Be-
wertung zur Verfügung zu stellen. Die Ergebnisse dieser Arbeit können zur Ermittlung der
Datenqualität eines beliebigen DWH herangezogen werden. Die hier vorgestellten Ergebnis-
se wurden auf Basis des PAYBACK-DWH erarbeitet und angewandt. Es wurden Beispiele
aus der Praxis dargestellt, die für die Bestimmung und Überwachung der Datenqualität im
PAYBACK-DWH konzipiert wurden. Loyalty Partner hat dadurch eine neue Möglichkeit
gewonnen, die Qualität der strategisch wichtigen Daten zu messen.
Einführend wurde der Begriff der Datenqualität näher erläutert, denn sowohl die verschiede-
nen Definitionen des Begriffes der Datenqualität selbst, als auch die zur Messung notwendi-
gen Merkmale und deren Beschreibungen variieren stark in der wissenschaftlichen Literatur.
Ein Beispiel dafür ist der Systematisierungsansatz von Garvin [Ga84], nach dem er Qualität
unterschiedlich klassifiziert. Garvin identifiziert unterschiedliche Sichtweisen bezogen auf
die Qualität von Produkten und Dienstleistungen. Seine anwenderbezogene Betrachtungs-
weise, nach welcher der Datennutzer in den Vordergrund gestellt wird, wurde als die
zweckmäßigste Sichtweise erachtet, um die Datenqualität in einem DWH zu ermitteln. Im
Hinblick darauf wurden einige Ansätze vorgestellt, die zur Bestimmung der Datenqualitäts-
merkmale dienen können.
Um die relevanten Datenqualitätsmerkmale für das PAYBACK-DWH zu identifizieren,
wurde eine Umfrage unter den LP Mitarbeitern durchgeführt, die regelmäßig Daten aus dem
unternehmensweiten DWH beziehen. Durch die Analyse der Umfrageergebnisse konnten die
wichtigsten Merkmale identifiziert werden, die für die Messung von Datenqualität für das
PAYBACK-DWH ausschlaggebend sind. Die daraus resultierenden Merkmale sind messbar
und beziehen sich auf Vollständigkeit, Korrektheit, Aktualität, Historisierung und Wider-
spruchsfreiheit der Daten. Die Messung dieser Merkmale kann bei jedem DWH erfolgen.
Zusammenfassung 80
Da in der wissenschaftlichen Literatur keine einheitliche Bezeichnung und Definition für die
oben genannten Merkmale existiert, wurden diese in der vorliegenden Arbeit genauer be-
schrieben und definiert. Dabei wurden die Besonderheiten eines DWH berücksichtigt, dessen
Datenhaltung sich deutlich von der eines operativen Systems unterscheidet.
Die notwendige Vorgehensweise für die Messung der Datenqualität anhand der identifizier-
ten Merkmale wurde näher erläutert. Hierbei spielen unterschiedliche Faktoren eine Rolle.
Die Messprozesse müssen unter Berücksichtigung von Systemverfügbarkeit und den vor-
handenen Ressourcen eingeplant und durchgeführt werden. Um die Ergebnisse der Messun-
gen für weitergehende Bewertungen unternehmensweit zur Verfügung zu stellen, wurde die
bei LP angewandte Darstellungsweise vorgestellt.
Die Erkenntnisse dieser Arbeit wurden exemplarisch umgesetzt. Anhand von entwickelten
Messprozessen wurden einige der oben aufgeführten Merkmale bei LP prototypisch imple-
mentiert. Diese Messprozesse finden im täglichen Geschäftsleben bei LP bereits ihren Ein-
satz, um anhand deren Ergebnisse eine Aussage über die Datenqualität im PAYBACK-DWH
treffen zu können.
10.2 Ausblick
Die Qualität der Daten bekommt in den unterschiedlichsten Unternehmen eine immer höhere
Bedeutung. Immer mehr wird ersichtlich, dass strategische Entscheidungen auf Daten hoher
Qualität basieren müssen, um mögliche Fehlentscheidungen zu vermeiden. Das Konzept,
welches hier vorgestellt wurde, bietet eine geeignete Vorgehensweise, um Datenqualität in
einem beliebigen DWH zu messen.
Die hier dargestellte Vorgehensweise kann als Grundlage für weitere Arbeiten herangezogen
und erweitert werden. In dieser Arbeit wurden Datenqualitätsmerkmale identifiziert, die mit
Hilfe des existierenden Datenmodells gemessen werden können. Vorhandene wissenschaftli-
che Arbeiten identifizieren jedoch auch Merkmale, die ein adaptiertes (angepasstes) Daten-
modell voraussetzen. Des Weiteren findet man in der Literatur Merkmale, die sich auf die
Qualität eines Datenmodells beziehen. Diese wurden im Rahmen der vorliegenden Arbeit
nicht näher untersucht, da das Datenmodell für diese Arbeit als fest vorgegeben und nicht
veränderbar vorausgesetzt wurde. Es gibt zusätzliche Merkmale, welche die Verfügbarkeit
des Systems, die Darstellung der Daten in den Auswertungen oder auch den Zugriff auf das
Gesamtsystem betreffen. In weiterführenden Arbeiten können auch diese Merkmale genauer
Zusammenfassung 81
untersucht werden, in Abhängigkeit der Anforderungen, die an die Qualität von Daten in
einem DWH gestellt werden.
Auch die Überprüfung der in dieser Arbeit erwähnten Aggregationen von Daten, die im
DWH aufwendig berechnet werden, können, in Hinsicht auf Datenqualität, ein Thema für
weitere Arbeiten darstellen.
Bisher konnten noch keine objektiven Kriterien zur Bewertung von Ergebnissen, die aus
Messungen von Datenqualität resultieren, etabliert werden. Hier besteht Bedarf für weiterge-
hende Untersuchungen, welche geeignete und einheitliche Kriterien identifizieren und fest-
legen. Diese müssen immer unter der Berücksichtigung der unternehmensspezifischen An-
forderungen erfolgen.
Literaturverzeichnis VII
Literaturverzeichnis
[AA87] Agmon, N.; Ahituv, N.: Assessing Data Reliability in an Information System.
In: Journal of Management Information Systems. Vol. 4, Ausgabe 2, 1987,
S. 34-44.
[Ba03] Bange, C. et al.: BARC Studie. Data Warehousing und Datenintegration. 15
Data-Warehouse- und ETL-Werkzeuge. Oxygon Verlag, München, 2003.
[Be96] Behme, W.: Business Intelligence als Baustein des Geschäftserfolgs. In:
Mucksch, H.; Behme, W. (Hrsg.): Das Data-Warehoue-Konzept: Architektur
– Datenmodelle – Anwendungen. Mit Erfahrungsberichten. Gabler, Wiesba-
den, 1996, S. 27-45.
[BG01] Bauer, A.; Günzel, H.: Data-Warehouse-Systeme: Architektur, Entwicklung,
Anwendung. dpunkt.Verlag, Heidelberg, 2001.
[Bi94] Bischoff, J.: Achieving Warehouse Success. In: Database Programming &
Design. Vol. 7, Nr. 7, 1994, S. 26 – 33.
[Bo97] Botta, V.: Kennzahlensysteme als Führungsinstrumente: Planung, Steuerung
und Kontrolle der Rentabilität im Unternehmen. Schmidt, 5. Auflage, Berlin,
1997.
[Br80] Brodie, M.L.: Data Quality in Information Systems. In: Information Mange-
ment. Vol. 3, 1980, S. 245-258.
[BS02] Bange, C.; Schinzer, H. (o.J.): Data Warehouse und Business Intelligence –
Grundlagen entscheidungsorientierter Informationssysteme. 2002.
http://www.competence-site.de/bisysteme.nsf (Abgerufen am: 17.05.2006)
[Bu48] Buchanen, S. (Hrsg.): The Portable Plato. The Viking Press, New York,
1948.
[Bu03] Butthof, W.: Ausländische Akkreditierungssysteme und Qualitätsmanage-
ment-Modelle für Krankenhäuser. Darstellung und Analyse ausgewählter
Standards. Dissertation, Universität Konstanz, 2003.
Literaturverzeichnis VIII
[Ca97] Caduff, D.: Vorgehensweise für entwicklungsorientierte Assessments am
Beispiel von Modellen des Total Quality Managements. Dissertation, Uni-
versität St. Gallen, Difo-Druck, Bamberg, 1997.
[CCS93] Codd, E.F.; Codd, S.B.; Salley, C.T.: Providing OLAP (On-Line Analytical
Processing) to User-Analysts. An IT Mandate. Technical Report, E.F. Codd
and Associates, 1993.
[Ch04] Chamoni, P. et al.: Empirische Bestandsaufnahme zum Einsatz von Business
Intelligence. Business Intelligence Maturity Modell (biMM). In: Chamoni, P.
et al. (Hrsg.): Multikonferenz Wirtschaftsinformatik (MKWI) 2004. Universi-
tät Duisburg-Essen, 9.-11. März 2004, Band 2, Akademische Verlagsgesell-
schaft, Berlin, 2004, S. 111 - 124.
[Cr90] Crosby, P.B.: Qualität ist machbar. McGraw Hill, Hamburg, 1990.
[De82] Deming, W.E.: Quality, Productivity and Competitive Position. Massachu-
setts Institute of Technology, Cambridge, MA, 1982.
[DI90] DIN ISO 8402: Qualitäts-Begriffe. Hrsg.: DIN, Deutsches Institut für Nor-
mung e.V., Beuth Verlag, Berlin, 1990.
[Eb04] Ebert, C. et al.: Best Practices in Software Measurement. How to use metrics
to improve project and process performance. Springer, Berlin, 2004.
[En99] English, L.P.: Improving Data Warehouse and Business Information Qual-
ity: Methods for Reducing Costs and Increasing Profits. John Wiley & Sons,
New York, 1999.
[Ec02] Eckerson, W.W.: Data Quality and the bottom line: Archieving Business
Success Through a Commitment to High Quality Data. The Data Warehouse
Institute Report Series, Seattle, 2002.
[EW00] Eppler, M.; Wittig, D.: Conceptualizing Information Quality: A Review of
Information Quality Frameworks from the Last Ten Years. In: Klein, B.D.;
Rossin, D.F. (Hrsg.): Proceedings of the 2000 Conference on Information
Quality. Massachusetts Institute of Technology, Cambridge, MA, 2000,
S. 83-96.
Literaturverzeichnis IX
[Fe91] Feigenbaum, A.V.: Total Quality Control. McGraw Hill, Third edition
revised, New York, 1991.
[Ga84] Garvin, D.A.: What does ’Product Quality’ really mean?. In: Sloan Man-
agement Review. Volume 26, Nr. 1, 1984, S. 25–43.
[Gl97] Gluchowski, P.: Data Warehouse-Detenmodellierung – Weg von der starren
Normalform. In: Datenbank-Fokus. Nr. 11, 1997, S. 62-66.
[HA01] Harren, A,; Appelrath, H.J.: Bewirtschaftung Temporaler Data Warehouses
unter Berücksichtigung von Schemaänderungen. In: Doctoral Consortium im
Vorfeld der WI-IF 2001, Kolloquium für Doktoranden der Wirtschaftsinfor-
matik. Günzburg, 2001.
[Ha03] Hahne, M.: Logische Datenmodellierung zur Abbildung mehrdimensionaler
Datenstrukturen im SAP Business Information Warehouse. In: Weikum, G.;
Schöning, H.; Rahm, E. (Hrsg.): BTW 2003 Datenbanksysteme für Business,
Technologie und Web. Köllen Druck + Verlag, Bonn, 2003, S. 630-647.
[He01] Helfert, M.: Spezifikation und Messung der Datenqualität in Data–
Warehouse–Systemen - Vorstellung des Dissertationsprojektes, St. Gallen,
2001. http://www.computing.dcu.ie/~mhelfert/Research/publication/2001/
DocColloquium2001.pdf (Abgerufen am: 11.01.2006).
[He02a] Helfert, M.: Planung und Messung der Datenqualität in Data-Warehouse-
Systemen, Dissertation, Universität St. Gallen, Difo-Druck, Bamberg, 2002
[He02b] Helfert, M.: Proaktives Datenqualitätsmanagement in Data–Warehouse–
Systemen – Qualitätsplanung und Qualitätslenkung. Logos Verlag, Berlin,
2002.
[Hi02] Hinrichs, H.: Datenqualitätsmanagement in Data Warehouse-Systemen.
Dissertation, Universität Oldenburg, 2002.
[HH03] Heinrich, B.; Helfert, M.: Nützt Datenqualität wirklich im CRM? – Wir-
kungszusammenhänge und Implikationen. In: Proceddings of the 6th Inter-
national Conference for Business Informatics 2003. Dresden, 2003.
Literaturverzeichnis X
[HKB01] Holten, R.; Knackstedt, R.; Becker, J.: Betriebswirtschaftliche Herausforde-
rungen durch Data-Warehouse-Technologien. In: Schütte, R.; Rotthowe, T;
Holten, R.: Data Warehouse Managementhandbuch: Konzepte, Software,
Erfahrungen. Springer, Berlin, 2001, S.41-64.
[HLW99] Huang, K.; Lee, Y.W.; Wang, R.Y.: Quality Information and Knowledge.
Prentice Hall, Upper Saddle River, N.J., 1999.
[HM01] Helfert, M; Maur, E.: A Strategy for Managing Data Quality in Data Ware-
house Systems. In: Pierce, E.M.; Kaatz-Haas, R.: Proceedings of the Sixth In-
ternational Conference on Information Quality. Massachusetts Institute of
Technology , Cambridge, MA, 2001, S. 62-76.
[Ho99] Holthuis, J.: Der Aufbau von Data Warehouse-Systemen: Konzeption – Da-
tenmdellierung – Vorgehen. DUV/Gabler, 2. Auflage, Wiesbaden, 1999.
[HW05] Humm, B.; Wietek, F.: Architektur von Warehouses und Business Intelligen-
ce Systemen. In: Informatik Spektrum. Band 28, Nr. 1, 2005, S. 3–18.
[In96] Inmon, W.H.: Building the Data Warehouse. John Wiley & Sons, 2. Auf-
lage, New York, 1996.
[Ja99] Jarke, M et. al.: Architecture and Quality in Data Warehouses: An Extended
Repository Approach. In: Information Systems, 24. Jg., Nr. 3, 1999,
S. 229-253.
[Ju74] Juran, J.M.: Quality Control Handbook. McGraw Hill, 3. Auflage, New
York 1974.
[JV97] Jarke, M.; Vassiliou, Y.: Foundation of Data Warehouse Quality – A Review
of the DWQ Project. In: Strong, D.M.; Kahn, B.K. (Hrsg.): Proceedings of
the 1997 Conference on Information Quality. Massachusetts Institute of
Technology, Cambridge, MA, 1997, S.299-313.
[KE06] Kemper, A.; Eickler, A.: Datenbanksysteme. Eine Einführung. Oldenbourg
Verlag, 6. Auflage, München, 2006.
Literaturverzeichnis XI
[Ki96] Kimball, R.: The Data Warehouse Toolkit. John Wiley & Sons, New York,
1996.
[Ki98] Kimball, R. et al.: The Data Warehouse Lifecycle Toolkit. Expert Methods
for Designing, Developing and Deploying Data Warehouses. John Wiley &
Sons, New York, 1998.
[KN96] Kaplan, R. S.; Norton, D. P.: The Balanced Scorecard - Translating Strategy
Into Action. Harvard Business School Press, Boston, 1996.
[KSW97] Kahn, B.; Strong, D.M.; Wang, R.Y.: A Model for Delivering Quality Infor-
mation as Product and Services. In: Proceedings of the 1997 Conference on
Information Quality. Massachusetts Institute of Technology, Cambridge,
MA, 1997, S. 80-94.
[Lu01] Lusti, M.: Data Warehousing und Data Minig: Eine Einführung in entschei-
dungsunterstützende Systeme. Springer, 2. Auflage, Berlin, 2001.
[Ma05] Martin, M.: Measuring and Improving Data Quality. Part II: Measuring
Data Quality. In: NAHSS Outlook. Ausgabe 5, April 2005.
http://www.aphis.usda.gov/vs/ceah/ncahs/nsu/outlook/issue5/data_quality_p
art2.pdf (Abgerufen am 28.05.2006).
[MB00] Mucksch, H.; Behme, W.: Das Data Warehouse-Konzept als Basis einer
unternehmensweiten Informationslogistik. In: Mucksch, H.; Brehme, W.
(Hrsg.): Das Data-Warehoue-Konzept: Architektur – Datenmodelle – An-
wendungen. Mit Erfahrungsberichten. Gabler, 4. Auflage, Wiesbaden, 2000,
S. 3-82.
[Mu96] Mutscheller, A.M.: Vorgehensmodell zur Entwicklung von Kennzahlen und
Indikatoren für das Qualitätsmanagement. Dissertation, Universität St. Gal-
len, Difo-Druck, Bamberg, 1996.
[Ni99] Niemiec, R.J.: Oracle Performance Tuning Tips & Techniques. Osbor-
ne/McGraw-Hill, Berkeley, CA, 1999.
Literaturverzeichnis XII
[NR99] Naumann, F.; Rolker, C.: Assessment Methods for Information Quality Cri-
teria. In: Proceedings of the 1999 Conference on Information Quality. Mas-
sachusetts Institute of Technology, Cambridge, MA, 1999, S. 99-114.
[Nu98] Nußdorfer, R.: Star Schema, das E/R-Modell steht Kopf – Teil I: Modellie-
rung von Faktentabellen. In: Datenbank-Fokus, Nr. 10, 1998, S. 22-28.
[Oe00] Oehler, K.: OLAP: Grundlagen, Modellierung und betriebswirtschaftliche
Lösungen. Hanser, München, 2000.
[Or02] Orcacle User´s Guide and Reference: PL/SQL. Release 2 (9.2), Part No.
A96624-01. 2002. http://download-east.oracle.com/docs/cd/B10501_01/app
dev.920/a96624.pdf (Abgerufen am 10.06.2006).
[Pf96] Pfeifer, T.: Praxishandbuch Qualitätsmanagement. Hanser, München, 1996.
[Pi74] Pirsig, R.: Zen and the Art of Motorcycle Maintenance. Bantam Books, New
York, 1974.
[Po98] Potthof, I.: Kosten und Nutzen der Informationsverarbeitung - Analyse und
Beurteilung von Investitionsentscheidungen. DUV/Gabler, Wiesbaden, 1998.
[Qu03] Quix, C.J.: Metadatenverwaltung zur qualitätsorientierten Informationslo-
gistik in Data-Warehouse-Systemen. Dissertation, Technische Hochschule
Aachen, 2003.
[Re95] Reichmann, T.: Controlling mit Kennzahlen und Managementberichten:
Grundlage einer systemgestützten Controlling-Konzeption. Vahlen,
4.Auflage, München, 1995.
[Re96] Redman T.C.: Data Quality for the Information Age. Artech House, Boston,
1996.
[RH96] Reiser, M; Holthuis, J.: Nutzenpotenziale des Data-Warehouse-Konzepts. In:
Mucksch, H.; Brehme, W. (Hrsg.): Das Data-Warehoue-Konzept: Architek-
tur – Datenmodelle – Anwendungen. Mit Erfahrungsberichten. Gabler,
Wiesbaden, 1996, S. 117-132.
Literaturverzeichnis XIII
[RM02] Rinne, H.; Mittag, H.J.: Statistische Methoden der Qualitätssicherung. Han-
ser, 3. Auflage, München, 2002.
[Sa03] Studie im Auftrag von SAS: In zwei Drittel der europäischen Unternehmen
leidet die Profitabilität unter schlechter Datenqualität. 2003.
http://www.sas.com/offices/europe/switzerland/news/pressrelease/2003/archi
v/archiv_juni_2003.html (Abgerufen am: 11.01.2006).
[Sc00] Schelp, J.: Modellierung mehrdimensionaler Datenstrukturen analyseorien-
tierter Informationssysteme. Gabler, Wiesbaden, 2000.
[Se95] Seidl, J.: Ansatz geht weiter als EIS und MIS, Einbeziehung der Anwender ist
das A und O beim Warehousing. In: Computerwoche. Ausgabe 50, 1995,
S. 56-58.
[SBM99] Schinzer, H.D.; Bange, C.; Mertens, H.: Data Warehouse und Data Mining.
Vahlen, 2. Auflage, München, 1999.
[SMB05] Scannapieco, M.; Missier, P.; Batini, C.: Data Quality at a Glance. In: Da-
tenbank-Spektrum. dpunkt.Verlag GmbH, 5. Jg., Nr. 14, 2005, S. 6-14.
[Si98] Siegwart, H.: Kennzahlen für die Unternehmensführung. Haupt, 5. Auflage,
Bern, 1998.
[St95] Stahlknecht, P.: Eine Einführung in die Wirtschaftsinformatik. Springer,
7. Auflage, Berlin, 1995.
[Th03] Thurnheer, A.: Temporale Auswertungsformen in OLAP. Dissertation, Uni-
versität Basel, 2003.
[Th04] Thienen, L. (Manager Magazin): Die Macht der Daten. 2004.
http://www.manager-magazin.de/it/artikel/0,2828,311287,00.html (Abgeru-
fen am: 11.01.2006).
[TKS01] Tsois, A.; Karayiannidis, N.; Sellis, T.: MAC: Conceptual data modeling for
OLAP. In: Proceedings of the International Workshop on Design and Man-
agement of Data Warehouses (DMDW). Interlaken, Schweiz, 2001.
S. 5/1-5/13.
Literaturverzeichnis XIV
[Wa95] Wang, R. et. al.: A framework for analysis of data quality research. In: IEEE
Transactions on Knowledge and Data Engineering, 7.Jg., Nr. 4, 1995,
S. 623-640.
[Wa01] Wallmüller E.: Software-Qualitätsmanagement in der Praxis. Hanser-
Verlag, München, 2001.
[Wi72] Witte, E.: Das Informationsverhalten in Entscheidungsprozessen. Mohr
Siebeck, Tübingen, 1972.
[Wi06] Wimmer, H.: Ohne ein Enterprise Data Warehouse ist effizientes Business
Intelligence kaum zu realisieren. In: manage it. Online-Artikel zu Business
Intelligence. 2006. http://www.ap-verlag.de/Online-Artikel/200604-
BI/200604-BI-Teradata.htm (Abgerufen am: 02.06.2006).
[Wo99] Wolf, P.: Konzept eines TQM-basierten Regelkreismodells für ein „Informa-
tion Quality Management“ (IQM). Hrsg.: Kuhn, A., Verlag Praxiswissen,
Dortmund, 1999.
[WS96] Wang, R.Y.; Strong D.M.: Beyond Accuracy: What Data Quality Means to
Data Consumers. Journal of Management Information Systems, 12. Jg.,
Nr. 4, 1996, S. 5–34.
[WW96] Wand, Y.; Wang, R.Y.: Anchoring Data Quality Dimensions in Onthologi-
cal Foundations. Communications of the ACM, 39. Jg., Nr. 11, 1996,
S. 86-95.
[ZS99] Zurek, T.; Sinnwell, M.: Data Warehousing Has More Colours Than Just
Black & White. In: Proceedings of the 25th International Conference on
Very Large Data Bases, VLDB´99. 1999, S. 726-729.
Anhang A: Fragebogen XV
Anhang A: Fragebogen
Der Bereich Business Intelligence (BI) stellt Ihnen in Form von Reports, Auswertungen oder der Scorecard Daten zur Verfügung, die im Data Warehouse vorgehalten sind. Wir würden gerne unseren Service verbessern und bitten Sie daher, sich kurz Zeit zu nehmen und einige Fragen zu unserem Service bzw. zu den von uns bereit gestellten Daten zu beantworten.
Für welches Team arbeiten Sie:
Umfrage zur Qualität der durch Business Intelligence zur Verfügung gestellten Daten
nie (1)
selten (2)
häuf ig (3)
sehr hä ufig (4)1 a) Kommt es vor, dass sich Daten in unterschiedlichen Reports /
Auswertungen oder in der Scorecard widersprechen?
b) Geben Sie bitte ein Beispiel an:
2 Falls Sie in den letzen Monaten Auswertungen oder Analysen durchgeführt haben, beantworten Sie bitte die folgenden Fragen:
a) Waren die Daten nicht vollständig, haben Zeilen bzw. Kennzahlen gefehlt?
c) Waren Daten doppelt vorhanden?d) Sonstige
e) Falls sonstige, welche:
b) Waren die Daten nicht korrekt (Anzeige von falsche Daten)?
Falls 2 bis 4: (ansonsten weiter mit Frage 2)
Anhang A: Fragebogen XVI
sehr wicht ig (1)
wichtig (2)
weniger wichtig (3)
unwic hti g (4)
BI ist bemüht, mit dem Data Warehouse möglichst aktuelle Daten zur Verfügung zu stellen. Die aktuellsten Daten, die bereitgestellt werden können, sind vom Vortag. In einigen Fällen werden uns von PAYBACK-Partnern Daten nur monatsweise übermittelt. Hier ist es nur möglich, die Daten des Vormonats oder ältere Daten abzurufen.
3
a) Ist es für Sie entscheidend, Daten auf Basis eines höchstmöglich aktuellen Datenbestands (also vom Vortag)
4 a) Ist es für Sie wichtig, dass Daten für sehr lange Zeit gespeichert werden, damit sie für Auswertungen über einen langen Zeitraum hinweg (z.B. mehrere Jahre) zur Verfügung stehen?
b) Wie lange sollen Daten für die Scorecard, Reports oder Auswertungen zur Verfügung stehen?
5 Falls Sie selbst mit Hilfe eines Programms Auswertungen auf der Datenbank durchführen, beantworten Sie bitte folgende Fragen:
a) Ist es für Sie von Bedeutung, dass das System (die Datenbank) während Ihrer Arbeitszeit immer verfügbar ist, so dass Sie jederzeit Auswertungen ausführen können?
b) Wie wichtig ist für Sie eine kurze Laufzeit der Abfragen?c) Wie lange sind Sie bereit, auf das Ergebnis einer Auswertung zu warten? Maximale Wartezeit:
d) Können Sie alle Daten abfragen, die zur Erledigung Ihrer Aufgaben notwendig sind?
BI ist bemüht, mit dem Data Warehouse möglichst aktuelle Daten zur Verfügung zu stellen. Die aktuellsten Daten, die bereitgestellt werden können, sind vom Vortag. In einigen Fällen werden uns von PAYBACK-Partnern Daten nur monatsweise übermittelt. Hier ist es nur möglich, die Daten des Vormonats oder ältere Daten abzurufen.
b) Bitte geben Sie an, wie aktuell die Daten zur Verfügung stehen sollen:
Vortag Vorwoche Vormonat Voriges Quartal Vorjahr
1 Jahr 2 Jahre 3 Jahre Seit Programmstart
Ja Nein
Anhang A: Fragebogen XVII
sehr gut ( 1)
gut (2)
befr iedigend (3)
ausreiche nd (4)
mange lhaft (5)
6 a) Bewerten Sie bitte den Nutzen der Ihnen für Ihre Aufgaben zur Verfügung gestellten Reports / Daten / Auswertungen.
Falls 2 bis 4: (ansonsten weiter mit Frage 7)b) Bitte geben Sie an, warum Ihnen die Daten nicht (mehr) hilfreich für Ihre Aufgaben sind:
7 Bewerten Sie bitte die Darstellung der abgefragten bzw. Ihnen zur Verfügung gestellten Daten.
8 Falls Sie selbst mit Hilfe eines Programms Auswertungen auf der Datenbank durchführen, beantworten Sie bitte folgende Fragen.
a) Können Sie die Daten auf einen für Ihre Aufgabe relevanten Datenbereich einschränken?
b) Warum nicht?
9
Falls 2 bis 4:
Beschreiben Sie bitte, welchen Qualitätsanforderungen die von Ihnen benötigten Daten Ihrer Meinung nach genügen sollten.
Anhang A: Fragebogen XVIII
10
Vielen Dank!
Platz für sonstiges:
Anhang B: Angaben der Anwendergruppen XIX
Anhang B: Angaben der Anwendergruppen
B1: Angaben der Anwendergruppe Management
Angaben in den Auswahlfeldern:
Frage Merkmal Antwort Anzahl Nennungen Prozentual nie 1 20% selten 1 20% häufig 3 60% sehr häufig 0 0%
1a Widersprüchliche Daten
keine Angaben 0 0% nie 0 0% selten 0 0% häufig 3 60% sehr häufig 0 0%
2a Vollständige Daten
keine Angaben 2 40% nie 0 0% selten 2 40% häufig 1 20% sehr häufig 0 0%
2b Korrekte Daten
keine Angaben 2 40% nie 0 0% selten 1 20% häufig 2 40% sehr häufig 0 0%
2c Dubletten vorhanden
keine Angaben 2 40% nie 0 0% selten 0 0% häufig 0 0% sehr häufig 0 0%
2d Sonstige
keine Angaben 5 100% sehr wichtig 2 40% wichtig 2 40% weniger wichtig 1 20% unwichtig 0 0%
3a Aktualität
keine Angaben 0 0% Vortag 5 100% Vorwoche 0 0% Vormonat 0 0% Voriges Quartal 0 0% Vorjahr 0 0%
3b Wie aktuell sollten die Daten sein?
keine Angaben 0 0% sehr wichtig 1 20% wichtig 3 60%
4a Historisierung
weniger wichtig 1 20%
Anhang B: Angaben der Anwendergruppen XX
Frage Merkmal Antwort Anzahl Nennungen Prozentual unwichtig 0 0% keine Angaben 0 0% 1 Jahr 2 40% 2 Jahre 0 0% 3 Jahre 1 20%
Alle Daten seit Pro-grammstart 2 40%
4b Über welchen Zeitraum sollen Daten historisiert vorgehalten werden?
keine Angaben 0 0% sehr wichtig 3 60% wichtig 1 20% weniger wichtig 1 20% unwichtig 0 0%
5a Systemverfügbarkeit
keine Angaben 0 0% sehr wichtig 1 20% wichtig 3 60% weniger wichtig 1 20% unwichtig 0 0%
5b Kurze Laufzeit
keine Angaben 0 0% Ja 2 40% Nein 3 60% 5d
Zugriff auf alle Daten möglich?
Keine Angaben 0 0% sehr gut 2 40% gut 2 40% befriedigend 1 20% ausreichend 0 0% mangelhaft 0 0%
6a Nutzen der Daten
keine Angaben 0 0% sehr gut 1 20% gut 2 40% befriedigend 1 20% ausreichend 1 20% mangelhaft 0 0%
7 Darstellung
keine Angaben 0 0% sehr gut 2 40% gut 3 60% befriedigend 0 0% ausreichend 0 0% mangelhaft 0 0%
8a Relevanz
keine Angaben 0 0%
Angaben in den Freitextfeldern:
Frage Antworten 1b - 2e Abweichungen von operativen Kennzahlen
2 Minuten 5c 1 Stunde
Anhang B: Angaben der Anwendergruppen XXI
Frage Antworten 1 Min.
6b - 8b -
Konsistenz, Verständlichkeit (vor allem bzgl. Definition und Benennung), Vollständigkeit, Aktualität
Gewissenhafte Check der Zahlen bevor sie kommuniziert werden; Regelmäßige Prüfung der Kennzahldefinitionen, keine Dubletten
höhere Zuverlässigkeit in der Bereitstellung; höherer SL der Pünktlichkeit in der Bereitstel-lung; nachträgliche Änderungen - wenn überhaupt - nur aus externen Ursachen (die in der gemessenen Größe selbst liegen); bei Reloads keine Vervielfachung der Mengen
9
korrekt, allgemein gültig, genau einer Definition entsprechend 10 -
B2: Angaben der Anwendergruppe Prozessverantwortliche
Angaben in den Auswahlfeldern:
Frage Merkmal Antwort Anzahl Nennungen Prozentual nie 1 7,7% selten 6 46,1% häufig 4 30,8% sehr häufig 1 7,7%
1a Widersprüchliche Daten
keine Angaben 1 7,7% nie 2 15,4% selten 6 46,2% häufig 2 15,4% sehr häufig 0 0,0%
2a Vollständige Daten
keine Angaben 3 23,1% nie 2 15,4% selten 4 30,8% häufig 2 15,4% sehr häufig 1 7,7%
2b Korrekte Daten
keine Angaben 4 30,8% nie 5 38,5% selten 2 15,4% häufig 0 0,0% sehr häufig 0 0,0%
2c Dubletten vorhanden
keine Angaben 6 46,2% nie 0 0% selten 0 0% häufig 0 0% sehr häufig 0 0%
2d Sonstige
keine Angaben 13 100% sehr wichtig 4 30,8% wichtig 8 61,4%
3a Aktualität
weniger wichtig 1 7,7%
Anhang B: Angaben der Anwendergruppen XXII
Frage Merkmal Antwort Anzahl Nennungen Prozentual unwichtig 0 0,0%
keine Angaben 0 0,0% Vortag 11 84,6% Vorwoche 2 15,4% Vormonat 0 0,0% Voriges Quartal 0 0,0% Vorjahr 0 0,0%
3b Wie aktuell sollten die Daten sein?
keine Angaben 0 0,0% sehr wichtig 5 38,5% wichtig 6 46,1% weniger wichtig 2 15,4% unwichtig 0 0,0%
4a Historisierung
keine Angaben 0 0,0% 1 Jahr 5 38,5% 2 Jahre 6 46,1% 3 Jahre 2 15,4%
Alle Daten seit Pro-grammstart 0 0,0%
4b Über welchen Zeitraum sollen Daten historisiert vorgehalten werden?
keine Angaben 0 0,0% sehr wichtig 3 23,1% wichtig 6 46,1% weniger wichtig 0 0,0% unwichtig 0 0,0%
5a Systemverfügbarkeit
keine Angaben 4 30,8% sehr wichtig 3 23,1% wichtig 6 46,1% weniger wichtig 0 0,0% unwichtig 0 0,0%
5b Kurze Laufzeit
keine Angaben 4 30,8% Ja 2 15,4% Nein 7 53,8% 5d
Zugriff auf alle Daten möglich?
Keine Angaben 4 30,8% sehr gut 3 23,1% gut 8 61,5% befriedigend 1 7,7% ausreichend 1 7,7% mangelhaft 0 0,0%
6a Nutzen der Daten
keine Angaben 0 0,0% sehr gut 11 84,6% gut 1 7,7% befriedigend 0 0,0% ausreichend 0 0,0% mangelhaft 1 7,7%
7 Darstellung
keine Angaben 0 0,0% sehr gut 1 7,7% gut 2 15,4%
8a Relevanz
befriedigend 1 7,7%
Anhang B: Angaben der Anwendergruppen XXIII
Frage Merkmal Antwort Anzahl Nennungen Prozentual ausreichend 0 0,0% mangelhaft 1 7,7%
keine Angaben 8 61,5%
Angaben in den Freitextfeldern:
Frage Antworten 1b Widersprüche der Daten bei den verschiedenen Analysetools 2e -
0,1s (sonst werde ich unruhig => nicht zu früh lachen! Dies sind immerhin mehr als x Milli-arden (!) CPU-Takte 3 Minuten 30 min Komplexe Abfragen dauern mir immer zu lange! 15 Min
5c
Bei vielen Abfragen wären Antwortzeiten unter 1 Minute schön - da ich nur Daten aus Log-files abfrage, kann ich das auch nur für diesen Bereich sagen.
6b lange Reaktionszeiten auf sich ändernde oder neue Anforderungen (Ressourcenmangel) Es ist für mich ohne Mithilfe nicht möglich, weitere Tabellen/Felder zu integrieren
8b Nicht alle Informationen, die wir in Analysen einbauen, stehen dem DWH zur Verfügung (Datenschutz!)
Die Daten müssen stets 100% mit den Daten aus dem Produktionssystem übereinstimmen (abgesehen vom Zeitverzug bei der Spiegelung der Daten von Produktion nach DWH.); Es müssen alle wesentlichen Datenfelder enthalten sein, sonst können Abfragen nicht im DWH , sondern nur störend in Produktion ausgeführt werden. Allg. LP QA Definitionen; keinen Widersprüche Die derzeit gelieferte Qualität ist für mich gut. Sie sollten aktuell, korrekt und vollständig sein.
Daten sollen valide bzw. validiert sein, so dass ohne Bedenken kommuniziert werden kön-nen. Daten sollten zu den vereinbarten Terminen zur Verfügung stehen. Den höchsten, da Daten auch vom Management benutzt werden.
Konsistent (Widerspruchsfrei), Transparenz, Aktuell schnell an neue Ansprüche anpassbar, rechtzeitig und zeitnah zum Stichtag einer Auswertung im Zugriff, klare Definition von Begrifflichkeiten - Glossar! Kenntnis über Reports, die Stammdaten betreffen, jedoch nicht zwangsweise aus unserer Abteilung angefordert wurden. So kann verhindert werden, dass Reports aus unserer Abteilung im Widerspruch zu anderen Reports stehen. Manchmal führen nur kleine Definitionsunterschiede zu großen Widersprüchen, die Auswirkungen haben.
9
Besonders wichtig ist mir die Datenkonsistenz, d. h., dass die verschiedenen Reporting-Tools die gleiche Datenbasis zugrunde legen, dass sich Zahlen nicht im Nachhinein verändern können. Im Prinzip müsste bei gleicher Datenabfrage mit jedem Reporting-Tool das gleich Datenergebnis zustande kommen. Sicherlich gibt es Unterschiede in der Betrachtung der Daten. Da in der Vergangenheit einige Ungereimtheiten aufgetreten sind, werden Reports derzeit doppelt und dreifach überprüft und abgeglichen, bevor diese unser Team verlassen. Dies ist eine sehr zeitraubende Angelegenheit.
10 Zu Frage 5d: Ich habe nicht auf alle Daten Zugriff.
Anhang B: Angaben der Anwendergruppen XXIV
B3: Angaben der Anwendergruppe Datenanalysten
Angaben in den Auswahlfeldern:
Frage Merkmal Antwort Anzahl Nennungen Prozentual nie 0 0% selten 4 80% häufig 1 20% sehr häufig 0 0%
1a Widersprüchliche Daten
keine Angaben 0 0% nie 0 0% selten 2 40% häufig 1 20% sehr häufig 0 0%
2a Vollständige Daten
keine Angaben 2 40% nie 0 0% selten 2 40% häufig 1 20% sehr häufig 0 0%
2b Korrekte Daten
keine Angaben 2 40% nie 1 20% selten 2 40% häufig 0 0% sehr häufig 0 0%
2c Dubletten vorhanden
keine Angaben 2 40% nie 0 0% selten 0 0% häufig 0 0% sehr häufig 0 0%
2d Sonstige
keine Angaben 5 100% sehr wichtig 2 40% wichtig 2 40% weniger wichtig 1 20% unwichtig 0 0%
3a Aktualität
keine Angaben 0 0% Vortag 5 100,0% Vorwoche 0 0,0% Vormonat 0 0,0% Voriges Quartal 0 0,0% Vorjahr 0 0,0%
3b Wie aktuell sollten die Daten sein?
keine Angaben 0 0,0% sehr wichtig 2 40% wichtig 3 60% weniger wichtig 0 0%
4a Historisierung
unwichtig 0 0%
Anhang B: Angaben der Anwendergruppen XXV
Frage Merkmal Antwort Anzahl Nennungen Prozentual keine Angaben 0 0% 1 Jahr 0 0,0% 2 Jahre 0 0,0% 3 Jahre 1 20,0%
Alle Daten seit Pro-grammstart 4 80,0%
4b Über welchen Zeitraum sollen Daten historisiert vorgehalten werden?
keine Angaben 0 0,0% sehr wichtig 2 40% wichtig 2 40% weniger wichtig 0 0% unwichtig 0 0%
5a Systemverfügbarkeit
keine Angaben 1 20% sehr wichtig 1 20% wichtig 2 40% weniger wichtig 0 0% unwichtig 0 0%
5b Kurze Laufzeit
keine Angaben 2 40% Ja 3 60% Nein 1 40% 5d
Zugriff auf alle Daten möglich?
Keine Angaben 0 0% sehr gut 1 20% gut 4 80% befriedigend 0 0% ausreichend 0 0% mangelhaft 0 0%
6a Nutzen der Daten
keine Angaben 0 0% sehr gut 0 0% gut 4 80% befriedigend 0 0% ausreichend 0 0% mangelhaft 0 0%
7 Darstellung
keine Angaben 1 20% sehr gut 1 20% gut 1 20% befriedigend 0 0% ausreichend 0 0% mangelhaft 1 20%
8a Relevanz
keine Angaben 2 40%
Angaben in den Freitextfeldern:
Frage Antworten 1b Differenzen operative Systeme <--> DWH 2e -
Hängt extrem von der Abfrage ab 5c
abhängig von der Abfrage, große Abfragen max. 1h
Anhang B: Angaben der Anwendergruppen XXVI
Frage Antworten 30 min 1 Tag
6b - 8b Abfrage auf verschiedenste Schemata, komplexe übergreifende Analysen
aktueller Stand; eindeutig; konsistent aktuell und vor allem verfügbar. Wenn Tabellen nicht vorhanden sind, führt dies oft zu Verzögerungen. Zuverlässigkeit
9
Einhaltung der Geschäftsregeln 10 -
B4: Angaben der Anwendergruppe DWH-Management
Angaben in den Auswahlfeldern:
Frage Merkmal Antwort Anzahl Nennungen Prozentual nie 0 0% selten 2 50% häufig 2 50% sehr häufig 0 0%
1a Widersprüchliche Daten
keine Angaben 0 0% nie 0 0% selten 3 75% häufig 0 0% sehr häufig 0 0%
2a Unvollständige Daten
keine Angaben 1 25% nie 0 0% selten 3 75% häufig 1 25% sehr häufig 0 0%
2b Nicht korrekte Daten
keine Angaben 0 0% nie 0 0% selten 3 75% häufig 0 0% sehr häufig 0 0%
2c Dubletten vorhanden
keine Angaben 1 25% nie 0 0% selten 0 0% häufig 0 0% sehr häufig 0 0%
2d Sonstige
keine Angaben 4 100% sehr wichtig 0 0% wichtig 1 25% weniger wichtig 3 75% unwichtig 0 0%
3a Aktualität
keine Angaben 0 0% 3b Wie aktuell sollten die Vortag 1 25%
Anhang B: Angaben der Anwendergruppen XXVII
Frage Merkmal Antwort Anzahl Nennungen Prozentual Vorwoche 2 50% Vormonat 0 0% Voriges Quartal 0 0% Vorjahr 0 0%
Daten sein?
keine Angaben 1 25% sehr wichtig 0 0% wichtig 0 0% weniger wichtig 4 100% unwichtig 0 0%
4a Historisierung
keine Angaben 0 0% 1 Jahr 1 25% 2 Jahre 1 25% 3 Jahre 2 50%
Alle Daten seit Pro-grammstart 0 0%
4b Über welchen Zeitraum sollen Daten historisiert vorgehalten werden?
keine Angaben 0 0% sehr wichtig 3 75% wichtig 0 0% weniger wichtig 1 25% unwichtig 0 0%
5a Systemverfügbarkeit
keine Angaben 0 0% sehr wichtig 2 50% wichtig 0 0% weniger wichtig 2 50% unwichtig 0 0%
5b Kurze Laufzeit
keine Angaben 0 0% Ja 4 100% Nein 0 0% 5d
Zugriff auf alle Daten möglich?
Keine Angaben 0 0% sehr gut 0 0% gut 3 75% befriedigend 0 0% ausreichend 0 0% mangelhaft 0 0%
6a Nutzen der Daten
keine Angaben 1 25% sehr gut 0 0% gut 2 50% befriedigend 1 25% ausreichend 0 0% mangelhaft 0 0%
7 Darstellung
keine Angaben 1 25% sehr gut 1 25% gut 2 50% befriedigend 0 0% ausreichend 0 0% mangelhaft 0 0%
8a Relevanz
keine Angaben 1 25%
Anhang B: Angaben der Anwendergruppen XXVIII
Angaben in den Freitextfeldern:
Frage Antworten 1b - 2e -
10 Min bei sehr komplexen Abfragen einige Stunden, bei "Standardabfragen" ca. 20 Min einige Sekunden bis 30 Minuten
5c 20 Minuten 2e - 6b - 8b -
aktuell, vollständig, korrekt, eindeutig, widerspruchsfrei, gemäß den Geschäftsregeln und den Definitionen der Ladeprozessen
9 Inhaltlich korrekt, keine doppelten Datensätze, untereinander eindeutig, Gemäß definierter Ladeprozesse, Einhaltung der Geschäftsregeln
10 -