Testen von Data Warehouse und Business Intelligence Systemencleve/vorl/projects/da/12-Ma-Hegel... · 2019. 9. 19. · wendbarkeit für Data Warehouse und Business Intelligence Systeme

Hochschule Wismar Fakultät für Wirtschaftswissenschaften

Testen von Data Warehouse und Business Intelligence Systemen

Thesis zur Erlangung des Grades

Master of Science (M.Sc.)

Verfasser: Renke Hegeler

Studiengang Wirtschaftsinformatik

Betreuer:

Prof. Dr. Jürgen Cleve

Prof. Dr. Jan Helmke

Hannover, 20. Februar 2012

Abstract

Abstract In der Literatur finden sich viele Abhandlungen zu den Themenbereichen „Data Wa-

rehouse und Business Intelligence“ sowie „Testen von Software“. Die Kombination

aus beiden Themen wurde bisher jedoch nur sehr spärlich betrachtet. Ralph Kimball,

einer der meist zitierten Autoren zum Thema „Data Warehouse“, beschreibt in seinen

Büchern auf hunderten Seiten seine Modelle und Konzepte für ein Data Warehouse,

während das Testen nur am Rande erwähnt wird.

Diese Master-Thesis widmet sich daher explizit dem Testen von Data Warehouse

und Business Intelligence Systemen. Dabei wird analysiert, wie sich diese Systeme

von klassischer Software unterscheiden und anhand von Beispielen aus der Praxis

gezeigt, welche Besonderheiten zu beachten sind und was für Fehlersituationen bei

der Entwicklung auftreten können. Auf Basis der etablierten Softwareprüftechniken

wird dann für die jeweiligen Situationen untersucht, welche Techniken sich anwen-

den lassen. Auch im Betrieb gibt es oftmals Komplikationen und es treten Fehlersitu-

ationen auf. Deshalb werden Methoden beschrieben, wie mit diesen alltäglichen

Problemstellungen umgegangen werden kann. Da effektive Tests nur mithilfe von

Testwerkzeugen durchgeführt werden können, werden zusätzlich einige Werkzeuge

vorgestellt.

Inhaltsverzeichnis

Inhaltsverzeichnis 1. Einleitung ............................................................................................................... 1

1.1. Vorstellung des Themas und der Zielsetzung ................................................... 2

1.2. Aufbau der Arbeit .............................................................................................. 2

1.3. Verwandte Arbeiten .......................................................................................... 3

2. Umfeld der Arbeit .................................................................................................. 5

2.1. Data Warehouse und Business Intelligence Systeme....................................... 6

2.1.1. Definitionen ................................................................................................ 6

2.1.2. Ziele und Notwendigkeiten ......................................................................... 8

2.1.3. Architektur und Komponenten .................................................................. 10

2.1.3.1 Quellsysteme ...................................................................................... 10

2.1.3.2 Analysesysteme.................................................................................. 11

2.1.3.3 OLAP-Systeme ................................................................................... 13

2.1.3.4 Data Warehouse ................................................................................. 16

2.1.3.5 Datenintegration ................................................................................. 17

2.1.3.6 Automatisierungssysteme ................................................................... 21

2.1.4. Business Intelligence System Big Picture ................................................ 22

2.2. Testen von Software ....................................................................................... 23

2.2.1. Softwareentwicklungsprozess .................................................................. 24

2.2.2. Dynamische Prüftechniken ....................................................................... 26

2.2.2.1 Funktionsorientierte Tests .................................................................. 27

2.2.2.2 Strukturorientierte Tests ..................................................................... 30

2.2.2.3 Diversifizierende Tests ....................................................................... 33

2.2.3. Statische Prüftechniken ............................................................................ 33

2.2.3.1 Stilanalyse .......................................................................................... 33

2.2.3.2 Visuelle Hilfsmittel ............................................................................... 34

2.2.3.3 Anomalieanalyse ................................................................................ 35

2.2.3.4 Slicing ................................................................................................. 37

2.2.3.5 Review ................................................................................................ 37

2.2.3.6 Metriken .............................................................................................. 37

2.2.3.7 Verifizierende Analysen ...................................................................... 38

2.2.4. Testen von Datenbanken ......................................................................... 38

2.2.5. Testen nichtfunktionaler Anforderungen ................................................... 39

Inhaltsverzeichnis

3. Testen während der Entwicklung ...................................................................... 41

3.1. Allgemeine Besonderheiten bei der Entwicklung ............................................ 42

3.1.1. Softwareentwicklungsprozess .................................................................. 42

3.1.2. Tätigkeiten eines Entwicklers ................................................................... 43

3.1.3. Unterschiede beim Testen ....................................................................... 44

3.2. Multidimensionale Modellierung ...................................................................... 44

3.2.1. Besonderheiten der multidimensionalen Modellierung ............................. 44

3.2.2. Prüftechniken für die multidimensionale Modellierung ............................. 45

3.3. Datenintegration ............................................................................................. 50

3.3.1. Besonderheiten der Datenintegration ....................................................... 50

3.3.1.1 Funktionale Besonderheiten der Datenintegration .............................. 50

3.3.1.2 Nichtfunktionale Besonderheiten der Datenintegration ....................... 54

3.3.2. Prüftechniken für die Datenintegration ..................................................... 55

3.3.2.1 Funktionale Prüftechniken für die Datenintegration ............................ 55

3.3.2.2 Nichtfunktionale Prüftechniken für die Datenintegration ..................... 65

3.4. Data Warehouse ............................................................................................. 66

3.4.1. Besonderheiten eines Data Warehouses ................................................. 66

3.4.1.1 Funktionale Besonderheiten eines Data Warehouses ........................ 66

3.4.1.2 Nichtfunktionale Besonderheiten eines Data Warehouses ................. 67

3.4.2. Prüftechniken für ein Data Warehouse..................................................... 68

3.4.2.1 Funktionale Prüftechniken für ein Data Warehouse............................ 68

3.4.2.2 Nichtfunktionale Prüftechniken für ein Data Warehouse ..................... 70

3.5. OLAP-System ................................................................................................. 71

3.5.1. Besonderheiten eines OLAP-Systems ..................................................... 71

3.5.1.1 Funktionale Besonderheiten eines OLAP-Systems ............................ 71

3.5.1.2 Nichtfunktionale Besonderheiten eines OLAP-Systems ..................... 74

3.5.2. Prüftechniken für ein OLAP-System ......................................................... 75

3.5.2.1 Funktionale Prüftechniken für ein OLAP-System ................................ 75

3.5.2.2 Nichtfunktionale Prüftechniken für ein OLAP-System ......................... 81

3.6. Reporting Front-End ....................................................................................... 82

3.6.1. Besonderheiten eines Reporting Front-Ends ........................................... 83

3.6.1.1 Nichtfunktionale Besonderheiten eines Reporting Front-Ends ........... 83

3.6.2. Prüftechniken für ein Reporting Front-End ............................................... 85

3.6.2.1 Nichtfunktionale Prüftechniken für ein Reporting Front-End ............... 85

Inhaltsverzeichnis

3.7. Automatisierungssystem ................................................................................. 87

3.7.1. Besonderheiten eines Automatisierungssystems ..................................... 88

3.7.1.1 Funktionale Besonderheiten eines Automatisierungssystems ............ 88

3.7.1.2 Nichtfunktionale Besonderheiten eines Automatisierungssystems ..... 89

3.7.2. Prüftechniken für ein Automatisierungssystem ........................................ 89

3.7.2.1 Funktionale Prüftechniken für ein Automatisierungssystem ............... 89

3.7.2.2 Nichtfunktionale Prüftechniken für ein Automatisierungssystem ........ 90

3.8. Bewertung ....................................................................................................... 91

4. Testen während des Betriebes ........................................................................... 97

4.1. Tätigkeiten während des Betriebes ................................................................. 98

4.1.1. Betrieb ...................................................................................................... 98

4.1.2. Anpassungen ........................................................................................... 98

4.2. Fehlersituationen während des Betriebes ....................................................... 99

4.2.1. Falsche Datenlieferungen ........................................................................ 99

4.2.2. Unachtsamkeit ....................................................................................... 101

4.2.3. Infrastruktur ............................................................................................ 101

4.3. Korrektheit der Daten .................................................................................... 102

4.3.1. Validierung von Kennzahlen ................................................................... 103

4.3.2. Quality Gates ......................................................................................... 104

5. Testinfrastruktur ................................................................................................ 106

5.1. Testwerkzeuge ............................................................................................. 107

5.2. Testsystem, Testteam und Testdaten ........................................................... 112

6. Konklusion ......................................................................................................... 114

Anhang A: Business Intelligence System in der Praxis..................................... 116

Anhang B: ADAPT-Notation ................................................................................. 117

Abkürzungsverzeichnis ............................................................................................. i Abbildungsverzeichnis ............................................................................................. ii Tabellenverzeichnis ................................................................................................. iv

Listingverzeichnis ..................................................................................................... v

Formelverzeichnis .................................................................................................... vi Literaturverzeichnis ................................................................................................ vii

Kapitel 1 - Einleitung

1. Einleitung

1 Kapitel 1

Einleitung

In diesem Kapitel werden das Thema und die Zielsetzung der Master-Thesis vorge-

stellt, ein Überblick zu verwandten Arbeiten gegeben sowie die Vorgehensweise und

der Aufbau der Thesis beschrieben.

Übersicht 1. Einleitung ............................................................................................................... 1

1.1. Vorstellung des Themas und der Zielsetzung ................................................... 2

1.2. Aufbau der Arbeit .............................................................................................. 2

1.3. Verwandte Arbeiten .......................................................................................... 3


1.1. Vorstellung des Themas und der Zielsetzung Die Literaturrecherche zu den Stichpunkten „Data Warehouse System + Testen“ oder

„Business Intelligence System + Testen“ liefert eine geringe Anzahl an direkten Tref-

fern. Die Suche nach den einzelnen Stichpunkten hingegen zu einer erheblich größe-

ren Trefferanzahl1. Es gibt entweder Fachliteratur entweder zu dem Themenbereich

„Data Warehouse“ / „Business Intelligence“ oder für den Themenbereich „Testen von

Software“. Zu der Kombination der beiden Themenbereiche gibt es keine spezielle

Literatur. Es lassen sich lediglich einige wissenschaftliche Arbeiten sowie kurze Ab-

handlungen zu der Thematik finden, von denen einige im Abschnitt 1.3 näher erläu-

tert werden.

Diese Arbeit widmet sich explizit dem Testen von Data Warehouse und Business

Intelligence Systemen. Dabei werden die Besonderheiten und typische Fehlersituati-

onen dieser Systeme beschrieben und darauf basierend analysiert, was demnach

getestet werden muss. Da es sich bei Data Warehouse und Business Intelligence

Systemen um Software handelt, sollen die etablierten Prüftechniken auf ihre An-

wendbarkeit für Data Warehouse und Business Intelligence Systeme untersucht

werden.

Um den Rahmen dieser Arbeit in Grenzen zu halten, werden die Teilbereiche „Data

Mining“ und „formaler Beweis“ nur genannt und nicht weiter vertieft.

1.2. Aufbau der Arbeit Diese Arbeit ist in fünf Kapitel eingeteilt. Im ersten Kapitel werden einleitend das

Thema vorgestellt sowie die Rahmenbedingungen festgelegt. Das zweite Kapitel be-

1 http://scholar.google.de/scholar?hl=de&q=data+warehouse+system+testing - 66.000 Treffer

http://scholar.google.de/scholar?hl=de&q=business+intelligence+system+testing - 619.000 Treffer

http://scholar.google.de/scholar?hl=de&q=data+warehouse+system - 238.000 Treffer

http://scholar.google.de/scholar?hl=de&q=business+intelligence+system - 1.840.000 Treffer

http://scholar.google.de/scholar?hl=de&q=software+testing - 3.230.000 Treffer

(Abgerufen 12.12.2011)


schreibt die für das Thema wichtigen theoretischen Grundlagen, also die Bereiche

Data Warehouse und Business Intelligence Systeme, und das Testen von Software.

Auf den Grundlagen aufbauend wird im dritten Kapitel analysiert, welche der Prüf-

techniken bei der Entwicklung von Data Warehouse und Business Intelligence Sys-

temen anwendbar sind. Dazu werden zunächst die Unterschiede zu der klassischen

Softwareentwicklung gezeigt. Anhand von typischen Fehlersituationen aus der Praxis

wird dann anhand von Beispielen gezeigt, welche der etablierten Softwareprüftechni-

ken für die beschriebenen Fehlersituationen verwendet werden können. Abschlie-

ßend folgt eine Bewertung, inwieweit die vorgestellten Prüftechniken praxistauglich

sind. Im vierten Kapitel wird beschrieben, welche Fehlersituationen im alltäglichen

Betrieb eines Data Warehouse uns Business Intelligence Systems auftreten können

und mit welchen Techniken den Fehlern entgegengewirkt werden kann.

Das fünfte Kapitel behandelt den Bereich Testinfrastruktur und stellt einige verfügba-

re Testwerkzeuge vor. Die Arbeit schließt im sechsten Kapitel mit einer Konklusion

ab.

1.3. Verwandte Arbeiten Die „Literatur-Klassiker“ zum Thema Business Intelligence und Data Warehouse Sys-

teme von Inmon [Inm05] sowie Kimball et al. [Kim02 und Kim04] beschreiben Tech-

niken und Vorgehensmodelle für den Aufbau solcher Systeme. Kimball et al. erwäh-

nen das Testen dabei nur am Rande. Innerhalb der Kapitel finden sich gelegentlich

Aussagen nach dem Motto „ist zu testen“. Inmon hingegen schreibt sogar:

„Testing in the data warehouse is not the same level of importance as in the

operational transaction environment. But occasionally there is a need for test-

ing, especially when new types of data are being loaded and when there are

large volumes of data.“ [Inm05, S. 481]

Rainardi [Rai08] ist einer der wenigen, der dem Testen in seinem Buch ein eigenes

Kapitel widmet. Er beschränkt sich allerdings darauf, was zu testen ist und geht nicht

auf Prüftechniken ein:

„I will not discuss [...] testing methodology. [...] Instead, I will focus on the con-

tent of those tests specific to data warehousing.“ [Rai08, S. 477]


Er unterscheidet dabei folgende fünf Testbereiche:

„ETL testing: In the ETL testing stage, you make sure that appropriate changes

in the source system are captured properly and propagated correctly into the

data warehouse. [...]

Functional testing: In the functional testing stage, you make sure all the busi-

ness requirements are fulfilled.

Performance testing: In the performance testing stage, you verify that the data

warehouse can handle the required load and volume.

Security testing: In the security testing stage, you make sure only the users who

should be able to access the resources can actually access them.

User acceptance testing: In the user acceptance testing stage, the end users

use the data warehouse system to verify the usability.

End-to-end testing: In the end-to-end testing stage, you let the system run for a

few days to simulate production situations.“ [Rai08, S. 477]

Einige weitere Abhandlungen zum Testen finden sich in wissenschaftlichen Arbeiten

und Whitepapers. [Bha07], [Bra07], [Coo02], [Inf10], [Moo08] und [The07] behandeln

dabei aber auch lediglich, was zu testen ist. Des Weiteren sind sie bei Ihrer Betrach-

tung sehr fokussiert auf die Datenintegrationsprozesse. In [Kam10] wird zusätzlich

etwas detaillierter auf die zu prüfenden Komponenten eingegangen. So nennen die

Autoren neben den Datenintegrationsprozessen auch explizit das Testen der mul-

tidimensionalen Strukturen sowie der Berichte.

Golfarelli und Rizzi beschreiben in ihren Arbeiten [Gol09 und Gol11] ebenfalls, was

zu überprüfen ist und stellen zusätzlich Vorgehensmodelle zum Testen auf. Einen

besonderen Schwerpunkt haben sie auf das Testen der multidimensionalen Modellie-

rung gelegt.

[Sha07] beschreibt zwei Szenarien für die Testautomatisation für Datenintegrations-

prozesse. [Sun07] geht weniger auf das Testen an sich ein, sondern mehr auf die

allgemeinen Missstände. Genannt werden die fehlende Auswahl an speziellen Test-

werkzeugen sowie die mangelnden Qualifikationen der Business Intelligence Ent-

wickler im Fachbereich Testen und umgekehrt der Tester im Fachbereich Business

Intelligence.

Kapitel 2 - Umfeld der Arbeit

2. Umfeld der Arbeit

2 Kapitel 2

Umfeld der Arbeit

In diesem Kapitel werden die theoretischen Grundlagen zu der Master-Thesis vorge-

stellt. Dazu werden als erstes der Themenbereich Data Warehouse und Business

Intelligence und anschließend der Themenbereich Testen von Software beschrieben.

Übersicht 2. Umfeld der Arbeit .................................................................................................. 5

2.1. Data Warehouse und Business Intelligence Systeme....................................... 6

2.2. Testen von Software ....................................................................................... 23


2.1. Data Warehouse und Business Intelligence Systeme Damit Führungskräfte eines Unternehmens strategische und operative Entscheidun-

gen treffen können, benötigen sie einen Überblick über ihr Geschäft. Sogenannte

entscheidungsunterstützende Systeme2 haben sich daher schon seit der Einführung

der elektronischen Datenverarbeitung etabliert, um den Entscheidungsträgern alle

relevanten Informationen zur Verfügung zu stellen. [vgl. Koe09, S. 1]

Wie in der IT-Branche üblich, haben sich im Laufe der Zeit eine Vielzahl von Begrif-

fen und Abkürzungen im Zusammenhang mit entscheidungsunterstützenden Syste-

men gebildet. In den letzten Jahren haben sich besonders die Begriffe Data Wa-

rehouse (DW) und Business Intelligence (BI) im Fachjargon der Informatik durchge-

setzt. Dabei ist zu beachten, dass in der Literatur verschiedene Definitionen und Be-

schreibungen für die beiden Bezeichnungen zu finden sind. Kimball et al. schreiben

dazu passend:

„To this day, you can ask ten experts to define a data warehouse, and you are

likely to get ten different responses.“ [Kim04, S. 23]

Für diese Arbeit werden im Folgenden für die beiden Begriffe zwei Definitionen her-

angezogen. Danach werden Ziele und Notwendigkeiten von Data Warehouse und

Business Intelligence Systemen erläutert sowie deren Architektur und Komponenten

beschrieben.

2.1.1. Definitionen

Eine Definition für den Begriff Data Warehouse System (DWS) liefern Kimball et al.:

„A data warehouse [..] system [...] extracts, cleans, conforms, and delivers

source data into a dimensional data store and then supports [...] querying and

analysis for the purpose of decision making.“ [Kim04, S. 23]

Zusammengefasst extrahiert ein DWS also Daten aus verschiedenen Quellsyste-

men, integriert sie in einem speziellen Datenspeicher und stellt sie zu Abfrage- und

Analysezwecken bereit. Der Datenspeicher selbst wird dabei häufig als DW bezeich-

2 Auch engl.: Decision Support Systems (DSS)


net. Das gesamte DWS besteht zusätzlich noch aus einer Datenintegrationskompo-

nente. Der Aspekt der Dimensionalität wird im Abschnitt 2.1.3 weiter erläutert.

Abbildung 2-1: Zusammenhang von BIS und DWS [Eigene Darstellung]

Kemper et al. gehen ebenfalls sehr ausführlich auf die Problematik der Definitions-

vielfalt für den Begriff Business Intelligence ein und es werden unterschiedliche Defi-

nitionen und Sichtweisen genannt. Für diese Arbeit wird die folgende Variante über-

nommen:

„Unter Business Intelligence [...] werden alle direkt und indirekt für die Entschei-

dungsunterstützung eingesetzten Anwendungen verstanden.“ [Kem10, S. 4]

Das Business Intelligence System (BIS) ist also ein abstrakter Oberbegriff, der so-

wohl das DWS als auch Analysesysteme und weitere Randsysteme (beispielsweise


eine Job-Steuerung) umfasst. Die Abbildung 2-1 zeigt den groben Zusammenhang

der beiden Begriffe. Da das DWS (die Datenbereitstellung) innerhalb des gesamten

BIS eine sehr wichtige und zentrale Rolle einnimmt, ist eine gesonderte Benennung

gerechtfertigt.

2.1.2. Ziele und Notwendigkeiten

Gerade beim DW ergibt sich die Frage nach der technischen Notwendigkeit. Schließ-

lich ist es, salopp gesagt, nur eine Replizierung von Daten, die ein Unternehmen in

seinen Datenverarbeitungssystemen generiert und dort auch speichert.

Grundsätzlich ergeben sich zwei unterschiedliche Sichtweisen auf die Daten: opera-

tiv und dispositiv. Die operativen Daten haben einen direkten Bezug zu den Tätigkei-

ten der Leistungserbringung des Unternehmens. Dispositive Daten hingegen haben

einen analytischen Charakter und dienen der Leitung und Steuerung des Unterneh-

mens. [vgl. Kem10, S. 13] In der Tabelle 2-1 sind die wichtigsten Unterschiede der

beiden Sichtweisen dargestellt. Am Beispiel eines Versicherungsunternehmens las-

sen sich die Unterschiede verdeutlichen:

• Operative Daten

o Detaillierte Informationen zu den einzelnen Versicherungsverträgen

o Datenänderungen rund um die Uhr durch das Onlineportal

o Speicherung der Verträge in zwei unterschiedlichen Systemen, jeweils

ein eigenes für Kraftfahrt- und Lebensversicherungen

• Dispositive Daten

o Summierung der Umsätze und Profite pro Kundengruppe

o Darstellung der zeitlichen Veränderungen zum Vorjahr

o Gegenüberstellung der Produktsparten Kraftfahrt und Haftpflicht

Eine direkt auf den operativen Daten beruhende Auswertung erfüllt somit nicht die

dispositiven Anforderungen. Besonders die heterogene Systemlandschaft erschwert

das Gegenüberstellen von Informationen. Zusätzlich verdeutlichen die Aspekte „Ab-

fragen“ und „Transaktionen“ in der Tabelle, dass Analysen direkt auf operativen Da-

ten gefährlich sind: Langläufige und ressourcenintensive Abfragen können das ge-

samte operative System blockieren und das Tagesgeschäft beeinträchtigen. [vgl.

Koe09, S. 14]


Operative Daten Dispositive Daten Ziel Leistungserbringung Entscheidungsunterstützung

Anwender viele Sachbearbeiter wenige Analysten

Detaillierung feingranulare Geschäftsprozesse

verdichtete (aggregierte) Informationen

Zeitbezug aktuell (zeitpunktbezogen)

historisch (zeitraumbezogen)

Implementierung heterogen (historisch gewachsen)

homogen (vereinheitlicht)

Aktualisierung kontinuierlich in Echtzeit

turnusmäßige Fortschreibung

Abfragen einfach strukturiert rechenintensiv

Transaktionen viele kurze wenige lange

Tabelle 2-1: Operative vs. dispositive Daten [vgl. Hin02, S. 13]

In der Regel sind es unternehmerische bzw. wirtschaftliche Gründe, die einen Betrieb

dazu veranlassen, ein BIS zur Entscheidungsunterstützung einzuführen. Typische

Interessenten für Auswertungen innerhalb des Unternehmens sind zum Beispiel die

Vertriebsabteilung, die für eine effektive Steuerung des Außendienstes Umsatz- und

Renditeinformationen zu den verschiedenen Absatzgebieten benötigt, oder die Mar-

ketingabteilung, die anhand von Informationen zu den verschiedenen Kundengrup-

pen gezielte Werbemaßnahmen durchführt.

Mittlerweile existieren allerdings auch einige gesetzliche Regelungen, die ein BIS

notwendig machen. [vgl. Kem10, S. 6] Durch das Gesetz zur Kontrolle und Transpa-

renz im Unternehmensbereich (KonTraG) wurde im Jahr 1998 das Aktiengesetz

(AktG) um Aspekte der Risikokontrolle erweitert:

„[Ein Unternehmen hat] geeignete Maßnahmen zu treffen, insbesondere ein

Überwachungssystem einzurichten, damit den Fortbestand der Gesellschaft ge-

fährdende Entwicklungen früh erkannt werden kann.“ [AktG, § 91 Abs. 2]

Spätestens durch dieses Gesetz ist ein BIS für ein Unternehmen nahezu unumgäng-

lich.


2.1.3. Architektur und Komponenten

Neben den unterschiedlichen Definitionsansätzen existieren in der Literatur auch

entsprechend verschiedene Architekturansätze für DW und BI Systeme. In dieser

Arbeit werden neben den Definitionen auch die Architekturansätze von Kimball et al.

sowie Kemper et al. übernommen.

2.1.3.1 Quellsysteme Als Quellsysteme werden alle Systeme bezeichnet, deren Daten im BIS analysiert

und ausgewertet werden. Bei diesen Systemen handelt es sich in der Regel um fir-

meninterne Anwendungen, die im eigenen Rechenzentrum laufen. Es ist aber auch

möglich, dass ein Unternehmen externe Daten heranzieht, beispielsweise wenn ein

Teil des Tagesgeschäfts durch einen Dienstleister erbracht wird oder wenn allgemei-

ne Marktdaten (Prognosen, Umfragen etc.) abgerufen werden.

Die (internen) operativen Anwendungen für das Tagesgeschäft werden oft als Onli-

ne-Transaction-Processing (OLTP) Anwendungen bezeichnet. Viele Benutzer lesen

und bearbeiten gleichzeitig (in Echtzeit) den gleichen Datenbestand. Daneben besit-

zen Unternehmen auch autarke Anwendungen, die im Hintergrund ohne Benutzerin-

teraktionen laufen. In einem Versicherungsunternehmen sind das etwa die Antrags-

prüfung oder die Rechnungsschreibung.

Abbildung 2-2: Heterogenität von Quellsystemen [Eigene Darstellung]

Es wird ersichtlich, dass die Arten und Strukturen der Quellsysteme einen starken

Hang zur Heterogenität aufweisen (Abbildung 2-2). [vgl. Kem10, S. 28] Bei Versiche-


rungsunternehmen tritt diese Heterogenität besonders oft auf: Die OLTP Anwendun-

gen stammen dort zum Teil noch aus den 1960er oder 1970er Jahren. Diese Alt3-

Anwendungen laufen samt Datenhaltung auf einem Großrechner. Seit den 1990er

Jahren existieren zusätzlich Client-Server Anwendungen, die objektorientiert imple-

mentiert wurden und deren Daten in einem relationalen Datenbanksystem liegen. Im

administrativen Bereich wird Standardsoftware wie SAP eingesetzt. Mit externen

Dienstleistern und Branchen-Verbänden wird über das Internet und mittels einfacher

Text-Dateien oder Webservices kommuniziert. Das DWS steht also bei der Datenin-

tegration der verschiedenen Quellen vor einer großen technischen Herausforderung.

Um den Prozess der Datenintegration der dispositiven Daten als auch dessen Spei-

cherung besser verstehen zu können, ist es sinnvoll zunächst das Ziel der Daten zu

betrachten: die Analyse Anwendungen.

2.1.3.2 Analysesysteme Analysesysteme dienen der Darstellung von Daten über ein Reporting Front-End.

Das Ziel ist es, die Daten so darzustellen und aufzubereiten, dass daraus verwend-

bare Informationen abgeleitet werden können.

Spreadsheet Reporting Die einfachste Variante der Analyse ist das sogenannte Spreadsheet Reporting. Da-

bei werden die zu analysierenden Daten auf einem klassischen Tabellenblatt, beste-

hend aus Zeilen und Spalten, dargestellt. Das wohl bekannteste und am meisten

verbreitete Reporting Front-End ist Microsoft Excel (Abbildung 2-3). [vgl. Kem10, S.

102] Mit den von Excel bereitgestellten Funktionen können die wichtigsten Kennzah-

len, wie Summen oder Durchschnittswerte, ermittelt werden.

Die Daten für die Auswertungen werden dabei in der Regel von einer Informatikabtei-

lung geliefert, die beispielsweise mittels SQL eine Datei für einen Import in Excel be-

reitstellt. [vgl. Kim02, S. 11] Das Listing 2-1 stellt einen solchen Abzug exemplarisch

dar. Soll die Sichtweise verändert werden, ist auch eine Anpassung der SQL-

Statements nötig. 3 Auch engl.: Legacy


Abbildung 2-3: Spreadsheet Reporting (Excel)

[Eigene Darstellung]

01 02 03 04

SELECT PRODUKT, MONAT, SUM(BEITRAG) FROM VERKAUFSZAHLEN WHERE PRODUKT IN ('Kfz', 'Haftpflicht') GROUP BY PRODUKT, MONAT;

Listing 2-1: SQL für Spreadsheet Reporting [Eigene Darstellung]

Die wesentlichen Nachteile des Spreadsheet Reportings sind Redundanzen und

Vervielfältigungen von Daten in ähnlichen Berichten, eine mangelnde Mehrbenutzer-

fähigkeit sowie die Inflexibilität bei der Sicht auf die Daten durch statische SQL-

Statements.

Data Mining Eine besondere Analysetechnik stellt das sogenannte Data Mining dar. Hierbei steht

nicht das Berichten von vorhandenen Informationen im Vordergrund. Stattdessen

wird innerhalb der Daten gezielt nach Mustern und Zusammenhängen gesucht und

somit neue Erkenntnisse abgeleitet. [vgl. Cle10, S. 11] Da das Data Mining ein sehr

spezielles und eigenständiges Verfahren ist, wird es in dieser Arbeit nicht weiter be-

trachtet.


2.1.3.3 OLAP-Systeme Eine modernere Analysetechnik ist das sogenannte Online-Analytical-Processing

(OLAP). Das Ziel von OLAP ist es, die Nachteile beim Spreadsheet Reporting zu be-

seitigen. Ein Analyst soll die Möglichkeit erhalten, seine Auswertungen „live“ bzw.

„online“ anpassen zu können, um je nach geschäftlicher Anforderung verschiedene

Sichten auf die Daten zu erhalten. [vgl. Kem10, S. 93ff] In diesem Zuge hat sich auch

der bereits im Abschnitt 2.1.1 erwähnte Begriff der multidimensionalen Analyse

durchgesetzt.

Abbildung 2-4: OLAP-Würfel [Eigene Darstellung]

Im allgemeinen Sprachgebrauch wird der so entstehende multidimensionale Daten-

raum auch als OLAP-Würfel4 bezeichnet (Abbildung 2-4), weil sich eine dreidimensi-

onale Betrachtung plastisch am besten darstellen lässt. Ein solcher Würfel besteht

immer aus Dimensionen (Kanten des Würfels) und Kennzahlen5 (Werte an den Ko-

ordinaten innerhalb des Würfels). Kennzahlen sind die betriebsbedingten Größen wie

etwa Umsatz, Kosten oder Stückzahlen. Dimensionen hingegen haben einen be-

schreibenden Charakter für die Kennzahlen, z.B. die Zeit, der Kunde und das Pro- 4 Auch engl.: Cube 5 Auch alternativ: Fakten


dukt für einen Umsatz. Der Würfel der Abbildung 2-4 zeigt exemplarisch, dass im

Jahr 2011 in Norddeutschland für die Sparte Lebensversicherung (Dimensionen Zeit,

Region und Sparte) ein Umsatz von 78 Mio. Euro (Kennzahl) erzielt wurde.

Die Elemente einer Dimension lassen sich aufgrund funktionaler Abhängigkeiten oft

in Hierarchien gruppieren (Abbildung 2-5). So können beispielsweise in der Zeitdi-

mension die Monate zu Quartalen oder in der Produktdimension Produkte zu Pro-

duktgruppen zusammengefasst werden. Entlang der Dimensionshierarchie lassen

sich die Kennzahlen dann konsolidieren (in der Regel Summenbildung). [vgl. Koe09,

S. 9]

Abbildung 2-5: Zeit-Hierarchie [Eigene Darstellung]

Ein Würfel kann aus verschiedenen Perspektiven analysiert werden (Abbildung 2-6).

Pivoting bezeichnet das Drehen bzw. Kippen des gesamten Würfels, indem die Ach-

sen (Dimensionen) vertauscht werden. Slice bzw. Dice ist die Einschränkung der

Sicht auf Teilbereiche, indem nicht relevante Informationen ausgeblendet werden.

Ein Slice definiert die Einschränkung auf eine einzige Dimension, ein Dice hingegen

auf mehrere Dimensionen. Das Navigieren entlang der Dimensionshierarchien wird

auch Roll Up bzw. Drill Down genannt. Ein Roll Up konsolidiert die Kennzahlen auf

eine höhere (allgemeinere) Ebene der Dimension, beispielsweise von einzelnen Ver-

sicherungssparten auf eine Gesamtsicht. Ein Drill Down ist die Navigation in die ent-

gegengesetzte Richtung, es wird also eine detailliertere Sicht auf die Kennzahlen

erzeugt (z.B. die einzelnen Quartale eines Jahres). [vgl. Kem10, S. 96ff]


Abbildung 2-6: OLAP-Würfel Perspektiven [Eigene Darstellung]

Für die multidimensionale Datenspeicherung bieten Hersteller von OLAP-Systemen

spezielle multidimensionale Datenbankmanagementsysteme (MDBMS) an. Diese

sind für die OLAP-spezifischen Anforderungen optimiert und bieten beispielsweise

die Möglichkeit zur Berechnung von konsolidierten Kennzahlen direkt beim Laden

eines Würfels. So sind für Abfragen zur Laufzeit keine weiteren Berechnungen mehr

nötig. Alternativ kann ein OLAP-System auch mittels relationaler Datenbankmana-

gementsystemen (RDBMS) implementiert sein. Es wird je nach zugrundeliegender

Technik zwischen multidimensionalen OLAP (MOLAP), relationalen OLAP (ROLAP)

und einer Mischform, dem hybriden OLAP (HOLAP), unterschieden. [vgl. Tot00, S.

65ff] Die analytischen Grundgedanken sind bei allen drei Techniken jedoch gleich.

Als Front-End für die Analyse und Berichterstellung bieten OLAP-Systeme mehrere

Zugriffsmöglichkeiten. Gängige Praxis sind Erweiterungen für Excel als auch proprie-

täre Rich-Client-Anwendungen oder Online-Portale. [vgl. Kem10, S. 101]


2.1.3.4 Data Warehouse Das DW ist das zentrale Lager für dispositive Daten. [vgl. Kem10, S. 17] Da relatio-

nale Datenbanken heutzutage sehr weit entwickelt sind, sie mittels SQL umfassende

Zugriffs- und Manipulationsoperationen bereitstellen und sie innerhalb von Unter-

nehmen eine starke Verbreitung haben, bieten sie sich auch als einheitliche Spei-

cherform für das DW an. Alternativ kann ein DW aber auch (zum Teil oder komplett)

aus einfachen Text- oder XML-Dateien bestehen. [vgl. Kem10, S. 22]

Abbildung 2-7: Operatives Schema und Sternschema [vgl. Tot00, S. 112]

Für die Unterstützung der multidimensionalen Anforderungen bietet sich das soge-

nannte Sternschema als ein einfaches Verfahren an, um Dimensionen und Kennzah-

len in relationalen Tabellen zu speichern. Die Faktentabelle in der Mitte referenziert

mittels Fremdschlüssel die Dimensionen und speichert für die verschiedenen Kombi-

nationen aus Dimensionselementen die Kennzahlen. Eine Denormalisierung

(Abbildung 2-7) wird bei der Erstellung des Sternschemas bewusst in Kauf genom-

men, um eine möglichst einfache und schnelle Analyseabfrage zu ermöglichen. [vgl.

Tot00, S. 111ff]

Für die tatsächlichen Auswertungen werden den Analyseanwendern oft verschiede-

ne Sichten bzw. Teilbereiche abgeleitet und bereitgestellt. Diese Teilbereiche werden

auch als Data Mart bezeichnet und bieten den Vorteil, dass ein Anwenderkreis nur

die für ihn interessanten Daten sieht. So hat eine Vertriebsabteilung in der Regel nur

Interesse an Kennzahlen wie Verkaufsstückzahlen, Umsatz oder Provisionen. Eine

Fertigungsabteilung hingegen interessiert sich für Produktionsstückzahlen oder Fer-


tigungszeiten. Ein solcher Data Mart ist die Datengrundlage, aus der ein OLAP-

Würfel geladen wird.

Zu dem DW gehört weiterhin die sogenannte Staging Area. Die Staging Area ist ein

(Hilfs-)Speicherbereich, der während der Extraktion und Integration der Daten ver-

wendet wird und zum Beispiel Zwischenergebnisse speichert. [vgl. Kim02, S. 8]

2.1.3.5 Datenintegration Der Prozess des Übertrages der Daten aus den Quellsystemen in das DW findet in

drei Stufen statt:

• Extraktion der benötigten Daten

• Transformation in ein einheitliches multidimensionales Format

• Laden in das DW und Bereitstellen für Analysen

Der gesamte Prozess wird in der Literatur häufig abgekürzt als ETL-Prozess be-

zeichnet. In dieser Arbeit wird der Prozess vereinfacht als Datenintegration (DI) be-

zeichnet.

Gültiger Wert Ungültiger Wert Fehlender Wert

Richtiger Wert Falscher Wert

Richtige Darstellung

Falsche Darstellung

Exakte Daten Inexakte Daten

Abbildung 2-8: Exaktheit von Daten [vgl. Ols03, S. 33]

Das Lesen der Rohdaten aus den Quellsystemen wird als Extraktion bezeichnet. Das

Lesen kann aus Sicht des DWS sowohl direkt als auch indirekt erfolgen. Direkt be-

deutet, dass der Extraktionsprozess selber aktiv auf die produktiven Quellen zugreift

und sich die benötigten Daten holt. Dieses Vorgehen hat jedoch zwei Nachteile. Zum

einen muss sich der DW-Entwickler intensiv mit der Struktur des operativen Daten-

modells auseinandersetzen und dieses verstehen, um die richtigen Attribute selektie-

ren zu können. Zum anderen ist der Prozess damit vom operativen Datenmodell ab-

hängig und muss bei Änderungen ebenfalls angepasst werden. Für einige geschlos-

sene, proprietäre Anwendungen gibt es darüber hinaus häufig keine Möglichkeit, di-


rekt auf das zugrundeliegende Datenmodell zuzugreifen. Von daher bietet sich für

die Extraktion oftmals ein indirekter Zugriff an. Hierbei stellt der Verantwortliche des

operativen Systems eine klar definierte Schnittstelle bereit, auf die der Extraktions-

prozess zugreift. Eine Schnittstelle kann beispielsweise eine Tabellen-View oder ein

exportierter Tabellen-Abzug als Datei sein. Der Entwickler des Quellsystems hat

dann sicherzustellen, dass bei Änderungen des Datenmodells die Schnittstelle wei-

terhin korrekt beliefert wird. [vgl. Tot00, S. 110]

Der Transformationsschritt ist der aufwendigste und komplexeste Teil des Integrati-

onsprozesses. Kimball et al. teilen die Transformation zum besseren Verständnis in

zwei Schritte: Säubern6 und Harmonisieren7. [vgl. Kim04, S. 18ff]

Das Säubern der Daten dient der Behebung von Mängeln und somit der Erreichung

einer definierten Datenqualität. [vgl. Kim04, S. 134ff] Die Säuberung ist deshalb not-

wendig, weil operative Systeme nicht zwangsweise immer exakte Daten enthalten

(Abbildung 2-8). Die Ursachen für inexakte Daten kann sehr vielfältig sein: falsche

Eingaben durch die Anwender, Systemfehler oder Evolution der Systeme. [vgl.

Ols03, S. 43ff] Bei den zu behebenden Mängeltypen lassen sich syntaktische (tech-

nische) und semantische (inhaltliche) Mängel unterscheiden. Syntaktische Mängel

sind alphanumerische Werte in einem numerischen Feld, NULL Werte in einem NOT

NULL Feld oder Werte außerhalb des Wertebereiches. Semantische Mängel ergeben

sich aufgrund von falschen inhaltlichen Beziehungen zwischen mehreren Feldern,

etwa zwischen der Postleitzahl und dem Ort.

Das Harmonisieren ist notwendig, wenn Daten aus verschiedenen Quellsystemen

zusammengespielt werden. In den heterogen gewachsenen Quellsystemen werden

für gleiche Sachverhalte bzw. Eigenschaften oftmals unterschiedliche Schlüssel oder

Ausprägungen verwendet. Das klassische Beispiel ist der Schlüssel für das Ge-

schlecht, der in drei Systemen unterschiedlich als männlich/weiblich, M/W und als

0/1 dargestellt wird. Ziel ist es also, die gleichen Sachverhalte auf einen gemeinsa-

men Schlüssel zu bringen. Weiterhin werden unterschiedliche Messgrößen in ein

gemeinsames Maß übertragen, beispielsweise werden verschiedene Währungen in

eine einheitliche Währung umgerechnet. [vgl. Kim04, S. 148ff]

6 Auch engl.: Clean 7 Auch engl.: Conform


Im finalen Schritt des Integrationsprozesses werden die gesäuberten und harmoni-

sierten Daten in das Sternschema überführt bzw. als Sternschema ausgeliefert8

(Abbildung 2-7). Das bedeutet, dass gemäß dem multidimensionalen Modell die Di-

mensionstabellen und Faktentabellen gefüllt werden. Abschließend werden aus dem

Sternschema die OLAP-Würfel geladen. [vgl. Kim04, S.19]

Im Folgenden wird das Vorgehen der Datenintegration exemplarisch veranschaulicht.

Die Tabelle 2-1 zeigt die Originaldaten, so wie sie über die Schnittstelle des Quell-

systems geliefert werden. Bei den Daten handelt es sich um Versicherungsdaten

(Versicherungsschein-ID, Datum des Vertragsbeginns, Geschlecht sowie Postleit-

zahl/Ort des Versicherungsnehmers, gezahlter Beitrag und verursachte Schäden in

Dollar).

Vers.ID Datum Geschlecht PLZ Ort Beitrag $ Schäden $ 201-38214 13.07.2011 männlich 10000 Hannover 207,16 195,42

200-92346 28.04.2011 männlich 30419 Hannover 186,03 427,81

201-19203 08.01.2011 weiblich 30165 Hannover 311,40 84,32

201-71829 15.10.2011 weiblich 30657 Hannover 229,74 0x2A

Tabelle 2-2: Originaldaten aus Quellsystem [Eigene Darstellung]

Das Anwenden von Qualitätsregeln ergibt, dass beim ersten und letzten Datensatz

fehlerhafte Informationen vorliegen. Die Postleitzahl 10000 passt nicht zu dem Ort

Hannover und 0x2A ist kein gültiger Wert für eine Schadenzahlung.

Vers.ID Datum Geschlecht PLZ Ort Beitrag $ Schäden $ 201-38214 13.07.2011 männlich 10000 Hannover 207,16 195,42

200-92346 28.04.2011 männlich 30419 Hannover 186,03 427,81

201-19203 08.01.2011 weiblich 30165 Hannover 311,40 84,32

201-71829 15.10.2011 weiblich 30657 Hannover 229,74 0x2A

Tabelle 2-3: Gesäuberte Daten [Eigene Darstellung]

8 Auch engl.: Deliver


Die fehlerhaften Datensätze werden ausgesteuert und nur die gültigen Sätze werden

weiterverarbeitet. Zur Harmonisierung der Daten werden die Schlüssel für das Ge-

schlecht in das Format M/W umgewandelt und die Beträge von Dollar in Euro umge-

rechnet:

Vers.ID Datum Geschlecht PLZ Ort Beitrag € Schäden € 200-92346 28.04.2011 M 30419 Hannover 146,21 336,25

201-19203 08.01.2011 W 30165 Hannover 244,75 66,27

Tabelle 2-4: Harmonisierte Daten [Eigene Darstellung]

Schließlich werden die Daten in das Sternschema umgeformt. Aus den ersten drei

Ziffern der Versicherungsschein-ID wurde das Produkt abgeleitet. Weitere Dimensio-

nen sind die Zeit, das Geschlecht und das Absatzgebiet. Die Faktentabelle in der

Mitte referenziert die umliegenden Dimensionstabellen mittels surrogater Fremd-

schlüssel:

ProduktKey Produktgruppe Produkt ZeitKey Jahr Monat 78 Kraftfahrt Kraftfahrt-Haftpflicht 20110128 2011 Januar

79 Kraftfahrt Kraftfahrt-Teilkasko 20110408 2011 April

ProduktKey ZeitKey Geschl.Key AbsatzgebietKey Beitrag € Schäden € 78 20110428 1 13 146,21 336,25

79 20110801 2 13 244,75 66,27

Geschl.Key Geschl. AbsatzgebietKey Land Bundesland Region 1 M 13 Deutschland Niedersachsen Hannover

2 W

Tabelle 2-5: Daten im Sternschema [Eigene Darstellung]


2.1.3.6 Automatisierungssysteme In der Definition von BI werden auch die indirekt beteiligten Systeme mit einge-

schlossen. Als direkt beteiligt können die zuvor vorgestellten Systeme für die Daten-

bereitstellung, Datenhaltung und Analyse angesehen werden. Indirekt beteiligt sind

folglich alle anderen Systeme, die beim Betrieb eines BIS partizipieren.

Eines der wichtigsten Systeme, das für den Betrieb eines automatisierten BIS benö-

tigt wird, ist die Job-Steuerung. Allgemein gesprochen sorgt eine Job-Steuerung da-

für, dass Programme zur richtigen Zeit am richtigen Ort in der richtigen Art und Wei-

se gestartet und beendet werden. Die Transformation innerhalb eines Datenintegra-

tionsprozesses kann ein solches Programm sein. Der Prozess selber weiß nicht,

wann er zu starten hat, weil er mögliche Abhängigkeiten sowie Vorbedingungen nicht

kennt. So darf die Transformation natürlich erst dann starten, wenn die Extraktion

erfolgreich beendet ist und alle benötigten Daten bereitstehen. Somit werden Pro-

gramme, die gemeinsam einen Prozess darstellen, in der richtigen Reihenfolge zu

einem sogenannten Job zusammengefasst. Soll dieser Job in einem regelmäßigen

Intervall laufen (z.B. täglich), dann kann er von der Steuerung in einen Zeitplan9 ein-

gebunden werden.

Der „richtige Ort“ ist ein Server innerhalb des Rechenzentrums. Da die Prozesse in-

nerhalb des BIS für gewöhnlich rechenintensiv sind und viele Hardwareressourcen

(CPU, RAM, I/O) verbrauchen, müssen sie zur Erzielung der optimalen Gesamtper-

formance gleichmäßig auf die verschiedenen Server verteilt10 werden. Ein zu star-

tender Prozess wird also immer auf den Server übertragen, der gerade am wenigs-

ten ausgelastet ist. Das Starten und Beenden der Programme „in der richtigen Art

und Weise“ bezieht sich zum einen auf die Eingabeparameter und zum anderen auf

Rückgabewerte von einem Programm. Beim Start einer Transformation muss bei-

spielsweise die Referenz auf die zu verarbeitenden Daten und beim Beenden die

Referenz an den folgenden Lade-Prozess übergeben werden. Falls das Programm

aufgrund eines Fehlers abbricht, so muss der Fehler abgefangen und behandelt

werden. Etwa indem der gesamte Prozess gestoppt und ein Administrator darüber

benachrichtig wird. [vgl. Sco09, S. 3ff]

9 Auch engl.: Schedule 10 Auch engl.: Load Balancing


2.1.4. Business Intelligence System Big Picture

Die logische Übersicht zum Zusammenhang von DWS und BIS aus Abbildung 2-1

wurde in der Abbildung 2-9 um die in den vorherigen Abschnitten vorgestellten Kom-

ponenten zu einem abschließenden Big Picture erweitert.

Abbildung 2-9: Business Intelligence System Big Picture [Eigene Darstellung]

Aufgrund der genannten Definitionsvielfalt gibt es in der Literatur ebenfalls eine ent-

sprechende Vielfalt bei den zusammenfassenden Big Pictures. Diese Bilder neigen

dazu, sehr überladen zu wirken, weil sie jeden Aspekt bzw. jede Variation berück-


sichtigen sollen (Metadaten-Repository, Operational Data Store etc.). Die hier ge-

zeigte Abbildung ist mit Absicht schlicht gehalten und beschränkt sich auf die we-

sentlichen Punkte eines BIS, die für den weiteren Verlauf dieser Arbeit von Bedeu-

tung sind.

2.2. Testen von Software Jede Software enthält ab einer bestimmten Komplexität Fehler. [vgl. Lig09, S. 4] Un-

entdeckte Fehler können im schlimmsten Fall nach Auslieferung der Software

schwerwiegende Schäden verursachen. Neben wirtschaftlichen Schäden können

auch körperliche Schäden angerichtet werden, beispielsweise bei Software in der

Medizin- oder in der Luftfahrttechnik11. Zu den Schadensersatzforderungen hat der

Softwarehersteller in einem derartigen Fehlerfall zusätzlich mit einem starken Image-

verlust zu rechnen. Da BIS die Grundlagen für unternehmerische Entscheidungen

liefern, können Fehler zu falschen Entscheidungen führen und somit wirtschaftliche

Schäden innerhalb eines Unternehmens anrichten.

Unter dem Testen von Software wird nach Spillner und Linz [vgl. Spi03, S.8ff] das

stichprobenartige Ausführen eines Testobjektes mit dem anschließenden Vergleich

des Soll- und Ist-Verhaltens verstanden. Daneben gibt es aber auch statische Analy-

sen, bei denen ein Testobjekt geprüft wird, ohne ausgeführt zu werden. Als Hauptzie-

le von Tests ergeben sich:

• Entdeckung von Fehlern bevor ein Schaden entsteht

• Aufbauen von Vertrauen in die Software

Eine sehr ausführliche Einteilung verschiedener praktischer Softwareprüftechniken

wurde in Liggesmeyer [vgl. Lig09, S. 38] vorgenommen. In der Abbildung 2-10 sind

die in dieser Arbeit verwendeten Techniken als Übersicht zusammengefasst. In den

folgenden Abschnitten werden diese Techniken näher beschrieben.

11 Hoffmann [Hof08, S. 33ff] liefert in diesem Zusammenhang einige prominente Beispiele von Soft-

warefehlern und deren Auswirkungen bei der US Army, der NASA und der ESA.


Abbildung 2-10: Klassifikation der Softwareprüftechniken [vgl. Lig09, S. 38]

2.2.1. Softwareentwicklungsprozess

Das klassische Vorgehensmodell bei der Softwareentwicklung ist das Wasserfallmo-

dell. [vgl. Han05, S. 267] Die Software durchlebt dabei sechs strikt aufeinanderfol-

gende Phasen: Anforderungen (Start) à Analyse à Design à Implementierung à

Test à Betrieb (Ende). In Abbildung 2-12 auf der linken Hälfte ist dieses Vorgehen

dargestellt.

Das Testen zum Ende des Entwicklungsprozesses kann jedoch bereits zu spät sein.

Liggesmeyer liefert eine anschauliche Darstellung, wie sich die Fehleranzahl und die

Fehlerbehebungskosten auf die einzelnen Projektphasen aufteilen (Tabelle 2-6). Et-

wa die Hälfte aller Fehler entsteht also noch bevor eine Zeile Code geschrieben wur-

de. Gleichzeitig sind die Fehlerbehebungskosten in den frühen Projektphasen am


niedrigsten. Von daher empfiehlt es sich, während eines Projektes so früh wie mög-

lich mit dem Testen anzufangen.

Anzahl der ent-standenen Fehler 10% 40% 50% - - -

Anzahl der erkannten Fehler 3% 5% 7% 25% 50% 10%

Kosten pro Fehler-behebung 250€ 250€ 250€ 1.000€ 3.000€ 12.500€

Analyse Design Implemen-tierung

Entwick-lertest

System-test

Produk-tivbetrieb

Tabelle 2-6: Fehlerkosten [vgl. Lig09, S. 33]

Eine Erweiterung des Wasserfallmodells ist das sogenannte V-Modell (Abbildung

2-11). Die Testaktivitäten sind dabei mit der eigentlichen Konstruktion (Analyse, Ent-

wurf, Implementierung) gleichgestellt und jeder Entwicklungsstufe wird eine eigene

Teststufe zugeordnet. [vgl. Spi03, S. 39ff]

Abbildung 2-11: V-Modell [vgl. Spi03, S. 40]

Moderne Entwicklungsansätze bei Projekten mit unvollständigen oder sich ändern-

den Anforderungen gehen evolutionär bzw. prototypisch vor. Dabei wird das Ge-

samtprojekt in kleine Portionen aufgeteilt und zunächst mit der Entwicklung der Kern-

funktionen begonnen. Mithilfe eines so entstehenden Prototyps kann ein Auftragge-


ber sich schneller ein Bild davon verschaffen, ob die Entwicklung in die gewünschte

Richtung geht oder ob die Anforderungen überhaupt realisierbar sind. Auf Basis des

Prototyps wird das System nach und nach erweitert. Die einzelnen Ausbaustufen

durchlaufen jeweils die Entwicklungs- und Testphasen (Abbildung 2-12, rechte Hälf-

te). [vgl. Spi03, S. 68]

Abbildung 2-12: Wasserfallmodell vs. Prototyp [vgl. Koe07, S. 7]

2.2.2. Dynamische Prüftechniken

Ein dynamischer Test liegt dann vor, wenn die Software mit konkreten Eingabedaten

zur Ausführung gebracht wird. Die dynamischen Tests besitzen zusammengefasst

die folgenden Merkmale:

• Die übersetzte, ausführbare Software wird mit konkreten Eingabewerten ver-

sehen und ausgeführt.

• Es kann in der realen Betriebsumgebung getestet werden.

• Es handelt sich um ein Stichprobenverfahren.

Der wesentliche Nachteil ist, dass sie nur einen Stichprobencharakter aufweisen,

weil nicht alle möglichen Situationen (Eingabewerte) getestet werden können. Ein

vollständiger Test aller möglichen Eingaben wird auch als erschöpfender Test be-

zeichnet. Die Durchführung eines erschöpfenden Tests ist in der Regel nicht möglich,

weil die Anzahl an Testfällen gegen unendlich gehen kann. Das Ziel der dynami-


schen Prüftechniken ist daher die Erzeugung effektiver und sinnvoller Testfälle. [vgl.

Lig09, S. 39]

Eine weitere Unterteilung der dynamischen Prüftechniken erfolgt in funktionsorien-

tierte und in strukturorientierte Testtechniken. Die funktionsorientierten Techniken

leiten anhand der in der Spezifikation beschriebenen Funktionen die Testfälle ab und

bewerten die Testvollständigkeit und -ergebnisse auch an der Spezifikation. [vgl.

Lig09, S. 40] Die strukturorientierten Techniken hingegen liefern keine Regeln für die

Testfallerstellung. Im Vordergrund steht die Bewertung der Abdeckungen der Struk-

turelemente des Quellcodes (Anweisungen, Zweige, Datenzugriffe etc.) durch die

(wie auch immer) erzeugten Testfälle. [vgl. Lig09, S. 84]

2.2.2.1 Funktionsorientierte Tests Der Ausgangspunkt für funktionsorientierte Tests ist die Spezifikation, die das Soll-

Verhalten der Software definiert. Aus der Spezifikation werden entsprechend die

Testfälle abgeleitet. Durch die Testausführung entstehen Reaktionen der Software,

welche mit den vorgegebenen Reaktionen übereinstimmen müssen.

Der Vorteil des funktionsorientierten Testens liegt in der Verifikation des vorgegebe-

nen Verhaltens. Somit können erfolgreich durchgeführte Tests ein grundsätzliches

Vertrauen in die Software liefern. Nachteilig ist allerdings, dass aufgrund der Vielzahl

an theoretischen Eingabekombinationen die Struktur der Software (der Quellcode)

unter Umständen nicht vollständig getestet wird und so die Möglichkeit besteht, dass

verdeckte Fehler nach dem Testen weiterhin bestehen bleiben. Der Erfolg des Tes-

tens steht und fällt mit der Stichprobenauswahl. Als Zielsetzung der funktionsorien-

tierten Prüftechniken ergibt sich die Erstellung von Testfällen, die repräsentativ, feh-

lersensitiv, redundanzarm und ökonomisch sind. [vgl. Lig09, S. 39]

Äquivalenzklassenbildung Eine einfache Testfallermittlung kann mittels Grenzwertanalyse und der daraus resul-

tierenden Äquivalenzklassenbildung erfolgen. Dafür werden alle Eingabedaten, die

zu demselben Ergebnis führen, als eine Äquivalenzklasse zusammengefasst. Aus

dieser Klasse wird dann nur ein Testfall stellvertretend für die ganze Gruppe zur Aus-

führung gebracht. [vgl. Lig09, S. 52ff]


Grenzwerte -1 0 4 5 9 10 60 61

Gratifikation Fehler 250€ 250€ 500€ 500€ 1.000€ 1.000€ Fehler

Tabelle 2-7: Grenzwerte [Eigene Darstellung]

Das folgende Beispiel soll die Testfallermittlung mittels Äquivalenzklassenbildung

verdeutlichen: In Abhängigkeit der Firmenzugehörigkeit soll ein Programm die Weih-

nachtsgratifikation für die Mitarbeiter berechnen. Für 0 bis 4 Jahre Zugehörigkeit

250€, für 5 bis 9 Jahre 500€ und für 10 oder mehr Jahre 1.000€. Die Firmenzugehö-

rigkeit ist immer eine ganze Zahl. Ein Mitarbeiter kann maximal 60 Jahre dem Betrieb

zugehören. [vgl. Spi03, S. 24f] Aus diesen Informationen ergeben sich die Grenzwer-

te in der Tabelle 2-7. Mit den Grenzwerten lassen sich die möglichen Eingabewerte

in insgesamt sechs Äquivalenzklassen aufteilen, aus denen dann jeweils ein Reprä-

sentant ausgewählt und getestet wird:

Äquivalenzklassen (Werte) Repräsentant Gratifikation (Ergebnis) Ä" = {0,1,2,3,4} 3 250€

Ä- = {5,6,7,8,9} 7 500€

Ä3 = {10,… ,60} 37 1.000€

Ä5 = {−1,−2,… } -9 Fehler

Ä7 = {60,61,… } 73 Fehler

Tabelle 2-8: Äquivalenzklassen [Eigene Darstellung]

Ursache-Wirkungs-Analyse Während die Äquivalenzklassenbildung lediglich einzelne Eingaben und Ergebnisse

betrachtet, stellt die Ursachen-Wirkungs-Analyse auch Zusammenwirkungen von

Eingaben dar. Bei vielen Eingabemöglichkeiten existiert auch eine hohe Anzahl von

Kombinationsmöglichkeiten. Deshalb ist es ein Ziel der Ursache-Wirkungs-Analyse,

diese Anzahl auf ein überschaubares und sinnvolles Maß zu reduzieren. [vgl. Lig09,

S. 66ff]


Bei Ursachen handelt es sich um logische Eingangsbedingungen des Systems, die

als Wahrheitswerte dargestellt werden (z.B. Schadenszahlung > 10.000€). Eine Wir-

kung ist die aus einer oder mehreren Ursachen hervorgerufene Ausgangsbedingung

des Systems. Die Ursachen und Wirkungen werden mit ihren Beziehungen in einen

Ursache-Wirkungs-Graphen übertragen. Bei einer Identität gilt: U ist wahr à W, bei

der Negation gilt: U ist falsch à W. Die Kombination zweier Ursachen für eine ge-

meinsame Wirkung wird mittels logischer Operatoren (∧= UND, ∨ = ODER) gekenn-

zeichnet. Eine R-Abhängigkeit zwischen zwei Ursachen zeigt die Voraussetzung12

von U1 für U2. In der folgenden Abbildung sind die in dieser Arbeit verwendeten Nota-

tionen des Ursache-Wirkungs-Graphen zusammengefasst. Eine vollständige Über-

sicht samt Erläuterungen kann bei Liggesmeyer [vgl. Lig09, S. 68f] nachgeschlagen

werden.

Abbildung 2-13: Ursache-Wirkungs-Graph Notation [vgl. Lig09, S. 68f]

Der aufgestellte Graph bildet die Grundlage für eine Entscheidungstabelle. Die Ursa-

chen sowie die Wirkungen bilden die Zeilen der Tabelle. Für alle Kombinationen von

Ursachen werden die daraus resultierenden Wirkungen eingetragen. Um die ge-

wünschte Reduzierung von Testfällen zu erreichen, werden Ursachen, die einen

gleichen Sachverhalt darstellen, komprimiert. In der Tabelle 2-9 ist beispielsweise die

Ausprägung von U2 irrelevant, sobald U1 falsch ist. Die Irrelevanz wird in einer kom-

primierten Entscheidungstabelle durch ein „-“ gekennzeichnet. Die Testfälle T1 bis T3

ergeben sich aus den Spalten der komprimierten Entscheidungstabelle.

12 Auch engl.: Requires


Ursachen Ursachen U1 N N J J U1 N J J

U2 J N J N U2 - J N

Wirkungen Wirkungen W1 J J N N W1 J N N

W2 N N J N W2 N J N

W3 N N N J W3 N N J

T1 T2 T3 T1 T2 T3

Tabelle 2-9: Entscheidungstabelle [Eigene Darstellung]

2.2.2.2 Strukturorientierte Tests Strukturorientierte Tests ermitteln keine Testfälle gemäß der vorgegebenen Funktio-

nalität laut Spezifikation, sondern sie bewerten die Abdeckung des Quellcodes durch

zuvor aufgestellte Testfälle. Die Bewertung erfolgt entweder anhand des Kontrollflus-

ses oder anhand des Datenflusses eines Programms. [vgl. Lig09, S. 40]

Kontrollflussorientierte Tests Der Begriff Kontrollfluss bezeichnet die Verarbeitungslogik bzw. die Steuerung einer

Software (Anweisungen, Zweige, Bedingungen oder Schleifen). Die Vollständigkeit

des Testens wird anhand der Abdeckung der einzelnen Strukturen bewertet. Der

Kontrollflussgraph ist eine gängige Darstellungsform für den Zusammenhang der

Strukturen. In der Abbildung 2-14 ist ein Kontrollflussgraph zu einer Methode gege-

ben, die den Betrag aus einer Zahl ermittelt. [vgl. Lig09, S. 84]

Die einfachste Form des kontrollflussorientierten Testens ist der Anweisungsüberde-

ckungstest. Dabei soll jede Anweisung in einem Programm mindestens einmal aus-

geführt werden (alle Knoten im Graphen). Es wird sichergestellt, dass alle Anweisun-

gen für sich korrekt sind. Zusätzlich lassen sich Anweisungen aufspüren, die niemals

ausgeführt werden (sogenannter toter Code). [vgl. Lig09, S. 85ff]

Eine Steigerung des Anweisungsüberdeckungstests ist der Zweigüberdeckungstest.

Dieser fordert zusätzlich, dass jeder Programmzweig (alle Kanten im Graphen) min-


destens einmal durchlaufen wird. Das bedeutet, dass zum Beispiel alle Entscheidun-

gen sowohl für true als auch für false ausgeführt werden müssen. [vgl. Lig09, S.

88ff]

Eine weitere Steigerung ist der Bedingungsüberdeckungstest, bei dem zusätzlich alle

möglichen Kombinationen für verschachtelte bzw. zusammengesetzte Entscheidun-

gen getestet werden. Damit lassen sich auch Fehler aufdecken, die nur aufgrund

spezieller Testdatenkonstellationen hervorgerufen werden. [vgl. Lig09, S. 93ff]

Die höchste Steigerung des kontrollflussorientierten Testens ist der erschöpfende

Test. Dabei werden alle möglichen Eingaben zu allen möglichen Betriebssituationen

getestet. Da diese Anzahl allerdings gegen unendlich gehen kann, ist der erschöp-

fende Test nicht praktikabel. [vgl. Lig09, S. 511]

Abbildung 2-14: Kontrollflussgraph [Eigene Darstellung]

Datenflussorientierte Tests Jede Software enthält neben den Kontrollstrukturen auch Daten, die verarbeitet wer-

den. Diese Datenverarbeitung (Lesen und Schreiben) innerhalb der Software wird

auch als Datenfluss bezeichnet. Das datenflussorientierte Testen beurteilt die Test-

vollständigkeit daher anhand der Abdeckung der getesteten Datenzugriffe. [vgl.

Lig09, S. 142f] Auf Variablen im Speicher kann wie folgt zugegriffen werden:


Zugriff Beschreibung def Schreibend13, z.B. x=1

c-use Lesend für eine Berechnung14, z.B. y=x+1 oder

p-use Lesend für eine Entscheidung15, z.B. if(x>0)

Tabelle 2-10: Variablenzugriffe (Datenflussgraph) [Eigene Darstellung]

Ein zuvor aufgestellter Kontrollflussgraph kann mit diesen drei Datenzugriffarten er-

weitert werden (def und c-use an den Knoten, p-use an den Kanten). [vgl. Lig09, S.

143] Die folgende Abbildung zeigt einen so entstehenden Datenflussgraphen zu der

Betrag-Methode:

Abbildung 2-15: Datenflussgraph


13 Auch engl.: definition 14 Auch engl.: computaional use 15 Auch engl.: predicate use


Die Beurteilung der Testvollständigkeit kann nun anhand der Abdeckung der drei

Datenzugriffarten auf die Attribute erfolgen. Dabei gibt es unterschiedlich scharfe Kri-

terien, etwa ob alle defs, alle p-uses, alle c-uses oder die Kombinationen der Zugriffe

abgedeckt sind. [vgl. Lig09, S. 147ff]

2.2.2.3 Diversifizierende Tests Die diversifizierenden Tests beziehen sich auf verschiedene Versionen einer Soft-

ware, welche beispielsweise durch mehrfache Realisierung oder durch Weiterent-

wicklung entstanden sind. Eine sehr bekannte und verbreitete Variante davon ist der

Regressionstest. Dieser gleicht das Verhalten einer neuen Softwareversion gegen

das Verhalten der vorherigen Version ab, indem alte Testfälle bei der neuen Version

erneut ausgeführt werden. [vgl. Lig09, S. 42]

2.2.3. Statische Prüftechniken

Bei den statischen Analysen wird die zu prüfende Software nicht zur Ausführung ge-

bracht. Von daher ist es auch nicht nötig, dass Testfälle erstellt bzw. ausgewählt

werden. [vgl. Lig09, S. 43]

2.2.3.1 Stilanalyse Bei der Stilanalyse wird der Quellcode einer Software auf die Einhaltung von Pro-

grammierkonventionen überprüft. Solche Konventionen haben die Absicht, die Les-

barkeit des Quellcodes zu gewährleisten sowie fehleranfällige Codekonstrukte im

Vorfeld zu vermeiden. Inhaltlich werden syntaktische und semantische Programmier-

konventionen unterschieden. [vgl. Lig09, S. 271]

Syntaktische Programmierkonventionen Syntaktische Konventionen sind in der Regel Einschränkungen der zur Verfügung

stehenden Programmiersyntax. Programmiersprachen bieten für Variablendefinitio-

nen und -zuweisungen unterschiedliche Möglichkeiten an, diese in einer verkürzten

Schreibweise zu implementieren. Die Verkürzung erschwert jedoch deutlich die Les-

barkeit, sodass viele Unternehmen diese Konstrukte in ihren Konventionen nicht er-

lauben. [vgl. Lig09, S. 272] Im folgenden Listing sind einige Beispiele gegeben:


01 02 03 04 05 06 07 08 09 10

// Verbotene Zuweisungen int x = 1, y = 2; y++; x += y; // Erlaubte Zuweisungen int x = 1, int y = 2; y = y + 1; x = x + y;

Listing 2-2: Syntaktische Programmierkonventionen [Eigene Darstellung]

Ebenfalls zu den syntaktischen Konventionen zählen Vorschriften zum Formatieren

des Quellcodes, wie etwa das Setzen von Klammern oder das Einrücken von Anwei-

sungen. Eine Prüfung der syntaktischen Konventionen ist mit geringem Aufwand

verbunden, da entsprechende Testwerkzeuge lediglich Symbole im Quellcode auf-

spüren müssen. [vgl. Lig09, S. 272]

Semantische Programmierkonventionen Semantische Konventionen fordern die Nutzung von aussagekräftigen Benennungen

sowie von Kommentaren. Gerade die Wartbarkeit des Programmcodes soll mit die-

sen Konventionen erhöht werden. So kann eine Vorschrift lauten, dass Methoden

immer mit einem Verb anfangen. Eine Methode zum Suchen nach Kunden muss

dann exemplarisch sucheKunde() benannt sein und nicht kundeSuchen(). Da ein

Programm über seinen Lebenszeitraum von verschiedenen Entwicklern bearbeitet

wird, sind Kommentare notwendig. Ein neuer Entwickler kann sich in ein kommentier-

tes Programm schneller einarbeiten. Die Prüfung von semantischen Konventionen

kann nicht durch ein Testwerkzeug durchgeführt werden. Hier ist stets ein Mensch

erforderlich, der den Inhalt bewerten kann. [vgl. Lig09, S. 272]

2.2.3.2 Visuelle Hilfsmittel Ein Bild sagt mehr als tausend Worte. Diese Lebensweisheit gilt natürlich auch für

die Softwareentwicklung, sodass die Verwendung von Grafiken, Diagrammen und

Tabellen schon lange als unverzichtbare Hilfsmittel für Visualisierungen genutzt wer-


den. Für die Entwicklung objektorientierter Software hat sich die Unified Modeling

Language (UML) mit seiner Vielzahl an Diagrammtypen beispielsweise als de-facto

Standard durchgesetzt. Auch die im Abschnitt 2.2.2.2 vorgestellten Kontroll- und Da-

tenflussgraphen zählen zu den visuellen Hilfsmitteln. [vgl. Lig09, S. 276]

Aus Sicht eines Entwicklers gibt es gleich zwei Gründe, welche die Verwendung von

visuellen Hilfsmitteln zwingend notwendig machen. Zum einen erleichtern Diagram-

me und Grafiken die Kommunikation mit den (fachlichen) Auftraggebern. Selbst

wenn beide Seiten - Informatik und Fachabteilung - dieselbe Sprache sprechen, kön-

nen die jeweils verstandenen Inhalte stark voneinander abweichen. Die fachlichen

und technischen Denkweisen sind einfach zu unterschiedlich. Daher ist es essentiell

wichtig, bei der Zusammenarbeit eine Symbolik zu verwenden, die für beide Parteien

dieselbe Semantik besitzt. Der zweite Grund ist der Wissenserhalt bzw. die Doku-

mentationsfunktion für Wartungs- und Weiterentwicklungsarbeiten. Ein Entwickler

kann sich schneller in die Geschäftslogik und die Implementierung einarbeiten, wenn

diese übersichtlich visualisiert ist. [vgl. Lig09, S. 276]

2.2.3.3 Anomalieanalyse Eine Anomalie ist eine Abweichung vom Normalen. Im Bereich der Softwareentwick-

lung können Anomalien im Quellcode auftauchen. Doch nicht jede Softwareanomalie

ist tatsächlich ein Softwarefehler. Die abweichenden Stellen enthalten zunächst nur

ungewöhnliche bzw. auffällige Anweisungssequenzen, die auf einen Fehler hindeu-

ten. Diese auffälligen Anweisungssequenzen aufzuspüren, ist das Ziel der Anomalie-

analyse. Unterteilen lassen sich die Softwareanomalien in Kontrollfluss- und Daten-

flussanomalien. [vgl. Lig09, S. 292f]

Kontrollflussanomalien Kontrollflussanomalien entstehen durch Bedingungen oder Schleifen. Die häufigste

und wohl bekannteste Anomalie ist der unerreichbare Programmcode, der durch if-

else Konstrukte entstehen kann. In diesem Fall führt der unerreichbare Code zwar

nicht zu Programmabbrüchen, es kann sich jedoch um einen Fehler handeln, weil

der Entwickler entweder die Bedingungen falsch implementiert hat oder den uner-

reichbaren Code an einer falschen Stelle platziert hat. Moderne Entwicklungsumge-


bungen beinhalten oft Funktionalitäten zur Aufdeckung von Kontrollflussanomalien

und warnen den Entwickler etwa bei unerreichbarem Code. [vgl. Hof08, S. 313f]

Abbildung 2-16: Zustandsautomat Datenflussanomalien [vgl. Lig09, S. 295]

Datenflussanomalien Bei der Datenflussanomalieanalyse werden die Variablenzugriffe etwas anders als

bei dem Datenflussgraphen betrachtet. Die Verwendung einer Variablen wird, egal

ob es sich um eine Berechnung oder einer Entscheidung handelt, zusammengefasst.

Dafür wird die Undefinition als neue Zugriffsart aufgenommen (Tabelle 2-11). Die drei

Zugriffsarten tauchen in einem Programm in verschiedenen Reihenfolgen auf. Ein

konsistenter Datenfluss muss immer gemäß dem Zustandsautomaten in Abbildung

2-16 aufgebaut sein. In drei Fällen kann es demnach zu einer Anomalie kommen.

Die dd-Anomalie (Variable wird zweimal hintereinander geschrieben) und du-

Anomalie (Variable wird geschrieben und dann gelöscht) deuten auf eine unsachge-

mäße Verwendung der Variablen hin. Die ur-Anomalie (undefinierte Variable wird

verwendet) hingegen führt zu einem harten Programmabbruch. [vgl. Lig09, S. 292ff]

Zugriff Beschreibung d(x) Eine Variable wird mit jeder Wertzuweisung definiert, z.B. x=1

r(x) Der Wert einer Variablen wird verwendet, z.B. y=x+1 oder if(x>0)

u(x) Die Variable wird undefiniert, z.B. Betreten oder Verlassen der Methode

Tabelle 2-11: Variablenzugriffe (Datenflussanomalieanalyse) [Eigene Darstellung]


2.2.3.4 Slicing Slicing ist vergleichbar mit dem Debugging, also der manuellen Fehlersuche nach

dem Auftreten eines Fehlverhaltens. Ein Programmslice ist ein Ausschnitt aus dem

Programmcode und hat das Ziel, alle Anweisungen zu identifizieren, die auf die Aus-

prägung eines betrachteten Attributs einwirken. Dieses Analysieren erfolgt rückwärts

von der Stelle, an der die Ausprägung eines Attributes nachvollzogen werden soll.

Ein Datenflussgraph ist hierbei der Ausgangspunkt. Von einer beliebig gewählten

Variablen werden anschließend alle Knoten herausgesucht, die Einfluss auf die Vari-

able haben. [vgl. Lig09, S. 285ff]

2.2.3.5 Review Das manuelle Durchsehen und Prüfen vom Quellcode sowie aller für die Entwicklung

einer Software relevanten Dokumente wird als Review bezeichnet. Die Grundidee ist

dabei, dass eine Inspektion nicht vom Autor des zu prüfenden Objektes durchgeführt

wird, sondern von unabhängigen Teilnehmern bzw. Kollegen. Neben der Qualitätssi-

cherung ergeben sich außerdem noch die Vorteile des Wissensaustausches und der

Verantwortungsteilung unter den Teilnehmern. [vgl. Lig09, S. 307]

Die manuelle Durchführung ergibt gegenüber Testwerkzeugen einen immensen Vor-

teil. Ein Mensch kann die Semantik bzw. die inhaltlichen Aspekte des geprüften Ob-

jektes verstehen und bewerten. Die Nachteile von Inspektionen liegen allerdings

ebenfalls in der Natur der manuellen Durchführung. Die Arbeit eines Menschen ist

zum einen langsamer und teurer als die eines Werkzeuges und zum anderen neigt

ein Mensch zur Unachtsamkeit. Das bedeutet, dass selbst wenn mehrere Menschen

ein Dokument oder einen Quellcode inspiziert haben, trotzdem Fehler übersehen

werden können. [vgl. Lig09, S. 306]

2.2.3.6 Metriken Die Softwaremessung hat zum Ziel, die Eigenschaften einer Software zu quantifizie-

ren. Anhand der so ermittelten Zahlen können dann qualitative Aussagen abgeleitet

werden. Zwei bekannte und sehr einfache Maße für Software sind die Anzahl der

Programmzeilen16 und die Anzahl der Funktionen. Mögliche Qualitätsaussagen an-

hand dieser beiden Maße sind beispielsweise die „Anzahl der Fehler pro Programm- 16 Auch engl.: Lines of Code


zeilen“ oder aber das Prädikat „ausreichend getestet“, welches aus der prozentualen

Testabdeckung abgeleitet wurde. [vgl. Lig09, S. 232f]

2.2.3.7 Verifizierende Analysen Zu den verifizierenden Analysen gehören der symbolische Test und der formale Kor-

rektheitsbeweis. Der symbolische Test ist eine Verallgemeinerung des dynamischen

Tests. Dabei wird die Software auf einem abstrakten Niveau geprüft, indem symboli-

sche Stellvertreter für konkrete Variablen aufgestellt werden. Die Anzahl der Testfälle

wird gegenüber dem dynamischen Test drastisch verringert. Beim formalen Korrekt-

heitsbeweis wird die Konsistenz zwischen Spezifikation und Implementierung ermit-

telt. Das setzt voraus, dass die Spezifikation in einer formalen Sprache vorliegt. [vgl.

Lig09, S. 44f] Aufgrund mangelnder praktischer Bedeutung [vgl. Lig09, S. 358f] wer-

den die formalen Analysen in dieser Arbeit nicht weiter berücksichtigt.

2.2.4. Testen von Datenbanken

Software besteht neben dem Programm an sich auch aus Daten und der entspre-

chenden Datenhaltung. Die bisher genannten (funktionalen) Prüftechniken beziehen

sich allesamt auf das Testen von Programmen. Relationale Datenbanken sind bei

der heutigen Softwareentwicklung der de-facto Standard für die Datenhaltung. Zum

Testen von Datenbanken findet sie ähnlich wie zum Testen von DWS und BIS wenig

Literatur. Ambler und Sadalage [vgl. Amb06, S. 29ff] gehen etwa kurz auf das Testen

von Datenbankobjekten ein, benennen aber nur, was zu testen ist und geben keine

praktischen Testtechniken an.

Sneed et al. [vgl. Sne09, S. 123ff] beschreiben Techniken zum Prüfen von Daten-

banktabellen. Die Idee hierbei ist, dass in eine Tabelle Testdaten eingetragen wer-

den und somit ihre Struktur (Datentypen und Längen der Attribute) geprüft wird. Da-

bei ergeben sich gemessen an der Anzahl von Testdatensätzen vier Überdeckungs-

tests:

• Satzüberdeckungstest

o Für eine Tabelle existiert eine Datensatzausprägung.

• Attributüberdeckungstest

o Für jedes einzelne Attribut in einer Tabelle existieren mindestens zwei

Datensatzausprägungen.


• Wertüberdeckungstest

o Für jeden Wert aus dem Wertebereich aller Attribute existiert eine Da-

tensatzausprägung.

• Zustandsüberdeckungstest

o Für die Kombinationen von allen Werten aus den Wertebereichen aller

Attribute existiert eine Datensatzausprägung.

Die Prüftechniken geben zwar einen Ansatz, müssen bezüglich der Anwendbarkeit

jedoch kritisch hinterfragt werden. So ergeben sich spätestens beim Zustandsüber-

deckungstest fachlich falsche Attributkombinationen, zum Beispiel wenn bei der Ta-

belle für Postleitzahlen und deren Orte entsprechend jede Postleitzahl mit jedem Ort

kombiniert wird. Ebenfalls wird es bei manchen Attributen schwierig, den Wertebe-

reich vorherzusagen. Bei einer Kundentabelle ist etwa im Vorfeld nicht bekannt, wie

viele Kunden es in Zukunft genau geben wird. Der Wertebereich einer Kunden-ID ist

also nicht bekannt. Selbiges Problem gilt auch für Attribute, die einen Geldbetrag

darstellen. Neben den inhaltlichen Problemen gibt es auch technische Schwierigkei-

ten bei der Realisierung. Bei einer Tabelle mit 10 Attributen, deren Wertebereiche

jeweils 10 Werte zulassen, verlangt der Zustandsüberdeckungstest demnach 1010

(10 Milliarden) Testdatensätze. Auch wenn sich diese Datensätze automatisiert ge-

nerieren lassen, ist ein Test mit so vielen Datensätzen wegen der hohen Ressour-

cenauslastung wenig sinnvoll. Der Satz- und der Attributüberdeckungstest hingegen

eignen sich auf Grund der Ungenauigkeit nicht.

Eine praktikable Lösung ist an dieser Stelle die Einführung eines Äquivalenzklassen-

überdeckungstests. Hierbei werden zu einem Wertebereich Äquivalenzklassen gebil-

det (Abschnitt 2.2.2.1) und für jeden Repräsentant eine Datensatzausprägung er-

stellt. Von besonderem Interesse sind hierbei die Äquivalenzklassengrenzen. Mittels

der Grenzwertanalyse wird genau das Ziel des Tests erreicht: die Überprüfung der

Datentypen und Längen.

2.2.5. Testen nichtfunktionaler Anforderungen

Nichtfunktionale Anforderungen an ein Softwaresystem beschreiben alle Eigenschaf-

ten, die nicht direkt die Funktionalität beeinflussen, sondern die Güte des Systems.


[vgl. Spi03, S. 71] Hoffmann [vgl. Hof08, S. 6ff, S. 170ff] nennt hierzu als weitere zu

testende Aspekte unter anderem die Effizienz, die Benutzbarkeit und die Sicherheit.

Effizienz Die Effizienz setzt sich aus den Antwortzeiten bzw. der Verarbeitungsgeschwindig-

keit sowie dem Ressourcenverbrauch des Systems zusammen. Bei der Betrachtung

der Effizienz muss das System sowohl unter „normalen“ Bedingungen als auch unter

Bedingungen in Grenzbereichen (hohe Last oder gar Überlastung) überprüft werden.

Benutzbarkeit Die Benutzbarkeit beinhaltet die Erlernbarkeit und Verständlichkeit der Bedienung

aus Sicht der Benutzer sowie die Vollständigkeit der Dokumentation.

Sicherheit Aus sicherheitstechnischer Sicht muss das System vor unberechtigten (lesenden und

manipulierenden) Zugriffen geschützt sein.

Viele nichtfunktionale Anforderungen gelten heutzutage als selbstverständlich und

tauchen deshalb meist in keinem Anforderungsdokument mehr explizit auf. Etwa der

Aspekt der Zuverlässigkeit (Stabilität und Wiederherstellbarkeit) gilt für alle Software-

systeme im unternehmerischen Umfeld und kann als obligatorisch angesehen wer-

den. Andere nichtfunktionale Anforderungen haben das Problem, dass sie nicht klar

definiert werden können, beispielsweise die Wartbarkeit eines Systems. Aus der un-

terschiedlichen Qualifikationen der Mitarbeiter ergeben sich hier immer andere Be-

trachtungen. Für diese Arbeit werden daher nur die drei oben genannten Aspekte als

weitere Prüfkriterien betrachtet.

Kapitel 3 - Testen während der Entwicklung

3. Testen während der Entwicklung

In diesem Kapitel wird analysiert, was die Besonderheiten bei der Entwicklung von

Data Warehouse und Business Intelligence Systemen sind und welche Fehlersituati-

onen in der Praxis typischerweise auftreten können. Auf Basis der Besonderheiten

und der Fehlersituationen wird dann analysiert, welche Prüftechniken sich anwenden

lassen. Abschließend folgt eine Bewertung der Anwendbarkeit der Prüftechniken.

Übersicht 3. Testen während der Entwicklung ...................................................................... 41

3.1. Allgemeine Besonderheiten bei der Entwicklung ............................................ 42

3.2. Multidimensionale Modellierung ...................................................................... 44

3.3. Datenintegration ............................................................................................. 50

3.4. Data Warehouse ............................................................................................. 66

3.5. OLAP-System ................................................................................................. 71

3.6. Reporting Front-End ....................................................................................... 82

3.7. Automatisierungssystem ................................................................................. 87

3.8. Bewertung ....................................................................................................... 91

3 Kapitel 3

Testen während der Entwicklung


3.1. Allgemeine Besonderheiten bei der Entwicklung BIS und DWS stellen ähnlich wie Standardsoftware (z.B. SAP, Siebel) eine Beson-

derheit in der Informatik dar und unterscheiden sich in vielen Punkten von der klassi-

schen Programmierung proprietärer Software. Im Folgenden werden die wichtigsten

Besonderheiten und Unterschiede näher erläutert.

3.1.1. Softwareentwicklungsprozess

Auf den ersten Blick folgt die Implementierung der Komponenten eines BIS einem

einfachen chronologischen Ablauf:

Abbildung 3-1: Softwareentwicklungsprozess [Eigene Darstellung]

Das Wasserfallmodell oder das V-Modell scheinen somit auch geeignete Modelle für

den Entwicklungsprozess zu sein. Diese strikte Folge setzt jedoch voraus, dass alle

Anforderungen von vornherein bekannt und definiert sind. In der Praxis zeigt sich

jedoch, dass diese idealtypischen Voraussetzungen oft nicht gegeben sind. Ein häu-

figes Problem besteht darin, dass der Auftraggeber (z.B. eine Vertriebsabteilung)

seine Anforderungen nicht genau genug spezifizieren kann. So fehlen vielen Anwen-

dern entweder die Erfahrung mit der Multidimensionalität von OLAP-Systemen (Was

ist eine Dimension? Was ist eine Kennzahl?) oder es kann dem Entwickler lediglich

eine Menge von fachlichen Kennzahlen und Dimensionen genannt werden, wobei die

Beschreibung, wie und woher diese Daten beschafft werden, fehlt17.

Um ein Verständnis der Quelldaten zu erhalten, müssen die Daten gemeinsam mit

dem Auftraggeber und dem Verantwortlichen des Quellsystems untersucht und ana-

17 Im schlimmsten Fall kann die Spezifikation des Anwenders lauten: „Attribut x vom operativen Sys-

tem auf der Eingabemaske oben links.“


lysiert werden. Dieses „Kennenlernen“ und „Verstehen“ der Daten wird auch als Data

Profiling bezeichnet:

„Data profiling is a systematic examination of the quality, scope, and context of

a data source [...]“ [Kim04, S. 5]

Aus den Data Profiling Ergebnissen werden die Anforderungen für Datenqualitätsre-

geln abgeleitet. Aber selbst mit Data Profiling Techniken werden nicht immer alle Da-

tenkonstellationen im Vorfeld aufgedeckt. Manche Fälle treten erst bei einem initialen

Testlauf des Datenintegrationsprozesses auf. Eine Nichtvorhersehbarkeit von Daten-

konstellationen tritt gerade bei historisch gewachsenen Legacy-Systemen auf. Diese

Systeme wurden im Laufe der Zeit von einer Vielzahl von Entwicklern angepasst,

wodurch unter Umständen kein vollständiges Wissen über die Funktionsweise und

das Datenmodell des Systems vorliegt.

Es erscheint günstiger, bei der Entwicklung auf ein prototypisches Vorgehensmodell

zurückzugreifen. [vgl. Gol11, S. 1184] Dementsprechend wird zunächst ein Modell

aufgestellt und implementiert, das den Kernanforderungen entspricht. Sowohl der

Auftraggeber als auch der Entwickler können somit schnell erste Erkenntnisse sam-

meln und mögliche Missverständnisse, Designfehler oder nichtumsetzbare Anforde-

rungen frühzeitig erkennen.

3.1.2. Tätigkeiten eines Entwicklers

Innerhalb von BIS und DWS wird keine operative Geschäftslogik angewendet, son-

dern bestehende operative Daten werden analytisch verarbeitet. Ein Großteil der

Entwicklungstätigkeiten entfällt hierbei auf das Modellieren und Implementieren von

relationalen (Sternschema) und multidimensionalen (OLAP-Würfel) Datenmodellen.

Die Implementierung von Verarbeitungslogik beschränkt sich auf einfache Datenma-

nipulationen innerhalb der Datenintegrationsprozesse.

Da es sich bei der Datenverarbeitung in der Regel um einfache und immer wieder-

kehrende Funktionen handelt (z.B. Zeichenkettenfunktionen, mathematische Grund-

rechenarten), haben sich zunehmend standardisierte Datenintegrationswerkzeuge

durchgesetzt. [vgl. Sch07, S. 15ff] Diese bieten über eine grafische Oberfläche die

Möglichkeit einer prozessgetriebenen Entwicklung, wobei der Entwickler aus einer

Palette alle benötigten Funktionen kombinieren kann. Die Implementierung besteht


bei der Verwendung eines Datenintegrationswerkezug nicht aus dem Schreiben von

Programmcode, sondern dem Zusammenfügen und Konfigurieren von Funktions-

bausteinen. Der Implementierungsansatz der Datenintegration mittels klassischer

Programmiersprachen soll in dieser Arbeit nicht weiter betrachtet werden.

Auch OLAP-Systeme werden von den Herstellern mit grafischen Administrations-

werkzeugen ausgeliefert. Diese ermöglichen es, einen Würfel dialoggesteuert anzu-

legen und zu verwalten.

Die dispositiven Daten werden turnusmäßig aktualisiert. Damit die entsprechenden

Datenintegrations-Prozesse nicht manuell angestoßen werden müssen, folgt die

Übernahme in eine automatisierte Ablaufsteuerung. Somit muss ein Entwickler die

zusammengehörigen Arbeitsschritte zu Batch-Jobs bündeln und zeitlich einplanen.

3.1.3. Unterschiede beim Testen

Anhand der beschriebenen Entwicklungstätigkeiten lässt sich bereits erkennen, dass

sich das Testen ebenfalls von der klassischen Softwareentwicklung unterscheidet.

Wie schon erwähnt implementieren BIS keine Geschäftslogik bzw. Geschäftsprozes-

se, sondern Datenaufbereitungen in ein analytisches Format. Es gibt also keine

komplexen Anwendungsfälle, die getestet werden müssen. Da der Großteil der Im-

plementierung über grafische Werkzeuge, steht nicht das Überprüfen von Quellcode

im Vordergrund, sondern das Überprüfen von richtigen Konfigurationen.

3.2. Multidimensionale Modellierung Im Abschnitt 2.2.1 wurde gezeigt, dass die Hälfte aller Fehler schon bei der Analyse

und dem Entwurf von Softwaresystemen entsteht. Somit wird in diesem Abschnitt

zunächst analysiert, wie schon bei der Modellierung von BIS getestet werden kann.

3.2.1. Besonderheiten der multidimensionalen Modellierung

Der Ausgangspunkt für die Bereitstellung von Daten im BIS ist immer eine betriebs-

wirtschaftliche, auswertungsorientierte Fragestellung. Eine solche Frage (auch The-

ma genannt [vgl. Koe09, S. 15]) aus einer Controlling-Abteilung kann etwa lauten:

„Analysiere die Anzahl abgeschlossener Versicherungen, die eingenommenen Bei-


träge und die durchschnittlichen Beiträge pro Kombination aus Versicherungspro-

dukt, Absatzgebiet und Zeit.“ Hier lässt sich bereits die Multidimensionalität bzw. die

Unterscheidung von Dimensionen und Fakten erkennen:

Fakten Dimensionen Anzahl abgeschlossene Versicherungen Produkt

Eingenommene Beiträge Absatzgebiet

Durchschnittlicher Beitrag Zeit

Tabelle 3-1: Fakten und Dimensionen [Eigene Darstellung]

Das Ziel bei der Entwicklung ist immer ein OLAP-Würfel. Die Fragestellung gibt die

Grundstruktur des Würfels bereits vor. Wie im Abschnitt 3.1 erwähnt, ist es leider

nicht immer der Fall, dass ein Auftraggeber exakt weiß, was er möchte. Wenn der

Auftraggeber ein klares Vorstellungsbild seiner Analyseanforderungen hat, so kann

dies bei der Aufnahme der Anforderungen zu sehr großen Missverständnissen zwi-

schen der Informatik und den Fachbereichen führen.

3.2.2. Prüftechniken für die multidimensionale Modellierung

Um Unklarheiten sowie Missverständnisse zu beseitigen, bietet es sich sehr an, auf

altbewährte Mittel der Softwareentwicklung zurückzugreifen: visuelle Hilfsmittel.

Bei der Zusammenarbeit mit einem analytisch unerfahrenen Auftraggeber ist es

sinnvoll, dass Entwickler und Auftraggeber gemeinsam einen Mock-Up-Bericht er-

stellen, beispielsweise in Excel. Anhand des Berichts kann dann die analytische Fra-

gestellung samt Dimensionen und Fakten abgeleitet werden. Bei der gemeinsamen

Erarbeitung und Analyse der Anforderungen ist es ungemein wichtig, dass beide Sei-

ten eine gemeinsame (fachlich semantische) Sprache sprechen. Neben Mock-Up-

Berichten empfiehlt sich ebenso die Anfertigung eines Glossars, in dem die Fachbe-

griffe für beide Seiten verständlich beschrieben sind. [vgl. Gol11, S. ] In dem Beispiel

der Tabelle 3-1 würde das Glossar etwa aufdecken, dass sich der durchschnittliche

Beitrag aus dem eingenommenen Beiträgen dividiert durch die Anzahl der verkauften

Versicherungen ergibt.


Abbildung 3-2: ADAPT-Modell [Eigene Darstellung]

Mit der Fragestellung ist jedoch nur die Grundstruktur mit Dimensionen und Fakten

gegeben. Aussagen zu den Hierarchien innerhalb der Dimensionen sind dadurch

noch nicht getroffen. Somit folgt als nächstes eine detaillierte Analyse der einzelnen

Dimensionsstrukturen. Eine de-facto Standardsprache für die Modellierung von kon-

zeptionellen multidimensionalen Modellen, wie die UML für objektorientierte Soft-

ware, gibt es bisher nicht. Herden [vgl. Her01, S. 19ff] stellt in seiner Arbeit insge-

samt sechs verschiedene multidimensionale Modellierungssprachen vor:

• Multidimensional E/R Model

• starER-Model

• Application Design for Analytical Processing (ADAPT)


• Dimensional Fact Model

• Multidimensional Data Model

• Multidimensional Aggregation Cube Model

Jedes der Modelle hat seine Vor- und Nachteile. Die Sprache ADAPT bietet bei-

spielsweise sehr einfache Möglichkeiten, die Beziehungen von Kennzahlen, Dimen-

sionen, Dimensionshierarchien und berechneten Kennzahlen darzustellen. Im An-

hang B findet sich eine Übersicht der ADAPT-Notation, in der Abbildung 3-2 ist das

Beispiel des Versicherungsgeschäfts exemplarisch modelliert. So ein konzeptionelles

Modell bietet nicht nur den Vorteil, dass ein gemeinsamer Standpunkt für Auftragge-

ber und Entwickler geschaffen wurde, sondern es dient dem Entwickler gleichzeitig

als Vorlage für die Implementierung der physikalischen DW-Tabellen (Sternschema)

und des OLAP-Würfels.

Abbildung 3-3: Standarddimension Zeit [Eigene Darstellung]

Mithilfe einer Stilanalyse kann untersucht werden, inwiefern der Entwurf den Konven-

tionen oder den Best Practices genügt. [vgl. Gol11, S. 1189] So ist es sehr wahr-

scheinlich, dass die Dimensionen „Absatzgebiet“ und „Zeit“ bereits in anderen The-

men verwendet werden und somit schon existieren. Das neue Thema muss sich ent-

sprechend an diese Standarddimensionen halten, um einen Wildwuchs von ähnli-


chen Dimensionen zu vermeiden. Die unternehmensweite Zeitdimension kann bei-

spielsweise als zusätzliche Hierarchieebene das Quartal beinhalten und zu den ein-

zelnen Tagen die Information, ob es sich um einen Feiertag handelt (Abbildung 3-3).

In diesem Fall kann auch auf die Standarddimension zurückgegriffen werden, weil

sie die gleiche Bedeutung hat wie die im Entwurf aufgestellte Zeitdimension. Sie ist

mit der zusätzlichen Quartalsebene sogar noch detaillierter und bietet die Kalender-

woche als alternativen Drill-Pfad.

Golfarelli und Rizzi [Gol11] nennen in ihrem Artikel zum Testen von multidimensiona-

len Modellen als Prüftechnik den sogenannten Konformitätstest. Der Test basiert auf

zwei Metriken und misst damit die Wohlgeformtheit der Dimensionen. Als Metriken

werden der Konformitätsfaktor 𝑐𝑓 und der Gleichheitsfaktor 𝑠𝑓 ermittelt. Der Konfor-

mitätsfaktor gibt Auskunft zur durchschnittlichen Wiederverwendung von Dimensio-

nen über alle Würfel:

Sei𝐹dieMengeallerWürfelund𝐷dieMengeallerDimensionen. Danngilt:

𝑐𝑓 =1|𝐷| ∙

|𝑓 ∈ 𝐹: 𝑑 ∈ 𝐷𝑖𝑚(𝑓)||𝐹| ∈ \

1|𝐹|…1]

wobei𝐷𝑖𝑚(𝑓) ⊆ 𝐷eineTeilmengederimWürfel𝑓genutztenDimensionenist.

Formel 3-1: Konformitätsfaktor [Gol11, S. 1186]

Je niedriger der Konformitätsfaktor ist, umso spärlicher18 ist die Wiederverwendung

von Dimensionen bzw. umso höher ist der Wildwuchs von Dimensionen. In diesem

Fall empfiehlt es sich, darüber nachzudenken, semantisch gleiche Dimensionen zu-

sammenzuführen. Umgekehrt bedeutet ein sehr hoher Konformitätsfaktor um 1, dass

die Würfel strukturell sehr ähnlich oder sogar gleich sind und entsprechend zusam-

mengeführt werden können. In der Tabelle 3-2 ist exemplarisch eine Bus-Matrix für

drei Würfel und acht Dimensionen gegeben. Zu der Tabelle ergibt sich als Konformi-

tätsfaktor:

𝑐𝑓 =18 ∙3 + 6 + 5

3 =18 ∙143 ≈ 0,58

18 Auch engl.: Sparse


Versicherungsgeschäft Vertriebsstatistik Schadenstatistik

Geschäftsbereich ✔ ✔

Vertriebsart ✔

Organigramm ✔

Produkt ✔ ✔ ✔

Absatzgebiet ✔ ✔

Schadenart ✔

Vermittler ✔

Zeit ✔ ✔ ✔

Tabelle 3-2: Bus-Matrix [Eigene Darstellung]

Der Gleichheitsfaktor dient als Indikator, ob ein Würfel möglicherweise in einem an-

deren Würfel enthalten ist und somit aus diesem abgeleitet werden kann:

Seien𝑓und𝑔zweiWürfel.Dannergibtsich:

𝑠𝑓(𝑓, 𝑔) =|𝐷𝑖𝑚(𝑓) ∩ 𝐷𝑖𝑚(𝑔)|

|𝐷𝑖𝑚(𝑓)| ∈ [0…1]

Formel 3-2: Gleichheitsfaktor [Gol11, S. 1188]

Die Ergebnisse von 𝑠𝑓(𝑓, 𝑔) und 𝑠𝑓(𝑔, 𝑓) lassen sich in einem Quadranten darstellen

(Abbildung 3-4). Für das Beispiel aus der Tabelle 3-2 ergeben sich als Gleichheits-

faktoren für die Würfel „Versicherungsgeschäft“ und „Vertriebsstatistik“:

𝑠𝑓(𝑉𝑒𝑟𝑠𝑖𝑐ℎ𝑒𝑟𝑢𝑛𝑔𝑠𝑔𝑒𝑠𝑐ℎä𝑓𝑡, 𝑉𝑒𝑟𝑡𝑟𝑖𝑒𝑏𝑠𝑠𝑡𝑎𝑡𝑖𝑠𝑡𝑖𝑘) =33 = 1

𝑠𝑓(𝑉𝑒𝑟𝑡𝑟𝑖𝑒𝑏𝑠𝑠𝑡𝑎𝑡𝑖𝑠𝑡𝑖𝑘, 𝑉𝑒𝑟𝑠𝑖𝑐ℎ𝑒𝑟𝑢𝑛𝑔𝑠𝑔𝑒𝑠𝑐ℎä𝑓𝑡) =26 = 0,5

Daraus wird ersichtlich, dass der Würfel „Versicherungsgeschäft“ eine Teilmenge des

Würfels „Vertriebsstatistik ist. Somit muss geprüft werden, ob der neue Würfel Versi-

cherungsgeschäft überhaupt benötigt wird und ob der bestehende Würfel Vertriebs-

statistik wieder verwendet werden kann.


𝑠𝑓(𝑔, 𝑓)

1

𝑓 ⊃ 𝑔 𝑓 ≡ 𝑔

𝑓 ≠ 𝑔 𝑓 ⊂ 𝑔

0 1

𝑠𝑓(𝑓, 𝑔)

Abbildung 3-4: Gleichheitsfaktorquadrant [Gol11, S. 1188]

3.3. Datenintegration Die Datenintegration ist die Übertragung der Daten aus den Quellsystemen in das

DWS. Die Integration besteht zum einen aus dem Zugriff auf die zu integrierenden

Daten und zum anderen aus dem Prozess der Integration dieser Daten.

3.3.1. Besonderheiten der Datenintegration

3.3.1.1 Funktionale Besonderheiten der Datenintegration Durch Schnittstellen wird die Verbindung zwischen einem Quellsystem und dem

DWS hergestellt. Handelt es sich bei der Schnittstelle um einen direkten Zugriff, so

werden die Daten aus den produktiven Tabellen des operativen Systems gelesen.

Bei einem indirekten Zugriff wird von dem operativen System ein Datenabzug bereit-

gestellt. Je nach Quellsystem kann der Abzug in verschiedenen Formaten vorliegen:

als Tabelle, als View, als Text-Datei oder als Datei in einem Spezialformat. Eine Feh-

lerquelle der Schnittstelle ist das Einlesen von Spezialformaten.

Als Standard- bzw. Trivialformate gelten relationale Tabellen als auch strukturierte

Text-Dateien im CSV- oder XML-Format. Ein Spezialformat ist beispielsweise ein

COBOL Copybook, welches sich im Bereich von Mainframe-Anwendungen finden

lässt und gerade bei Versicherungs- und Finanzunternehmen eine hohe Verbreitung

hat. Die Komplikation bzw. Komplexität bei Copybooks entsteht hauptsächlich durch


Mehrfachdefinitionen (Redefinitionen) von Teilbereichen eines Datensatzes und die

daraus resultierenden Mehrfachstrukturen. Im Listing 3-1 ist exemplarisch eine

Schnittstelle für Versicherungsschäden als Copybook implementiert. Je nach Versi-

cherungsprodukt (Kraftfahrt oder Privathaftpflicht) enthält die Struktur entweder die

spezifischen Attribute „HSN“, „TSN“ und „SF-Klasse“ bzw. „Grobfahrlässig“ und

„Selbstbeteiligung“. Für die Unterscheidung, ob es sich bei einem Datensatz um ei-

nen Kraftfahrt- oder um einen Privathaftpflicht-Datensatz handelt, muss in dem Da-

tenintegrationsprozess die entsprechende Logik implementiert werden.

01 02 03 04 05 06 07 08 09 10 11 12 13 14

01 SCHADEN-SCHNITTSTELLE. 05 VERSICHERUNGSSCHEIN-ID PIC 9(10). 05 SCHADEN-ID PIC 9(05). 05 EREIGNIS-DATUM PIC 9(08). 05 VERSICHERUNGSPRODUKT PIC 9(03). 05 KRAFTFAHRT. 10 HSN PIC X(04). 10 TSN PIC X(08). 10 SF-KLASSE PIC X(02). 05 PRIVATHAFTPFLICHT REDEFINES KRAFTFAHRT. 10 GROBFAHRLAESSIG PIC X(06). 10 SELBSTBETEILIGUNG PIC X(06). 05 ZAHLUNG PIC S9(9)V99. 05 RESERVE PIC S9(9)V99.

Listing 3-1: COBOL Copybook [Eigene Darstellung]

Die Säuberung der eingelesenen Daten geschieht durch das Anwenden von Quali-

tätsregeln sowie das Reagieren auf Verletzungen der Regeln. Damit ergeben sich als

mögliche Fehler das falsche Anwenden der Qualitätsregeln sowie das falsche Rea-

gieren auf die Verletzung von Regeln. [vgl. The07, S. 2f; Kam10, S. 9f] Die Qualitäts-

regeln lassen sich einteilen in technische Qualitätsregeln sowie fachliche Qualitäts-

regeln. Die fachlichen Qualitätsregeln werden vom Fachbereich bzw. Auftraggeber

vorgegeben und beziehen sich auf die fachlichen Inhalte der Daten und ob diese in

sich stimmig sind. Einfache Regeln können etwa lauten, dass die Postleitzahl zu ei-

nem Ort passen muss, ein Kunde mit „Gold-Status“ auch tatsächlich den dafür benö-

tigten Umsatz erreicht hat oder zu einer Warenlieferung auch eine Bestellung vor-


liegt. Die Regeln müssen spezifiziert sein und werden dann vom Entwickler imple-

mentiert. Aus technischer Sicht werden darüber hinaus noch weitere Regeln ange-

wendet. Der gesamte Integrationsprozess stützt sich auf ein fest definiertes Format

der Daten, bestehend aus Datentypen und -längen, Genauigkeiten von Dezimalwer-

ten oder das Vorkommen von NULL-Werten. Wird das Format nicht eingehalten,

bricht der Prozess im günstigsten Fall mit einem harten Programmfehler ab, etwa

einer NULL-Pointer-Exception oder mit einer Format-Exception bei einem alphanu-

merischen Wert in einem numerischen Feld. Schlimmer hingegen können Fehler

aufgrund von zu kurzen oder zu ungenauen Datentypdefinitionen sein. Da es sich bei

den verarbeiteten Kennzahlen häufig um Geldbeträge handelt, ist eine absolute Ge-

nauigkeit der Zahlen unerlässlich. In Listing 3-2 sowie in Abbildung 3-5 ist ein Bei-

spiel gegeben, in dem es bei einer Gleitkommazahl vom Typ Float zu einem ab-

weichenden Wert kommt. Eine solche Wertezuweisung führt jedoch nicht zwingend

zu einem Programmabbruch. Daher müssen Regeln angewendet werden, mit denen

die Daten auf die Einhaltung ihrer Typendefinition geprüft werden. Entstehen können

Formatabweichungen vor allem, wenn das Quellsystem seine Schnittstellendaten als

Text-Datei bereitstellt, weil diese im Gegensatz zu einer Datenbanktabelle keine

Typsicherheit garantieren können.

01 02 03 04

Float f = new Float(1234567.89); Double d = new Double(1234567.89); System.out.println("Float : " + f); System.out.println("Double: " + d);

Listing 3-2: Ungenauigkeit bei Gleitkommazahlen [Eigene Darstellung]

Abbildung 3-5: Ungenauigkeit bei Gleitkommazahlen [Eigene Darstellung]


Auf die Verletzung einer Regel kann auf vier verschiedene Weisen reagiert werden:

[vgl. Kem10, S. 25]

• Autokorrektur des Datensatzes

• Aussteuerung des Datensatzes zur manuellen Nachbesserung

• Sofortiger Abbruch des gesamten Prozesses

• Bedingter Abbruch nach Überschreitung einer Anzahl von Regelverletzungen

Eine Autokorrektur ist bei dem oben genannten Beispiel des Kundenstatus nach Um-

satz möglich: Der Kunde bekommt bei einem zu geringen Umsatz automatisch den

entsprechenden niedrigeren Status zugeordnet. Eine Aussteuerung ist hingegen bei

der falschen Zuordnung von Postleitzahl und Ort nötig, da nicht automatisch erkenn-

bar ist, ob nun die Postleitzahl oder der Ort der eigentlich korrekte Wert ist. Bei den

technischen Regeln wird es hingegen bei einer Verletzung zu einem Prozessabbruch

kommen. Ein bedingter Abbruch kann dabei unterschiedlich formuliert sein, zum Bei-

spiel dass ab einer bestimmten Anzahl regelwidriger Sätze pro aktueller Lieferung

abgebrochen werden soll oder wenn im Vergleich zur vorherigen Datenlieferung sig-

nifikant mehr Regelverstöße vorliegen. Dafür muss die Anzahl der Regelverstöße

entsprechend protokolliert werden.

Für die Harmonisierung werden sogenannte Mapping-Tabellen verwendet, um die

verschiedenen Schlüssel der Quellsysteme zu vereinheitlichen. [vgl. Kim04, S. 48]

Für jedes System gibt es eine Spalte in der Mapping-Tabelle sowie eine Übersetzung

der Schlüsselausprägungen in das einheitliche Format. In der Tabelle 3-3 ist exemp-

larisch eine Mapping-Tabelle für verschiedene Schlüssel des Geschlechts gegeben.

Mittels einem einfachen JOIN über die Spalte des Quellsystems kann nun der jeweils

gültige einheitliche Schlüssel abgefragt werden. Als möglicher Fehler kann während

der Harmonisierung daher das Nicht-Auffinden eines Schlüssels auftreten, etwa

wenn der JOIN über eine falsche Spalte stattfindet oder aber die Schlüsselüberset-

zungen für ein Quellsystem noch nicht eingetragen sind.

Einheitlicher Schlüssel Quellsystem 1 Quellsystem 2 Quellsystem ... M m männlich ...

W f weiblich ...


Tabelle 3-3: Mapping-Tabelle [Eigene Darstellung]

Der Aufbau der multidimensionalen Datenstruktur (Sternschema) geschieht in zwei

Schritten: Zuerst werden die Dimensionstabellen erstellt, anschließend die Faktenta-

bellen. Beim Erstellen der Dimensionstabellen ist zu beachten, wie Veränderungen

innerhalb von Dimensionen behandelt werden sollen. Im einfachsten Fall ist eine Di-

mension fix und ändert sich nicht, zum Beispiel besteht ein Jahr immer aus vier

Quartalen, die Quartale jeweils aus drei Monaten. Bei der Produktdimension kann es

jedoch passieren, dass sich die Produktgruppe eines Produktes ändert. Kimball et al.

[vgl. Kim04, S. 183ff] nennen diese Problematik Slowly Changing Dimensions (SCD)

und geben dafür drei Lösungsszenarien vor: Der geänderte Wert in der Dimension

wird überschrieben (Typ 1), der geänderte Wert wird als neuer Satz in die Dimensi-

onstabelle aufgenommen und mit einem Zeitstempel versehen (Typ 2) oder für den

geänderten Wert wird eine neue Spalte in die Dimensionstabelle eingefügt (Typ 3).

Es muss also geprüft werden, ob das Verfahren der sich ändernden Dimensionen

korrekt angewendet wird. [vgl. Rai08, S. 481] In der folgenden Tabelle ist das Vorge-

hen bei einer Typ 2 SCD für die Organigrammdimension exemplarisch angedeutet.

SurrogatKey ID Name Job GueltigVon GueltigBis 2132 11514 Max Mustermann Student 01.09.2003 31.08.2006

5929 11514 Max Mustermann Entwickler 01.09.2006 31.05.2011

9284 11514 Max Mustermann Manager 01.06.2011 31.12.9999

Tabelle 3-4: Typ 2 SCD [Eigene Darstellung]

3.3.1.2 Nichtfunktionale Besonderheiten der Datenintegration Ein Datenintegrationsprozess muss in einem vorgegebenen Zeitfenster (z.B. nachts

von 1 Uhr bis 3 Uhr) abschließen, weil ansonsten abhängige Folgeprozesse wie die

Berechnung der OLAP-Würfel nicht rechtzeitig starten können. Somit ist auch das

Überprüfen der Ausführungsgeschwindigkeit sehr wichtig. Hierbei muss auch analy-

siert werden, wie der Integrationsprozess auf größere Datenmengen reagiert. [vgl.

Rai08, S. 482ff; The07, S. 3]


Durch die Datenintegrationsprozesse werden die Informationen aus den verschiede-

nen Quellsystemen zusammengespielt und aufbereitet. Aus Gründen der Revisions-

sicherheit ist deshalb besonders auf die Benutzbarkeit in Form der Dokumentation zu

achten. Gerade im Versicherungs- und Finanzsektor, wo besonders strenge Rege-

lungen von Aufsichtsbehörden existieren, muss gewährleistet sein, dass bei einer

Überprüfung der Datenintegrationsprozesse durch einen Wirtschaftsprüfer eine Do-

kumentation der Prozesse vorgewiesen werden kann. Es muss für fachkundige Dritte

belegt werden können, woher die Daten ursprünglich kommen und wie und warum

sie in den Prozessen verarbeitet werden.

3.3.2. Prüftechniken für die Datenintegration

3.3.2.1 Funktionale Prüftechniken für die Datenintegration Für das Testen der Spezialformate bietet sich die Äquivalenzklassenbildung an. Im

oben genannten Beispiel der Versicherungsschäden als COBOL Copybook kann ein

Datensatz entweder zu dem Versicherungsprodukt „Kraftfahrt“ oder „Privathaftpflicht“

gehören. Das hierfür ausschlaggebende Attribut „Versicherungsprodukt“ muss abge-

fragt werden und daraus die entsprechend gültige Redefinition beim Einlesen ange-

wendet werden. Die Unterscheidungsregel kann etwa lauten, dass die Versiche-

rungsproduktausprägungen 100, 101 und 102 einen Privathaftpflichtschaden darstel-

len und die Ausprägungen 200, 201 und 202 einen Kraftfahrtschaden. Somit ergeben

sich dafür zwei Äquivalenzklassen. Gerade bei solchen Legacy-Dateien kann unter

Umständen nicht garantiert werden, dass die Schlüsselausprägungen genau in den

beiden genannten Wertebereichen liegen. Mögliche „Datenleichen“ können mit ande-

ren Ausprägungen auftauchen und müssen folglich ausgesteuert werden. Für diese

ungültigen bzw. unbekannten Datensätze ergibt sich eine dritte Äquivalenzklasse:

Produkt Äquivalenzklassen Repräsentant Privathaftpflicht 𝑃 = {100,101,102} 101

Kraftfahrt 𝐾 = {200,201,202} 202

Unbekannt 𝑈 = ((𝑥 ∈ {0, … ,999}) ∧ (𝑥 ∉ (𝑃 ∪ 𝐾))) 303

Tabelle 3-5: Äquivalenzklassen für COBOL Copybook [Eigene Darstellung]


In der Abbildung 3-6 ist das Einlesen des Copybooks exemplarisch angedeutet (im-

plementiert in dem Datenintegrationswerkzeug Talend19). Das Copybook (eine im

EBCDIC-Format kodierte Datei) wird eingelesen und je nach Ausprägung der Spalte

„Versicherungsprodukt“ in eine Staging-Tabelle geschrieben. Die Unterscheidungs-

regeln führen einfache Wertvergleiche durch und sind in Java-Syntax implementiert.

Unbekannte Datensätze werden in einer CSV-Datei protokolliert. Wenn der Job mit

den drei Repräsentanten ausgeführt wird, muss jeweils ein Datensatz in den beiden

Tabellen geschrieben worden sein und ein Datensatz in der CSV-Datei protokolliert

worden sein.

Abbildung 3-6: Einlesen eines COBOL Copybooks (Talend) [Eigene Darstellung]

Für das Überprüfen der Datenqualitätsregeln können der Ursache-Wirkungs-Graph

und Entscheidungstabellen herangezogen werden. Jede Regel entspricht dabei einer

Ursache. Ob ein Datensatz übernommen oder verworfen wird sind die zwei mögli-

chen Wirkungen. Werden bei den abgewiesenen Datensätzen Schwellwerte über-

wacht oder Autokorrekturen angewendet, ergeben sich hierdurch zusätzliche Ursa-

chen und Wirkungen. 19 Weitere Informationen unter http://www.talend.com (Abgerufen 01.01.2012)


Die Regeln haben oftmals einen aufeinander aufbauenden Charakter. Gestartet wird

mit den syntaktischen Qualitätsregeln, denn diese bilden den Grundstein dafür, dass

ein Datensatz überhaupt weiterverarbeitet werden kann und harte Programmabbrü-

che (etwa NULL-Pointer) während des Datenintegrationsprozesses ausgeschlossen

werden. Darauf folgen die semantischen Regeln, die beispielsweise prüfen, ob er-

laubte Wertebereiche eingehalten wurden. Nur wenn alle Regeln eingehalten wer-

den, wird der Datensatz zur weiteren Verarbeitung übernommen. Andernfalls wird

der Datensatz abgewiesen und protokolliert. Eine exemplarische Implementierung

eines solchen Ablaufes sowie die Umsetzung der syntaktischen Schemaüberprüfung

(Datentypen, Längen, NULL) ist in der Abbildung 3-7 dargestellt. Dabei wird bei der

Überschreitung von Schwellwerten der gesamte Ablauf abgebrochen.

Abbildung 3-7: Datenqualitätsregeln (Talend) [Eigene Darstellung]

Für dieses Beispiel ergeben sich drei Wirkungen und vier Ursachen:

• Wirkungen

o W1 : ein Datensatz wird übernommen


o W2 : ein Datensatz wird ausgesteuert

o W3 : die Verarbeitung wird abgebrochen

• Ursachen

o U1 : ein Datensatz entspricht dem Schema

o U2 : ein Datensatz entspricht dem Wertebereich

o U3 : ein Datensatz entspricht der Regel „...“

o U4 : ein Schwellwert wird überschritten

Die Zusammenhänge der Ursachen und Wirkungen lauten wie folgt: Ein Datensatz

wird genau dann übernommen (W1), wenn alle Regeln eingehalten wurden (U1 bis U3

erfüllt) und der Schwellwert nicht überschritten wurde (U4 nicht erfüllt). Ein Datensatz

wird abgelehnt (W2), sobald eine Regel nicht eingehalten wurde (U1 oder U2 oder U3

nicht erfüllt). Der Prozessabbruch (W3) erfolgt, sobald der Schwellwert überschritten

wurde (U4). Abbildung 3-8 zeigt einen entsprechenden Ursache-Wirkungs-Graphen

und die Tabelle 3-6 die daraus abgeleitete Entscheidungstabelle mit insgesamt fünf

Testfällen.

Abbildung 3-8: Ursache-Wirkungs-Graph - Qualitätsregeln [Eigene Darstellung]


Ursachen U1 Schema eingehalten - J - - J

U2 Wertebereich eingehalten - - J - J

U3 Regel „...“ eingehalten - - - J J

U4 Schwellwert überschritten J N N N N

Wirkungen W1 Datensatz übernehmen N N N N J

W2 Datensatz aussteuern N J J J N

W3 Verarbeitung abbrechen J N N N N

T1 T2 T3 T4 T5

Tabelle 3-6: Entscheidungstabelle - Qualitätsregeln [Eigene Darstellung]

Die Überprüfung der Harmonisierung und der Übersetzung in das Sternschema (in-

klusive SCD) als auch die Überprüfung der korrekten Aggregation können ebenfalls

über Ursache-Wirkungs-Graphen und Entscheidungstabellen durchgeführt werden.

Die Ursachen bei der Harmonisierung und Dimensionsverarbeitung können sein,

dass ein Schlüssel in der Mapping- bzw. Dimensionstabelle entweder gefunden wird

oder nicht. Als Wirkungen ergibt sich dann das entsprechende Umsetzen des

Schlüssels.

Für eine Typ 1 SCD gelten beispielsweise folgende Ursachen und Wirkungen:

• Ursachen

o U1 : zu einer ID existiert ein Eintrag in der Dimensionstabelle

o U2 : ein Attribut zu einer ID hat sich geändert

• Wirkungen

o W1 : ein neuer Eintrag wird in der Dimensionstabelle eingefügt

o W2 : bestehender Eintrag in der Dimensionstabelle wird aktualisiert

o W3 : bestehender Eintrag in der Dimensionstabelle wird übernommen

Die Zusammenhänge lauten: Wenn zu einer ID noch kein Eintrag in der Dimensions-

tabelle existiert (U1 nicht erfüllt), wird ein neuer Eintrag in die Dimensionstabelle ein-

gefügt (W1). U1 ist erforderlich für U2, denn ein Attribut kann sich nur geändert haben,

wenn es zu der ID bereits einen Eintrag gegeben hat. Bei einer Attributänderung (U2


erfüllt) wird der Eintrag in der Dimensionstabelle aktualisiert (W2) bzw. wenn keine

Änderung erfolgt (U2 nicht erfüllt), wird der bestehende Eintrag übernommen (W3). In

der folgenden Abbildung ist der resultierende Ursache-Wirkungs-Graph gegeben. Die

Tabelle 3-7 zeigt die Entscheidungstabelle mit drei Testfällen.

Abbildung 3-9: Ursache-Wirkungs-Graph - Typ 1 SCD [Eigene Darstellung]

Ursachen U1 Eintrag existiert bereits N J J

U2 Attribut hat sich geändert - J N

Wirkungen W1 Neuer Eintrag J N N

W2 Eintrag aktualisieren N J N

W3 Eintrag übernehmen N N J

T1 T2 T3

Tabelle 3-7: Entscheidungstabelle - Typ 1 SCD [Eigene Darstellung]

Die Struktur eines Datenintegrationsprozesses wie in Abbildung 3-7 stellt einen Kon-

trollfluss dar. Die Orchestrierung der verschiedenen Funktionsbausteine ergibt die

Knoten und Kanten des Kontrollflussgraphen. Durch die Verwendung eines grafi-

schen Datenintegrationswerkzeuges wird der Kontrollflussgraph automatisch gene-

riert bzw. die Implementierung geschieht kontrollflussorientiert. Somit kann der Da-

tenintegrationsprozess auch kontrollflussorientiert überprüft werden. Der Grundge-


danke bei dieser Prüftechnik ist die Bewertung der Abdeckung der Strukturelemente

des Datenintegrationsprozesses durch Testfälle. Eine einfache Forderung an die

Testfälle kann sein, dass jeder Funktionsbaustein bzw. Knoten mindestens einmal

ausgeführt werden muss (Anweisungsüberdeckung). Für den Datenintegrationspro-

zessausschnitt in Abbildung 3-7 wird unter dieser Betrachtung gefordert, dass die

Komponenten „Lese EBCDIC-Datei“, „Schema Check“, „Wertebereich Check“,

„Schema Schwellwert“, „Wertebereich Schwellwert“, „Schema Protokoll“, „Wertebe-

reich Protokoll“ und „Abbrechen“ alle mindestens einmal durch entsprechende Test-

fälle zur Ausführung kommen. Dabei ist es egal, ob die Funktion „Abbrechen“ durch

die Überschreitung des Schema- oder Wertebereichschwellwertes zustande kommt.

Erst mit der Forderung nach der Zweigüberdeckung (alle Kanten) werden auch tat-

sächlich beide Fälle abgedeckt.

Abbildung 3-10: Datenflussgraph (Talend) [Eigene Darstellung]


Wie es der Name bereits ausdrückt, verarbeitet der Datenintegrationsprozess Daten.

Attribute werden aus einer Quelle gelesen, verarbeitet und in ein Ziel geschrieben.

Somit bietet sich das datenflussorientierte Testen als weitere Prüftechnik an. Für das

datenflussorientierte Testen muss der bestehende Kontrollflussgraph um die Zugriffe

auf die Attribute erweitert werden. Wie sich die Attributzugriffe gestalten, ergibt sich

aus der näheren Betrachtung der Funktionsweise eines Datenintegrationswerkzeu-

ges. Am Beispiel von Talend soll dies hier verdeutlicht werden: Jeder Knoten bzw.

jeder Verarbeitungsschritt in einem Talend-Prozess besitzt sein eigenes Schema

bzw. seine eigenen Attribute. Der Datenfluss ergibt sich, wenn die Attributwerte von

einem Schema an das nächste Schema übergeben werden. In der Abbildung 3-10

wird dieses Vorgehen veranschaulicht. Die linke Spalte zeigt den Prozess als Über-

sicht. Die von einem Knoten ausgehenden Kanten sind mit dem jeweiligen Sche-

manamen beschrieben. Der erste Verarbeitungsschritt liest aus einer Tabelle mittels

SELECT * FROM zeilenweise alle Attribute (ID, Vorname, Nachname, Telefonnum-

mer, Umsatz) und weist die einzelnen Werte den Attributen des ersten Schemas „s1“

zu. Das gesamte Schema „s1“ besteht aus den Attributen:

• „s1_ID“

• „s1_Vorname“

• „s1_Nachname“

• „s1_Telefonnummer“

• „s1_Umsatz“

Im zweiten Schritt werden in dem Schema „s2“ die ID und der Umsatz aus „s1“ über-

nommen und der Vor- und Nachname einfach als Name konkateniert. Die Telefon-

nummer wird nicht übernommen. Das Schema „s2“ hat sich im Vergleich zu „s1“ ge-

ändert und besteht lediglich aus den drei Attributen:

• „s2_ID“

• „s2_Name“

• „s2_Umsatz“

Im dritten Schritt findet anhand des Umsatzes aus „s2“ eine Entscheidung statt (Um-

satz größer 10.000). Der Datenfluss wird in die zwei Schemata „s3“ und „s4“ aufge-

teilt (entsprechend mit den Attributen „s3_ID“, „s4_ID“ etc.) und für die weitere Verar-

beitung bereitgestellt. Die mittlere Spalte der Abbildung zeigt die entsprechenden

Variablenzugriffe (def, c-use, p-use) des Datenflusses je Schema. Es ist zu erken-


nen, wie bei jedem Knoten eine Variable x mittels def(x) und c-use(x) von Schema zu

Schema übertragen wird. Für die Entscheidung anhand des Umsatzes wird auf die

Variable „s2_Umsatz“ über p-use zugegriffen.

In der rechten Spalte ist zur Verdeutlichung der Vorgehensweise der für den Prozess

zugrundeliegende Talend-Quellcode20 in vereinfachter Form dargestellt. Für die

Durchführung des datenflussorientierten Tests wird der Quellcode jedoch nicht benö-

tigt.

Abbildung 3-11: Datenflussanomalieanalyse (Talend) [Eigene Darstellung]

Auf Basis des Datenflussgraphen kann zusätzlich eine Anomalieanalyse durchge-

führt werden. Von Interesse ist hierbei vor allem das Aufdecken von du-Anomalien.

Eine solche Anomalie ist die Definition einer Variablen, ohne dass sie verwendet

wird. Sie tritt etwa auf, wenn der Datenintegrationsprozess beim Einlesen von Daten 20 Talend verwendet für seine Funktionalitäten im Hintergrund Java. Da das System offen ist, kann der

Quellcode eingesehen werden.


aus einer Tabelle alle Spalten selektiert, für die tatsächliche Verarbeitung aber nicht

alle Attribute relevant sind. Die Vermeidung der du-Anomalie kann die zu verarbei-

tende Datenmenge gravierend verringern und dadurch deutlich zur Steigerung der

Verarbeitungsgeschwindigkeit beitragen. In der Abbildung 3-11 wurde der Datenin-

tegrationsprozess und der vereinfachte Quellcode aus Abbildung 3-10 mit den für die

Anomalieanalyse benötigten Zugriffsarten für Variablen angepasst. Hier wird die du-

Anomalie bei dem Attribut der Telefonnummer ersichtlich: Das Attribut s1_TELEFON

wird im ersten Verarbeitungsschritt definiert und in keinem der weiteren Schritte refe-

renziert. Beim Verlassen des Prozesses wird das Attribut wieder undefiniert. Da die

Telefonnummer keine Rolle für den Prozess spielt, kann sie in dem SELECT-

Statement ausgeschlossen werden.

Das Slicing als statische Fehleranalyse wird von vielen Datenintegrationswerkzeugen

unterstützt. Als Slicing-Instrumente bieten sie die Impact Analyse sowie die Data Li-

neage Analyse an. Beide Analysen dienen der Aufdeckung, wo und wie die einzel-

nen Attribute in den Integrationsprozessen verarbeitet werden. Der Unterschied ist

dabei der Standpunkt der Betrachtung: Die Impact Analyse ist anterograd und die

Data Lineage Analyse retrograd. Das bedeutet, dass mittels Impact Analyse zu ei-

nem Attribut ermittelt werden kann, in welchen nachfolgenden Prozessschritten die-

ses Attribut verwendet wird. Bei der Data Lineage Analyse kann umgekehrt aufge-

deckt werden, welche vorgelagerten Prozessschritte an der Ausprägung eines Attri-

butes partizipieren. Beide Methoden eigenen sich gleichermaßen, um einen Über-

blick erlangen zu können, wie die einzelnen Attribute aufeinander einwirken. In der

nachfolgenden Abbildung ist eine Impact Analyse in Talend dargestellt. Die Analyse

wurde für das Attribut „Versicherungsscheinnummer“ (VSNR) durchgeführt. Die ret-

rograde Perspektive startet mit dem Schreiben (Write) in eine Tabelle. Seinen Ur-

sprung hat das Attribut in einer anderen Tabelle (Read). Von zwei weiteren Prozess-

schritten wurde die VSNR verwendet (Set). Für die Art der Attributverwendung wird

hierbei keine Unterscheidung vorgenommen, ob es ein Zugriff für eine Berechnung

(c-use) oder Entscheidung (p-use) ist.


Abbildung 3-12: Data Lineage Analyse (Talend) [Eigene Darstellung]

Aufgrund der hohen Komplexität der Datenintegrationsprozesse empfiehlt es sich,

auch eine Stilanalyse sowie Reviews durchzuführen. Ausschlaggebende Punkte für

die Stilanalyse sind dabei, dass die einzelnen Knoten und Kanten in den Prozessen

verständlich benannt sind und mögliche Konventionen eingehalten wurden. Der kon-

trollierende Blick eines zweiten, unabhängigen Entwicklers kann gerade bei den

komplizierten Mechanismen der Dimensionserstellung (z.B. Typ 2 SCD) helfen.

3.3.2.2 Nichtfunktionale Prüftechniken für die Datenintegration Die Geschwindigkeit des Prozesses lässt sich aus Sicht der zu verarbeitenden Daten

in Zeilen pro Sekunden messen. Dazu wird die Anzahl der in den Prozess eingeflos-

senen Datensätze durch die Verarbeitungszeit in Sekunden dividiert. Mit dieser

Messgröße lassen sich auch Aussagen zu der Skalierbarkeit treffen, etwa wie viel

Zeit der Prozess bei höheren Datenvolumina benötigt. Um Engpässe innerhalb des

Prozesses festzustellen, kann sowohl die Gesamtgeschwindigkeit gemessen wer-

den, als auch die Geschwindigkeiten einzelner Teilabschnitte.

Das Überprüfen der Dokumentation aus Sicht der Revisionsabteilung kann nur in

direkter Zusammenarbeit mit eben dieser stattfinden. Ein fachkundiger Dritter muss

beurteilen, ob die Dokumentation verständlich und ausreichend ist. Durch das Ver-


wenden eines grafischen Datenintegrationswerkzeuges und die Einhaltung von Pro-

grammierkonventionen dokumentieren sich die Integrationsprozesse zum größten

Teil automatisch. Talend bietet etwa die Möglichkeit, eine Prozessdokumentation im

HTML-Format zu exportieren, wodurch die Dokumentation sehr einfach an einen in-

teressierten Empfängerkreis verteilt werden kann. Ein solches HTML-Dokument be-

inhaltet dabei neben einer grafischen Übersicht des Prozesses auch alle vorgenom-

menen Einstellungen an den einzelnen Prozessschritten (z.B. vollständige SQL-

Statements bei Zugriff auf Tabellen, verwendete Qualitätsregeln).

3.4. Data Warehouse Das Data Warehouse ist der zentrale Speicherort für die dispositiven Daten. Es be-

steht zum einen aus den Tabellen im Sternschema für die eigentlichen Auswertungs-

zwecke und zum anderen aus Staging-Tabellen für die Speicherung von Zwischen-

ergebnissen während der Datenintegration.

3.4.1. Besonderheiten eines Data Warehouses

3.4.1.1 Funktionale Besonderheiten eines Data Warehouses Bei der Erstellung der DW-Tabellen kann es dazu kommen, dass die Strukturen feh-

lerhaft sind. Ganz egal, ob die Tabellen mittels manuell geschriebener SQL-

Statements oder mithilfe von einem Datenbankwerkzeug angelegt werden, kann sich

der Entwickler bei der Definition von Datentypen oder bei der Namensvergabe der

Spalten irren. Gerade sehr breite Tabellen mit mehr als 100 Spalten werden schnell

unübersichtlich und verleitet zu solchen Fehlern.

Eine Ausweitung des Testens auf weitere Datenbankobjekte wie Constraints oder auf

referentielle Integrität (RI) ist nicht notwendig:

„[...] the data warehouse is not transactional. All data is entered via a controlled,

managed mechanism - ETL. All RI should be enforced by the ETL process, ma-

king RI at the database level redundant and unnecessary.“ [Kim04, S. 299]


3.4.1.2 Nichtfunktionale Besonderheiten eines Data Warehouses Da im Data Warehouse massiv Daten gelesen und geschrieben werden, ist die

Überprüfung der Geschwindigkeit sehr wichtig. Für das Erzielen einer hohen Lese-

geschwindigkeit bieten RDBMS eine Reihe von Möglichkeiten. Gängigste Praxis ist

hier die Verwendung Tabellenpartitionierung. Dabei wird der Inhalt einer Tabelle über

mehrere Tablespaces verteilt, wodurch Zugriffe parallelisiert und somit beschleunigt

werden können. Um eine möglichst hohe Schreibgeschwindigkeit bei Massendaten

zu erzielen, müssen einfache, transaktionskontrollierte INSERT-Statements vermie-

den und stattdessen auf den hierfür ausgelegten BULK LOAD Mechanismus zurück-

gegriffen werden.

Auch wenn die Preise für Speicherkapazitäten immer weiter sinken, so ist trotzdem

auf eine effiziente Nutzung zu achten. Gerade im Unternehmensumfeld sind die Kos-

ten für Speicher um ein vielfaches höher als für einen Privatanwender zu Hause, weil

hier die Daten mehrfachredundant und ausfallsicher abgelegt werden. Von daher ist

schon bei der Entwicklung zu beachten, dass das DW nicht mit unnötigen Daten be-

lastet wird. Gerade für die Staging Area muss überlegt werden, wie lange die Daten

in diesem Zwischenspeicher vorgehalten werden müssen und wann hier Speicher-

platz wieder freigegeben werden kann. Sehr selten abgerufene Daten lassen sich auf

kostengünstigere Speichermedien wie Magnetbänder auslagern.

Daneben müssen die Daten aus sicherheitstechnischer Sicht vor nicht-autorisierten

Zugriffen sowie vor unerlaubten Manipulationen geschützt werden. Die gespeicher-

ten Daten im DW sind mitunter hoch sensibel. Von daher müssen sowohl die Ver-

traulichkeit (Schutz vor unerlaubtem Lesen) als auch die Integrität (Schutz vor uner-

laubter Manipulation) bewahrt werden. Eine einfache Lösung für dieses Problem ge-

ben Kimball et al. [vgl. Kim04, S. 16f], indem das DW in einen „Back Room“ und ei-

nen „Front Room“ aufgeteilt wird. Im Back Room hat dann lediglich ein technischer

Benutzer für die Datenintegrationsprozesse Schreibrechte und die DW Entwickler

Leserechte. Die eigentlichen Anwender haben nur auf die veröffentlichten OLAP-

Würfel im Front Room Zugriff. Entsprechend werden die genauen Zugriffsrechte für

den Front Room über das OLAP-System und das Reporting Front-End abgedeckt.

[vgl. Gol11, S. 1192]


3.4.2. Prüftechniken für ein Data Warehouse

3.4.2.1 Funktionale Prüftechniken für ein Data Warehouse Zum Überprüfen der Tabellenstrukturen bietet sich der Äquivalenzklassenüberde-

ckungstest mit besonderer Betrachtung der Äquivalenzklassengrenzen an. Für die

Wertebereiche der Spalten werden dafür die entsprechenden Äquivalenzklassen er-

mittelt und anhand derer die Testfälle abgeleitet. Soll eine Kunden-Tabelle beispiels-

weise einen Namen (bis zu 10 Zeichen), das Alter (beliebige Zahl, NULL wenn Alter

unbekannt) sowie das Geschlecht (M oder F) speichern können, so kann die dafür

erstellte Tabelle folgendermaßen aufgebaut sein:

01 02 03 04 05

CREATE TABLE KUNDE ( NAME VARCHAR(10) NOT NULL ,ALTER SMALLINT ,GESCHLECHT CHAR(1) NOT NULL );

Listing 3-3: Struktur einer Kunden-Tabelle [Eigene Darstellung]

01 02 03 04 05 06 07 08 09 10 11 12 13

--VERPFLICHTEND: KORREKTE WERTE INSERT INTO KUNDE VALUES ('ABCDEFGHIJ', 109, 'M'); INSERT INTO KUNDE VALUES ('MEIER', 0, 'F'); INSERT INTO KUNDE VALUES ('MEIER', NULL, 'M'); --OPTIONAL: FEHLERHAFTE WERTE --FEHLER IN SPALTE NAME INSERT INTO KUNDE VALUES ('ABCDEFGHIJK', 0, 'F'); INSERT INTO KUNDE VALUES (NULL, 0, 'F'); --FEHLER IN SPALTE AGE INSERT INTO KUNDE VALUES ('MEIER', 'X', 'F'); --FEHLER IN SPALTE GENDER INSERT INTO KUNDE VALUES ('MEIER', 0, NULL);

Listing 3-4: SQL-Statements zum Testen der Kunden-Tabelle [Eigene Darstellung]

Es muss verpflichtend geprüft werden, ob die Spalte für den Namen tatsächlich einen

Text mit 10 Zeichen, die Spalte für das Alter sowohl Zahlen als auch NULL und die


Spalte für das Geschlecht die Werte M und F entgegen nehmen (Positiv-Tests). [vgl.

The07, S. 2] Diese Tests sind deshalb verpflichtend, damit es bei einem INSERT-

Statement während der Datenintegration auf keinen Fall zu einem Abbruch kommt.

Optional sind hingegen die Tests mit fehlerhaften Werten. Diese Situationen dürfen

gar nicht auftreten, weil die ursächlichen fehlerhaften Werte schon während der Da-

tenintegration durch Qualitätsregeln herausgefiltert werden. [vgl. Kim04, S. 299] Im

Listing 3-4 sind exemplarisch SQL-Statements zum Testen der Kunden-Tabelle ge-

geben. Hätte der Entwickler bei der Tabellendefinition einen Fehler gemacht und bei-

spielsweise die Spalte für den Namen maximal 9-Stellig definiert, so würde das erste

INSERT-Statement diesen Fehler aufdecken.

Auch für Datenbankobjekte und Datenbankzugriffe per SQL gibt es Programmier-

konventionen, die von den Entwicklern eingehalten werden müssen. Somit muss

beim Testen eine Stilanalyse durchgeführt werden.

Eine syntaktische Konvention auf Ebene der Datenbankobjekte im DW-Umfeld ist

etwa das Verzichten auf Trigger. Ein Trigger ist ein Programm, das vor oder nach

einer Datenmanipulation (INSERT, UPDATE, DELETE) automatisch von der Daten-

bank aufgerufen wird. Ein Nachteil von Triggern ist, dass sie zum einen die Ge-

schwindigkeit des Schreibens in die Tabelle beeinträchtigen können. Des Weiteren

ist ein Trigger nach außen hin „unsichtbar“. Ein Entwickler, der nicht weiß, dass zu

einer Tabelle ein Trigger besteht, bekommt mitunter ein für ihn unerklärliches Verhal-

ten, wenn er mit dieser Tabelle arbeitet. Semantische Konventionen zu den Daten-

bankobjekten betreffen die Benennung der Objekte. Ein mögliches Namensschema

für Tabellen kann sein: „Typ_Thema_Name“. Der Typ gibt an, ob es sich um eine

Dimensionstabelle („Dim“), eine Faktentabelle („Fakt“) oder um eine Stagingtabelle

(„Stag“) handelt. Das Thema gibt Auskunft, zu welchem Themenbereich die Tabelle

gehört, zum Beispiel zur Kraftfahrtversicherung („KV“) oder zur Haftpflichtversiche-

rung („HV“). Themenübergreifende Tabellen gehören zu dem Bereich Allgemein

(„Allg“). Mit diesem Namensschema ergeben sich exemplarisch die Namen

„Dim_Allg_Zeit“ für die allgemeine Zeitdimensionstabelle, „Fakt_KV_Beitraege“ für

die Faktentabelle der Kraftfahrtversicherungsbeiträge und „Stag_HV_Schaeden“ für

eine Stagingtabellen der Haftpflichtversicherungsschäden.


Bei den Datenbankzugriffen mittels SQL gibt es die syntaktische Konvention, dass

beim Verknüpfen von Tabellen nicht eine WHERE-Bedingung, sondern der JOIN-

Operator verwendet wird (Listing 3-5). Eine weitere syntaktische Konvention fordert

etwa, dass SQL-Schlüsselworte in Großbuchstaben zu schreiben sind und dass

mehrzeilige Statements eingerückt werden müssen. Optional kann noch eine seman-

tische Konvention die Verwendung von Kommentaren zu jedem Statement fordern.

01 02 03 04 05 06 07 08 09

--VERBOTENE TABELLEN-VERKNÜPFUNG SELECT TABLE1.*, TABLE2.* FROM TABLE1, TABLE2 WHERE TABLE1.ID = TABLE2.ID; --ERLAUBTE TABELLEN-VERKNÜPFUNG SELECT TABLE1.*, TABLE2.* FROM TABLE1 JOIN TABLE2 ON TABLE1.ID = TABLE2.ID;

Listing 3-5: SQL-Programmierkonventionen [Eigene Darstellung]

Um eine Übersicht der DW-Tabellen und deren Beziehungen untereinander zu erhal-

ten, ist es ratsam, visuelle Hilfsmittel zu verwenden. So lässt sich mithilfe von Dia-

grammen auf einen Blick sehen, welche Dimensionstabellen in den verschiedenen

Sternschemata verwendet werden und welche für Auswirkungen die Änderung einer

Tabelle hat. Als Diagrammtyp haben sich für relationale Tabellen Entity-Relationship-

Diagramme (ER-Diagramme) etabliert. Moderne Datenbankentwicklungswerkzeuge

bieten sowohl die Möglichkeit, zu bestehenden Tabellen ER-Diagramme zu generie-

ren, als auch neue Tabellen über einen grafischen ER-Diagramm-Editor zu erstellen.

3.4.2.2 Nichtfunktionale Prüftechniken für ein Data Warehouse Der Geschwindigkeitstest kann durchgeführt werden, indem Zeitmessungen für

SELECT-Statements und für BULK LOAD Kommandos durchgeführt werden. Einfa-

che Statements müssen dabei im Bereich von Sekunden oder weniger Minuten ab-

schließen. Ein BULK LOAD muss mit einer zu erwartenden Datenmenge durchge-

führt werden.


Für das Testen der Speicherauslastung müssen die Tabellen zum einen mit der initi-

alen Datenmenge beladen werden und anschließend noch mit einer turnusmäßig zu

erwartenden Datenmenge. Daraus lässt sich ableiten, wie sich der Speicherver-

brauch im Betrieb entwickeln wird. Ist für die Daten in der Staging Area ein Verfalls-

datum angegeben, muss getestet werden, ob diese auch entsprechend gelöscht

wurden.

Zum Testen der Sicherheit muss geprüft werden, ob die („Back Room“) Datenbank

tatsächlich so konfiguriert ist, dass nur der technische Datenintegrationsbenutzer ei-

nen Schreibzugriff besitzt und die autorisierten DW Entwickler nur Lesezugriffe besit-

zen. Das Recht weitere Berechtigungen zu erteilen (GRANT) darf nur der Datenbank-

administrator besitzen.

3.5. OLAP-System Das OLAP-System verwaltet die multidimensionalen OLAP-Würfel. Dazu zählen die

Struktur der Würfel aus den Dimensionen und Kennzahlen, die Regeln zum Laden

der Daten aus den Dimensions- und Faktentabellen sowie Berechnungen der Kenn-

zahlenkonsolidierung entlang der Dimensionen.

3.5.1. Besonderheiten eines OLAP-Systems

3.5.1.1 Funktionale Besonderheiten eines OLAP-Systems Für das Erstellen eines OLAP-Würfels wird zunächst nur dessen Grundstruktur defi-

niert, also die Dimensionen und die Kennzahlen, die er darstellen soll. Die Grund-

struktur muss zu dem im Data Warehouse vorliegenden Sternschema passen, an-

sonsten können die gewünschten Daten nicht geladen werden. Unter der Annahme,

dass das im Abschnitt 3.2 aufgestellte multidimensionalen Modell die einheitliche

Grundlage für das Sternschema und den OLAP-Würfel ist, kann die Verträglichkeit

von Sternschema und OLAP-Würfel als gegeben angesehen werden.

Sobald die Struktur definiert ist, müssen die Dimensionen und Kennzahlen mit Inhal-

ten gefüllt werden. Die Reihenfolge ist hierbei analog zum Aufbau des Sternsche-

mas: Zuerst werden die Dimensionen geladen, anschließend die Kennzahlen. Die

Übertragung aus dem Sternschema in den OLAP-Würfel geschieht mit sogenannten

Laderegeln. Es muss für jede Dimension eine eigene Dimensionsladeregel angelegt


werden sowie eine Faktenladeregel. Hierbei ist es wichtig, dass Hierarchien inner-

halb der Dimensionen korrekt aufgelöst werden. Hierarchien in Dimensionstabellen

lassen sich über zwei Wege darstellen: Als Eltern-Kind-Beziehung oder als vollstän-

dige Generation. [vgl. Ora10, Kap. 6 S. 20f] Bei der Eltern-Kind-Beziehung kennt je-

des Element der Dimension nur seinen direkten Vorgänger in der Hierarchie. Im Bei-

spiel der Tabelle 3-8 kennt „Hannover“ nur seinen Vorgänger „Niedersachsen“, nicht

jedoch seinen indirekten Vorgänger „Deutschland“. Zum Aufbauen der gesamten

Hierarchiestruktur sind somit rekursive Zugriffe nötig.

Eltern Kind Deutschland Niedersachsen

Niedersachsen Hannover

Niedersachsen Göttingen

Deutschland Bremen

Deutschland Bayern

Bayern München

... ...

Tabelle 3-8: Eltern-Kind-Beziehung [Eigene Darstellung]

Eine alternative Darstellungsform ist die vollständige Generation (Tabelle 3-9). Hier-

bei kennt jedes Element all seine Vorgänger.

Generation 1 Generation 2 Generation 3 Generation ... Deutschland Niedersachsen Hannover ...

Deutschland Niedersachsen Göttingen ...

Deutschland Bremen NULL ...

Deutschland Bayern München ...

... ... ... ...

Tabelle 3-9: Vollständige Generation [Eigene Darstellung]


In einer Dimensionsladeregel müssen demnach der richtige Hierarchietyp als auch

die korrekten Beziehungen zu den Spalten der Dimensionstabelle (z.B. welches ist

die Eltern-Spalte, welches die Kind-Spalte) aufgebaut werden.

Für das Laden der Fakten ist es wichtig, dass das Laden der Dimensionen vorab

stattgefunden hat und auch vollständig gelaufen ist. Zudem muss die Reihenfolge

der angegebenen Koordinaten stimmen. Ansonsten kann es passieren, dass eine

Kennzahl zu einer unbekannten Koordinate im Würfel (einer unbekannten Kombina-

tion von Dimensionselementen) geschrieben werden soll. [vgl. Ora10, Kap. 6 S. 22]

In der Tabelle 3-10 ist bei dem letzten Datensatz exemplarisch die Reihenfolge der

Dimensionen „Absatzgebiet“ und „Produkt“ vertauscht.

Absatzgebiet Produkt Zeit Anzahl Beitrag Hannover Kraftfahrt Januar 1.461 347.104,38

München Haftpflicht Februar 2.974 812.433,60

... ... ... ... ...

Kraftfahrt Bremen März 308 97.427,12

Tabelle 3-10: Laden von Kennzahlen [Eigene Darstellung]

Ein OLAP-Würfel enthält nicht nur die granularen Kennzahlen (z.B. 1.461 verkaufte

Kraftfahrtversicherungen in Hannover im Januar), sondern auch noch konsolidierte

Kennzahlen und abgeleitete Kennzahlen. Eine Konsolidierung (auch Aggregation

oder Verdichtung genannt) geschieht bei der Navigation entlang einer Dimensions-

hierarchie. In der Regel handelt es sich bei der Konsolidierung um eine Summierung.

Entlang der Dimension Absatzgebiet können etwa die Einzelwerte zu „Deutschland

Gesamt“ summiert werden. Abgeleitete Kennzahlen ergeben sich aus dem Zusam-

menführen mehrerer anderer Kennzahlen und stellen somit eine zusätzliche Informa-

tion dar. In dem Beispiel oben lässt sich aus den Kennzahlen „Beitrag“ und „Stück“

ein durchschnittlicher Beitrag errechnen (z.B. 347.104,38 / 1.461 = 237,58 durch-

schnittlicher Beitrag in Hannover im Januar für das Versicherungsprodukt Kraftfahrt).

Gerade bei abgeleiteten Kennzahlen ist zu beachten, wie diese entlang der Dimensi-

onshierarchie konsolidiert werden sollen. So ist die Summierung einer abgeleiteten

durchschnittlichen Kennzahl wie in Tabelle 3-11 auf der linken Seite eine falsche


Konsolidierung. Als möglicher Fehler kann also das falsche Berechnen von abgelei-

teten und konsolidierten Kennzahlen auftreten.

Æ Beitrag Æ Beitrag Quartal 1 826,86 Quartal 1 275,62

Januar 283,13 Januar 283,13

Februar 261,60 Februar 261,60

März 282,13 März 282,13

Tabelle 3-11: Falsche und korrekte Konsolidierung [Eigene Darstellung]

Neben dem Anwenden der richtigen Rechenoperationen spielt auch die Vorgehens-

art der Berechnungen eine wichtige Rolle. Einige OLAP-Systeme wie etwa Oracle

Essbase21 bieten die Möglichkeit der „intelligenten“ Berechnung eines OLAP-Würfels.

Die Idee hierbei ist, dass nach der Änderung von Daten auch nur die geänderten

Blöcke in dem Würfel neu berechnet werden und so eine höhere Berechnungsge-

schwindigkeit erzielt wird. Das Problem hierbei liegt in der Speicherarchitektur eines

Würfels: Ein Würfel besteht aus Blöcken, ein Block besteht aus Zellen, eine Zelle

enthält einen konkreten Datenwert. Das intelligente Berechnungsverfahren stützt

seine Informationen, ob sich Daten geändert haben und ob eine Berechnung durch-

zuführen ist lediglich auf Block-Ebene anstatt auf Zellen-Ebene. Es ist also möglich,

dass nur ein Teilbereich eines Blocks berechnet wird und der ganze Block anschlie-

ßend fälschlicherweise als „sauber“ markiert wird. [vgl. Ora10, Kap. 15 S. 18ff] Die

Nutzung der intelligenten Berechnung ist deshalb mit Vorsicht zu genießen. Eine

dauerhafte Deaktivierung kann unter Umständen sinnvoll sein.

3.5.1.2 Nichtfunktionale Besonderheiten eines OLAP-Systems Ein Vorteil von OLAP-Systemen ist, dass konsolidierte und abgeleitete Kennzahlen

physikalisch gespeichert und für spätere Auswertungen vorgehalten werden können.

Zur Laufzeit, wenn ein Benutzer sich durch einen Würfel navigiert, müssen in dem

Fall keine Berechnungen mehr durchgeführt werden und der Benutzer erhält sehr 21 Weitere Informationen unter http://www.oracle.com/technetwork/middleware/essbase/index.html

(Abgerufen 10.01.2012)

!


schnell seine Resultate. Bei einem Würfel, der besonders viele Daten beinhaltet,

kann sich das Kalkulieren und Speichern der Konsolidierungen aber unter Umstän-

den sehr stark auf den Speicherverbrauch sowie die Berechnungslaufzeit beim La-

den des Würfels auswirken. Es darf selbstverständlich nicht passieren, dass das La-

den eines Würfels mehrere Tage dauert oder dass der Speicherbedarf des Würfels

um ein Vielfaches ansteigt. Von daher ist abzuwägen, ob wirklich alle konsolidierten

und abgeleiteten Kennzahlen vorgehalten werden müssen, indem das Geschwindig-

keitsverhalten des Würfel-Ladens und des Navigierens durch den Würfel gegenüber-

gestellt wird. Ein Kompromiss kann sein, dass nur die am häufigsten von den An-

wendern abgerufenen konsolidierten Kennzahlen physikalisch gespeichert werden

und die weniger häufig abgerufenen Kennzahlen zur Laufzeit berechnet werden.

Durch intelligente Caching-Mechanismen des OLAP-Systems hat in diesem Fall

auch nur der Anwender länger zu warten, der als Erster eine dynamisch berechnete

Kennzahl abruft. Alle folgenden Anfragen erhalten das Ergebnis sofort aus dem

Cache.

3.5.2. Prüftechniken für ein OLAP-System

3.5.2.1 Funktionale Prüftechniken für ein OLAP-System Zunächst muss überprüft werden, ob die Dimensionsladeregeln korrekt implementiert

und die Dimensionsstrukturen richtig aufgebaut wurden. Anhand der Dimensionen

und der Hierarchieebenen können die zu überprüfenden Äquivalenzklassen ermittelt

werden. Am Beispiel der Dimensionen „Zeit“ und „Absatzgebiet“ ergeben sich als

Äquivalenzklassen:

Dimension Äquivalenzklassen Repräsentant

Zeit Z={2009àJanuarà1,

...,2011àDezemberà31}

2010 à März à 23

Absatzgebiet A={DeutschlandàBayernàMünchen,

...,DeutschlandàThüringenàErfurt}

Deutschland à Niedersachsen

à Hannover

Tabelle 3-12: Äquivalenzklassen zum Testen der Dimensionalität [Eigene Darstellung]


Bei der Überprüfung ist von Interesse, ob etwa der Pfad Deutschland à Niedersach-

sen à Hannover existiert. Angenommen, die geladene Dimension hat die Struktur

Land à Hannover à Niedersachsen, so wurden in der Laderegel fälschlicherweise

die Spalten der Generationen 2 und 3 vertauscht. Im Folgenden soll dieser Fehler

anhand eines Beispiels (implementiert in dem OLAP-System Jedox22) demonstriert

werden. Aus der Tabelle „Dim_Absatzgebiet“ soll die Dimension Absatzgebiet gela-

den werden. Diese ist als vollständige Hierarchie abgespeichert:

Abbildung 3-13: Tabelle Dim_Absatzgebiet [Eigene Darstellung]

Die Laderegel wird in Jedox dialoggesteuert implementiert (Abbildung 3-14). Der

Entwickler muss den Typ der Hierarchie angeben, in diesem Fall „TreeFH“, wobei

das FH für „Full Hierarchy“ (vollständige Hierarchie) steht. Im unteren Bereich wer-

den die Ebenen der Hierarchie angegeben. Hier ist es wichtig, dass die Reihenfolge

der Ebenen (Land à Bundesland à Region) korrekt eingehalten wird.

Abbildung 3-14: Korrekte Dimensionsladeregel (Jedox)


22 Weitere Informationen unter http://www.jedox.de (Abgerufen 01.01.2012)


In einer fehlerhaften Implementierung wurde die Reihenfolge von Bundesland und

Region vertauscht:

Abbildung 3-15: Falsche Dimensionsladeregel (Jedox) [Eigene Darstellung]

Abbildung 3-16: Geladene Dimensionen (Jedox) [Eigene Darstellung]

Die Resultate des Ladens müssen anschließend kontrolliert werden. In der Abbildung

3-16 ist auf der linken Seite das korrekte und auf der rechten Seite das falsche Er-

gebnis zu sehen. Anhand des Testfalls muss der Pfad Deutschland à Niedersach-

sen à Hannover in der Hierarchie gefunden werden, was im rechten Bild nicht der

Fall ist. Fraglich ist noch, ob für unvollständige Hierarchien (z.B. das Bundesland

Bremen, das keine Region unter sich hat) eigene Äquivalenzklassen zu bilden sind.

Dies ist nicht der Fall, da der Pfad Land à Bundesland eine Teilmenge von Land à

Bundesland à Region ist und deshalb beim Testen der vollständigen Hierarchie mit

abgedeckt ist. In der gezeigten falschen Implementierung wird beim Laden auch di-


rekt eine Warnung ausgegeben, weil in diesem Fall Bremen einem leeren Knoten

zugeordnet werden soll.

Einen weiteren Test für das korrekte Laden von Dimensionselementen nennt Rainar-

di. [vgl. Rai08, S. 481] Für jede Hierarchieebene der Dimensionen muss die Anzahl

der geladenen Elemente geprüft werden. Wenn beispielsweise die Zeitdimension vier

Jahre abbilden soll, dann muss sie auf Jahresebene vier Elemente, auf Monatsebene

48 Elemente und auf Tagesebene 1.460 Elemente besitzen.

Abbildung 3-17: Faktenladeregel (Jedox) [Eigene Darstellung]

Das analoge Beispiel zu der Faktenladeregel in Jedox ist in der Abbildung 3-17 dar-

gestellt. Hierbei ist wie schon bei den Dimensionen darauf zu achten, dass die Spal-

ten aus der Eingabe (die Faktentabelle) auf die korrekten Dimensionsfelder (1) und

Kennzahlen (2) des Würfels verweisen.

1

2


Mittels Berechnungsregeln können aus den elementaren Kennzahlen weitere Kenn-

zahlen abgeleitet werden. Oftmals handelt es sich bei den abgeleiteten Kennzahlen

um Durchschnitte, Abweichungen oder einfache Additionen/Subtraktionen und Multi-

plikationen. Neben den abgeleiteten Kennzahlen werden durch die Berechnungsre-

geln auch die Konsolidierungen der Kennzahlen berechnet. Es gilt dabei, dass jede

einzelne Berechnungsregel auf korrekte Anwendung der Rechenoperatoren zu prü-

fen ist. Im folgenden Listing ist eine einfache Berechnungsregel für Essbase gege-

ben:

01 02 03 04 05 06 07 08 09 10 11

// Info : Berechnet den Würfel Versicherungsgeschäft // Autor: Renke Hegeler, 01.01.2012 // Ohne intelligentes Berechnungsverfahren SET UPDATECALC OFF; // Konsolidierung der elementaren Kennzahlen CALC DIM (Kennzahlen, Zeit, Absatzgebiet, Produkt); // Berechnung der Kennzahl "Durchschn. Beitrag" "Durchsch. Beitr." = Beitrag / "Verk. Versicherungen";

Listing 3-6: Berechnungsregel (Essbase) [Eigene Darstellung]

Für das Testen der Faktenladeregeln und der Berechnungsregeln müssen die ein-

zelnen Kennzahlen überprüft werden. Aufgrund der verschiedenen Kombinations-

möglichkeiten der Dimensionen gibt es sehr viele Kennzahlen, die zu testen sind. Die

theoretische Anzahl kann in die Millionen oder gar Milliarden gehen (Formel 3-3).

Hier muss eine Strategie gefunden werden, diese hohe Anzahl auf ein testbares Maß

zu begrenzen.

Rainardi [vgl. Rai08, S. 480f] schlägt hierfür ein intuitives Vorgehen vor. Dabei wird

pro Dimension mit den konsolidierten Kennzahlen auf höchster Ebene gestartet und

dann entlang der Hierarchieebenen die Sicht immer weiter detailliert. Auf unterster

Ebene, wo es die meisten Dimensionsausprägungen gibt, muss dann die getestete

Elementanzahl eingeschränkt werden. Der Grundgedanke bei diesem Vorgehen ist,

dass die konsolidierten Kennzahlen abhängig von den elementaren Kennzahlen sind.


Wenn eine Kennzahl falsch geladen wurde oder eine Berechnungsregel fehlerhaft

ist, so ist auch der konsolidierte Wert falsch.

Bei einer Produktdimension mit den Ebenen „Sparte“ à “Produktgruppe“ à „Pro-

dukt“ und den drei Kennzahlen „Umsatz“, „Verkaufte Einheiten“ und „Durch-

schnittsumsatz“ wird also mit den konsolidierten Ebenen „Sparte“ gestartet. Bei drei

Sparten ergeben sich somit bereits neun zu testende Kennzahlen. Bei jeweils drei

Produktgruppen je Sparte multipliziert sich die Anzahl der Testfälle auf 27. Auf der

untersten Ebene „Produkt“ kann es je Produktgruppe hunderte Ausprägungen geben.

Rainardi schlägt vor, diese Menge mittels Äquivalenzklassen zu verringern. Die

Äquivalenzklassenbildung geschieht dabei auf einer fachlichen Betrachtung, bei-

spielsweise anhand der Verkaufshäufigkeit (viel, wenig), der Beliebtheit (beliebt, un-

beliebt) oder dem Alter (neu, alt) eines Produktes.

Das Erstellen der Laderegeln ist je nach Hersteller des OLAP-Systems unterschied-

lich. Häufig geschieht dieses wie in dem gerade genannten Beispiel über einen inte-

grierten Dialog bzw. über einen „Wizard“. In diesem Fall können keine strukturorien-

tierten Prüftechniken angewendet werden, da die Regeln gekapselt in dem OLAP-

System vorliegen.

Für alle Arten von Regeln empfiehlt sich, eine Stilanalyse durchzuführen. Gerade für

die unter Umständen komplexen Berechnungen der Kennzahlen in Skriptform muss

auf die Vollständigkeit von Kommentaren geachtet werden. Eine syntaktische Kon-

vention bei den Berechnungsregeln kann lauten, dass das oben erwähnte intelligente

Berechnungsverfahren nicht erlaubt ist und immer abgeschaltet werden muss.

Mit dem multidimensionalen Diagramm aus der Modellierungsphase (Abbildung 3-2)

liegt bereits ein erstes visuelles Hilfsmittel für die Übersicht der Würfelstruktur und

der Berechnung von Kennzahlen vor. Was diese Modelle jedoch nicht vorsehen, ist

eine Visualisierung der Konsolidierungen. Dieser Punkt wurde auch von Herden [vgl.

Her01, S. 19ff] bei den verglichenen Diagrammtypen bemängelt. Eine denkbare

Möglichkeit ist hier die Erweiterung des Diagramms um Konsolidierungsvorschriften.

Als mögliche Konsolidierungen können entweder die Grundrechenarten oder aber

ein Ausschluss von der Konsolidierung auftreten. In der Abbildung 3-18 wurde das

ADAPT-Modell exemplarisch erweitert und die Konsolidierungsvorschriften als Attri-


but zu den Kennzahlen hinzugefügt. Für die Kennzahl der durchschnittlichen Beiträ-

ge wurde aufgrund der in Tabelle 3-11 dargestellten Situation die Konsolidierung

ausgeschlossen.

Abbildung 3-18: ADAPT-Modell erweitert um Konsolidierungen


3.5.2.2 Nichtfunktionale Prüftechniken für ein OLAP-System Der benötigte Speicherbedarf eines OLAP-Würfels kann manuell überprüft werden,

indem er anhand der Würfelstruktur und der Anzahl der zu erwartenden Werte be-

rechnet wird. In der Regel bieten die Hersteller von OLAP-Systemen Richtwerte für

die Berechnung an.

Bei einem Würfel in Essbase, der konsolidierte Werte speichert23, ergibt sich die ma-

ximale Größe aus der möglichen Anzahl von Kombinationen der Dimensionselemen-

te (der Anzahl der Koordinaten in dem Würfel). [vgl. Ora10, Kap. 11 S. 14f]

Sei𝐷dieMengeallerDimensioneneinesWürfels. Danngilt:

𝑠𝑖𝑧𝑒�� = �� 𝑀𝑒𝑚(𝑑)�∈�

� ∙ 𝑛Bytes

wobei𝑀𝑒𝑚(𝑑)dieAnzahlderElementederDimensionen𝑑istund

𝑛diebenötigtenByteszumSpeicherneinerZahlangibt.

Formel 3-3: Maximale Größe eines Essbase BSO-Würfels [Eigene Darstellung]

23 Auch BSO-Würfel genannt,


Angenommen, ein BSO-Würfel besteht aus fünf Dimensionen mit 3, 36, 64, 100 und

10.000 Elementen und eine Zahl wird als Double (8 Byte) gespeichert. Dann ergibt

sich mithilfe der Formel 3-3 als maximale Größe des Würfels:

𝑠𝑖𝑧𝑒�� = (3 ∙ 36 ∙ 64 ∙ 100 ∙ 10000) ∙ 8Bytes = 55296000000Bytes ≙ 55,296GB

Diese (theoretische) Größe gilt nur für einen absolut nicht-optimierten Würfel. Ess-

base bietet selbstverständlich Möglichkeiten, die Kombinationsmöglichkeiten zu re-

duzieren und somit auch Speicherplatz zu sparen. Die Berechnung in Formel 3-3

kann helfen, Optimierungsbedarf aufzudecken. So kann die Entscheidung an dieser

Stelle auch lauten, dass weniger oder auch gar keine konsolidierten und abgeleiteten

Kennzahlen gespeichert werden. In diesem Fall ergibt sich die Würfelgröße aus der

zu erwartenden Anzahl an elementaren Kennzahlen.

Die Geschwindigkeit des OLAP-Systems spiegelt sich in zwei Punkten wieder: dem

Laden bzw. Berechnen des Würfels und dem anschließenden Zugriff auf die Daten

des Würfels. Der Geschwindigkeitstest muss also beide Aspekte berücksichtigen.

Die Ladegeschwindigkeit des Würfels kann ermittelt werden, indem ein Testlauf mit

einer realistischen Datenmenge durchgeführt wird. Eine langsame Ladegeschwindig-

keit ist bei Würfeln zu erwarten, die alle oder viele konsolidierte bzw. abgeleitete

Kennzahlen speichern. Für diese Würfel ergibt sich dafür automatisch eine hohe Ab-

fragegeschwindigkeit. Ist die Ladegeschwindigkeit zu langsam, kann das Problem

durch das Laden von ausschließlich elementaren Kennzahlen gelöst werden. Dann

muss jedoch zwingend ein Test der Zugriffszeiten erfolgen. Es empfiehlt sich dabei,

die Anwender zu interviewen, welches die wichtigsten und am häufigsten abgerufe-

nen nicht-elementaren Kennzahlen sind. So kann sich letztendlich der Kompromiss

ergeben, dass die wichtigsten Kennzahlen vorkalkuliert werden, der Rest jedoch dy-

namisch zur Laufzeit berechnet wird.

3.6. Reporting Front-End Bei den Konsumenten von Analysen lassen sich drei verschiedene Typen unter-

scheiden: Standard-Benutzer, „Power“-Benutzer und „VIP“-Benutzer. Ein Standard-

Benutzer ist beispielsweise ein Vertriebsmitarbeiter, der monatlich seine aktuellen

Verkaufszahlen betrachtet. Hierbei nutzen viele andere Anwender (z.B. alle Ver-

triebsmitarbeiter) denselben Bericht, jeweils mit einem anderen Datenfilter (dem ei-


genen Vertriebsgebiet). „Power“-Benutzer verwenden weitaus mehr Funktionalitäten

des Reporting Front-Ends und erstellen auch selber Berichte. Hierbei handelt es sich

um einen wesentlich kleineren Anwenderkreis wie den Mitarbeitern der Controlling-

Abteilung. „VIP“-Benutzern sind Mitglieder des Vorstands oder des Aufsichtsrates

des Unternehmens. Diese Personen sind oft keine direkten Anwender, die das Front-

End selbst bedienen, sondern die von einem Assistenten optisch sehr hochwertige

Berichte als digitales Dokument oder als Ausdruck vorgelegt bekommen.

Das Reporting Front-End an sich ist in der Regel eine Web-Applikation oder eine

Excel-Erweiterung, die vom Hersteller des OLAP-Systems bereitgestellt wird.

3.6.1. Besonderheiten eines Reporting Front-Ends

Das Front-End dient der Darstellung der multidimensionalen Daten. Es implementiert

für gewöhnlich keine weitere Logik, die aus funktionaler Sicht zu testen ist. Es kön-

nen zwar mit den Bordmitteln des Front-Ends (z.B. Funktionsumfang von Excel) aus

den zur Verfügung stehenden Kennzahlen noch beliebige Berechnungen durchge-

führt werden, diese Tätigkeiten fallen jedoch in den Anwendungsbereich des Anwen-

ders und sind nicht durch einen Entwickler zu testen.

3.6.1.1 Nichtfunktionale Besonderheiten eines Reporting Front-Ends Nichtfunktionale Tests sind hingegen sehr wichtig, weil nur so eine hohe Akzeptanz

der Anwender erreicht werden kann. Wichtige Aspekte sind hierbei die Sicherheit

sowie die Benutzerfreundlichkeit. [vgl. Rai08, S. 485ff]

Für BIS gelten oftmals besonders strikte sowie kritische Sicherheitsbestimmungen in

Bezug auf die Vertraulichkeit der Daten. Die Vorgaben der Vertraulichkeitsstufen

können von der Geschäftsführung oder auch von Betriebsräten gefordert sein. Eine

Forderung der Geschäftsführung kann etwa lauten, dass Vertriebsmitarbeiter nicht

die Kennzahlen der Kollegen im selben Vertriebsgebiet sehen dürfen, um zu starke

Konkurrenzkämpfe zu verhindern. Eine allgemeine Forderung des Betriebsrates ist

der Schutz personenbezogener Mitarbeiterdaten. Die Hierarchietiefe einer „Organi-

gramm“ Dimension darf deshalb nur bis auf Abteilungsebene ausgerichtet sein und

nicht bis auf einzelne Mitarbeiter.

Sicherheitseinstellungen können über drei Ebenen definiert werden: Auf Front-End-

Ebene wird bestimmt, ob sich ein Anwender überhaupt an dem System anmelden


darf. Auf Berichtsebene wird definiert, welcher Anwender welche Berichtsobjekte

überhaupt öffnen darf und ob der Anwender einen Bericht auch bearbeiten und spei-

chern darf. Auf Würfelebene wird festgelegt, welche Daten dann in dem Bericht zu

sehen sind. Für die Einschränkung der Sicht auf die Daten können Sicherheitsfilter

angelegt werden. Angenommen, es existiert eine Dimension für die Vertriebsstruktur,

deren unterste Elemente die Vertriebsmitarbeiter darstellen, dann kann in Essbase

mit dem in Listing 3-7 dargestellten Filter die Sicht für den Mitarbeiter „Max Muster-

mann“ so eingeschränkt werden, dass dieser nur die ihm zugehörigen Kennzahlen

plus alle (konsolidierten) Vorfahren sehen kann. Die Kennzahlen seiner Kollegen

kann er nicht einsehen.

01 02 03 04

// Lesezugriff auf das Element 'Max Mustermann' // inklusive aller Vorfahren CREATE OR REPLACE FILTER <würfel>.<filtername> READ ON @IANCESTORS('Max Mustermann');

Listing 3-7: Sicherheitsfilter (Essbase) [Eigene Darstellung]

Der Großteil der Anwender gehört zu der Kategorie der Standard-Benutzer. Für die-

se Anwender ist das BIS ein Hilfsmittel, das nicht unbedingt täglich verwendet wird

(sondern nur einmal am Anfang des Monats, wenn die aktuellsten Zahlen verfügbar

sind). Da die Nutzungsfrequenz eher niedrig ist, muss die Benutzerfreundlichkeit

dementsprechend hoch sein. Das Front-End wird vom Hersteller des OLAP-Systems

bereitgestellt, daher kann auf die Benutzerschnittstelle und dessen Verhalten kein

Einfluss genommen werden. Der Einflussfaktor der Entwickler beschränkt sich also

auf das Betriebsumfeld und auf das Design der Berichte.

Zu dem Betriebsumfeld zählt die Hardware- und Softwareausstattung der Anwender.

Hier ist oftmals der vom Anwender verwendete Browser ein Störungsherd. Durch

veraltete Versionen der Browser oder aber durch Browser-Erweiterungen wie Adobe

Flash kann es hier zu diversen Komplikationen kommen.

Beim Design der Berichte kommt es vor allem darauf an, ob die Kennzahlen korrekt

dargestellt werden. Wenn etwa eine Kennzahl zu lang für die Breite einer Spalte ist,

darf die Kennzahl nicht abgeschnitten werden, weil dadurch falsche Informationen

entstehen würden. Stattdessen muss die Kennzahl zum Beispiel mit ####### ge-


kennzeichnet werden. Nach einem ähnlichen Prinzip muss auch bei fehlenden oder

nicht-berechtigten Werten vorgegangen werden: Diese Werte dürfen nicht als 0 an-

gezeigt werden, sondern beispielsweise als #Missing oder #NoAccess. Die Tabelle

3-13 soll die Darstellung der Kennzahlen verdeutlichen. Der Vertriebsmitarbeiter

„Max Mustermann“ darf nur seine eigenen Kennzahlen sehen und nicht die seiner

Kollegin „Erika Musterfrau“. Der Zeitpunkt des Berichtsaufrufes ist Anfang Oktober

2011, dementsprechend gibt es noch keine Werte für das vierte Quartal. Die Summe

der eingenommenen Beiträge als Zahl ist zu breit für das Tabellenlayout und ist des-

halb ohne eine Anpassung der Spaltenbreite nicht darstellbar.

Max Mustermann Erika Musterfrau

Abgeschl. Versicherungen

Eingenom. Beitrag

Abgeschl. Versicherungen

Eingenom. Beitrag

Quartal 1 154 30.572,42 #NoAccess #NoAccess



Quartal 4 #Missing #Missing #NoAccess #NoAccess

2011 Gesamt 324 ########## #NoAccess #NoAccess

Tabelle 3-13: Korrekte Darstellung von Kennzahlen [Eigene Darstellung]

Von den „VIP“-Benutzern können weitere Forderungen an die Benutzerfreundlichkeit

kommen. Für diese Anwender werden in der Regel sogenannte Pixel-Perfect Berich-

te erstellt, die durch Firmenlogos und das Corporate Design aufgewertet werden.

Neben der korrekten Darstellung der Kennzahlen ist hier auf das exakte Einhalten

der verwendeten Farben und Logos zu achten.

3.6.2. Prüftechniken für ein Reporting Front-End

3.6.2.1 Nichtfunktionale Prüftechniken für ein Reporting Front-End Hinter einem Sicherheitskonzept steckt meistens ein Rollenkonzept. [vgl. Kem10, S.

50f] Die Rollen beziehen sich auf alle drei Sicherheitsebenen (Front-End, Bericht,

OLAP-Würfel). Zum Überprüfen der Sicherheitsbestimmungen müssen je Ebene alle

möglichen Benutzerklassen bzw. Rollen ermittelt und in Kombination geprüft werden.


Wie die nachfolgenden Tabellen zeigen, sind die Rollen aufeinander aufbauend und

erweitern sich. Ein Benutzer benötigt mindestens die Front-End Rolle „BI-Anwender“

um sich am System anmelden zu können. Die Rollen auf Ebene der Berichte und der

OLAP-Würfel konkretisieren die weiteren Zugriffsrechte.

Rollenzuordnung Berechtigung Front-End Keine Benutzer kann sich nicht am System anmelden.

BI-Anwender Benutzer kann sich am System anmelden.

Rollenzuordnung Berechtigung Bericht Keine Benutzer darf keine Berichte öffnen.

Standard Benutzer kann Vertriebsberichte lesend öffnen.

Power Benutzer kann Vertriebsberichte lesen und bearbeiten.

... ...

Rollenzuordnung Berechtigung Würfel Keine Benutzer darf keine Daten sehen.

Mitarbeiter Benutzer darf nur seine persönlichen Daten sehen.

Direktor Benutzer darf die Daten seiner Mitarbeiter sehen.

... ...

Tabelle 3-14: Sicherheitsrollen [Eigene Darstellung]

Aufgrund des erweiternden Charakters der Rollen reicht es aus, je Ebene die zuge-

hörigen Rollen einzeln zu testen und nicht in allen Kombinationen. Verdeutlicht wird

dieses, wenn die Rollen in einer Entscheidungstabelle gegenübergestellt werden

(Tabelle 3-15). Insgesamt ergeben sich für das hier dargestellte Beispiel acht Testfäl-

le. Zum Testen können die Rollen nacheinander einem Test-Benutzer zugeordnet

werden, mit dem der Tester sich anmeldet und probiert, ob er die ihm zugesicherten

Rechte besitzt. Für den Testfall T4 lautet der zu testende Ablauf: 1) am System an-

melden à ok, 2) Bericht lesend öffnen à ok, 3) Bericht schreibend öffnen à verbo-

ten.


Rollen Front-End Keine BI-An. BI-An. BI-An. BI-An. BI-An. BI-An. Bi-An.

Bericht - - Keine Stand. Pow. Stand. Stand. Stand.

Würfel - - - - - Keine Mitarb. Direkt.

Berechtigung Systemzugriff N J J J J J J J

Bericht öffnen - - N J J J J J

Bericht ändern - - N N J N N N

Eigene Daten - - - - - N J J

Mitarbeiterdaten - - - - - N N J

T1 T2 T3 T4 T5 T6 T7 T8

BI-An. = BI-Anwender, Stand. = Standard, Pow. = Power, Mitarb. = Mitarbeiter, Diekt. = Direktor

Tabelle 3-15: Entscheidungstabelle Sicherheitsrollen [Eigene Darstellung]

Der Test der Benutzerfreundlichkeit muss von einer Auswahl an späteren Anwendern

durchgeführt werden. Um das Verhalten in der tatsächlichen Systemumgebung

überprüfen zu können, müssen die Tester unbedingt von ihren eigenen Arbeitsplät-

zen aus das System bedienen. Zur Kontrolle der Berichtslayouts empfiehlt sich, den

Würfel bereits mit echten bzw. realistischen Zahlen zu laden und die Test-Anwender

aus den verschiedenen Unternehmensbereichen mit ihren Rollen auszuwählen. Die

Benutzer müssen live mit dem System arbeiten und die Bedienung ausprobieren.

Jegliche Ungereimtheiten, die den Anwendern auffallen, müssen dann analysiert und

gegebenenfalls korrigiert werden.

3.7. Automatisierungssystem Da die Informationen im BIS in regelmäßigen Intervallen aktualisiert werden (täglich,

wöchentlich, monatlich), wird eine Job-Steuerung für die Automatisierung der betei-

ligten Prozesse eingesetzt. Ein Job orchestriert dabei für einen Themenbereich (z.B.

das oben genannte Beispiel Versicherungsgeschäft) die einzelnen Schritte der Da-

tenintegration und der Berechnung der OLAP-Würfel und sorgt dafür, dass sie zum

richtigen Zeitpunkt gestartet werden.


3.7.1. Besonderheiten eines Automatisierungssystems

3.7.1.1 Funktionale Besonderheiten eines Automatisierungssystems Als wichtigste Faktoren der Job-Steuerung ergeben sich das Ausführen der Jobs in

der richtigen Reihenfolge, das Einhalten von vorgegebenen Zeitfenstern sowie das

Reagieren auf Fehlersituationen. [vgl. Rai08, S. 483]

Der Job für einen Themenbereich kann aus folgenden sieben Prozessen bestehen:

Nr. Name Typ 1 Extraktion Talend Prozess

2 Säubern Talend Prozess

3 Harmonisieren Talend Prozess

4 Ausliefern Talend Prozess

5 Dimensionen Laden Essbase Skript

6 Fakten Laden Essbase Skript

7 Würfel Berechnen Essbase Skript

Tabelle 3-16: Prozess-Reihenfolge [Eigene Darstellung]

Es ist dabei klar, dass die eingegebene Reihenfolge eingehalten werden muss, weil

die Prozesse auf den Ergebnissen des vorherigen Prozesses aufbauen. Die Jobs

laufen für gewöhnlich über Nacht, damit am nächsten Morgen die aktualisierten In-

formationen im BIS auftauchen. Die Jobs müssen demnach bis zum Beginn des Ar-

beitstages (z.B. 08:00 Uhr morgens) terminiert sein.

Hält ein Prozess sein Zeitfenster nicht ein, weil etwa zu wenig Hardwareressourcen

zur Verfügung stehen, so kann dieses als Fehlverhalten bzw. als Fehlersituation ge-

wertet werden. Weitere Fehlersituationen sind Abbrüche der einzelnen Prozesse,

beispielsweise wenn die benötigte Datenbank für die Datenextraktion nicht erreichbar

ist. Bei solchen Fehlern hilft oftmals nur das Eingreifen eines Menschen in Form des

Systemadministrators. Nur ein Mensch kann in den unvorhersehbaren Fehlersituati-

onen entscheiden, wie zu reagieren ist und der weitere Ablauf zu gestalten ist. Somit

muss die Job-Steuerung einen Fehler in dem aufgerufenen Prozess bemerken (z.B.


durch einen Fehlercode, der zurückgegeben wird), daraufhin den Verantwortlichen

benachrichtigen und die weitere Verarbeitung des Jobs anhalten.

3.7.1.2 Nichtfunktionale Besonderheiten eines Automatisierungssystems Aus sicherheitstechnischer Sicht ist zu beachten, dass zu keinem Zeitpunkt Passwör-

ter in Klarschrift zu lesen sind. Bei Prozessaufrufen werden Benutzername und

Passwort für Datenbankzugriffe als Parameter von dem aufrufenden Job übergeben.

Der Prozessaufruf durch den Job kann etwa durch einen Kommandozeilenbefehl

erfolgen. Da die Ausgaben der Kommandozeile nachvollzogen werden können (z.B.

in einem Log), müssen die vertraulichen Passwörter unkenntlich gemacht werden.

3.7.2. Prüftechniken für ein Automatisierungssystem

3.7.2.1 Funktionale Prüftechniken für ein Automatisierungssystem Das richtige Reagieren auf Fehler in den aufgerufenen Prozessen kann mittels Ursa-

chen-Wirkungs-Analyse erfolgen. Die Ursachen ergeben sich je Prozess, ob dieser

erfolgreich abgeschlossen wurde. Die darauffolgenden Prozesse sind von dem Er-

gebnis abhängig. Die Wirkungen sind dabei der erfolgreiche Abschluss oder das Be-

nachrichtigen des Administrators im Fehlerfall.

Für das Überprüfen des Einhaltens der richtigen Prozessreihenfolge bieten sich vi-

suelle Hilfsmittel an. Ein Job unter realen Bedingungen besteht oftmals aus weit

mehr Prozessen, als in der Tabelle 3-16 dargestellt und auch Abhängigkeiten können

wesentlich komplexer sein. Ein klassischer Programmablaufplan (Abbildung 3-19)

kann hier helfen, einen Überblick zu erhalten. Dieser kann um weitere Angaben zur

Startzeit ergänzt werden, sodass alle Informationen zu dem Job an einer zentralen

Stelle ersichtlich sind. Teilweise werden vergleichbare Ablaufpläne bzw. Übersichten

von Job-Steuerungswerkzeugen automatisch generiert.

Ein solcher Job-Programmablaufplan stellt ähnlich wie ein Datenintegrationsprozess

einen Kontrollfluss dar. Der Kontrollfluss ergibt sich aus den aufgerufenen Prozessen

(Knoten) und den Prozessübergängen (Kanten) und kann aus dem Programmab-

laufplan abgeleitet werden. Das Kriterium der Zweigüberdeckung fordert hier, dass

jeder Prozess des Jobs einmal erfolgreich und einmal mit einem Fehler durchlaufen


wird. Damit wird geprüft, ob tatsächlich die einzelnen Prozesse mit ihren Abhängig-

keiten in der korrekten Reihenfolge ausgeführt werden und ob im Betrieb auch auf

einen Fehlerfall reagiert wird.

Abbildung 3-19: Job-Programmablaufplan [Eigene Darstellung]

3.7.2.2 Nichtfunktionale Prüftechniken für ein Automatisierungssystem Das Überprüfen der Verschlüsselung von Passwörtern kann mittels Review-Technik

durchgeführt werden. Dafür müssen alle Prozessaufrufe und Skripte analysiert wer-

den. Es wird geprüft, ob diese frei von klarschriftlichen Passwörtern sind und ob bei


kritischen Kommandozeilenaufrufen die Ausgabe der Befehlszeile auf der Konsole

unterdrückt wird. Im Windows- bzw. DOS-Umfeld geschieht dies etwa durch ein vor-

gestelltes @echo off Kommando.

3.8. Bewertung Nachdem in den vorherigen Abschnitten analysiert wurde, welches die zu prüfenden

Besonderheiten und Fehlersituationen bei der Entwicklung eines BIS sind und wel-

che Prüftechniken dafür anwendbar sind, folgt in diesem Abschnitt eine Bewertung

der Analyseergebnisse. In der Tabelle 3-17 sind die Prüftechniken und deren An-

wendbarkeit noch einmal als Übersicht zusammengetragen.

Äqu

ival

enzk

l.

Urs

.-Wirk

.

Kon

trol

lflus

s

Dat

enflu

ss

Ano

mal

ie

Slic

ing

Vis.

Hilf

sm.

Stila

naly

se

Rev

iew

Met

riken

Eff iz

ienz

Sich

erhe

it

Ben

utzb

arke

it

Modellie-rung ✔ ✔ ✔

Daten-integration ✔ ✔ ✔ ✔ ✔ ✔ ✔ ✔ ✔ ✔ ✔

Data Warehouse ✔ ✔ ✔ ✔ ✔

OLAP-System ✔ ✔ ✔ ✔

Reporting Front-End ✔ ✔

Automati-sierung ✔ ✔ ✔ ✔

Äquivalenzkl. = Äquivalenzklassen, Urs.-Wirk. = Ursache-Wirkung-Analyse, Vis. Hilfsm. = Visuelle Hilfsmittel

Tabelle 3-17: Prüftechniken Big Picture [Eigene Darstellung]

Modellierung Bei der Entwicklung klassischer Software gehört der Einsatz visueller Hilfsmittel (z.B.

UML-Fachklassendiagramm) während der Analyse- und Entwurfsphase zum bewähr-

ten Stand der Technik. Die Verwendung einer multidimensionalen Modellierungsno-


tation als gemeinsame Sprache zwischen Auftraggeber und Entwickler kann helfen,

Fehler aufgrund von Missverständnissen oder unzureichender Spezifikationen zu

vermeiden. Mithilfe der Stilanalyse und der vorgestellten Metriken lassen sich dar-

über hinaus Fehler und Schwächen der Modellierung aufdecken.

Da in dieser frühen Phase des Entwicklungsprozesses viele Fehler ihren Ursprung

haben, sind sowohl die visuellen Hilfsmittel als auch die Stilanalyse und Metriken

sehr effektive Prüftechniken. Der Aufwand für die Anwendung der Prüftechniken ist

sehr gering. Für die Modellierung gibt es entsprechende Modellierungswerkzeuge

und die Ermittlung der Metriken kann beispielsweise mithilfe von Excel geschehen.

Datenintegration Das Verarbeiten von Daten aus Legacy-Systemen ist oftmals sehr komplex und feh-

leranfällig. Mithilfe der Äquivalenzklassenbildung lassen sich die verschiedenen Aus-

prägungen der Datenformate ermitteln und dann überprüfen. Die Äquivalenzklassen-

bildung ist ein einfaches Verfahren, das bei der Analyse und Implementierung von

Datenformaten oftmals bereits implizit angewendet wird. Der Aufwand für die Prüf-

technik ist somit gering. Die systematische und bewusste Anwendung der Prüftech-

nik hilft dem Tester, mehr Fehler zu finden als bei der impliziten Anwendung.

Für die Überprüfung der Verarbeitungsregeln müssen auch Kombinationen bzw.

Wechselwirkungen der Äquivalenzklassen berücksichtigt werden. Auch hier wird die

Ursache-Wirkungs-Analyse oftmals implizit durchgeführt. Eine systematische An-

wendung ist also ebenfalls wenig aufwendig, kann jedoch bei der Testdurchführung

ihre vollen Stärken ausspielen und Fehler effektiver aufdecken. Gerade das Aufstel-

len eines Ursache-Wirkungs-Graphen und der daraus abgeleiteten Entscheidungsta-

belle hilft, alle Situationen während der Datenintegration zu prüfen.

Das kontrollflussorientierte Testen gilt für die Beurteilung der Testfallabdeckung als

unverzichtbar. [vgl. Lig09, S. 138] Bei der Nutzung eines grafischen Datenintegrati-

onswerkzeuges liegt der Kontrollflussgraph automatisch vor. Somit ist die Grundlage

des kontrollflussorientierten Tests bereits geschaffen und es ist kein gesondertes

Testwerkzeug notwendig. Der gesamte Testaufwand ergibt sich aus dem angewen-

deten Überdeckungsgrad. Da der Anweisungsüberdeckungstest im Allgemeinen als

zu schwach gilt [vgl. Lig09, S. 87], empfiehlt sich der Zweigüberdeckungstest als Mi-

nimalanforderung. Hierfür müssen alle Knoten und Kanten des Datenintegrationspro-


zesses einmal durchlaufen werden. Der Aufwand ist also überschaubar. Der Bedin-

gungsüberdeckungstest hingegen ist zwar noch effektiver, aber auch sehr aufwen-

dig. Liggesmeyer schreibt in seiner Bewertung des kontrollflussorientierten Testens,

dass die Entscheidung für bzw. gegen den Bedingungsüberdeckungstest von der

Komplexität der Verarbeitungslogik abhängt:

„Die Bedingungsüberdeckungstests sind insbesondere dann als Testtechniken

interessant, wenn eine komplizierte Verarbeitungslogik vorliegt, die zu kompli-

ziert aufgebauten Entscheidungen führt. [...] Die Verwendung von Bedingungs-

überdeckungstests ist in manchen kritischen Fällen verbindlich.“ [Lig09, S. 117]

Obwohl das datenflussorientierte Testen eine sehr effektive Prüftechnik ist, hat es in

der Praxis kaum eine Bedeutung. [vgl. Lig09, S. 177] Gerade für das Überprüfen von

Datenintegrationsprozessen, wo es genau auf das korrekte Verarbeiten von Daten-

flüssen ankommt, bietet sich diese Prüftechnik sehr an. Für das datenflussorientierte

Testen muss der Kontrollflussgraph um die Datenzugriffe ergänzt werden. Diese Er-

weiterung ist jedoch nicht Bestandteil des vom Datenintegrationswerkzeug bereitge-

stellten Kontrollflussgraphen und ist manuell durchzuführen. Da in einem Dateninteg-

rationsprozess oft hundert oder mehr Attribute verarbeitet werden, ist diese manuelle

Durchführung nicht praxistauglich.

Diese Problematik ergibt sich folglich auch für die Durchführung einer Anomalieana-

lyse. Für triviale Anomalien, wie unerreichbare Prozessschritte als auch nicht ver-

wendete Attribute (du-Anomalie), bieten Datenintegrationswerkzeuge integrierte

Funktionalitäten, die einen Entwickler direkt auf solche Anomalien hinweisen.

Das Slicing in Form der Data Lineage bzw. Impact Analyse kann für die Fehlersuche

als ergänzende Prüftechnik angewendet werden. Wenn bei der Testdurchführung

fehlerhafte Attribute aufgefallen sind, können mithilfe der beiden Analysen die parti-

zipierenden Prozessschritte aufgedeckt werden. Die Slicing-Funktionalität ist in vie-

len Datenintegrationswerkzeugen enthalten.

Die Durchführung eines Reviews geschieht manuell durch einen unabhängigen Ent-

wickler. Somit ist diese Prüftechnik mit einem hohen Aufwand verbunden. Da durch

eine unabhängige Kontrolle sowohl Fehler in der Verarbeitungslogik als auch Miss-

achtungen von Programmierkonventionen aufgedeckt werden (Stilanalyse), empfiehlt

sich diese Prüftechnik trotz des hohen Aufwandes. Eine automatisierte Stilanalyse

durch das Datenintegrationswerkzeug ist nicht möglich, weil nur ein Mensch die Ver-


ständlichkeit der Benennung sowie die Übersichtlichkeit der Anordnung von Pro-

zessschritten beurteilen kann. Besonders im Hinblick auf die Dokumentationspflicht

wird die Notwendigkeit eines Reviews verdeutlicht.

Neben der korrekten Verarbeitung muss der Datenintegrationsprozess auch effizient

mit den zur Verfügung stehenden Hardware-Ressourcen umgehen. Ein Effizienztest

ist somit unerlässlich. Die Informationen über die Verarbeitungsgeschwindigkeit (Da-

tensätze pro Sekunde) werden durch das Datenintegrationswerkzeug aufgestellt. Die

Überwachung der Prozessor- und Arbeitsspeicherauslastung geschieht über die vom

Betriebssystem bereitgestellten Mittel (z.B. Windows Task-Manager). Der Effizienz-

test wird mit einem echten Datenabzug durchgeführt, es müssen somit keine separa-

ten Testdatensätze aufgestellt werden.

Da die Datenintegration insgesamt der komplexeste und aufwendigste Teil während

der Entwicklung eines BIS ist [vgl. Gol11, S. 1197], muss sie entsprechend ausgiebig

und umfangreich getestet werden. Das Anwenden der vielen genannten Prüftechni-

ken ist somit gerechtfertigt und auch sehr sinnvoll.

Data Warehouse Das Bilden von Äquivalenzklassen für die Überprüfung von Tabellen-Strukturen ist

eine einfach anwendbare Prüftechnik. Nur so kann sichergestellt werden, ob eine

Tabelle korrekt definiert ist und die für sie vorgesehenen Daten speichern kann. Im

Abschnitt 5.1 wird für diesen Test ein passendes Werkzeug vorgestellt.

Sowohl die Nutzung visueller Modellierungswerkzeuge, als auch die Definition von

Programmier- und Sicherheitskonventionen gehören zum Stand der Technik bei der

Verwendung von Datenbanken. Somit sind die visuellen Hilfsmittel, die Stilanalyse

und ein Sicherheitstest obligatorisch. Auch das Überprüfen der Geschwindigkeit und

des Speicherverbrauches ist in vielen Unternehmen ein verpflichtender Test. Der

Test wird automatisch mit dem Effizienztest der Datenintegration durchgeführt, es

entsteht kein zusätzlicher Aufwand.

OLAP-System Das Überprüfen der Dimensionen und Kennzahlen in dem Würfel ist ein sehr auf-

wendiges Verfahren. Aufgrund der verschiedenen Kombinationsmöglichkeiten der

Dimensionen existiert eine sehr große Anzahl an unterschiedlichen Darstellungen


bzw. Ausprägungen der Kennzahlen. Hier gilt es, die Anzahl der Testfälle auf ein

durchführbares Maß zu beschränken. Die reine Prüfung der korrekten Dimensionali-

tät ist wenig aufwendig, weil für jede Dimension ein Testfall ausreichend ist. Das Prü-

fen der Kennzahl ist jedoch weitaus komplexer. Selbst mit dem Vorgehen nach

Rainardi und der Bildung von Äquivalenzklassen können je nach Anzahl der Dimen-

sionen und Kennzahlen mehrere hundert oder tausend Testfälle entstehen. Bei be-

sonders großen Würfeln ist die Testfallanzahl dann noch weiter einzuschränken, bei-

spielsweise indem je Dimension nur die obersten zwei sowie die unterste Hierarchie-

ebene geprüft werden.

Auch für das OLAP-System empfiehlt sich der Einsatz visueller Hilfsmittel und der

Stilanalyse. Durch die Verwendung einer multidimensionalen Notationsform während

der Analyse und Entwurfsphase liegt ein visuelles Hilfsmittel bereits vor. Die vorge-

schlagene Ergänzung der Notation um die Konsolidierungsvorschriften bringt weitere

Informationen in das Modell mit ein.

Die Berechnung von Speicherbedürfnissen eines Würfels im Vorfeld kann nachträgli-

che Anpassungsarbeiten vermeiden. Es empfiehlt sich, die vom Hersteller vorge-

schlagenen Tipps für die physikalische Speicherform des Würfels zu berücksichtigen.

Ähnlich wie bei RDBMS gibt es auch für MDBMS eine Vielzahl von „Tuning“-

Optionen (z.B. Kompression und Partitionierung), die angewendet werden kann.

Reporting Front-End Das Überprüfen der Benutzbarkeit zusammen mit den tatsächlichen Anwendern des

Reporting Front-Ends ist unverzichtbar. Selbst vermeintliche Kleinigkeiten wie Far-

ben, die nicht zum Corporate Design passen, können eine Ablehnungshaltung bei

den Anwendern verursachen. In vielen Unternehmen existieren mittlerweile soge-

nannte Business Intelligence Competence Center (BICC). Diesem Kompetenzzent-

rum gehören ausgewählte Fachbereichsmitarbeiter an, die in dem Unternehmen das

Thema BI vorantreiben. Das BICC erteilt Vorgaben zu der Benutzbarkeit und ist so-

mit auch für die Abnahme verantwortlich.

Auch Sicherheitskonzepte werden von dem BICC aufgestellt. Aufgrund der Sensibili-

tät der Informationen ist ein Sicherheitstest der verschiedenen Benutzerrollen ver-

pflichtend. Da es aber für gewöhnlich eine überschaubare Anzahl von Rollen gibt, ist

der Sicherheitstest nicht sehr aufwendig.


Automatisierungssystem Ob der gesamte Job sein Zeitfenster einhält, kann nur unter annähernd realen Be-

dingungen verlässlich überprüft werden. Die häufigsten Gründe, warum ein Prozess

sein Zeitfenster überschreitet, sind Ressourcenengpässe der verfügbaren Hardware.

Solche Engpässe entstehen durch die vielen parallel laufenden Jobs für die ver-

schiedenen Themenbereiche. Es kann daher ausnahmsweise vorkommen, dass der

Test erst im Produktivsystem durchgeführt werden kann. Die Liste aller möglichen

Fehlersituationen ist im Vorfeld nicht bestimmbar, da auch nichtvorhersehbare exter-

ne Einflüsse Fehler verursachen können, wie beispielsweise ein Brand im Rechen-

zentrum. Somit kann nur geprüft werden, ob ein definierter Fehler, wie die Über-

schreitung des Schwellwertes einer Qualitätsregel, während der Datenintegration

auch tatsächlich gefangen und berücksichtig wird. Hierfür bietet sich die Ursachen-

Wirkungs-Analyse an, um das Reagieren auf einen einzelnen Prozessabbruch zu

testen. Eine kontrollflussorientierte Betrachtung kann zusätzliche Aussagen über die

Testvollständigkeit geben.

Um stets den Überblick über die Abhängigkeiten der verschiedenen Abläufe sowie

deren Zeitfenster zu bekommen, bieten sich visuelle Darstellungsformen an. Wäh-

rend des Betriebes kann in einer Fehlersituation (Programmabbruch) mithilfe des

Programmablaufplanes schnell festgestellt werden, welche Folgeprozesse von die-

sem Abbruch betroffen sind und gegebenenfalls wiederholt werden müssen.

Dass Passwörter nicht in Klarschrift in Startskripten stehen dürfen, zählt zu den all-

gemeinen Sicherheitsbestimmungen eines Unternehmens. Eine Prüfung mittels Re-

view kann mögliche Verstöße gegen diese Bestimmung aufdecken.

Kapitel 4 - Testen während des Betriebes

4. Testen während des Betriebes

4 Kapitel 4

Testen während des Betriebes

In diesem Kapitel wird beschrieben, was während des Betriebes eines Business In-

telligence Systems zu beachten ist und welche Fehlersituationen auftreten können.

Das Testen bezieht sich dabei auf das Überwachen und Kontrollieren der automati-

sierten Abläufe sowie auf das Validieren von bereitgestellten Kennzahlen.

Übersicht 4. Testen während des Betriebes ........................................................................... 97

4.1. Tätigkeiten während des Betriebes ................................................................. 98

4.2. Fehlersituationen während des Betriebes ....................................................... 99

4.3. Korrektheit der Daten .................................................................................... 102


4.1. Tätigkeiten während des Betriebes Neben der Betreuung der Anwender (Support) gehört die Wartung zu den Hauptauf-

gaben eines Entwicklers während des Betriebes eines BIS. Unter der Systemwartung

wird im Allgemeinen die Anpassung an systembedingte Veränderungen des Umfelds

und die Beseitigung von Fehlern verstanden. Da das BIS sehr viele Kontaktpunkte

und Abhängigkeiten zu anderen Systemen, können im Betrieb viele extern verschul-

dete Fehlersituationen bzw. Anpassungsbedarfe auftreten.

4.1.1. Betrieb

Der Betrieb eines BIS besteht aus der Überwachung und Steuerung der automati-

sierten Abläufe. Für die viele Anwender des BIS ist das Starten des Reporting Front-

Ends und das Abrufen der aktuellen Zahlen einer der ersten Arbeitsschritte am Mor-

gen, um die Tagesaktivitäten (z.B. Vertriebssteuerung) zu planen. Wenn in der Nacht

also ein Job abgebrochen ist und die aktuellen Zahlen nicht bereitstehen, so besteht

für den Entwickler ein schneller Handlungsbedarf, um die Zahlen schnellstmöglich

nachzuliefern.

Der „Super-GAU“ während des Betriebes tritt jedoch ein, wenn die Kennzahlen falsch

sind. Bei besonders kritischen Themenbereichen wie beispielsweise der Deckungs-

beitragsrechnung, deren Kennzahlen für den Vorstand, den Aufsichtsrat oder externe

Interessensgruppen (Aufsichtsbehörden, Aktionäre, Presse) bestimmt sind, kann da-

her ein gesondertes Test- und Freigabeverfahren gefordert sein. Die wichtigen

Kennzahlen müssen unter Umständen validiert werden, bevor sie veröffentlicht wer-

den.

4.1.2. Anpassungen

Eine Anpassung der multidimensionalen Datenmodelle und der Datenintegrations-

prozesse ist dann nötig, wenn von dem Auftraggeber neue Anforderungen (zusätzli-

che Kennzahlen oder Dimensionen) formuliert werden. Solche Anpassungen stellen

eine Weiterentwicklung des Systems dar. Somit sind für die Implementierung der Er-

weiterungen die Prüftechniken aus Kapitel 3 anzuwenden. Um sicherzustellen, ob die

bestehenden Funktionen durch die Anpassungen nicht negativ beeinflusst wurden,


müssen Regressionstests (das Wiederholen der Testfälle der vorherigen Version)

durchgeführt werden. Außerdem müssen Dokumentationen entsprechend aktualisiert

werden.

4.2. Fehlersituationen während des Betriebes Auch wenn das BIS während der Entwicklung ausgiebig getestet wurde, kann es

während des Betriebes trotzdem zu Fehlersituationen kommen. Neben übersehenen

Implementierungsfehlern in den Prozessen kann es auch zu Fehlern kommen, die

unabhängig von der Implementierung entstanden sind.

4.2.1. Falsche Datenlieferungen

Der Datenintegrationsprozess benötigt die Daten aus den Quellsystemen als Einga-

bedaten. Eine mögliche Fehlersituation tritt dann ein, wenn die Eingabedaten nicht

vorhanden sind und der Prozess somit nicht ablaufen kann.

Gerade bei einem direkten Zugriff auf operative Tabellen ist die Gefahr für einen

nicht erfolgreichen Zugriff groß. So kann es passieren, dass das Quellsystem auf-

grund von Wartungsarbeiten vorrübergehend abgeschaltet wurde, es überlastet ist

und nur sehr langsame Zugriffe zulässt oder sich Strukturen der Tabellen geändert

haben. Aber auch bei einem indirekten Zugriff über Schnittstellen kann es zu diesen

Fehler kommen. Wartet der Datenintegrationsprozess etwa auf die Lieferung eines

Datenabzuges als Datei in ein spezielles Verzeichnis, so kann bei einer ausbleiben-

den Lieferung ebenfalls keine Verarbeitung stattfinden.

Eine zweite Gefahr sind falsche Eingabedaten. Beim indirekten Zugriff auf Datenab-

züge als Datei kann versehentlich die vorherige Periode erneut geliefert werden.

Auch bei direkten Zugriffen auf die Quellsysteme lassen sich falsche Datenabzüge

nicht verhindern. Ein Negativszenario kann sein, dass sträflicherweise im operativen

System mit Testdaten gearbeitet wurde. Wenn dieser Test von den Entwicklern des

operativen Systems nicht kommuniziert wurde, greift der Datenintegrationsprozess

bei seinem Datenabzug Testdaten mit ab und verarbeitet diese fälschlicherweise.

Das Problem aus Sicht des Datenintegrationsprozesses ist folglich, dass dieser nicht

erkennen kann, ob die Eingabedaten korrekt sind. Die einzige Stelle, an der Daten


abgewiesen werden, ist das Anwenden der Qualitätsregeln. Wenn jedoch eine dop-

pelte Datenlieferung einer Periode erfolgt und die Daten gemäß der Qualitätsregeln

syntaktisch und semantisch korrekt sind, werden sie auch weiterverarbeitet.

Key Name Job GueltigVon GueltigBis AnlageID AendID 1736 Mustermann Student 01.09.2003 31.08.2006 273 309

5392 Mustermann Entwickler 01.09.2006 31.05.2011 309 436

9287 Mustermann Manager 01.06.2011 31.12.9999 436 NULL

11826 Musterfrau Direktor 01.06.2011 31.12.9999 441 NULL

Tabelle 4-1: Zeitscheiben mit Prozess-ID [Eigene Darstellung]

Da jederzeit mit einer falschen Datenlieferung gerechnet werden muss, muss sich

ein Entwickler überlegen, wie er die Korrektur der Lieferung schnell und einfach

durchführen kann. Besonders schmerzhaft ist es, wenn aufgrund einer falschen Lie-

ferung die Faktentabelle und die Dimensionstabellen komplett neu bestückt werden

und alle historischen Datenstände erneut eingespielt werden müssen. Einfacher ist

es, wenn lediglich die falsche Lieferung entfernt wird und anschließend nur die korri-

gierten Daten neu eingespielt werden.

Um Datenlieferungen rückgängig machen zu können, müssen diese eindeutig identi-

fizierbar sein. Es empfiehlt sich, jeden Prozess, der Daten im Data Warehouse

schreibt oder manipuliert, mit einer eindeutigen ID auszustatten und Datensatzände-

rungen damit zu kennzeichnen. Damit ein vorher gültiger Stand wiederhergestellt

werden kann, dürfen Änderungen nicht physisch durch ein UPDATE erfolgen, sondern

logisch mittels Zeitscheiben. Jeder Datensatz erhält zwei Zeitstempel, die Auskunft

geben, über welchen Zeitraum (gültig-von und gültig-bis) er gültig war bzw. ist. Der

gerade aktuelle Satz hat als gültig-bis-Datum den maximalen Zeitstempel

(31.12.9999). Dieses Verfahren ist bereits von den Typ 2 SCD bekannt (Tabelle 3-4).

Eine Erweiterung um die Prozess-ID vereinfacht hierbei jedoch das Aufspüren der

fehlerhaften Lieferung. Ein Prozess trägt seine ID beim Anlegen einer neuen Zeit-

scheibe sowohl bei der aktuell gültigen Zeitscheibe als Anlage-ID ein als auch bei der

vorher gültigen verkürzten Zeitscheibe als Änderungs-ID.


Wenn in dem Beispiel der Tabelle 4-1 die Lieferung des Prozesses „436“ falsch war,

lautet das SQL-Statement zum Zurücknehmen der Änderungen wie folgt:

01 02 03 04 05 06 07

DELETE FROM DIM_ORGANIGRAMM WHERE AnlageID = 436; UPDATE DIM_ORGANIGRAMM SET GueltigBis = '31.12.9999' ,AendID = NULL WHERE AendID = 436;

Listing 4-1: Korrigieren einer falschen Lieferung [Eigene Darstellung]

4.2.2. Unachtsamkeit

Automatismen und gleichartige bzw. monotone Abläufe verleiten Menschen zur Un-

achtsamkeit. Hieraus ergibt sich unter Umständen das Problem, dass ein Fehler in

der Verarbeitung während des Betriebes nicht wahrgenommen wird. Vornehmlich

wird eine Unachtsamkeit durch eine Überflutung von Benachrichtigungen des BIS

ausgelöst. Wenn jeder kleinste Verarbeitungsschritt sowohl beim erfolgreichen als

auch nicht erfolgreichen Durchlaufen eine Benachrichtigungsmail versendet, so kann

das Postfach des Entwicklers am Morgen schnell sehr voll werden. Wenn von 100

Mails 99 einen Erfolgsstatus melden und eine einzige Mail auf einen Fehler hinweist,

so kann diese wichtige Mail leicht übersehen werden. Es ist also darauf zu achten,

positiv Meldungen weitestgehend zu vermeiden und nur die tatsächlich wichtigen

Informationen wie Fehler und Warnungen zu kommuniziert.

4.2.3. Infrastruktur

Wie jede Software ist auch das BIS abhängig von der Infrastruktur in der es einge-

bunden ist. Problemen mit dem Betriebssystem, der Hardware oder dem Netzwerk

wirken sich direkt auf das BIS aus. Entsprechend müssen Änderungen an der Infra-

struktur auch getestet werden. Verändert sich beispielsweise die Adresse von einem

Netzlaufwerk, so muss geprüft werden, ob ein Datenintegrationsprozess von diesem


Netzlaufwerk Dateien bezieht. Wenn ja, müssen diese Prozesse auf die neue Adres-

se umgestellt werden, damit ihre Dateizugriffe nicht ins Leere laufen.

Da das DWS sehr ressourcenhungrig ist, gilt es diese stets zu überwachen. Wenn

etwa die zur Verfügung stehenden Speicherkapazitäten an ihre Grenzen kommen,

müssen frühzeitig Gegenmaßnahmen getroffen werden (z.B. Aufstockung der Kapa-

zitäten). Selbiges gilt auch für die Ressourcen CPU und Arbeitsspeicher.

Ein grundsätzliches Problem bei BIS ergibt sich aus der Abhängigkeit von den einge-

setzten Produkten und Werkzeugen. Das im Anhang A exemplarisch gezeigte BIS

besteht aus fünf verschiedenen kommerziellen Produkten (Datenintegrationswerk-

zeug, relationale Datenbank, OLAP-System, Analyse Front-End, Job-Steuerung).

Jedes dieser Produkte kann selber fehlerhaft sein und Bugs enthalten. Somit ergibt

sich durch die eingesetzten Produkte einer weitere Fehlerquelle im Betrieb.

4.3. Korrektheit der Daten Die Korrektheit der durch das BIS bereitgestellten Kennzahlen ist essenziell wichtig.

Die Crux hierbei besteht im Erkennen von fehlerhaften Kennzahlen. Im einfachsten

Fall erkennen erfahrene Anwender sofort, wenn die Daten nicht stimmig sind, zum

Beispiel wenn die Werte plötzlich doppelt so hoch sind wie in den vorherigen Zeit-

räumen. Unter Umständen weichen die Kennzahlen nur minimal ab, beispielsweise

um wenige Cent. In diesem schwierigen Fall kann der Fehler unentdeckt bleiben. Ein

gesondertes Validierungsverfahren vor der Freigabe von Würfeln kann aus diesem

Grund gefordert werden.

Die zweite Schwierigkeit besteht in der Lokalisierung der Fehlerquelle. Die Ursache

kann eine fehlerhafte Verarbeitung des BIS sein, die beim Testen während der Ent-

wicklung nicht gefunden wurde. Aufgrund der genannten Abhängigkeiten zu den

Quellsystemen, ist es aber auch nicht auszuschließen, dass unverschuldet falsche

Daten in das DWS eingespielt werden.


4.3.1. Validierung von Kennzahlen

Bei besonders sensiblen bzw. kritischen Berichten kann ein Test des Würfels nach

dem turnusmäßigen Beladen mit neuen Daten gefordert sein, bevor die Freigabe für

die Anwender erteilt wird. Ohne einen Freigabetest besteht die Gefahr dass falsche

Kennzahlen in Umlauf geraten. Wie oben bereits erwähnt, können die Datenintegra-

tionsprozesse selber nicht feststellen, ob die gelieferten Daten fachlich valide sind.

Ein manueller Test ist also unausweichlich. Die Zuständigkeit des Testens fällt dabei

auf den fachlich bzw. inhaltlich für den Würfel verantwortlichen Mitarbeiter.

Für die Testdurchführung muss überlegt werden, wie die Kennzahlen validiert wer-

den können. Dafür muss definiert sein, was die „Wahrheit“ ist und wo bzw. wie diese

gefunden werden kann. Die eigentliche Wahrheit befindet sich natürlich im operati-

ven Quellsystem. Aus diesem müssen die Referenzkennzahlen durch spezielle Se-

lektionen ermittelt werden. Da aufgrund der hohen Anzahl von Kennzahlen nicht jede

einzelne überprüft werden kann, muss der Testumfang auf ein verträgliches Maß be-

schränkt werden. So reicht es etwa aus, die ursprünglichen Kennzahlen zu testen.

Die daraus abgeleiteten Kennzahlen können selber nur dann richtig sein, wenn der

Ursprung auch richtig ist. Bei der tatsächlichen Testdurchführung kann aus Dimensi-

onssicht vom Wurzelelement (dem obersten Element) aus gestartet werden und

dann Ebene für Ebene die folgenden Konsolidierungen geprüft werden (vgl. Ab-

schnitt 3.3.2.1).

Die Vergleichsselektionen haben einen ähnlichen Aufbau wie das SQL-Statement im

Listing 2-1, wobei je nach gerade ausgewählter Sicht mehr oder weniger Dimensio-

nen in die GROUP BY Klausel aufgenommen werden. Je mehr Quellsysteme für die

Erstellung der Referenzkennzahlen angesprochen werden müssen, desto mehr

nimmt auch die Schwierigkeit der Erstellung der Selektionen zu. All die Schemaver-

sätze, die durch die Datenintegrationsprozesse vereinheitlicht wurden, müssen in

den Statements nachgebildet werden. Das gesamte Freigabeverfahren ist somit ein

hoch komplexes und aufwendiges Unterfangen. Das Verfahren kann daher auch nur

bei Würfeln angewendet werden, die in einem sehr großen zeitlichen Intervall (mo-

natlich oder quartalsweise) erstellt werden. Da das Validieren durchaus eine Woche


Zeit in Anspruch nehmen kann, ist es bei Würfeln mit kurzen Intervallen (wöchentlich

oder täglich) nicht praktizierbar.

Für Themenbereiche mit einer hohen Aktualisierungsrate muss eine andere (automa-

tisierte) Lösung geschaffen werden. Die einzige hierfür Möglichkeit besteht darin, die

Qualitätsregeln der Datenintegration zu verschärfen und zu erweitern. Kimball et al.

[vgl. Kim04, S. 144ff] schlagen vor, die Qualitätsregeln um Statistiken zu erweitern.

Jeder Prozess protokolliert dabei pro Datenlieferung statistisch interessante Informa-

tionen. Von Interesse sind vor allem die Anzahl der verarbeiteten Datensätze sowie

Summen und Durchschnitte der verarbeiteten Kennzahlen. Beim Beispiel des Versi-

cherungsgeschäfts von oben protokolliert der Prozess pro Datenlieferung:

• Anzahl der verarbeiteten Datenätze

• Summe Versicherungsbeitrag

• Durchschnittlicher Versicherungsbeitrag

Mit diesen Informationen können dann bei jedem Lauf Abweichungen zu vorherigen

Läufen ermittelt werden und gegen Schwellwerte bzw. Regeln geprüft werden. An-

genommen es handelt sich um eine tägliche Verarbeitung, so kann eine Regeln

Schwankungen der Datensatzanzahl um mehr als ±10% verbieten. Eine zweite Re-

gel kann fordern, dass an zwei Tagen hintereinander die Summen und Durchschnitte

der Kennzahlen nicht gleich sein dürfen (exakt gleiche Kennzahlen deuten auf eine

Doppellieferung hin). Die Instrumente der Statistik bieten einem Entwickler eine Viel-

zahl von Stellschrauben, um automatisiert fehlerhafte oder fehlerverdächtige Daten-

lieferungen zu identifizieren.

4.3.2. Quality Gates

Wenn ein Anwender beim Freigabetest oder gar nach der Freigabe im Betrieb auf-

grund seiner Erfahrung erkennt, dass die Kennzahlen in einem Bericht falsch sind,

beginnt die Schwierigkeit des Auffindens der Fehlerquelle. Da die Daten auf dem

Weg aus dem Quellsystem bis in den Bericht durch eine Vielzahl von Prozessen auf-

bereitet wurden, gibt es auch entsprechend viele potenzielle Fehlerquellen.

Eine Möglichkeit das Validieren der Daten zu vereinfachen, ist die Einführung soge-

nannter Quality Gates („Qualitätsstufen“). Die Quality Gates ergeben sich aus den


einzelnen Stufen, die während der Datenaufbereitung aus den Quellsystemen bis in

den Bericht durchlaufen werden:

• Schnittstelle

• Säuberung (Staging Area)

• Harmonisierung (Staging Area)

• Sternschema

• OLAP-Würfel

Die einzelnen Stufen können dann leichter gegen die erwarteten Werte getestet wer-

den und der verantwortliche Prozess identifiziert werden.

Kapitel 5 - Testinfrastruktur

5. Testinfrastruktur

5 Kapitel 5

Testinfrastruktur

In diesem Kapitel wird beschrieben, wie die Testinfrastruktur eines BIS aussehen

kann. Zu dieser Infrastruktur zählen eine eigene (vom produktiven System gekoppel-

te) Umgebung sowie spezielle Testwerkzeuge.

Übersicht 5. Testinfrastruktur ................................................................................................ 106

5.1. Testwerkzeuge ............................................................................................. 107

5.2. Testsystem, Testteam und Testdaten ........................................................... 112


5.1. Testwerkzeuge Für das Testen von BIS existieren keine speziellen Testwerkzeuge. [vgl. Inf10, S. 9;

Sun07, S. 3] Da das gesamte BIS kein eigenes Produkt ist, sondern aus Bausteinen

verschiedenster Hersteller zusammengesetzt wird (Beispiel im Anhang A), ist die

Schaffung eines zentralen und allgemeingültigen Testwerkezuges unrealistisch. Es

muss somit auf die bestehenden Möglichkeiten der einzelnen BI Produkte und auf

die Testwerkzeuge aus der klassischen Softwareentwicklung zurückgegriffen wer-

den.

Die visuellen Hilfsmittel finden Einsatz in nahezu allen Teilbereichen des BIS. Für

relationale Datenmodelle gibt es eine Reihe von Modellierungswerkzeugen, die so-

wohl eine Vorwärts- als auch Rückwärtsentwicklung erlauben. Dabei kann sowohl

aus einem bestehenden Tabellenschema ein Diagramm (z.B. ER-Diagramm) gene-

riert werden kann, als auch umgekehrt aus einem Diagramm ein Tabellenschema.

Für den Bereich der multidimensionalen Modellierung sieht die Werkzeugauswahl

weitaus schwieriger aus. Für die in dieser Arbeit verwendete ADAPT-Notation exis-

tiert eine kostenlose Schablonenvorlage für Microsoft Visio24. Eine automatisierte

Generierung von Würfelstrukturen im OLAP-System ist damit leider nicht möglich

und umgekehrt müssen Änderungen an dem physischen Datenmodell manuell in

dem Diagramm nachgepflegt werden. Trotzdem empfiehlt es sich, gerade während

der Analyse und Entwurfsphase auf die Möglichkeiten der Modellierung zurückzu-

greifen. Vor der endgültigen Festlegung auf eine Notationsform, ist daher der Markt

auf zur Verfügung stehende Modellierungswerkzeuge zu untersuchen.

Aus funktionaler Sicht werden im BIS Daten aufbereitet und dabei in andere Sche-

mata oder Darstellungsformen überführt. Bei der Durchführung der funktionalen

Tests gilt es zu prüfen, ob Eingangsdatensätze tatsächlich in das erwartete Aus-

gangsformat überführt wurden. Wird etwa durch einen Harmonisierungsprozess der

Schlüssel für das Geschlecht vereinheitlicht, so wird erwartet, dass ein Datensatz mit

der Ausprägung „männlich“ anschließend die Ausprägung „M“ besitzt. Grundsätzlich

kann diese Prüfung manuell erfolgen, indem per SQL das Ergebnis eines Prozesses

24 http://www.symcorp.com/tech_expertise_design.html (Abgerufen 27.01.2012)


selektiert und vom Tester selbst abgeglichen wird. Ein manueller Abgleich ist jedoch

zum einen zu langsam und zum anderen auch zu ungenau, weil das menschliche

Auge sich bei einer Überflutung von Zahlen schnell irren kann. Somit wird für die ef-

fektive Testdurchführung ein Werkzeug benötigt, das Datensätze automatisch ab-

gleicht.

01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 17

<dataset> <table name="KUNDE"> <column>ID</column> <column>NAME</column> <column>GESCHLECHT</column> <row> <value>162</value> <value>Max Mustermann</value> <value>M</value> </row> <row> <value>294</value> <value>Erika Musterfrau</value> <value>W</value> </row> </table> </dataset>

Listing 5-1: Erwartete Datenätze als XML-Datei (DbUnit) [Eigene Darstellung]

Genau diesen Ansatz verfolgt das freie Datenbank-Testwerkzeug DbUnit25. DbUnit

ist eine Erweiterung des bekannten Java-Testwerkzeugs JUnit26 und nutzt dessen

Methoden zum Abgleichen eines erwarteten und tatsächlichen Sachverhaltes. Die

erwarteten Datensätze lassen sich hierbei sehr einfach in eine XML-Datei eintragen

(Listing 5-1), somit fällt das unter Umständen aufwendige Erstellen einer Vergleich-

stabelle innerhalb der Datenbank weg. Der Inhalt der zu prüfenden Tabellen wird

mittels getTable() komplett geladen oder alternativ über ein selbstgeschriebenes

SQL-Statement eingeschränkt. Dann werden die geladenen Datensätze mittels

25 Weitere Informationen unter http://www.dbunit.org (Abgerufen 29.01.2012) 26 Weitere Informationen unter http://www.junit.org (Abgerufen 29.01.2012)


assertEquals()gegen die Testdatensätze der XML-Datei geprüft (Listing 5-2). Je

nachdem, ob der Test erfolgreich war oder nicht, ist der „JUnit-Balken“ entsprechend

grün oder rot. Im Fehlerfall wird ein kurzer Hinweistext ausgegeben, welcher Ver-

gleich fehlgeschlagen ist (Abbildung 5-1).

Abbildung 5-1: Fehlgeschlagener Datenbank-Testfall (DbUnit) [Eigene Darstellung]

01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 17 18

@Test public void testKunde() throws Exception { // Erwartete Daten aus XML File xml = new File("C:\test.xml"); IDataSet expectedDataSet = new XmlDataSet(new FileInputStream(xml)); ITable expected = expectedDataSet.getTable("KUNDE"); // Tatsächliche Daten aus Tabelle IDataSet databaseDataSet = getConnection().createDataSet(); ITable actual = databaseDataSet.getTable("KUNDE"); // Vergleich Assertion.assertEquals(expected, actual); }

Listing 5-2: Datenbank-Testfall (DbUnit) [Eigene Darstellung]

Neben dem Abgleich von Datensätzen eignet sich DbUnit auch, um Strukturen von

angelegten Datenbanktabellen zu überprüfen. In der XML-Datei können die bei der

Grenzwertanalyse ermittelten Testdatensätze eingetragen und dann per INSERT-


Statement abgesetzt werden. Das Ergebnis des Tests lautet entsprechend, dass die

Datensätze erfolgreich oder nicht erfolgreich (SQLException) eingefügt wurden

(Listing 5-3).

01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 17 18 19 20 21 22

@Test public void testInsert() throws Exception { // Erwartete Daten aus XML // ... // INSERT-Statement absetzen DatabaseOperation.INSERT.execute( getConnection(), expectedDataSet); // Tatsächliche Daten aus Tabelle // ... // Vergleich Assertion.assertEquals(expected, actual); } @Test(expected = SQLException.class) public void testConstraint() throws Exception { // Negativ-Test, eine Exception wird erwartet DatabaseOperation.INSERT.execute( getConnection(), faultyDataSet); }

Listing 5-3: Datenbank-Testfall für Strukturen (DbUnit) [Eigene Darstellung]

DbUnit ist allerdings nur auf relationale Datenbanken ausgelegt und nicht auf mul-

tidimensionale OLAP-Datenbanken. Als Testwerkzeug-Ersatz hierfür kann Excel

herangezogen werden, wenn der Hersteller des OLAP-Systems eine Excel-

Erweiterung anbietet. In dem Excel-Tabellenblatt werden dann für die aufgestellten

Testfälle Selektionen vorbereitet und alle erwarteten Resultate in Vergleichszellen

eingetragen. Zwischen den Zellen der erwarteten und tatsächlichen Werte wird dann

jeweils mittels WENN-Funktion geprüft, ob die Werte gleich sind. Das Ergebnis des

Vergleichs kann mittels bedingter Formatierung optisch aufbereitet werden, sodass


wie in DbUnit rote und grüne Balken dargestellt werden. In der folgenden Abbildung

ist ein exemplarisches Test-Tabellenblatt in Excel dargestellt.

Abbildung 5-2: OLAP-Testfall (Excel)


Einige triviale Überprüfungen werden direkt durch die verwendeten BI-Produkte

durchgeführt. Essbase prüft beim Laden der Daten automatisch, ob ungültige Koor-

dinaten in dem Würfel referenziert werden und gibt eine entsprechende Warnung

aus. Talend kann beispielsweise die einfachen Kontrollfluss- und Datenflussanoma-

lien erkennen und gibt ebenfalls eine Warnung aus. Wie in Abbildung 3-12 darge-

stellt, bietet Talend auch eine integrierte Slicing-Funktionalität. Für das automatisierte

Testen eines Datenintegrationsprozesses schlägt Talend auf seiner Entwickler-

Website27 ein Verfahren vor. Das Vorgehen ist ähnlich zu DbUnit: Das tatsächliche

Ergebnis eines Prozesses wird mit Erwartungswerten abgeglichen. Die Einschrän-

kung bei diesem Verfahren ist allerdings, dass es nur mit einfachen CSV-Dateien

funktioniert und nicht mit Datenbanktabellen. Das Resultat des Tests (erfolgreich,

nicht erfolgreich) wird auf der Konsole ausgegeben. In der Abbildung 5-3 ist ein

exemplarischer Test dargestellt. Dabei werden drei Dateien parallel gegen Erwar-

tungswerte geprüft.

27 http://www.talendforge.org/wiki/doku.php?id=tests:automated_tests:design (Abgerufen 05.02.2012)


Abbildung 5-3: Test Unit Job (Talend) [Eigene Darstellung]

5.2. Testsystem, Testteam und Testdaten Das Testsystem bzw. die Testumgebung eines BIS orientiert sich an den Standards

der klassischen Programmierung. Das bedeutet, die übliche Dreiteilung in ein Ent-

wicklungs-, ein Test- und ein Produktionssystem findet hier genauso Anwendung.

Die Testumgebung kann sowohl zum Testen während der Entwicklung als auch zum

Validieren der Kennzahlen vor der Freigabe während des Betriebes genutzt werden.

Auch wenn in dieser Arbeit oft nur vom Entwickler die Rede ist, besteht das Testteam

nicht aus ihm alleine. Viele Informatikabteilungen unterhalten mittlerweile spezielle

Testgruppen mit speziell für das Testen geschulten Mitarbeitern. Ein Entwickler neigt

bei seinen eigenen Implementierungen dazu, nicht genau genug zu testen. Die spe-

ziellen Tester können den Entwickler unterstützen und sogar entlasten. Gleichzeitig

finden sie aufgrund ihrer Erfahrung oftmals mehr Fehler als der Entwickler selber.

Weiterhin gehören zu dem Testteam auch noch Datenbank- und Systemadministra-

toren sowie ausgewählte Endanwender. [vgl. Gol09, S. 24]

Für das Testen kleiner Funktionen (z.B. eine Qualitätsregel) werden in der Regel

synthetische Daten hergestellt, etwa durch die Äquivalenzklassenbildung. Für die

Überprüfung des Gesamtablaufes sowie für Effizienztests müssen jedoch realistische

und viele Testdaten vorliegen. Eine synthetische Testdatenerstellung für diese An-


forderungen ist oftmals zu aufwendig, deshalb werden für diese Tests Echtdaten aus

den operativen Systemen verwendet. Beim Testen mit Echtdaten sind allerdings die

datenschutzrechtlichen Bestimmungen zu beachten und personenbezogene Daten

müssen anonymisiert werden. Die Vorschriften zum Datenschutz geben jedoch auch

Ausnahmen vor, die für ein BIS für gewöhnlich erfüllt sind:

„Tests mit einer Kopie der erforderlichen, nicht-anonymisierten Originaldaten

(personenbezogene Echtdaten) sind nur zulässig, wenn [...]

• eine Anonymisierung der Originaldaten für die vorgesehene Test-

Konstellation nur mit einem unvertretbar hohem Aufwand verbunden wä-

re,

• bei der Durchführung oder Auswertung des Tests die schutzwürdigen

Belange der Betroffenen und die Informationssicherheit angemessen be-

rücksichtigt werden,

• Zugang zu diesen Daten nur Personen erhalten, die den jeweils maßge-

benden Vertraulichkeitsgrundsätzen und insbesondere datenschutzrecht-

lichen Vorschriften unterliegen.“ [BSI]

Bei Massendaten kann auch die Anonymisierung sehr aufwendig sein. Der zweite

und der dritte Aspekt sind aufgrund der hohen Vertraulichkeitsstufe des BIS ebenfalls

erfüllt.

Kapitel 6 - Konklusion

6. Konklusion

6 Kapitel 6

Konklusion

„[J]edes Softwaresystem ab einem bestimmten Maß an Komplexität [enthält]

Fehler.“ [Lig09, S. 4]

Da es sich bei Data Warehouse und Business Intelligence Systemen um Software-

systeme mit einer sehr hohen Komplexität handelt, ist die Gefahr für Fehler folglich

besonders hoch. Die Bedeutung des Testens dieser Systeme wird jedoch in der Lite-

ratur sehr wenig behandelt und auch in der Praxis findet es in der Regel weniger Be-

trachtung, als oftmals nötig. Golfarelli und Rizzi haben diesbezüglich eine Unterneh-

mensbefragung durchgeführt. Sie kommen zu dem Ergebnis, dass der Großteil der

befragten Unternehmen das Testen im Business Intelligence und Data Warehouse

Umfeld sehr informell und wenig organisiert angeht. [vgl. Gol11, S. 1183] Aus diesen

Umständen ergab sich die Motivation für die Anfertigung dieser Arbeit. Das Ziel war

dabei zu zeigen, was zu testen ist und welche Prüftechniken dabei angewendet wer-

den können.

Um einen Überblick zu den Thematiken „Data Warehouse und Business Intelligence

Systeme“ sowie „Testen von Software“ zu erlangen, wurden diese beiden Aspekte

zunächst vorgestellt. Als Referenzarchitektur eines Data Warehouse Systems wurde

der Ansatz nach Kimball et al. [Kim04] mit seinen Komponenten und Vorgehensmo-

dellen gewählt. Anschließend wurden allgemeine Softwareprüftechniken beschrie-

ben.

Im Hauptteil dieser Arbeit wurde analysiert, wie sich die Softwareprüftechniken auf

die verschiedenen Teilbereiche eines Business Intelligence Systems anwenden las-

sen. Als erstes wurde gezeigt, inwiefern sich Data Warehouse und Business Intelli-

gence Systeme von klassischen Softwaresystemen unterscheiden. Danach wurden

für die einzelnen Komponenten eines Business Intelligence Systems (Datenintegrati-

on, Data Warehouse, OLAP-System, Reporting Front-End und Automatisierungssys-

tem) anhand von Beispielen typische Fehlersituationen aus der Praxis beschrieben.

Zu diesen Situationen wurden exemplarisch Prüftechniken vorgestellt. Viele allge-

Kapitel 6 - Konklusion

meingültige Prüftechniken finden dabei ihren Einsatz wieder. Neben dem Testen der

Implementierung lag ein zusätzlicher Fokus auf einem vorgelagerten Schritt: dem

Überprüfen der multidimensionalen Modellierung.

Auch im alltäglichen Betrieb ist ein Business Intelligence System zu testen. Die Da-

ten im Data Warehouse werden regelmäßig aktualisiert. Aufgrund der vielen Abhän-

gigkeiten zu den umliegenden Quellsystemen, können fehlerhafte Datenlieferungen

im Data Warehouse nicht ausgeschlossen werden. Damit keine falschen Informatio-

nen in den Umlauf geraten, müssen besonders kritische Zahlen vor einer Freigabe

geprüft werden. Mithilfe von Statistiken zu den Datenverarbeitungen kann sogar ein

gewisses Maß an Automatisierung bei der Überprüfung erzielt werden. Mit einigen

einfachen Vorkehrungen können Falschlieferungen im Betrieb schnell korrigiert wer-

den.

Abschließend wurde beschrieben, wie die Infrastruktur für das Testen von Business

Intelligence und Data Warehouse Systemen aussehen kann. Die Auswahl an Test-

werkzeugen hält sich im Vergleich zur klassischen Softwareentwicklung sehr stark in

Grenzen. Für das Überprüfen von Daten in relationalen Tabellen wurde ein Test-

werkzeug vorgestellt.

Mit den Ergebnissen dieser Arbeit können Unternehmen ihre Testaktivitäten bezüg-

lich Data Warehouse und Business Intelligence Systemen besser strukturieren. Die

oftmals informellen, impliziten Tests lassen sich mit den vorgestellten Prüftechniken

formalisieren und konkretisieren, sodass bessere Testergebnisse zu erwarten sind.

Anhang A: Business Intelligence System in der Praxis

Anhang A: Business Intelligence System in der Praxis Die folgende Abbildung zeigt, wie ein Business Intelligence System in der Realität

aussehen kann. Für die fünf Komponenten kommen auch fünf verschiedene Produk-

te zum Einsatz. Nähere Beschreibungen zu den einzelnen Produkten können auf den

Produkt-Websites nachgelesen werden: Talend, IBM DB2, Oracle Essbase, Oracle

Hyperion, UC4 (jeweils Abgerufen 12.02.2012).

Abbildung A-1: Business Intelligence System in der Praxis [Eigene Darstellung]

Anhang B: ADAPT-Notation

Anhang B: ADAPT-Notation ADAPT ist eine multidimensionale Modellierungssprache. In der folgenden Abbildung

sind die wichtigsten Notationselemente kurz beschrieben. Eine ausführliche Be-

schreibung der Sprache kann in [Sym06] nachgelesen werden.

Der OLAP-Würfel. Die Kennzahlen wer-

den als eigene Dimension dargestellt

(Kennzahlendimension).

Eine Dimension (Kante) des Würfels.

Eine Hierarchie einer Dimension.

Eine Aggregationsstufe innerhalb einer Dimension.

Ein eindeutiges Element einer Dimension.

Zusätzliches (beschreibendes Attribut)

einer Dimension.

Formel zum Berechnen abgeleiteter

Kennzahlen.

Lose Zuordnung.

Strikte Zuordnung.

Abbildung B-1: ADAPT-Notation [vgl. Sym06]

Abkürzungsverzeichnis

Abkürzungsverzeichnis ADAPT Application Design for Analytical Processing Technologies

AktG Aktiengesetz

BI Business Intelligence

BICC Business Intelligence Competence Center

BIS Business Intelligence System

DI Datenintegration

DSS Decision Support System

DW Data Warehouse

DWS Data Warehouse System

ER Entity-Relationship

ETL Extraktion, Transformation, Laden

HOLAP Hybrides Online-Analytical-Processing

KonTraG Gesetz zur Kontrolle und Transparenz im Unternehmensbereich

MDBMS Multidimensionales Datenbankmanagementsystem

MOLAP Multidimensionales Online-Analytical-Processing

OLAP Online-Analytical-Processing

OLTP Online-Transaction-Processing

RDBMS Relationales Datenbankmanagementsystem

RI Referentielle Integrität

ROLAP Relationales Online-Analytical-Processing

SCD Slowly Changing Dimension

UML Unified Modeling Language

VSNR Versicherungsscheinnummer

Abbildungsverzeichnis

Abbildungsverzeichnis Abbildung 2-1: Zusammenhang von BIS und DWS..................................................... 7

Abbildung 2-2: Heterogenität von Quellsystemen ..................................................... 10

Abbildung 2-3: Spreadsheet Reporting (Excel) ......................................................... 12

Abbildung 2-4: OLAP-Würfel ..................................................................................... 13

Abbildung 2-5: Zeit-Hierarchie ................................................................................... 14

Abbildung 2-6: OLAP-Würfel Perspektiven ............................................................... 15

Abbildung 2-7: Operatives Schema und Sternschema .............................................. 16

Abbildung 2-8: Exaktheit von Daten .......................................................................... 17

Abbildung 2-9: Business Intelligence System Big Picture ......................................... 22

Abbildung 2-10: Klassifikation der Softwareprüftechniken ......................................... 24

Abbildung 2-11: V-Modell .......................................................................................... 25

Abbildung 2-12: Wasserfallmodell vs. Prototyp ......................................................... 26

Abbildung 2-13: Ursache-Wirkungs-Graph Notation ................................................. 29

Abbildung 2-14: Kontrollflussgraph ............................................................................ 31

Abbildung 2-15: Datenflussgraph .............................................................................. 32

Abbildung 2-16: Zustandsautomat Datenflussanomalien .......................................... 36

Abbildung 3-1: Softwareentwicklungsprozess ........................................................... 42

Abbildung 3-2: ADAPT-Modell................................................................................... 46

Abbildung 3-3: Standarddimension Zeit .................................................................... 47

Abbildung 3-4: Gleichheitsfaktorquadrant ................................................................. 50

Abbildung 3-5: Ungenauigkeit bei Gleitkommazahlen ............................................... 52

Abbildung 3-6: Einlesen eines COBOL Copybooks (Talend) .................................... 56

Abbildung 3-7: Datenqualitätsregeln (Talend) ........................................................... 57

Abbildung 3-8: Ursache-Wirkungs-Graph - Qualitätsregeln ...................................... 58

Abbildung 3-9: Ursache-Wirkungs-Graph - Typ 1 SCD ............................................. 60

Abbildung 3-10: Datenflussgraph (Talend) ................................................................ 61

Abbildung 3-11: Datenflussanomalieanalyse (Talend) .............................................. 63

Abbildung 3-12: Data Lineage Analyse (Talend) ....................................................... 65

Abbildung 3-13: Tabelle Dim_Absatzgebiet .............................................................. 76

Abbildung 3-14: Korrekte Dimensionsladeregel (Jedox) ........................................... 76

Abbildung 3-15: Falsche Dimensionsladeregel (Jedox) ............................................ 77

Abbildung 3-16: Geladene Dimensionen (Jedox) ...................................................... 77

Abbildungsverzeichnis

Abbildung 3-17: Faktenladeregel (Jedox) .................................................................. 78

Abbildung 3-18: ADAPT-Modell erweitert um Konsolidierungen ............................... 81

Abbildung 3-19: Job-Programmablaufplan ................................................................ 90

Abbildung 5-1: Fehlgeschlagener Datenbank-Testfall (DbUnit)............................... 109

Abbildung 5-2: OLAP-Testfall (Excel) ...................................................................... 111

Abbildung 5-3: Test Unit Job (Talend) ..................................................................... 112

Abbildung A-1: Business Intelligence System in der Praxis .................................... 116

Abbildung B-1: ADAPT-Notation ............................................................................. 117

Tabellenverzeichnis

Tabellenverzeichnis

Tabelle 2-1: Operative vs. dispositive Daten ............................................................... 9

Tabelle 2-2: Originaldaten aus Quellsystem .............................................................. 19

Tabelle 2-3: Gesäuberte Daten ................................................................................. 19

Tabelle 2-4: Harmonisierte Daten .............................................................................. 20

Tabelle 2-5: Daten im Sternschema .......................................................................... 20

Tabelle 2-6: Fehlerkosten .......................................................................................... 25

Tabelle 2-7: Grenzwerte ............................................................................................ 28

Tabelle 2-8: Äquivalenzklassen ................................................................................. 28

Tabelle 2-9: Entscheidungstabelle ............................................................................ 30

Tabelle 2-10: Variablenzugriffe (Datenflussgraph) .................................................... 32

Tabelle 2-11: Variablenzugriffe (Datenflussanomalieanalyse)................................... 36

Tabelle 3-1: Fakten und Dimensionen ....................................................................... 45

Tabelle 3-2: Bus-Matrix ............................................................................................. 49

Tabelle 3-3: Mapping-Tabelle .................................................................................... 54

Tabelle 3-4: Typ 2 SCD ............................................................................................. 54

Tabelle 3-5: Äquivalenzklassen für COBOL Copybook ............................................. 55

Tabelle 3-6: Entscheidungstabelle - Qualitätsregeln ................................................. 59

Tabelle 3-7: Entscheidungstabelle - Typ 1 SCD ........................................................ 60

Tabelle 3-8: Eltern-Kind-Beziehung ........................................................................... 72

Tabelle 3-9: Vollständige Generation ........................................................................ 72

Tabelle 3-10: Laden von Kennzahlen ........................................................................ 73

Tabelle 3-11: Falsche und korrekte Konsolidierung .................................................. 74

Tabelle 3-12: Äquivalenzklassen zum Testen der Dimensionalität............................ 75

Tabelle 3-13: Korrekte Darstellung von Kennzahlen ................................................. 85

Tabelle 3-14: Sicherheitsrollen .................................................................................. 86

Tabelle 3-15: Entscheidungstabelle Sicherheitsrollen ............................................... 87

Tabelle 3-16: Prozess-Reihenfolge ........................................................................... 88

Tabelle 3-17: Prüftechniken Big Picture .................................................................... 91

Tabelle 4-1: Zeitscheiben mit Prozess-ID ................................................................ 100

Listingverzeichnis

Listingverzeichnis

Listing 2-1: SQL für Spreadsheet Reporting .............................................................. 12

Listing 2-2: Syntaktische Programmierkonventionen ................................................. 34

Listing 3-1: COBOL Copybook .................................................................................. 51

Listing 3-2: Ungenauigkeit bei Gleitkommazahlen..................................................... 52

Listing 3-3: Struktur einer Kunden-Tabelle ................................................................ 68

Listing 3-4: SQL-Statements zum Testen der Kunden-Tabelle ................................. 68

Listing 3-5: SQL-Programmierkonventionen.............................................................. 70

Listing 3-6: Berechnungsregel (Essbase) .................................................................. 79

Listing 3-7: Sicherheitsfilter (Essbase) ...................................................................... 84

Listing 4-1: Korrigieren einer falschen Lieferung ..................................................... 101

Listing 5-1: Erwartete Datenätze als XML-Datei (DbUnit) ....................................... 108

Listing 5-2: Datenbank-Testfall (DbUnit) ................................................................. 109

Listing 5-3: Datenbank-Testfall für Strukturen (DbUnit) ........................................... 110

Formelverzeichnis

Formelverzeichnis Formel 3-1: Konformitätsfaktor .................................................................................. 48

Formel 3-2: Gleichheitsfaktor .................................................................................... 49

Formel 3-3: Maximale Größe eines Essbase BSO-Würfels ...................................... 81

Literaturverzeichnis


[AktG] BUNDESGESETZBLATT DEUTSCHLAND: Aktiengesetz 36. Auflage, Deutscher Taschenbuch Verlag, München, 2003

[Amb06] S. W. AMBLER, P. J. SADALAGE: Refactoring Databases: Evolutionary Database Design 1. Auflage, Addison-Wesley Longman, Amsterdam, 2006

[BSI] BUNDESAMT FÜR SICHERHEIT IN DER INFORMATIONSTECHNIK: M 7.9 Datenschutzrechtliche Freigabe https://www.bsi.bund.de/ContentBSI/grundschutz/baustein-datenschutz/html/m07009.html (Abgerufen 12.02.2012)

[Bha07] S. R. BHAT: Data Warehouse Testing – Practical Approach Whitepaper, 2007 http://www.stickyminds.com/s.asp?F=S13041_ART_2 (Abgerufen 12.02.2012)

[Bra07] K. BRAHMKSHATRIYA: Data Warehouse Testing Whitepaper, 2007 http://www.stickyminds.com/s.asp?F=S12340_ART_2 (Abgerufen 12.02.2012)

[Cle10] J. CLEVE: Wissensmanagement: Wissensextraktion Studienbrief, WINGS - Wismar International Graduation Services GmbH, Wismar, 2010

[Coo02] R. COOPER, S. ARBUCKLE: Ho to Thoroghly Test a Data Warehouse Whitepaper, 2002 http://www.stickyminds.com/s.asp?F=S5941_ART_2 (Abgerufen 12.02.2012)

[Gol09] M. GOLFARELLI, S. RIZZI: Data warehouse testing: A prototype-based methodology In: Proceedings 12th International Workshop on Data Warehousing and OLAP (DOLAP 2009), S. 17-24, Hong Kong, 2009

[Gol11] M. GOLFARELLI, S. RIZZI: Data warehouse testing: A prototype-based methodology In: Information and Software Technology, Volume 53, Number 11, S. 1183-1198, 2011


[Han05] H. R. HANSEN, G. NEUMANN: Wirtschaftsinformatik 1 - Grundlagen und Anwendung 9. Auflage, Lucius & Lucius, Stuttgart, 2005

[Her01] O. HERDEN: Eine Entwurfsmethodik für Data Warehouses Dissertation, Carl von Ossietzky Universität Oldenburg, 2001 http://oops.uni-oldenburg.de/volltexte/2002/307/ (Abgerufen 15.01.2012)

[Hin02] H. HINRICHS: Datenqualitätsmanagement in Data Warehouse-Systemen Dissertation, Carl von Ossietzky Universität Oldenburg, 2002 http://oops.uni-oldenburg.de/volltexte/2002/309/ (Abgerufen 15.01.2012)

[Hof08] D. W. HOFFMANN: Software-Qualität 1. Auflage, Springer-Verlag, Berlin/Heidelberg, 2008

[Inf10] INFOSYS LIMITED: Data Warehouse Testing Whitepaper, 2010 http://www.infosys.com/offerings/IT-services/independent-validation-testing-services/white-papers/Documents/data-warehouse-testing.pdf (Abgerufen 12.02.2012)

[Inm05] W. H. INMON: Building the Data Warehouse 4. Auflage, Wiley Publishing, Indianapolis, 2005

[Kam10] R. KAMAL, NAKUL: Adventures with Testing BI/DW Application: On a crusade to find the Holy Grail Whitepaper, 2010 http://www.stickyminds.com/s.asp?F=S15975_ART_2 (Abgerufen 12.02.2012)

[Kem10] H.-G. KEMPER, H. BAARS, W. MEHANNA: Business Intelligence - Grundlagen und praktische Anwendung 3. Auflage, Vieweg + Teubner Verlag, Wiesbaden, 2010

[Kim02] R. KIMBALL, M. ROSS: The Data Warehouse Toolkit 2. Auflage, John Wiley & Sons, 2002

[Kim04] R. KIMBALL, J. CASERTA: The Data Warehouse ETL Toolkit 1. Auflage, Wiley Publishing, Indianapolis, 2004


[Koe07] H. KÖNIG: Grundlagen der Objektorientierung Lehrskript, Fachhochschule für die Wirtschaft (FHDW), Hannover, 2007

[Koe09] H. KÖNIG: Formale Grundlagen entscheidungsunterstützender Systeme Lehrskript, Fachhochschule für die Wirtschaft (FHDW), Hannover, 2009

[Lig09] P. LIGGESMEYER: Softwarequalität 2. Auflage, Spektrum Akademischer Verlag, Heidelberg, 2009

[Moo08] A. MOOKERJEA, P. MALISETTY: Data Warehouse / ETL Testing: Best Practices Whitepaper, 2008 http://test2008.in/Test2008/pdf/Anandiya et al - Best Practices in data warehouse testing.pdf (Abgerufen 12.02.2012)

[Ols03] J. E. OLSEN: Data Quality: The Accuracy Dimension 1. Auflage, Morgan Kaufmann Publishers, 2003

[Ora10] ORACLE: Oracle Essbase 11.1.2 Bootcamp Schulungsunterlagen, 2010

[Rai08] V. RAINARDI: Building a Data Warehouse: With Examples in SQL Server 1. Auflage, Apress, 2008

[Sch07] F. C. SCHRÖDER: Vergleichende Analyse von ETL-Konzepten für latenzzeitsensible Data Warehouse Architekturen Diplomarbeit, Otto-von-Guericke-Universität Magdeburg, 2007 http://wwwiti.cs.uni-magdeburg.de/iti_db/publikationen/ps/ auto/thesisSchroeder.pdf (Abgerufen 16.02.2012)

[Sco09] M. SCOTT: The Shortcut Guide to IT Workload Automation and Job Scheduling 1. Auflage, Realtime Publishers, 2009

[Sha07] R. K. SHARMA: Test Automation: Im Data Warehouse Projects Whitepaper, 2007 http://www.stickyminds.com/s.asp?F=S13590_ART_2 (Abgerufen 12.02.2012)


[Sne09] H. M. SNEED, M. BAUMGARTNER, R. SEIDEL: Der Systemtest 2. Auflage, Carl Hanser Verlag, München, 2009

[Spi03] A. SPILLNER, T. LINZ: Basiswissen Softwaretest 3. Auflage, dpunkt Verlag, Heidelberg, 2005

[Sun07] A. SUNDARARAMAN: Testing for DW/BI - Current State and a Peek into Future Whitepaper, 2007 http://www.information-management.com/infodirect/20070622/-1083670-1.html?zkPrintable=true (Abgerufen 12.02.2012)

[Sym06] SYMMETRY CORPORATION: Getting Started with ADAPT™ Whitepaper, 2006 http://www.symcorp.com/downloads/ADAPT_white_paper.pdf (Abgerufen 15.01.2012)

[The07] J. THEOBALD: Strategies for Testing Data Warehouse Applications Whitepaper, 2007 http://www.information-management.com/issues/20070601/1086005-1.html?zkPrintable=true (Abgerufen 12.02.2012)

[Tot00] A. TOTOK: Modellierung von OLAP- und Data-Warehouse-Systemen 1. Auflage, Deutscher Universitäts-Verlag, Wiesbaden, 2000

Ehrenwörtliche Erklärung

Ehrenwörtliche Erklärung Ich erkläre hiermit ehrenwörtlich, dass ich die vorliegende Arbeit selbstständig ange-

fertigt habe. Die aus fremden Quellen direkt oder indirekt übernommenen Gedanken

sind als solche kenntlich gemacht. Es wurden keine anderen als die angegebenen

Quellen und Hinweise verwandt.

Die vorliegende Arbeit wurde bisher keiner anderen Prüfungsbehörde vorgelegt und

auch noch nicht veröffentlicht.

Hannover, 20. Februar 2012 _________________________

(Renke Hegeler)