Bewertungsmethoden von Datenqualität in einem Data Warehouse

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.


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].


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].


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.


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)


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].


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.


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


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).


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.


• 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


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


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%


Laufzeit

n = 13


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


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%


n = 5


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.


0%

20%

40%

60%

80%

100%


Laufzeit

n = 5


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.


0%

20%

40%

60%

80%

100%


n = 4


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.


0%

20%

40%

60%

80%

100%


Laufzeit

n = 4


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.


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-


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].


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.


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-


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].


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.


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


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.


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.


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.


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


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-


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.


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.


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


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.


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.


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.


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-


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.


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


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


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.


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.


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.


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].


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.


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.


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.


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


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


2b Korrekte Daten


2c Dubletten vorhanden


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?


5a Systemverfügbarkeit


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


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


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%


keine Angaben 1 7,7% nie 2 15,4% selten 6 46,2% häufig 2 15,4% sehr häufig 0 0,0%



2b Korrekte Daten



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%


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%





5b Kurze Laufzeit

keine Angaben 4 30,8% Ja 2 15,4% Nein 7 53,8% 5d


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%


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







2b Korrekte Daten




2d Sonstige


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%


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%


keine Angaben 0 0,0% sehr wichtig 2 40% wichtig 2 40% weniger wichtig 0 0% unwichtig 0 0%



5b Kurze Laufzeit




6a Nutzen der Daten


7 Darstellung


8a Relevanz

keine Angaben 2 40%


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





2a Unvollständige Daten


2b Nicht korrekte Daten




2d Sonstige


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?


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%





5b Kurze Laufzeit




6a Nutzen der Daten


7 Darstellung


8a Relevanz

keine Angaben 1 25%

Anhang B: Angaben der Anwendergruppen XXVIII


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 -

Documents

Bewertungsmethoden von Datenqualität in einem Data Warehouse