Transformation operativer Daten zur Nutzung im Data Warehouse

Muller Transformation operativer Daten zur Nutzung im Data Warehouse

GABLER EDITION WISSENSCHAFT

Jochen Muller

Transformation operativer Daten zur Nutzung im Data Warehouse

Mit einem Geleitwort von Prof. Dr. Roland Gabriel

Springer Fachmedien Wiesbaden GmbH

Die Deutsche Bibliothek - CIP-Einheitsaufnahme

Miiller, Jochen: Transformation operativer Daten zur Nutzung im Data Warehouse / Jochen Muller. Mit einem Geleilw. von Roland Gabriel. - Wiesbaden : Dt. Univ.-Verl. ; Wiesbaden : Gabler, 2000 (Gabler Edition Wissenschaft) lugl.: Bochum, Univ., Diss., 1999

ISBN 978-3-8244-7073-0 ISBN 978-3-663-09052-6 (eBook) DOI 10.1007/978-3-663-09052-6

Aile Rechte vorbehalten

© Springer Fachmedien Wiesbaden 2000

Urspriinglich erschienen bei Betriebswirtschaftlicher Verlag Dr. Th. Gabler GmbH 2000.

Lektorat: Brigitte Siegel/ Stefanie Brich

Dos Werk einschliel3lich oller seiner Teile ist urheberrechtlich geschUtzt. Jede Verwertung aul3erhalb der eng en Grenzen des Urheberrechtsgesetzes ist ohne lustimmung des Veri ages unzulassig und strafbar. Dos gilt insbesondere fur Vervielfaltigungen, Ubersetzungen, Mikroverfilmungen und die Einspeicherung und Verarbeitung in elektronischen Systemen.

http://www.gabler.de http://www.duv.de

Hochste inhaltliche und technische Qualitat unserer Produkte ist unser liel. Bei der Produktion und Verbreitung unserer Werke wollen wir die Umwelt schonen. Dieses Buch ist deshalb auf saurefreiem und chlorfrei gebleichtem Papier gedruckt. Die Einschweil3folie besteht aus Polyethylen und damit aus organischen Grundstoffen, die weder bei der Herstellung noch bei der Verbrennung Schadstoffe freisetzen.

Die Wiedergabe von Gebrauchsnamen, Handelsnamen, Warenbezeichnungen usw. in diesem Werk berechtigt ouch ohne besondere Kennzeichnung nicht zu der Annahme, doss solche Nomen im Sinne der Warenzeichen- und Markenschutz-Gesetzgebung als frei zu betrachten waren und daher von jedermann benutzt werden durften.

Geleitwort

Die Informationsversorgung zur Entscheidungsuntersttitzung erweist sich in vielen

Unternehmen heute noch als unbefriedigend. Wiihrend eine Untersttitzung der operati

yen betrieblichen Prozesse durch leistungsfahige Administrations- und Dispositions

systeme nahezu fliichendeckend gegeben ist, offenbaren sich insbesondere fUr analyse

orientierte Aufgabenstellungen Defizite. Spezifische Datenbanksysteme, die eine be

sondere Problemadiiquanz fUr diesen Aufgabenbereich versprechen, gewinnen daher in

letzter Zeit zunehmend an Bedeutung. Hier sind es insbesondere Data Warehouse

Konzepte, mit denen man sich in der Forschung wie in der Praxis auseinandersetzt. Mit

der EinfUhrung entsprechender Losungen als moderner Interpretation der lange be

kannten Management Support Systeme wird die Erwartung hoher Nutzenpotentiale auf

der operativen und insbesondere auf der strategischen Managementebene verkntipft.

Der Verfasser dieser Arbeit untersucht einen wichtigen Aspekt der Data Warehouse

Forschung, der entscheidende Auswirkungen auf den erfolgreichen Einsatz dieser

Systeme hat. Er widmet sich der Transformation operativer Daten zur Nutzung im Data

Warehouse. Dabei analysiert er die Funktionalitiiten und die Anforderungen an eine

Systernkomponente, die der Extraktion, Umwandlung und Integration von Daten ftiT

ein analyseorientiertes Informationssystem dient. Hier wird Neuland betreten, denn

bisher liegen lediglich Realisierungen fUr Einzelfall-Losungen vor, die nicht auf wis

senschaftlich abgesicherten Konzepten basieren.

Der Autor legt ein Werk vor, daB sich mit einem anspruchsvollen und sehr aktuellen

Thema befaBt. Ausgehend von der Bedeutung des Einsatzes von Data Warehouse

Systemen in Unternehmungen zeigt er auf, daB die Bereitstellung syntaktisch und

semantisch richtiger, vollstiindiger und aktueller Daten einen kritischen Erfolgsfaktor

solcher Projekte bildet. Die Problembereiche der Redundanz, der Inkonsistenz und der

mangelhaften Datenqualitiit werden analysiert und dienen der Ableitung von Ansiitzen

zur ProblemlOsung. Der Aufbau eines Vorgehensrahmens zur Schaffung von System

komponenten, die einer zeitnahen Versorgung eines Data Warehouse mit operativen

Daten hoher Qualitiit dienen, bildet ein schltissiges Ergebnis, das ftiT die Realisierung

in der Praxis wertvolle Erkenntnisse liefert und interessante Ansatzpunkte ftiT weitere

Forschung bietet.

Prof. Dr. Roland Gabriel

Vorwort

Das Modewort "Data Warehouse" ist seit einiger Zeit Gegenstand zahlreicher Diskus

sionsbeitrage aus Theorie und Praxis der Wirtschaftsinformatik. Auch wenn es vielfach

einer breiten und oft plakativen Argumentation dient, kann nicht verkannt werden, daB

das dem Data Warehouse zugrundeliegende Konzept einen wichtigen Ansatz zur Ver

besserung der Verftigbarkeit von Information in Entscheidungssituationen bildet. Ne

ben leistungsfahigen Komponenten zur Datenspeicherung und zielgruppengerechten

Informationsreprasentation sind die Schnittstellen zu den herkommlichen Informati

onssystemen, deren DatenbesUinde Spiegelbild des Unternehmensgeschehens und da

mit Informationslieferant sind, in einer Data Warehouse-Architektur von zentraler Be

deutung. Diesen Systemelementen, die bisher eher Gegenstand pragmatischer Ansatze

als wissenschaftlicher Forschung waren, widmet sich die vorliegende Dissertation.

Bei der Erstellung dieser Arbeit ist mir vieWiltige Unterstiitzung zuteil geworden.

HierfUr sei allen Beteiligten herzlich gedankt. Mein besonderer Dank gilt Herrn Pro

fessor Dr. Roland Gabriel fUr die engagierte Betreuung und Forderung dieser Arbeit.

Er hat einerseits hilfreiche Leitlinien aufgezeigt, andererseits aber auch wertvolle aka

demische Freiraume gewahrt. Frau Professor Dr. Birgitte Werners danke ich fUr ihr

Interesse an der Thematik und fUr die Ubernahme des Korreferates.

Die Teilnehmer unseres informellen Arbeitskreises "Data Warehouse" haben durch

ihre Diskussionsbereitschaft und viele wertvolle Anregungen sehr zu der vorliegenden

Arbeit beigetragen. Besonders hervorzuheben sind Dr. Peter Gluchowski, der tiber

viele Jahre hinweg durch seine Ideen und DenkanstoBe meine fachliche Ausrichtung

beeinfluBt hat, sowie Joachim Schelp, mit dem mich ein gegenseitiger Motivationspro

zeB verbindet und des sen Anmerkungen zum Manuskript eine wichtige Hilfe waren.

Ich entziehe mich der schwierigen Aufgabe, auch im folgenden eine zumindest imma

nent wertende Reihenfolge zu bilden und bedanke mich neben den genannten Personen

bei Dr. Andre Becker, Carsten Dittmar, Michael Hahne, Stefan Krebs, Carsten Schone,

Dr. Ulrike Ufer, Sascha und Marco Wallenfels, Claus Winterberg und den Kolleginnen

und Kollegen sowie den studentischen Hilfskraften am Lehrstuhl fUr Wirtschaftsin

formatik fUr ihre vielfaltige und engagierte Hilfe in inhaltlicher, redaktioneller und

personlicher Hinsicht.

lochen Mtiller

Inhaltsverzeichnis

Inhaltsverzeichnis

Abbildungsverzeichnis

Abkiirzungsverzeichnis

1 Einleitung

1.1 Problemstellung und Zielsetzung

1.2 Vorgehensweise

1.3 Begriffsbestimmungen

1.3.1 Wissen, Information und Daten

1.3.2 Informationssystem

1.3.3 Kategorien betrieblicher Informationssysteme

1.3.4 Qualitat von Daten

2 Operative Informationssysteme

2.1 Bedeutung und Ziele

2.1.1 Historie

2.1.2 Nutzenaspekte transaktionsorientierter Informationssysteme im

Unternehmen

2.1.3 Vorgehensmodelle zor Entwicklung von datenbankbasierten

Informationssystemen

2.2 Datenmodelle und Reprasentationsformen

2.2.1 Datenmodell

2.2.2 Semantische Datenmodelle

2.2.3 Logische Datenmodelle

2.2.3.1 Relationale Modelle

2.2.3.2 Alternative Reprasentationsformen

2.3 Architektoren und Komponenten

2.3.1 Anforderungen an Datenbanksysteme

2.3.2 Klassifikationsmerkmale fUr Datenbanksystemarchitekturen

2.3.3 Architektorarten

2.3.3.1 Zentrale Datenbanksysteme

2.3.3.2 Verteilte Datenbanksysteme

2.3.3.3 Multidatenbanksysteme

IX

XIII

XV

1

2

3

4

5

8

10

14

19

20

20

24

26

32

32

35

37

37

42

44

47 50

53

53

59

67

x Inhaltsverzeichnis

2.4 Metadatenverwaltung transaktionsorientierter Informationssysteme

2.4.1 Arten von Metadaten flir transaktionsorientierte

Informationssysteme

2.4.2 Verwaltungssysteme flir Metadaten

2.4.3 Stellenwert von Metadaten im Rahmen der operativen

70

71

72

Informationsverarbeitung 75

2.5 Datenaustausch auf operativer Ebene 78

3 Analyseorientierte Informationssysteme 81

3.1 Bedeutung und Ziele 82

3.1.1 Stellenwert analyseorientierter Informationssysteme im

Unternehmen 83

3.1.2 Charakteristika des Data W arehouse-KOllzepts 86

3.2 Datenmodelle und Reprasentationsformen 91

3.2.1 Mehrdimensionale Informationsstrukturen 92

3.2.2 Reprasentationsformen auf relationaler Basis 95

3.2.3 Reprasentationsformen auf multidimensionaler Basis 99

3.3 Architekturen und Komponenten 102

3.3.1 Data Warehouse 104

3.3.2 Data Mart 114

3.3.3 Endbenutzerwerkzeuge 117

3.4 Metadatenverwaltung analyseorientierter Informationssysteme 120

3.4.1 Arten von Metadaten flir analyseorientierte Informationssysteme 121

3.4.1.1 Strukturorientierte Metadaten 122

3.4.1.2 Funktionsorientierte Metadaten 128

3.4.1.3 Versionierung der Metadaten 130

3.4.2 Stellenwert von Metadaten im Umfeld analyseorientierter

Informationssysteme

3.4.3 Verwaltungssysteme flir Metadaten

3.5 Schnittstellen zu den Vorsystemen

4 Funktionale und inhaltIiche Aspekte der Transformation operativer

133

136

138

Daten fUr analyseorientierte Informationssysteme 143

4.1 Einordnung des Problembereichs 146

4.2 Anwendungsflille einer Datentransformation flir das Data Warehouse 149

4.2.1 Erzeugung der Data Warehouse-Datenbestande 150

Inhaltsverzeichnis XI

4.2.2 Aktualisierung der Data Warehouse-Datenbestande 151

4.3 Gewinnung und Transformation von Daten flir das Data Warehouse 152

4.3.1 Aktivitaten auf Seiten des operativen Systems 154

4.3.1.1 Zeitstempel-gesteuerte Verfahren 156

4.3.1.2 Datentibergabe durch Anwendungsprogramme 158

4.3.1.3 Protokollierung relevanter Datenbank-Transaktionen 160

4.3.1.4 Auswertung der Logdateien 164

4.3.1.5 SchnappschuB-Vergleichsverfahren 165

4.3.1.6 Untersttitzung durch Werkzeuge 166

4.3.2 Transformation im engeren Sinne 167

4.3.2.1 Basisfunktionen zur Durchflihrung der

Transformationsschritte 169

4.3.2.2 Beseitigung syntaktischer Heterogenitat 172

4.3.2.3 Datenaufbereitung 175

4.3.2.3.1 Datenreinigung 176

4.3.2.3.2 Entfernung irrelevanter Datenobjekte 178

4.3.2.3.3 Behandlung fehlender Werte 178

4.3.2.4 Modellkonvertierung 182

4.3.2.5 Homogenisierung des Datenbestands 186

4.3.2.6 Gesamtsicht 190

4.3.3 Aktivitaten auf Seiten der Zielumgebung 191

4.3.3.1 Datentibernahme 192

4.3.3.2 Erzeugen abgeleiteter Werte 196

4.4 Datentransformation zwischen Komponenten des analyseorientierten

Informationssystems

4.5 SchluBfolgerungen

198

204

5 Anforderungen an die Transformationskomponente im Rahmen der

Entwicklung und Nutzung eines analyseorientierten Informationssystems 207

5.1 Besonderheiten bei der Entwicklung von Komponenten flir

analyseorientierte Informationssysteme

5.2 Vorgehen bei der Data Warehouse-Entwicklung

5.2.1 Planung und Entwurf

5.2.1.1 Umfeldanalyse

5.2.1.2 Architekturplanung

208

211

212

213

215

XII Inhaltsverzeichnis

5.2.l.3 Begleitende akzeptanzsichernde MaBnahmen 216

5.2.2 Entwicklung und Betrieb 217

5.2.2.1 Auswahl und Entwicklung eines Prototypen 218

5.2.2.2 Systemausbau 219

5.2.2.3 Betrieb 222

5.2.3 Zusammenfassende Betrachtung 223

5.3 Lebenszyklusmodell fiir analyseorientierte Informationssysteme 224

5.3.1 Nutzungscharakteristik im Entwicklungsverlauf 225

5.3.2 Typische Phasen im Lebenszyklus 227

5.4 Phasenspezifische Anforderungen 230

5.4.1 Pilotphase 230

5.4.2 Erfahrungsphase 232

5.4.3 Ausbauphase 237

5.4.4 Betriebsphase 240

5.5 Phaseniibergreifende Aspekte 242

6 Zusammenfassende Bewertung und Ausblick 245

Literaturverzeichnis 249

Abbildungsverzeichnis XIII

Abbildungsverzeichnis

Abbildung I: Die Abgrenzung der Begriffe Wissen, Daten und Information 7

Abbildung 2: Einteilung der Anwendungssysteme nach der

Managementpyramide

Abbildung 3: Betriebliche Informationssystempyramide

Abbildung 4: Wasserfallmodell

Abbildung 5: Spiralmodell

Abbildung 6: Klassifikation von Datenbanksystemen

Abbildung 7: Architekturvarianten von Datenbanksystemen

Abbildung 8: Drei-Schema-Konzept fUr Datenbanken

Abbildung 9: Vier-Schema-Architektur verteilter Datenbanksysteme

11

13

28

31

46

51

55

63

Abbildung 10: Allgemeine Architektur fOderierter Datenbanksysteme 69

Abbildung II: Hauptfunktionen eines EIS 85

Abbildung 12: Komponenten von Management Support Systemen 86

Abbildung 13: Star Schema 96

Abbildung 14: Architekturkomponenten eines analyseorientierten

Informationssystems 104

Abbildung 15: Charakteristika operativer und analyseorientierter Datenbanken 105

Abbildung 16: Auslastungsformen operativer und analyseorientierter Systeme 108

Abbildung 17: Metadaten in Data Warehouse-Systemen nach Systemebenen und

Subsystemen 123

Abbildung 18: Semantische Beschreibung von Datenobjekten 125

Abbildung 19: Funktionsorientierte Metadaten in Data Warehouse-Systemen 128

Abbildung 20: Strukturraum fUr Metadaten in Data Warehouse-Umgebungen 131

Abbildung 21 : Versionsorientiertes Metadatenverstandnis in Data Warehouse-

Systemen 133

Abbildung 22: Problemdefinitionsraum der Datenintegration 147

XIV Abbildungsverzeichnis

Abbildung 23: Drei-Schichten-Modell der Transformationskomponente 153

Abbildung 24: Extraktion von Detail-Datensatzen tiber Zeitstempel am Master-

Datensatz 157

Abbildung 25: Datentibergabe durch das Anwendungsprogramm 159

Abbildung 26: Protokollierung von Transaktionen mit Hilfe von

Datenbanktriggern 163

Abbildung 27: Beispiele syntaktischer Umwandlung von Datenbestanden 173

Abbildung 28: Schritte zur Datenaufbereitung 176

Abbildung 29: Modellkonvertierung 183

Abbildung 30: Modellkonsolidierung von Datenbestanden unterschiedlicher

Quellen 185

Abbildung 31: Inhaltliche Homogenisierung von Datenbestanden 188

Abbildung 32: Gesamtsicht des Umwandlungsprozesses 191

Abbildung 33: Alternative Konzepte zur Data Mart-Population 202

Abbildung 34: Vorgehen im Rahmen von Data Warehouse-Projekten 224

Abbildung 35: Data Warehouse-Lebenszyklus 228



ACID

ACM

ADAPT

AIS

ANSI

APB

API

ASCII

BOW

BIW

CAD

CASE

CD

CDIF

CIS

COBOL

CODASYL

COLAP

DB

DBMS

DBS

DIN

Diss.

DSS

DV

OW

EIR

EBCDIC

ed.

EDBT

EDI

EDIFACT

Atomicity, Consistency, Isolation, Durability

Association for Computing Machinery

Application Design for Analytical Processing Technologies

Association for Information Systems

American National Standards Institute

Analytical Processing Benchmark

Application Programming Interface

American Standard Code for Information Interchange

Business Data Warehouse

Business Information Warehouse

Computer Aided Design

Computer Aided Software Engineering

Compact Disk

CASE Data Interchange Format

Chefinformationssystem

Common Business Oriented Language

Conference On Data System Languages

Client-OLAP

Datenbank, Database

Datenbankmanagementsystem, Database Management System

Datenbanksystem

Deutsche Industrie-Norm

Dissertation

Decision Support System

Datenverarbeitung

Data Warehouse

Entity-Relationship

Extended Binary Coded Decimal Interchange Code

Edition

Extending Database Technology

Electronic Data Interchange

Electronic Data Interchange for Administration, Commerce and

Transport

xv

XVI

EDV

EIA

EIS

ER

ESS

et al.

ETL

EUS

F.u.E.

FIS

FORWISS

GB

HMD

HOLAP

HR

lAO

IEEE

IMS

Inc.

IS

ISO

IT

IV

JEUC

KDD

KW

MDBS

MIS

MOLAP

MSS

No.

o.J.

o.S.

o.V.

ODBC

Elektronische Datenverarbeitung

Electronic Industries Association

Executive Information System

Entity-Relationship

Executive Support System

et alii

Extraction, Transformation, Loading

Entscheidungsunterstiitzungssystem

Forschung und Entwicklung

Fiihrungsinformationssystem

Forschungszentrum fUr wissensbasierte Systeme

Gigabyte

Handbuch der modernen Datenverarbeitung

HybridOLAP

Human Ressources

Institut fUr Arbeitswirtschaft und Organisation

Institute of Electrical and Electronics Engineers

Interoperability in Multidatabase Systems

Incorporated

Informationssystem

International Standardization Organization

Informationstechnologie, Information Technology

Informationsverarbeitung

Japan Extended UNIX Code

Knowledge Discovery in Databases

Kalenderwoche

Multidatenbanksystem

Management Information System

Multidimensional OLAP

Management Support System

Number

ohne Jahresangabe

ohne Seitenangabe

ohne Verfasserangabe

Open Database Connectivity


AbkUrzungsverzeichnis

OLAP

OLE

OLTP

PhD.

PL/SQL

RA

ROLAP

ROM

SIGMOD

SQL

TorS

TPC-D

UML

VLDB

Vol.

WI

WWW

On-Line Analytical Processing

Object Linking and Embedding

On-Line Transactional Processing

Doctor of Philosophy

Programming Language/Structured Query Language

Risikoanalyse

Relational OLAP

Read-Only Memory

Special Interest Group on Modeling

Structured Query Language

Transactions on Office Information Systems

Transaction Processing Council - Decision Support

Unified Modeling Language

Very Large Data Base

Volume

Wirtschaftsinformatik

World Wide Web

XVII

Einleitung

1 Einleitung

Unternehmerisches Handeln ist Rahmenbedingungen unterworfen, die durch eine hohe

Komplexitat und rasche Veranderungen gekennzeichnet sind. Nur Marktteilnehmer,

denen es gelingt, sich an diese Bedingungen anzupassen, konnen langfristig im Wett

bewerb bestehen. Die strategischen und operativen Tatigkeiten im Umgang mit dem

permanenten Anpassungsbedarf sind in hohem MaBe informationsbezogen. Daher ist

eine ausgereifte Informationslogistik erforderlich, die sicherstellt, daB die benotigten

Informationen zeitgerecht in angemessener Qualitat vorliegen. GroBe Datenbestande,

wie sie durch die Verwendung der Informationstechnologie fiir die operativen betrieb

lichen Ablaufe entstehen, sind allein kein Garant fiir die bedarfsgerechte Verfugbarkeit

hochwertiger Information. Plakative Formulierungen, die von "DatenfriedhOfen" oder

von der "Informationsarmut im InformationsiiberfluB"1 sprechen, belegen dies vielfach

und verdeutlichen, daB die Daten verwendungsgerecht aufbereitet werden mussen,

bevor sie als Grundlage fiir Entscheidungen nutzbar werden.

Vor diesem Hintergrund wird seit geraumer Zeit versucht, durch spezifische Informa

tionssysteme fiir das Management Daten problemadaquat aufbereitet so vorzuhalten,

daB sie problem- und situationsgerecht als Basis fiir Entscheidungen abgerufen werden

konnen. Die Diskussion urn solche Systeme ist in jiingster Zeit aus zwei Richtungen

neu belebt worden.

Einerseits finden in Unternehmen vielfach tiefgreifende UmstrukturierungsmaBnahmen

statt, die in geanderten Aufbau- und Ablaufstrukturen munden und tendenziell dazu

fiihren, daB Entscheidungskompetenzen in der Unternehmenshierarchie nach unten

verlagert werden. Dies kann jedoch nur dann zum Erfolg fiihren, wenn den Mitarbei

tern auch die entscheidungsnotwendigen Informationen zuganglich gemacht werden.

Andererseits werden seit einigen Jahren unter Schlagworten wie "Data Warehouse" in

Wissenschaft und Praxis intensiv Konzepte diskutiert, die versprechen, mit einer sepa

raten Speicherung zu einer erfolgreichen technologischen Basis fiir das Vorhalten

entscheidungsrelevanter Daten als Kern einer leistungsfahigen Informationslogistik zu

fiihren.

Nieschlag/DichtllHorschgen (1994), S. 1005.

2 Einleitung

Die Data W arehouse-Thematik kann aus unterschiedlichen Blickwinkeln betrachtet

werden. Haufig erfolgt eine Diskussion, die sich mit der Eignung bestimmter Daten

banksystem- oder Hardwarearchitekturen fiir solche Anwendungen befaBt. Auch die

entsprechenden Datenmodelle, bei denen es sich urn neue Entwicklungen oder urn

umfassende Neuinterpretationen herkommlicher Ansatze handelt, werden thematisiert.

Weniger im Vordergrund stehen dagegen bisher Fragestellungen, die sich mit der Be

schaffung der Daten, die in guter Qualitat im Data Warehouse gespeichert werden

sollen, auseinandersetzen. Dies verwundert, da hierbei aufgrund der Heterogenitat der

im Unternehmen vorhandenen operativen Systeme die Problematik der Integration und

der Migration von Informationssystemen ein wei teres anspruchsvolles Anwendungs

gebiet erhalt.

1.1 Problemstellung und Zielsetzung

Die Bereitstellung syntaktisch und semantisch richtiger, vollstandiger und aktueller

Daten hoher Qualitat ist ein kritischer Erfolgsfaktor fUr das Gelingen eines Data Ware

house-Projekts. Nur so kann es seine Nutzenpotentiale als Lieferant entscheidungsre

levanter Daten entfalten und findet die notwendige Akzeptanz. Die Daten, die im Data

Warehouse vorgehalten werden sollen, miissen aus mehreren heterogenen unterneh

mensinternen und -externen Que11en mit iiberlappenden Themenfeldern entnommen

werden. Dies gibt AnlaB zu der Annahme, daB die Daten nicht nur redundant, sondern

in der Regel auch syntaktisch oder semantisch inkonsistent vorliegen. Daher miissen

sie zusammengefUhrt, bereinigt und einander angeglichen werden, bevor sie Eingang

in das Data Warehouse finden. Als besonders problematisch erweist sich dabei die

vielfach schlechte Datenqualitat, die sich etwa durch falsche oder widerspriichliche

Inhalte, fehlende Daten oder uneinheitliche Darstellungsformen manifestiert.

Eine standardisierte, universe11e Software zur Abdeckung a11er Transformationsaufga

ben ist derzeit auf dem Markt nicht verfUgbar. Ein solches Produkt erscheint auch nicht

unbedingt erfolgversprechend, da die im Rahmen der Datentransformation durchzufUh

renden Teilaufgaben in Abhangigkeit von der vorhandenen Systemlandschaft und der

Qualitat der operativen Daten stark differieren konnen. ZweckmaBiger ist daher eine

Vorgehensweise, die starker Bezug auf die konkret und projektspezifisch notwendigen

Teilschritte einer Datentransformation nimmt. Dafiir sol1 in dieser Arbeit ein abstraktes

Vorgehensweise 3

Modell entwickelt werden, das dann als Architektur- und Vorgehensrahmen dienen

kann.

Die Fragestellungen, die sich bei der Integration verschiedener Datenquellen ergeben,

werden im Rahmen der Betrachtung verteilter und fi:iderierter Datenbanksysteme be

reits seit einiger Zeit unter dem Begriff "Materialized View" diskutiert. 1m Data Ware

house-Umfeld findet diese Thematik einen praktischen Anwendungsfall, wobei jedoch

viele hier relevante Problemfelder bisher nur unzureichend diskutiert wurden. So sind

insbesondere unterschiedliche Auspragungen von Heterogenitat und mangelnde Qua

litat der Daten in die Betrachtung einzubeziehen.

Ziel der Arbeit ist daher eine umfassende Problemanalyse zu den Fragen der Trans

formation operativer Daten flir Data Warehouse-Systeme. Darauf aufbauend wird ein

Vorgehensrahmen zur Schaffung von anforderungsgerechten Architekturkomponenten,

die der zeitnahen Versorgung eines Data Warehouse mit integrierten operativen Daten

hoher Qualitat dienen kennen, erarbeitet.

1.2 Vorgehensweise

1m AnschluB an eine kurze Diskussion und Abgrenzung der flir diese Arbeit zentralen

Begriffe werden in den folgenden beiden Kapiteln die wesentlichen Aspekte operativer

(Kapitel 2) und analyseorientierter Informationssysteme (Kapitel 3) erertert und einan

der gegentibergestellt. Hier sollen vor allem die Unterschiede, die sich aus den jeweili

gen Einsatzbereichen hinsichtlich einer problemadaquaten Modellierung und Imple

mentierung ergeben, herausgearbeitet werden. Dies wird durch eine weitgehend sym

metrische Gliederung dieser Kapitel verdeutlicht. Ein Vorgehen dieser Art flihrt zu

einer breiten Darstellung auch der Thematik der herkemmlichen operativen Daten

bank- und Informationssysteme. Diese ausflihrliche Argumentation erscheint hier

zweckmaBig, da sie die vergleichende Betrachtung der einander gegentibergestellten

Systemklassen ermeglicht und gleichzeitig wtirdigt, daB Heterogenitatsapekte, die

einen wesentlichen Ausgangspunkt der angestellten Uberlegungen bilden, ihren Ur

sprung in den operativen Systemen haben.

Das vierte Kapitel dient der Entwicklung einer abstrakten, dreistufigen Architektur,

anhand der im Sinne einer Anforderungsanalyse die notwendigen Schritte zur Trans

formation der Daten beschrieben werden kennen. Ein Schwerpunkt liegt hier auf der

systematischen Herausarbeitung der zu erwartenden Probleme, die sich tiber verschie-

4 Einleitung

dene Auspragungen von Heterogenitat kategorisieren und darstellen lassen. Abschlie

Bend wird in diesem Kapitel kurz auf die Transformation von Daten zwischen den

verschiedenen Komponenten eines analyseorientierten Informationssystems als Son

derfall des Gesamtproblems eingegangen.

Ftir Softwarekomponenten lassen sich weitere Anforderungen definieren, die tiber die

Bewaltigung der zu erflillenden Aufgabe im engeren Sinne - der Durchflihrung der in

den vorhergehenden Abschnitten diskutierten Transformationsschritte - hinausgehen

und sich auf die Einbettung des Systems in das organisatorische und technische Um

feld beziehen. Eine Diskussion derartiger Anforderungen ist Gegenstand des flinften

Kapitels. Hier wird als Strukturierungsrahmen auf der Basis eines Vorgehenskonzepts

flir Entwicklung, Einflihrung und Betrieb eines analyseorientierten Informationssy

stems ein Lebenszyklus-Phasenmodell gewahlt. Den einzelnen Phasen, die tiber nut

zungsorientierte MeBgroBen beschrieben werden konnen, lassen sich sodann aufgrund

ihrer Charakteristika jeweils wichtige Sol1-Eigenschaften der Softwarewerkzeuge

zuordnen.

Das sechste Kapitel faBt schlieBlich die wesentlichen Aussagen zusammen und gibt

einen Ausblick auf mogliche weiterflihrende Entwicklungen zu dies em Aspekt der

derzeit in Wissenschaft und Praxis vieldiskutierten Data Warehouse-Thematik.

1.3 Begriffsbestimmungen

Die Begriffswelt im Umfeld des Gegenstandes dieser Arbeit ist in der Literatur nicht

immer konsistent. Aus diesem Grunde solI hier zunachst ein begriffliches Rahmenkon

zept entwickelt werden, auf dem dann in den folgenden Kapiteln aufgebaut werden

kann.

Die Beschaftigung mit computergesttitzen Informationssystemen unterschiedlicher Art

als zentralem Erkenntnisobjekt macht es erforderlich, zunachst den Begriff der Infor

mation zu erortern und ihn von den gleichfalls grundlegenden Begriffen Daten und

Wissen abzugrenzen. Auf der Grundlage dieser Darlegungen kann dann auf den Be

griff des Informationssystems genauer eingegangen und eine erste Kategorisierung

vorgenommen werden. Da die Qualitat der gespeicherten Daten ein wesentliches Er

folgskriterium flir die Nutzung von Informationssystemen darstellt und Fragen der

Datenqualitat in dieser Arbeit breiten Raum einnehmen, wird auch dieser Aspekt um

rissen.

Begriffsbestimmungen 5

1.3.1 Wissen, Information und Daten

Information ist als Betrachtungsgegenstand unter anderem in der Informatik und in der

Wirtschaftswissenschaft gelaufig, wobei in der Literatur stark divergierende Be

griffsauffassungen erkennbar sind und auch innerhalb beider Fachbereiche unter

schiedliche Ansatze existieren.

In der Informatik werden die Begriffe Information und Daten haufig synonym verwen

det, da hier eine explizite Abgrenzung nicht unbedingt erforderlich scheint.2 Es wird

im wesentlichen auf die maschinelle Verarbeitbarkeit als konstituierende Eigenschaft

von Daten abgestellt. Dabei werden die Daten gleichgesetzt mit den Informationen, die

sie reprasentieren.3

Die Wirtschaftswissenschaft dagegen sieht Information sowohl als bedeutsamen Pro

duktionsfaktor wie auch als Zwischen- oder Endprodukt des betrieblichen Transfor

mationsprozesses an.4 Daher wird hier auch eine deutlichere Abgrenzung von den

beiden anderen genannten Begriffen vorgenommen. Ausgangspunkt ist haufig die

Definition von Information als zweckorientiertem Wissen,5 wobei allerdings der Wis

sensbegriff nicht naher erkliirt wird, obwohl er Bestandteil der Definition ist.

Fur die Zwecke der Wirtschaftsinformatik, in der Informationssysteme als zentrales

Erkenntnisobjekt im Mittelpunkt stehen,6 ist eine prazise Kliirung des Informationsbe

griffs bedeutsam. Kritiker an der obigen Definition von Wittmann fUhren aus, daB

diese - wie auch die Definitionen aus der Informatik - fUr die Fragestellungen der

Wirtschaftsinformatik nicht hinreichend genau sei.7

2

4

6

Eine Zusammenstellung der unterschiedlichen Sichtweisen auf diese Begriffe in der Informatik enthiilt Lehner/Maier (1994), S. 29ff. Beispielhaft fiir einen Vertreter der Datenbankliteratur sei Date genannt, der ausdriicklich Daten und Information synonym verwendet (vgl. Date (1995), S. 4). Vgl. auch Barkow et al. (1989), S. 57f., sowie Hesse et al. (1994), S. 42f. Dort wird altemativ zu dieser Sichtweise auch ein hierarchischer Zusammenhang zwischen Wissen, Information und Daten aufgezeigt, wobei Information ein subjektiver Charakter zugeordnet wird. Vgl. Gemiinden (1993), Sp. 1725; Picot/Franck (1988), S. 544f.; Picot (1990), S. 9f. Krcmar (1997), S. 22ff., stellt verschiedene Sichtweisen zur Interpretation von Information als Produktionsfaktor zusammen. Vgl. Wittmann (1959), S. 14f. Diese Definition wird beispielsweise von Gemiinden (1993) und Berthel (1992) als Basis der Ausfiihrungen iiber Information verwendet. Scharf kritisiert ("Diese Kennzeichnung ist [ ... ] unbrauchbar") wird sie dagegen von Schneider (1997), S. 80f. V gl. zum Gegenstand der Wirtschaftsinformatik Wissenschaftliche Kommission Wirtschaftsinformatik (1994). S. 80f. V gl. Lehner/Maier (1994), S. 28, und Streubel (1996), S. 20.

6 Einleitung

Entsprechend wurden in der Literatur zahlreiche Strukturierungsmethoden und Ansatze

zur Systematisierung und Abgrenzung dieser Begriffe fUr das Erkenntnisinteresse der

Wirtschaftsinformatik entwickelt.8 Die verschiedenen Ansatze vermitteln ein sehr

heterogenes Bild der Begriffsverwendung in der Wirtschaftsinformatik. Daher ist es

notwendig, hier die im folgenden verwendete Sichtweise kurz darzulegen.9

Wissen stellt das begriffliche Dach dar, unter dem sich sowohl Daten als auch Infor

mation als Teilmengen subsumieren lassen. Wissen besteht aus Wahrnehmungen,

Erfahrungen und Kenntnissen einer Person tiber ihre Umwelt. Dieses subjektive Wis

sen kann durch Diskurs und interpersonalen Konsens objektiviert werden. lo Weiterge

hende Ansatze abstrahieren von der Bindung des Wissens an den Menschen und sehen

daher auch Wissenskategorien, die unabhangig yom Menschen, z.B. in einer Organisa

tion, vorliegen. 11 Es bleibt festzuhalten, daB Wissen im Unternehmen damit in unter

schiedlicher Form vorliegt, in subjektiver und in objektiver Form, sowie gebunden an

die Menschen im Unternehmen oder auch 10sgelOst von diesen. Dabei ist weder die

maschinelle Verarbeitbarkeit noch der Bezug zu den Zielen des Unternehmens konsti

tutionell fUr das Vorliegen von Wissen. Diese beiden Eigenschaften konnen der Ab

grenzung der tibrigen zu diskutierenden Begriffe dienen.

Verwendet man das genannte Kriterium der maschinellen Verarbeitbarkeit, so gelangt

man zum Begriff Daten, fUr den genau diese Eigenschaft konstitutiv iSt. 12 Es fallt

jedoch durch den technischen Fortschritt in der Datenverarbeitung zunehmend schwer,

die Teilmenge der Daten aus dem Wissen genau abzugrenzen, da immer mehr auch

unstrukturierte Ausdrucksformen von Wissen maschinell verarbeitet werden konnen. 13

LieB sich tiber viele Jahre hinweg praktisch nur schriftliches und genau strukturiertes

10

II

12

13

In Streubel (1996), S. 21, findet sich eine Zusammenstellung verschiedener Ansatze deutschsprachiger Autoren, in der ausgehend von den jeweiligen Definitionen des Informationsbegriffs der Bezug zu Daten und Wissen verdeutlicht wird. Lehner/Maier (1994). S. 44ff., diskutieren ausfiihrlicher die unterschiedlichen Striimungen. Das dargestellte Begriffsverstandnis orientiert sich an Streubel (1996), S. 22ff. Dort findet sich eine ausfiihrlichere Darstellung, die eine Strukturierung anhand der Semiotik vornimmt. V gl. Hesse et al. (1994), S. 42. Wissen kann nach zahlreichen Merkmalen klassifiziert werden. Beispiele nennt Gabriel (1992), S. 32ff. Derartiges Wissen wird als organisational bzw. organisatorisch bezeichnet. V gl. Oberschulte (1994), S. 60ff. Ausfiihrlichere Diskussionen des Datenbegriffs finden sich in Lehner/Maier (1994), S.30f., sowie Lehner/Hildebrand/Maier (1995), S. 200f. Ferner haben auch die Normungsinstitutionen in DIN 43300 und ISO 2382/1 1974-12-15 Definitionen hierzu verabschiedet. Kiing (1994), S. 12f., stellt weitere Auffassungen aus der Literatur zusammen. Vgl. z.B. Hansen (1996), S. 8.


Wissen durch Computer auswerten, konnen heute oder in naher Zukunft Daten auch in

vielfaltigen anderen Erscheinungsformen (Tone, Sprache, Bilder, Geriiche usw.) vor

liegen, da entsprechende Verarbeitungsgerate verftigbar sind oder sein werden.

Daten

Wissen

maschinell

Informationen und Daten

nicht maschinell verarbeitbar

ohne Zweckeignung

Abbildung I: Die Abgrenzung der Begriffe Wissen, Daten und Information 14

Der Bezug zu einem gegebenen Zweck der Verarbeitung ist hingegen nicht Gegen

stand der Betrachtung, wenn der Datenbegriff abgegrenzt werden solI. Orientiert man

sich an diesem Kriterium und unterscheidet also zweckbezogenes von nicht zweckbe

zogenem Wissen, so bildet die erstgenannte Teilmenge Information. Dabei handelt es

sich urn das Wissen, das den Erkenntnisstand eines (mensch lichen) Aufgabentragers in

einer bestimmten Situation zur Erfiillung einer Aufgabe verbessern kann. Information

ist somit an einen spezifischen Verwertungszusammenhang gebunden. Unerheblich ist,

ob die Information auch tatsachlich zur Verbesserung seiner Entscheidungsgrundlage

verwendet wird oder nicht. Lediglich die potentielle Eignung bzw. Einsetzbarkeit der

14 In Anlehnung an Streubel (1996), S. 25.

8 Einleitung

Information zur Untersttitzung bei einer bestimmten Aufgabe ist entscheidend. ls Nicht

konstitutiv fUr den Informationsbegriff ist dagegen die maschinelle Verarbeitbarkeit,

so daB sich das Wissen in die Teilmengen Daten, Information sowie die Schnittmenge

dieser Teilmengen aufteilen laBt. Abbildung 1 zeigt zusammenfassend nochmals diese

Unterscheidung zwischen Wissen, Daten und Information.

Da nicht Information, sondern das (computergesttitzte I6) Informationssystem im Mit

telpunkt der Diskussion steht, ist auch dieser Begriff zu klaren. Dies ist Gegenstand

des folgenden Abschnitts.

1.3.2 Informationssystem

Als Ausgangspunkt der Betrachtung wird hier der Systembegriff verwendet. 17 Dieser

laBt sich z.B. mit Hilfe der Systemtheorie erlautern, die als interdisziplinare Wissen

schaft versucht, eine grundsatzlich auf aile, also etwa soziale, technische oder biologi

sche Systeme anwendbare formale Theorie zu entwickeln. 18 Die Realitat wird hierbei

in einem allgemeinen Modellrahmen - dem System - abgebildet, erklart und gestal

tet. 19

Ein System besteht aus Elementen sowie den Beziehungen zwischen diesen Elemen

ten. Elemente sind als Grundbestandteil des Systems entweder nicht weiter zerlegbar,

oder sie sollen nicht weiter zerlegt werden, urn eine Betrachtung auf einem hoheren

Aggregationsniveau zu ermoglichen.2o Die EinfUhrung von Subsystemen ermoglicht

die Betrachtung verschiedener Aggregationsstufen, indem alternativ das Subsystem als

"black box" im Kontext seiner Beziehungen zu anderen Systemelementen

(AuBensicht) oder aber die Elemente und Beziehungen innerhalb des Subsystems

IS

16

17

18

19

20

Vgl. Gemiinden (1993), Sp. 1725; Hahn/LaBmann (1993), S.3; Szyperski (1980), Sp.904; Berthel (1992), Sp. 872f. Grundsatzlich ist die Eigenschaft der Computerunterstiitzung nicht konstitutiv fUr ein Informationssystem. So kann zwischen aktuell computergestiitzten, potentiell computerunterstiitzbaren und nicht computergestiitzten Informationssystemen unterschieden werden, vgl. Streubel (1996), S. 57f. Diese Klassifikation soli hier jedoch nicht verfolgt werden. Fiir eine vertiefte Darstellung des Systembegriffs vgl. Lehner/Hildebrand/Maier (1995), S. 44ff.; Streubel (1996), S. 58ff. Eine allgemeine EinfUhrung in die Systemtheorie enthalt Gabler Wirtschaftslexikon (1997), S.3700. Vgl. Schiemenz (1993), Sp. 4128. V gl. Barkow et al. (1989), S. 58.


(Innensicht) betrachtet werden.21 Neben dieser Hierarchisierung durch Subsysteme

konnen auch Teilsysteme, die bestimmte Eigenschaften hervorheben, gebildet wer

den.22

Als eine wichtige These des systemtheoretischen Ansatzes gilt, daB das System mehr

umfaBt als die Summe seiner Teile (Ubersummativitlit).23 Danach wird das System mit

zunehmender Integration zu einem Gesamtsystem urn weitere Eigenschaften berei

chert, die in den einzelnen Teilen nicht angelegt sind, wlihrend allerdings andere Ei

genschaften der Subsysteme durch die Integration verlorengehen. FUr eine Untersu

chung, die sich mit der Betrachtung von Aspekten einer Integration verschiedener

Informationssysteme befaBt, erscheint dies wichtig, da sich vermuten lliBt, daB auf

grund von Ubersummativitlit ein Nutzen entsteht, der tiber den der Teilsysteme hinaus

geht.

Auch ein Informationssystem als Ausprligung eines solchen allgemeinen Systems kann

somit als Menge aus Elementen und Beziehungen bezeichnet werden. Als Elementar

ten eines computergesttitzten Informationssystems sollen unterschieden werden:24

• Die durch das System zu bearbeitende Aufgabenstellung,

• der Mensch als Trliger dieser Aufgabe sowie

• die Informationstechnologie25 zur Untersttitzung bei der Erftillung dieser Aufgabe.26

Als erster wesentlicher Bestandteil des computergesttitzten Informationssystems ist

zunlichst die Aufgabe zu betrachten. Sie reprlisentiert den Zweck dieses Systems, der

sich aus der Gesamtheit der von der Organisation zu erbringenden Leistungen ableiten

lliBt.27 Geht man davon aus, daB alle Arten von anfallenden Aufgaben Information

voraussetzen, konnen slimtliche Aufgaben im Unternehmen als Elemente des Informa

tionssystems bezeichnet werden.

21 22 23 24

25

26

27

Vgl. z.B. FerstllSinz (1998), S17f. Vgl. Lehner/HiidebrandIMaier (1995), S. 50. Vgl. MUller-Merbach (1992), S. 856f. Vgl. GabriellChamoni/Gluchowski (1995), S. 36f.; Hesse et al. (1994), S. 43; Heinrich (1986), S.67. GemaB den obigen Ausflihrungen mUBte genaugenommen von Datentechnologie gesprochen werden. Hier wird jedoch mit dem Begriff Inforrnationstechnologie der gangige Sprachgebrauch beibehalten, auBerdem kann von der These ausgegangen werden, daB die gespeicherten Daten auch zweckorientiert verarbeitet werden sollen. Fehlt das letzte Element, liegt offensichtlich ein nicht computergestlitztes Informationssystem vor, z.B. in einer Besprechung im Untemehmen. Vgl. Hesse et al. (1994), S. 43.

10 Einleitung

Als Trager einer Aufgabe kann immer der Mensch identifiziert werden. Ihm kommt

selbst bei automatisierten Systemen die Rolle zu, die Ziele, die Aufgabe selbst und

auch die Informationsverwendung vorher definiert zu haben und auch Planung und

Kontrolle auszutiben sowie die Verantwortung fiir die Aufgabe zu tragen.28

Das Systemelement Informationstechnologie umfaBt schlieBlich die Gesamtheit der

eingesetzten physischen informationsverarbeitenden Komponenten (Hard- und Soft

ware), die zur vollstandigen oder teilweisen Untersttitzung der Menschen bei der Er

fiillung ihrer Aufgaben dienen.29

Konkretisiert man diese abstrahierende Betrachtung, so lassen sich unterschiedliche

Abgrenzungen des Begriffs Informationssystem und Merkmale zu deren weitergehen

der Klassifizierung ableiten. Diese Aspekte sind Gegenstand des folgenden Abschnitts.

1.3.3 Kategorien betrieblicher Informationssysteme

In der Literatur finden sich sehr unterschiedliche Erklarungen zu der Frage, was genau

unter einem Informationssystem zu verstehen ist und nach welchen Kriterien verschie

dene Kategorien von Informationssystemen unterschieden werden konnen.30

Vielfach wird bei den Informations- bzw. Anwendungssystemen31 zwischen Admini

strations-, Dispositions-, Planungs- und Kontrollsystemen differenziert.32 Unter diesem

begrifflichen Dach lassen sich also alle Systeme zur Informationsverarbeitung in einer

Unternehmung33 zusammenfassen. Zunehmend abgertickt wird dagegen von Sichtwei-

28

29

30

31

32

33

Vgl. Hesse et al. (1994), S.43. Eine andere Sichtweise vertreten dagegen z.B. Ferstl/Sinz (1998), S. 2ff. und 233, die zwischen menschlichen und maschinellen Aufgabentragern unterscheiden, wobei von maschinellen Tragern durchgefilhrte Aufgaben als automatisiert bezeichnet werden. Vgl. Hesse et al. (1994), S. 43; Gluchowski/Gabriel/Chamoni (1997), S. 40. Eine Zusammenfassung gangiger deutschsprachiger Begriffsauslegungen findet sich in FerstllSinz (1998), S. 8f. Unter einem Anwendungssystem versteht man die technischen Komponenten eines Informationssystems einschlieBlich der System- und Anwendungssoftware zur Bearbeitung spezifischer Aufgaben, vgl. z.B. Ferstl/Sinz (1998), S. 3f.; Gluchowski/GabriellChamoni (1997), S. 44. V gl. z.B. Mertens (1997a), S. 11 ff.; Mertens/Griese (1993), S. Iff. In dieser Untersuchung wird vielfach mit der Informationsverarbeitung in Unternehmungen argumentiert und damit dem in der Literatur weitgehend iiblichen Sprachgebrauch gefolgt. Trotzdem lassen sich die angestellten Oberlegungen weitgehend auch auf sonstige infonnationsverarbeitende Gebilde anwenden, die andere iibergeordnete Zielc verfolgen oder in anderen Strukturen organisiert sind als (typischerweise erwerbswirtschaftlich ausgerichtete) Unternehmungen. Auch werden die Begriffe "Unternehmung" und "Unternehmen" im folgenden synonym verwendet.


sen, die unter einem Informationssystem explizit ein Anwendungssubsystem zur Un

tersttitzung von Entscheidungen des Managements verstehen.34

Systeme zur Unternehmensplanung und -fuhrung

Analyse-I nformationssysteme

Berichts- und Kontrolisysteme

Wertorientierte Abrechnungssysteme

Mengenorientierte operative Systeme

Abbildung 2: Einteilung der Anwendungssysteme nach der Managementpyramide35

GemaB der genannten Einteilung und in Analogie zur "Managementpyramide" konnen

die verschiedenen Anwendungssysteme im betrieblichen Informationssystem auch in

einer Systempyramide dargestellt werden (Abbildung 2).

Der untere Teil dieser Pyramide umfaBt Prozesse, die direkt mit der Leistungserstel

lung im Unternehmen zusammenhangen. Mengen- und wertorientierte Systeme sind

34

35

Vgl. Gluchowski/GabriellChamoni (1997), S. 44. Ferstl/Sinz (1998), S. 3f., nennen beispielhaft als diese Sichtweise vertretende Autoren Stahlknecht (der z.B. auch noch in StahlknechtlHasenkamp (1997), S.426, "Informationssystem" als Synonym zu "Fiihrungsinformationssystem" bezeichnet) und altere Werke von Mertens und Griese. In Anlehnung an Scheer (1997), S. 5, und Gluchowski/Gabriel/Chamoni (1997), S. 44.

12 Einleitung

hinsichtlich der Datenentstehung eng miteinander verkniipft und werden sich auch

ablauforganisatorisch kaum voneinander trennen lassen.36 Diese Administrations-,

Dispositions- und Abrechnungssysteme werden vielfach als operative Informationssy

sterne bezeichnet.37 Sie sind oft an den betrieblichen Funktionsbereichen orientiert.

Aufgrund der engen horizontalen Verzahnung der Funktionsbereiche ist eine inte

grierte Datenbasis wiinschenswert, die allen Anwendungssystemen flir die einzelnen

Funktionen zugrundeliegt. 38

Ais logisches Komplement zu diesen operativen Informationssystemen stehen im obe

ren Teil der Pyramide in Abbildung 2 verschiedene Planungs- und Kontrollsysteme.39

Diese sind weitgehend deckungsgleich mit den vieldiskutierten Management Support

Systemen, also den Anwendungssystemen, die den betrieblichen Entscheidungstragern

zur Unterstiitzung bei der Abwicklung ihrer spezifischen Aufgaben dienen.40

Die dieser Begriffswelt immanente personengruppenspezifische Klassifikation be

trieblicher Informationssysteme erscheint flir diese Untersuchung nicht zweckmaBig.

Konstituierend flir eine Informationssystemklasse im Unternehmen ist nicht der Status

des Benutzers, so daB die Bezeichnung "Hilfe fiir das Management" fehlgeht. Wesent

lich ist dagegen, daB das System der Bereitstellung von spezifisch aufbereiteten Infor

mationen zur Unterstiitzung von Entscheidungen dienen soil. Die These, daB Entschei

dungen generell von Managern hoher Hierarchiestufen getroffen werden, erscheint in

Zeiten moderner, schlanker Organisationsformen wenig haltbar, und es ist erkennbar,

daB auch dispositive und planende Tatigkeiten, die in Entscheidungen mit gewisser

Tragweite miinden, von Personen im Unternehmen durchgeflihrt werden, die nicht dem

Management zuzurechnen sind. Daher soli hier als Komplement zu den operativen

Informationsystemen von analyseorientierten Informationssystemen gesprochen wer

den. Ais begriffliche Klammer werden damit die Systeme eingeschlossen, die den

Fach- und Fiihrungskraften Informationen flir Analysezwecke bereitstellen.41 Diese

36

37

38

39

40

41

Vgl. Scheer (1997), S. 5. Vgl. z.B. FerstllSinz (1998), S. 33ff.; Scheer (1997), S. 5; Chamoni/Gluchowski (I 998b), S. 10. Diese Forderung manifestiert sich in der wissenschaftlichen Diskussion auch dadurch, daB in letzter Zeit eher tiber Prozesse, die bei der Leistungserstellung durchlaufen werden, gesprochen wird. Das funktionsorientierte Paradigma tritt dagegen in den Hintergrund. Vgl. z.B. Scheer (1997), S. 8. Zu dieser Begriffsabgrenzung vgl. Gluchowski/GabriellChamoni (1997), S. 47ff. Zum Begriff des Management Support Systems vgl. z.B. Gluchowski/GabriellChamoni (1997), S. 237ff.; Krallmann/Rieger (1987), S. 29f. In Anlehnung an Chamoni/Gluchowski (l998b), S. IOf.


Sichtweise wird durch die modifizierte Informationssystempyramide visualisiert, die in

Abbildung 3 dargestellt ist.

Abbildung 3: Betriebliche Informationssystempyramide42

Analyseorientierte Informations

systeme

Operative I nlormationssysteme

Die Unterscheidung zwischen operativen Informationssystemen einerseits und analy

seorientierten Informationssysteme andererseits soli Grundlage fUr die folgende Unter

suchung sein, die in ihrem Kern die Datenaustauschbeziehungen zwischen diesen

Systemklassen betrachtet. Ais Basis fUr die Datenhaltung in beiden Kategorien werden

Datenbanksysteme verwendet, in denen die Strukturen der abgebildeten Betrachtungs

objekte jeweils durch Modelle reprasentiert werden.

Informationssysteme lassen sich unter vielerlei Gesichtspunkten betrachten. Der

Schwerpunkt der AusfUhrungen in dieser Arbeit liegt auf den Aspekten, die Fragen der

Datenspeicherung und der Integration von Daten verschiedener Quellen betreffen.

42 Chamoni/Gluchowski (l998b), S. 11.

14 Einleitung

Auch wenn andere Betrachtungsgegenstande wie z.B. einzelne Anwendungsprogram

me oder auch die organisatorische Einbettung in der Unternehmung damit zuweilen in

den Hintergrund rucken, sei dennoch ausdrucklich betont, daB auch diese mit unter den

Informationssystembegriff subsumiert werden sollen.

1.3.4 Qualitiit von Daten

Ein wichtiger Erfolgsfaktor ftir die Nutzung von Informationssystemen ist die Qualitat

der gespeicherten Daten, denn betriebliche Entscheidungen auf allen Ebenen basieren

auf Informationen, die vielfach aus diesen Daten gewonnen werden. So erscheint es

einleuchtend, daB nur Daten guter Qualitat es ermoglichen, Informationen zu erzeugen,

die als Basis fiir zuverlassig sachgerechte Entscheidungen dienen konnen.43 1m Zu

sammenhang mit der verstiirkten Nutzung eigenstandiger Informationssysteme ftir

Analysezwecke gewinnt dieser Aspekt noch an Bedeutung, denn hier konnen Datenbe

stande breiteren und systematischeren Auswertungen unterzogen werden als durch

herkommliche Berichtssysteme. Dabei ist schon das Zustandekommen eines hierftir

vorgesehenen eigenstandigen Datenbestands von der Erftillung von Mindestanforde

rungen an die Datenqualitat abhangig, da hierftir zumindest strukturelle Vorgaben

eingehalten werden mtissen.44 Ein steigender Automatisierungsgrad in den Analyse

prozessen ftihrt auBerdem dazu, daB die durch das Erfahrungswissen des Entscheiders

bedingte gedankliche Korrektur falscher Daten so nicht mehr erfolgen kann.

Der Begriff der Datenqualitat wird in der Literatur in sehr unterschiedlicher Sichtweise

und mit verschiedenen operationalisierenden Merkmalen beschrieben.45 Ohne auf die

einzelnen Richtungen im Detail einzugehen, wird im folgenden erlautert, inwieweit die

vielfiiltigen mit diesem Problemfeld verbundenen Aspekte fiir diese Arbeit von Be

deutung sind.

Unter Qualitat wird die Eignung eines Gutes fiir einen gegebenen Zweck verstanden.46

Zweck der Daten ist, neben ihrer Nutzung als moglichst effizient einzusetzender Fak

tor im Rahmen des Leistungserstellungsprozesses, die Erzeugung von hochwertigen

Informationen, die moglichst sachgerechte Entscheidungen ermoglichen.47 Somit laBt

43 44 45 46 47

V gl. Nayer (1993), S. 51ff. Vgl. Celko/McDonald (1995), S. 43. Eine Ubersicht iiber die verschiedenen Ansiitze wird in Wang/StoreylFirth (1995) entwickelt. V gl. Engelhardt (1995), S. 6. Ahnlich auch Gabler Wirtschaftslexikon (1997), S. 3161. Vgl. zum Zweck von Informationen auch Gemiinden (1993), Sp. 1725f.


sich Datenqualitat im vorliegenden Zusammenhang als die potentielle Eignung der

Daten auffassen, aus ihnen Informationen ableiten zu konnen, welche die menschli

chen Aufgabentrager bei ihren Entscheidungsprozessen untersttitzen.48

Mit Hilfe der Semiotik als Strukturierungshilfe JaEt sich die Qualitat von Daten anhand

von Merkmalen auf der syntaktischen, semantischen und pragmatischen Ebene unter

suchen:

• Auf der syntaktischen Ebene kann die technische Verftigbarkeit und Verwendbar

keit der Daten betrachtet werden. Dies betrifft neben Aspekten der Datensicherheit

auch Fragen der geeigneten und einheitlichen Reprasentation der abgebildeten

Sachverhalte, etwa die Einheitlichkeit von Formaten und Darstellungsformen.49

• Auf der semantischen Ebene werden Merkmale betrachtet, die sich auf den Aussa

gegehalt der Daten beziehen, wie z.B. Prazision, Detailliertheit, Validitat und

Quantifizierbarkeit. Relevant sind auEerdem Aspekte des empirischen und log is chen

Wahrheitsgehaltes wie Vertrauenswtirdigkeit, Fehlerfreiheit, Konsistenz und Prtif

barkeit.50

• Auf der pragmatischen Ebene kann man die zeitliche und sachliche Eignung sowie

die Vollstandigkeit der Daten fUr den gegebenen Zweck untersuchen.

Konkretisieren und operationalisieren lassen sich diese Merkmale, indem der Bezug

zur Nutzung der Daten hergestellt wird, also etwa als Information zur Entscheidungs

untersttitzung im Rahmen bestimmter Aufgabenbereiche. Zentral ist dann insbesondere

das Merkmal der Relevanz der Daten fUr die betrachtete Aufgabe. Nicht relevante

Daten liefern keinen Informationszuwachs und sind gegebenenfalls kontraproduktiv,

wei I auch deren Verarbeitung (maschinelle und kognitive) Ressourcen verbraucht. 51

Dartiber hinaus sind z.B. Merkmale wie Vollstandigkeit, eine problemadaquate Ge

nauigkeit und die VerfUgbarkeit von Metadaten von Bedeutung.52

48

49

50

51

52

VgI auch Davis (I 997b), S. III, und Berg/Heagele (1997), S. 89ff. V gl. Wang/StoreylFirth (1995), S. 629. Vgl. zu diesen Merkmalen Gemiinden (1993), Sp. 1726; Wand/Wang (1996), S. 92f. Vgl. Redman (1996), S. 249. Vgl. Behme/Mucksch (l998b), S.26f. Ein strukturierter und hierarchisierter Merkmalskatalog ist in Jeusfeld/Jarke (1997), S. 493, dargestellt.

16 Einleitung

Die Qualitat der Datenbestande im Unternehmen wird vielfach als schlecht bezeich

net.53 1m Rahmen der operativen Nutzung der Daten werden durch die mangelnde

Qualitat Effizienzverluste und zusatzliche Kosten verursacht.54 Trotzdem kann nicht

iibersehen werden, daB die Daten den Anforderungen der mengen- und wertorientier

ten Administrations- und Dispositionssysteme weitgehend entsprechen und somit in

diesem Zusammenhang nur wenig Motivation zur Erhahung der Qualitat besteht. In

den Vordergrund riickt das Problem mangelnder Datenqualitat dann, wenn die Umge

bung, in der die Nutzung dieser Datenbestande erfolgt, verandert werden soil. Dies

kann an zwei Beispielen verdeutlicht werden:

• Informationssysteme, die den aktuellen Anforderungen z.B. hinsichtlich ihres Lei

stungsverhaltens, der durch sie entstehenden Kosten, der Funktionalitat, der Daten

haltungskonzepte, der verwendeten Hardware- und Betriebssystemumgebung oder

der Softwareergonomie nicht mehr entsprechen, werden durch Nachfolgesysteme

abgelOst. 1m Rahmen eines solchen, als Migration bezeichneten Prozesses ist es ne

ben anderen UmstellungsmaBnahmen auch erforderlich, die Datenbestande aus den

Altsystemen an geanderte Datenhaltungskonzepte und Strukturen anzupassen.55

Vielfach werden auch mehrere alte Systeme durch eine integrierte Lasung ersetzt,

etwa im Rahmen der Einfiihrung einer betriebswirtschaftlichen Standardsoftware. 56

Dies setzt voraus, daB die bestehenden und weiterzuverwendenden Datenbestande

zumindest in ihrer Struktur, den Formaten und der physischen Reprasentation adap

tiert werden. Dieser Vorgang und die anschlieBende Nutzung der Daten in der neuen

Systemumgebllng erscheint jedoch nur dann erfolgversprechend, wenn die Daten

von guter syntaktischer, semantischer und pragmatischer Qualitat sind.

• 1m Rahmen der Einfiihrung eines analyseorientierten Informationssystems gewinnt

der Aspekt der Datenqualitat noch starker an Bedeutung. Hier wird die im Rahmen

der Migration allgemein auftretende Problematik der Transformation und Integrati

on der Daten dadurch erweitert, daB die Daten zusatzlich einer veranderten Nutzung

zugefiihrt werden sollen. Mehr noch als im Rahmen von Migrationsprojekten tritt

53

54

55

56

Vgl. Wang/Storey/Firth (1995), S. 623; Wand/Wang (1996), S. 86f.; Celko/McDonald (1995), S. 43. Redman (1996), S. 5ff., zitiert zahlreiche weitere Quellen. Beispiele nennt Redman (1996), S. 7ff. Zum breiten Themenfeld der Migration vgl. Brodie/Stonebraker (1995), S. 7ff., sowie Meier (1997). V gl. Hansen (1996), S. I 87ff.


der Integrationsaspekt in den Vordergrund, und auch die hier eher zeitraumbezogene

Nutzungscharakteristik stellt erh6hte Anforderungen an die Qualitat der Daten.57

Die Qualitat der Datenbestande stellt somit einen wichtigen Aspekt bei der Gewinnung

von Daten fUr analyseorientierte Informationssysteme dar. Bereits an dieser Stelle ist

erkennbar, daB qualitatsverbessernde MaBnahmen offensichtlich bei den entsprechen

den Transformationsfunktionen einen breiten Raum einnehmen. Offen bleibt an dieser

Stelle die Frage, ob entsprechende MaBnahmen auch dazu geeignet sein k6nnen, die

Qualitat der operativen Daten zu verbessern, indem die im Rahmen der Transformation

zur Bestiickung einer Datenbank fUr Analysezwecke gewonnenen Erkenntnisse auch

auf den operativen Datenbestand zuriickiibertragen werden.

Nachdem nun die zentralen begrifflichen Aspekte umrissen worden sind, dienen die

folgenden beiden Kapitel der naheren Darstellung der beiden wesentlichen System

klassen. Das nachste Kapitel widmet sich den operativen Systemen, ihrer Bedeutung

innerhalb der betrieblichen Informationsverarbeitung und ihrer Rolle als Datenlieferant

fUr die funktionslogisch nachgelagerten analyseorientierten Informationssysteme,

deren detailliertere Betrachtung dann Gegenstand von Kapitel 3 ist.

57 Vgl. z.B. CelkofMcDonald (1995), S. 43ff.

Operative 1nformationssysteme 19


Informationssysteme, die auf die Untersttitzung operativer Anwendungsfelder ausge

richtet sind, leisten in nahezu jedem Unternehmen unverzichtbare Dienste. Als bedeut

sames Element in der Architektur dieser Systeme werden Datenbanksysteme einge

setzt, die der Speicherung und Verwaltung der anfallenden Datenbestande dienen. In

diesem Kapitel werden die operativen Informationssysteme vornehmlich unter diesem

Gesichtspunkt der ihnen zugrundeJiegenden datenspeichernden Komponenten be

schrieben. Das Ziel Jiegt in der Darstellung der Aspekte, die flir eine splitere Betrach

tung der Extraktion und Transformation der relevanten Daten flir Analysezwecke von

Belang sind.

Dazu wird in Abschnitt 2.1 grundlegend auf Fragen des Aufbaus und des Einsatzes

operativer Informationssysteme im Unternehmen und auf entstehende Nutzeffekte

eingegangen.

Abschnitt 2.2 dient der Darstellung der semantischen und logischen Datenmodelle, die

Gegenstand der Entwicklung und Bestandteil eines "fertigen" Informationssystems

sind.

In Abschnitt 2.3 liegt dann der Fokus der Betrachtung auf den Architekturen und

Komponenten solcher Systeme. Hier wird ein Schwerpunkt auf die Architekturformen

gelegt, die tiber mehr als nur ein zentrales Datenbanksystem verftigen.

Metadaten als Daten tiber die Daten spielen eine bedeutsame Rolle flir die Entwicklung

eines operativen Informationssystems, treten jedoch im Rahmen seiner Nutzung eher in

den Hintergrund. Sollen Daten auBerhalb des abgegrenzten Bereichs der Anwendung,

flir die sie gespeichert werden, eine weitere Verwendung finden, wie etwa in separaten

Systemen flir Analysezwecke, erfahren Metadaten wiederum eine stlirkere Beachtung,

da sie als "Schltissel" zu einer erweiterten Nutzung der Problemdaten dienen konnen.

Daher wird in Abschnitt 2.4 auf Aspekte der Metadatenverwaltung in den operativen

Systemen eingegangen.

Den AbschluB dieses Kapitels bildet mit Abschnitt 2.5 eine kurze Diskussion der Pro

blematik des Datenaustausches auf operativer Ebene, der nicht nur durch den Uber

gang von einer funktions- zu einer prozeBorientierten Betrachtung an Bedeutung ge

winnt.



Flir ein Verstandnis der Bedeutung der heute eingesetzten Informationssysteme, ihrer

Architekturen und auch den daraus erwachsenden Problemen erscheint eine Zusam

menfassung der Entwicklungsgeschichte der Informationssysteme und insbesondere

ihrer Konzepte zur Datenspeicherung angemessen, flihren doch die vielfach bis heute

verwendeten alten Systeme zu den Problembereichen der Heterogenitat und mangeln

den Integration und damit zu einem wesentlichen Motiv dieser Arbeit. AnschlieBend

werden Nutzeffekte, die sich aus dem Einsatz (alter und neuer) Informationssysteme

ergeben, diskutiert. Ein Blick auf die gangigen Vorgehensmodelle zum Aufbau daten

bankbasierter Informationssysteme beschlieBt diesen Abschnitt.

2.1.1 Historie

Die Anflinge automatisierter Datenverarbeitung im Unternehmen waren dadurch ge

kennzeichnet, daB viele eigenstandige Anwendungsprogramme entworfen und imple

mentiert wurden, die jeweils ein eng abgegrenztes Aufgabengebiet unterstlitzten. Dabei

wurden die Funktionslogik und die zugrundeliegende Datenhaltung eng miteinander

verknlipft, wogegen eine Integration der flir unterschiedliche Aufgaben entwickelten

Programme nur nachrangige Bedeutung hatte. Dies hatte zur Folge, daB die Program

mierer die flir ihr Programm beni:itigten Datenstrukturen zumindest teilweise unabhan

gig von bereits bestehenden anderen Programmen und deren Datenstrukturen entwer

fen konnten.58 Dieses Vorgehen erlaubte eine gute Anpassung der Datenstrukturen und

des physischen Dateiaufbaus an die speziellen Erfordernisse des jeweiligen Programms

und die Entwicklung von Software, die im Rahmen der gegebenen technischen M6g

lichkeiten leistungsflihig war. Die im Laufe der Zeit stattfindende Weiterentwicklung

und Erweiterung der Informationssysteme flihrte jedoch zu einem wachsenden und

schwer liberschaubaren Bestand an Daten- und Programmdateien, die eine systemati

sche Nutzung vorhandener Daten und bereits programmierter Ablaufe prohibitiv er

schweren.59

58

59 V gl. Schlageter/Stucky (1983), S. 20. So wird beispielsweise von einer Untersuchung in einem Stahlkonzern berichtet, wo 40.000 Dateien mit 25.000 Datensatzbeschreibungen vorlagen, die von 30.000 Jobs, 69.000 Programmen und 39.000 Auswertungen verarbeitet wurden (vgl. Mertes/Klonki (1991), S. 314). Auch wenn diese Untersuchung einige Jahre zuriickliegt, kann angenommen werden, daB auch he ute noch viele Unternehmen mit derartigen "Altlasten" umgehen.

Bedeutung und Ziele 21

Betrachtet man tiber das einzelne Programm hinaus die Gesamtheit der im Unterneh

men eingesetzten Software und deren Datenstrukturen, so ist zu erwarten, daB bei

derartigen Strukturen viele Daten redundant gespeichert sind. Unabhangig von der

mittlerweile wohl weitgehend obsoleten Frage nach den Kosten flir den durch die

Redundanzen benotigten zusatzlichen Speicherplatz lassen sich zahlreiche Argumente

nennen, die ftir eine integrierte und zentralisierte Datenhaltung unabhangig von den

auf diese Daten zugreifenden Programmen sprechen. Beispielhaft konnen angeflihrt

werden:

• Redundanz birgt die Gefahr der Inkonsistenz, wenn sich widersprechende Informa

tionen tiber denselben Sachverhalt vorliegen.

• Datenbestande stellen eine wertvolle Ressource im Unternehmen dar und haben aus

okonomischen und auch juristischen60 Grtinden eine lange Lebensdauer, die tiber

die der Programme, welche die Daten manipulieren, hinausgeht. Letztere unterlie

gen aufgrund sich wandelnder Anforderungen einer signifikant groBeren Ande

rungsdynamik.

• Dezentrale, nicht verbundene Datenbestande erschweren die Abbildung und Unter

stiitzung von Querschnittsfunktionen oder verhindern sie sogar ganz.

Weiterhin besteht bei einer Konzeption von Programmsystemen aus einer Vielzahl von

Einzelprogrammen ohne zentralen Datenbestand, die z.B. in einer Programmiersprache

der dritten Generation wie COBOL realisiert sein konnen, eine sehr enge Verflechtung

zwischen dem einzelnen Programm und seinen Daten. MuB der Aufbau einer Datei

geandert werden, sind gleichzeitig erhebliche Anderungen an den entsprechenden

Programmen erforderlich. Dieser Umstand wird als Datenabhangigkeit bezeichnet.

Als Basis flir ein Konzept, das die genannten Nachteile dezentralisierter Datenspeiche

rung zu vermeiden sucht, haben sich Datenbanksysteme als Instanz zur zentralisierten

Speicherung der im operativen Unternehmensgeschaft anfallenden Daten heute weit

gehend durchsetzen konnen. Zur Begrtindung kann angeftihrt werden, daB einerseits

mit den heutigen Datenbankmanagementsystemen die technischen Moglichkeiten

gegeben sind, urn auf der Basis problemadaquater Datenmodelle (insbesondere des

Relationenmodells) auch groBe Datenmengen effizient, schnell und sicher zu speichern

sowie flir Lese- und Veranderungsoperationen vorzuhalten. Zudem wurden durch die

60 Hier kann etwa an die gesetzlichen Aufbewahrungspflichten fOr Belege gedacht werden, denen auch nachgekommen werden kann, indem die entsprechenden Daten vorgehalten werden.


groBen technischen Fortschritte im Hardwarebereich Rechenleistung sowie Primar

und Sekundarspeicherplatz wesentlich kostengtinstiger, was den Ubergang von wenig

benutzungsfreundlichen Betriebsarten wie der Stapelverarbeitung zu interaktiven,

bildschirmorientierten Anwendungen begtinstigte.61 Durch diese dialogorientierte

Arbeitsweise ist es notwendig, veranderte Datenbestiinde sofort in aktualisierter Form

zur VerfUgung zu stellen. Dies kann mit Datenbanksystemen, die eine transaktionsori

entierte Verarbeitungsform verwenden, einfacher realisiert werden als mit dateibasier

ten Anwendungen.62

Diese Vorztige der Datenbanktechnologie im Vergleich zur konventionellen, dateiori

entierten Datenspeicherung haben dazu gefUhrt, daB neu entwickelte Informationssy

sterne heute in der Regel zur Datenhaltung auf einem Datenbanksystem basieren. Da

her ist erkennbar, daB die Menge der Daten, die in alteren Datenhaltungsformen wie

etwa wenig strukturierten Textdateien vorliegt, abnimmt. Daruber hinaus laBt sich fUr

operative Informationssysteme in groBen wie auch in kleineren Unternehmen ein brei

ter Trend zur EinfUhrung betriebswirtschaftlicher Standardanwendungssoftware -

zumindest zur Untersttitzung bestimmter Funktionsbereiche im Unternehmen - beob

achten.63 Nicht nur die prominenten Vertreter dieser Softwaregattung wie z.B. SAP

R/3 oder Oracle Applications bedienen sich dabei zur Datenhaltung relationaler Daten

bankmanagementsysteme,64 so daB mit steigendem Einsatz solcher Standardsoftware

auch der Verbreitungsgrad der Datenbanksystemsoftware zunimmt und diese sich

heute durchgesetzt hat.

Derartige Datenbanksysteme zur Untersttitzung operativer Aufgaben im Unternehmen

lassen sich anhand ihres Nutzungscharakters durch die auf sie zugreifenden Anwen

dungen beschreiben. Ftir diese Charakteristik wurde der Ausdruck OL TP (On-Line

Transactional Processing) gepragt.65 Dies bezeichnet Zugriffe, die typischerweise kurz

und anderungsintensiv sind. Sie dienen hauptsachlich dazu, die durch Geschaftsvor

falle im Unternehmen entstandenen Daten in den entsprechenden Datenbanken nieder

zulegen. Solche Transaktionen treten also im allgemeinen sehr zahlreich auf, greifen

jedoch jeweils nur auf kleine Datenmengen einer hohen Detaillierungsstufe zu. Die

61

62

63

64 65

Eine iiberblicksartige Abgrenzung der Betriebsarten Stapel- und Dialogverarbeitung findet sich z.B. in Gabriel (1997), S. 63. Vgl. Dadam (1996), S. 3. Vgl. Hansen (1996), S. 202. Vgl. Hansen (1996), S. 188 und 207ff. V gl. Kemper/Eickler (1997), S. 458; Chaudhuri/Dayal (1997), S. 65; Edelstein (1997), S. 33.


Daten, die bei einer solchen Operation gelesen oder geschrieben werden mtissen, sind

dabei gut tiber eindimensionale Identifikationskriterien, wie z.B. Schltisselfelder in

einer Tabelle, zu identifizieren.66 Typische Vertreter von OLTP-Anweisungen an Da

tenbanken sind etwa sogenannte Debit-Credit-Transaktionen, die Buchungsvorgange

durchflihren.67

Trotz des angesprochenen Trends zur Verwendung betrieblicher Standardanwendungs

software wird ein konsistenter und unternehmensweit integrierter Datenbestand der

operativen Systeme im Unternehmen nicht in allen Fallen vorliegen. Die Grtinde flir

die verbleibenden Heterogenitaten sind vielfaltig. Viele Produkte dienen, entsprechend

der herkommlichen, funktionsorientierten Unternehmensgliederung, der Untersttitzung

von Teilbereichen, etwa von Vertrieb, Rechnungswesen oder Beschaffung, und verfti

gen tiber jeweils eigene Datenbasen, so daB funktionsbezogene "Dateninseln" entste

hen.68 Selbst bei der flachendeckenden Einflihrung einer modernen betrieblichen Stan

dardanwendungssoftware, die aile Funktionsbereiche abdeckt und bei durchgangiger

Einflihrung einen hohen Grad an Datenintegration im Unternehmen verspricht, er

scheint es zweifelhaft, ob ein wirklich konsistent integriertes Datenmodell mit homo

genen Datenbestanden vorliegt. Der modulare Aufbau der gangigen Programmpakete

begtinstigt zudem die isolierte Verwendung nur einzelner, wiederum funktionsbezoge

ner Teilsysteme und die schrittweise Einflihrung des Gesamtsystems tiber einen lange

ren Zeitraum hinweg.69

Insgesamt ist also erkennbar, daB mit dem Konzept des Datenbanksystems zwar Tech

niken verfligbar sind, mit denen die Datenbestande unternehmensweit zentralisiert

werden konnen. Die praktische Umsetzung ist jedoch derzeit nicht so weit fortge

schritten, daB weitgehend integrierte Datenbestande zu erwarten sind. Vielmehr sind

haufig Insellosungen vorhanden, die Teildatenbestande in unterschiedlichen Daten

banksystemen oder auch in Dateistrukturen verwalten. Dehnt man diese Betrachtung

tiber das einzelne Unternehmen hinweg aus, so ist ein noch geringerer Datenintegrati

onsgrad erkennbar. Es lassen sich beispielsweise in Konzernstrukturen, die aus dem

ZusammenschluB zuvor eigenstandiger Unternehmen entstanden sind, vielfach weiter

hin eigenstandige Informationssysteme finden, die auch hinsichtlich der Datenbestande

66

67

68

69

Vgl. Eckerson (1994), S. 6; Meyer/Cannon (1998), S. 22f. Vgl. Gray/Reuter (1993), S. 8ff. Vgl. Scheer (1997). S. 7. Vgl. Hansen (1996). S. 188.


nicht mit den verbundenen Unternehmen koordiniert werden. Daher konnen bei einer

Gesamtbetrachtung dieser Einzelsysteme erhebliche Redundanzen erwartet werden, die

eine Gesamtkonsistenz dieser Daten als ein auBerst schlecht erreichbares Ziel erschei

nen lassen. Eine Zusammenfiihrung der Informationssysteme der Konzernunternehmen

setzt dagegen erhebliche Eingriffe in die bestehende Anwendungsarchitektur voraus,

ohne daB fiir die herkommlichen operativen Arbeitsablaufe ein Nutzen zu erwarten ist,

der ein solches Projekt rechtfertigen konnte.

2.1.2 Nutzenaspekte transaktionsorientierter Informationssysteme im

Unternehmen

Informationssysteme zur Unterstiitzung der operativen, leistungserstellenden Prozesse

sind wohl in praktisch allen Unternehmen in unterschiedlichen Auspragungen anzu

treffen. Sie automatisieren standardisierte Arbeitsvorgange und k6nnen Nutzeffekte

erzielen, die sich ursachlich auf die 6konomische Effizienz der elektronischen Infor

mationsverarbeitung zuriickfiihren lassen.?o Der Einsatz operativer Systeme zielt zu

nachst auf die Rationalisierung der standardisierten administrativen Ablaufe, die durch

den Anfall groBer Datenmengen charakterisiert sind. Rationalisierungsnutzen entsteht

hier durch Kostensenkung und Entlastung des Personals von einfachen Routineaufga

ben.?! Damit einher geht auch die Verkiirzung der Durchlaufzeiten von ProzessenJ2

Auch im Faile dispositiver Aufgaben lassen sich Rationalisierungseffekte erzielen,

wenn durch das Informationssystem Entscheidungen vorgeschlagen oder vorgenom

men werden, die denen des Menschen zumindest gleichwertig sind. Auch hier ist eine

Entlastung von Routineaufgaben erkennbar, zudem werden automatisierte Ablaufe

weniger durch menschliche Eingriffe unterbrochen und k6nnen so im Idealfall fliissi

ger ablaufenJ3

70

7!

72

73

Vgl. Schumann (1992), S. 71. Vgl. Mertens (I 997a). S. 11. Schumann (1992). S. 71ff.. unterscheidet hier Kostenanderungen und Produktivitatsanderungen. V gl. Mertens (1997a). S. 12.


Mit dem erzielten technischen Fortschritt riicken weitere Nutzeffekte in den Vorder

grund, die sich durch Computeruntersttitzung beobachten lassen.74 Als bedeutsam

sollen hier tiber die Rationalisierungseffekte hinaus genannt werden:75

• brei teres, leichter zugangliches Informationsangebot,

• flexiblere Moglichkeiten zur Informationsverkntipfung,

• Beschleunigung der Informationsfltisse,

• Verwirklichung moderner, datenintensiver betriebswirtschaftlicher Konzeptionen

wie z.B. neuerer Kostenrechnungsverfahren,

• Moglichkeit ganzheitlicher Informationsfltisse tiber Abteilungsgrenzen hinweg,

• Moglichkeit zur Datenversorgung von Planungs- und Kontrollsystemen,

• vorgangsbezogene Informationsfltisse.

Uber die Aspekte der Kostensenkung sowie der ProzeB- und Ressourcenokonornie

hinaus konnen Informationssysteme noch in anderer Hinsicht zur Erftillung der Unter

nehmensziele beitragen. So kann der gezieite Einsatz moderner Anwendungssysteme

auch einen Beitrag zur Starkung der strategischen Position des Unternehmens leisten.

Dies ist etwa dann der Fall, wenn die Anwendungssysteme das Generieren zusatzlicher

Leistungen ermoglichen, die der Verbesserung der Kundenbindung oder auch der

ErschlieBung neuer Geschaftsfelder dienen konnen.76

Wesentlich erscheint, daB sich die genannten Nutzeffekte durch die Integration der

Informationssysteme verstarken lassen. Eine horizontale Integration im Rahmen der

operativen Systeme reprasentiert die Verkntipfung der funktionsbezogenen Informati

onssysteme, so daB durchgangige Informationsstrome entstehen, die dem MaterialfluB

und den Leistungserstellungsprozessen entsprechen.77 Vertikale Integration erlaubt

zusatzlich das Bereitstellen von Daten aus den operativen Systemen im Unternehmen

74

75

76

77

Eine breite Darstellung der Nutzeffekte der Informationsverarbeitung enthiilt Schumann (1992), S.71ff. Vgl. Hesse (1995), S. 63; Mertens (1993), Sp. 417f. Weitere Beispie1e beschreibt Mertens (I 997a), S. 16f. Vgl. Scheer (1997), S. 8.


fUr analyseorientierte Informationssysteme.78 Diese Datenversorgung ist das zentrale

Thema der vorliegenden Arbeit.

Datenbanksystemen kommt durch die bereits genannten, konzeptbedingt integrations

fOrdernden Wirkungen eine besondere Bedeutung als technische Basis fUr die Daten

speicherung in diesen Systemen zu. Sie dienen auch fUr moderne Standard

anwendungssoftware wie z.B. SAP R/3 als Datenhaltungskomponente.

2.1.3 Vorgehensmodelle zur Entwicklung von datenbankbasierten

Informationssystemen

Dem erfolgreichen Einsatz eines Datenbanksystems im Unternehmen geht der Ent

wicklungsprozeB voraus, innerhalb des sen auf der Basis eines kommerziellen Daten

bankmanagementsystems eine Software zur Losung einer gegebenen Problemstellung

entsteht. Als auf die Entwicklung von datenbankorientierten Anwendungen fokussierte

spezielle Auspragung eines allgemeinen Software-Engineering-Ansatzes ("Data Engi

neering"79) konnen hier verschiedene Prinzipien und Methoden angewandt werden, die

im Software-Engineering seit geraumer Zeit wissenschaftlich diskutiert werden.80 1m

Mittelpunkt einer solchen datenorientierten Vorgehensweise steht der Aufbau eines

globalen Datenmodells.81 Wesentlich fUr eine erfolgreiche Entwicklung erscheint die

Beachtung eines Vorgehensmodells, das dem EntwicklungsprozeB einen festgelegten

organisatorischen Rahmen fUr eine strukturierte und systematische Vorgehensweise

gibt.

Hier sind zwei wesentliche Richtungen zu unterscheiden, die im folgenden skizziert

werden und mit einer Phasenorientierung einerseits und einem iterativen Vorgehen

andererseits sehr unterschiedliche Entwicklungsparadigmen verfolgen. Andere

Schwerpunkte im Rahmen der Entwicklung und EinfUhrung eines Informationssystems

78

79 80

81

Neben der beschriebenen Gliederung nach der Integrationsrichtung unterscheidet etwa Mertens drei weitere Dimensionen des Integrationsbegriffs: Den Integrationsgegenstand (Daten. Funktionen, Prozesse, Methoden, Programme), die Integrationsreichweite (in einem Bereich, innerbetrieblich, zwischenbetrieblich) sowie den Automationsgrad der Verkettung der Teilsysteme (teil- oder vollautomatisch). V gl. Mertens (I 997a), S. Iff. Hier erfolgt im wesentlichen eine Konzentration auf die Datenintegration, die tibrigen Aspekte und Dimensionen werden nicht weiter betrachtet. Gabriel/Rohrs (1995), S. 36. Vgl. auch Vetter (1990), S. 386. V gl. z.B. Balzert (1982), S. 27ff.; Gabriel (1990); Balzert (1996). Vgl. Vetter (1993), S. 26ff.


sind zu setzen, wenn ein standardisiertes Softwareprodukt eingefUhrt werden solI. Hier

ist der ModellierungsprozeB dahingehend abzuandern, daB die Organisation des Unter

nehmens nicht nur analysiert werden muB, sondern auch mit den in der Software impli

zit enthaltenen Annahmen tiber Strukturen, Funktionen und Prozesse in Ubereinstim

mung zu bringen iSt.82 Dieses auch als "Customizing" bezeichnete Vorgehen kann

entweder durch eine Anpassung der in der Software abgebildeten Strukturen an den

konkreten Anwendungsfall oder aber durch Veranderungen im Unternehmen realisiert

werden.

- Phasenorientierte Konzepte

Phasenorientierte Konzepte basieren auf der Vorstellung, daB ein Software-Projekt von

der ersten Idee bis zur Inbetriebnahme und Nutzung des Endproduktes eine Reihe von

Phasen in einer festen, sequentiellen, als Lebenszyklus (Software-Life-Cycle) bezeich

neten Reihenfolge durchlauft. 83 In der Literatur finden sich zahlreiche Auspragungen

von Modellen, die sich an einem solchen Phasenkonzept orientieren.84 Die praktische

Bedeutung dieser Modelle zeigt sich darin, daB bisher die meisten groBen Software

entwicklungsprojekte anhand eines Phasenkonzepts durchgeftihrt werden.85 Vielfach

beschrieben und auch in der Anwendung weit verbreitet sind die unterschiedlichen

Varianten des Wasserfallmodells.86 Wie durch diese Bezeichnung suggeriert, ,,fallen"

die Ergebnisse einer Phase in die nachste Phase, wobei Rtickkopplungen zu vorherge

henden Phasen nur in sehr begrenztem MaBe vorgesehen sind, da Uberarbeitungen

tiber mehrere Stufen hinweg zu stark ansteigenden Kosten fUr die Fehlerbeseitigung

fUhren konnen.87 Abbildung 4 zeigt ein solches Wasserfallmodell mit einer der in der

deutschsprachigen Literatur gangigen Bezeichnungssystematiken fUr die Phasen.

82

83

84

85

86

87

Vgl. z.B. Mertens et al. (1998), S. 168. Vgl. zum Software-Life-Cycle z.B. Fairley (1985), S. 37ff.; Sommerville (1987), S. 3ff.; Pomberger (1987), S. 63f. V gl. Hildebrand (1990), S. 57 und die dort genannten Quellen. Vgl. Budde et al. (1992), S. 24, sowie Balzert (1998), S. 101, der besonders die Bedeutung des Wasserfallmodells hervorhebt. Vgl. zum Wasserfallmodell z.B. Boehm (1986), S. 30ff. Eine zusammenfassende Darstellung enthiilt Balzert (1998), S. 99ff. V gl. Boehm (1986), S. 34f.

28

Planungs· phase

... 1 Definitions· \.. phase

... 1

\ ...... ,- --

Entwurfs· phase

... 1 , ,

Operative Informationssysteme

Implemen· tie rungs·

phase

... 1 , Abnahme· und

Einfiihrungs· phase

Abbildung 4: Wasserfallmode1l88

Eine Erweiterung des Wasserfallmodells stellt das V-Modell89 dar, das mit der Verifi

kation und Vaiidation90 verstlirkt auch Aspekte der Qualitatssicherung in das Phasen

modell integriert und die abstrakten Konzepte des Wasserfallmodells um konkretere,

praxisbezogene Anweisungen erganzt.91 Es gilt als derzeit insbesondere in der Praxis

weitverbreitetes Konzept, das sowohl in der Offentlichen Verwaltung als auch in vielen

Unternehmen eingesetzt wird.92 Neuerdings soil es zu einem Systembereitstellungs

standard ausgebaut werden, der neben der Softwareentwicklung auch die Konfigurati

on der Hardware und ein verbessertes Projektmanagement umfaBt.93 Dariiber hinaus ist

88

89

90

91

92 93

In Anlehnung an Balzert (I 992b ), s. 30. Der Begriff "V-Modell" ist urspriinglich die Kurzform fUr "Vorgehensmodell" (vgl. Versteegen (1994), S. 162), er wirdjedoch in den im folgenden genannten Quellen zu diesem Konzept eher als Eigenname verwendet. "Unter Verifikation wird die Uberpriifung der Ubereinstimmung zwischen einem Software· Produkt und seiner Spezifikation verstanden. Unter Validation wird die Eignung bzw. der Wert eines Produktes bezogen auf seinen Einsatzzweck verstanden." Balzert (1998), S. 101. Zum V-Modell vgl. Versteegen (1996), S.140ff. ; Bundesministerium des Inneren (1997); Balzert (1998), S. 101ff.; Hansen (1996), S. 142ff. Vgl. Hansen (1996), S. 142; Balzert (1998), S. 103. Vgl. Versteegen (1996), S. 140f.


mit der expliziten Beriicksichtigung von Anwender-Riickkopplungen eine stiirkere

Einbindung des Benutzers als bei den Wasserfall-Modellen erkennbar.94

Nimmt man speziell Bezug auf die Entwicklung eines Datenbanksystems, so lassen

sich diese Modelle entsprechend anpassen und zu einem Data Engineering

Phasenmodell erweitern.95 Hier wie in anderen Phasenmodellen wird in mehreren

Schritten durch Abstraktion von der vielfaltigen Realitat auf die problernrelevanten

Sachverhalte ein Informations-, Funktions- und Kommunikationsstrukturmodell gebil

det. Diese abstrakten Modelle werden in den weiteren Schritten fUr ein - entsprechend

dem Problemumfeld ausgewahltes - Datenbanksystem in Systemkonzepten konkreti

siert, und zwar in einer Gesamtsicht, in benutzer- oder benutzergruppenspezifischen

Sichten mit den jeweils relevanten Teilmodellen sowie mit dem physischen Entwurf in

einer weiteren, implementierungsabhangigen Sicht.96 Die abschlieBenden Phasen die

nen dann der Implementierung und Integration des neuen Systems in das Urnfeld sowie

schlieBlich der Wartung und Pflege des Systems.97

- Iterative KODzepte

Der sequentielle Charakter der oben dargestellten phasenorientierten Vorgehensmo

delle ist vielfach Gegenstand von Kritik. So wird unter anderem bemangelt, daB zu

wenig Interaktion zwischen dem Softwareentwickler und dem spateren Anwender bzw.

Auftraggeber stattfindet und daB ein linearer EntwicklungsprozeB Problemstellungen

nicht gerecht wird, die sich im Projektverlauf andern oder auch im vorhinein nicht

detailliert beschrieben werden konnen.98

Daher werden auch iterative Konzepte diskutiert, die von der sequentiellen Vorge

hensweise absehen und damit das mehrfache Durchlaufen einzelner Phasen ermogli

chen. Auch diese Konzepte sind in der Literatur in unterschiedlichen Auspragungen zu

finden und werden im folgenden iiberblicksartig skizziert.99

94

95

96

97

98

99

Vgl. dazu insbesondere Versteegen (1994) und Riihling (1996). Vgl. GabrieVRohrs (1995), S. 35f. Vgl. z.B. Conrad (1997), S. 37. Vgl. Gabriel/Rohrs (1995), S. 36ff. Ahnliche Modelle beschreiben z.B. Barker (1990), Kapitel 2ff.; KemperlEickler (1997), S. 29ff.; LangILockemann (1995), S. 292ff., und ElmasrilNavathe (1994). S. 40f. Vgl. zur Kritik an den Phasenmodellen z.B. Pomberger (1990), S. 224f., und Balzer! (1998), S.114. Die Auswahl und die hier verwendete Terminologie orientieren sich an Balzer! (1998), S.114ff.


Fur Entwicklungsprojekte, die sich auf datenbankbasierte Informationssysteme bezie

hen, erscheint die Nutzung solcher iterativer Vorgehensmodelle ebenfalls interessant.

Viele Aufgaben, die mit solchen Systemen untersttitzt werden sollen, sind dadurch

charakterisiert, daB der Aufgabentrager erst mit dem Erkennen der MCiglichkeiten, die

ihm die Software erCiffnet, seine Anspruche definieren kann und diese mit zunehmen

der Erfahrung mit dem Informationssystem auch ausweitet. Daher erscheint es schwie

rig, diese Systeme ex ante in voller Funktionsbreite und -tiefe zu modellieren. Statt

dessen bietet es sich an, eine evolutionare Vorgehensweise zu verfolgen, die den zu

nehmenden Erfahrungen der Benutzer mit der Software und den sich wandelnden

Anforderungen gerecht wird. Trotzdem sollte auch bei iterativen Vorgehenskonzepten

nicht auf eine systematische Vorgehensweise verzichtet werden, so daB sich innerhalb

der Entwicklungszyklen doch eine Orientierung an den Phasenmodellen empfiehlt.

Dies erscheint insbesondere in bezug auf die Datenmodellierung geboten, urn hier zu

konsistenten Sichtweisen zu gelangen.

Bei einer Vorgehensweise anhand eines Prototypen-Modells (Prototyping) wird zu

nachst ein Software-Muster erstellt, das ausgewahlte Eigenschaften des Zielproduktes

haben soIl. Dieses dient als Diskussionsbasis, z.B. zur endgtiltigen Festlegung der

Anforderungen an das Zielprodukt und als Versuchstrager zur Sammlung praktischer

Erfahrungen im relevanten Problemumfeld.lOo Je nach Verwendungszweck lassen sich

unterschiedliche Arten von Prototypen unterscheiden. 101 Neben solchen zu Analyse

zwecken im Rahmen der Entwicklung (Prototypen i.e.S. und Labormuster) sind insbe

sondere Demonstrationsprototypen und Pilotsysteme von Interesse. Demonstrations

prototypen dienen der Akquisition von Entwicklungsauftragen, indem gezeigt wird,

wie ein Produkt fUr die entsprechende Aufgabenstellung aussehen kCinnte. Sie werden

schnell erstellt und dienen nicht als relevanter Teil einer spateren Produktentwicklung.

Pilotsysteme dagegen sollen yom Anwender eingesetzt und auf der Basis entstehender

Erfahrungen in Zyklen weiterentwickelt werden.

Dem Pilotsystem-Konzept sehr ahnlich ist eine evolutionare bzw. inkrementelle Vor

gehensweise, bei der gleichfalls zunachst Kernsysteme entwickelt und in Betrieb ge

nommen werden. Anhand der damit gemachten Erfahrungen kann die Anforderungsde-

100

101 V gl. Sommerville (1987), S. 40f. Vgl. Kieback et al.(1992), S. 67f.; Budde et al. (1992).


finition erganzt und das Softwareprodukt in neuen Versionen entsprechend erweitert

werden. I02

Ziele, Alternativen und Randbedingungen identifizieren (fOr jedes Teilprodukt)

schrittweises. __ -+-__ .Vorgehen

Evaluierung der Alternativen, Identifizierung und Uber

windung der Risiken

Einverstandnis liber nachsten Zyklus herstellen, Uberprlif~u~n~gL-__ +-____ +-____ 4-__ ~ ____ ~~ ____ -4~ __ ~ ____ ~~ ____ ~r-__ _ (Review)

Planung der nachsten Phasen

Entwicklung und Verifikation des

Produkts der nachsten Generation

Abbildung 5: Spiralmodell 103

Beim sogenannten Spiralmodelll o4 wird das evolutioniire Konzept dahingehend erwei

tert, daB jeder Innovationszyklus wiederum als eigenstandiges Entwicklungsprojekt

gesehen werden kann, das zunachst evaluiert und dann anhand eines Vorgehensmo

dells umgesetzt wird. Damit lassen sich die Entscheidungen hinsichtlich der weiteren

102

103

104

V gl. Balzert (1998), S. 120ff. In Anlehnung an Balzert (1998), S. 130. V gl. zum Spiralmodell z.B. Boehm (1988), S. 6lff.; Balzert (1998), S. 129ff.


Vorgehensweise periodisch iiberprUfen und gegebenenfalls modifizieren. Die grundle

gende Struktur dieses Modells ist in Abbildung 5 dargestellt.

Es erscheint als gut geeignet fiir datenbankbasierte Entwicklungsprojekte, da es auch

innerhalb eines Konzepts mit evolutionarem Charakter die methodische Basis fiir ein

Database-Engineering und eine systematische Datenmodellierung liefert.

2.2 Datenmodelle und Repriisentationsformen

Die im vorhergehenden Abschnitt beschriebenenen Vorgehensmodelle dienen als

methodische Grundlage zur Entwicklung eines datenbankbasierten Informationssy

stems. Hier wird in ersten Schritten zunachst ein Modell aufgebaut. Diese Vorgehens

weise entspricht dem aus dem allgemeinen Software-Engineering bewahrten Vorgehen

und dient der genauen und sorgfliltigen Strukturierung des abzubildenden Problems.

Gleichzeitig wird mit einer prlizisen Modellierung auch eine gute Dokumentation

gewonnen, die in Data Dictionaries/Repositories einflieBen kann und der spateren

Verwendung im Data Warehouse dient.

2.2.1 Datenmodell

Eine Voraussetzung flir den erfolgreichen Einsatz eines Informationssystems besteht in

der sorgfaltigen Strukturierung und Beschreibung des konkreten Anwendungsfalles. 105

Dazu dienen im'Rahmen der oben beschriebenen sequentiellen Vorgehensmethoden

die frUhen Phasen. Auch die iterativen Vorgehensweisen benotigen in den einzelnen

Zyklen Planungs- und Problemstrukturierungsphasen. Gerade hier erscheint eine sy

stematische Beschreibung der Problemstrukturen anhand von Modellen wichtig, urn

die Erweiterungen, die sich bei den wiederholten Durchlaufen ergeben, gut in das

Konzept integrieren zu konnen.

Bei einer datenorientierten Vorgehensweise werden in erster Linie die Datenobjekte

sowie ihre Beziehungen analysiert und in Form von Datenmodellen dargestellt. Zur

Annliherung an diesen Begriff wird zunachst allgemeiner beschrieben, was in diesem

Zusammenhang unter einem Modell zu verstehen ist und welche Voraussetzungen

vorliegen miissen, damit ein Modell seinen Zweck erfiillen kann.

105 Vgl. Gabriel/Rohrs (1995), S. 6.

Datenmodelle und Reprasentationsformen 33

Unter einem Modell wird in emer ersten Bestimmung eme vereinfachte problem

adaquate Abbildung eines Ausschnittes der Wirklichkeit verstanden. I06 Modelle sind in

nahezu allen wissenschaftlichen Fachgebieten und vielfach im taglichen Leben anzu

treffen. So ist etwa jede Landkarte ein Modell, in dem durch eine geeignete Symbolik

bestimmte natur- oder kulturgeographische Phanomene besonders hervorgehoben sind.

Die genaue Ausgestaltung des Modells, etwa die Auswahl der in die Karte aufzuneh

menden Realweltobjektklassen oder auch der AbbildungsmaBstab, ist yom verfolgten

Zweck abhangig. So wird etwa eine Wanderkarte andere Beobachtungen abbilden als

eine Karte, die der groBraumigen Orientierung von Autoreisenden dient. Allgemein

konnen damit durch unterschiedliche Auswahl der abgebildeten Gegenstande aus der

Realitat Modelle erzeugt werden, die, obwohl sie auf demselben Betrachtungsobjekt

basieren, nur sehr wenige gemeinsame Elemente aufweisen.

Ein wichtiger Gesichtspunkt an einem Modell ist also die Abstraktion, die gezielte

Auswahl der im Modell darzustellenden Elemente aus der vielgestaltigen Realitat. Dies

setzt jedoch eine vorherige Auseinandersetzung mit dem Zweck des Modells voraus,

da nur ein Zweckbezug eine Abstraktion ermoglicht. I07 Ein Modell kann damit nur im

Zusammenhang mit seinem Bezugsobjekt und dem Zweck, den es erfiillen soli, defi

niert werden. I08 Urn also z.B. Aussagen aus einem Organigramm herzuleiten, muB

demnach angegeben werden, daB es sich urn eine Darstellung der Organisationsstruk

tur eines bestimmten Unternehmens (Bezugsobjekt) handelt, die den Zweck verfolgt,

die Unter- bzw. Uberordnungsbeziehungen zwischen den verschiedenen Stellen und

Mitarbeitern des Unternehmens zu verdeutlichen. I09

Die Zusammenfiihrung der Begriffe Daten und Modell ermoglicht eine erste, allge

meine Definition. Ein Datenmodell wird verstanden als Beschreibung, die "keine

Wirklichkeit, sondern ein Wissen tiber die lebensweltliche Bedeutung (Semantik)

sowie tiber die maschinelle Reprasentation und Manipulation von Daten"IIO darstellt.

Der Zweck ist also mit der Beschreibung des Wissens tiber Daten festgelegt. Als Be

zugsobjekt ist ein Realitatsausschnitt mit den dort vorhandenen Informationen und

deren dynamischen Eigenschaften zu wahlen.

106

107

108

109

110

V gl. Busse von Colbe/LaBmann (1991), S.48; Heinrich/Roithmayr (1995), S. 353; ahnlich Heinrich (1993). S. 83. Vgl. Hars (1994), S. 7ff. Vgl. Grochla (1974), S. 22. Vgl. Hars (1994), S. 9. Wedekind (1997). S. 118.


Viele Autoren beschranken sich bei der Definition eines Datenmodells auf die Mog

lichkeit zur Abbildung struktureller Eigenschaften. 111 Neben diesen statischen Aspek

ten, mit deren Hilfe die Elemente des Bezugsobjektes abstrahiert sowie ihre Eigen

schaften und ihre Beziehungen untereinander betrachtet werden, muB ein Datenmodell

jedoch auch dynamische Aspekte beinhalten. Diese betreffen das Verhalten der be

trachteten Systeme, das durch einen Satz von Operatoren, die dem Umgang mit den

Systemen dienen, definiert wird. 112 Der dynamische Aspekt wird in der bereits zitierten

Definition ausgedriickt, in der auch die Manipulation der Daten Bestandteil des Da

tenmodells ist. Diese Auffassung von einem Modell wird von vielen Autoren erweitert,

indem sie ein Datenmodell als Kombination von drei Komponenten beschreiben. Ne

ben seinen statischen und dynamischen Eigenschaften stellt ein Datenmodell dariiber

hinaus eine Reihe von allgemeinen Integritatsbedingungen auf, die sicherstellen, daB

nur solche Daten in die Datenbank aufgenommen werden, die nach diesen Bedingun

gen zulassig sind. Auf diese Weise ist gewahrleistet, daB die gesamte Semantik an

spruchsvoller Anwendungen ausgedriickt werden kann. Die Integritatsbedingungen

dienen dabei haufig der Verkntipfung von statischen und dynamischen Eigenschaf

ten. 113

Diese Auffassung eines Datenmodells fiihrt zur umfassenden Definition von Brodie.

Nach Brodie ist ein Datenmodell eine Menge mathematisch wohldefinierter Konzepte,

die aile statischen und dynamischen Eigenschaften der Anwendungswelt erfassen

sollen, indem sowohl statische Eigenschaften wie Objekte, Eigenschaften von Objek

ten und Beziehungen zwischen Objekten, aber auch dynamische Eigenschaften wie

Operationen auf Objekten, Eigenschaften dieser Operationen und Beziehungen zwi

schen Operationen und Integritatsbedingungen tiber Objekte (statische Integritatsbe

dingungen) und tiber Operationen (dynamische Integritatsbedingungen) abgebildet

werden. 114 Diese ausfiihrliche Definition ist von vielen Autoren aufgegriffen wor

den.lls

III

112

113

114

lIS

So definiert Zehnder ein Datenmodell als "eine Struktursprache, welche sich zur Beschreibung von Datenbestanden eignet" (Zehnder (1989), S. 17). Ahnlich Heinrich (1993), S. 226, sowie Mertens et al. (1998), S. 66; Picot/Maier (1994), S. 115; Schwarze (1994), S. 162. Vgl. Hughes (1992), S. If.; Bertino/Martino (1993), S. 2. Vgl. Hughes (1992), S. 2; Brodie (1984), S. 23. Vgl. Brodie (1984), S. 20. Vgl. z.B. Date (1995), S.348; Heuer (1997), S. 129ff. Ahnlich auch Hughes (1992), S. If.; Dittrich/Scherrer (1993), S. 44; Hars (1994), S. 22f.; Codd (1982), S. III.


Es wird allgemein zwischen unterschiedlichen Formen der Datenmodellierung unter

schieden. Besteht das Ziel in einer moglichst verstandlichen Beschreibung der Struktu

ren ohne den konkreten Bezug zu einem Datenbanksystem, so wird von semantischen

Datenmodellen gesprochen. Logische Modelle dagegen dienen der Abbildung mit den

Strukturelementen, die von einem konkreten Datenbanksystem bereitgeste11t werden.

1m Sinne einer phasenweisen Entwicklung wird zunachst ein semantisches Modell

erstellt, das dann anschlieBend in ein (implementierbares) logisches Datenmodell trans

formiert wird. 116 Beide Formen der Datenmodellierung werden im folgenden betrach

tet.

2.2.2 Semantische Datenmodelle

1m Rahmen der Entwicklung operativer Informationssysteme wird die semantische

Datenmodellierung als fester Bestandteil des Gestaltungsprozesses angesehen. Sie

dient dazu, den abzudeckenden Problembereich aus der Sicht des Anwenders zu mo

dellieren, ohne auf Aspekte der spateren Implementierung einzugehen. ll7 Einer sorg

faltigen Modellierung in diesen frtihen Phasen des Entwicklungsprozesses kommt eine

groBe Bedeutung zu. Fehler, die sich aus einem unvollstandigen oder unsachgemaBen

Aufbau der Modelle ergeben, fiihren in den spateren Phasen zu dann gleichfalls un

sachgemaBen Entwurfsentscheidungen, deren Korrektur hohe Kosten verursachen

kann. II 8

Die Bezeichnung "semantisch" verdeutlicht hier zwei Funktionen dieser Datenmodel

Ie. Zum einen soli durch ein semantisches Datenmodell ein Begriffssystem entwickelt

werden, welches eine prazise und umfassende Abbildung des betrachteten Problembe

reichs ermoglicht (Semantik als Beziehung zur Realitat). Zum anderen so11 auch die

Bedeutung der Daten selbst, die innerhalb des Begriffssystems agieren, abgebildet

werden. 1 19 Dies sollte durch ein machtiges Modellierungskonzept untersttitzt werden,

urn spater den Abstand zwischen dem betrachteten Realitatsausschnitt und dem im

plementierten Datenmodell des Datenbanksystems so gering wie moglich zu halten. 120

116

117

118

119

120

V gl. z.B. KemperlEickler (1997), S. 20ff.; ElmasrilNavathe (1994), S. 39ff. V gl. z.B. KemperlEickler (1997), S. 27; Gabriel/Rohrs (1995), S. 104f. Vgl. Kemper/Eickler (1997), S. 27. V gl. Sinz (1990), S. 18. V gl. Bohnlein/Nittel/Dittrich (1990), S. 116.; Lockemann/Radermacher (1990), S. Sf.


Es werden in der Literatur verschiedene, unterschiedlich machtige semantische Da

tenmodelle diskutiert, die fUr verschiedene Anwendungsklassen vorgeschlagen wur

den. 121 Nahezu als Standardmodell hat sich jedoch das Entity-Relationship-Modell mit

seinen verschiedenen Weiterentwicklungen etabliert. 122

Grundlegende Modellelemente dieses Modells sind Gegenstandstypen (Entity-Types)

als Abstraktion einer Klasse von Realweltobjekten und Beziehungstypen

(Relationships), welche die Gegenstandstypen miteinander verkntipfen. Die Darstel

lung kann tiber eine verhaltnismaBig einfache grafische Notation erfolgen, die hier

nicht im einzelnen beschrieben werden sol1. 123 Beim Entity-Relationship-Modell han

delt es sich urn ein nicht sehr machtiges semantisches Datenmodel1. Gerade diese Ein

fachheit wird als Grund dafUr angesehen, daB es sich zur dominanten Modellierungs

methode ftir den Datenbankentwurf im praktischen Einsatz entwickelt hat. 124 Vielfach

dient es auch als methodische Basis in Softwarewerkzeugen zur rechnergestiitzten

Datenmodellierung.

Die Bestrebung, Datenbanksysteme zu entwicken, die auf semantischen Datenmodel

len aufbauen und deren umfassende Abbildungsmoglichkeiten mit Hilfe entsprechen

der Datenbeschreibungssprachen erfassen, ist bisher nicht umgesetzt worden. 125 Se

mantische Datenmodelle dienen dagegen eher als Strukturierungshilfe bei der Spezifi

zierung des Realweltausschnittes und mtissen anschlieBend in Modelle fUr das verwen

dete Datenbanksystem umgewandelt werden.

121 122

123

124

125

Einen Uberblick gibt Brodie (1984), S. 29-3S. Vgl. Maier (1996), S. 124; Batini/Ceri/Navathe (1992), S. 30. Das Entity-Relationship-Modell wurde urspriinglich in Chen (1976) beschrieben. Eine breitere Darstellung zu den Modellelementen und der grafischen Notation liefern z.B. Chen (1991), S. ISff.; Kemper/Eickler (1997), S. 33ff., und Elmasri/Navathe (1994), S. 42ff. Fiir das EntityRelationship-Modell sind zahlreiche Erweiterungen und Varianten entwickelt worden, die entweder die Ausdrucksmoglichkeiten zugunsten einer vereinfachten Beherrschbarkeit der Methode einschriinken oder umgekehrt zusiitzliche Ausdrucksmittel und Strukturelemente einfiihren. Rauh/Stickel (1997) beschreiben die Konzepte ausgewiihlter Varianten (S. 88ff.) und nennen zahlreiche Quellen (S. 108ff.). Eine weitere Darstellung, die auch alternative grafische Notationen beriicksichtigt, enthiilt Scheer (1997), S. 31 ff. Hesse (l99S), S. 120ff., stellt verschiedene Erweiterungen zusammen, welche die zuniichst fiir die statische Abbildung von Datenstrukturen gedachten Konstrukte urn Moglichkeiten zur Modellierung von Zeit- und Verhaltensaspekten erweitern. Vgl. EickerlSchiingel (1998), S. 84. Vgl. Date (I 99S), S. 347f.


2.2.3 Logische Datenmodelle

Ein logisches Datenmodell liefert den formalen Rahmen zur computergerechten Dar

stellung der im semantischen Datenmodell erfolgten Abstraktion relevanter Zusam

menhange aus der realen Welt. Dazu werden die Strukturen des semantischen Daten

modells durch die Anwendung von Transformationsregeln flir die Implementierung mit

einem konkreten Datenbanksystem aufbereitet. Der betrachtete Realitatsausschnitt

wird jetzt also nicht mehr eher verbal, sondern orientiert an den Konstrukten des zu

verwendenden Datenbanksystems abgebildet. 126 Die Form der Abbildung ist abhangig

vom Datenmodell des zum Einsatz kommenden Datenbanksystems.

Aufgrund der iiberragenden Bedeutung des relationalen Datenmodells wird dieses im

folgenden naher beschrieben; ein weiterer Abschnitt widmet sich kurz den anderen

gangigen logischen Datenmodellen.

2.2.3.1 Relationale Modelle

Das relationale Datenmodell hat sich seit den siebziger lahren zu dem bedeutendsten

Datenmodell entwickelt. Auf diesem basieren nahezu aile seitdem entwickelten kom

merziellen Datenbanksysteme, und es besitzt den Rang eines De-Facto-Standards. 127

Datenbanksysteme, die nicht auf dem relationalen Modell basieren, haben zumindest

flir operative Anwendungen nur eine geringe Marktbedeutung. 128 Auch die Datenbank

forschung bezieht sich zu groBen Teilen auf Fragestellungen, die einen direkten oder

indirekten Bezug zum Relationenmodell haben. 129

Das Relationenmodell wurde 1970 von Codd vorgestellt. 130 Es basiert im wesentlichen

auf zwei Strukturelementen, den Relationen und den Domanen. 131 Das Konzept der

126

127

128

129

130

131

Eine solche Darstellung eines konkreten Realitatsausschnittes mit Hilfe der Konstrukte eines logischen Datenmodells wird auch als konzeptionelles Modell bezeichnet, wobei diese Begriffe auch als Synonyme verwendet werden konnen. V gl. Gabriel/Rohrs (1995), S. 106. Vgl. Vossen (1994), S. 123; Hansen (1996), S. 947; Bartsch-Sporl (1989), S. 9. V gl. Heuer (1997), S. 5 I. Hansen (1996), S. 965ff., nennt Marktdaten fUr relationale und andere Datenbankmanagementsysteme sowie die Marktanteile der graBen Hersteller. V gl. Date (1995), S. 21 f. Die erste Veroffentlichung findet sich in dem heute als klassisch bezeichneten (vgl. Date (1995), S. 56) Aufsatz "A Relational Model of Data for Large Shared Data Banks" (Codd (1970)). Eine Bibliografie der Veroffentlichungen von Codd zu diesem Thema findet sich in Codd (1990), S. 505ff. Date (1995), S. 100ff., enthaIt eine ausfiihrliche Quellenliste. Neben den bereits genannten Quellen enthalten z.B. Lang/Lockemann (1995), S.43ff., und Kemper/Eickler (1997), S. 59ff., ausfiihrliche Erorterungen dieser Konzepte.


Domline entsprieht weitgehend einem benutzerdefinierten Datentyp. Eine Domane

besteht aus der Menge aller zullissigen Werte, die wiederum die kleinste semantisehe

Dateneinheit bilden.132

Eine Relation besteht aus einer Menge von Attributen, denen jeweils eine Domline

zugeordnet ist, sowie einer Menge von Tupeln (Datenslitzen), die fiir jedes Attribut

einen Wert beinhalten. In der iibliehen tabellenformigen Darstellungsforml33 reprlisen

tieren die Spalten die Attribute, die einzelnen Datenslitze sind zeilenweise in der Ta

belle eingetragen. 134

An den Relationsbegriff konnen vier eharakteristisehe Eigensehaften gekniipft werden,

die sieh aus der Definition einer Relation als Menge von Tupeln, die wiederum Men

gen von Attribut-lDomanenpaaren sind, ergeben: 135

• Es existieren keine identisehen Tupel,

• die Tupel sind in der Relation nieht geordnet,

• die Attribute sind in der Relation nieht geordnet,

• alle Attributwerte sind atomar.

1st die zuletzt genannte Eigensehaft, die sieh aus dem genannten Domlinenkonzept

ergibt, erftillt, wird die Relation als in erster Normalform normalisiert bezeiehnet. 136

Zur Identifizierung von Tupeln in einer Relation dienen SehlUssel. Diese werden aus

einer (ein- oder mehrwectigen) Menge von Attributen gebildet, die fiir ein Tupel ein

deutig ist und der Minimaleigensehaft l37 gentigt. Der aus den aufgrund dieser Eigen-

132

133

134

135

136

137

Vgl. Date (1995), S. 81. Werte wei sen die Eigenschaft auf, atomar zu sein, d.h. sie lassen sich nicht weiter in kleinere Einheiten zerlegen, ohne daB der Bedeutungsgehait verlorengeht. Date (1995), S. 88f., weist darauf hin, daB die Begriffe Relation und Tabelle nicht synonym verwendet werden sollten, da es sich bei einer Tabelle nur urn eine eingiingige Darstellungsform fur das abstrakte Objekt "Relation" handele, jedoch Eigenschaften suggeriere, die fUr Relationen nicht zutreffen. Formale Definitionen des Relationsbegriffs finden sich z.B. in Date (1995), S. 86f.; GabriellRohrs (1995), S. 120. Vgl. z.B. Codd (1970), S. 379; Gabriel/Rohrs (1995), S. 120f.; Hughes (1992), S. 14. Vgl. z.B. Date (1995), S. 93. Die Minimaleigenschaft des Schliissels bedeutet, daB ein Entfemen eines Attributes aus der Attributkombination den Verlust der Schliisseleigenschaft bewirkt. Vgl. z.B. Lang/Lockemann (1995), S. 314f., und KemperlEickler (1997), S. 145f. Hiiufig werden kunstliche Schliissel verwendet, d.h. Attribute, die nur zu Identifikationszwecken dienen.


schaften potentiell in Frage kommenden Attributen ausgewahlte Schltissel wird Pri

marschltissel genannt. 138

Relationenschemata, die lediglich den oben genannten Eigenschaften entsprechen, sich

also in erster Normalform befinden, eignen sich noch nicht zur problemadaquaten

Abbildung von Sachverhalten, wie sie in betriebswirtschaftlich-operativen Zusammen

hangen auftreten. So ist in derartigen Relationen em hohes MaB an

(konsistenzgefahrdender) Redundanz erkennbar. Weiterhin treten Abhangigkeiten

zwischen aus semantischer Sicht voneinander unabhangigen Datenobjekten auf, die zu

Schwierigkeiten (Anomalien) bei der Einftigung, Anderung und Loschung von Daten

satzen ftihren.139 Abhilfe schafft die Anwendung einer Theorie zur redundanzvermei

denden Verteilung der Attribute auf verschiedene Relationen, der Normalisierung. 14o

Das Ziel liegt in der Schaffung eines redundanzarmen Modells, das einer hoheren

Normalform entspricht (meist 3. Normalform oder Boyce-Codd-NormalformI41 ). Da

bei besteht die Tendenz zur Erzeugung immer weiterer Tabellen, da durch die Norma

lisierung versteckte Entity-Typen erkannt werden. Zur Nutzung der in solcherart zer

legten Relationen hinterlegten Daten ist ein SyntheseprozeB erforderlich. 142 In der

Praxis empfiehlt sich dann meist eine kontrollierte und dokumentierte Denormalisie

rung, die zwar wieder zu erhohter Redundanz ftihrt, jedoch Geschwindigkeitsvorteile

bei der Nutzung des Datenbanksystems bringen kann, weil semantisch zusammengeho

rige Daten bei einer Abfrage nicht aus ganz so vielen Tupeln in unterschiedlichen

Tabellen zusammengesetzt werden mtissen. 143

Entsprechend der dargestellten grundsatzlichen Definition emes Datenmodells sind

auch Integritatsregeln ein wesentlicher Bestandteil des Relationenmodells. Eine erste

Integritatsregel wurde oben im Rahmen der Beschreibung des Schltisselkonzepts be

reits angesprochen. Primarschltisseln kommt eine wichtige Bedeutung zu. Sie sind

notwendig, urn ein Tupel in einer Relation eindeutig adressieren zu konnen. 144 Tupel,

138 139 140

141 142 143 144

Vgl. z.B. Date (1995), S. 115f. V gl. MayrlDittrichlLockemann (1987), S. 526ff. Beschreibungen des Normalisierungsprozesses finden sich z.B. bei Vetter (1990), S. 129ff.; Vetter (1991), S. 19lff., und KemperlEickler (1997), S. 151ff. Vgl. E1masriINavathe (1994), S. 416; KemperlEickler (1997), S. 163f. Vgl. Vetter (1990), S. 400f. Vgl. Jackson (1990), S. 165f.; Palffy (1991), S. 51; Roeing (1996), S. 19lf. Die Differenzierung zwischen Schliisselkandidaten (candidate keys) und Primarschliisse1n (primary keys) soli hier nicht naher verfo1gt werden. Die Unterschiede und deren Implikationen auf Fremdsch1iisse1 sind in Date (1995), S. 115ff., beschrieben.


deren Primarschliisselattribut keinen Wert aufweist, sind nicht zulassig, denn in einem

solchen Fall ginge nicht nur die eindeutige Adressierbarkeit in der Datenbank verloren,

auch der Bezug zu dem abgebildeten Objekt der Realwelt ware zweifelhaft, da es an

der eindeutigen Identifizierbarkeit mangelt. 145

Beziehungen zu Tupeln in weiteren Relationen werden gleichfalls tiber Schliissel dar

gestellt. Ein Primarschliissel, der in einer anderen Relation zur Darstellung von Bezie

hungen in Form eines Attributes erscheint, wird dort Fremdschliissel genannt. 146 Die

Regel der referentiellen Integritat des Relationenmodells besagt, daB es keine Werte

mit Fremdschliisseleigenschaft geben dart, die auf nicht vorhandene Primarschliissel

verweisen. 147 Zur Konkretisierung dieser Regel ist es notwendig zu definieren, welche

Operationen gestattet sind, wenn schreibend auf referenzierte Primarschltissel zuge

griffen werden solI. 148

Eine dritte Integritatsregel ergibt sich implizit aus dem bereits beschriebenen Doma

nenkonzept. Jedes Attribut einer Relation hat einer Domane anzugehi::iren. Der entspre

chende Wert eines Tupels muE aus der zugehi::irigen Domane entnommen sein.149 So

ergibt sich bei sorgfaltiger Definition der Domanen auch eine semantische Kontrolle

der Inhalte der Relationen.

Die bisherigen Eri::irterungen zum Relationenmodell beziehen sich auf strukturelle

Elemente und damit auf die statischen Eigenschaften des so erstellten Datenmodells.

Als letzte wesentliche Komponente ist der Operationenteil des relationalen Modells zu

betrachten, der die dynamischen Eigenschaften beschreibt. Die Operationen des rela

tionalen Modells sind mengenorientiert. Sie arbeiten nicht auf einzelnen Satzen, son

dem ki::innen mit ganzen Relationen umgehen. Auch die Ergebnisse sind also wieder -

eventuell einwertige - Mengen von Tupeln, namlich Relationen. 150

145

146 147 148

149 150

"In a relational database, we never record information about something we cannot identify." Date (1995), S. 125. Vgl. Wedekind (1991), S. 192. Vgl. z.B. Lang/Lockemann (1995), S. 81 f.; KemperlEickler (1997), S. 134ff. Fiir die Zugriffsformen "Update" und "Delete" kommen jeweils die kaskadierende Vorgehensweise, die die Tupel mit den Fremdschliisseln analog behandelt, sowie ein Verhindern des schreibenden Zugriffs im Faile vorhandener Fremdschliissel in Frage, vgl. KemperlEickler (1997), S. 135f. Vgl. Date (1995), S. 129f. Vgl. Gabriel/Rohrs (1995), S. 132; Date (1995), S. 141f.

Datenmodelle und Repriisentationsformen 41

Die Ansatze des Operationenteils des relationalen Modells basieren zumeist auf der

Relationenalgebra. 151 Eine Ergebnisrelation ergibt sich infolge von Mengenoperatio

nen auf den Relationen. Hier werden die herkommlichen Operatoren der Mengenlehre

verwendet, wobei Berticksichtigung findet, daB die Operanden Relationen sind und

damit spezifische Eigenschaften haben. 152 Erweiterungen dieser Algebra bestehen in

den relationentypischen Operationen Projektion, Verbund (Join), Selektion (Restrikti

on) sowie Division.

Die Projektion wahlt bestimmte Attribute einer Relation aus, die Selektion hingegen

sondert bestimmte Tupel aus einer Relation aus. Mit der Projektion werden also Spal

ten, mit der Selektion Zeilen einer Tabelle ausgewahlt. Der Verbund verkntipft zwei

Relationen tiber gemeinsame Attribute. Durch diese Operation werden Relationen,

zwischen denen durch Fremdschltissel ausgedrtickte Beziehungen existieren, zusam

mengefilhrt. Mit Hilfe der (seltener diskutierten) relationalen Division werden die

Tupel aus dem Dividenden ermittelt, die in einer definierten Spalte aile Werte der

einstelligen Divisor-Relation enthalten. 153

In einem Datenbanksystem werden die beschriebenen Elemente tiber eine Datenbank

sprache realisiert. Diese ist als Komponente der Kommunikationsschnittstelle des

Datenbanksystems ausgefilhrt. Altere Ansatze der Spezifikation von Datenbankspra

chen trennten zwischen Sprachkonstrukten zur Datendefinition einerseits und zur Da

tenmanipulation und -wiedergewinnung andererseits und spiegeln so Struktur- und

Operationenteil des Datenmodells wider. 154 Mit SQL existiert heute eine genormte l55

Standardsprache filr relation ale Datenbanksysteme, die diese Elemente sowie weitere

Befehle zur Steuerung eines Datenbanksystems enthalt. 156 Es handelt sich urn eine

mengenorientierte, deskriptive Sprache, die vom Benutzer direkt tiber die Kommuni

kationsschnittstelle angewendet werden kann, oder die durch Anwendungsprogramme

151

152

153

154

155

156

Alternativ kann auch ein Relationenkalklil verwendet werden, vgl. hierzu Hughes (1992), S. 133; Wedekind (1991), S. 227ff., sowie Date (1995), S. 185ff. Date (1995), S. 139, nennt die Operatoren Vereinigung, Durchschnitt, Differenz und Kartesisches Produkt. Ftir die deutschen Ubersetzungen der in dieser QueUe englischsprachigen Bezeichnungen vgl. z.B. Schwarze (1984), S. 48ff. Eine ausftihrliche Diskussion des Relationenkalktils und der Relationenalgebra sowie eine Bibliographie findet sich in Date (1995), Kapitel 6. Vgl. zur relationalen Division Date (1995), S. 155f., und LangiLockemann (1995), S.67f. V gl. CODASYL (1978), Martin (1988), S. 150. Einen Uberblick zur Normung der verschiedenen SQL-Versionen geben Teschke (1997), S. 378, und Melton (1998), S. l03ff. Eine Kategorisierung des Befehlssatzes nimmt Sttirner (1991), S. 207, vor.


genutzt wird, die auf das Datenbanksystem zugreifen. 157 Durch das Fortschreiben des

standardisierten Sprachumfangs wird SQL an die erweiterte Funktionalitat moderner

Datenbanksysteme angepaBt, wobei die Neuerungen zunehmend auch Konzepte der

Objektorientierung berucksichtigen. 158

Relationale Anfragesprachen wie SQL sind ungeachtet ihrer groBen Relevanz in heuti

gen Softwareprodukten auch Gegenstand kritischer Stimmen. Insbesondere werden

Mangel in der Strukturierbarkeit praktisch bedeutsamer Anfragen genannt. So wird

angefUhrt, daB Anfrageergebnisse probleminadaquat unstrukturiert ausgegeben wer

den, komplexe Strukturen in Anfragen nicht untersttitzt werden und Verbundoperatio

nen in Anfragen explizit formuliert werden miissen.159

2.2.3.2 Alternative Reprasentationsformen

Die heutige Dominanz des relationalen Datenmodells kann nicht damber hinwegtau

schen, daB in Wissenschaft und Praxis auch zahlreiche andere Modelle prasent sind.

Diese lassen sich in priirelationale Modelle, also in der Historie der Datenbankfor

schung vorgelagerte, und postrelationale Modelle, die Entwicklungen jiingeren Datums

sind, gliedern.

Nach wie vor von groBer Bedeutung sind Datenbanksysteme, die auf einem der alteren

Datenmodelle basieren und als Datenspeicher fUr die sogenannten Altsysteme dienen.

Daher diirfen diese bei einer Betrachtung von Aspekten der Beschaffung von Daten fUr

ein Data Warehouse nicht vernachlassigt werden.

Wichtige Vorlaufer des relationalen Modells sind die III ihrer Entwicklungshistorie

evolutioniir aus den herkommlichen Techniken der Datenverarbeitung und Dateiorga

nisation entwickelten hierarchischen und netzwerkartigen Datenmodelle. Diese wer

den, gemeinsam mit dem relationalen Modell, manchmal auch als "klassisch" bezeichnet. 160

157

158

159

160

Eine ausfiihrliche Beschreibung von SQL liefem z.B. Kleinschmidt/Rank (1997), S. 23ff.; Date (1990), S. 379ff.; DatelDarwen (1997), S. 79ff., sowie Bowman/Emerson/Damovsky (1996). Zum neuesten SQL-Standard SQL3 vgl. Melton (1996), S.666ff.; DatelDarwen (1997), S. 495ff., und Melton (1998), S. 120f. Zur Kritik an SQL vgl. Heuer (1997), S. 93ff.; Lang/Lockemann (1995), S.529f.; Date (1990), S. 329ff.; Warden (1990), S. 484ff.; Date (1993), S. 19ff. Letzterer weist auf die mangelnde Ubereinstimmung zwischen relationalen Operationen und entsprechenden SQL-Befehlen hin. Z.B. in Wedekind (1997), S. 119, aber auch schon in Stucky/Krieger (1990), S. 851, wird dieser Begriff verwendet.


Beziehungen zwischen den abgebildeten Objekten miissen hier anders als beim Rela

tionenmodell ausdriicklich definiert werden. 161 Sie sind lediglich in einer auf hierarchi

sche bzw. netzwerkartige Strukturen reduzierten Form darstellbar und damit nicht

immer problemadaquat. Durch die verhaltnismaBig einfache Struktur insbesondere des

hierarchischen Modells gibt es viele effiziente Verarbeitungsalgorithmen und die

Moglichkeit der sequentiellen Bearbeitung. 162 Dieser Vorteil ist jedoch angesichts

gestiegener Leistungsfahigkeit der Rechnersysteme und der auf neueren Modellent

wicklungen basierenden Datenbanksysteme nicht mehr von ausschlaggebender Be

deutung. Auch die durch kurzfristig wechselnde Informationsbediirfnisse gestiegenen

Anforderungen an die VerarbeitungsflexibiliUit konnen mit diesen Datenmodellen

nicht befriedigt werden.

Das hierarchische Datenmodell hat jedoch trotz der aus heutiger Sicht vorhandenen

Nachteile seine groBe Bedeutung als Basis fUr Datenbanksysteme bisher nicht verloren.

Insbesondere in groBen Unternehmen sind noch vielfach hierarchische Datenbanksy

sterne anzutreffen, die sehr groBe Datenmengen und Transaktionsvolumina verwalten

konnen. Hier ist absehbar, daB diese Systeme auch in Zukunft zunachst noch vorhan

den sein werden, da viele entsprechende Anwendungsprogramme vorliegen und eine

Umstellung auf modernere, z.B. relationale Systeme als teuer, langwierig und risiko

behaftet angesehen wird. 163

Am anderen Ende des Spektrums der eingesetzten Software ist erkennbar, daB Systeme

auf der Basis eines der postrelationalen Modelle zumindest fUr Spezialanwendungen

zunehmend an Bedeutung gewinnen. Die Vielfalt der Entwicklungen, die an Prototy

pen erforscht werden und teilweise auch als kommerzielle Produkte erhaltlich sind,

erschwert eine systematische Kategorisierung. Hier sind einerseits Konzepte erkenn

bar, die relationale Modelle erweitern, andererseits auch solche, die - wie z.B. die

objektorientierten Datenmodelle164 - auf Anregungen aus anderen Forschungsberei

chen basieren und daher nicht primlir auf relationalen Konzepten aufbauen.

161

162

163

164

V gl. Gabriel/Rohrs (1995), S. 135. Vgl. Gabriel/Rohrs (1995), S. ISS. V gl. StahlknechtiHasenkamp (1997), S. 211; Laudon/Laudon (1994), S. 255. Eine breite Darstellung zu objektorientierten Datenmodellen und Datenbanksystemen liefert z.E. Heuer (1997).


Die vielfaItigen Aktivitaten in der Forschung bezuglich neuerer Datenmodelle, die sich

z.B. in der graBen Zahl von Veroffentlichungen ausdrucken,165 soil ten allerdings nicht

verges sen lassen, daB Anwendungen des relationalen Modells nach wie vor marktbe

herrschend sind. 166 Zunehmend verschwimmen allerdings die Grenzen zwischen den

Systemklassen. So ist beispielsweise zu beobachten, daB Konzepte aus objektorien

tierten Datenmodellen auch in die marktbedeutenden relationalen Pradukte integriert

werden, so daB von hybriden oder objektrelationalen Modellen gesprachen werden

kann.

Die in den vorhergehenden Abschnitten beschriebenen Datenmodelle dienen als Kon

zept fUr den Aufbau eines konkreten datenbankbasierten Informationssystems, das auf

einem (kommerziellen) Datenbanksystem basiert. 1m folgenden Abschnitt sollen wich

tige Gesichtspunkte der Architektur von Datenbanksystemen beschrieben werden.

2.3 Architekturen und Komponenten

Zur Speicherung der Daten, die durch die oben dargestellten Modelle beschrieben

werden, bedient man sich gemeinhin kommerzieller Datenbanksysteme, die in einer

sehr graBen Bandbreite hinsichtlich der Leistungsfahigkeit und des Preises erhaltlich

sind und eine nicht unerhebliche Rolle im Gesamtmarkt fUr Software spielen.

In der Literatur wird der Begriff "Datenbanksystem" durchaus uneinheitlich verwen

det. Es besteht insbesondere Uneinigkeit dartiber, wieviele und welche Komponenten

eines betrieblichen Informationssystems zum Datenbanksystem zu zahlen sind. In einer

eher engen Definition umfaBt ein Datenbanksystem lediglich das Datenbankmanage

mentsystem als Kontrall- und Verwaltungsinstanz, die eigentliche Datenbank sowie

eine Kommunikationskomponente als alleinige Schnittstelle zur "Umwelt" des Daten

banksystems. 167

165

166 167

Ais Beispiel sei auf die umfangreichen Bibliografien zu objektorientierten Datenmodellen und Datenbanksystemen in Heuer (1997), S. 401 ff. und Kapitel 12, sowie in Kemper/Eickler (1997), S. 373f. verwiesen. Vgl. Kemper/Eickler (1997), S. 331. Vgl. Gabriel/Rohrs (1995), S. 189; Hansen (1996). S. 943; Schwarze (1994). S. 178ff.

Architekturen und Komponenten 45

Nach einer umfassenderen Definition168 zahlen zum Datenbanksystem dartiber hinaus

weitere Komponenten, die jedoch die begriffliche Trennung zwischen einem Informa

tionssystem und seiner Komponente Datenbanksystem verschwimmen lassen:

• die Anwendungsdaten als "Ftillung" der o.g. Datenbank,169

• Hardwarekomponenten, d.h. Prozessor und Arbeitsspeicher zum Betrieb des Daten

bankmanagementsystems sowie externe Speicher,

• das Betriebssystem und andere systemnahe Software,

• Anwendungs- und sonstige Software, die auf die Datenbestande des Datenbanksy

stems zugreift, sowie schlieBlich auch

• die Nutzer des Datenbanksystems, etwa in ihren Funktionen als Anwender, Anwen-

dungsprogrammierer oder Datenbankadministrator.

Neben diesen Positionen finden sich in der Literatur Zwischenformen, die sich im

wesentlichen dadurch unterscheiden, daB einzelne Komponenten des betrieblichen

Informationssystems ebenfalls zum Datenbanksystem gezahlt werden oder aber

nicht. 170 1m folgenden wird der engeren Definition gefolgt, urn die Rolle eines Daten

banksystems als gemeinsame Datenspeicherungsinstanz in einem Informationssystem

herauszustellen.

Die Struktur der folgenden Abschnitte orientiert sich am Merkmal der Verteilung ge

speicherter Daten und der ihnen zugehorigen Verwaltungsfunktionalitat auf verschie

dene Rechner. Hier ist zwischen der physischen Sichtweise, also der tatsachlichen

Anordnung von Datenbestanden und Verwaltungskomponenten auf einzelnen Rech

nern, und einer logischen Sichtweise, welche die Perspektiven der Benutzer widerspie

gelt, zu differenzieren.

168 169

170

V gl. Date (1995), S. 4ff. Damit sind gleichzeitig auch Metadaten, zumindest in Form der Datenmodelle, Bestandteil des Datenbanksystems. Kung (1994), S. 18ff., grenzt einige weitere Sichtweisen voneinander abo

46

zentrales DBS

Datenbanksystem (DBS)

verteiltes DBS

Operative Informationssysteme

Multidatenbanksystem

(MDBS)

foderiertes MDBS

nicht foderiertes MDBS

Abbildung 6: Klassifikation von Datenbanksystemen 171

Es sollen drei Datenbanksystemkategorien untersehieden werden (Abbildung 6).172 Ein

zentrales Datenbanksystem besteht aus einem einzelnen Datenbankmanagementsystem,

seinen Sehnittstellen und der dazugehorigen Datenbasis und ist entspreehend sowohl

physiseh als aueh logiseh als Einheit zu sehen. Ein verteiltes Datenbanksystem verfiigt

gleiehfalls tiber nur ein einzelnes Datenbankmanagementsystem (zentral oder auf meh

reren Reehnerknoten), aber tiber eine Datenbank, die physiseh auf mehrere Knoten in

einem Reehnernetz verteilt ist. Diese Verteilung der Daten soli fiir den Anwender

jedoeh nieht siehtbar sein, die logisehe Gesamtsieht bleibt also erhalten. Als Multida

tenbanksystem bezeiehnet man einen Verbund aus mehreren Datenbanksystemen, die

tiber eigene Verwaltungssysteme verfiigen. Hier ist aueh aus Sieht des Anwenders

erkennbar, daB eigenstandige Teildatenbestande vorliegen. Die einzelnen Systeme

konnen in untersehiedlieh enger Form zusammenarbeiten, wobei von einer fOderierten

Arehitektur gesproehen wird, wenn sie dabei eine gewisse Selbstandigkeit behalten.

Die Benennung der einzelnen Arehitekturvarianten ist in der Literatur allerdings sehr

171

172 In Anlehnung an die Terminologie in Conrad (1997), S. 34ff. Diese Begriffsauslegung orientiert sich an Sheth/Larson (1990), S. 189f.; Conrad (1997), S. 32ff., sowie in bezug auf die enge Definition verteilter Datenbanksysteme an Gabriel/Rohrs (1995), S. 279.


unterschiedlich, umgekehrt ist jedoch auch zu beobachten, daB gleiche Begriffe m

unterschiedlichen Auslegungen verwendet werden. 173

Eine nahere Beschreibung dieser Architekturtypen sowie der fUr sie jeweils relevanten

Datenbankschemata folgt in Abschnitt 2.3.3. Urn sie innerhalb der in einem Unterneh

men einsetzbaren Datenbanksysteme einordnen zu konnen, werden zuvor noch Klassi

fikationsmerkmale diskutiert (Abschnitt 2.3.2), die auf allgemeinen Anforderungen

aufbauen, die zunachst im folgenden Abschnitt 2.3.1 kurz vorgestellt werden.

2.3.1 Anforderungen an Datenbanksysteme

Gemeinsam ist allen Arten von Datenbanksystemen ihre zentrale Aufgabe und die sich

daraus erg eben den grundlegenden Anforderungen. Diese sind zunachst prinzipiell

unabhangig von der Art des Datenbankmanagementsystems und gelten fur Multidaten

banksysteme in analoger Art wie fUr zentrale oder verteilte Datenbanksysteme. Die

konstituierende Aufgabe dieser Systeme besteht darin, "umfangreiche Datenbestande

zu speichern, zu verwalten und zur weiteren Verarbeitung in korrekter Form zur Ver

fUgung zu stellen."174 Damit sie fUr diese Aufgabe geeignet sind, mussen eine Reihe

weiterer Anforderungen erfUllt werden: 175

• Das Datenbankmanagementsystem muB einen Satz grundlegender Operationen

bereitstellen, die die Definition und Manipulation der Daten sowie der zugrundelie

genden Datenmodelle ermoglichen.

• Das Datenbankmanagementsystem muB es ermoglichen, aile im Wirkungsbereich

des Datenbanksystems benotigten Daten vollstandig, korrekt und widerspruchsfrei

zu verwalten. Ais Mittel zur Umsetzung dieser Anforderung gilt die Minimierung

von Redundanz.

173

174 175

Hier tritt also das noch ausftihrlich zu diskutierende Problem der Synonyme und Homonyme auf. Als Beispiel sei angeftihrt, daB im Gegensatz zu der hier verwendeten Begriffssystematik ein "Mehrrechner-Datenbanksystem" von Dadam (1996), S. 12, als spezielle Realisierungsform eines verteilten Datenbanksystems bezeichnet wird. Umgekehrt stellt ein verteiItes Datenbanksystem in der Klassifikation von Rahm (1994), S. 27ff., eine durch bestimmte Merkmale charakterisierte Form eines Mehrrechner-Datenbanksystems dar. V gl. zur Begriffsvielfalt auch Sheth/Larson (1990), S. 190. Gabriel/Rohrs (1995), S. 197. V gl. zu den allgemeinen Anforderungen an Datenbanksysteme z.B. Codd (1982); Gabriel/Rohrs (1995), S. 197ff.; Heuer/Saake (1995), S. 6ff.


• Ein Transaktionskonzept stellt sicher, daB Datenmanipulationsoperationen die Kon

sistenz der Daten nicht verletzen. Dazu wird kontrolliert, ob schreibende Zugriffe

auf die Datenbank vollstandig ausgefiihrt worden sind. 1m Fehlerfall mtissen die

Anderungen zuruckgesetzt werden. 176

• 1m Mehrbenutzerbetrieb sind Zugriffe daruber hinaus so zu koordinieren, daB durch

konkurrierende Transaktionen, die die gleichen Datensatze bearbeiten wollen, keine

Konflikte auftreten konnen.

• 1m Mehrbenutzerbetrieb werden fiir die einzelnen Benutzer unterschiedliche Sichten

auf den Gesamtdatenbestand benOtigt. Bei diesen Sichten handelt es sich urn die

Teilmengen des Datenbestands, die ftir den Benutzer jeweils relevant sind. Damit

wird einerseits die Komplexitat auf ein problemadaquates MaB reduziert, anderer

seits muB gleichzeitig sichergestellt werden, daB aus Grunden der Datensicherheit

und des Datenschutzes nur auf die Daten - Ie send oder schreibend - zugegriffen

werden darf, fiir die eine entsprechende Berechtigung vorliegt.

• Nach Systemfehlern muB es moglich sein, einen definierten, konsistenten und mog

lichst aktuellen Zustand der Datenbasis wiederherzustellen.

• Es soH Daten-Programm-Unabhangigkeit vorliegen: Das Datenbankmanagementsy

stem soH den Zugriff auf die Daten durch verschiedene Anwendungsprogramme

tiber gut definierte Schnittstellen gestatten und so eine anwendungsneutrale Daten

speicherung errnoglichen.

• Da die Lebensdauer der gespeicherten Daten moglicherweise langer ist als es die

Innovationszyklen der verwendeten Rechner und der auf die Daten zugreifenden

Anwendungsprogramme sind, soH das Datenbanksystem portabel sein. Es solI also

die Moglichkeit bieten, das Datenbankmanagementsystem und die Datenbasis auf

andere Hardware bzw. Betriebssysteme zu verlagern, urn veranderten Anforderun

gen an das Gesamtsystem oder dem technischen Fortschritt bei diesen Systemkom

ponenten Rechnung tragen zu konnen.

176 In diesem Zusammenhang wird gelegentlich vom ACID-Prinzip gesprochen, das die Eigenschaften von Transaktionen beschreibt. Das Akronym steht fUr Atomizitiit (atomicity), Konsistenz (consistency), Isolation (isolation) und Dauerhafigkeit (durability). Vgl. LangiLockemann (1995), S. 623; Gray (1981), S. l45ff.


SchlieBlich soli auch ein Datenbanksystem mit den in ihm hinterlegten Modellen die

Qualitatsanforderungen erflillen, die tiblicherweise an Softwareprodukte zu stellen

sind. Diese lassen sich anhand der folgenden sechs Merkmale definieren: I77

• Funktionalitat: Das Datenbanksystem besitzt Funktionen mit festgelegten Eigen

schaften, welche die flir sie definierten Anforderungen erflillen.

• Zuverlassigkeit: Die Funktionalitat soli moglichst selten durch Fehler eingeschrankt

werden. Notfalls mtissen nach einem Versagen der tiblichen Leistung unbrauchbar

gewordene Daten wiederhergestellt werden konnen.

• Benutzbarkeit: Das Datenbanksystem soli flir die unterschiedlichen Benutzergrup

pen erlernbar, verstandlich und bedienbar sein.

• Wirtschaftlichkeit: Das Verhaltnis zwischen den durch den Betrieb des Datenbank

systems anfallenden Kosten und dem entstehenden Nutzen soli ausgewogen sein.178

• Anderbarkeit: Die Software soli leicht zu korrigieren, zu verbessern und an ein

verandertes Umfeld anzupassen sein. Dieses Merkmal steht damit in enger Bezie

hung zur bereits erwahnten Daten-Programm-Unabhangigkeit.

• Ubertragbarkeit: Es wird gefordert, daB Software in eine andere Hardware- oder

Software-Umgebung oder in ein anderes organisatorisches Umfeld tibertragen wer

den kann. Auch dieses Merkmal ist oben bereits als spezifische Anforderung an ein

Datenbanksystem erwahnt worden.

Diese Anforderungen lassen sich flir Datenbanksysteme naher spezifizieren und urn

anwendungsspezifische weitere Aspekte erganzen. AuBerdem konnen sie hinsichtlich

ihrer Bedeutung bewertet und in eine prioritatenbildende Hierarchie eingeordnet wer

den.179 Eine konkrete, anwendungsbezogene Bewertung der einzelnen Anforderungen

erscheint zwingend notwendig, wei I Konkurrenzbeziehungen und Konflikte erkennbar

sind. Weniger Redundanz wird z.B. mit geringerer Effizienz und Flexibilitat erkauft.

So werden etwa an ein Datenbanksystem, das als Datenhaltungskomponente flir ein

integriertes betriebswirtschaftliches Anwendungssystem dient, andere Anforderungen

177

178

179

Vgl. DIN ISO 9126 (1991), S. 3ff.; Balzer! (1998), S. 257ff.; Schmitz (1990), S. 311f. Zur Problematik der Wirtschaftlichkeitsrechnung bei Informationssystemen vgl. Schumann (1997), S. 436f., sowie Schumann (1992), S. 148ff. Wie z.B. durch die in Gabriel/Rohrs (1995), S. 198ff., vorgenommene Klassifikation in grundlegende, notwendige und wUnschenswerte Anforderungen.


zu stellen sein als an ein Datenbanksystem, das der Versorgung von Entscheidungstra

gem mit entscheidungsreievanten Informationen dient.

Neben diese Anforderungen treten Klassifikationsmerkmale, anhand derer Datenbank

systeme eingeordnet werden konnen. Sie werden immer dann relevant, wenn nicht nur

ein einzelnes Datenbanksystem betrachtet werden soil, sondem eine Umgebung, in der

mehrere Datenbanksysteme anzutreffen sind, mithin also wohl in den meisten prakti

schen Anwendungsgebieten.

2.3.2 Klassifikationsmerkmale fUr Datenbanksystemarchitekturen

Drei charakteristische Eigenschaften spieien bei der Klassifikation von Architekturen

fUr Datenbanksysteme eine groBe Rolle und werden daher im folgenden naher be

trachtet: Verteilung, Heterogenitat und Autonomie. 180 Diese Eigenschaften lassen sich

als Dimensionen eines Klassifikationsraumes darstellen, in den dann konkrete Daten

bankarchitekturen eingeordnet werden konnen (Abbildung 7).181

- Verteilung

Der Begriff der Verteilung wird haufig zunachst auf die Speicherung der Daten bezo

gen. Diese konnen also in mehreren Datenbanken enthalten sein, die entweder auf

einem Rechner oder auf verschiedenen Rechnem betrieben werden. Bei der Verteilung

der Datenbanken auf mehrere Rechner spielt die raumliche Entfernung nur eine unter

geordnete Rolle, zwangslaufig notwendig ist dagegen, daB die Rechner tiber Kommu

nikationsinfrastrukturen miteinander verbunden sind.

Die Verteilung von Daten kann beabsichtigt und planmaBig vorgenommen werden.

Haufig tritt sie jedoch auch unkoordiniert und unbewuBt auf, wenn an verschiedenen

Stellen, etwa in verschiedenen Abteilungen eines Untemehmens oder auch auf den

lokalen Speichermedien der Arbeitsplatze der Mitarbeiter, Daten unabhangig vonein

ander gespeichert werden, die zueinander in Beziehung stehen. 182

180

181

182

Vgl. zu diesen Merkmalen insbesondere Sheth/Larson (1990), S. 185ff., und OzsulValduriez (1991), S. 79ff. Vgl. Conrad (1997), S. 44ff.; SchekIWeikum (1991), S. 39. Vgl. Conrad (1997), S. 45.

Architekturen und Komponenten

Verteilung

verteilte homogene DBS

verteilte fbderierte DBS

homogene fbderierte DBS

Autonomie

heterogene integrierte DBS

heterogene fbderierte DBS

Heterogenitat

Abbi1dung 7: Architekturvarianten von Datenbanksystemen 183

51

Neben den (Problem-)Daten sind weitere Verteilungsobjekte m emer Datenbank

systemarchitektur denkbar. So konnen auch die Anwendungsprogramme, die auf das

Datenbanksystem zugreifen, sowie die Datenmodelle oder die Operationen, die das

Datenbanksystem bereitstellt, verteilt werden. 184

- Heterogenitat

Heterogenitat, also Verschiedenartigkeit, kann in einem Datenbanksystem in mehreren

Auspragungen auftreten. Von technischer Heterogenitat kann gesprochen werden,

wenn unterschiedliche Hardware, Betriebssysteme oder Kommunikationswege vorlie

gen. Diese Differenzen sollen hier mit Blick auf die entsprechenden verftigbaren

Schnittstellen nicht weiter interessieren.

Bei der Betrachtung der tibrigen Formen der Heterogenitat von Datenbanksystemen

lassen sich mehrere Ebenen unterscheiden. So konnen einerseits die verschiedenen

Systeme unterschiedliche Datenmodelle, z.B. relationale und hierarchische, verwen-

183

184 In Anlehnung an SchekiWeikum (1991), S. 39. Beispiele fUr die Verteilung von Datenbankoperationen beschreibt Fasnacht (1993), S. 87f.


den. Dies fiihrt dazu, daB die reprasentierten Objekte durch unterschiedliche Strukturen

dargestellt werden und die Verwendung mehrerer Anfragesprachen erforderlich ist, urn

darauf zugreifen zu konnen. Auch Integritatsbedingungen lassen sich in einem so1chen

Fall nicht einheitlich formulieren, da Unterschiede in der Untersttitzung impliziter oder

explizit formulierter Bedingungen auftreten.

Von syntaktischer Heterogenitat kann gesprochen werden, wenn auf der Ebene der

Inhalte der Datenbank gleiche Werte in den Datenbanken unterschiedlich reprasentiert

werden, etwa wenn verschiedene Datentypen (numerisch und alphanumerisch) zur

Speicherung von Zahlen verwendet werden.

Semantische Heterogenitat liegt vor, wenn Differenzen tiber die Bedeutung, Interpre

tation oder beabsichtigte Verwendung von gleichen oder zusammengehorigen Daten

vorliegen,185 1m Vergleich zu den tibrigen genannten Heterogenitatsformen ist seman

tische Heterogenitat deutlich schwerer zu entdecken und zu behandeln. Als Beispiel

seien zwei Datenbanken betrachtet, die beide Umsatzwerte enthalten. 1st in einer der

Datenbanken der Umsatz definiert als Rechnungsbetrag ohne Umsatzsteuer, wird in

der anderen Datenbank zur Ermittlung dieser Kennzahl jedoch zusatzlich gewahrtes

Skonto abgezogen, sind die entsprechenden Zahlen nicht mehr vergleichbar. Es ent

steht eine semantische Heterogentat aufgrund der implizit unterschiedlichen Definition

dieser GroBe "Umsatz" in der Datenbank. 186

Semantische Heterogenitat stellt einen der wesentlichen Problempunkte bei der Trans

formation von Daten aus verschiedenen Quellen ftir ein Data Warehouse dar, wie spa

ter noch ausfiihrlich zu zeigen sein wird.

- Autonomie

Als dritte und letzte Dimension zur Klassifizierung von Datenbanksystemen solI der

Aspekt der Autonomie betrachtet werden. Die Unabhiingigkeit der Datenbanksysteme

zueinander wird vie1fach unter den Aspekten Entwurfs-, Kommunikations-, Ausftih

rungs- und Assoziierungsautonomie betrachtet. 187

Von Interesse ist hier insbesondere die Entwurfsautonomie. Darunter werden die Frei

heitsgrade verstanden, die beim Entwurf und der Gestaltung eines Datenbanksystems

185

186 187

"Semantic heterogenity occurs when there is a disagreement about the meaning. interpretation. or intended use of the same or related data." Sheth/Larson (1990). S. 187. V gl. zu weiteren Beispielen Litwin! Abdellatif (1986). S. 13. Vgl. neben den genannten Quellen auch Veijalainen (1989). S. 144ff.


zur Verfligung stehen. Je groBer diese Freiheitsgrade sind, desto groBere Differenzen

werden zwischen den Komponentensystemen entstehen, und desto groBer wird damit

auch der Grad der Heterogenitat innerhalb eines aus mehreren Datenbanken bestehen

den Gesamtsystems sein. Somit liegt hier gleichzeitig eine Ursache, wenn auch viel

leicht nicht die bedeutsamste, flir Heterogenitat vor. 188

2.3.3 Architekturarten

Nach der Zusammenstellung wichtiger Anforderungen und Merkmale flir Datenbank

systeme werden nun wesentliche Datenbankarchitekturen mit ihren charakteristischen

Merkmalen beschrieben. Dabei treten die Gemeinsamkeiten und Unterschiede hin

sichtlich des Aufbaus und der Funktionalitat hervor. Der Schwerpunkt Iiegt auf der

Erlauterung der Datenbankschemata, die notwendig sind, urn unter Beriicksichtigung

der diskutierten Anforderungen einen Datenbankbetrieb auf der Basis der jeweiligen

Architektur zu ermoglichen.

2.3.3.1 Zentrale Datenbanksysteme

Der urspriingliche Leitgedanke bei der Entwicklung der Datenbanksysteme bestand in

der Bereitstellung einer zentralisierten, besonders effizient realisierten gemeinsamen

Datenverwaltung flir eine groBe Zahl von Benutzern und deren auf die dort gespei

cherten Daten zugreifende Anwendungsprogramme. Dabei wird aufgrund der bereits

erwahnten unterschiedlichen Lebenszyklen von Daten, Problemstrukturen und Com

putertechnik eine moglichst groBe Unabhangigkeit der Daten einerseits von den An

wendungsprogrammen, mit denen sie bearbeitet werden, und andererseits vom Be

triebssystem und der Hardware angestrebt. Diese Gedanken finden ihren Niederschlag

in Architekturkonzepten wie dem in den 70er Jahren vorgestellten und bis heute aner

kannten ANSUSparc-Konzept. Diese auch als Drei-Ebenen- oder Drei-Schema-

188 Fasnacht (1993), S. III, folgert dagegen, daB die Heterogenitat im wesentlichen eine Funktion der Entwurfsautonomie ist und stellt daher die dreidimensionale Klassifizierung der Datenbanksysteme (vgl. Abbildung 7) in Frage. Diese Meinung setzt sich jedoch in der Literatur nicht fort. vielmehr wird diese Klassifizierung haufig dargestellt und zur Strukturierung verwendet, vgl. z.B. auch Dadam (1996), S. 19f., und ElmasrilNavathe (1994), S. 715f.


Konzept bezeichnete Architektur sieht die Bildung mehrerer Schemata zur abstrakten

Beschreibung der Daten aus den verschiedenen Sichten vor (Abbildung 8):189

• Das konzeptionelle Schema enthalt mit dem konzeptionellen Datenmodell eme

Gesamtsicht aller relevanten Daten des durch die Datenbank abgebildeten Problem

bereichs. Die Darstellung erfolgt in einer abstrakten Beschreibung, die von den ein

zelnen Benutzersichten und Datenschutzaspekten 190 einerseits und von Zugriffs

und Implementierungsaspekten andererseits absieht.

• Die externen Schemata reprasentieren fiir die Benutzer bzw. Anwendungsprogram

me jeweils eine geeignete Sicht auf die Daten, die der Benutzer benOtigt und auf die

er zugreifen darf. Damit handelt es sich urn Ausschnitte aus den im konzeptionellen

Schema beschriebenen Strukturen.

• Das interne Schema dient der Darstellung der implementierungsabhangigen Eigen

schaften der Daten, also z.B. der Zuordnung von Objekten des konzeptionellen

Schemas zu physischen Speicherstrukturen. AuBerdem konnen weitere Datenstruk

turen festgelegt werden, die etwa den Zugriff tiber Indexierungsmechanismen re

geln. 191

Diese Schemata werden durch Transformationsregeln miteinander verkntipft, die die

Unabhangigkeit der einzelnen Ebenen gewahrleisten. So kann, indem die Transforma

tionsregeln angepaBt werden, insbesondere das konzeptionelle Schema langerfristig

stabil bleiben, auch wenn interne oder externe Schemata verandert werden. 192 Dies

ermoglicht z.B. das Modifizieren des internen Schemas, wenn es an ein geandertes

technisches Umfeld angepaBt werden soli, ohne daB die Schnittstellen zu den Anwen

dungsprogrammen und Benutzern, die tiber die externe Ebene realisiert sind, davon

betroffen werden.

189

190

191

192

V gl. z.B. Gabriel/Rohrs (1995), S. 268ff.; Schlageter/Stucky (1983), S. 26ff.; Date (1995), S. 28ff.; ElmasrilNavathe (1994), S. 26ff., und Conrad (1997), S. 36f. Zur Zuordnung der verschiedenen Aspekte von Datenintegritiit (Datenschutz, Datenkonsistenz, Datensicherheit) zu den Ebenen vgl. Gabriel/Rohrs (1995), S. 285ff. Vgl. Conrad (1997), S. 37. V gl. Gabriel/Rohrs (1995), S. 270; Date (1995), S. 36f.


externe Ebene

Transformations-

regeln

konzeptionelle Ebene

physische Daten- Transformations-

unabhangigkeit regeln

interne Ebene

Abbildung 8: Drei-Schema-Konzept fUr Datenbanken l93

Wesentlich an diesem Konzept erscheint, daB es nur ein konzeptionelles und ein inter

nes Schema gibt. Sie reprasentieren den gesamten erfaBten Datenbestand unter der

jeweiligen Sichtweise, so daB ein zentrales Konzept vorliegt. Eine konkrete Auspra

gung erfahrt dieses durch die Architektur eines Datenbanksystems, die z.B. durch drei

Kernkomponenten beschrieben werden kann. 194 Danach besteht ein Datenbanksystem

aus:

• Einer Datenbank als dem physischen Speicherort fUr die zu verwaltenden Pro

blemdaten. Diese kann sich verschiedener Speichermedien - auch auf mehreren

Rechnerknoten - bedienen, die jedoch von einem einzigen internen Schema ange

steuert werden,

193

194 In Anlehnung an Date (1995), S. 32. Vgl. Gabriel/Rohrs (1995), S. 256; Schlageter/Stucky (1983), S. 21ff.; ElmasrilNavathe (1994), S. 29ff. Ahnlich auch KemperlEickler (1997), S. 24ff., und Date (1995), S. 39ff.


• dem Datenbankverwaltungssystem als der Software, die die Datenbank und aile

Zugriffe verwaltet und kontrolliert, sowie

• der Datenbankkommunikationsschnittstelle, die der Kommunikation zwischen dem

Datenbanksystem und seiner Umwelt dient.

Ordnet man ein derartiges zentrales Datenbanksystem in den dargestellten Klassifikati

onsraum ein, ist offensichtlich, daB bei einem zentralen System keine Verteilung vor

liegt. Auch der Autonomiebegriff HiBt sich hier nicht sinnvoll anwenden, da nur ein

einzelnes Datenbanksystem vorhanden ist. Differenzierter kann die Frage nach dem

Vorliegen von Heterogenitat betrachtet werden: Zwar kann hier nicht von technischer

Heterogenitat innerhalb des Datenbanksystems gesprochen werden. Die Gefahr des

Auftretens syntaktischer Heterogenitat ist jedoch gegeben, sofern im Datenmodell

Objektklassen der Realitat mehrfach abgebildet werden. Dieser Fall liegt vor, wenn,

etwa aus pragmatischen Grunden oder zur Steigerung der Verarbeitungsgeschwindig

keit des Datenbanksystems, Modelle gebildet werden, die hier formale Ungenauigkei

ten aufweisen. In dies em Fall kann es durch die entstehenden Redundanzen leicht zu

sich widersprechenden Definitionen oder Werten kommen. Semantische Heterogenitat

kann dariiber hinaus selbst dann auftreten, wenn ein korrektes Datenmodell vorliegt,

jedoch Daten schlechter Qualitat verwendet werden. So k6nnen z.B. Objekte der realen

Welt mit unterschiedlichen Angaben mehrfach erfaBt werden. Insgesamt kann also

festgehalten werden, daB auch die Verwendung eines zentralen Datenbanksystems eine

syntaktische und semantische Homogenitat nicht in allen Fallen gewahrleisten kann.

Datenbanksysteme in der oben skizzierten Architektur bilden die zentrale Datenversor

gung fUr die darauf zugreifenden Anwendungsprogramme. Dabei kann es sich urn eine

oder mehrere Einzelanwendungen zur Abbildung einzelner betrieblicher Aufgaben

handeln oder auch urn umfangreiche Anwendungssysteme, die in integrierter Form

eine Vielzahl von Funktionen im Unternehmen unterstiitzen.

Trotz der theoretischen Vorteile, die aus der zentralen Speicherung aller Daten im

Unternehmen in einem Datenbanksystem erwachsen, sieht die praktische Realitat im

Unternehmen wohl vielfach anders aus. Es sind meist mehrere Datenbanksysteme auf

verschiedenen Rechnertypen und von verschiedenen Herstellern anzutreffen, die je

weils Teilbestande der Daten bereithalten. 195 Diesen liegen verschiedene Datenmodelle

zugrunde, die sich neben dem Inhalt auch in dem verwendeten Modelltyp unterschei-

195 V gl. z.B. Goodhue/Wybo/Kirsch (1992), S. 293; HeuerlSaake (1995), S. 445f.


den. Dies ist vergleichbar mit der Verwendung verschiedener Programmiersprachen

fUr die Erstellung von Anwendungsprogrammen. 196 Die Auswahl orientiert sich dabei

an der Problemadaquanz der zur VerfUgung stehenden Alternativen, aber auch an den

technischen Moglichkeiten zum Zeitpunkt der Programmerstellung und haufig wohl

auch an pragmatischen Erwagungen, die an die Stelle eines systematisierten Auswahl

prozesses treten.

Unternehmensweite Datenmodelle als Basis fUr unternehmensweit zentrale Daten

banksysteme werden dagegen in der Praxis selten erstellt und dienen dann meist aus

schlieBlich zu Dokumentationszwecken. HierfUr konnen vieIniitige Griinde genannt

werden. Wesentlich erscheint zum einen der Aspekt, daB ein solches Datenmodell eine

nur schwer beherrschbare Komplexitat besitzt und seine Erstellung mit sehr hohen

Kosten verbunden iSt. 197 Weiterhin werden andererseits regelmaBig bereits Datenbe

stande in mehr oder minder strukturierter Form vorliegen, so daB fUr das Erstellen

eines unternehmensweiten Datenmodells die Vorgehensweise einer bei Null anfangen

den Modellierung in Top-Down-Strategie I98 verworfen werden muB. Die bereits geta

tigten Investitionen werden statt des sen in das Gesamtmodell einbezogen, und es ist zu

fordern, daB dieses durch entsprechende Systemarchitekturen unterstiitzt wird. 199 Da

mit wird eher ein abteilungsbezogenes Redesign in Einzelschritten durchgefUhrt. Un

ternehmensweite Datenmodelle fUr ein Informationssystem entstehen, indem einzelne,

auf bestimmte Anwendungen beschrankte Teilmodelle zusammengefUgt werden. 2OO

Einzelne Organisationseinheiten konnen so parallel und zeitversetzt ihre Teilmodelle

als Konstruktionsbausteine einem globalen Unternehmensdatenmodell zufUhren, das

allerdings eher als dokumentative Basis und weniger als implementiertes konzeptio

nelles Modell eines Datenbanksystems dient.

Dabei ist jedoch zu beobachten, daB auch diese Ansatze haufig an der strukturellen und

semantischen Heterogenitat der Einzelmodelle scheitern. Obwohl bereits seit einigen

lahren zahlreiche Verfahren zur Schemaintegration diskutiert werden,201 mangelt es

gleichwohl in der Literatur an durchgangigen Ansatzen zur Bottom-Up-Integration, die

196 197 198

199 200 201

Vgl. SchekIWeikum (1991). S. 39. V gl. StahlknechtlHasenkamp (1997). S. 360. Zu Problemlosungsstrategien wie etwa dem Top-Down-Vorgehen vgl. z.B. Balzert (1998). S. 582ff.; Mellis (1997). S. 383. V gl. Cannata (1991). S. 3f. V gl. Mertens/Holzner (1992). S. I If. BatinilLenzerini/Navathe (1986). S. 338ff., geben eine Ubersicht tiber solche Verfahren.


den gesamten Ablauf von der Bestimmung der Reihenfolge bis zum erwiinschten Inte

grationsgrad abbilden konnen.202 Neuerdings wird auch diskutiert, systemiibergreifen

de Konsistenzsicherung als IntegrationsmaBnahme zu betreiben, urn so dem Ist

Zustand zahlreich existierender, sich teilweise iiberlappender DatenbesUinde Rechnung

zu tragen.203 Technisch ermoglicht wird diese Form der Integration durch aktive Da

tenbankmechanismen, wie sie von den aktuellen relationalen Datenbankverwaltungs

systemen bereitgestellt werden.204

Betrachtet man die Problematik der unternehmensweiten Datenmodelle spezifisch aus

dem Blickwinkel dieser Arbeit, muB zudem ein weiterer Aspekt Beriicksichtigung

finden, der die Relevanz solcher Modelle fUr analyseorientierte Informationssysteme

fraglich erscheinen HiBt. Unternehmensstrukturen sind typischerweise gekennzeichnet

durch Konzernbeziehungen, die zudem einer gewissen Dynamik unterworfen sind.

Unternehmen und Unternehmensteile innerhalb eines Konzerns werden in der Hierar

chie neu angeordnet oder gruppiert, und durch Firmenakquisitionen oder -verkaufe

vedindert sich die Mitgliederstruktur des Konzerns. Innerhalb solcher, immer haufiger

anzutreffender dezentraler Unternehmensstrukturen erscheint es besonders illusorisch,

jeweils unternehmensweite Datenmodelle mit ausreichend wei tern Giiltigkeitsrahmen

zu bilden, urn diese als Basis fiir eine spatere Datenversorgung fUr konzernweite analy

seorientierte Informationssysteme verwenden zu konnen. Unabhangig von der techni

schen und organisatorischen Machbarkeit solcher integrierten Modelle wird teilweise

auch die Frage gestellt, ob die Nutzeffekte die Integrationskosten rechtfertigen kon

nen.205

Neben diese Uberlegungen zur praktischen Machbarkeit und Sinnhaftigkeit zentrali

sierter Datenbanksysteme treten auch Argumente, die eine gezielte Dezentralisierung

von Daten nicht nur notwendig, sondern auch sinnvoll erscheinen lassen. Als Griinde

werden beispielsweise genannt: 206

• Kostengriinde: Dezentrale Systeme lassen sich auf kostengiinstigeren, kleineren

Rechnern realisieren und verursachen - je nach Verteilung der Standorte - mogli

cherweise geringere Dateniibertragungskosten,

202

203

204

205

206

V gl. Stickel et al. (1995), S. 206. V gl. ConradlTiirker (1997), S. 345f. Vgl. zum Stand aktiver Mechanismen in Datenbankmanagementsystemen LufterlSchaarschmidtiKiispert (1997), S. 104ff. Vgl. Goodhue/Wybo/Kirsch (1992). S. 303ff.; Stickel et al. (1995). S. 207ff. Vgl. Zehnder (1998). S. 287f.; Rahm (1994). S. 4ff.


• Unterstiitzung dezentraler Strukuren: Wenn Unternehmensorganisation und Kom

petenzen dezentral organisiert sind, sollen auch jeweils eigene Informatiklosungen

betrieben werden konnen,207

• Sicherheits- und ZuverHissigkeitsgriinde: Die Abhangigkeit von einer einzigen zen

tralen Datenbank ist haufig unerwiinscht, der Ausfall eines Teilsystems in einer de

zentralen Struktur beeintrachtigt das Gesamtsystem weniger stark als der Ausfall ei

nes zentralen Datenbanksystems.

Erkennbar sind die Unterschiede zwischen historisch gewachsenen, de-facto

dezentalisierten Systemen sowie gezielter und kontrollierter Dezentralisierung: 1m

ersten Fall ist man mit wenig koordinierten, kaum aufeinander abgestimmten Datenbe

standen heterogenen Charakters konfrontiert. Gezie1te Dezentralisierung oder die

nachtragliche Zusarnmenfiihrung der Datenbestiinde unter Beibehaltung lokaler Auto

nomie fiihrt dagegen zu einem verteilten oder fOderierten Datenbanksystem, zwei

Architekturformen, die im weiteren zu diskutieren sind.

Als Fazit dieser Uberlegungen kann hier festgehalten werden, daB unternehmensweite

Datenmodelle und darauf basierende zentralisierte Datenbanksysteme, wie sie vielfach

in der Wirtschaftsinformatik diskutiert werden, in der Praxis nur in Ausnahmefallen

vorhanden sein werden. Zwar ist nicht zu iibersehen, daB zunehmend integrierte Stan

dardanwendungssoftware eingesetzt wird, es verbleiben jedoch Funktionen, die durch

diese Programmpakete nicht abgedeckt werden und fiir die andere Anwendungssyste

me mit eigenen Datenspeichern erforderlich sind. Somit wird sichtbar, daB die Frage

stellungen der Beschaffung von Daten fiir analyseorientierte Informationssysteme sich

immer auch mit der Verwendung mehrerer Datenquellen und mit der Auflosung von

Heterogenitaten auseinandersetzen miissen.

Damit treten Architekturen in den Blickpunkt, welche die Moglichkeit bieten, mehrere

Systeme und deren Datenbestande miteinander zu verkniipfen.

2.3.3.2 Verteilte Datenbanksysteme

In diesem Abschnitt wird iiberblicksartig auf verschiedene Formen des logischen Zu

sammenschlusses von Datenbanksystemen eingegangen. Diese Frage ist, wie oben

erortert, insofern von Bedeutung, als eine zentralisierte Datenhaltung in einem einzigen

207 Vgl. auch Dadam (1996), S. 4.


Datenbanksystem im Unternehmen offensichtlich eine unrealistische Annahme dar

stellt. Daher ist zu priifen, inwieweit die Systeme mit den Teildatenbestanden mitein

ander verkntipft werden konnen. War moglicherweise bisher diese Frage von nachran

giger Bedeutung, wei I "Querverbindungen" zwischen den Datenbestanden tiber mehr

oder minder manuell erzeugte Redundanzen simuliert wurden, so gewinnt das Problem

der Kopplung von Datenbestanden dann an Bedeutung, wenn diese als Grundlage fiir

ein Data Warehouse dienen sollen.208

Die Diskussion der Thematik verteilter Datenbanksysteme setzt eine vorherige Spezifi

zierung der mit dem Attribut "verteilt" verkntipften Begriffe in einem etwas breiteren

Kontext voraus. Die Termini "verteiltes System" und "verteilte Datenverarbeitung"

werden allerdings in der Literatur in sehr heterogener Weise verwendet.209 Ftir diese

Untersuchung soli unter verteilter Datenverarbeitung die Ausfiihrung der Datenverar

beitungsaufgaben auf einer Mehrzahl von homogenen oder heterogenen, mindestens

teilweise autonomen Rechnern, die durch ein Netzwerk verbunden sind, verstanden

werden.210 Verteilten Systemen konnen damit die folgenden Eigenschaften zugeordnet

werden: 211

• Das Vorhandensein mehrerer unabhangiger, meist heterogener Rechnerknoten,

jeweils mit Prozessoren, internen und externen Speichern usw.,

• die Moglichkeit zur Kommunikation zwischen dies en Knoten durch ein Netzwerk,

• ein unabhangiges Fehlerverhalten, d.h. die Fahigkeit, das Gesamtsystem beim Aus

fall einzelner Komponenten mindestens teilweise weiternutzen zu konnen,

• ein logisches Gesamtkonzept, das den einzelnen Komponenten lnformationen tiber

das Vorhandensein und die Eigenschaften anderer Komponenten liefert, mit denen

kooperiert werden kann, sowie

• ein MindestmaB an lnteraktion zwischen den einzelnen Netzknoten.

208

209

210

211

Dadam (1996), S. 4f. nennt allgemeiner die (sich nicht unbedingt widersprechenden) Trends zur Dezentralisierung und zur Integration als Motive fUr die verstarkte Beachtung dieses Themas. Eine Zusammenstellung der verschiedenen Begriffsauslegungen in der Literatur findet sich in Martin (1981), S.87 sowie bei Fasnacht (1993), S. 33f. In Anlehnung an OzsuIValduriez (1991), S. 3, und Martin (1981), S. 103. Vgl. zu diesen Charakteristika Enslow (1978), S. 14ff.; Lamersdorf (1994), S. 30, sowie Rho (1997), S. 57.


Auf der Basis leistungsstarker und immer weiter verbreiteter Rechnernetze bilden diese

Systeme zunehmend die Basis fUr die Realisierung von Datenhaltungssystemen und

Anwendungsprogrammen.212

Fur verteilte Systeme lassen sich zahlreiche Vor- und Nacheile organisatorischer und

technischer Art auffuhren. Da jedoch im Gesamtkontext dieser Arbeit Verteilung eher

eine Pramisse als einen Kern-Diskussionsgegenstand darstellt, soli hier eine vertiefte

Diskussion dieser Aspekte unterbleiben.213

Die genannten, zunachst allgemeinen und abstrakten Eigenschaften verteilter Systeme

lassen sich auf das Anwendungsgebiet der Datenbanksysteme konkretisieren. Idealty

pisch tritt ein verteiltes Datenbanksystem aus der Sicht des Benutzers wie ein zentrales,

geschlossenes System auf.2 14 Es ist transparent in dem Sinne, daB die Verteilung nicht

sichtbar ist. 215 Fur die Benutzer wird damit eine logische Sicht auf die Daten realisiert,

die vorspiegelt, aile Daten seien an einer einzigen Stelle, in einem homogenen Daten

banksystem und lokal auf dem Rechner, auf dem das Anwendungsprogramm abJauft,

gespeichert.216 Die Daten werden - partitioniert oder repliziert217 - auf mehreren

Rechnern innerhalb eines Computernetzwerkes gespeichert.218

Die moglichen Realisierungsformen verteilter Datenbanksysteme lassen sich wiederum

in den bereits beschriebenen Klassifikationsraum mit den Dimensionen Verteilung,

Heterogenitat und Autonomie einordnen.219 Die Verteilungsdimension beschreibt die

Allokation der Daten auf die verschiedenen Rechnerknoten. Fur die Dimension der

Heterogenitat soli an dieser Stelle vereinfachend nur binar zwischen den Auspragungs-

212 213

214

215

216 217

218

219

Vgl. Lamersdorf (1994), S. 29f. Ftir eine ausfiihrliche Darstellung der Vor- und Nachteile verteilter Systeme vgl. z.B. Fasnacht (1993), S. 36ff.; Holler (1989), S. 88ff., und Jablonski (1990), S. 4ff. Vgl. zu den Eigenschaften verteilter Datenbanksysteme Date (1995), S. 598ff, und Stonebraker/Hellerstein (l998b), S. 321. Entgegen der gemeinhin assoziierten Bedeutung der Durchsichtigkeit (vgl. Duden (1996» wird der Begriff Transparenz im folgenden wie in der einschH1gigen deutsch- und englischsprachigen fachspezifischen Literatur im Sinne von unsichtbar verwendet. V gl. Lamersdorf (1994), S. 21. Wird in einem verteilten Datenbanksystem kein Datenobjekt mehrfach gespeichert, spricht man von einer partitionierten, andemfalls von einer replizierten Datenbank. Weiterhin kann zwischen vollstandiger Replikation, bei der aile Datenobjekte vollstandig auf allen Rechnerknoten gespeichert werden, und teilweiser Replikation unterschieden werden. Vgl. z.B. Rahm (1994), S.62. Vgl. OzsuIValduriez (1991), S. 4f., sowie Date (1995), S. 593f. Eine Ubersicht tiber die verschiedenen Definitionsvarianten in der Literatur findet sich in Fasnacht (1993), S. 75f. V gl. Abbildung 7, Seite 5 I.


formen "nicht heterogen" (homogen) bei gleichen lokalen Datenbankmanagementsys

temen und "heterogen" in allen anderen Hillen unterschieden werden. Die Autonomie

dimension liefert hier einen Indikator fUr die Frage, inwieweit neben den Daten auch

die Managementfunktionen des Datenbanksystems verteilt werden. Hier ist erkennbar,

bis zu welchem MaBe die einzelnen, lokalen Datenbanksysteme auch innerhalb des

verteilten Systems lokal agieren konnen.220

Nach dieser eher idealtypischen Beschreibung verteilter Datenbanksysteme werden im

folgenden zusammenfassend die Merkmale einiger Realisierungsformen vorgestellt.

Diese Architekturen haben gemeinsam, daB der Datenbestand physisch auf die ver

schiedenen Knoten verteilt ist. Weiterhin werden generell den lokalen Datenbestand

betreffende Anfragen auch lokal bearbeitet.221 Diese beiden Eigenschaften werden

auch als Mindestanforderungen an verteilte Datenbanksysteme bezeichnet.222

Unterschiede zeigen sich jedoch einerseits in dem Grad der Realisierung eines zu den

zentralen Datenbanksystemen analogen Transaktionskonzepts und andererseits im

Grad der "Transparenz", also in der auBeren Sichtbarkeit der Tatsache, daB es sich

nicht urn ein zentrales Datenbanksystem handelt. AuBerdem wird von sehr unter

schiedlichen Annahmen tiber die vorliegenden organisatorischen Gegebenheiten aus

gegangen, die zu einem verteilten Datenbanksystem fUhren.

Die Reihenfolge der dargestellten Architekturen spiegelt eine zunehmende Komplexi

tat der fUr eine Verkntipfung der lokalen Datenbanksysteme notwendigen Schema

transformationen wider. Zusatzlich mag vorgreifend bereits festgehalten werden, daB

auch der Bezug zu real im betrieblichen Umfeld vorhandenen Problemstellungen zu

nimmt.

- Homogene, pra-integrierte Datenbanksysteme223

Der Begriff "pra-integriert" beinhaltet bereits die wesentliche MaBgabe fUr diese Ar

chitekturform. Hier soli der Fall subsumiert werden, daB im Rahmen der Modellierung

und Implementierung des Datenbanksystems von vornherein eine verteilte Architektur

220

221

222

223

Vgl. OzsulValduriez (1991), S. 79ff. Conrad (1997), S. 47f., unterscheidet dabei die Autonomiearten Entwurfs-, Kommunikations- und AusfUhrungsautonomie. Vgl. Dadam (1996), S. 10. Vgl. Dadam (1996), S. 20. Die folgende Zusammenstellung einiger Architekturbeispiele fUr verteilte Datenbanksysteme orientiert sich, auch hinsichtlich der Bezeichnungen fUr die Architekturen, an Dadam (1996), S. 88ff.


vorgesehen wird. Es tritt keine Heterogenitat auf, die durch entsprechende Abbildungs

regeln aufgelost werden mtiBte. Es ist jedoch ein globales Schema erforderlich, wel

ches das Gesamtmodell reprasentiert und dazu dient, dieses sowie die externen Sche

mata der einzelnen Nutzer auf die lokalen Schemata der einzelnen Knoten im verteilten

Datenbanksystem abzubilden. So laBt sich die 3-Schema-Architektur zentralisierter

Datenbanksysteme224 entsprechend um eine weitere Ebene mit der genannten Aufgabe

zu einer 4-Schema-Architektur erweitern (vgl. Abbildung 9).225

externes Schema 1

lokales internes Schema

konzeptionelles Schema



Abbildung 9: Vier-Schema-Architektur verteilter Datenbanksysteme226

Hier liegt also der idealtypische Fall eines verteilten Datenbanksystems vor: Die inter

nen Schemata und damit auch die Datenhaltung sind auf mehrere Rechnerknoten ver

teilt, die Nutzer greifen jedoch tiber ihre externen Schemata auf ein gemeinsames kon

zeptionelles Schema zu, so daB Verteilungstransparenz entsteht. Ftir diese Architektur

form werden jedoch Pramissen getroffen, die als realitatsfern erscheinen. Die Annah

me, ein verteiltes Datenbanksystem lasse sich "auf der griinen Wiese" und ohne die

224

225

226

V gl. Abschnitt 2.3.3.1. Vgl. z.B. OzsuNalduriez (1991), S. 82f., sowie Conrad (1997), S. 38ff. In Anlehnung an Conrad (1997), S. 39.


Beriicksichtigung von "Altlasten" in Form von Heterogenitaten erstellen, scheint einer

in der Praxis nur sehr selten anzutreffenden Situation zugrundezuliegen. Neben dieser

Kritik an den restriktiven Voraussetzungen wird auch eingewendet, daB eines der

wichtigsten Argumente flir die Verwendung eines verteilten Datenbanksystems die

Moglichkeit zur Uberbriickung von Heterogenitat sei.227

In den weiteren Abschnitten werden daher schrittweise komplexere Architekturformen

betrachtet.

- Heterogene, pra-integrierte Datenbanksysteme

Hier wird zunachst die Pramisse der Homogenitat der Teilsysteme fallengelassen. Das

Ziei einer solchen Architektur besteht in der Nutzung verschiedener Datenspeiche

rungskomponenten, die jeweils in besonders problemadaquater Form unterschiedliche

Datentypen speichern konnen, die durch ein Anwendungsprogramm verwendet wer

den. Als Anwendungsbeispiel wird etwa ein CAD-Anwendungssystem genannt, das

einerseits Verwaltungsdaten, Stucklisten usw. in einem (relationalen) Datenbanksy

stem speichert, geometrische Informationen, flir die diese Speicherform weniger effizi

ent ist, jedoch separat und problemadaquater verwaltet.228

Die in Abbildung 9 dargestellte 4-Schema-Architektur hat hier prinzipiell auch Gultig

keit, jedoch steigt die Komplexitat der Transformationsregeln zwischen den Schichten,

da die unterschiedlichen Datenstrukturen harmonisiert werden mussen.

- Post-integrierte Datenbanksysteme

Mit der Aufhebung der Pramisse einer ex-ante-Integration der Datenmodelle steigt die

Komplexitat des verteilten Datenbanksystems signifikant an. Die Kernaufgabe einer

nachtraglichen Integration von Datenbanken zu einem verteilten Datenbanksystem

besteht in der Bildung eines globalen Schemas. Dies setzt eine Integration der beste

henden Datenbankschemata voraus. In diesem IntegrationsprozeB werden statische und

dynamische Ziele verfolgt. Statisches Ziel ist die Bildung eines globalen Datenmo

dells. Dynamisches Ziel ist es, auch verteilte Anfragen an die verschiedenen Daten

banksysteme zu ermoglichen.229 Eine solche Schemaintegration ist insbesondere in

groBen Anwendungsumgebungen mit vieien, auch flir sich genommen schon komple-

227

228

229

Vgl. Stonebraker/Helierstein (I 998b), S. 324f. V gl. Conrad (1997), S. 94f. Vgl. Fasnacht (1993), S. 166.


xen Teilmodellen eine sehr anspruchsvolle Aufgabe,230 fUr die verschiedene Methoden

entwickelt worden sind.231 Hier werden lediglich einige grundlegende Aspekte ange

sprochen.

Ais Vorgehensweise fUr eine Schemaintegration werden vielfach vier nacheinander zu

durchlaufende Phasen genannt: 232

I) Vorintegrationsphase: Diese Phase beinhaltet, in Analogie zu den ersten, fruhen

Phasen des Software-Engineering-Wasserfallmodells, eine Problemanalyse sowie

die Planung, welche Schemata in welcher Reihenfolge mit welcher Integrationsme

thode zusammengefUhrt werden sollen. Ais Grundmodelle moglicher Vorgehens

weisen kommen die binare Integration und die n-stellige Integration in Frage. Bei

der binaren Integration werden zunachst zwei Schemata integriert und das Ergebnis

schema dann mit einem weiteren Schema (gewichtete Strategie233) oder dem Ergeb

nisschema einer anderen binaren Integration (balancierte Strategie234) zusammenge

fUhrt. Diese kleinschrittige Vorgehensweise wird wiederholt, bis das Zielschema aus

allen zu integrierenden lokalen Schemata erreicht ist. Bei der zweiten Methode da

gegen werden aile Schemata in einem Schritt zusammengefUhrt.235

2) Vergleichsphase: In dieser Phase werden durch Vergleich der lokalen Schemata

Konflikte ermittelt und dokumentiert. Fundamental ist zunachst das Problem der

Namensdifferenzen. Konflikte konnen weiterhin auf struktureller, inhaltlicher und

funktionaler Ebene auftreten.236

Das Namensproblem manifestiert sich in Synonymen und Homonymen, die auf allen

Stufen innerhalb der Schemata auftreten konnen. So konnen z.B. - in relationaler

Terminologie237 - auf Datenbank-, Tabellen- oder Spaltenebene verschiedene Be

nennungen fUr denselben Sachverhalt (Synonyme) auftreten. Umgekehrt muS er-

230 231

232

233

234 235

236

237

Vgl. Dadam (1996), S. 98. Ein Vergleich zahlreicher existierender Methoden zur Schemaintegration wird von Batini/LenzerinilNavathe (1986), S. 338ff., angestellt. V gl. z.B. BatinilLenzerinilNavathe (1986), S. 336f.; OzsulValduriez (1991), S. 425ff.; Dadam (1996), S. 100ff. V gl. Conrad (1997), S. 75. Vgl. Conrad (1997), S. 75. Hinsichtlich der konkreten Vorgehensweise sind Mischformen dieser Grundvarianten denkbar. Vgl. hierzu OzsulValduriez (1991), S.433; Conrad (1997), S. 75. Vor- und Nachteile beider Formen werden auch in Dadam (1996), S. 100f., diskutiert. Beispiele zu den im folgenden genannten Konflikten finden sich in Deen/Amin/Taylor (1987), S. 861ff., sowie Kim/Seo (1991), S. 14ff. 1m folgenden sollen sich die Beispiele zur Verdeutlichung an relationalen Schemata orientieren.


mittelt werden, ob dieselbe Bezeichnung homonym in verschiedenen Bedeutungen

vorkommt.

Auf der Strukturebene konnen zahlreiche Differenzen auftreten, die sich aus einer

unterschiedlichen Modellierung der lokalen Schemata ergeben. Exemplarisch sollen

vier mogliche Konflikttypen kurz betrachtet werden.238

• Typkonflikte treten etwa auf, wenn ein bestimmtes Datenobjekt in einem Schema

als Relation, in einem anderen aber als Attribut abgebildet ist.

• Differenzen zwischen den Beziehungstypen erg eben sich, wenn die KardinaliUi

ten239 zwischen den Relationen nicht iibereinstimmen.

• Wenn unterschiedliche Attribute als Primarschliissel verwendet werden oder die

se verschiedenen Domanen angehoren, treten Schliisselkonflikte auf.

• Ein Verhaltenskonflikt ist z.B. beim Vorliegen von unterschiedlichen Integritats

bedingungen denkbar, die etwa im Rahmen referentieller Integritat zu kaskadie

rendem Loschen existenzabhangiger Entitaten fiihren konnen.

Neben dies en durch heterogene Schemata verursachten Konflikten sind inhaltliche

Konflikte moglich, wenn seman tisch identische Objekte unabhangig voneinander

mehrfach in den verschiedenen Datenbanken erfaBt werden.240 Auch das vielfach

auftretende Problem fehlender oder unvollstandiger Daten ist hier von Relevanz.

Zum AbschluB dieser Liste moglicher Konflikte bei der Integration von Datenbank

schemata soli auf funktionale Konflikte hingewiesen werden, die entstehen, wenn in

den Schemata hinterlegte Operationen aufgrund unterschiedlichen Funktionsum

fangs der verschiedenen lokalen Datenbanksysteme nicht in semantisch aquivalente

Operationen in einem globalen Datenmodell umgesetzt werden konnen.

3) Vereinheitlichungsphase: Die in der vorangegangenen Phase ermittelten Konflikte

miissen nun aufge16st werden. Erkannte Synonyme und Homonyme lassen sich noch

verhaItnismaBig einfach durch geeignete Umbenennungen beseitigen. Dagegen wird

die Auflosung der beschriebenen strukturellen Konflikte ungleich komplexer sein

und erscheint nur mit Hilfe fundierten Anwendungswissens moglich, wodurch eine

238

239

240

Vgl. zu diesen Konfliktarten Dadam (1996), S. 102. Zum Begriff der Kardinalitat vgl. z.B. March (1997), S. 41 und 43. Auf diese auch als "Ambiguitatsproblem" (Dadam (1996), S. 102) bezeichnete Konfliktart wird spater im Rahmen der Diskussion zur Konsolidierung von Daten in einem analyseorientierten Datenbanksystem noch ausfiihrlich eingegangen, vgl. Abschnitt 4.3.2.


Automatisierung dieses Prozesses sehr erschwert wird.241 So konnen etwa Typkon

flikte, die sich aus der Abbildung eines Datenobjektes als EntiUit einerseits oder als

Attribut anderseits ergeben, nur durch eine Umformung aufgelOst werden.242

4) Restrukturierungs- und Zusammenfiihrungsphase: In dieser letzten Phase werden

die nunmehr aneinander angepaBten Schemata in einem tibergeordneten Schema zu

sammengefaBt. Transformationsregeln stellen den Bezug zwischen den lokalen

Schemata und dem so entstehenden globalen Schema her. Dessen Qualitat kann an

hand der Kriterien Vollstandigkeit, Korrektheit, Minimalitat und Verstandlichkeit

tiberprtift werden.243

Die nachtragliche Integration von Datenbanksystemen zu einem verteilten System mit

einem globalen Schema erscheint unter diesen Gesichtspunkten als eine nahezu prohi

bitiv komplexe Aufgabe. Daher sollen im folgenden Realisierungsformen betrachtet

werden, die anstelle einer derart weitreichenden Integration einen Verbund aus mehre

ren Datenbanksystemen vorsehen, die - zumindest bis zu einem gewissen Grad - selb

standig sind. Solche Verbtinde werden in einer allgemeinen Definition als Multidaten

banksysteme bezeichnet.244

2.3.3.3 Multidatenbanksysteme

Der Einsatz eines Verbundes von Datenbanksystemen erscheint vielfach problem

adaquater als der Aufbau eines verteilten Datenbanksystems. Einerseits konnen so die

Probleme einer vollstandigen Schema- und Datenintegration vermieden werden, die

sich ergeben, wenn bereits existente Datenbanksysteme einbezogen werden sollen.

Andererseits erscheint diese Form auch dann sinnvoll, wenn zwischen Teildatenbe

standen nur sehr wenig Beziehungen existieren und keine komplexen Transaktionen

tiber mehrere Teildatenbestande hinweg erfolgen sollen. Dann lassen sich tiber eigen

standige Datenbanksysteme mit jeweils passenden Modelltypen moglicherweise die

Daten effizienter speichern und verwalten.

1m Unterschied zu den beschriebenen verteilten Datenbanksystemen ist also beim

Konzept der Multidatenbanksysteme keine logische Gesamtsicht und keine Vertei-

241

242

243

244

Vgl. OzsuNalduriez (1991), S. 439. Vgl. Batini/LenzerinilNavathe (1986), S. 347f., und Larson/NavathelElmasri (1989), S. 458ff. V gl. zu diesen Kriterien BatinilLenzerini/Navathe (1986), S. 349ff., und OzsulValduriez (1991), S. 440. V gl. Conrad (1997), S. 40f.


lungstransparenz mehr gegeben. Es liegen also Teilsysteme vor, die homogenen oder

heterogenen Charakters sind und tiber jeweils eigene Datenbestande verftigen. Eine

weitere Klassifikation von Multidatenbanksystemen kann anhand des Autonomiekrite

riums erfolgen: Sofern die Teilsysteme tiber eigenstandige Managementfunktionen

verfiigen und autonom agieren konnen, wird auch von fOderierten Datenbanksystemen

gesprochen. Entsprechend wird ein ZusammenschluB von nicht autonomen Kompo

nentensystemen als nicht fOderiertes Multidatenbanksystem bezeichnet.245 Diese Ab

grenzung zwischen foderiert und nicht foderiert stimmt im wesentlichen mit dem poli

tischen Begriff einer Foderation tiberein.

Die Schemaarchitektur von fOderierten Datenbanksystemen sieht nicht, Wle bei ver

teilten Datenbanksystemen, ein vollstandig integriertes konzeptionelles Schema vor,

welches die Existenz aller lokalen Schemata fiir den Benutzer verbirgt. Statt dessen

bleiben in einem fOderierten Datenbanksystem die bisherigen Einzelsysteme als Kom

ponentensysteme dieser Architektur weitgehend erhalten. Die Anwendungsprogramme

wickeln die Zugriffe auf die Datenbank unverandert tiber die lokalen Kommunikati

onsschnittstellen ab, so daB die Komponentensysteme in diesem Sinne auch ihre Auto

nomie behalten. Dies erscheint wesentlich, weil damit keine Migration der Anwen

dungs programme erforderlich ist, wie sie bei einer vollstandigen Schemaintegration

unter Aufgabe der lokalen Autonomie anfallen wtirde.246

Eine Kommunikation zwischen den bisher isoliert betriebenen Datenbanksystemen

wird bei dies em Konzept durch einen FOderierungsdienst ermoglicht. Dieser stellt fiir

globale Anwendungen entsprechende Zugriffsmoglichkeiten auf die Komponenten

systeme bereit. Abbildung 10 zeigt ein solches Architekturkonzept.

245

246

Diese Begriffssystematik orientiert sich an ShethlLarson (1990), S. 189f., sowie Conrad (1997), S.40f. Leider finden sich in den Begriffssystematiken bei der Benennung der verschiedenen Konzepte viele Homonyme und Synonyme. Wahrend hier foderierte Datenbanksysteme als Auspragung von Multidatenbanksystemen gesehen werden, beschreibt etwa Dadam (1996). S. 17f., letztere als sehr losen Verbund autonomer Systeme und ordnet foderierte Datenbanksysterne als Auspragung verteilter Datenbanksysteme mit teilweiser Autonomie der Komponentensysteme ein. Rahm (1994). S. 214 und 223ff., sieht dagegen Multidatenbanksysteme als Unterkategorie der fOderierten Datenbanksysteme. Fasnacht (1993), S. 81f., nennt weitere Begriffsabgrenzungen. Die hier vorgenommene Abgrenzung erscheint zweckdienlich, weil sie die begriffliche Trennung zwischen verteilten Datenbanksystemen mit deren gemeinhin enger und restriktiver Definition sowie sonstigen Architekturen mit mehreren Datenbanksystemen aufgreift. Nicht foderierte Multidatenbanksysteme solJen jedoch hier aufgrund der Abgrenzungsproblematik zu verteilten Datenbanksystemen nicht weiter betrachtet werden. V gl. Conrad (1997), S. 49f.

Architekturen und Komponenten

lokale Anwendungen

KomponentenDBS 1

KomponentenDBS n

fbderiertes Datenbanksystem

Abbildung 10: Allgemeine Architektur fOderierter Datenbanksysteme247

lokale Anwendungen

69

Flir die konkrete Ausgestaltung eines solchen Architekturkonzepts sind unterschiedli

che VorschHige in der Literatur zu finden.248 Sie erweitern die herkommliche

3-Schema-Architektur urn zusatzliche Schemata, die den Teil der Daten beschreiben,

der flir andere Systeme bereitgestellt werden soli (Import-lExport-Schema

Architektur249) oder urn ein globales fOderiertes Schema, das aile Datenmodellteile

integriert, die in der Foderation genutzt werden konnen (5-Schema-Architektur250).

Insgesamt ist angesichts der bereits dargestellten heterogenen Systemlandschaften und

auch der Erkenntnis, daB die Integration der Datenbestande ein erhebliches Nutzenpo

tential beinhaltet, erkennbar, daB Fragen der Kopplung verschiedenartiger Datenbank

systeme im Unternehmen an Bedeutung gewinnen. Insbesondere im Kontext der Ge

winnung von Daten flir analyseorientierte Informationssysteme erscheinen die Kon

zepte der verteilten und foderierten Datenbanksysteme als geeignete theoretische An

satze. Sie bilden die Basis zur Entwicklung von Vorgehensweisen zur Verknlipfung

verschiedenartiger Datenbestande aus unterschiedlichen Quellen.

247 248 249 250

Vgl. Conrad (1997), S. 49. Conrad (1997), S. 50ff., beschreibt verschiedene Ansatze und nennt entsprechende Quellen. V gl. HeimbignerlMcLeod (1985). V gl. ShethlLarson (1990). S. 1 98ff.

70 Operati ve Informationssysteme

In diesem Zusammenhang wird die Frage nach einer Beschreibung und Dokumentation

der vorhandenen Daten zunehmend wichtiger, denn eine - keineswegs se1bstverstand

lich erftillte - elementare Voraussetzung fUr einen Erfolg derartiger Bemtihungen ist

das Wissen urn die inhaltliche Bedeutung und die Struktur der vorhandenen Daten.

Daher soIl im folgenden eine Diskussion tiber Metadaten, zunachst im Umfe1d der

herkommlichen, transaktionsorientierten Systeme, erfolgen.

2.4 Metadatenverwaltung transaktionsorientierter Informationssysteme

Bei der Planung und Implementierung von Informationssystemen fallt wiederum se1bst

eine Vielzahl von Informationen an, mit denen diese Systeme beschrieben werden

konnen. Es werden beispielsweise umfangreiche Datenmodelle mit einer groBen An

zahl an Datenobjekten und Beziehungen aufgestellt. Dabei werden fUr jedes Element

in diesem Modell zahlreiche beschreibende Merkmale erfaBt.

Die so verftigbaren Informationen tiber die vorhandenen Datenobjekte werden haufig

unter dem Oberbegriff "Metadaten" zusammengefaBt. Eine pragnante, vielfach ver

wendete Kurzdefinition des Begriffs Metadaten lautet folglich "Daten tiber Daten".251

Entsprechend enthalten Metadaten hohere, beschreibende, klassifizierende Angaben

zum betrachteten Problemdatenbestand.252 Sie stellen damit eine Abstraktion der be

trieblichen Datenobjekte dar und fUhren den gespeicherten Anwendungsdaten einen

Sinngehalt und eine Bedeutung zu.

1m folgenden Abschnitt 2.4.1 werden zunachst kurz die verschiedenen Arten von Me

tadaten, wie sie in operativen Informationssystemen von Bedeutung sind, etwas naher

erlautert. Urn die Metadaten sinnvoll einsetzen und zur Dokumentation sowie zur

Steuerung und Kontrolle des Zugriffs auf die Problemdaten verwenden zu konnen,

sind sie in geeigneter Weise zu verwalten und strukturiert abzulegen. Es lassen sich

systematische Sammlungen von Metadaten bilden, die unter dem Begriff Data

Dictionary gelaufig sind.253 Sie konnen prinzipiell auch manuell, z.B. in Form eines

Karteikartensystems gefUhrt werden. Aufgrund der Komplexitat und der Moglichkeit

der Mehrfachverwendung dieser Informationen werden Data Dictionaries jedoch viel-

251

252 253

Vgl. z.B. Gabriel/Rohrs (1995), S. 158; RigneylFrank (1996). S. I; Devlin (1997). S.52; Mucksch (1997). S. C811.03; Chiang (1997). S.40. V gl. Gabriel/Rohrs (1995). S. III. Vgl. z.B. Schreier (1997). S. 103f.; Gabriel/Rohrs (1995). S. 158ff.

Metadatenverwaltung transaktionsorientierter Informationssysteme 71

fach auch als Anwendung eines Datenbanksystems implementiert. Entsprechend wird

dann von einem Data Dictionary-System gesprochen.254 Eine zusammenfassende Dar

stellung der wesentlichen Eigenschaften von Data Dictionary-Systemen ist Gegenstand

von Abschnitt 2.4.2.

Metadaten und Metadatenverwaltungssysteme sind seit vie len lahren Gegenstand

wissenschaftlicher Publikationen. Die Verbreitung entsprechender kommerzieller

Softwareprodukte in der Praxis ist jedoch weit hinter den Erwartungen zUriickgeblie

ben.255 Dies soli zum AniaB genommen werden, in Abschnitt 2.4.3 auf den Stellenwert

der aktiven Verwendung von Metadaten im Rahmen der operativen Informationsverar

beitung einzugehen.

2.4.1 Arten von Metadaten fUr transaktionsorientierte Informationssysteme

Implizit sind in jeder Software eine Vielzahl von Metadaten enthaiten, so z.B. Daten

satz- oder Variablendefinitionen in Anwendungsprogrammen, Tabellendefinitionen in

Datenbanksystemen oder auch in Datenbankviews, die ein Datenzugriffsberechti

gungskonzept abbilden. 1m Einzelfall kann es sich fUr konkrete Datenobjekte dabei urn

Angaben zu den Datentypen, den Formatvorschriften, den Prtifbedingungen und den

verwendenden Instanzen handeln.256 Die gespeicherten Daten gewinnen erst in Ver

bindung mit den Metadaten eine Bedeutung. Sie sollen, indem sie systematisch ge

sammelt werden, auch tiber ihre funktionale Notwendigkeit im Rahmen der Software

hinaus verwendet werden konnen.

Diese Abgrenzung des Begriffs "Metadaten" stellt sehr stark auf die statisch

syntaktische Struktur der abgelegten Datenbestande und der relevanten Umgebungs

objekte abo Eine Berticksichtigung von Informationen tiber die lebenswirkliche Be

deutung dieser Daten erfolgt damit nicht. Dartiber hinaus kann aber auch eine Vielzahl

weiterer Metadaten, die eher Dokumentationscharakter haben und tiber die physischen

Datendefinitionen hinausgehen, wie z.B. benutzerorientierte Beschreibungen, erfaBt

und genutzt werden. Daneben sind auch funktions- und prozeBbezogene Aspekte rele

vant, welche die Herkunft und Verwendung der Daten beschreiben.

254

255

256

Von einer genauen Abgrenzung der zahlreichen in der Literatur anzutreffenden ahnlichen, nur teilweise synonym verwendeten Begriffe soli hier abgesehen werden. Vgl. dazu, insbesondere zu den Begriffen Data Dictionary und Repository, HabermannlLeymann (1993), S. 216ff. V gl. Eicker (1994), S. 15ff. V gl. Gabriel/Rohrs (1995), S. Ill.


Dies ftihrt zu einem breiter angelegten Begriffsverstandnis, nach dem unter Metadaten

solche Daten verstanden werden, die die Bedeutung und Struktur geschaftsrelevanter

Daten sowie die Regeln zu deren Entstehung, Bearbeitung und Nutzung beinhalten.257

Damit werden also zusatzlich zu den Metadaten, die die Datenstrukturen betreffen,

sowohl die semantische Ebene der Bedeutung der Daten als auch funktionale Aspekte

der dynamischen Nutzung der Datenbestande in das Begriffsverstandnis einbezogen.

Hier soli dem wei ten Begriffsverstandnis der Metadaten gefolgt werden. Demzufolge

umfassen Metadaten aile Informationen tiber Daten, die sowohl die statische Struktur

als auch die dynamische Verwendung und damit auch die relevanten, auf die Daten

einwirkenden Prozesse und Objekte der Systemumgebung betreffen. Dabei ist es zu

nachst unerheblich, auf welchem Abstraktionsniveau sich die Metadaten bewegen, d.h.

ob es sich urn sehr implementierungsnahe Angaben oder eher urn allgemeine Modelle

auf semantischer Ebene handelt. Demzufolge umfassen Metadaten sowohl z.B. Daten

satzbeschreibungen in COBOL-Programmen oder SQL-CREATE-Statements als auch

Entity-Relationship-Diagramme, Funktionsbaume, Petrinetze etc.258

2.4.2 Verwaltungssysteme fUr Metadaten

Data Dictionary-Systeme enthalten mit den Metadaten einerseits Daten tiber die Ob

jekte, Eigenschaften und Beziehungen der Datenverarbeitungswelt und damit Daten

tiber die Daten der realen Welt. Andererseits werden dartiber hinaus im Data

Dictionary Informationen tiber die auf die Daten zugreifenden Programme, tiber Be

nutzer und deren Zugriffsrechte sowie tiber Aspekte der physikalischen Datenspeiche

rung verwaltet.259 Es handelt sich urn eine Datenbank, die als zentrales, organisiertes

Referenzwerk zur Ablage aller Metadaten dient. 260

Zusatzlich gehoren zu einem Data Dictionary-System Funktionen zur Auswertung der

Daten, Werkzeuge zur Sicherstellung z.B. der Datenintegritat und -sicherheit des Data

Dictionary und Schnittstellen zu den Anwendungsprogrammen, die die im Data

Dictionary gespeicherten Informationen verwenden sollen.261 Da es sich bei einem

257

258

259

260

261

"Metadata - Data that describes the meaning and structure of business data, as well as how it is created, accessed, and used." Devlin (1997), S. 52. V gl. Biethahn/MuckschlRuf (1997), S. 235. Vgl. DeMarco (1978), S. 126. Vgl. Martin (1988), S. 241. Vgl. Allen/Loomis/Mannino (1982), S. 247.


Data Dictionary-System gleichzeitig auch selbst urn ein Datenbanksystem flir einen

konkreten Anwendungsfall handelt, kann analog auch die allgemeine Architektur eines

Datenbanksystems zur Beschreibung herangezogen werden.262

Data Dictionary-Systeme weisen wie Datenbanksysteme Pflegefunktionen auf, die es

erlauben, die Metadaten in das Data Dictionary einzubringen und fortzuschreiben.

Diese Datenpflege wird teilweise durch maschinelle Prozesse ausgelost, die auf das

Data Dictionary zugreifen. Manuelle Eingaben erfolgen tiber Online-Schnittstellen.

Analog zu anderen Datenbanksystemen haben auch Metadatenbanken Abfrage- und

Ausgabeschnittstellen implementiert. Generierungsfunktionen im Data Dictionary

System ermbglichen, anhand der Metadaten automatisiert z.B. Datenbankdefinitions

skripten in SQL-Syntax oder Datenstrukturdefinitionen in gangigen Programmierspra

chen flir das Zielsystem zu erstellen. Weitere mbgliche Funktionen dienen zu Analyse-,

Prtif- oder Sicherheitszwecken.263 "Reverse-Engineering"-Komponenten haben die

Aufgabe, bestehende Datenbanksysteme hinsichtlich ihrer Strukturen zu untersuchen

und die gefundenen Objekte als Modelle darzustellen.

Data Dictionary-Systeme kbnnen nach verschiedenen Kriterien kategorisiert werden.

Dabei wird aus unterschiedlichen Blickwinkeln im wesentlichen die Nahe zum eigent

lichen Datenbanksystem mit den Problemdaten und der Haupteinsatzzweck des Data

Dictionary betrachtet.264 Mit unterschiedlichen Kombinationen der Kategorisierungs

merkmale lassen sich nach dem Verwendungszweck vier verschiedene Varianten von

Data Dictionary-Systemen unterscheiden: 265

• Eingebettete Data Dictionaries, die auch als Datenkataloge bezeichnet werden, sind

integraler Bestandteil relationaler Datenbanksysteme.266 Diese kbnnen als die wohl

am weitesten verbreiteten Data Dictionary-Systeme angesehen werden. Sie stellen

eine eigene, in diesem Datenbanksystem abgelegte Datenbank dar, so daB einige der

oben genannten Funktionen des Data Dictionary-Systems, wie Pflege- und Report

funktionen, vom Trager-Datenbankmanagementsystem wahrgenommen werden

kbnnen. Die im Data Dictionary gespeicherten Metadaten sind wie die eigentlichen

262

263

264

265

266

V gl. Gabriel/Rohrs (1995), S. 159. Vgl. Stiilpnagel (1984), S. 64. Zur Klassifikation werden als Merkmale vielfach die Begriffspaare aktiv/passiv, primar/sekundar und abhangiglunabhangig verwendet. V gl. z.B. Gabriel/Rohrs (1995), S. 160ff.; Myrach (1994), S. 6ff.; HabermannlLeymann (1993), S. 16 und S. 235f. V gl. Schreier (1997), S. 103f. Vgl. Codd (1990), S. 277; Allen/Loomis/Mannino (1982), S. 259f.


Benutzerdaten auch in einer Tabellenstruktur abgelegt und konnen vom Benutzer

abgefragt werden.267 Eine Veranderung der in den Dictionary-Tabellen abgelegten

Informationen tiber Tabellen und Spalten durch das Eingeben von Datenmanipulati

onsbefehlen verletzte allerdings die Integritat der Datenbank und ist daher nicht

moglich. Diese Eintrage im Dictionary werden automatisch bei Anderungen an der

Benutzerdatenbank aktualisiert. So flihrt etwa die Data Dictionary-Anweisung

"create table" zur Einfligung der Tabellen- und Spaltendefinitionen der so angeleg

ten Tabelle in die entsprechenden Tabellen des Dictionaries.

• Auch die Metadaten- und Dokumentationsspeicherkomponente in CASE-Systemen

wird als Data Dictionary bezeichnet. Hier konnen neben den Datenmodellen flir die

mit dies en Systemen abgebildeten Anwendungen idealerweise auch semantische In

formationen wie z.B. Begriffsdefinitionen und Geschaftsregeln abgelegt werden.268

• Als dritte Variante konnen Data Dictionary-Systeme angesehen werden, die als

eigenstandiges Programm die Metadaten aller im Unternehmen eingesetzten Daten

banksysteme und Anwendungen verwalten. Diese Systeme konnen der zentralen

Definition, Dokumentation und Administration der Datenstrukturen dienen, so daB

bei konsequentem Einsatz eine unternehmensweite Datendokumentation entsteht.

• SchlieBlich wird der Begriff Data Dictionary auch im Zusammenhang mit Werkzeu

gen zur deskriptiven Programmierung von Benutzungsoberflachen flir Datenbank

anwendungen verwendet. Hier wird der Aspekt betont, daB auch Informationen tiber

die Verwendung der Datenstrukturen, z.B. in den Masken der Benutzungsoberfla

chen, nachgewiesen werden sollen.

Die verschiedenen Arten von Data Dictionary-Systemen konnen also der Abbildung

ganz unterschiedlicher Metadaten dienen. Die Spanne reicht von struktur- und funkti

onsbezogenen Angaben, die flir den Betrieb der Systeme unmittelbar notwendig sind

und syntaktische Informationen liefern, bis hin zu semantischen Informationen, die

dem Data Dictionary mehr die Bedeutung einer Datenbank tiber die Geschaftsobjekte

und ihre Zusammenhange geben.

Zu hinterfragen ist, welcher Stellenwert den unterschiedlichen Systernklassen und den

darin verwalteten Informationsarten im Unternehmen gemeinhin zugemessen wird.

Darauf wird im nachsten Abschnitt eingegangen.

267

268 V gl. Date (1985), S. 165. Vgl. Rauh/Sticke1 (1997), S. 301.

Metadatenverwaltung transaktionsorientierter Informationssysteme

2.4.3 Stellenwert von Metadaten im Rahmen der operativen Informations

verarbeitung

75

Im vorhergehenden Abschnitt sind unterschiedliche Varianten von Data Dictionary

Systemen mit ihren Funktionen beschrieben worden. Daraus geht bereits hervor, daB

diese Systeme und damit die Metadaten im Rahmen der operativen Informationssyste

me nahezu ausschlieBlich fUr die Entwicklung, Administration und den Betrieb der

entsprechenden Systeme eingesetzt werden. Der Dokumentationscharakter der Meta

daten wird genutzt, urn grundlegende Strukturen und Prozesse im Rahmen von Daten

und Funktionsmodellen tibersichtlich darzustellen. Ftir die Anwendungsentwickler

dienen sie als Orientierungshilfe bei der Applikationsentwicklung, bieten aber auch

wesentliche Untersttitzungsfunktionalitat bei der Gewahrleistung von Konsistenz,

Datenschutz und Datensicherheit. Der Systemadministrator kann die Metadaten bei

Modifikationen an Datenstrukturen wie auch bei Belastungstibersichten ausgezeichnet

verwenden. Die Metadaten leisten damit insgesamt wertvolle Hilfestellung bei unter

schiedlichen Aufgaben auf der Back-End-Seite der Systeme.

Allerdings ist zu erwarten, daB in erster Linie Metadaten erfaBt und verwendet werden,

die sich im Rahmen der Systemdefinition und -entwicklung ohnehin ergeben. Eine

systematische Erfassung und Pflege von Metadaten, die auch semantische Informatio

nen wie z.B. Definitionen wichtiger Kennzahlen enthalten, unterbleibt jedoch hau

fig. 269 Die Grtinde dafUr mogen vielfiiltig sein. Es kann wohl angenommen werden,

daB in Systementwicklungsprojekten mit ihren gemeinhin engen Zeit- und Kostenpla

nen die Bereitschaft fehlt, sich strukturiert mit solchen Fragestellungen auseinanderzu

setzen, die eher tibergreifenden Charakter haben und nicht unmittelbar zur Erreichung

eines konkreten Zieles in einem Projekt zur Entwicklung von Software fUr operative

Zwecke dienen. Dieses Problem verschiirft sich durch den vielfach diskutierten An

wendungsstau im Rahmen der Softwareentwicklung: Der Mangel an Metadaten und

die fehlenden Ressourcen zu deren Sammlung fUhren zu mangelnder Information tiber

die vorhandenen Datenbestande, so daB bei wachsendem Bedarf nach Daten neue,

ebenfalls schlecht dokumentierte Datenbestande aufgebaut werden, obwohl bei ent

sprechendem Wissen auch die vorhandenen Daten genutzt werden konnten.270

269

270 V gl. Myrach (1994), S. 268. Brackett (1996), S. 187, spricht in diesem Zusammenhang von einem "Teufelskreis".


Es kann insgesamt daher nicht angenommen werden, daB flir die Landschaft operativer

Systeme im Unternehmen eine konsistente und umfassende Metadatenbasis vorliegt,

die die verschiedenen Anwendungen und Datenbanksysteme gleichermaBen abdeckt

und zentralisiert als Speicher und Quelle aller Metadaten dient. 271

Die Endbenutzer, die mit den operativen Anwendungsprogrammen arbeiten, werden

kaum mit Metadaten wie z.B. genauen, semantischen Datendefinitionen in Beriihrung

geraten. Deren Arbeit ist vielfach charakterisiert durch das routinemaBige Ausftillen

von Bildschirmmasken, wo in vordefinierte Eingabefelder Werte einzutragen sind bzw.

Ausgaben abgelesen werden kannen. Die Oberflachen dieser Systeme sind vergleichs

weise starr und exakt flir den jeweiligen Anwendungsbereich vorstrukturiert. Metada

ten treten hier insofern in Erscheinung, als die Beschriftung auf den Bildschirmmasken

den angezeigten Werten eine Bedeutung zuweist und somit eine Interpretation erlaubt.

Der sehr begrenzte Geltungsbereich solcher Metadaten ist insoweit ohne Bedeutung,

als der Benutzer sich ohnehin nicht aus dieser festen Zuordnung von Daten und Pro

gramm lasen soli und kann. So werden spontane, nicht im System vorgesehene Zu

sammenstellungen von Informationsobjekten zur Befriedigung von Ad-hoc-Informa

tionsbedtirfnissen in der Regel nicht untersttitzt. Zwar lassen sich Berichte und Reports

parametergesteuert anstoBen und damit in Grenzen individualisieren, die Kernfunktio

nalitat allerdings operiert auf der Basis vorgedachter Mentistrukturen und Bildschir

maufbauten.

Da somit Metadaten, die tiber die implizit in der Software enthaltenen Strukturinfor

mationen hinausgehen, flir das "Tagesgeschaft" im Unternehmen kurzfristig nicht von

existentieller Notwendigkeit sind, weil die entsprechende Software ja auch ohne diese

funktioniert, unterbleibt haufig deren systematische, unternehmensweit konsistente

Aufbereitung. Als Folge kann beobachtet werden, daB in den meisten Unternehmen

keine Metadaten vorliegen, die in Qualitat und Umfang zufriedenstellen kannen. So

fern tiberhaupt explizit formulierte Metadaten vorliegen, sind sie haufig unvollstandig,

veraltet, unprazise formuliert oder unverstandlich.272 Insbesondere wichtige, allerdings

eher unstrukturierte Metadaten, wie beispielsweise Definitionen geschaftsrelevanter

Begriffe oder Regeln zur Datentransformation zwischen verschiedenen Anwendungen,

sind vielfach nicht schriftlich fixiert, sondern durch das Erfahrungswissen der entspre

chenden Mitarbeiter gegeben. Sie werden einzelfallbezogen festgelegt und angewen-

271

272 Vgl. Myrach (1994), S. 302. Vgl. Brackett (1996), S. 185.


det, ohne daB unternehmensweit gtiltige Regeln vorliegen, die zu beachten waren.

Auch wenn die Metadaten schriftlich dokumentiert sind, kann mangels des flachen

deckenden Einsatzes eines Data Dictionary-Systems vielfach beobachtet werden, daB

die gesuchten Informationen in heterogenen, unvollstandigen und moglicherweise nur

schwer aufzufindenden Dokumenten verteilt vorliegen.273

Insgesamt kann festgehalten werden, daB Metadaten in operativen Informationssyste

men im Unternehmen zwar in unterschiedlichster Form tiber die einzelnen Teilsysteme

hinweg verstreut vorhanden sind, eine effiziente Nutzung jedoch vielfach nicht statt

findet. Dies mag aus den genannten Grunden unbefriedigend sein, trotzdem sind darnit

aus der Sicht der Anwender keine Beeintrachtigungen verbunden, weil die einzelnen

Anwendungsprogramme auch dann funktionieren, wenn keine programmtibergreifende

Konsistenz der Metadaten vorliegt.

Urn die Potentiale der Informationstechnologie moglichst weitgehend im Wettbewerb

einsetzen zu konnen, sollten jedoch Mitarbeiter aller Hierarchiestufen in die Lage

versetzt werden, auch Informationen aus verschiedenen Quellen DV -gesttitzt zu verar

beiten.274 Vor diesem Hintergrund hat der Aufbau analyseorientierter Informationssy

sterne in den letzten lahren an Bedeutung gewonnen. Hier wird erkennbar, daB der

Mangel an organisationsweit konsistenten Metadaten die Zusammenftihrung der ver

schiedenen operativen Quellen signifikant erschwert. Daher kann es als erster und

sicherlich groBer Schritt in soIchen Projekten gesehen werden, wenn zunachst die

Metadaten zusammengefiihrt werden.

Ein erster Ansatz, verschiedene Datenbestande im Unternehmen zu konsolidieren und

so auch anwendungstibergreifend besser nutzbar zu machen, liegt daher im Aufbau

einer gemeinsamen Metadatenbasis durch Integration und Konsolidierung vorhandener

Metadaten. Hier rticken allerdings Uberlegungen ins Blickfeld, die analoge Probleme

wie bei der Schemaintegration verteilter Datenbanksysteme275 erkennen lassen.

Konsolidierte Metadaten konnen also den Informationsaustausch auch zwischen den

verschiedenen operativen Systemen offensichtlich erleichtern. Der folgende Abschnitt

begrtindet die Notwendigkeit soIcher Austauschbeziehungen und geht auf Problembe

reiche ein.

273

274

275

V gl. Brackett (1996), S. 186ff. Vgl. Mucksch (1997), S. C811.05. V gl. Abschnitt 2.3.3.2.


2.5 Datenaustausch auf operativer Ebene

Herkommliche operative Systeme bilden iiberwiegend Funktionsbereiche oder Abtei

lungen abo Aus einer integrierten Sichtweise auf das gesamte Unternehmensgeschehen

handelt es sich dabei jedoch urn mehr oder minder kiinstliche Grenzen, bestehen doch

erhebliche Interdependenzen zwischen dies en Bereichen und den Daten, die dort ent

stehen und in den Informationssystemen gespeichert sind. So filhrt beispielsweise eine

Anderung von Verrechnungspreisen in der Kostenrechnung zu einer Umbewertung

von Lagerbestanden, die wiederum Umbuchungen in den Finanzbuchhaltungspro

grammen aus16sen.276 Analog filhrt ein eingehender Kundenauftrag zu einer Anwei

sung an die Fertigungsplanung, die in einem nachsten Schritt Implikationen auf die

Materialwirtschaft hat. Sind die entsprechenden Programme als Insellosungen reali

siert, miissen bei der Abwicklung dieser Datenstrome immer wieder Struktur- und

Medienbriiche iiberwunden werden, die z.B. entstehen, wenn eine Koordination iiber

papiergebundene Belege erfolgt. Die entstehenden Nachteile sind offensichtlich: Ne

ben die Effizienzverluste durch den mehrfachen manuellen Eingabeaufwand tritt die

Gefahr von Erfassungsfehlern und die der versehentlichen Unterbrechung von Prozes

sen, wenn etwa ein Kundenauftrag nicht an die Fertigungsplanung gemeldet wird.

Derartige Fehler lassen sich zudem nur schwer entdecken, da iibergreifende Integri

tatspriifungen, die falsche oder verlorengegangene Daten identifizieren, nicht durchge

filhrt werden konnen.

Verschiedene Ansatze dienen der Verbesserung der Datenfliisse auf operativer Ebene.

Als wesentlicher Trend ist hier die Migration zu integrierten Anwendungssystemen zu

nennen, bei denen innerhalb des Wirkungsbereichs dieser Systeme die Prozesse auch

hinsichtlich der Datenstrome entsprechend abgebildet sind. Die volle Wirkung konnen

diese Systeme hinsichtlich der Automatisierung der Datenstrome jedoch nur entfalten,

wenn sie "flachendeckend" verwendet werden. Daneben stellen sie Schnittstellen be

reit, die durchgangige Datenfliisse auch zu Fremdsystemen ermoglichen sollen.

Neben der Einfilhrung integrierter Losungen existieren weitere Konzepte, die einen

vereinfachten Datenaustausch ermoglichen konnen. Eine effizientere Gestaltung der

Datenfliisse im Unternehmen unter Inkaufnahme der Struktur- und Medienbriiche laBt

sich etwa durch maschinell lesbare Belege realisieren. Sie erscheinen als ein durchaus

geeignetes Medium, urn bei nur kleinen zu iibertragenden Datenmengen pro Vorgang

276 Beispiel in Anlehnung an Mertens (I 997a). S. 9.

Datenaustausch auf operati ver Ebene 79

die vielfaltigen Probleme, die sich aus einer technischen und organisatorischen Inte

gration ergeben, zu umgehen. Unter dem Stichwort "Workflow-Management-System"

wird eine Vielzahl von Konzepten verstanden, die eine prozeBorientiertere Betrachtung

der Datenstrome im Unternehmen untersttitzen sollen und einzelne Vorgange von

Abteilung zu Abteilung transportieren.277 Deren Anwendungsfeld umfaBt nicht nur die

eingangs in den Beispielen erwahnten Buchungsfalle, sondern auch weniger struktu

rierte Vorgange, wo sie primar dem Datentransport und der Protokollierung dienen.

Datenaustausch zwischen operativen Systemen erscheint dariiber hinaus nicht nur

innerhalb des Unternehmens betrachtenswert, sondern auch im Kontext der Beziehun

gen zu Geschaftspartnern. 1m unternehmenstibergreifenden Datenaustausch und in der

damit einhergehenden Vermeidung von Medienbrtichen und der Beschleunigung der

Kommunikation von strukturierten Geschaftsnachrichten, wie z.B. Bestellungen oder

Rechnungen, wird ein hohes Rationalisierungspotential und ein geeignetes Instrument

zur Verbesserung der strategischen Position gesehen.278 Hier verbietet sich eine weit

gehende Integration der beteiligten Informationssysteme, so daB statt dessen moglichst

standardisierte Datenaustauschformate als notwendig erscheinen. Entsprechende Kon

zepte werden als ED! (Electronic Data Interchange) diskutiert. 279 EinheitIiche Formate

werden primar branchenspezifisch entwickelt und genutzt (etwa in der Automobilindu

strie, im Versicherungs- und im Bankwesen), die mit EDIFACT angestrebte Branchen

und landertibergreifende Norm konnte dagegen bisher nicht etabliert werden.280

Datenaustauschbeziehungen auf der operativen Ebene werden weitgehend mit sehr

strukturierten Daten und in vergleichsweise geringem Umfang durchgeftihrt. Trotzdem

sind zahlreiche Erschwernisse erkennbar, die erahnen lassen, daB sich eine Ubertra

gung weiter Teile der Datenbestande in analyseorientierte Systeme als nicht-triviale

Aufgabe darstellt. 1m folgenden werden diese analyseorientierten Informationssysteme

zunachst isoliert betrachtet, bevor die Fragen hinsichtlich ihrer Datenversorgung in den

Mittelpunkt rticken.

277

278

279

280

Vgl. zu Workflow-Management-Systemen im Kontext einer Integration der Informationsverarbeitung Mertens (1997a), S. 13f. KlaggelNettiWindler (1998), S. 36ff., nennen entsprechende Nutzeffekte. Zu den strategischen Aspekten vgl. auch Mertens (1997a), S. 16f. Grundlagen zu den verschiedenen EDI-Konzepten und Standards erortern Klagge/Nett/Windler (1998), S. Iff.; Picot/NeuburgerlNiggl (1993), S. 20ff., und Hansen (1996), S. 401 ff. Hier existieren statt des sen zahlreiche Varianten, die der angestrebten Unabhangigkeit entgegenwirken. Vgl. KlaggelNettlWindler (1998), S. 8f.

Analyseorientierte Informationssysteme 81

3 Analyseorientierte Informationssysteme

Informationen sind ein wesentliches Element des betriebswirtschaftlichen Geschehens

und ein bedeutsamer Faktor im ProzeB der Leistungserstellung im Unternehmen.281 1m

vorhergehenden Kapitel wurden Moglichkeiten und Infrastrukturen beschrieben, In

formationen fUr das operative Geschehen im Unternehmen datenbankbasiert zu spei

chern und zu verarbeiten.

Diese operativen Systeme konnen den Anforderungen, die man heute an Informations

systernkomponenten zur Versorgung mit Informationen fUr Entscheider stellt, nicht

gerecht werden. Die Anwendungssysteme dieser Kategorie dienen in erster Linie der

Automatisierung der Massendatenverarbeitung und konnen die Losung eher einfacher,

strukturierter Entscheidungsprobleme untersttitzen.282 Die Betrachtung und Auswer

tung der Daten erfolgt auf sehr detaillierter Ebene und gilt primm dem einzelnen Ge

schaftsvorfall. Die einzelnen Systeme sind meist nur in geringem Umfang mit denen

anderer Abteilungen oder Funktionsbereiche integriert. Folglich ist der Nutzungshori

zont der in ihnen befindlichen Daten eingeschrankt. Fiir eine Ausweitung der Be

trachtungsebene hin zu Daten, die eine Vielzahl von Geschaftsvorfallen betreffen und

z.B. abteilungs- und periodeniibergreifend strukturiert werden konnen, eignen sich

diese Systeme dagegen ebenso wenig wie fUr eine aggregierende Sicht auf die Daten.

Zwar konnen fest programmierte Berichte erzeugt werden, die diese Sichten nachvoll

ziehen, dadurch wird jedoch der gewiinschten Flexibilitat bei der Informationsversor

gung nicht Rechnung getragen. Die betriebliche Informationssystempyramide umfaBt

daher neben den operativen Systemen auch analyseorientierte Informationssysteme, die

eine adaquatere DV-Unterstiitzung fUr Fach- und Fiihrungskrafte bieten, deren Aufga

ben weniger strukturiert und parametrisiert sind als die der Nutzer operativer Systeme.

In diesem Kapitel erfolgt zunachst in Abschnitt 3.1 eine Einordnung der verschiedenen

Formen analyseorientierter Informationssysteme in den Gesamtzusammenhang der

Informationsverarbeitung im Unternehmen. AuBerdem wird das Konzept eines zentra

lisierten Datenspeichers fUr Analysezwecke eingefUhrt. Der Abschnitt 3.2 widmet sich

dann Datenmodellen und Reprasentationsformen, die sich zur Abbildung der fUr diese

Anwendungen spezifischen Daten- und Problemstrukturen besonders eignen. In Ab-

281

282 V gl. Wacker (1971), S. 41; PicotIFranck (1988), S. 544. Vgl. BehmelMucksch (I 998b), S. 13.


schnitt 3.3 werden die einzelnen Komponenten des Gesamtkomplexes "analyseorien

tiertes Informationssystem" beschrieben, bevor im folgenden Abschnitt spezifisch auf

den Aspekt der Metadaten eingegangen wird. Den AbschluB und einen Dbergang zu

den folgenden Kapiteln bildet aufgrund deren besonderer Bedeutung flir diese Arbeit

eine Beschreibung der Schnittstellen, die ein analyseorientiertes Informationssystem zu

den Vorsystemen aufweist (Abschnitt 3.5).


Informationssysteme flir die Bewaltigung der operativen Aufgaben im Unternehmen

sind seit vielen Iahren erfolgreich im Einsatz und leisten in nahezu jeder Unterneh

mung unverzichtbare Dienste. Sie bauen auf den im vorhergehenden Kapitel zusam

mengefaBten Technologien auf und werden aufgrund der ausgepragten Transaktions

orientierung der durch sie untersttitzten Aufgaben vielfach auch als OLTP (On-Line

Transactional Processing)-Systeme bezeichnet.

So bilden Administrations- und Dispositionssysteme z.B. die Basis flir die Verwaltung

von Kunden-, Produkt- und Lieferantenstammdaten und flir die Erfassung, Bearbeitung

und Abrechnung von Bestellungen, Produktionsvorgaben und Kundenauftragen. Diese

Systeme sind als Standardsoftware flir Branchen oder Funktionen erhaltlich und gelten

als ausgereifte Produkte zur Erledigung des "Tagesgeschafts" im Unternehmen.

Weniger kiar stellt sich die Situation in bezug auf Systeme zur Unterstiitzung analyti

scher bzw. dispositiver Tatigkeiten dar. Bereits seit vielen Iahren wird versucht, auch

flir diese Tatigkeitsbereiche eine aufgabenadaquate DV -Unterstiitzung bereitzustellen,

ohne daB derartige Systeme den Durchbruch in der Praxis erzielten.283 Trotzdem lie

fern sie die konzeptionellen Gundlagen auch der modernen Anwendungen zur Unter

sttitzung analytischer Aufgaben. Daher wird im folgenden Abschnitt ein kurzer Dber

blick tiber die Evolution solcher Systeme gegeben.

Mit dem Aufkommen neuer Technologien und neuer Konzepte ist die Idee einer spezi

fischen Informationsversorgung flir Fach- und Ftihrungskrafte zu Analysezwecken

heute wieder verstarkt in die Diskussion in Wissenschaft und Praxis geriickt. 1m Mit

telpunkt der Diskussion stehen vielfach die Begriffe "OLAP" und "Data Warehouse",

aber auch viele andere neue Ausdriicke ("Data Mining", "Data Mart" usw.) werden in

283 Zu den Griinden fUr dieses Scheitem vgl. z.B. Chamoni/Gluchowski (I 998b), S. 8ff.


Publikationen und Produktbeschreibungen verwendet. Die terminologische Abgren

zung dieser Konzepte ist Gegenstand von Abschnitt 3.1.2.

3.1.1 Stellenwert analyseorientierter Informationssysteme im Unternehmen

Mit der Verbreitung der elektronischen Datenverarbeitung fUr operative Zwecke im

Unternehmen und dem daraus resultierenden Anwachsen groBer Datenmengen ent

stand bereits in den sechziger Jahren der Wunsch nach der Extraktion entscheidungs

relevanter Informationen aus diesen Daten, urn sie auch als Grundlage fUr Manage

mentaufgaben verwenden zu konnen. Dies resultierte aus der Erkenntnis, daB relevante

und aktuelle Informationen dazu beitragen konnen, qualitativ bessere Entscheidungen

zu treffen und so Wettbewerbsvorteile zu erzielen. Insofern kann Information als stra

tegische Waffe im Wettbewerb verstanden werden. Daneben werden Informationen

heute zunehmend zu einem eigenstandigen Produkt oder dienen der ErschlieBung

neuer Geschaftsfelder. Folgt man daher der Einschatzung, Information sei die unter

nehmerische Ressource schlechthin,284 muB auch der Bereitstellung einer modernen

Infrastruktur zur entscheidungsuntersWtzenden Nutzung von Daten ein sehr hoher

Stellenwert eingeraumt werden.

Unter dem Begriff Management Information System (MIS)285 wurden zu Beginn die

ser Entwicklung entsprechende Informationssysteme aufgebaut, die sich jedoch auf

grund der seinerzeit mangelnden technischen Moglichkeiten als nicht erfolgreich er

wiesen.286 Auch unterblieb eine sachgerechte Aufbereitung der gelieferten Daten zu

entscheidungsrelevanten Informationen, so daB kritisiert wurde, diese Systeme fUhrten

zu einem UberfluB an irrelevanten Fakten, deren Bewaltigung wiederum erhebliche

Ressourcen verbrauche.287 Trotzdem kann in diesen Systemen die konzeptionelle

Grundlage fUr das bis heute iibliche Berichtswesen im Unternehmen gesehen wer

den.288

284 285

286

287 288

V gl. Picot/Franck (1988), S. 544. Entgegen dieser Begriffsverwendung wird in der englischsprachigen Literatur unter einem Management Information System teilweise auch die Gesamtheit der Informations- und Kommunikationssysteme einer Organisation verstanden, vgl. LaudonlLaudon (1994), S.21; Davis/Olson (1985), S. 6ff.; Davis (I 997c), S. 138; Stahlknecht/Hasenkamp (1997), S. 426;. Zu einer ausfiihrlichen Beschreibung der Merkmale von Managementinformationssystemen vgl. Gluchowski/GabriellChamoni (1997), S. 150ff. Vgl. GluchowskilGabriellChamoni (1997), S. 162f.; Koreimann (1971), S. 1Of. Vgl. Chamoni/Gluchowski (I 998b), S. 7.


Mit Decision Support Systemen (DSS, bzw. Entscheidungsunterstiitzungssystemen,

EUS) wurde versucht, neben der Versorgung mit Daten auch Verfahren zur Problem

strukturierung und Problemlosung anzubieten, indem Modell- und Methodenbankele

mente in das System integriert wurden.289 Durch Konzentration auf iiberschaubare

Funktionsbereiche strebte man konkrete Teillosungen an. Derartige Systeme sollen in

eher schlecht strukturierten Entscheidungssituationen eine Unterstiitzung durch mit

Hilfe der Modelle und Methoden generierte Informationen liefern.290 Es handelt es

sich urn anerkannte Werkzeuge zur Entscheidungsunterstiitzung fUr abgrenzbare und

bereits wahrgenommene Probleme, die vielfach auf der Basis von Tabellenkalkulati

onsprogrammen entstanden sind. Sie werden zumeist eher von spezialisierten Fachan

wendern als von Entscheidungstragern hoherer Hierarchiestufen genutzt.291 Problema

tisch erscheint der dezentrale Einsatzcharakter solcher Werkzeuge, der eine Integration

zu einer unternehmensweiten Gesamtlosung erschwert und die Gefahr inkonsistenter

Ergebnisse beinhaltet. Dies ergibt sich insbesondere aus dem Verstandnis des DSS als

lebendigem Softwareprodukt, das den sich wandelnden Benutzeranforderungen immer

wieder angepaBt wird.292

Der Trend, die im Unternehmen vorhandenen Datenverarbeitungssysteme zu vernet

zen, sowie das Aufkommen anwenderfreundlicher Benutzungsoberflachen schafften

die technischen Voraussetzungen, leistungsflihigere Systeme zur Unterstiitzung von

Entscheidungstragern bei der Informationsbeschaffung und -weitergabe aufzubauen.

Unter Bezeichnungen wie Executive Information System (EIS)293 wird ein erweiterter

Funktionsurnfang angeboten, der auch verbesserte Moglichkeiten zur Prasentation der

Daten einschlieBt. Neuartige Techniken ermoglichen hier ein "intuitives" Navigieren.

So erlaubt es etwa das Drill Down, einem Problem schrittweise durch das Anzeigen

entsprechender Detailinformationen auf den Grund zu gehen. Exception Reporting,

z.B. durch Color Coding, hebt auffallige Informationen besonders hervor. Einem ge

stiegenen Bediirfnis nach Kommunikation auf elektronischem Wege wird durch die

Einbindung einer E-Mail-Funktion entsprochen. Ausdruck fUr das Streben nach hoher

289

290 291 292 293

V gl. fiir eine ausfiihrlichere Beschreibung zu Decision Support Systemen Gluchowski/Gabriel/Chamoni (1997), S. 165ff. V gl. auch Mertens/Griese (1993), S. 4. V gl. Schinzer (1996), S. 57. Vgl. GluchowskilGabriellChamoni (1997), S. 195. Gelaufige synonyme Bezeichnungen sind z.B. Chefinformationssystem (CIS) oder Fiihrungsinformationssystem (FIS). Vgl. zu Executive Information Systemen Gluchowski/GabriellChamoni (1997), S. 20lff.


Benutzerfreundlichkeit und intuitiver Bedienbarkeit ist die "Paperclip"-Funktion, die

entsprechend einer Biiroklammer das Anheften von Anmerkungen zur Wiedervorlage

oder vor der Weiterleitung eines Dokuments ermoglicht. Zusammenfassend werden die

Hauptfunktionen eines EIS in Abbildung 11 genannt, wo ihnen charakteristische Akti

vitaten eines Entscheidungstragers zugeordnet werden.

Managementaktivitiit E1S-Funktion

Uberwachen, Filtern Exception Reporting

Analysieren, Erforschen Drill-Down

Suchen, Explorieren Navigation (Retrace)

Informieren News

Prognostizieren Trendanalyse

Kommunizieren E-Mail

Aktivieren Paperclip

Abbildung 11: Hauptfunktionen eines EIS294

Die gestiegenen technischen Moglichkeiten der Informationsgewinnung und

-aufbereitung konnen nicht dariiber hinwegtauschen, daB auch EIS-Anwendungen

Schwachen hinsichtlich ihrer Einbindung in die Entscheidungsprozesse der Fiihrungs

krafte aufweisen. So ist einerseits erkennbar, daB in der urspriinglichen Zielgruppe,

dem Top-Management, Akzeptanzprobleme einen breiten und wirksamen Einsatz

verhindern. Dazu tragt auch die mangelnde Abbildbarkeit der interpersonalen Bezie

hungsstrukturen, die vielfach als wesentliche Informationskanale fungieren, bei. Ande

rerseits lassen solche Systeme auch Probleme in der Datenversorgung erkennen, da

eigenstandige EIS-Datenbasen mit festen Datenstrukturen zu unflexibel erscheinen.

Aufgrund von Medienbriichen zu den operativen Systemen und einer insgesamt man

gelnden Integration ist zudem fraglich, ob Daten ausreichender Qualitat bereitgestellt

werden konnen.295

294

295 GluchowskilGabriellChamoni (1997), S. 216. Vgl. Chamoni/Gluchowski (I 998b), S. 8f.


Die hier skizzierten Systemkategorien MIS, DSS und EIS lassen sich unter dem Ober

begriff der Management Support Systeme (MSS) einordnen. Hierzu gehoren neben den

genannten Komponenten weitere Werkzeuge, mit denen die herkommlichen Schreib

tischaufgaben am Rechner durchgefUhrt werden konnen (vgl. Abbildung 12).

I Management Support

I Systeme (MSS)

I l Basissysteme:

I Executive Information

I I Decision Support I

• Text- Systeme (EIS) Systeme (DSS)

verarbeitung I • Tabellen-kalkulation I Communication I

I Data

I Decision

• Grafik- Support Support Support verarbeitung I I • Termin- I I planung Standard- Simulation

Kommunikation reporting

Ad-hoc-Prognose

E-Mail, ... (MIS)

Reporting Optimierung

Abbildung 12: Komponenten von Management Support Systemen296

Ein erneuter Wandel in dieser Thematik wurde in den vergangenen lahren mit dem

Aufkommen neuer Konzepte, wie Data Warehousing oder Data Mining, eingeleitet.

Hier wird versucht, neue Losungen fUr die Probleme anzubieten, die eine grofiere

Verbreitung der geschilderten Systemkategorien bisher erschwert haben. Teilweise ist

auch erkennbar, daB nicht unbedingt die Losungen neu sind, sondern sich vielmehr die

technischen Moglichkeiten verbessert haben, die deren Umsetzung nun besser erlauben

als in der Vergangenheit. So wird insbesondere das Problem der Datenversorgung fUr

Werkzeuge der beschriebenen Art mit dem Data Warehouse-Konzept aufgegriffen.

3.1.2 Charakteristika des Data Warehouse-Konzepts

1m Mittelpunkt eines analyseorientierten Informationssystems als dem logischen Ge

genstiick zu den operativen Informationssystemen steht ein Datenpool, mit dessen

296 Chamoni/Gluchowski (I 998b), S. 9.


Inhalt sich die verschiedenen Analyseaufgaben wirksam fundieren lassen. Dies setzt

voraus, daB groBe Datenmengen effizient verfligbar gemacht werden, wobei hier auf

grund der Nutzungscharakteristik andere Anforderungen gestellt werden als bei trans

aktionsorientierten Datenbanken. Daher bietet es sich an, diesen Datenpool als eine

von den operativen Datenbestanden getrennte Datenbank zu betreiben.

Eine solche Datenbank, die aIs gemeinsame, unternehmensweite Datenbasis flir die

Versorgung aller managementuntersWtzenden Systeme dient, wird als Data Warehouse

bezeichnet. Das zugrundeliegende Konzept, Daten rein zu Auswertungszwecken red

undant und getrennt von den operativen Datenbestanden zu halten, wurde erstmals zu

Beginn der achtziger Jahre unter Schlagworten wie "Data Supermarket" oder "Super

Databases" erwahnt.297 1988 wurde von IBM ein erstes Projekt zu diesem Konzept

vorgestellt. 298 Mit der Veroffentlichung einer entsprechenden Produktstrategie durch

IBM im Jahre 1991 wurde dieses Konzept verstarkt auch von anderen Hard- und Soft

wareherstellern sowie Beratungshausern aufgegriffen und fand auch Interesse in der

Forschung.299 Seit dieser Zeit ist urn dieses Schlagwort und die darunter vermarkteten

Produkte und Dienstleistungen ein Markt entstanden, des sen jahrliches Volumen auf

derzeit 5 - 8 Milliarden US-$ geschatzt wird.3oo

Unter dem Begriff Data Warehouse wird heute allgemein eine Datenbank verstanden,

die als unternehmensweite Datenbasis flir das gesamte Spektrum der Anwendungen

zur Unterstiitzung der analytischen Aufgaben von Fach- und Fiihrungskraften dient. 301

Diese wird von den operativen Vorsystemen getrennt betrieben und beinhaltet Daten,

die aus den Vorsystemen iibernommen werden oder aus anderen, externen Quellen

stammen.302 Dabei wird mit dies em Begriff iiblicherweise kein konkretes Datenbank

systemprodukt gemeint, welches speziell flir diese Anwendung geeignet ist. Von Be

deutung ist hier vielmehr das zugrundeliegende Konzept der Separierung der entschei

dungsbezogenen Daten, so daB vielfach auch vom Data Warehouse-Konzept gespro

chen wird.

297

298

299

300

301

302

Vgl. o.V. (1994), S. 14ff. V gl. DevlinlMurphy (1988). V gl. Hackathorn (1993), S. 25 If. Vgl. Meyer/Cannon (1998), S. ixf. Auch Rudin (1996) und ChaudhurilDayal (1997), S.65, nennen Werte in dieser GriiBenordnung als Prognose fiir 1998. Vgl. z.B. Gluchowski (1997), S.48; Holthuis/Mucksch/Reiser (1995), S.IO; Chamoni/Gluchowski (l998b), S. 13. Zur Rolle externer Informationen bei der Entscheidungsunterstiitzung vgl. Mertens (I 998b ), S. 16ff.; Behme/Mucksch (I 998a), S. 86ff.


Die Daten im Data Warehouse lassen sich durch vier wesentliche Merkmale charakte

risieren, die bereits deutliche Unterschiede zu den operativen Daten erkennen las

sen:303

• Themenorientierung,

• Struktur- und Formatvereinheitlichung,

• Zeitraumbezug,

• geringe Volatilitat.

Diese Merkmale werden im folgenden naher beschrieben.

- Themenorientierung

Die inhaltliche Ausrichtung der Informationen im Data Warehouse orientiert sich an

den SachverhaIten, welche die Entscheidungsgegenstande im Unternehmen betreffen.

Derartige inhaltliche Kernbereiche fUr ein Data Warehouse konnen also z.B. Kunden

oder Produkte sein. 1m Gegensatz dazu sind die operativen Systeme eher an Organisa

tionseinheiten, Funktionen oder Prozessen orientiert und dienen der effizienten Ab

wicklung von Routineaufgaben, sind jedoch kaum zur U ntersttitzung von Entscheidun

gen geeignet. Daten, die nur in bezug auf die DurchfUhrung der Leistungserstellung im

Unternehmen von Bedeutung sind, aber nicht zur Entscheidungsuntersttitzung dienen

konnen, finden keinen Eingang ins Data Warehouse.

Neben der inhaltlichen Ausrichtung der im Data Warehouse abgelegten Daten wird

auch das logische Datenmodell von der im Vergleich zu den operativen Datenbanken

anderen Charakteristik der Operationen beeinfluBt.

- Struktur- und Formatvereinheitlichung

Ein zentrales Merkmal eines Data Warehouse (und wesentlicher Aspekt dieser Arbeit)

ist, daB die in das Data Warehouse eingehenden Daten hinsichtlich ihrer Struktur und

ihres Inhalts vereinheitlicht werden. Es wird damit eine unternehmensweite Integration

der Daten zu einem konsistenten Datenbestand in einem durchgangig modellierten

System angestrebt. Dieses Ziel ist zugleich Ausdruck des genannten Merkmals der

Themenorientierung, denn diese impliziert z.B. die funktionstibergreifende Verwen

dung der Daten.

303 Vgl. zu diesen Merkmalen z.B. Inmon/Hackathorn (1994), S. 3ff.; Hackathorn (1995), S. 38; Mucksch/Behme (I 998b), S. 40ff.


- Zeitraumbezug

Ftir die Managementuntersttitzung ist eine zeitpunktgenaue Bearbeitung von Daten,

wie sie durch die transaktionsorientierten operativen Systeme durchgefiihrt wird, von

nachgeordnetem Interesse. Wichtiger erscheint die Moglichkeit zur problemlosen

Betrachtung von Zeitreihen, die eine Analyse von Sachverhalten tiber langere

Zeitraume hinweg ermoglichen und so zur Erkennung von Trends verwendet werden

konnen. Spielen ZeitgroBen in den operativen Systemen nur als beschreibende Merk

male eine Rolle - sofern sie nicht ganz vernachlassigt werden - stellen sie im Data

Warehouse wichtige strukturelle Bestandteile dar. 304 Zudem werden auch altere Daten,

die in den operativen Systemen moglicherweise langst auf Archivmedien mit langerer

Zugriffszeit ausgelagert worden sind, im Data Warehouse weiterhin vorgehalten. Hier

konnen Verdichtungen vorgenommen werden, urn der im Zeitablauf abnehmenden

Relevanz alter werdender Detaildaten Rechnung zu tragen.

- Geringe Volatilitat

Mit dem Begriff der Volatilitat wird beschrieben, in welchem Umfang Daten im Ver

laufe ihres Lebenszyklus verandert werden. Dies laBt sich z.B. tiber die absolute An

zahl von Update-Vorgangen in einem Zeitraum beschreiben.305 Auf Daten im Data

Warehouse wird in der Regel nur Ie send zugegriffen, so daB im Rahmen der normalen

Nutzung keine Veranderungen durchgefiihrt werden. Diese treten lediglich bei Aktua

lisierungslaufen auf, wobei auch hier Detaildaten (mit Ausnahme eventuell notwendi

ger Korrekturen) nur hinzugefiigt, bestehende Datensatze aber nicht verandert werden.

Lediglich aggregierte Werte sind in Abhangigkeit von den Updatezyklen und den

Aggregationsalgorithmen zu aktualisieren. Vorteilhaft an der geringen Volatilitat ist,

daB erstellte Auswertungen und Analysen auch spater noch nachvollziehbar und repro

duzierbar sind. Dies ist bei Auswertungen, die unmittelbar den Daten aus operativen

Systemen zugrundeliegen, so nicht gegeben, da hier die Daten permanenten Verande

rungen unterworfen sind.

Zusammenfassend kann also festgehalten werden, daB es sich beim Data Warehouse

urn die zentrale Datenbank handelt, die mit den genannten Eigenschaften der Speiche

rung aller analyserelevanten Daten im Unternehmen dient. Allgemein kann daher unter

dem Data Warehouse-Konzept - unabhangig von konkreten Architekturen oder Reali-

304

305 V gl. Meyer/Cannon (1998), S. 21; Devlin (1997), S. 162f. V gl. Hackathorn (1993), S. 227f.


sierungsformen - der Gedanke verstanden werden, die operativen Daten in der ge

nannten Form integriert und unabhangig von den operativen Systemen zu speichern,

urn sie dann zu entscheidungsunterstiitzenden bzw. analytischen Zwecken zu nutzen.

1m Zusammenhang mit dem Data Warehouse-Begriff wird vielfach auch yom Data

Mart gesprochen. Unterschiede zwischen dies en Systemklassen sind bereits aus dem

Vergleich der verwendeten Metaphern erkennbar: Ein Lager (Warehouse) erscheint

groBer und weniger zur Selbstbedienung vorgesehen als ein Markt (Mart). So herrscht

denn auch in der Literatur und den Herstellerpublikationen weitgehend Einigkeit

dauber, daB ein Data Mart die Daten nicht in einer so groBen Breite wie das Data Wa

rehouse vorhalt, sondern lediglich einen Ausschnitt liefert, der z.B. einem der im Data

Warehouse abgebildeten Themenkomplexe entspricht oder das Informationsbedurfnis

einer Abteilung befriedigen solI. Weniger Ubereinstimmung ist in bezug auf den Zu

sammenhang von Data Warehouse und Data Mart erkennbar. So wird einerseits vorge

schlagen, im Rahmen einer schrittweisen EinfUhrung eines Data Warehouse im Unter

nehmen zunachst einen oder mehrere Data Marts aufzubauen, urn die Komplexitat des

Gesamtprojekts durch die vorlaufige Beschrankung auf Teilbereiche zu mindern. 306

Nach dies em Konzept entsteht dann das Data Warehouse durch Integration der Data

Marts. Daher kann diese Sichtweise als Bestandteil eines Vorgehensmodells zum Auf

bau eines Data Warehouse gesehen werden.

In einer anderen Sichtweise wird als Data Mart eine Teilmenge des Data Warehouse

gesehen, in der die Daten nochmalig redundant, aber in einer anderen Aufbereitungs

form vorliegen, so daB erst diese Data Marts als Datenbasis fUr Analysetools dienen.307

Hier soli der Zweck darin liegen, eine besonders aufgabenadaquate Teilmenge der

Daten bereitzustellen. Dies kann sich z.B. in einer anderen Reprasentationsform, spezi

fisch ausgewahlten Inhalten oder einer durch die Verkleinerung der Datenmenge be

dingten Verbesserung der Antwortzeiten bemerkbar machen.

Wiihrend sich also Data Warehouse- und Data Mart-Konzepte in erster Linie auf die

Bevorratung von Datenbestanden zu Analysezwecken beziehen, werden unter dem

Begriff OLAP (On-Line Analytical Processing) in erster Linie Auswertungsaspekte

306

307 Vgl. z.B. Behme (1996), S. 36. Vgl. z.B. Meyer/Cannon (1998), S. 27f.; Schinzer/Bange (1998), S. 46; Holthuis/Mucksch/Reiser (1995), S. 15f.


beschrieben.308 Es handelt sich hierbei urn eine Reihe von Anforderungen ("OLAP

Regeln"309), die erfUllt sein sol1en, damit managementrelevante Informationen aus den

Datenbestanden interaktiv, benutzerfreundlich und flexibel extrahiert werden konnen.

Diese Anforderungen wurden aus der Kritik an der mangelnden Eignung trans-aktions

orientierter Systeme zur Entscheidungsuntersttitzung abgeleitet und spater erweitert.3!0

Eine wichtige Funktion ist hierbei die Moglichkeit, mehrdimensionale Sichten auf die

Datenbestande zu definieren.

3.2 Datenmodelle und Repriisentationsformen

Analog zur Datenmodellierung fUr die operativen Datenbanksysteme im Untemehmen

(vgl. Abschnitt 2.2) mtissen auch fUr die im Data Warehouse abzuspeichemden Daten

Modelle entworfen werden, die eine abstrakte und problemadaquate Sicht auf den

behandelten Realitatsausschnitt liefem.

Aufgrund des speziellen Charakters der betrachteten Problemstrukturen mtissen hier

jedoch andere Modellierungskonzepte als bei den operativen Datenbanksystemen

Verwendung finden. Werden in den operativen Systemen typischerweise Datensatze

schreibend oder Ie send bearbeitet, die sich nach einzelnen Identifikationskriterien

beschreiben lassen (z.B. Artikel-Nummer oder Kunden-Nummer), soli eine analysie

rende Betrachtung der Daten zumeist auf mehreren Kriterien basieren: So sollen etwa

die summierten Erlose fUr ein bestimmtes Produkt, erzielt tiber einen bestimmten Ab

satzweg in einem bestimmten Zeitraum, betrachtet werden. Hier liegt also eine Frage

stellung mit einem mehrdimensionalen Charakter vor. Diese Eigenschaft kann als

typisch fUr Fragestellungen gelten, mit denen Entscheidungstrager konfrontiert wer

den)!! Dartiber hinaus dtirften nahezu aile anspruchsvolleren Entscheidungssituatio

nen einen solchen mehrdimensionalen Charakter haben, so daB dieser der menschli

chen Denkweise gelaufig ist. Wegen der Wichtigkeit der Mehrdimensionalitatseigen

schaft werden diese und einige typische Operationen auf mehrdimensionale Daten

308

309

310

311

V gl. zum OLAP-Begriff z.B. Gluchowski/Gabriel/Chamoni (1997), S. 282; Chamoni (1998), S. 233ff.; Chamoni/Gluchowski (1998c), S. 404ff.; Jahnke/Groffmann/Kuppa (1996), S. 32lff. Vgl. zu den OLAP-Regeln Codd/Codd/Salley (1993). Beschrieben werden diese Regeln z.B. bei Chamoni (1998), S. 233ff.; Chamoni/Gluchowski (l998c), S. 404ff., und Holthuis (l998a), S. 52ff. Z.B. durch Buytendijk (1995). Vgl. Holthuis (I 998b), S. 148f.


zunachst beschrieben, bevor auf die Abbildung solcher Informationsstrukturen in den

in Frage kommenden Reprasentationsformen eingegangen wird.

3.2.1 Mehrdimensionale Informationsstrukturen

Eine auf drei Kriterien basierende (also dreidimensionale) Fragestellung laBt sich in

tuitiv in einem WtirfeP12 visualisieren. Die Kanten des Wtirfels und damit die struk

turbestimmenden Dimensionen sind die Anfragekriterien mit ihren Auspragungen, in

den Zellen des Wtirfels stehen die sich jeweils ergebenden Werte. Die Anzahl der

Dimensionen einer mehrdimensionalen Fragestellung ist dabei prinzipiell nicht bc

grenzt, auch wenn die wtirfelfOrmige grafische Darstellung nur drei Dimensioncn

zulaBt.313 Praktische Grenzen werden sich dariiber hinaus aus der Anzahl sinnvoll

definierbarer Dimensionen und der Vorstellungs- und Abstraktionskraft des Benutzers

ergeben.

Die einzelnen Dimensionen enthalten atomare Elemente, also Kriterien, die nicht in

weitere Teilkriterien zerlegt werden konnen oder sollen. Dariiber hinaus lassen sich

inharente oder explizit eingefUhrte verdichtete Dimensionselemente ableiten, die zu

mehrstufigen Elementhierarchien ausgebaut werden konnen.314 Die damit entstehenden

Konsolidierungspfade bilden die moglichen Stufen ab, auf denen aggregierte Werte

gespeichert werden. Die sehr haufig vorhandene Zeit-Dimension laBt sich z.B. in einer

Hierarchie mit den Ebenen Tag, Monat, Quartal und Jahr gliedern, fUr eine Dimension

Produkt lassen sich etwa Produktgruppen und Hauptgruppen definieren.315

Komplexer, aber im praktischen Anwendungsfall haufig anzutreffen, sind Dimensi

onshierarchien mit Elementen, die sich tiber verschiedene Aggregationspfade inhaltlich

sinnvoll konsolidieren lassen. So kann es etwa wtinschenswert sein, fUr die angespro

chene Produktdimension die dort abgebildeten Kennzahlen zusatzlich tiber das Kriteri

urn "Vertriebsweg" zu aggregieren. Hier kann von Dimensionshicrarchien mit multi-

312

313

314 315

Genaugenommen mOBte von einem Quader gesprochen werden, weil die Kantenlange (Anzahl der Auspragungen der Dimensionen) hier keineswegs immer gleich sein muB. Trotzdem wird bei der gangigen Bezeichnung "WOrfel" geblieben. Hiihere Dimensionen lassen sich bei schnell abnehmender Anschaulichkeit z.B. durch nebeneinandergestellte WOrfel visualisieren. Vgl. Schelp (1998), S. 266f.; Hahne (I 998b), S. 9f. V gl. insbesondere zur Hierarchisierung der Zeitdimension Yazdani/Wong (1998), S. 46f.


plen Konsolidierungspfaden316 oder auch von parallelen Hierarchien317 gesprochen

werden.

Insgesamt ergibt sich fiir solche mehrdimensionalen Strukturen em hohes MaE an

bereits strukturbegrtindeter Organisation, wodurch navigierende Analysen vereinfacht

werden. So HiEt sich etwa in Anlehnung an das obige Beispiel der Gesamterlos tiber

aile Absatzwege fiir ein Produkt und einen Zeitraum durch einfaches Summieren ent

lang der Absatzweg-Dimension ermitteln.

Ftir Problemstellungen, die sich auf Daten mehrdimensionalen Charakters beziehen,

konnen verschiedene Operationen definiert werden, die ein Navigieren im Datenraum

ermoglichen. Ais Basisoperationen lassen sich unterscheiden:318

- Drill Down

Betrachtet man innerhalb eines Datenraumes aggregierte Werte, kann es wtinschens

wert sein, diese in ihre einzelnen Komponenten zu zerlegen, sich also innerhalb einer

Dimensionshierarchie zu einer untergeordneten Stufe zu bewegen. So kann es bei

spielsweise fiir einen Entscheidungstrager von Interesse sein, eine fiir den Zeitraum

"Quartal" ausgewiesene Kennzahl in die Werte fiir die einzelnen Monate aufzuglie

dem, urn dann auf dieser Basis fiir einen der Monate etwa eine Artikelgruppe in ihre

Bestandteile zu zerlegen. Dieses "Bohren" nach Detailwerten innerhalb der Dimensi

onshierarchien wird als Drill Down bezeichnet und kann der Erkliirung von Auffallig

keiten, die im verdichteten Datenbestand entdeckt wurden, dienen.319

- Roll Up

Umgekehrt zum Drill Down wird mit Roll Up eine Navigation entlang der Hierarchien

zu einer hoheren Dimensionsstufe beschrieben, so daB eine Betrachtung der Daten auf

einem hoheren Verdichtungsniveau erfolgen kann.

- Slicing

Mit einer Slicing-Operation wird ein zweidimensionaler Schnitt aus dem mehrdimen

sionalen Datenwtirfel zur Betrachtung ausgewahlt. So entsteht aus dem abstrakten

Gebilde des vieldimensionalcn Wtirfels (Hyperwtirfel), das fiir den Benutzer nur

316

317

318

319

Vgl. GabriellGluchowski (1997), S. 25. V gl. Schelp (1998), S. 268f. V gl. z.B. Codd/Codd/Salley (1993); Buytendijk (1995); W.-R. Hansen (1996), S. 431; SapialHbfling/Dinter (1997). V gl. Bissantz (1998), S. 325.


schwer vorstellbar und interpretierbar ist, eine Vielzahl von Sichten, die sich am Bild

schirm leicht darstellen lassen und durch die effizient navigiert werden kann. Die Zahl

der moglichen Scheiben, die aus einem Wiirfel herausgetrennt werden konnen, steigt

mit der Anzahl der Dimensionen schnell an. So hat ein dreidimensionaler Wiirfel

sechs, ein vierdimensionaler bereits 24 verschiedene Betrachtungsschichten.320

- Dicing

Mit Dicing oder Ranging wird die KantenHinge des Wiirfels verkleinert, d.h. entlang

der Dimensionen erfolgt eine Vorauswahl bestimmter Dimensionswerte. So kann der

urspriinglich moglicherweise sehr umfangreiche Wiirfel auf die fUr die Betrachtung

re1evanten Teile reduziert werden. Anfragen an die Datenbank, die zum Bestiicken der

Zellen des Wiirfels mit den Werten erforderlich sind, werden ressourcensparender und

schneller ausgefiihrt. Durch die Verkleinerung des Datenbestands konnen auch andere

Operationen wie z.B. das Erstellen neuer Berechnungen effizienter durchgefUhrt wer

den. Der Benutzer erhalt auf diese Weise lediglich den Ausschnitt aus der Datenmenge

angezeigt, der fiir relevant erachtet wird, so daB auch durch diese Operation die Uber

sichtlichkeit gesteigert wird.321

Aus den geschilderten Eigenschaften multidimensionaler Datenstrukturen, wie sie mit

analyseorientierten Informationssystemen abgebildet und verwendet werden sollen,

und den darauf basierenden Operationen ist leicht zu erkennen, daB hier vollig andere

Problemstrukturen vorliegen als im Rahmen der Modellierung und Implementierung

operativer Datenbanksysteme. Dies fUhrt zu der Erkenntnis, daB die herkommlichen

logischen Datenmodelle, die z.B. auf normalisierten relationalen Strukturen basieren,

hier nicht problemadaquat sind. Da jedoch trotzdem als Datenbanksystem fUr ein Data

Warehouse aufgrund der zweifellos vorhandenen Vortei1e dieser Produkte haufig rela

tionale Systeme verwendet werden, ist es notwendig, die mehrdimensionalen Struktu

ren in Modellen abzubilden, die die somit vorgegebenen relationalen Konstrukte ver

wenden. 1m folgenden Abschnitt wird auf entsprechende logische Datenmodelle ein

gegangen, die dieses leisten konnen.

Sogenannte multidimensionale Datenbanksysteme verwenden dagegen eigenstandige

logische Datenmodelle, die nicht auf der Grundstruktur des Relationenmodells basie

ren. Auf diese Datenmodelle wird im dann folgenden Abschnitt 3.2.3 eingegangen.

320

321 Vgl. Holthuis (l998b), S. 152. V gl. Kenan Technologies (1995), S. 16f.


3.2.2 Repriisentationsformen auf relationaler Basis

Logische Datenmodelle zur Modellierung eines Data Warehouse auf der Basis einer

relationalen Datenbank unterscheiden sich gravierend von herkommlichen Modellen,

wie sie fiir operative Systeme tiblich sind. Insbesondere muE von der Forderung nach

weitgehender Redundanzfreiheit und dem damit verbundenen Normalisierungspara

digma Abstand genommen werden.

Ein vielfach verwendeter Ansatz zur Modellierung mehrdimensionaler Datenstrukturen

fiir relationale Datenbanksysteme besteht in den unterschiedlichen Varianten des soge

nannten Star Schemas, das im folgenden niiher erliiutert wird.322

Hier werden nach der Art der zu speichernden Daten zwei Kategorien von Datentabel

len unterschieden: Fakten- und Dimensionstabellen.

In einer Faktentabelle werden die einzelnen im Rahmen der spiiteren Auswertungen zu

betrachtenden (meist numerischen) Werte gespeichert.323 Damit handelt es sich - greift

man auf die angesprochene Visualisierungsform tiber einen Wtirfel zurUck - urn die

Werte, die in den einzelnen Zellen des Wtirfels enthalten sind. Urn diese richtig zuord

nen zu konnen, muE das Tupel in der Faktentabelle neben dem eigentlichen Wert auch

Angaben tiber die Position dieses Wertes im mehrdimensionalen Raum, also die Koor

dina ten innerhalb der Dimensionen, enthalten. Realisiert wird dies tiber Fremdschltis

sel ftir aile Dimensionen in den Tupeln der Faktentabelle, die jeweils zu einem Eintrag

in den Dimensionstabellen fiihren. Zu jeder Dimension besteht eine eigene Dimensi

onstabelle, welche die einzelnen Auspriigungen der jeweils re1evanten Geschiiftsdi

mensionen beschreibt. Verkniipfungen bestehen nur zwischen der Faktentabelle und

den Dimensionstabellen, letztere sind untereinander nicht verkniipft. In einer grafi

schen Darstellung entsteht so die namensgebende sternfOrmige Anordnung mit der

Faktentabelle im Mitte1punkt und den urn diese herum angeordneten Dimensionsta

bellen. Abbildung 13 zeigt ein Beispiel fiir ein Star Schema mit einer Faktentabelle

(FTMain) und den Dimensionstabellen (DT ... ).

322

323

Vgl. hierzu z.B. Raden (1996), Kimball (1996), S. IOff.; YazdanilWong (1998), S. 51ff.; Hahne (1998a) S. 11 Off. Eine Vielzahl von Anwendungsbeispielen zeigen Silverson/lnmon/Graziano (1997), S. 265ff. Vgl. Poe (1996), S. 121.


DTModell

r- KModell DTZeit

KZeit I-- Modell KModeligruppe

Monat Modellgruppe Jahr KMotor level FTMain Motor

DTVerkiiufer

~ KZeit level

KVerkiiufer KVerkiiufer DTModelivariante KModell ~ I KModelivariante Name KModelivariante

KNiederlassung KModelifarbe ~ Modellvariante Niederiassung ~ KKundentyp KLand KVertragstyp ~ DTModelifarbe Land -1 KModelifarbe level Umsatz

IstAbsatzmenge Modellfarbe DTKundentyp

KKundentyp ~ DTVertragstyp Kundentyp KVertragstyp

Vertragstyp

Abbildung 13: Star Schema324

Ein so1ches Star Schema eignet sich gut, urn einen "Datenwiirfel" auch mit vielen

Dimensionen darzustellen. Es erlaubt anhand der dem Anwender ohnehin geUiufigen

Dimensionen eine einfache Navigation durch den Datenbestand.325 Zudem erscheint es

als eine leicht verstiindliche Modellierungsform, die eine gute Basis flir die Zusam

menarbeit des Fachanwenders mit dem Data Warehouse-Entwickler im Rahmen der

Erstellung des Datenmodells bieten kann.

Kritik, die an dieser Grundform des Star Schemas geiiuBert wird, bezieht sich vielfach

auf zwei Aspekte: Die Beschrankung auf eine einzige Faktentabelle erschwert eine

adaquate Modellierung, wenn unterschiedliche Fakten, die durch verschiedene Dimen

sionen beschrieben werden, abgebildet werden sollen. Daneben unterstiitzt diese Form

des Star Schemas keine hierarchischen Strukturen innerhalb der Dimensionen.326 Dies

stellt einen groBen Mangel dar, da - wie bereits ausgeflihrt - die Dimensionshierar-

324

325

326

Hahne (1998a), S. 110. Vgl. Red Brick Systems (1995), S. 4. Vgl. ChaudhurilDayal (1997), S. 69f.


chien ein wichtiges Ordnungs- und Aggregationskriterium bilden. Zudem sind Hierar

chien wohl in nahezu allen praxisrelevanten Hillen gegeben. Erweiterungen des Star

Schemas fiihren zu einer besseren Beriicksichtigung dieser Aspekte und zur Abbild

barkeit soIcher Strukturen. Hierarchien konnen in unterschiedlicher Form in ein Star

Schema integriert werden.

Als erste Moglichkeit Iiegt die Speicherung aller denkbaren Verdichtungsstufen in der

jeweiligen Dimensionstabelle nahe. Dies kann geschehen, indem in die Dimensionsta

bellen fiir jede mogliche Hierarchiestufe ein eigenes Attribut aufgenommen wird,

wobei Dimensionsauspragungen hoherer Aggregationsstufen dann hinsichtlich der

Attribute fiir die niedrigen Ebenen Nullwerte zugewiesen werden. Auf diese Weise

lassen sich die Aggregationspfade aus den Null-Eintragen in der Dimensionstabelle

herleiten.327 Weiterhin lassen sich moglicherweise Verbesserungen in der Verarbei

tungsgeschwindigkeit erzielen, wenn zusatzlich ein "Level-Attribut" eingefiihrt wird,

das numerisch oder durch einen entsprechenden Bezeichner ein Tupel in der Dimensi

onstabelle mit seinen Auspragungen einer konkreten Hierarchiestufe zuordnet.328 In

der Faktentabelle konnen auf diese Weise, da entsprechende Dimensionswerte ja exi

stieren, auch die aggregierten Werte abgelegt werden.

Durch das Abbilden der Hierarchien mit Hilfe von Attributen in den Dimensionstabel

len konnen die verschiedenartigsten Strukturen reprasentiert werden. Auch parallele

Hierarchien lassen sich so gut darstellen. Als nachteilig erscheint dagegen, daB Veran

derungen in der Dimensionshierarchie die Struktur der Tabelle modifizieren und somit

zu schwerwiegenden Eingriffen in das Datenmodcll fiihren, so daB Anfrageoperationen

neu formuliert werden miissen.

Eine weitere Moglichkeit zur Abbildung von Hierarchien und damit von aggregierten

Werten besteht darin, diese in separate Faktentabellen auszulagern.329 Verbindet man

diese Strategie mit einer Partitionierung der Dimensionstabellen nach den einzelnen

Aggregationsstufen, so spricht man - in Anlehnung an die bei einer grafischen Dar

stellung entstehenden komplexen Strukturen - von einem Snowflake-Schema.330 Ne

ben der genannten Komplexitat der entstehenden Modelle wird als Nachteil dieses

Schemas allerdings auch angefiihrt, daB so implementierte Modelle aufgrund der Viel-

327

328

329

330

V gl. Hahne (1 998a), S. Iliff. V gl. Hahne (1 998a), S. 112f.; Chaudhuri/Dayal (1997), S. 70. Vgl. Chaudhuri/Dayal (1997), S. 70. Vgl. Hahne (1998a), S. 120f.; McGuff(1998).


zahl der Dimensionstabellen Geschwindigkeitsnachteile bei Abfrageoperationen auf

weisen.331

Die in einem Data Warehouse abzubildende Geschaftssituation weist III der Regel

einen hohen Komplexitatsgrad auf, der im Datenmodell durch eine Vielzahl von Di

mensionen sowie zahlreiche Fakten, die sich jeweils auf eine Teilmenge der Dimen

sionen beziehen, deutlich wird. Finden nun aile Werte Eingang in eine einzige Fakten

tabelle, so wird diese schnell sehr graB, was Prableme bei der Bearbeitung durch das

Datenbankrnanagementsystem erwarten laBt.332 AuBerdem entstehen sehr viele unbe

setzte Werte, da nicht aile Dimensionen auch fUr aile Fakten anwendbar sind. Daher

liegt es nahe, die Faktentabelle zu zerlegen und jeweils nur Fakten gleicher Dimensio

nierung in einer Tabelle abzuspeichem. Jede der kleineren Faktentabellen wird nun

durch eine Teilmenge der Dimensionstabellen beschrieben, wobei letztere auch mit

mehreren Faktentabellen verkniipft sein k6nnen.

Stellt man sich das Modell wiederum in Form der "Datenwiirfel" vor, so entsteht durch

die Zerlegung der Faktentabelle aus dem graBen, hochdimensionalen, aber nur an

wenigen Stellen mit Werten besetzten Ausgangsgebilde eine Reihe kleinerer Wiirfel

mit jeweils niedrigerer Dimensionalitat und einem hohen Fiillungsgrad. Diese erwei

terten Modelle werden z.B. als Multi-Fakttabellen-Schema333 oder (im Sinne einer

Ansammlung von Stemen) als Galaxie334 bezeichnet.

Zusammenfassend kann festgehalten werden, daB mit den unterschiedlichen Varianten

des Star Schemas Modelle existieren, mit deren Hilfe man gut die Data Warehouse

spezifischen Prablemstrukturen in fUr relationale Datenbanksysteme adaquate Modelle

umsetzen kann.335 Techniken fUr die semantische Datenmodellierung werden im Rah

men der Star Schema-Modellierung allerdings nicht angeboten.336

Auch in der Literatur wird die Anwendung semantischer Datenmodellierung fUr analy

seorientierte Informationssysteme bisher kaum diskutiert. Ein soIches Modell k6nnte

jedoch auch bei Prablemstellungen zur Data Warehouse-Modellierung Hilfe bei der

331

332

333

334

335

336

Vgl. Kimball (1996), S. 95ff. V gl. Edelstein (1995), S. Iff. Vgl. Red Brick Systems (1995), S. 13ff.; Holthuis (I 998b), S. 178f. V gl. McGuff (1998). Potentiell auftretende Geschwindigkeitsprob1eme bei Anfragen an so modellierte Datenbestande, die sich aus den Charakteristika relationaler Anfragesprachen ergeben, sowie Verbesserungsansatze diskutiert z.B. Holthuis (I 998b), S. l80ff. Vgl. GabriellGluchowski (1997), S. 29f.


implementierungsunabhangigen Sammlung und Strukturierung der relevanten Da

tenobjekte bieten, urn so die in den Daten enthaltene Semantik abzubilden.337 Wenn

auch problemspezifische semantische Datenmodelle nicht vorhanden sind, konnen

doch die herkommlichen Ansatze Hilfestellung bei der Modellierung multidimensio

naler Strukturkomponenten leisten.338

Mit dem Star Schema und seinen Varianten werden mehrdimensionale Datenstrukturen

auf die Schemaobjekte abgebildet, die von relationalen Datenbanksystemen bereitge

stellt werden. Dieser Ansatz ist insofern verstandlich, als mit diesen Datenbanksyste

men bewahrte Produkte zur Speicherung und Verwaltung groBer Datenmengen ver

fiigbar sind. So lassen sich analyseorientierte Datenbanken aufbauen, die die erforder

lichen sehr groBen Datenmengen beinhalten und zugleich die Eigenschaften der markt

gangigen relationalen Datenbanksysteme wie Portabilitat, Moglichkeit zur paralleli

sierten Verarbeitung und standardisierte Schnittstellen nutzen konnen.339 Als weiterer

Vorteil mag angefiihrt werden, daB relationale Datenbankprodukte im Unternehmen

meist bereits im Einsatz sind und so z.B. vorhandenes Wissen tiber die Administration

dieser Software auch fiir dies en neuen Einsatzzweck verwendet werden kann. Die

Einfiihrung einer zusatzlichen, vollig neuen Technologie eines fremden Herstellers im

Unternehmen scheint dagegen mit weit groBeren Htirden organisatorischer und techni

scher Art verbunden.

Besser auf die problemspezifischen Datenstrukturen zugeschnitten sind allerdings

Datenbanksysteme, die die genannten multidimensionalen Datenstrukturen auch in

ihren physischen Datenbank- und Speicherstrukturen umsetzen konnen. Daher wird im

folgenden Abschnitt ein Oberblick tiber multi dimension ale Datenmodelle gegeben, die

nicht auf Relationen als Grundstrukturen basieren.

3.2.3 Repriisentationsformen auf muItidimensionaler Basis

Wahrend die geschilderten relationalen Modellierungsansatze auf der Basis des Star

Schemas die mehrdimensionalen Problemstrukturen auf zweidimensionale Tabellen als

337

338

339

Ansatze semantischer Modelle fUr mehrdimensionale Datenstrukturen zeigen Hahne/Schelp (1997), S. 15ff., sowie GolfarellilMaio/Rizzi (1998), S. 334ff. Holthuis (l998a), S. 139ff., untersucht in diesem Zusammenhang insbesondere die EntityRelationship-Methode und objektorientierte Modellierungsmethoden. Vgl. Meyer/Cannon (1998), S. 79.


Grundelement eines jeden Relationenschemas zerlegen, sollen mit den multidimensio

nalen Reprasentationsformen unmittelbar diese Strukturen beschrieben werden.

Dabei ist zu beobachten, daB relational basierende Modellierungstechniken einen ho

hen Reifegrad aufweisen, der darin begrtindet ist, daB die zugrunde liegenden Theorien

sowie Produkte, die solche Modelle implementieren, seit vielen Jahren auf dem Markt

sind und tiber genormte Schnittstellen verftigen. So gibt es, auch bei der Modellierung

mehrdimensionaler Strukturen, nur wenig Diskussionsbedarf tiber die zur Verftigung

stehenden Beschreibungselemente.

Anders stellt sich die Situation bei den mehrdimensionalen logischen Datenmodellen

und ihren Implementierungsplattformen dar. Hier besteht kein Standard, der regelt,

welche Schemaobjekttypen, Zugriffsformen und Funktionen ein solches Datenbanksy

stem bereitstellen muG. Die angebotene Funktionalitat ist sehr unterschiedlich, und

auch eine genormte Datenbanksprache, wie sie bei den relationalen Systemen mit SQL

gegeben ist, fehlt bisher bei diesen Produkten. Bemtihungen urn eine Vereinheitlichung

der Strukturen sind seitens der Industrie zwar erkennbar, befinden sich jedoch noch im

Anfangsstadium.340

Ais kleinster gemeinsamer Nenner ist erkennbar, daB die den Produkten zugrunde

liegenden mehrdimensionalen logischen Datenmodelle auf den drei- oder mehrdimen

sionalen Wtirfelstrukturen basieren, die oben bereits erlautert wurden. Hinsichtlich der

Anzahl der Dimensionen in einem solchen Wtirfel sind jedoch bereits Unterschiede in

den Modellierungskonzepten erkennbar, die sich durch zwei Entwicklungsrichtungen

beschreiben lassen. Einerseits verfolgt ein Teil der Anbieter entsprechender Produkte

die Philosophie, alle Daten in einem Wtirfel mit sehr vielen Dimensionen

("Hypercube") unterzubringen, andererseits praferieren manche Hersteller den Aufbau

mehrerer, entsprechend kleinerer Datenwtirfel ("Multicubes").341

340

341

So werden zunehmend die vom OLAP-Council aufgestellten Begriffsdefinitionen (vgl. OLAPCouncil (1995» in der Terminologie der Hersteller aufgegriffen. Beim OLAP-Council handelt es sich urn eine von mehreren Herstellern entsprechender Produkte getragene Organisation, die der produktorientierten Forschung dienen soli und durch Standardisierung Interoperabilitat ermoglichen will. Vgl. zur Selbstdarstellung dieser Organisation OLAP-Council (1997). Microsoft entwickelt ftir Middleware zum Zugriff auf Datenbanken Erweiterungen ftir die Abfrage mehrdimensionaler Datenbanken (vgl. Microsoft (1997», wobei eine Nutzung durch moglichst viele Hersteller von OLAP-Datenbanken angestrebt wird. Vgl. Gabriel/Gluchowski (1997), S. 20.

Datenmodelle und Repriisentationsformen 101

Entsprechend diesen Rahmenbedingungen konnen sich Modellierungsmethoden, die

sich auf mehrdimensionale Datenstrukturen und Datenbanken beziehen, weniger an

den konkreten Schemaobjekten orientieren, wie dies beim oben beschriebenen Star

Schema und seinen Varianten geschieht. Ein Ansatz zur Modellierung mehrdimensio

naler Datenstrukturen ist dagegen mit der Methodik ADAPT (Application Design for

Analytical Processing Technologies) gegeben, die eine spezifisch ausgerichtete Menge

von Beschreibungselementen anbietet.342 Diese sind als abstrakte Strukturkomponen

ten ausgelegt und erfordern vor der Implementierung mit einem mehrdimensionalen

Datenbanksystem eine Transformation auf die von diesem konkret bereitgestellten

Strukturen.

Bei ADAPT handelt es sich urn eine grafische Methode, die fUr eine Vielzahl von

Modellierungsbausteinen jeweils Symbole enthiilt, die zu umfangreichen Diagrammen

zusammengefUgt werden. Kernelemente eines solchen Modells sind vieldimensionale

Wtirfel, Dimensionen, Hierarchien, Berechnungsmodelle und Datenquellen.

Der Aufbau eines ADAPT-Modells kann z.B. erfolgen, indem zuniichst die darzustel

lenden Datenwtirfel identifiziert und durch ihre Dimensionen beschrieben werden. 1m

niichsten Schritt konnen dann die Strukturen innerhalb der Dimensionen untersucht

werden. Hier lassen sich sowohl hierarchische als auch nicht-hierarchische Beziehun

gen zwischen Dimensionselementen mit den Modellierungsbausteinen darstellen. Be

rechnungsvorschriften werden von den Entwicklern dieser Methode als sehr bedeutsa

mes Element eines analyseorientierten Datenmodells erachtet.343 Folgerichtig finden

auch diese Eingang in das Modell, wobei Berechnungen nicht nur Dimensionen als

Ganzes, sondern auch einzelnen Elementen zugeordnet werden konnen.344

Bezogen auf eine Gesamtsicht operativer und analyseorientierter Informationssysteme

im Unternehmen ist positiv hervorzuheben, daB mit dem Symbol fUr Datenquellen die

Herkunft der in den Wtirfel eingehenden Werte explizit im Modell dargestellt werden

kann. Hier wird ein Schritt hin zur Integration einer Data Warehouse

Transformationskomponente in das Modell sichtbar. Allerdings scheint eine Beruck

sichtigung der vorzunehmenden Transformationsschritte im Modell nicht vorgesehen

zu sein, da hierftir keine entsprechenden Modellkonstrukte vorhanden sind.

342

343

344

Zu ADAPT vgl. Bulos (1996). Vgl. Bulos (1996), S. 34. Eine ausfiihrlichere Beschreibung der Notationselemente von ADAPT sowie ein Fallbeispiei zur Modellierung mit dieser Methode findet sich bei Totokllaworski (1998), S. 19ff.


In ersten Ansatzen kritischer Wtirdigungen der Methode ADAPT wird ausgefUhrt, daB

sie problemspezifisch einen hohen Komplexitatsgrad aufweist, so daB eine gelungene

Modellierung eine intensive Beschaftigung mit den vorhandenen Beschreibungskon

strukten voraussetzt. So gesehen erscheint es fraglich, ob das Ziel, mit ADAPT eine

einfache und verstandliche Kommunikationsgrundlage fUr Entwickler und Fachan

wender zu schaffen,345 erreicht wurde.346

Das hohe Abstraktionsniveau, das mit der Methode ADAPT erstellte Datenmodelle

charakterisiert, hat zur Folge, daB die Umsetzung der Modelle in die Strukturen eines

konkreten mehrdimensionalen Datenbanksystems aufwendige Transformationen erfor

dert. So mtissen alle Modellelemente an die yom zu verwendenden Datenbanksystem

untersttitzten Konstrukte angepaBt werden. Zudem sind groBe Unterschiede zwischen

den am Markt verftigbaren mehrdimensionalen Datenbanksystemen erkennbar.347

Daher muB auch die Modellierungsmethode, z.B. bei der Darstellung paralleler Hierar

chien, angepaBt werden.348 1m direkten Vergleich lassen sich dagegen Star Schemata

in relationalen Datenbanken verhaltismaBig einfach implementieren, weil sie die spate

re Tabellenstruktur bereits enthalten und zumindest die grundlegenden Strukturkon

strukte in allen in Frage kommenden Produkten zumindest ahnlich sind.

Nach der Diskussion verschiedener Datenmodelle fUr analyseorientierte Informations

systeme wird im nachsten Abschnitt die Architektur solcher Systeme betrachtet.

3.3 Architektoren ond Komponenten

Analyseorientierte Informationssysteme bestehen aus zahlreichen Komponenten, deren

zweckmaBiges Zusammenwirken als ein zentrales Erfolgskriterium fUr ein solches

System gesehen werden muB. 1m folgenden wird eine idealtypische Referenzarchitek

tur anhand dieser Komponenten beschrieben. Die Betrachtung erfolgt dabei aus einer

logisch-abstrakten Sicht, es wird weder auf die konkrete funktionale Abdeckung dieser

345 346

347

34B

V gl. Bulos (1996), S. 38. Bewertungen zu ADAPT finden sich in Gabriel/Gluchowski (1997), S. 31 f, und in Holthuis (1 998a), S. 163f Hahne (l998b), S. 15ff, zeigt am Beispiel von drei Produkten den Aufbau mehrdimensionaler Datenmodelle in OLAP-Datenbanken. Vgl. Hahne (l998b), S. 48f.


Komponenten durch entsprechend ausgestaltete Software-Module noch auf die erfor

derliche Hardware eingegangen.349

1m Mittelpunkt eines analyseorientierten Informationssystems steht als zentraler Spei

cherort flir aile Datenbestande das Data Warehouse. Es soli, losgelost von den operati

yen Datenbanken, eine logisch zentrale, einheitliche und konsistente Datenbasis zur

Untersttitzung der analytischen Aufgaben von Fach- und Ftihrungskraften bieten. Es

stellt eine spezifische Anwendung flir ein Datenbanksystem dar und kann somit unter

den Gesichtspunkten betrachtet werden, nach denen sich auch allgemein Datenbanksy

sterne beschreiben lassen. Komponenten zur dezentralen Datenhaltung innerhalb eines

analyseorientierten Informationssystems sind vielfach unter dem Begriff Data Mart

gelaufig (Abschnitt 3.3.2). Den AbschluB bildet ein Blick auf Front-End-Werkzeuge,

die es den Benutzern erlauben, in vielfaltiger Weise auf die gespeicherten Daten zuzu

greifen. Mit den drei genannten Elementen werden die Kernfunktionen der Speiche

rung und Nutzung der Daten abgedeckt. Es verbleiben mit der Metadatenverwaltung

und den Schnittstellen zu den Vorsystemen zwei weitere Elemente, deren Betrachtung

Gegenstand der dann folgenden Abschnitte ist.

Den Metadaten und entsprechenden Verwaltungssystemen kommt im Umfeld analy

seorientierter Informationssysteme eine wichtige unterstiitzende Funktion zu. Wie in

Abschnitt 3.4 gezeigt wird, spielen Informationen tiber die Problemdaten hier eine

wesentlich groBere Rolle als bei der in Kapitel 2 betrachteten Informationssystemklas

se.

Aufgrund ihrer zentralen Bedeutung flir diese Arbeit wird auch den Schnittstellen, tiber

die analyseorientierte Informationssysteme mit den vorgelagerten Informationssyste

men und ihrer sonstigen Umwelt kommunizieren, ein eigener Abschnitt gewidmet.

Abbildung 14 gibt einen zusammenfassenden Uberblick tiber dieses Architekturkon

zept mit seinen Komponenten.

349 Konkrete Uberlegungen zu diesen Aspekten fmden sich z.B. in Anahory/Murray (1997), S. 135ff. (Software) und 155ff. (Hardware); Kimball et al. (1998), S.335ff.; Chan (1997), S.230ff.

104 Ana1yseorientierte Informationssysteme

Fronl-End-Werk:zeuge

Analysen

Extrakte

Data Warehouse

Updates

Abbildung 14: Architekturkomponenten eines analyseorientierten Informationssystems350

3_3_1 Data Warehouse

Zentrale Komponente eines analyseorientierten Informationssystems ist die Data Wa

rehouse-Datenbank. Diese enthalt sowohl aktuelle als auch historische Daten aus allen

zu betrachtenden Unternehmensbereichen in unterschiedlichen Verdichtungsstufen.351

Mit diesem Konzept einer zusatzlichen Datenbank, in der die entscheidungsrelevanten

Daten getrennt von den operativen Systemen und zusatzlich zu diesen gespeichert

werden, wird vom Paradigma der redundanzfreien Datenhaltung im Unternehmen

abgewichen. So treten einerseits zwar die bekannten Nachteile von redundanter Daten

haltung auf. Insbesondere werden dadurch zusatzliche Verarbeitungs- und Speicherres

sourcen benotigt, und eine jederzeitige Konsistenz aller Datenbestande im OL TP- und

OLAP-Bereich ist nicht gesichert. Andererseits laBt jedoch eine Reihe von Grunden

350

351 In Anlehnung an Muller (1998), S. 81. Vgl. Mucksch/Holthuis/Reiser (1996), S. 423.


eine solche Ausgliederung der entscheidungsuntersWtzenden Systeme aus dem Bereich

der operativen Systeme dennoch sinnvoll erscheinen. So erfordern die analyseorien

tierten Zugriffe, die beim Betrieb eines Data Warehouse entstehen, die Betonung ande

rer funktioneller und geschwindigkeitsorientierter Leistungsmerkmale als die transak

tionsorientierten Zugriffe, die charakteristisch fUr herkommliche Datenbanken sind.352

In der Literatur werden in diesem Zusammenhang vielfach verschiedene Merkmale

genannt, fUr die in den einzelnen Systernklassen jeweils unterschiedliche Auspragun

gen vorliegen.353 Abbildung 15 zeigt eine solche Zusammenstellung pragnanter

Merkma1e. Die konkrete Auspragung dieser Aspekte wird im folgenden kurz an eini

gen Beispielen beschrieben.

Charakteristika Operative DB Analyseorientierte DB

Transaktionsvolumen hohes Volumen niedriges bis mittie res Volumen

Antwortzeit sehr schnell normal

Update hohe Frequenz, permanent niedrige Frequenz

Betrachtungsperiode aktuelle Peri ode Vergangenheit bis Zukunft

Umfang anwendungsintern anwendungsiibergreifend

Abfragen vorhersehbar, periodisch unvorhersehbar, ad hoc

Niveau der Daten detailliert aggregiert, aufbereitet

Verarbeitungseinheit Datensatz, eindimensional Matrizen, mehrdimensional, sachbezogen

Abbildung 15: Charakteristika operativer und analyseorientierter Datenbanken354

352

353

354

V gl. Chaudhuri/Dayal (1997), S. 65. V gl. z.B. Inmon (1996), S. 18f.; Scheer (1996); Winterkamp (1995); Bontempo/Zagelow (1998), S. 40f. In Anlehnung an Scheer (1996), S. 75.


Operative Datenbanksysteme dienen der moglichst effizienten Untersttitzung des

"Tagesgeschiifts", das durch eine groBe Zahl an Transaktionen mit jeweils niedrigem

Komplexitatsgrad gekennzeichnet ist. Hierzu ist ein schreibender Zugriff auf detail

lierte, zeitpunktaktuelle Daten erforderlich, wobei jedoch die bei den einzelnen Trans

aktionen bearbeiteten Datenmengen eher gering sind. Die Integritat und Betriebssi

cherheit dieser Systeme ist vielfach als unternehmenskritisch zu bewerten, und als

wesentliches Performancemerkmal dient die Anzahl der durchzufiihrenden Transaktio

nen je Zeiteinheit.355 Entsprechend wird das Datenmodell hinsichtlich dieser Anforde

rungen und in bezug auf die Minimierung von Zugriffskonflikten, die sich aus den

Schreibvorgangen ergeben konnen, optimiert sein.

1m Gegensatz dazu liegt der Schwerpunkt beim Data Warehouse auf der effizienten,

lesenden Bearbeitung groBer Datenmengen in komplexen Strukturen.356 GroBeres

Gewicht als einzelnen Datensatzen wird der Betrachtung von Zeitreihen und aggre

gierten Daten beigemessen. Da das Data Warehouse integriert die Daten aus verschie

denen Vorsystemen und auch tiber langere Zeitraume enthalten soli, wird das Volumen

der Datenbasis typischerweise sehr vie! groBer sein als in den operativen Systemen.357

Weil sich Anfragen an diese Datenbanken flexibel an den sich dynamisch wandelnden

Informationsbedarf der Nutzer anpassen mtissen, sind sie so auszulegen, daB auch

komplexe Queries, die sehr groBe Datenmengen betreffen sowie Join- und Aggregati

onsoperationen in den Datenbestanden bedingen, bewaltigt werden konnen.358

Die Organisation und Struktur der Daten, die sich aus den Anforderungen ergibt, un

terscheidet sich bei den beiden Systemklassen erheblich. Bei den operativen Systemen

ist ein Anpassen an die Funktionen oder Prozesse zweckmaBig, das Data Warehouse

soli sich dagegen an den entscheidungsrelevanten Sachverhalten des Unternehmens

orientieren.359 Neben der sich daraus ergebenden Notwendigkeit zur Schaffung einer

Datenbank, welche die verschiedenen operativen Quellen integriert und Daten auch

tiber langere Zeitraume vorhalt, beinhaltet dieses Konzept auch die Berechnung und

Speicherung aggregierter Daten auf unterschiedlichen Verdichtungsebenen.360 Damit

einher geht der Aspekt, daB Daten in analyseorientierten Systemen moglichst wenig

355

356

357

358

359

360

V gl. Chaudhuri/Dayal (1997), S. 65f. Vgl. z.B. LehmannlEllerau (1997). S. 81f.; Schinzer/Bange (1998), S. 45. V gl. Chaudhuri/Dayal (1997). S. 65f.; AnahorylMurray (1997). S. 325f. Vgl. Mucksch/Behme (I 998b). S. 49. V gl. Abschnitt 3.1.1. V gl. z.B. KemperlFinger (1998). S. 72f.


volatil sein sollten, urn reproduzierbare Berichte und andere Auswertungsergebnisse zu

ermoglichen.361

SchlieBlich soli als letztes Argument fUr die Trennung operativer und analyseorien

tierter Datenbestande die unterschiedliche Charakteristik der Systembelastung beim

Einsatz dieser DV -Systeme angefUhrt werden. Operative Systeme, auf denen von zahl

reichen Anwendern Transaktionen mit den genannten Merkmalen durchgefUhrt wer

den, haben einen eher gleichmaBigen Auslastungsgrad ohne ausgepragte Lastspitzen.

Bei den analyseorientierten Systemen treten dagegen in Abhangigkeit von den durch

gefUhrten Anfragen an die Datenbank kurzzeitige Hochstlasten auf, denen Phasen mit

nur geringer Auslastung folgen. Abbildung 16 zeigt in typisierter Form diese Charakte

ristik des Auslastungsgrades operativer und analyseorientierter Systeme. Entsprechend

traten im Fall der kombinierten Nutzung von Datenbestanden und Ressourcen durch

die Uberlagerung der Lasten Beeintrachtigungen der operativen Systeme durch die

Analyseoperationen auf, die nicht akzeptabel erscheinen.362

Das Data Warehouse als die eigenstandige Datenbasis fUr analyseorientierte Informati

onssysteme kann in unterschiedlichen Organisationsformen implementiert werden.

Analog zu den operativen Systemen JaBt sich auch eine Data Warehouse

Datenbankanwendung in zentraler oder verteilter Form realisieren.

Die haufigste Realisierungsform stellt das zentrale Data Warehouse dar, bei dem die

Verwaltung aller Datenbestande fUr die verschiedenen Front-End-Anwendungen auf

einem einzelnen Rechner erfolgt.363 Dabei handelt es sich im Regeifall auch urn die

zweckmaBigste Realisierungsform.364 Daneben kann ein Data Warehouse auch als

verteiltes Datenbanksystem implementiert werden, etwa urn eine Unternehmensstruk

tur mit geographisch, rechtlich oder organisatorisch ausgegliederten Bereichen wider

zuspiegeln.365 Hier werden die gleichen Uberlegungen relevant, wie sie auch im Rah

men der Beschreibung verteilter operativer Systeme erortert wurden.366

361

362 363

364 365

366

Vgl. Mucksch/Behme (I 998b), S. 49. Vgl. z.B. Kenan Technologies (1995). Vgl. Mucksch/Behme (l998b), S. 69f., wo auch Vor- und Nachteile dieses Konzepts diskutiert werden. Vgl. Inmon (1996), S. 197; Bontempo/Zagelow (1998), S. 41. Vgl. Mucksch/Behme (1998b), S.7lf.; Inmon (1996), S.198ff.; Devlin (1997), S.366ff.; Kimball et al. (1998). S. 28. Vgl. Abschnitt 2.3.3.2.

108

Operative Systeme

Auslastung 100

90

80

70

60

50

40

30

20

10

o Zeit

Analyseorientierte Informationssysteme

Analyseorientierte Systeme

Auslastung 100

90

80

70

60

50

40

30

20

10

o Zeit

Abbildung 16: Auslastungsformen operativer und analyseorientierter Systeme367

Als weitere Variante einer Data Warehouse-Architektur findet sich in der Literatur und

vor allem in Materialien der Hersteller entsprechender Produkte teilweise auch der

Begriff "Virtuelles Data Warehouse".368 Darunter wird der direkte Zugriff von den

Client-Rechnern der Anwender durch die Software zur Entscheidungsuntersttitzung

auf die operativen Datenbestiinde verstanden. Damit wird allerdings yom Grundgedan

ken einer eigenstiindigen, von den operativen Systemen getrennten Datenbank abge

riickt. Wie bei den tibrigen Varianten erfolgt der Zugriff nur Ie send, so daB Datensi

cherheit gegeben ist. Wie das Attribut "virtuell" bereits andeutet, ist damit ein Data

Warehouse im eigentlichen Sinne nicht vorhanden, es wird eine entsprechende Funk

tionalitat jedoch bereitgestellt, indem die Datenquellen tiber Middleware

Komponenten369 angesprochen werden konnen.370 Es wird also nicht nur von dem

Konzept der physisch getrennten Speicherung der analyseorientierten Daten abgeriickt,

367 368

369 370

In Anlehnung an Kenan Technologies (1995), S. 26, und Inmon (1996), S. 25. V gl. zu einer Diskussion dieses Konzepts Schinzer et al. (1997), S. 20ff.; Mucksch/Behme (l998b), S. 73f. Ein Beispielprodukt fUr ein virtuelles Data Warehouse wird in Aberdeen Group (1995) beschrieben. V gl. zur Funktionalitiit von Middleware auch Tresch (1996), S. 249ff. V gl. Schwarzkopf (1997).


sondern auch von der persistenten Transformation und Integration der Teildatenbe

stande zu einer konsistenten Gesamtheit.

Als Starke dieses Konzepts ist erkennbar, daB auf die Investition in die Data Ware

house-Infrastruktur teilweise verzichtet werden kann. Dieser vordergrundige Vorteil

wird jedoch durch eine Reihe gravierender Nachteile relativiert. So miissen Kompro

misse hinsichtlich der Ausgestaltung der Datenbank und des Datenbankrnanagement

systems gefunden werden, urn die beschriebenen grundlegenden Unterschiede der

beiden Nutzungsformen zu iiberbrucken. Besonders hohe Anforderungen werden bei

diesem Konzept zudem an die Systemkomponenten zur Transformation und Integrati

on der Daten gestellt, da diese mangels eigenstandiger Speichermoglichkeiten hier erst

zum Zeitpunkt des Bedarfs entsprechender Daten aktiv werden konnen. Da im iibrigen

hinsichtlich der Transformationsproblematik die gleichen Fragestellungen zu lOs en

sind wie bei den "nicht-virtuellen" Data Warehouse-Losungen, kann im weiteren eine

eigenstandige Betrachtung dieser Konzepte unterbleiben.

Sieht man ein Data Warehouse als einen (wenn auch spezialisierten) Anwendungsfall

eines Datenbanksystems an, kann zur Gliederung der folgenden AusfUhrungen wieder

urn das allgemeine Konzept der Aufteilung eines Datenbanksystems in die drei Kom

ponenten Datenbankverwaltungssystem, Datenbank und Datenbankkommunikations

schnittstelle dienen.371

- Datenbankverwaltungssystem

Das Datenbankverwaltungssystem ist im Data Warehouse die zentrale Instanz zur

Verwaltung der analyseorientierten Datenbestande. Es stellt die Funktionalitaten zur

Datendefinition und Datenmanipulation bereit. Hier ist erkennbar, daB an das Daten

bankmanagementsystem Anforderungen anderer Art gestellt werden als im Rahmen

operativer Anwendungen.

So kann den verschiedenen Aspekten der Datenintegritat, die bei den operativen Da

tenbanken eine wesentliche Rolle spielen, hier eine geringere Bedeutung zugemessen

werden. Die Sicherstellung der Datenkonsistenz erfolgt fUr das Data Warehouse iiber

wiegend durch die Transformations- bzw. Importkomponenten und tritt aufgrund der

niedrigen Volatilitat im Data Warehouse in den Hintergrund. Daher kommt den Trans

aktions- und Sperrfunktionen hier eine geringere Bedeutung zu. Datensicherheit kann

einerseits unter dem Aspekt des Schutzes vor Verlust der Daten als weniger bedeutsam

371 V gl. zu den Komponenten eines Datenbanksystems Gabriel/Rohrs (1995). S. 256ff.


angesehen werden, da es sich bei den Daten im Data Warehouse ohnehin urn Kopien

anderer Datenbestlinde handelt, deren Verlust weniger geschaftskritisch ist als die

Unbrauchbarkeit der operativen Systeme, we1che die Handlungsfahigkeit im Unter

nehmen massiv beeintrachtigte. Andererseits ist dem Aspekt des Schutzes vor uner

laubtem Zugriff moglicherweise groBere Bedeutung zuzumessen, da durch die Autbe

reitung der Daten diese auch flir unbefugte untemehmensinteme und -exteme Nutzer

von groBerem Wert sein konnten als die Quelldaten. Vor diesem Hintergrund sind

zudem die spezifischen Fragen des Datenschutzes im Data Warehouse-Kontext be

deutsam und werden neuerdings diskutiert.372

Dartiber hinaus ergeben sich auch spezifische Anforderungen, denen im Data Ware

house-Umfeld besondere Bedeutung zukommt. Diese werden im folgenden iiber

blicksartig vorgestellt. 373

• Unterstiitzung der groBen Datenmengen, die fUr ein Data Warehouse charakteri

stisch sind. Hier muE nicht nur die Moglichkeit zur Adressierung entsprechend gro

Ber Speichereinheiten bestehen. Gleichzeitig ist es erforderlich, daB auch komplexe,

meist nur lesende Anfragen auf diese Datenbestande mit kurzer Antwortzeit durch

gefUhrt werden konnen.374 Dies bedingt das Vorhandensein problemadaquater, effi

zienter Indexierungsverfahren.375

• Unterstiitzung mehrerer Speichermedien, urn Teile der Datenbestande entsprechend

der Zugriffshaufigkeit auf kostengiinstige Archivmedien auslagem zu konnen.376

• Unterstiitzung der Partitionierung der Datenbestande. So konnen z.B. die in einzel

nen Tabellen enthaltenen Daten auf mehreren Datentragem verteilt abgelegt werden,

urn so komplexe Datenbankanfragen durch parallelisierte Leseoperationen schneller

372

373

374

375

376

Vgl. zu einer Wertung des Data Warehouse unter Datenschutzaspekten Moller (1998), S. 558f., und Moncke (1998), S. 564ff. V gl. Inmon (1996), S. 16lff.; Schinzer et al. (1997), S. 31 f. Zur Messung der Leistungsfahigkeit von Datenbanksystemen, aus der auch Anhaltspunkte tiber das Antwortzeitverhalten gewonnen werden konnen, lassen sich "Benchmarks" einsetzen. Vgl. GluchowskilHahne (1998), S. 72ff. Vgl. O'Neill/Quass (1998), S. 543ff. Hier werden vor diesem Hintergrund die Indexierungstechniken "Bitmap", "Bit-Slice" und "Projection Index" beschrieben und in bezug auf die Data Warehouse-Anforderungscharakteristik bewertet. Gluchowski (1998d), S. 16ff., beschreibt die Einsetzbarkeit herkommlicher Indexierungstechniken im Data Warehouse-Kontext. Eine Diskussion verschiedener Speichermedien unter Data Warehouse-Gesichtspunkten erfolgt in Meyer/Cannon (1998), S. 103ff.

Architekturen und Komponenten III

durchfUhren zu konnen. Zugleich verbessert die Moglichkeit der Partitionierung die

Erweiterbarkeit des Systems im Zuge wachsender Datenmengen.377

Zusammenfassend kann festgehalten werden, daB die im Anforderungsprofil enthalte

nen Kriterien mit denen fUr operative Datenbanksysteme zwar identisch sind,378 jedoch

lassen sich andere Schwerpunkte im Profil der konkreten Auspragungen der Kriterien

erkennen.

Kommerzielle Datenbanksystemsoftware, die sich fUr den Aufbau eines Data Ware

house eignet, ist von den groBen Anbietern erhaltlich. So sind in den vergangenen

lateen die marktbedeutenden relationalen Datenbankrnanagementsysteme wie z.B. die

der Hersteller Oracle oder IBM urn Zusatzfunktionalitaten erweitert worden, urn den

spezifischen Anforderungen einer Data Warehouse-Datenbank gerecht zu werden,379

Fur den Einsatz solcher Produkte spricht, daB es sich urn Software handelt, die mit dem

Relationenmodell auf einem weitgehend standardisierten konzeptionellen Datenmodell

basiert. 1m Bereich der operativen Anwendungen ist fUr diese Produkte unstrittig, daB

sie zuverHissig groBe Datenmengen speichern und mit hoher Geschwindigkeit verar

beiten konnen. Auch sind in den meisten Unternehmen Erfahrungen mit dieser Tech

nologie vorhanden, so daB sich ein Einsatz relationaler Datenbanksysteme zum Aufbau

eines Data Warehouse empfiehlt.380

Auf der anderen Seite sind hier die Einsatzbedingungen und das Einsatzumfeld anders

als bei den operativen Systemen, so daB Datenbanksysteme, die ein mehrdimensionales

Datenmodell implementieren, problemadaquater erscheinen. Diese gelten jedoch heute

als weniger ausgereifte Produkte, die aus Performancegrunden nur fUr verhaltnismiiBig

kleine Datenvolumina geeignet erscheinen.381 Ein weiterer Nachteil dieser Produktka

tegorie liegt in der mangelnden Transparenz und Standardisierung dieser Datenbanksy

sterne. Sind z.B. die verwendeten Speichertechniken, der Aufbau der Data Dictionaries

und das Zusammenwirken der verschiedenen Serverprozesse bei relationalen Daten

banksystemen weitgehend dokumentiert, werden mehrdimensionale Datenbanksysteme

meist als "Black Box" verkauft. Dies fUhrt dazu, daB Datenmodelle nicht von einem

Datenbanksystem zu einem anderen ubertragen werden konnen.

377

378

379 380 381

V gl. Inmon (1996), S. 57ff. Ein Anwendungsbeispiel beschreibt Scalzo (1996), S. 67ff. V gl. Schinzer et al. (1997), S. 31 f. Vgl. Gluchowski (1998b), S. 16 und 20. Vgl. Mucksch/Behme (I 998b), S. 55. G1uchowski (I 998b), S. 19, nennt eine Grenze von ca. 20 GB.


Die Abbildung von Datenstrukturen in physisch multidimensionalen Datenbanken

wirft das Problem auf, daB in dem entstehenden vieldimensionalen Wurfel nicht aile

Zellen mit Werten gefiillt sind, da sich nicht jeder Kombination von Dimensionsaus

pragungen eine sinnvolle GroBe zuordnen liiBt. Als pragnantes Beispiel fiir diese Si

tuation kann eine zweidimensionale Matrix betrachtet werden, die mit Werten eindi

mensionalen Charakters gefiillt ist. Hier bestehen nur sehr wenige Beziehungen zwi

schen den einzelnen Datenelementen. Jede Zeile und jede Spalte der Matrix enthiilt nur

genau eine Zelle, die mit einem relevanten Wert gefiillt ist. Die ubrigen Zellen enthal

ten einen Sonderwert, der anzeigt, daB keine Daten vorhanden sind.382 Man spricht hier

von dunn besetzten Matrizen (sparse arrays).383 Da auch die nicht mit einem Wert

belegten Zellen Speicherplatz und Verarbeitungskapazitat beanspruchen (im Gegensatz

zu einer relationalen Struktur, wo die Anzahl der Tupel reduziert wurde), ist die spezi

fische Verarbeitungsleistung der Datenbank umso geringer, je dunner die Datenstruk

tur mit relevanten Werten besetzt ist. Daher wird angestrebt, durch Verfahren zum

Umgang mit dunn besetzten Matrizen auf der physischen Ebene zur Verbesserung der

Verarbeitungsleistung und zur Speicherplatzersparnis die Quote der unbesetzten Zellen

zu verkleinern.384

Aus einer heutigen Sicht, die einerseits relationale Datenbanksysteme als gereifte und

am Markt etablierte Produkte kennt, in der aber andererseits mehrdimensionale Daten

banksysteme als eine noch am Anfang der Entwicklung stehende Technologie klassifi

ziert werden konnen, werden vielfach Empfehlungen zur Produktauswahl getroffen.385

So wird ausgefiihrt, daB multidimensionale Datenbanksysteme hinsichtlich ihrer Spei

cherformen problemadaquater sind und leistungsfiihige Mechanismen zur Ausfiihrung

mehrdimensionaler Operationen enthalten. Sie erlauben das Navigieren durch die

Hierarchien und fiihren Aggregationen zu Werten hoherer Hierarchiestufen zur Lade

zeit durch und speichern aile diese Werte, urn so einen schnell en Zugriff auf die aggre

gierten Werte zu ermoglichen. Aufgrund der komplexen Strukturen entstehen jedoch

auch aus verhaltnismiiBig kleinen operativen Extrakten sehr groBe Datenmengen, die

insgesamt schwer handhabbar erscheinen. Daraus ist abzuleiten, daB multidimensio

nale Datenbanksysteme derzeit eher fUr kleinere Projekte oder Teildatenbestande

382

383

384

385

Ein Beispiel zeigen Holthuis (l998b), S. 170ff., sowie Kenan Technologies (1995), S. 13. Vgl. zu dieser Problematik Chamoni (1998), S. 241ff. Vgl. Holthuis (1998a), S. 189. V gl. zu den folgenden Ausfiihrungen zu technischen Merkmalen multidimensionaler Datenbanksysteme Meyer/Cannon (1998), S. 78ff.


zweckmaBig erscheinen, wahrend zur Speicherung sehr groBer Datenmengen eher

relationale Datenbanksysteme eingesetzt werden sollten.386

Als wei teres Argument fUr die ausgereiftere relationale Technologie kann angeftihrt

werden, daB hier etablierte Produkte mit gefestigter Position im Markt verfUgbar sind.

Mehrdimensionale Systeme dagegen entstammen tiberwiegend einem Anbieterspek

trum, das derzeit noch groBen Veranderungen unterworfen ist. So ist regelmaBig zu

beobachten, daB Anbieter neu am Markt erscheinen oder auch, etwa durch Firmenzu

sammenschltisse, wieder verschwinden. Hier ist die Frage zu stellen, ob ein ausge

wahltes Produkt unter diesen Rahmenbedingungen ausreichende Investitionssicherheit

fUr den Einsatz in einem Data Warehouse-Projekt bieten kann und ob tiber einen lange

ren Zeitraum mit Weiterentwicklungen des Datenbanksystems und Anpassungen an

neue Hardware und Betriebssysteme gerechnet werden kann. Dieses Argument wiegt

vor allem insofern schwer, als - anders als bei den relationalen Produkten - wie er

wahnt keine standardisierten Strukturen vorliegen, so daB ein Wechsel des Datenbank

systems auch eine Neuentwicklung der entsprechenden Modelle erforderlich erschei

nen laBt.

Insgesamt wird prognostiziert, daB mehrdimensionale Datenbanksysteme aufgrund

ihrer groBeren Problemadaquanz und den daraus resultierenden potentiellen Perfor

mancevorteilen mit zunehmender Reife dieser sehr neuen Technologie an Bedeutung

gewinnen werden.387

- Datenbank

Die Data Warehouse-Datenbank bildet mit den dort gespeicherten aktuellen und histo

rischen Daten aus allen eingebundenen Unternehmensbereichen in den unterschiedli

chen Verdichtungsstufen den Kern eines analyseorientierten Informationssystems.

Hinsichtiich der Struktur ergeben sich neben den bereits diskutierten Aspekten der Art

des Datenmodells insbesondere im Hinblick auf aggregierte Daten wichtige Unter

schiede zu operativen Datenbanksystemen.388

Verdichtete Daten haben im Data Warehouse-Konzept einen groBen Stellenwert.389

Hier ist aus der Sicht des Anwenders ein Zielkonflikt erkennbar: Aggregierte Daten

386

387

388

389

Vgl. Raden (1995); Holthuis (1 998a), S. 186. Vgl. Mucksch/Behme (1998b), S. 55; Gluchowski (l998b), S. 19. Vgl. Bischoff (1994), S. 27ff. In operativen Datenbanksystemen spielen sie dagegen kaum eine Rolle, da hier primiir Detai1daten verarbeitet werden.


sind flir Auswertungen haufig von groBerem Interesse als detaillierte Einzelwerte.

Andererseits erlauben nur Daten niedriger Granularitat390 Drill-Down-Operationen hin

zu entsprechenden Detaildaten. Aus einer technischen Sicht erscheint dagegen eine

moglichst hohe Granularitat generell vorteilhaft, weil so das Datenvolumen abnimmt

und damit die flir die Bearbeitung von Anfragen an die Datenbank benotigten Ressour

cen und die Netzbelastung geringer werden.391 Diese konfliktaren Anforderungen an

die Granularitat der Daten im Data Warehouse sind gegeneinander abzuwagen, em

Modellierungsaspekt, dem eine groBe Bedeutung zuzumessen ist.392

Eine Losung dieses Zielkonflikts kann in der schrittweisen Aggregation der Daten

liegen. Aktuelle Daten werden dabei auch in detaillierter Form vorgehalten, urn zeitnah

Auswertungen auf Detailebene zu ermoglichen. Folgt man der Annahme, daB altere

Detailwerte an Relevanz verlieren, konnen verschiedene Aggregationsstufen festgelegt

werden, wobei mit zunehmendem Alter der Daten nur noch Werte hoherer Granularitat

verfligbar sind. Detailwerte konnen dann auf Offline-Archivmedien ausgelagert wer

den.

- Datenbankkommunikationsschnittstelle

Auf die vielfaltigen Datenbankkommunikationsschnittstellen zu den Datenquellen des

Data Warehouse und zu den Werkzeugen der Endbenutzer wird wegen ihrer groBen

Bedeutung in einem separaten Abschnitt eingegangen (vgl. Kapitel 3.5).

3.3.2 Data Mart

Ein unternehmensweites, zentrales Data Warehouse bildet die "groBe Losung" zur

Realisierung einer Datenbank flir analytische Zwecke. Es werden jedoch auch kleinere

Losungen diskutiert, die einfacher, schneller und mit niedrigeren Kosten zu realisieren

sind und die sich im Betrieb als flexibler erweisen. Solche Teilausschnitte aus der

unternehmensweiten Datenbasis werden als Data Mart bezeichnet und haufig in sehr

unterschiedlicher Weise in das Gesamtkonzept analyseorientierter Informationssysteme

eingeordnet.

390

391

392

Mit dem Begriff der Granularitat wird der Detaillierungsgrad der Daten beschrieben, vgl. Inmon (1996), S. 45ff. Je detaillierter die Datenbestande, desto niedriger ist nach dieser Terminologie die Granularitat. Vgl. Bischoff (1994), S. 31; Inmon (1996), S. 48. Vgl. Inmon (1996), S. 45f.


So wird ein Data Mart einerseits als Teilmenge des Data Warehouse gesehen, in dem

ein Ausschnitt der Datenbestande nochmals redundant gehalten wird.393 Dies laBt sich

aus der GroBe und Struktur des Data Warehouse begriinden. Es beinhaltet sehr groBe

Datenbestande, die aus den genannten Erwagungen meist auf relationalen Datenbank

systemen basieren und somit bezogen auf Anfragen in nicht vollstandig problem

adaquaten Strukturen organisiert sind. Insbesondere beim interaktiven Zugriff auf die

Datenbestande erweist sich daher das Data Warehouse hinsichtlich der Reprasentation

der Daten und auch der Antwortzeiten moglicherweise als nicht anforderungsgerecht.

Zur Losung dieses Problems konnen z.B. funktions- oder bereichsspezifische Extrakte

aus der Data Warehouse-Datenbank entnommen und redundant in einem Data Mart

gespeichert werden. Dieser kann mit der g1eichen Technologie und einem Datenmodell

realisiert sein, das einer echten Teilmenge des Data Warehouse entspricht, so daB eine

leichte Pflegbarkeit des Data Mart vorliegt.394 Alternativ erscheint es aber auch

zweckmaBig, fUr den Data Mart mit seinem iiberschaubaren Datenvolumen im Gegen

satz zum relational basierten Data Warehouse ein mehrdimensionales Datenbanksy

stem zu nutzen, urn die potentiell besseren Modellierungs- und Abfragemoglichkeiten

dieser Technologie ausnutzen zu konnen. Aufgrund der dann notwendigen Transfor

mation der Daten in das neue Modell wird allerdings die Pflege solcher Data Marts

aufwendiger, so daB hier eine Abwagung der Vor- und Nachteile heterogener Daten

mode lie erforderlich ist.

Die Anwender erhalten mit dem Data Mart einen auf ihre Informationsbediirfnisse

zugeschnittenen Ausschnitt aus der unternehmensweiten Datenbasis. So konnen bei

sorgfaltiger Abgrenzung dieser Ausschnitte wesentliche Teile der Anfragen aus dem

Data Mart bedient werden, was gegeniiber einem direkten Zugriff auf die Data Ware

house-Datenbank Vorteile hinsichtlich der Zugriffsgeschwindigkeit erwarten laBt.395

Neben dieses Konzept, das die gezielte Bildung von Data Marts als Teilmengen eines

Data Warehouse zur besseren Informationsversorgung der Anwender vorsieht, tritt der

Ansatz, Projekte zur Realisierung einer Datenbasis fUr ein analyseorientiertes Informa

tionssystem mit dem Aufbau einzelner Data Marts zu beginnen. Dies kann mit wenigen

Projektmitarbeitern in verhaltnismaBig kurzer Zeit verwirklicht werden, so daB Ergeb-

393

394

395

V gl. Anahory/Murray (1997), S. 69; Mucksch/Behme (I 998b), S.45f.; Gluchowski (I 998b), S.16. Vgl. Mucksch/Behme (I 998b), S. 45f. Vgl. Gluchowski (l998b), S. 16.


nisse schneller und zu geringeren Kosten sichtbar werden als bei der Implementierung

eines unternehmensweiten Data Warehouse.396 Schrittweise lassen sich dann weitere

Datenquellen integrieren, so daB flieBend eine graBere, eher als Data Warehouse zu

bezeichnende Lasung entsteht.397

Teilweise wird auch vallig auf den Aufbau des zentralen Data Warehouse verzichtet,

so daB die Datenversorgung fUr das analyseorientierte Informationssystem ganz auf

den Data Marts basiert. Hier ist allerdings erkennbar, daB eine Vielzahl von Schnitt

stellen zu den Vorsystemen erforderlich ist, die einen hohen Installations- und Pflege

aufwand erfordert.398 Auch die Synchronisation der Datenbestande in den verschiede

nen Data Marts, die zur Sicherung einer Gesamtkonsistenz der Datenbestande erfor

derlich ist, erscheint aufwendig, zumal sehr groBe Redundanzen durch die tiberlappen

den Datenbestande in den verschiedenen Data Marts entstehen,399 SchlieBlich kann als

weiterer Nachteil eines solchen Vorgehens angefUhrt werden, daB die Integrationsba

sis, die mit einem Data Warehouse fUr die Daten aus den verschiedenen Quellsystemen

vorliegt, hier fehlt. Somit kann dieser gewichtige Vorteil eines Data Warehouse nicht

genutzt werden.4OO Aufgrund dieser Aspekte wird ein solches Vorgehen, das zunachst

den Aufbau von Data Marts vorsieht, auch kritisiert.401

Die Begriffe Data Warehouse und Data Mart bezeichnen innerhalb eines analyseorien

tierten Informationssystems die Bausteine, die der Datenspeicherung dienen. 1m Sinne

einer schematisierten Architekturbetrachtung sind die angeschlossenen Front-End

Werkzeuge, mit deren Hilfe die Benutzer auf die Datenbestande zugreifen kannen, von

den datenspeichernden Komponenten zu trennen und somit keine Bestandteile des

Data Warehouse im engeren Sinne. Idealisiert liegt auch hier Daten-Programm

Unabhangigkeit vor, die es erlaubt, mit verschiedenen Tools tiber offene Schnittstellen

auf die Daten zuzugreifen, so daB fUr die Back-End- wie ftir die Front-End-Seite je

weils besonders geeignete und unabhangig voneinander austauschbare Hard- und

Softwarekomponenten zum Einsatz kommen kannen. Trotz dieser begrifflichen Tren

nung darf jedoch nicht tibersehen werden, daB in der Praxis haufig eine enge technolo

gische Verzahnung der Endbenutzerwerkzeuge mit den datenspeichernden Kompo-

396 397 398 399 400

401

Vgl. Schinzer et al. (1997), S. 23. Vgl. Behme (1996), S. 35f.; Miley (1998), S. 80f. Zu diesem Konzept vgl. auch Anahory/Murray (1997), S. 71 f. Vgl. Schinzer/Bange (1998), S. 45. Vgl. Inmon (I 997b). V gl. z.B. Inmon (l997a); Martin (1998), S.13!.


nenten erkennbar ist, die sich bei der Verwendung von Produkten des gleichen Her

stellers und auch durch die meist bessere Funktionalitat und Ubertragungsgeschwin

digkeit spezialisierter im Vergleich zu offenen Schnittstellen ergibt.

Die unterschiedlichen Endbenutzerwerkzeuge, die zu analytischen Zwecken eingesetzt

werden konnen, werden im folgenden Abschnitt beschrieben.

3.3.3 Endbenutzerwerkzeuge

Beim Aufbau analyseorientierter Informationssysteme muB immer der Einsatznutzen

fUr den Endanwender im Vordergrund stehen. Der mit hohen Kosten verbundene Auf

bau eines Data Warehouse darf keinen Selbstzweck darstellen, sondem muB durch die

Informationsbedtirfnisse der Endanwender getragen werden, so daB auch hinsichtlich

der Front-End-Werkzeuge der Einsatznutzen in den Vordergrund der Betrachtung

rtickt. Von groBer Bedeutung ist es somit, daB Endbenutzerwerkzeuge vorhanden sind,

welche die passenden Auswertungs- und Analysemoglichkeiten bereitstellen.

Die entsprechenden Werkzeuge umfassen ein breites Spektrum: Es reicht von Tools

zur Erstellung von Berichten tiber Ad-Hoc-Abfrage- und Analysewerkzeuge in einfa

cher oder komplexer Form bis hin zu vielschichtigen, multidimensionalen Auswer

tungssystemen (OLAP). Noch einen Schritt weiter gehen Data-Mining-Techniken, die

der zumindest teilweise automatisierten Entdeckung von Zusammenhiingen in den

Daten dienen. Eine klare Abgrenzung dieser Werkzeugkategorien erscheint problema

tisch, da die Grenzen zwischen den Moglichkeiten der Produkte und auch die Anforde

rungen der Benutzer zunehmend unscharf werden.402 1m folgenden werden kurz einige

wesentliche Merkmale dieser Formen von Endbenutzerwerkzeugen genannt, urn so

exemplarisch zu zeigen, welche Aufgaben durch eine Data Warehouse-Datenbasis

unterstiitzt werden konnen.

Berichtswerkzeuge sind wohl in nahezu jedem Untemehmen im Einsatz. Sie dienen

dazu, in allen Untemehmensbereichen und auf allen Hierarchiestufen Einsicht in die

relevanten Sachzusammenhange zu liefem. Selbstverstandlich wurden Berichte auch

schon vor dem Aufkommen des Data Warehouse-Gedankens erzeugt, jedoch liegt die

Idee nahe, aufgrund der Nutzungscharakteristik auch das Berichtswesen aus einem

Analysedatenbestand zu speisen. Dabei wird unter einem Bericht allgemein eine peri-

402 Vgl. Chamoni/Gluchowski (I 998c), S. 433.


odisch oder im Bedarfsfall erzeugte Sammlung relevanter Fakten fUr Fach- und Ftih

rungskrafte verstanden.403

Software-Werkzeuge, die der Erstellung solcher Berichte dienen, lassen sich hinsicht

lich ihres Funktionsumfangs und der Formen der erzeugten Berichte in vielfacher

Weise beschreiben. Das Spektrum beginnt bei einfachen Abfragewerkzeugen, die im

wesentlichen der benutzerfreundlichen Formulierung entsprechender Datenbankabfra

gen dienen und aus den Eingaben die entsprechenden Anfragen in der Datenbankspra

che erzeugen. Mehr Funktionalitat bieten Werkzeuge, die als Berichtsgeneratoren

Berechnungs- und Gestaltungsmoglichkeiten fUr die Berichte implementieren. Tools,

die sich der Gruppe der "Managed Query Environments" zuordnen lassen, bieten dar

tiber hinaus Moglichkeiten zur zeitlichen, inhaltlichen und interpersonal en Koordinati

on der Berichte.404 Insgesamt erscheinen Werkzeuge zum Aufbau betrieblicher Be

richtssysteme geeignet, urn weitgehend standardisierte Informationen zuammenzustel

len und anforderungsgerecht aufzubereiten.405 Eine Modifikation der vermittelten

Inhalte und eine interaktive Navigation ist dagegen meist nicht vorgesehen und auch

zumindest dann nicht moglich, wenn die Berichte den Benutzern in Papierform zu

ganglich gemacht werden. Ein Bericht ist also eher durch eine passive Haltung des

Benutzers gekennzeichnet, der diesen entgegennimmt und bearbeitet.

Eine flexiblere Exploration der Daten wird durch Werkzeuge realisiert, die groBere

Freiheitsgrade bei der Navigation in den Datenbestanden ermoglichen. Auf diese Wei

se kann ein Data Warehouse als Datenbasis fUr Executive-Information-Systeme ge

nutzt werden.406 Entsprechende Werkzeuge erlauben es dem Benutzer, interaktiv am

Bildschirm die Daten aus verschiedenen Blickwinkeln und in unterschiedlichen De

taillierungsgraden anzusehen. Hier kommen die Konzepte des OLAP zum Einsatz.

Insbesondere soll dem Benutzer die Moglichkeit gegeben werden, durch die Daten des

mehrdimensionalen Problemraumes zu navigieren und eigenstandig beliebig zusam

mengestellte Informationsausztige zu bilden, die fUr ihn von groBerem Interesse sind

als standardisierte Berichte.407 Die zugrundeliegenden Anwendungen mtissen also die

beschriebenen Operationen fUr mehrdimensionale Datenstrukturen wie Roll-Up

403 404 405

406 407

In Anlehnung an Gluchowski (l998a), S. 1174f. Vgl. Gluchowski (l998a), S. I 174ff., sowie ausfiihrlicher Gluchowski (l998c), S. 188ff. Mertens/Griese (1993), S. 41, wei sen allerdings darauf hin, daB Berichte vielfach wenig bedarfsgerecht erzeugt und kaum gelesen werden ("ZahlenfriedhOfe"). Vgl. GluchowskilGabriellChamoni (1997), S. 275f.; Schinzer et al. (1997), S. 56ff. Beispielanwendungen zeigt Totok (1998), S. 170ff.


(Aggregation), Drill Down (Disaggregation) sowie insbesondere Slicing und Dicing

ermoglichen.408

Die bisher angesprochenen Tools zum Zugriff auf Daten in einem Data Warehouse

setzen voraus, daB der Benutzer in der Lage ist, prazise Anfragen zu formulieren. So

mit wird ein groBes MaB an inhaltlichem Wissen tiber Zusammenhange in den Daten

bereits vorausgesetzt. Erweitert man den Gedanken der Datenanalyse, so liegt es nahe,

auch nach bisher nicht explizit formulierten Zusammenhangen zu suchen und so auto

matisiert ntitzliches, nicht-triviales Wissen aus groBen Datenbanken zu filtern.409 Ent

sprechende Ansatze sind unter dem Begriff Data Mining bekannt geworden. In einem

umfassenderen Rahmen, der den GesamtprozeB der Datenanalyse und Ergebnisinter

pretation umfaBt, wird auch von Knowledge Discovery in Databases (KDD) gespro

chen.4lO

Data Mining-Techniken wird vielfach eine wichtige Rolle bei der Analyse von Daten

besUinden in einem Data Warehouse zugesprochen.411 HierfUr sind zwei Grtinde aus

zumachen: Einerseits liegen mit den applikationstibergreifend integrierten und von den

operativen Datenbanken getrennten Datenbestanden im Data Warehouse gtinstige

Voraussetzungen fUr die Anwendung von Data Mining-Verfahren vor, andererseits

bilden effiziente Techniken zur teilweise automatisierten Auswertung der Datenbe

stande einen Ansatz, urn den Aufwand zur Gewinnung der Informationen aus den

Datenbestanden so zu verringern, daB diese breiteren Anwenderkreisen zuganglich

gemacht werden konnen.412

Zusammenfassend sei festgehalten, daB em Data Warehouse als datenversorgende

Basis fUr ganz unterschiedliche Front-End-Werkzeuge dienen kann, mit denen sich - je

nach Interessenlage und Qualifikation des Nutzers - verschiedene Fragestellungen

leichter beantworten lassen. Berichtssysteme untersttitzen bei Fragestellungen des

Typs: "Was ist geschehen?". OLAP-Tools eignen sich fUr die Frage "Warum ist es

408

409

410 411

412

V gl. zu den Operationen fUr mehrdimensionale Datenmodelle Abschnitt 3.2.1. Vgl. Bissantz/Hagedorn (1993), S. 481. Vgl. FayyadlPiatetsky-ShapirolSmyth (1996), S. 2ff. V gl. Moxon (1996) sowie o. V. (1997), wo auch zahlreiche Beispiele fUr den Einsatz von Data Mining im Data Warehouse-Umfeld beschrieben werden. V gl. Scheer (1996), S. 75; BissantzlHagedornlMertens (1998), S.458f.; Brooks (1997). Beispiele fUr eine Anwendung von Data Mining fUrbetriebswirtschaftliche Fragestellungen zeigen Mertens/Bissantz/Hagedorn (1997), S. 186ff.


geschehen?", wahrend weitergehende Data-Mining-Tools potentiell geeignet erschei

nen, auch fUr die Frage "Was wird geschehen?" Unterstiitzung zu liefem.

3.4 MetadatenverwaItung analyseorientierter Informationssysteme

Zu den wesentlichen Bestandteilen in einem Architekturmodell fUr analyseorientierte

Informationssysteme gehort ein Meta-Datenbanksystem, in dem Informationen tiber

die tibrigen Systemkomponenten gehalten und verwaltet werden. Es soli nicht nur

administrativen Zwecken dienen, sondem auch den Benutzem ein schnelles und siche

res Auffinden der benotigten Daten ermoglichen.

In Abschnitt 2.4.3 wurde ausgefUhrt, daB der systematischen Sammlung, Verwaltung

und Nutzung von Metadaten im Rahmen der operativen Informationssysteme eine eher

untergeordnete Bedeutung zukommt. Auch wenn generell Vorteile durch den gezielten

Umgang mit Metadaten erkennbar sind, konnen sie trotzdem als nicht unbedingt fUr

den effizienten Einsatz operativer Informationssysteme notwendig klassifiziert werden.

1m Umfeld analytischer Informationssysteme dagegen stellt sich die Situation anders

dar. Hier gehort es zu den kritischen Erfolgsfaktoren, dem Endanwender neben einem

Vorrat standardisierter Berichte und Auswertungen auch die Moglichkeit zu bieten, im

verfUgbaren Informationsbestand frei zu navigieren und sich benotigte Reports mog

lichst wahlfrei zusammenstellen zu konnen. Nur so kann es gelingen, neue Strukturen

zwischen betriebswirtschaftlichen Betrachtungsobjekten aufzudecken und bislang

unerforschte WirkungsgefUge zu eruieren. Dazu jedoch muB dem Benutzer ein Hilfs

mittel an die Hand gegeben werden, das ihn zunachst tiber die verfUgbaren Inhalte

aufklart. 413

Anders als z.B. dem Datenbankadministrator oder dem Applikationsentwickler sind

dem Endbenutzer leicht zugangliche Metadaten-Benutzungsschnittstellen zur VerfU

gung zu stellen, die ihn von technischen Details entlasten. Als wtinschenswert konnen

Zugriffsformen eingestuft werden, die sich weitgehend an den Geschliftsbegriffen des

Endanwenders orientieren und moglichst semantische Erklarungshilfen integrieren.

413 V gl. zur Bedeutung sowie zu Struktur und Inhalt von Metadaten im Umfeld analyseorientierter Informationssysteme auch Devlin (1997), S. 52ff.; Holthuis (l998a), S, 99ff.; Brackett (1996), S. 185ff., sowie Poe (1996), S. l70f.

Metadatenverwaltung analyseorientierter Informationssysteme 121

Daneben kann eine leistungsfahige Meta-Datenverwaltung auch bei der Bestiickung

und Pflege der Data Warehouse-Datenbasis wertvolle Dienste leisten. Anders als im

operativen Umfeld, wo die Datenbasis zumeist durch transaktionsorientierte Benut

zereingaben gespeist wird, erfolgt die Befiillung der Warehouse-Datenbank zumeist

durch periodische Datentibernahmen aus den operativen oder externen Vorsystemen.

Durch eine geeignete Ausgestaltung der Metadatenkomponente lassen sich hier viel

faltige Aktivitaten koordinieren und automatisieren.

Insgesamt HiBt sich damit festhalten, daB das Aufgabenspektrum von Metadaten

Komponenten im analyseorientierten Umfeld und insbesondere in Data Warehouse

Umgebungen wesentlich weiter gefaBt ist als in operativen Systemen. 1m folgenden

werden zunachst die unterschiedlichen Arten von Metadaten kategorisiert und darge

stellt. Abschnitt 3.4.2 geht sodann detaillierter auf den Stellenwert von Metadaten im

hier relevanten Umfeld ein. AbschlieBend folgt ein Blick auf die Moglichkeiten zur

werkzeuggesttitzten Verwaltung von Metadaten im Data Warehouse-Umfeld

(Abschnitt 3.4.3).

3.4.1 Arten von Metadaten fUr analyseorientierte Informationssysteme

Metadaten, die in analyseorientierten Informationssystemen anfallen und Verwendung

finden, lassen sich nach verschiedenen Gesichtspunkten abgrenzen und klassifizie

ren.414 Hier wird eine Sichtweise gewahlt, die sich eng am architektonischen Aufbau

solcher Systeme orientiert und dabei eine trennscharfe Typisierung von Metadatenin

halten im Warehouse-Umfeld ermoglicht. Sie lassen sich in einem ersten Schritt da

hingehend klassifizieren, daB sie entweder das eigentliche Data Warehouse betreffen

oder aber die Schnittstellen zu den Vorsystemen bzw. zu den Endbenutzerwerkzeugen.

Metadaten im ersten Sinne sind damit alle Informationen tiber Strukturen und Prozes

se, die innerhalb des Data Warehouse vorzufinden sind. Zunachst sind dies alle Anga

ben tiber Datenstrukturen und Konsistenzbedingungen entsprechend der klassischen

Data Dictionary-Funktionalitat (vgl. Abschnitt 2.4.2). Starker als in den operativen

Metadatenverwaltungssystemen mtissen hier die Zusammenhange zwischen abgeleite

tern Datenmaterial und den zugrundeliegenden und originaren Basisdatenbestanden

aufgezeigt werden, zumal die Datenbestande vielfach nicht in normalisierter Form

414 Vgl. z.B. Devlin (1997), S. 54ff.; Gardner (1997), S. 65f.; Gardner (0.1.), S. 4; Moriarty/Greenwood (1996), S. 78ff.; MoriartylMandraccia (1996), S. 70ff.; Muksch (1997), S. C811.08.


vorliegen und damit auch die MaBnahmen zur Konsistenzsicherung eine andere Aus

rich tung erfahren mUssen. Darliber hinaus soil hier auch die Konsistenz bei mehreren

physikalischen Datenbestanden gesichert und der Austausch zwischen den einzelnen

Speichern sinnvoll dokumentiert werden.

Die Metadaten, welche die Schnittstelle zwischen Data Warehouse und Vorsystemen

beschreiben und steuern sollen, mUssen die VerknUpfungen zwischen den unterschied

lichen Systemkategorien in geeigneter Weise strukturieren. Dazu bedarf es zunachst

Angaben darliber, aus welchen Datenobjekten auf operativer Seite die Data Ware

house-Datenbestande gewonnen werden.

SchlieBlich ist auch die Schnittstelle zu den Endbenutzersystemen Entstehungs-, aber

auch Verwendungsort fUr vielfaltige Metadaten. Wie oben bereits angedeutet, sollen

die Endbenutzer die hier vorgehaltenen Metadaten nutzen, urn selbstandig und mog

lichst frei im Informationsbestand navigieren und interessante Informationsobjekte

selbst auswahlen zu konnen.415 Auch fUr den Data Warehouse-Administrator konnen

hier wertvolle Informationen anfallen, die ihm bei der nutzungsorientierten Verbesse

rung der internen Datenbankstruktur und bei der angemessenen Gestaltung von Ware

house-Inhalten helfen konnen.

Eine weitere Betrachtungsdimension ergibt sich aus der Unterscheidung zwischen

struktur- und funktionsorientierten Metadaten, und schlieBlich muB auch der Umstand,

daB die Metadaten im Verlauf der Entwicklung und Nutzung des Informationssystems

Veranderungen unterworfen sind, BerUcksichtigung finden.

3.4.1.1 Strukturorientierte Metadaten

Die vorgenommene Einteilung der Metadaten in Warehouse-interne sowie schnittstel

lenspezifische Inhalte kann somit helfen, urn in einem ersten Schritt die Metadatenty

pen zu klassifizieren, die in einem umfangreichen Data Warehouse-System anfallen.

Sie ist jedoch zu unscharf, wenn konkrete Metadaten-Inhalte anzugeben sind. Aus

diesem Grund wird in einem zweiten Schritt eine weitere Strukturierung vorgenom

men, indem zwischen internen, konzeptionellen und externen Metadateninhalten unter

schieden wird. Darliber hinaus findet auf der konzeptionellen Ebene sowohl die logi

sche als auch die semantische Sicht auf die Metadaten Beachtung. Insgesamt ergibt

sich dann eine Matrix aus verschiedenen Betrachtungsschwerpunkten, die durch die

415 V gl. White (1995).


systemebenenspezifische Fokussierung in den Zeilen und die Subsystemorientierung in

den Spalten der Matrix aufgespannt wird. Diese ist in Abbildung 17 dargestellt.

~ SchniHstelie zu den Data Warehouse- SchniHstelie zu den

Ebene Endbenutzersystemen Kernbereich Vorsystemen

Views einzelner Identifikation,

Views einzelner Externe Ebene Front-End- Transformations- und

Anwendungen OW-API

Extraktionsmodule

Semantische, natUrlich- ER-Diagramme,

Semantisch sprachliche Beschrei- Semantische Mulli- Herkunfts-bung der OW-Inhalte dimensionale Daten- beschreibungen

Konzeptionelle l!.~~~~r~~.p~~~~~!:1 ____ mode lie -------------------- --------------------

Ebene Schema-Beschreibung, Logisches Mapping

Logisch Schematransformation Tabellenbeziehungs- auf Tabellen-, diagramme, Feld- und/oder Benutzerprofile Dateienebene

Inter-Programm-Indexe, Indextypen (Bit-Indizierung), Physikalisches

Interne Ebene kommunikation, Zugriffspfade, Mapping

Protokolle, Treiber Belastungsstatistiken

Abbildung 17: Metadaten in Data Warehouse-Systemen nach Systemebenen und Subsystemen

In einer zeilenweisen Betrachtung dieser Matrix sind zunachst auf der externen Ebene

die nach auBen gerichteten Metadateninhalte der einzelnen Data Warehouse

Komponenten zu erfassen und abzubilden. Allgemein sollen hier die jeweils relevanten

Sichtweisen bzw. Views auf den Data Warehouse-Datenbestand hinterlegt sein. An der

Schnittstelle zu den Endbenutzersystemen sind dies die Subschemata, die den zugrei

fenden Front-End-Applikationen zur Verfiigung stehen. Wie durch einen Filter sehen

diese Anwendungen auf den gesamten Datenbestand, der ihnen nur einen einge

schrankten Blick mit den jeweils relevanten Daten einraumt.

Die externe Ebene des Data Warehouse-Kernbereichs reprasentiert die Schnittstelle zu

den Datenbestanden. Jeder Zugriff, der von auBen erfolgen soil, muB nach unter

schiedlichen Kriterien verifiziert werden. Zunachst geht es dabei urn die Identitatskon

trolle, die hilft, einen unbefugten Zugriff zu vermeiden und (wie bei anderen Systemen

ahnlicher Architektur auch) aus Sicherheitsgriinden eher im Warehouse als in den

Endbenutzeranwendungen erfolgen 5011. Benutzernamen und Kennworter sind hier als

Metadaten zu verwalten. Hier kommt die enge Verkntipfung mit der logischen Data


Warehouse-Ebene zum Ausdruck, wo tiber konkrete Berechtigungsprofile, die den

identifizierten Nutzern zugeordnet sind, der Zugriff auf einzelne Inhalte gestattet oder

verwehrt werden kann.

Die externe Ebene der Schnittstelle zwischen Vorsystemen und Data Warehouse ver

korpert dagegen die unterschiedlichen Sichten auf die Datenbestlinde, die die einzelnen

Ubernahmeprogramme benotigen. Die Metadaten beinhalten hier Angaben tiber Zu

ordnungen zwischen einzelnen Subschemata.

Der vielleicht ergiebigste Bereich zur Modellierung und Nutzung von Metadaten findet

sich auf der konzeptionellen Ebene. LosgelOst von Fragen der konkreten technischen

Umsetzung sollen hier Objekte und Strukturen allgemein und global dargestellt wer

den. Zu differenzieren ist dabei zwischen einer eher fachbezogenen (semantischen)

und einer eher DV-bezogenen (logischen) Sichtweise.

Auf der semantischen Ebene sind die relevanten Objekte und Strukturen so abstrakt zu

beschreiben, daB einerseits alternative technische Realisierungskonzepte zur Umset

zung dienen konnen und andererseits durch die Orientierung an fachlichen Geschlifts

begriffen ein transparenter Orientierungsrahmen ftir den Metadaten-Nutzer geschaffen

wird.

Zunlichst geht es dabei an der Schnittstelle zu den Front-End-Systemen urn eine fachli

che Beschreibung der einzelnen Datenobjekte in der Terrninologie des betrieblichen

Endanwenders, wie in Abbildung 18 exemplarisch und verktirzt dargestellt wird.

Der Zweck derartiger Definitionen liegt in einer exakten Interpretierbarkeit der hinter

legten Dateninhalte durch den Endanwender, urn semantischen MiBverstlindnissen bei

der freien Navigation zuvorzukommen, die aus der homonymen Verwendung einzelner

Geschliftsbegriffe erwachsen konnen. Wtinschenswert wlire an dieser Stelle eine hy

pertextbasierte Erfassung und Dokumentation aller Data Warehouse-Inhalte als glo

baler Datenkatalog, urn sich rasch tiber verkntipfte Dateninhalte informieren zu kon

nen. Ais tibergeordnete Orientierungstibersicht, die mit den einzelnen Datenobjekt

Definitionen zu verbinden wlire, konnte eine schematische Darstellung der betriebs

wirtschaftlichen Variablen dienen, wie sie z.B. in Kennzahlensystemen vorgenommen

wird.416

416 Vgl. zu betriebswirtschaftlichen Kennzahlensystemen z.B. Kiiting (1983); Meyer (1994).


Datenobjekt-Definition

Bezeichnung Erlbse

MaBeinheit OM

Beschreibung Realisierte, periodenbereinigte Nettoerlbse

Anwendung Entwicklung und Aufteilung der Nettoerlbse

Formel = Bruttoerlbse - Korrekturen

Aufgliederungs-Zeit (Monate), Geschaftsfelder, Kunden

richtungen

Aktualisierung Taglich

Abbildung 18: Semantische Beschreibung von Datenobjekten

Auch im Data Warehouse-Kernbereich kann eine Darstellung der enthaltenen Da

tenobjekte und ihrer Verkntipfungen auf semantischer Ebene hilfreich sein. Hier bietet

sich die Verwendung der bereits genannten Abbildungstechniken an.417

An der Schnittstelle zu den datenliefernden Vorsystemen sind abstrakte Informationen

dartiber zu erwarten, aus welchen Systemen die Data Warehouse-Daten rekrutiert

wurden. Nicht zuletzt auch flir den Endanwender sind diese Angaben von Interesse,

weil von einer Aquivalenz der einzelnen Zahlen durchaus nicht immer auszugehen ist.

So konnen beispielsweise selbst vergleichsweise triviale GroBen wie Umsatzzahlen

erheblich divergieren, wenn sie einerseits im Vertriebsbereich oder andererseits aus

den Daten des Rechnungswesens einer Unternehmung ermittelt werden, etwa weil ein

abweichendes Verstandnis tiber die Bedeutung und Zusammensetzung dieser GroBe

vorliegt.

417 Vgl. Abschnitt 3.2.


Auf der Ebene der logischen Metadaten sind es fUr den Data Warehouse-Kernbereich

zunachst die Schemabeschreibungen der hinterlegten Datenbanktabellen, die von Re

levanz sind. Hier gelangen beispielsweise Tabellenbeziehungsdiagramme als Star oder

Snowflake Schemata zur logischen Modellierung mehrdimensionaler Datenstrukturen

im relationalen Umfeld zur Anwendung.418 Daneben sind an dieser Stelle die Berechti

gungsprofile fUr bestimmte Nutzergruppen zu hinterlegen und mit den einzelnen

Schemabestandteilen zu kombinieren.

Auch an der Schnittstelle zu den Endbenutzersystemen fallen Metadaten auf logischer

Ebene an, die aus der notwendigen Transformation des Data Warehouse

Datenbankschemas in die logischen Schemata der Endbenutzersysteme resultieren.

Haufig wird z.B. eine Transformation von relationalen Tabellenschemata in die mehr

dimensionale Sichtweise der Endbenutzersysteme zu vollziehen sein. Gegenstand der

Metadaten an dieser Stelle ist es, die einzelnen Dimensionen und Fakten auf der End

benutzerseite mit den korrespondierenden Tabellenbestandteilen zu verbinden und

umgekehrt.

Ahnliche Transformationsbeschreibungen finden sich auch an der Schnittstelle zu den

Vorsystemen. Allerdings konzentriert sich das logische Mapping hier auf die Zuord

nung zwischen der Data Warehouse-Datenbank und den datenliefernden operativen

Datenspeichern, die relationale, hierarchische oder netzwerkartige Datenbanken, aber

auch Dateisysteme sein konnen.419 Dieser Aspekt ist auch Gegenstand des folgenden

Kapitels.

Neben der konzeptionellen und externen Ebene ist es die interne, implementierungsab

hangige Schicht, auf der vielfliltige Metadaten anfallen und benotigt werden. Aus dem

Datenbankbereich bekannt ist bereits die Betrachtung der internen Metadaten fUr den

Data Warehouse-Kernbereich, die die gewahlten Datenorganisationsformen umfas

sen.420 Hier sind etwa die Einstellungen zu dokumentieren, die am Datenbanksystem

vorgenommen werden, urn im Rahmen eines Datenbanktuning die Leistungsflihigkeit

des Systems zu beeinflussen. Hierzu gehoren beispielsweise die angelegten Indizes, die

einen raschen Zugriff auf die vorhandenen Datenbestande ermoglichen sollen. Neben

der Angabe der indizierten Tabellenspalten bedarf es im Data Warehouse-Umfeld

418 419 420

V gl. Abschnitt 3.2. Beispiele werden ausfiihrlich in Wieken (1998), S. 299ff., beschrieben. V gl. Gabriel/Rohrs (1995), S. 271.


zusatzlich der Auswahl eines fUr das konkrete Datenumfeld geeigneten Indextyps.421

Auch tiber die physikalische Positionierung und Partitionierung sowie die gegebenen

falls eingesetzte Verschliisselung des Datenbestands muB exakt Buch gefUhrt werden.

SchlieBlich kann der Administrator durch die Auswertung von automatisch mitgefUhr

ten Belastungsstatistiken Anhaltspunkte fUr eine Verbesserung der internen Datenor

ganisation erhalten.

An der internen Schnittstelle zu den angeschlossenen Endbenutzersystemen fallen die

Metadaten an, die die physikalische Verkntipfung zwischen den unterschiedlichen

Systemkategorien beschreiben. Dabei ist zu dokumentieren, welche Programme tiber

welche Protokolle auf welche Dateien bzw. Tabellen zugreifen. Dartiber hinaus lassen

sich hier fUr konkrete Applikationen Nutzungsbeschrankungen hinterlegen, die z.B. die

Zeit und/oder das Datenvolumen einzelner Abfragen begrenzen oder bestimmte Aktio

nen verbieten, wie das Sortieren oder Suchen in Tabellenspalten ohne Index.

Auch die interne Ebene der Schnittstelle zu den Vorsystemen kann tiber Metadaten

beschrieben werden, die dann Informationen tiber das physikalische Mapping zwischen

den Systernkategorien liefern. So lassen sich etwa konkrete Zugriffspfade hinterlegen,

die Ausktinfte tiber die Entsprechungen zwischen operativen Datenlieferanten und der

Data Warehouse-Datenbank geben. Auch Informationen tiber zu verwendende Netz

werkprotokolle und betriebssystembedingte Transformationen, etwa zwischen Zei

chensatzen, fallen in diese Kategorie.

Insgesamt kannen damit an jeder Schnittstelle zwischen den betrachteten Subsystemen

und Betrachtungsebenen Metadaten identifiziert werden, die Hinweise auf den Aufbau

einer Data Warehouse-La sung liefern. Ihre angemessene Dokumentation und sinnvolle

Nutzung fUr Administratoren, Applikationsentwickler und Endanwender stellt ein

geeignetes Instrument zum Einsatz eines analyseorientierten Informationssystems dar.

Dieser Katalog strukturorientierter Metadaten erscheint geeignet, urn das statische

Gesamtbild eines analyseorientierten Informationssystems beztiglich der abgebildeten

Informationsobjekte und ihrer Verkntipfungen zu reprasentieren. In einem weiteren

Schritt werden auch Aspekte, die Funktionen und steuernde Ereignisse des Data Ware

house betreffen, in die Betrachtung einbezogen.

421 Verschiedene Indextypen flir Data Warehouse-Umgebungen werden in O'Neill/Quass (1998) erlautert.


3.4.1.2 Funktionsorientierte Metadaten

Als wichtiger Bestandteil zur Modellierung eines analyseorientierten Informationssy

stems dtirfen Ereignisse und funktionale Aspekte nicht ausgeklammert werden, es muB

also neben dem "Was" auch das "Wie" und das "Wann" betrachtet werden. Aus die

sem Grunde erscheint es sinnvoll, den gewahlten Ansatz auszudehnen, indem in einer

weiteren Betrachtungsdimension funktionale und ereignisorientierte Aspekte der da

tenorientierten Sichtweise an die Seite gestellt werden. Entsprechende Elemente sind

in der folgenden Abbildung 19 in der bereits bekannten Gliederung nach Ebenen und

Subsystemen aufgeftihrt.

~ Schnittstelle zu den Data Warehouse- Schnittstelle zu den

Ebene Endbenutzersystemen Kernbereich Vorsystemen

Externe Ebene Alert-Regeln, Color-Coding-Regeln

Ablaufregeln f(j r Extraktions- und

Semantisch Funktionshandbuch OW-interne Prozesse, Transformationsregeln

OatenfluBdiagramme Konzeptionelle -------------------- -------------------- --------------------Ebene

API zu den Logisch Frontend-API Triggerspezifikationen Transformations-

werkzeugen

Parallelisierung,

Interne Ebene Query-Optimizer, Oatensicherung, Archivierung

Abbildung 19: Funktionsorientierte Metadaten in Data Warehouse-Systemen

Bei einer wiederum zeilenweisen Betrachtung dieser Matrix riickt zunachst die externe

Ebene ins Blickfeld. Hier erscheinen funktionale Metadaten in erster Linie in bezug

auf die Schnittstelle zu den Endbenutzersystemen als relevant. Beispielsweise konnen

Angaben tiber anwendungsspezifische Kausalbeziehungen vorgehalten werden. Es

lassen sich, zugeschnitten auf einzelne Anwendungen oder Anwender, etwa Alert

Bedingungen definieren, die bei Eintreffen bestimmter Datenkonstellationen Meldun

gen an die Endbenutzersysteme aussenden, oder aber bestimmte Color-Coding-


Schemata, die in Abhangigkeit von konkreten Datenwerten die Darstellungsform be

stimmen.

Allgemeine, abstrakte Regeln filr die Uberfilhrung von Eingangsdatenobjekten in Aus

gangsdatenobjekte lassen sich auf der semantischen Ebene filr aIle Subsystembereiche

aufstellen.

An der Schnittstelle zu den Endbenutzern gewahrt ein fachlich-betriebswirtschaftlich

orientiertes Funktionshandbuch einen Uberblick tiber die implementierten Funktionen,

die auf dem verfilgbaren Datenmaterial zur Anwendung kommen konnen. Insbesonde

re sind die Eingangs- und AusgangsgroBen der Funktionen sowie Regeln zu deren

Einsatz zu beschreiben, urn so dem Benutzer die richtige Anwendung solcher Funktio

nen und eine inhaltliche Interpretation der Ergebnisse zu ermoglichen.422 Auch em

aussagekraftiges Beispiel kann die Anschaulichkeit der Beschreibung verbessern.

Ftir den Data Warehouse-Kernbereich lassen sich verschiedene interne Prozesse durch

Metadaten abstrakt abbilden. Analog zur GeschaftprozeBmodeIlierung konnen die

Prozesse hier in einzelne Vorgange zerlegt und in Funktionsbaumen, Vorgangsketten

diagrammen oder DatenfluBdiagrammen dargestellt werden.423 Aggregiert vorgehaite

ne Werte sind beispielsweise nach einer Aktualisierung des Datenbestands teilweise

neu zu berechnen. Sofern dies innerhalb der Data Warehouse-Datenbank durchgefilhrt

wird, sollten die entsprechenden Funktionen auch auf semantischer Ebene beschrieben

werden. So wird gleichzeitig eine Dokumentation tiber die erzeugten Daten und ihre

Entstehung mitgefilhrt und eine Anpassung der Algorithmen an sich andernde Gege

benheiten erleichtert. Weitere Beispiele filr entsprechende Funktionen bzw. Prozesse

sind mit der Datensicherung sowie der Archivierung von aiterem Datenmaterial gege

ben.

Auch bei der Durchfilhrung von Datentibernahmen aus den Vorsystemen sind vielfaiti

ge Teilfunktionen zu durchlaufen. Diese konnen semantisch anhand der durchgefilhr

ten Transformationsfunktionen beschrieben werden. Zudem sind Metadaten tiber Ak

tualisierungsverfahren unverzichtbar, die beispielsweise beschreiben, ob einzelne

Datenobjekte bzw. Datenobjektklassen komplett oder inkrementell aktualisiert werden

sollen.

422

423 V gl. Devlin (1997), S. 56f. Beispiele zeigt Zell (1997), S. 299f. Entsprechende Modellierungsmethoden beschreibt z.B. Scheer (1998).


Auf der logischen Ebene sind z.B. Spezifikationen von Triggern und Prozeduren zu

erwahnen, die bei relationalen Datenbanken etwa Angaben tiber Verfahrensweisen bei

Anderungen am Datenbestand beinhalten konnen. Dies stellt - in Analogie an die

Phasenmodelle aus dem Software-Engineering - die Konkretisierung der bereits eror

terten Beschreibungen auf semantischer Ebene dar. An den Schnittstellen zu den End

benutzer- und Vorsystemen lassen sich die in der beschriebenen Weise dokumentierten

Funktionen gleichfalls weiter verfeinern. Eine Umsetzung kann hier beispielsweise

durch die Definition geeigneter Schnittstellen zu den jeweiligen Systernkomponenten

(Application Programming Interface, API) erfolgen.

Die dargelegten Metadaten-Aspekte auf der konzeptionellen Ebene finden ihren tech

nischen Niederschlag in der Ausgestaltung konkreter Algorithmen. Zudem sind auf der

internen Ebene funktionale Metadaten tiber die implementierungsabhangigen Ge

sichtspunkte zu hinterlegen. Beispielsweise mtissen hier Fragen der Partitionierung von

Datenbestanden sowie der Parallelisierung und Optimierung von Abfragen dokumen

tiert werden.

Als eng mit den funktionalen Metadaten verkntipft erweisen sich auf allen Ebenen die

ereignisorientierten Daten tiber Daten. Bei Eintritt eines bestimmten Ereignisses, z.B.

einer Benutzeraktion, oder beim Auftreten eines definierten Systemzustandes werden

Funktionen angestoBen. Ein Beispiel hierftir ist wiederum das Neuberechnen aggre

gierter Werte, wenn diese durch die Aktualisierung ihrer Komponenten ungtiltig ge

worden sind. Funktionen konnen auch zeitgesteuert ausgeftihrt werden, also beim

Erreichen eines festgelegten Zeitpunktes oder nach Ablauf einer Zeitspanne. Vielfach

genanntes Beispiel hierftir sind zeitgesteuerte Funktionen zur Ubernahme von Daten

aus den operativen Vorsystemen. Voraussetzung ist die Existenz einer Scheduling

Komponente, deren relevante Ereignisse sich wiederum ebenfalls auf den unterschied

lichen Ebenen darstellen lassen.

3.4.1.3 Versionierung der Metadaten

Insgesamt finden sich damit bis hierher drei unterschiedliche Klassifikationsrichtun

gen, die in den vorhergehenden Abschnitten vorgestellt wurden. Mit deren Hilfe lassen

sich Metadaten detailliert klassifizieren und strukturieren. Damit liegt es nahe, den

aufgestellten Strukturrahmen entsprechend der mehrdimensionalen Sichtweise auf

verftigbare Datenbestande in Data Warehouse- und OLAP-Umgebungen als Wtirfel zu

verstehen und darzustellen, wie in Abbildung 20 gezeigt.

Metadatenverwaltung analyseorientierter Informationssysteme

Externe Ebene

Semantische Ebene

Logische Ebene

Interne Ebene

Daten

Schnittstelle zu den End- Data Schnittstelle

Ereignisse

Funktionen

benutzersystemen

0~ ------~-------

~~ ;;

Warehouse- zu den Vor-Kernbereich systemen

Abbildung 20: Strukturraum fUr Metadaten in Data Warehouse-Umgebungen

131

In der mit diesem Wtirfel beschriebenen Struktur lassen sich sowohl Datenobjekte und

-strukturen als auch funktionale Gesichtspunkte und Ereignisse betrachten. Sicherlich

dtirfen die einzelnen Wtirfelzellen nicht als isolierte Teilaspekte gewertet werden, da

insbesondere aus den Verbindungen in allen Richtungen Synergieeffekte beim Aufbau

und bei der Pflege des Metadatenbestands wirksam werden ktinnen.

Data Warehouse-DatenbesHinde sollen wesentliche Geschaftszahlen tiber mittlere und

lange Zeitraume von flinf Jahren und mehr beinhalten. In diesen Zeitraumen sind am

Markt tatige Untemehmen vielfaltigem Wandel in aufbau- und ablauforganisatorischer

Hinsicht unterworfen. Anderungen ktinnen sich beispielsweise bei personellen Zustan

digkeiten, Gebietsabgrenzungen oder Geschaftsfeldzuordnungen ergeben. Auch das

Verstandnis und die Interpretation betriebswirtschaftlicher GrtiBen variiert im Zeitab

lauf. 1m Rahmen der Schnittstelle zu den Vorsystemen muB beriicksichtigt werden, daB

auch hier Anderungen auftreten ktinnen, die sich aus Veranderungen oder der Ablti

sung einzelner Vorsysteme ergeben. Auch der schlichte Wechsel der Hardware- und

Betriebssystemplattform, der sich durch die vergleichsweise kurzen Lebenszyklen


dieser Komponenten ergibt, sollte beriicksichtigt werden konnen. Nicht zuletzt werden

Data Warehouse-Projekte vielfach in einer evolutionaren Vorgehensweise durchge

fUhrt, so daB sich wachsende und sich wandelnde Metadaten-Bestande ergeben.424

Die oben dargestellte Strukturierung von Metadaten kann nur jeweils einen zeit

punktspezifischen Zustand erfassen. Anderungen, die sich im Zeitablauf ergeben,

lassen sich dagegen in dieser Form nicht dauerhaft dokumentieren. Allerdings konnen

gerade diese strukturellen Anderungen von Interesse sein, wenn Datenmaterial tiber

lange Zeitraume betrachtet werden solI. Eine Versionsverwaltung von Metadaten kann

die Losung dieser Problematik gewahrleisten. So ist eine Erklarbarkeit historischer

Daten auch langfristig zu garantieren.

Ftir die Umsetzung einer Integration temporaler Aspekte in ein solches Metadatenmo

dell sind verschiedene Realisierungsaltemativen denkbar. Ein moglicher Weg liegt

sicherlich in der Speicherung zusatzlicher Gtiltigkeitsperioden mit den einzelnen Da

tenobjekten, Funktionen und Ereigniseintragen. Sofem das Meta-Metadatenmodell

eines gegebenenfalls verwendeten Data Dictionary-Systems entsprechende Eintrage

vorsieht, kann gewahrleistet werden, daB auch altere Versionen erhalten bleiben und

fUr Auswertungen und zur Dokumentation zur VerfUgung stehen.

Versinnbildlichen laBt sich die Abbildung unterschiedlicher Giiltigkeitsperioden durch

die Einbeziehung einer weiteren Betrachtungsdimension in den dann vierdimensiona

len Metadatenwtirfel, wie er in Abbildung 21 visualisiert wird.

Jeder einzelne Zustands(teil)wtirfel reprasentiert eine Metadaten-Version, die fUr eine

gewisse Zeitspanne aktuell war bzw. ist. Durch diese Sichtweise konnen sogar unter

schied1iche Metadaten-Versionen in einzelne Endbenutzerauswertungen einflieBen,

z.B. eine Darstellung aktueller Umsatzzahlen nach alter und aktueller Auftei1ung der

Verkaufsgebiete oder eine Kostenaufstellung nach historischer und aktueller Unter

nehmensstruktur.

424 V gl. hierzu Hammer (1997), S. 30f.

Metadatenverwaltung analyseorientierter Inforrnationssysteme 133

Version Dez. 1998 Version 34. KW 1998

c OJ c

15 UJ

c OJ c OJ .n

UJ

Subsysteme e(\5\'iY-

geg

--- ,..,..,V ,..,..,

,..,..,V 0(:- _______ V V

------- -"bV --- /V ~~ V 0

/ V

Version 11.11.1998

Subsysteme ge(\5 ge _

---/' ./ - --- /' ./ ,/

/V/

0(:- V/ ------- -"bV --- -------V V

;;.~ V / VV

c OJ c 15 UJ

c OJ c OJ .n

UJ

Subsysteme e(\5\'iY-

geg

,..,.., V ,/

/

0(:- VV/ ------- -"bV --- -------

/V/ ~~ 0

/V

Aktuelle Version

Subsysteme ge(\5 ge _

--- ./ ./ - --- /' ./ ,..,..,V / vV'

0(:- _______ V /V ------- -"bV ---If V /V

V

Abbildung 21: Versionsorientiertes Metadatenverstandnis in Data Warehouse-Systemen

3.4.2 Stell en wert von Metadaten im Umfeld analyseorientierter

Informationssysteme

Analyseorientierte Informationssysteme sollen den Nutzer in die Lage versetzen, weit

gehend autonom die gespeicherten Daten fiir sich zu nutzen. Dies ist eine grundlegen

de Abkehr vom Modell des Benutzers als "parametrischer Endbenutzer"425. Damit

wird es notwendig, daB nicht nur administrative Metadaten vorliegen, die etwa Infor

mationen tiber Fragen der physischen Datenspeicherung enthalten. Dartiber hinaus

mtissen die Daten im Data Warehouse fiir den Anwender auch erklart werden. Zusatz-

425 Date (1986), S. 160, eigene Ubersetzung.


lich ist es erforderlich, auch Navigationsinstrumente fUr den Endbenutzer bereitzustel

len. 1m einzelnen lassen sich damit drei wesentliche Nutzungsfelder ftir Metadaten

beschreiben:

Erstens benotigen Data Warehouse-Entwickler und -Administratoren technisch orien

tierte Metadaten in Analogie zu den im operativen Umfeld verwendeten Angaben. Hier

sind beispielsweise zu nennen:426

• Angaben tiber die Datenquellen,

• Regeln zur Verbesserung der Qualitat der Quelldaten,

• Transformations- und Konsolidierungsregeln,

• Mapping-Regeln, die die Beziehungsstruktur zwischen den Datenquellen beschrei

ben,

• Metadaten tiber die verschiedenen Modellebenen der Data Warehouse-Datenbank.

Hier ist erkennbar, daB sich der Charakter der mit Metadaten reprasentierten Informa

tionen im Vergleich zu den operativen Systemen nur wenig verandert, allerdings hat

die Breite der abgebildeten Aspekte signifikant zugenommen. Auch die Veranderungs

haufigkeit der abgebildeten Strukturen erscheint hier hoher als in den herkommlichen

Systemen.

Zweitens sind die Endbenutzer des analyseorientierten Informationssystems mit der

Aufgabe befaBt, die enthaltenen Daten zu verstehen und zu bewerten. Sie benotigen

daher ein breites Spektrum an Metadaten, mit denen die Inhalte des Data Warehouse

interpretiert werden konnen, wie beispielsweise:427

• Definitionen der geschaftlichen Begriffe, die zur Beschreibung der Daten verwendet

werden konnen,

• Verkntipfungen zwischen diesem semantischen Fachvokabular und den Bezeich

nungen der Datenquellen, die entsprechende Werte enthalten,

• semantische, endbenutzergeeignete Beschreibungen der Quellen fUr die Daten im

Data Warehouse,

• Beschreibungen der Berichte, die erzeugt werden konnen, und anderer moglicher

Anfragen an die Datenbank,

426

427 V gl. Hufford (1997), S. 229. Vgl. Gardner (1997), S. 66: Gardner (0.1.), S. 5.


• Informationen tiber zustandige Ansprechpartner, die die inhaltliche Verantwortung

flir die dargestellten Daten tragen,

• zu erfiillende Voraussetzungen flir eine Zugriffsberechtigung auf bestimmte Da

tenobjekte.

Derartige Metadaten werden in operativen Informationssystemen in der Regel nicht in

dieser Breite gepflegt. Sie erscheinen jedoch als unmittelbar notwendig, urn die Daten

in einem Data Warehouse nutzen zu konnen.

Drittens wird flir den erwtinschten freien und autonomen Zugang zu den Daten eine

endbenutzergeeignete Navigationskomponente benotigt, die wiederum Metadaten zur

Erklarung der Wege verwendet. Hier konnen als Beispiele genannt werden:

• Funktionen, die das freie Formulieren von Datenbankanfragen ermoglichen,

• Drill-Down-Funktionen,

• Moglichkeiten zum Aufruf bereits frtiher erzeugter Berichte mit den damaligen oder

mit aktuellen Werten,

• Funktionen zur elektronischen Verteilung von Berichten,

• Funktionen, die den Rtickgriff auf die Daten in den operativen Vorsystemen ermog

lichen.

Auch ftir diese Funktionen erscheint eine breite Untersttitzung durch Metadaten erfor

derlich, die es dem Benutzer erlauben, entsprechend vorzugehen. Auch solche Meta

daten, die eine umfangreiche und freie Navigation in den Datenbestanden untersttitzen,

findet man in den operativen Systemen nicht vor - nicht zuletzt aufgrund der unter

schiedlichen Nutzungscharakteristik.

Insgesamt laBt sich also festhalten, daB die Bedeutung einer breiten Metadatenbasis,

die auch einen moglichst vollstandigen und qualitativ hochwertigen Inhalt aufweist, im

Rahmen eines analyseorientierten Informationssystems signifikant hoher ist als bei den

operativen Systemen. Erst die Metadaten erlauben es, die Inhalte des Data Warehouse

dem Endanwender in einer breiten und flexiblen Form zur Verfligung zu stellen und

sie so nutzbar zu machen.

AbschlieBend sei ein Beispiel zitiert, das verdeutlicht, wie detailliert und am Fokus des

Endbenutzers orientiert Metadaten idealtypischerweise zur Aufbereitung der Daten im

Data Warehouse dienen konnen:


"In dieser Tabelle werden die Umsiitze je Kunde der einzelnen Liinderge

sellschaften konsolidiert wiedergegeben. Eine Aktualisierung erfolgt wo

chentlich in der Nacht von Donnerstag auf Freitag. Der letzte Aktualisie

rungslauf ist fehlgeschlagen, so daJ3 die Daten alle Vorgiinge bis zum

17.09.1998 enthalten. Die GroJ3e 'Umsatz' ist um konzernweite Rabatte be

reinigt, jedoch nicht um Rabatte, die von den einzelnen Liindergesellschaf

ten gewiihrt werden, da letztere nicht in den Quelldaten enthalten sind. Die

Wiihrungsumrechnung erfolgt mit dem SchluJ3kurs des Tages, an dem der

Umsatz angefallen ist. "428

Auch wenn eine so weitgehende Nutzung der Metadaten fill eine natiirlichsprachliche

"Erkllirungskomponente" mit den derzeit zur Verfiigung stehenden Produkten wohl

nicht erreicht werden kann, wird eine Entwicklung in diese Richtung als notwendig

angesehen, urn eine moglichst weitgehende Nutzbarkeit der Daten im Data Warehouse

zu ermoglichen.429

Anslitze, wie Metadaten-Verwaltungssysteme mit ihren entsprechenden Funktionen

realisiert werden konnen, sind Gegenstand des nlichsten Abschnittes.

3.4.3 Verwaltungssysteme fur Metadaten

Fill die Speicherung und Verwaltung der Metadaten im Umfeld analyseorientierter

Informationssysteme sind verschiedene Konzepte erkennbar. So konnen Metadaten in

Analogie zum Datenkatalog eines relationalen Datenbankmanagementsystems im Data

Warehouse selbst gespeichert werden. Die Moglichkeiten solcher integrierten Kompo

nenten und die Art des Zugriffes flir den Endbenutzer unterscheiden sich zwischen den

Produkten erheblich.43o So kann teilweise das zugrundeliegende Meta-Datenmodell

verlindert und mit standardisierten Tools auf die Metadaten zugegriffen werden.

Aufgrund des bei diesen Systemen insgesamt eingeschrlinkten Funktionsumfangs er

scheint es jedoch zweckmliBiger, auf spezialisierte Metadaten-Verwaltungssysteme

zuriickzugreifen. Solche Metadatenbanksysteme sind flir den operativen Bereich unter

Bezeichnungen wie Data Dictionary oder Repository seit langem Gegenstand der For-

428

429

430

Angelehnt an WellslCarnelley (1996), S. 93. Vgl. Wells/Carnelley (1996), S. 93. Vgl. Wells/Carnelley (1996), S. 82.


schung und auch als Softwareprodukte verftigbar.431 Sie konnen auch im Data Ware

house-Umfeld der Speicherung und Verwaltung der bei der Entwicklung und dem

Betrieb eines analyseorientierten Informationssystems anfallenden Metadaten dienen

und tiber entsprechende Schnittstellen mit den tibrigen Komponenten des Gesamtsy

stems verkntipft werden.432

Prinzipiell sind hier zwei Vorgehensweisen unterscheidbar: Einerseits konnen her

kommliche, nicht originar ftir Data Warehouse-Zwecke vorgesehene Repository

Systeme verwendet werden. Auch wenn sich hier Synergieeffekte durch die Integration

mit den anderen Metadaten im Unternehmen einstellen konnen,433 kann als nachteilig

angesehen werden, daB die Strukturen solcher Repositories zu wenig an den Anforde

rungen einer analyseorientierten Metadaten-Verwaltung ausgerichtet sind. So ist z.B.

nicht unbedingt zu erwarten, daB diese Werkzeuge tiber eine Benutzungsoberflache

verftigen, die den Anforderungen des Endbenutzers gerecht wird.

Daher bietet sich als Alternative die Einftihrung eines speziellen Repositories an, das

der Metadatenverwaltung ftir das analyseorientierte Informationssystem dienen kann.

Solche Systeme stellen die entsprechenden Metadaten den tibrigen Komponenten zur

Verftigung, so daB auf der Basis dieser Metadaten Entwurf, Einftihrung, Betrieb und

Verwaltung des Gesamtsystems durchgeftihrt werden konnen.434

Als wichtiger Ansatz ftir die Zukunft erscheint in diesem Zusammenhang die Standar

disierung entsprechender Metadaten-Modelle und der Zugriffsformen auf diese Daten,

urn die Bindung der Metadaten an einzelne, diese proprietar speichernde Tools zu

IOsen und einen werkzeugtibergreifenden Austausch von Metadaten zu ermoglichen.435

Die Bemtihungen zur Standardisierung von Metadaten und entsprechender Protokolle

haben durch das Aufkommen der Data Warehouse-Diskussion neuen Schub erhal

ten.436

431 432 433 434 435 436

V gl. Abschnitt 2.4.2. V gl. White (1995). Vgl. Gardner (0.1.), S. 5. Vgl. z.B. Chaudhuri/Dayal (1997), S. 73. Vgl. Hufford (1997), S. 259. Organisationen, die sich mit der Standardisierung von Metadaten befassen, sind das Metadata Council und die EIA (Electronic Industries Association)-CDIF-Division. V gl. Metadata Coalition (1996), Ernst (1997a) sowie Ernst (1997b).


3.5 Schnittstellen zu den Vorsystemen

Die Daten, die in das Data Warehouse einflieBen, werden entweder aus den operativen

Vorsystemen oder aus externen Quellen tibernommen. Dazu sind hard- und software

technische Schnittstellen sowie Transformationsprogramme notwendig, welche die

Daten aus den verschiedenen Quellen in das Data Warehouse mit seinem eigenen Da

tenmodell umsetzen. Durch die Wirkung der Transformationsprogramme wird die

Qualitat der Daten im Data Warehouse und damit deren Nutzen fUr die Entschei

dungstrager maBgeblich mitbestimmt, so daB sie als zentrale Faktoren fUr den Erfolg

eines analyseorientierten Informationssystems geiten konnen.

Die Funktionalitat der Transformationsprogramme umfaBt die Extraktion der Daten

aus den Quellsystemen, die eigentliche Transformation, die aus den Extrakten konsi

stente und analyserelevante Daten fUr das Data Warehouse erstellen soil, sowie den

Transport und das Laden dieser Ergebnisdaten in das Data Warehouse. Da diese Werk

zeuge nicht nur zum erstmaligen Bestticken des Data Warehouse im Rahmen der Neu

einfUhrung eines solchen Systems dienen, sondern auch fUr die periodische Extraktion

geanderter operativer Daten und deren Ubernahme in den analyseorientierten Datenbe

stand benotigt werden, ist ein hoher Automatisierungsgrad anzustreben. Es ist unmit

telbar erkennbar, daB das ZusammenfUhren von Daten aus verschiedenen, heterogenen

Quellen zu einem konsistenten Gesamtbestand eine breite Palette an Transformations

funktionen erfordert. Diese werden daher im folgenden Kapitel 4 ausfUhrlich erortert.

Weitere Uberlegungen konnen der Frage der technischen AusfUhrung solcher Schnitt

stellensoftware geiten. So konnen derartige Softwarekomponenten beispielsweise tiber

ihre Systemarchitektur, ihre Betriebsarten oder den Grad der Unabhangigkeit zu den

vor- und nachgelagerten Systemen beschrieben werden.

Hinsichtlich der Systemarchitektur lassen sich auf der einen Seite SchnittstellenlOsun

gen finden, die aus einer Vielzahl kleinerer Programme mit jeweils hohem Spezialisie

rungs grad und schmaler Funktionalitat bestehen. Derartige Programme tragen vielfach

den Charakter von Einzelfall-Uisungen und dienen etwa dazu, aus Aitanwendungen,

die aus heutiger Sicht moglicherweise das Pradikat "exotisch" verdienen, Daten zu

extrahieren und in Formate umzusetzen, die dann von standardisierten Werkzeugen

weiterverarbeitet werden konnen. Ein Datenaustausch erfolgt beispielsweise tiber

einfache Textdateien, auf denen nacheinander durch verschiedene Werkzeuge die

unterschiedlichen Funktionen zur Transformation ausgefUhrt werden, bis die Daten

Schnittstellen zu den Vorsystemen 139

sehlieBlieh in das Data Warehouse geladen werden konnen. Diese - in der Praxis weit

verbreiteten - Individuallosungen tragen allerdings dazu bei, die bestehenden Altsy

sterne funktional zu erweitern und erzeugen einen hohen Wartungsbedarf bei Verlinde

rungen in den Quell- oder Zielsystemen.437 Daneben ist die Gefahr erkennbar, daB bei

einem entstehenden Wartungsstau die zeitgereehte Aktualisierung des Data Warehouse

nieht mehr gewlihrleistet ist und so der Einsatznutzen der Systeme, die daraus mit

Daten versorgt werden, geflihrdet wird.438

Auf der anderen Seite sind hoehgradig integrierte Extraktions- und TransformationslO

sungen verfiigbar, die als kompakte Produkte mit einer einheitliehen Bedienungs- und

Parametrisierungsoberflliehe sowie einer entspreehenden zentralen Metadaten- und

Verwaltungskomponente aile notwendigen Sehritte durehfiihren und tiber standardi

sierte Sehnittstellen an die vorgelagerten, operativen Systeme sowie an die naehgela

gerten analyseorientierten Systeme angesehlossen sind. Die Entwieklung solcher Pro

grammpakete ermoglieht es, aueh ohne eigene Programmierung automatisiert Data

Warehouse-Losungen mit Daten zu besttieken, und dies zu Kosten, die geringer sind

als bei den oben besehriebenen Vorgehensweisen.439 Verbunden mit einer Benut

zungsoberflliehe, die eine leiehte Bedienung ermoglieht, konnen hier zudem die erfor

derliehen Transformationssehritte unmittelbar dureh die Benutzer definiert werden, die

aueh Kenntnisse tiber die Dateninhalte besitzen, ohne daB zunliehst ein Programmierer

entspreehende Funktionen implementieren muB. Somit kann ein langwieriger, kosten

verursaehender und fehlertrliehtiger Zwisehensehritt vermieden werden.440 Als vorteil

haft erseheint dartiber hinaus, daB im Vergleieh zu Individuallosungen ein groBeres

MaB an Unabhlingigkeit von den vor- und naehgelagerten Systemen gegeben ist, so

daB sieh naeh entspreehenden Verlinderungen erforderliehe Anpassungen leiehter

durehfiihren lassen.

Als bedeutsamster Vorteil der Verwendung automatisierter, standardisierter Tools

kann jedoeh angesehen werden, daB diese tiber eine Komponente zur Verwaltung und

Nutzung von Metadaten verfiigen. In Individuallosungen sind diese zwar implizit im

Code enthalten, mtissen zu Dokumentationszweeken jedoeh separat verwaltet werden.

Verlinderungen am Programme ode induzieren hier ein manuelles Andern der Doku-

437

438

439

440

V gl. Gleason (I 997a), S. 171. V gl. Wells/Carnelley (1996), S. 71. V gl. Wells/Carnelley (1996), S. 71. Vgl. Gleason (I 997a), S. 172.


mentation und bergen die Gefahr von Divergenzen zwischen implementierten Algo

rithmen und der Dokumentation. Entsprechende Tools dagegen arbeiten metadatenge

trieben, so daB Metadaten zum integralen Bestandteil der Transformationsvorgange

werden.441

Es kann jedoch nicht verkannt werden, daB der Einsatz standardisierter Transformati

onswerkzeuge auch Risiken birgt. So ist insbesondere ein Investitionsrisiko erkennbar,

denn der Markt flir derartige Produkte ist raschen Veranderungen unterworfen, so daB

Produkte vielfach auch wieder yom Markt verschwinden.442 Hier wirkt sich nachteilig

aus, daB die unterschiedlichen Tools verschiedene Formate und Strukturen auch flir die

Metadaten verwenden. Daher ist beim Ubergang von einem Produkt auf ein anderes

eine Migration der bereits erarbeiteten Definitionen nur schwer moglich.443

Als mogliche Betriebsarten flir Transformationswerkzeuge kommen der Stapel- und

der Dialogbetrieb444 in Frage. Beide Formen weisen spezifische, als vorteilhaft er

kennbare Eigenschaften auf: Ein Dialogbetrieb ermoglicht insbesondere bei den kom

plexeren Funktionen den unmittelbaren Eingriff durch einen Benutzer, der so z.B. auf

semantische Widerspmche hingewiesen und zu deren Beseitigung aufgefordert werden

kann. Ein Stapelverarbeitungsbetrieb dagegen kann effizient lang andauernde Verar

beitungsschritte ausflihren, die keinen AniaB zu menschlicher Interaktion bieten. Als

ein weiterer Schritt zur Automatisierung der Funktionsabarbeitung kann damber hin

aus angesehen werden, wenn die Batch-Laufe nicht durch einen Bediener angestoBen

werden, sondern tiber eine Scheduling-Komponente zeitgesteuert ablaufen oder durch

sonstige Ereignisse445 (wie z.B. das Vorliegen freier Systemkapazitaten, den AbschluB

einer funktionslogisch vorangehenden Funktion oder betriebswirtschaftliche Ereignis

se, wie etwa einen RechnungsabschluB) angestoBen werden.

Die Schnittstellen zu den vor- und nachgelagerten Systemen konnen auf allgemeinen

Standards basieren oder proprietar und individuell auf einzelne Systeme bezogen sein.

Standardisierte Schnittstellen werden im allgemeinen tiber eine auch als Middleware

bezeichnete Softwareschicht realisiert, die eine "transparente" Kommunikation zwi-

441

442

443

444

445

Vgl. Hammer (1997), S. 31f. Vgl. Gausden/Mason (1997), S. 272. Vgl. Hammer (1997), S. 31f. V gl. zu den Betriebsarten z.B. Gabriel (1997), S. 63. "Significant Business Events" (Welch (1997), S. 176).

Schnittstellen zu den Vorsystemen 141

schen heterogenen Systemkomponenten ermoglichen soll.446 Diese bieten dadurch den

Vorteil groBerer Flexibilitat, indem eben auch heterogene Datenquellen durch dasselbe

Tool angesprochen werden konnen und eine Unabhangigkeit von den vor- und nach

gelagerten Systemen gegeben ist. Andererseits lassen sich durch spezifische Schnitt

stellen auch Funktionen nutzen, die tiber einen dem kleinsten gemeinsamen Nenner

entsprechenden Standardumfang hinausgehen. Standardprodukte (wie z.B. ODBC)

geraten gelegentlich auch wegen der ihnen immanenten Geschwindigkeitsnachteile in

die Kritik. Hybride Losungen mit proprietaren Anbindungen an wichtige Systeme

sowie mit standardisierten Schnittstellen fUr den Zugriff auf weniger gangige Daten

haltungssysteme erscheinen geeignet, die Vorteile beider Konzepte zu nutzen.447

Die vorstehenden AusfUhrungen zeigen, daB hinsichtlich der technischen Realisierung

der Schnittstellen zwischen den operativen und den analyseorientierten Systemen zahl

reiche Moglichkeiten gegeben sind, die in ihrer Bandbreite von monofunktionalen

COBOL-Programmen bis hin zu ausgefeilten, metadatengesteuerten Programmpaketen

mit ausgepragter Funktionalitat und Kommunikationsfahigkeit reichen. Als Trend ist

auszumachen, daB vermehrt Produkte eingesetzt werden, die als Standardsoftware auf

dem Markt erhiiltlich sind und einen GroBteil der Transformationsaufgaben automati

sieren.448

1m folgenden Kapitel werden Funktionen beschrieben, die der Transformation operati

ver Daten in den Datenbestand fUr ein Data Warehouse dienen.

446

447

448

Vgl. Riehm/Vogler (1996), S. 28. Nach dieser Definition kann aus dem Blickwinkel des Gesamtsystems auch die Transformationskomponente selbst als Middleware bezeichnet werden, ermoglicht sie doch die transparente Kommunikation zwischen dem Data Warehouse und den Datenquellen. Vgl. GausdenlMason (1997), S. 255ff. So werden Werkzeuge im Data Warehouse-Umfeld vielfach mit Schnittstellensoftware ausgestattet, die einen unmittelbaren Zugriff auf die marktbedeutenden relationalen Datenbanksysteme wie z.B. Oracle oder DBI2 (IBM) erlaubt, wahrend die Schnittstellen zu weniger verbreiteten Systemen tiber die standardisierte Schnittstelle ODBC realisiert werden. V gl. SmalllEdelstein (1997), S. 172. Vgl. Gleason (1997a), S. 171f.; Wells/Carnelley (1996), S. 8. Kirchner (1998), S. 264ff., beschreibt ausgewahlte Produkte.

Funktionale und inhaltliche Aspekte der Transformation

4 Funktionale und inhaltliche Aspekte der Transformation operativer Daten fUr analyseorientierte Informationssysteme

143

Analyseorientierte Informationssysteme versprechen nur dann einen erfolgreichen

Einsatz, wenn sie tiber Datenbestande verfiigen, die einen breiten Themenbereich

abdecken, aktuelle und rtickwartsgerichtete Betrachtungen sowie darauf basierende

Prognosen erlauben und von hoher Qualitat sind.

Die Datenbestande, die diesen Anforderungen gentigen sollen, werden im Data Ware

house bzw. in den Data Marts als den datenspeichernden Komponenten eines analyse

orientierten Informationssystems vorgehalten. Die Transformationskomponente als

Schnittstelle zwischen den operativen und den analyseorientierten Systemen ist das

Element in der Gesamtarchitektur eines analyseorientierten Informationssystems, das

die Funktionalitat bereitstellt, urn die Daten aus den operativen Vorsystemen und ex

ternen Quellen zu entnehmen, zu einem konsistenten Gesamtdatenbestand umzuformen

und diesen in das Data Warehouse einzufiigen.

Das Problem der Transformation von Daten im Rahmen der Integration heterogener

Informationssysteme ist nicht erst seit dem Aufkommen der Data Warehouse

Diskussion von Bedeutung. Die in den letzten Jahren gleichfalls umfangreich disku

tierte Migration 1llterer Anwendungssysteme zu umfassenden Losungen in moderner

Architektur zieht ahnliche Probleme nach sich. Auch die Zusammenfiihrung von In

formationssystemen nach Unternehmensfusionen oder im Rahmen von Konzernver

btinden verursacht analoge Probleme, die durch Konversions- oder Transformations

programme ge16st werden konnen.449 Die Transformation von Daten im Rahmen von

Migrationsprojekten erscheint jedoch zumindest insofern weniger problembehaftet, als

es sich hierbei urn Aufgaben handelt, die nur einmal und nicht zyklisch wiederkehrend

durchgefiihrt werden mtissen. Auch sind altere Daten im operativen Umfeld vielfach

von untergeordneter Bedeutung, wahrend sie im Data Warehouse fiir die Betrachtung

von Zeitreihen genutzt werden.

Die Transformationskomponente als Schnittstelle zwischen den operativen und den

analyseorientierten Systemen muB also tiber Funktionen verfiigen, urn einen integrier

ten, aus den Quelldaten abgeleiteten Datenbestand hoher Qualitat fiir das Data Ware-

449 Beispiele beschreiben Sharp (1993), S. 72 ff., sowie Laudon/Laudon (1994), S. 361.

144 Funktionale und inhaltliche Aspekte der Transformation

house zu erzeugen. Die notwendige Funktionalitat laBt sich in erster Naherung z.B.

tiber folgende Aufgaben definieren:

• Ubernahme der relevanten Datenbestande aus den operativen Vorsystemen,

• Beseitigung syntaktischer Heterogenitaten. So mtissen Darstellungsformen und

Formate normiert werden. Beispielsweise kann ein Wert binaren Datentyps in ver

schiedenen operativen Datenbestanden tiber "J"/"N", "Y"/"N" oder ,,0"/,,1" darge

stellt werden, der Datumswert ,,04-03-97" laBt sowohl die Interpretation ,,04. Marz

1997" als auch (nach amerikanischer Lesart) die Interpretation ,,03. April 1997"

ZU,450

• Beseitigung semantischer Heterogenitaten. Inhaltliche Widerspriiche, die sich aus

der Zusammenfiihrung verschiedener operativer Teildatenbestande ergeben, mtissen

erkannt und nach vorher definierten Regeln aufgelost werden,

• Verteilung der Quelldaten auf die anders strukturierten Modellobjekte des Zielsy

stems (Mapping),

• Aggregation, Konsolidierung und Umwandlung der Datenbestande in die fUr die

Data-Warehouse-Zwecke geeignete Form.

Zur Durchfiihrung dieser Aufgaben sind Metadaten erforderlich, die beschreiben,

welche Daten wo verfiigbar sind und welche Transformationsprozesse durchgefiihrt

werden mtissen. Die Steuerung der Transformation tiber ein Metadatenmodell er

scheint sinnvoll, urn die Datenumwandlung systematisch, strukturiert und nachvoll

ziehbar erledigen zu konnen. Daneben bietet der Ansatz der metadatengetriebenen

Transformation den Vorteil, Anpassungen an Schemaevolutionen im analytischen oder

auch operativen Modell besser durchfiihren zu k6nnen. In einem idealtypischen Kon

zept sollten aile Metadaten des Data Warehouse, und damit auch die zur Transformati

on notwendigen, in einem zentralen Data Dictionary enthalten sein.451 Die Frage der

Metadatenverwaltung ist jedoch weiterhin ein zentraler Aspekt der Data Warehouse

Diskussion.452

450

451 452

Auf das dem zweiten Beispiel gleichfalls immanente "Jahr-2000-Problem" sei nur am Rande hingewiesen. Einen breiten AufriB zu dieser derzeit vieldiskutierten Problemstellung liefert z.B. Aebi (1998). Vgl. Abschnitt 3.4. V gl. Kirchner (1996), S. 296f.

Funktionale und inhaltliche Aspekte der Transformation 145

Bei der Obernahme der Daten aus den operativen Vorsystemen werden iiblicherweise

technische Heterogenitaten zu iiberbriicken sein, wenn im Unternehmen nebeneinander

unterschiedliche, nicht unbedingt zueinander kompatible Hard- und Softwaresysteme

eingesetzt werden. Dieses Problem betrifft sowohl beispielsweise Betriebssysteme,

Netzwerkarchitekturen und -protokolle als auch Datenbanksysteme und andere Daten

speicherungskonzepte mit voneinander abweichenden Reprasentationsformen. Diese

Heterogenitaten sind bei der Integration von Datenbestanden zu iiberwinden. Hetero

gene Systemumgebungen diirften in der Praxis haufig vorkommen, insbesondere wenn

in konzernweiten Data Warehouse-Anwendungen Daten verschiedener Konzernunter

nehmen zusammengefiihrt werden sollen.453 Der Aspekt der technischen Heterogenitat

soli hier jedoch nicht weiter beachtet werden, da heute entsprechende Schnittstellen

und Protokolle verfiigbar sind, die einen Austausch von Daten zwischen den Systemen,

wenn auch haufig in einer wenig strukturierten Form, ermoglichen.454

Insgesamt liegt die Vermutung nahe, daB der Aufwand zur Herstellung eines konsi

stenten Data Warehouse-Datenbestands mit wachsender Anzahl einander iiberiappen

der Quelldatenbestande exponentiell ansteigen wird.455

In diesem Kapitel erfolgt zunachst in Abschnitt 4.1 mit der Einordnung der Problem

stellung in einen iibergeordneten theoretischen Rahmen ein kurzer Blick auf unter

schiedliche Dimensionen, nach denen sich Probleme aus der Thematik der Dateninte

gration kategorisieren lassen. 1m folgenden Abschnitt 4.2 wird beleuchtet, wann Fra

gen der Datentransformation im Rahmen eines Data Warehouse-Projekts relevant sind,

wobei zwei Anwendungsfalle unterschieden werden.

Die Architektur einer Datentransformationskomponente zwischen operativen und

analyseorientierten Systemen kann anhand eines dreistufigen Schichtenmodells darge

stellt werden, wobei sich jeder Schicht spezifische Funktionen zuweisen lassen. Eine

Beschreibung dieser Funktionen folgt in Abschnitt 4.3, wobei das genannte Schich

tenmodell als weiterer Gliederungsrahmen dient. So werden nacheinander die Extrak

tion der analyserelevanten Daten aus den operativen Systemen, die Umwandlungs

schritte, die notwendig sind, urn aus den verschiedenen Datenextrakten einen homoge-

453

454

455

Vgl. Rahm (1994). S. 181. Zell (1997), S. 296, weist auf die Notwendigkeit der Einrichtung von Datenfernlibertragungswegen hin, urn auswartige, insbesondere auslandische Datenquellen nutzen zu konnen. V gl. Anahory/Murray (1997), S. 40.


nen und konsistenten Gesamtdatenbestand zu erzeugen, sowie Funktionen zur Integra

tion der aufbereiteten Daten in das Data Warehouse beschrieben.

SchlieBlich enthlilt Abschnitt 4.4 eine Sicht auf eine spezielle Transformationsaufgabe,

die Transformation innerhalb des analyseorientierten Informationssystemkomplexes.

Diese wird aufgrund ihrer spezifischen Problemcharakteristik gesondert betrachtet.

4.1 Einordnung des Problembereichs

Die Integration von Datenbestlinden aus heterogenen, nicht durchglingig datenbankori

entierten Quellen ist nicht nur unter dem Aspekt des Aufbaus von Data Warehouse

Losungen zu einem in Wissenschaft und Praxis vielbeachteten Thema geworden. Auch

fUr die Bewliltigung des "Tagesgeschlifts" im Vnternehmen besteht durch veranderte

Anforderungen und die EinfUhrung neuer Informationssysteme die Notwendigkeit zur

Integration von Daten, aber auch von anderen Betrachtungsgegenstlinden, wie z.B. von

Funktionen und Ablliufen.456 Ein erschwerender Aspekt im Rahmen der Datenintegra

tion ist darin zu erkennen, daB viele Daten in Formen vorliegen, die nicht zu heutigen,

meist relationalen Datenbankmodellen kompatibel sind.457

Vnter "Integration von Daten" bzw. dem Attribut "integriert" im gleichen Zusammen

hang soli hier in Erweiterung der bereits vorgenommenen allgemeinen Uberlegun

gen458 das HerbeifUhren bzw. Vorhandensein eines Zustandes bezeichnet werden, in

dem eine zumindest logisch einheitliche Datenbasis vorliegt, deren Datenbestlinde in

einem gemeinsamen Modell definiert und tiber eine einzelne Schnittstelle zuglinglich

sind. Integrierte Datenbestlinde konnen in zentralisierten oder verteilten Datenbanksy

stemen vorliegen, aber auch in fOderierten Systemen, die durch gemeinsame Schemata

verbunden sind.459

456

457

458

459

Beispiele nennen Mertens (l997b), S. 208f., und ConradITUrker (1997), S. 345f. Auch auBerhalb okonomischer Anwendungsfelder ist die Problematik der Integration von Informationssystemen bedeutsam. Davidson/Kosky (1996) beschreiben beispielsweise einen Anwendungsfall aus der Biologie. Unter dem Schlagwort "Legacy System" werden oft Datenquellen zusammengefaBt, die etwa in unstrukturierten Dateien oder prarelationalen Datenbanksystemen vorliegen. V gl. Abschnitt 2.1.2. Foderierte Datenbanksysteme sind jeweils autonom und konnen zueinander heterogen sein, wiihrend verteilte Datenbanksysteme je nach Verteilungsform nur teilautonome, auf verschiedenen Rechnerknoten laufende Instanzen desselben Datenbanksystems sind, vgl. Abschnitt 2.3.3.

Einordnung des Problembereichs 147

Die verschiedenen Anwendungsbereiche von Datenintegration lassen sich in einen

Problemdefinitionsraum einordnen, der im folgenden kurz beschrieben wird.460 Durch

die Spezifikation von Auspragungen der Dimensionen dieses Raumes fiir den Anwen

dungsfall der Integration zu Data Warehouse-Zwecken Hillt sich eine erste Strukturie

rung des Problems nach vier Dimensionen vornehmen (Abbildung 22).

Nr. Dimension Wertebereich

1 Persistenz voll persistent - hybrid - nicht persistent

Auspragung der 2 Kommunikationsfunktionen aktiv - teilweise aktiv - nicht aktiv

der Quelldatenbanken

3 Aktualisierungsstrategien inkrementell - global

4 Aktualisierungszeitpunkt ereignisgesteuert - zeitgesteuert

Abbildung 22: Problemdefinitionsraum der Datenintegration461

- Persistenz

1m Rahmen der Persistenzdimension ist zu klliren, ob das Produkt des Integrationsvor

ganges, also der Zieldatenbestand, vollstandig oder teilweise gespeichert werden

sol1.462 1m Gegensatz dazu wird im Rahmen einer nicht dauerhaften Speicherung der

integrierten Daten bei einer Anfrage an den (nur logisch vorhandenen) Zieldatenbe

stand unter Anwendung der Integrationsregeln jeweils das Ergebnis aus den Quellda-

460

461

462

Vgl. Zhou et al (l995a), S. 33ff. In Anlehnung an Zhou et al. (l995a), S. 33, und Zhou et al. (l995b). Die amerikanische Literatur spricht hier von "Materialization". Eine deutsche Ubersetzung des Pradikates "materialized" durch "materialisiert" erscheint als sinnverfiilschend, da dadurch suggeriert wird, es entstUnden materielle GUter. Daten gelten jedoch allgemein als immateriell, auch wenn hier mit dem Begriff "Materialized View" ausgedrtickt werden soli, daB sie in einer auf einem Datentrager gespeicherten Form vorliegen. Daher wird hier mit "dauerhaft" oder "persistent" eine sinnwahrendere Bezeichnung gewahlt.

148 Funktionale und inha1tliche Aspekte der Transformation

tenbestanden ermittelt.463 Aus den allgemeinen Architekturtiberlegungen ergibt sich,

daB fUr Data Warehouse-Losungen tiblicherweise ein persistenter Ansatz verfolgt wird.

Kann der Benutzer des Data Warehouse im Rahmen einer Drill-Down-Funktionalitat

auf nur in den Quelldatenbanken gespeicherte Detailinformationen durchgreifen, ist

dies als Auspragung hybrider Persistenz zu klassifizieren. Nicht-persistente Losungen

waren hier die unter dem Schlagwort "virtuelles Warehouse" diskutierten Ansatze.

Die im folgenden genannten weiteren Dimensionen beziehen sich auf die Gestaltung

der Funktionen zur Aktualisie:ung der einmal erzeugten integrierten Datenbestande.

Sie sind vorrangig dann relevant, wenn diese persistent, z.B. in einem Data Ware

house, gehalten werden.

- Auspragung der Kommunikationsfunktionen der Quelldatenbanken

Die Systeme, deren Datenbestande integriert werden sollen, konnen tiber unter

schiedliche Moglichkeiten zur aktiven Kommunikation mit der Integrationsinstanz

verfUgen, urn den integrierten Datenbestand aktuell zu halten. Das theoretische Spek

trum reicht dabei von der Moglichkeit, spezielle inkrementelle Updatenachrichten

("Deltas") weiterzuleiten bis zu Systemen, die nicht in der Lage sind, Veranderungen

an den Daten weiterzugeben. Zwischen dies en Extrema sind vielfaltige mogliche Aus

pragungen von Funktionen zu finden, durch die Datenbanksysteme Ereignisse, die zu

Veranderungen des Datenbestands geftihrt haben, nach auBen kommunizieren konnen.

In den folgenden Abschnitten wird tiber verschiedene Verfahren zu diskutieren sein,

die in Abhangigkeit hiervon die Extraktion der Quelldaten erlauben.

- Aktualisierungsstrategien

Eine Aktualisierung kann erfolgen, indem die gesamten Datenbestande oder einzelne

Schemaobjekte aus den Quelldaten neu zusammengestellt werden. 1m Gegensatz zu

diesem globalen Vorgang ist von einem inkrementellen Update zu sprechen, wenn nur

die Anderungsdaten in den bereits vorhandenen Datenbestand eingefUgt werden.

- Aktualisierungszeitpunkt

Der Aktualisierungsvorgang kann in verschiedener Weise angestoBen werden. Einer

seits ist eine Ereignissteuerung denkbar, welche die entsprechenden Vorgange in Gang

463 GuptaiMumick (1998), S. 3ff., beschreiben tiber die Data Warehouse-Thematik hinausgehend Anwendungsfalle fUr persistente Views sowie Techniken zu deren Aktualisierung und dabei auftretende Probleme.

AnwendungsfiiJle einer Datentransformation fUr das Data Warehouse 149

setzt, sob aId in der Quell- oder der Zieldatenbank bestimmte, vorab definierte Ereig

nisse auftreten, wie z.B.:464

• Das Uberschreiten einer festgelegten Quote von Anderungsdaten in der Datenbank,

• das Auftreten bestimmter, als besonders relevant definierter Transaktionen,465

• Anfragen, die als veraltet markierte Datensiitze zuriickliefern.

Andererseits ist auch eine periodische Aktualisierung in festgelegten Intervallen mag

lich.

Zusammenfassend kann also festgehalten werden, daB es sich bei der Problemstellung

der Transformation von Daten flir eine Data Warehouse-Umgebung urn einen Anwen

dungsfall von Datenintegration handelt.466 Dessen Auspriigungen und Umsetzungs

maglichkeiten sind im folgenden zu konkretisieren.

4.2 Anwendungsfalle einer Datentransformation fiir das Data Warehouse

1m Lebenszyklus einer Data Warehouse-La sung tritt an verschiedenen Stellen die

Notwendigkeit auf, Daten aus Vorsystemen zu ubernehmen.467 Die "Grundfiille" wer

den hier niiher beleuchtet:468

• Initiales Fullen des Data Warehouse mit den Daten aus den operativen Systemen,

evtl. ergiinzt urn die Ubernahme von Archivdaten, urn bereits am Anfang der Pro

duktivphase des Data Warehouse graBere Datenbestiinde zur Verfugung zu haben,

• permanentes oder zyklisches Aktualisieren im Rahmen der Nutzung des Data Ware

house.

Diese Auspriigungen sind von unterschiedlicher Bedeutung, insbesondere da der erste

Fall den Charakter einer einmaligen Aktion im Rahmen der Einfuhrung des Data Wa

rehouse triigt. Daher erscheint es vertretbar, wenn beim initialen Fullen Vorgehenswei

sen gewiihlt werden, die wenig automatisiert sind und sich nicht unbedingt an einer

ausgefeilten Methodik orientieren.

464 465 466 467 468

Vgl. Zhou et al. (1995a), S. 34f. Vgl. Welch (1997), S. 176f. V gl. Schreier (1996), S. 84. V gl. Edelstein (1997), S. 42. Vgl. Inmon (1996), S. 76.


Die regelmliBige Aktualisierung des Data Warehouse-Datenbestands sollte dagegen

eher auf automatisierten, unter Beriicksichtigung des entstehenden Ressourcenverbrau

ches entwicke1ten Verfahren basieren, da aufgrund der haufigen Wiederholung dieses

Prozesses hier moglicherweise ein wesentlicher Teil der Gesamtkosten eines Data

Warehouse anflillt.

Neben dieser Pflege der Datenbestlinde wird als weiterer Problembereich gelegentlich

auch eine Aktualisierung der Metadaten erforderiich sein, und zwar weil entweder im

operativen System Veranderungen am Modell vorgenommen wurden oder wei I

(mutmaBlich haufiger) das Modell des Data Warehouse modifiziert wurde. In diesem

Fall ergibt sich die Notwendigkeit, Schematransformationsregeln, Aggregationsalgo

rithmen und weitere Elemente der Metaebene anzupassen. Dieser Problembereich soli

an dieser Stelle jedoch nicht weiter diskutiert werden.

4.2.1 Erzeugung der Data Warehouse-Datenbestiinde

1m Rahmen der Entwicklung und Einftihrung einer Data Warehouse-Losung muS

dieses mit einem initialen Datenbestand besttickt werden, mit dem dann Analysen auch

fUr den Zeitraum vor dem Einftihrungsstichtag des Data Warehouse durchgeftihrt wer

den konnen. Die entsprechenden Daten sind unter Beriicksichtigung der oben bereits

angestellten Uberiegungen zur Integration, Konsistenzsicherung und Konsolidierung

aus den operativen Systemen zu tibernehmen. Daneben konnen auch Daten aus exter

nen Quellen, wie z.B. Wechselkurs-Zeitreihen, eingeftigt werden. Art und Umfang der

in dieser Phase benotigten Daten sind naturgemliB davon abhangig, inwieweit das Data

Warehouse bereits kurz nach seiner Einftihrung Analysen tiber langere Zeithorizonte

mit Daten versorgen soil. Einerseits konnen groSe Datenbestande, die gegebenenfalls

in den Langzeitarchivsystemen der operativen Datenhaltung voriiegen, verwendet

werden, urn von vornherein einen langen Analysezeitraum zu untersttitzen,469 anderer

seits ist eine Einftihrungsstrategie denkbar, die auf einen eher kleinen Ausgangsdaten

bestand setzt, so daB im Zeitablauf mit dem Wachsen der Datenbestande auch die

betrachtbaren Zeitraume llinger werden.470

469

470

Bei dieser Vorgehensweise sollte allerdings sorgfiiltig gepriift werden, ob gerade in der Einfiihrungsphase des Data Warehouse iiltere Daten von Nutzen sind und den Ubertragungsaufwand rechtfertigen. Vgl. Inmon (1996), S. 43ff.

Anwendungsfiille einer Datentransformation ftir das Data Warehouse 151

Das initiale Bestiicken des Data Warehouse ist ein Vorgang, der (idealerweise) nur

einmal durchgefiihrt werden muB. Dieses erlaubt eine weitgehend manuelle Koordina

tion des Ladevorganges, im simpelsten Fall z.B. durch einen Export der operativen

Daten in eine sequentielle Datei und einen anschlieBenden Import dieser Datei in das

Data Warehouse.471 Durch den Charakter der Einmaligkeit treten auch die Uberlegun

gen zu einer moglichst effizienten Gestaltung der Ubernahme in den Hintergrund. So

erscheint es z.B. nicht als sehr problematisch, wenn wahrend des Ubernahmevorganges

die operativen Systeme fiir den reguHiren Betrieb nicht zur Verfiigung stehen.

Von groBer Bedeutung ist allerdings, die Qualitat des in das Data Warehouse einge

fiigten Datenbestands sicherzustellen. Insbesondere sollte anhand des Data Warehouse

Datenmodells gepriift werden, ob auch aile erforderlichen Daten tatsachlich iibernom

men und syntaktische Heterogenitaten beseitigt wurden.

4.2.2 Aktualisierung der Data Warehouse-Datenbestiinde

Wesentlich problembehafteter als das initiale Bestiicken des Data Warehouse ist die

Implementierung der Mechanismen, die die laufenden Veranderungen der operativen

Datenbestande im Data Warehouse nachfiihren und es so auf einem aktuellen Stand

halten. Dabei ergibt sich die Aktualitat unmittelbar aus der Haufigkeit der Dateniiber

nahme. Hier wird sofort ein Konflikt erkennbar: Einerseits soli das Data Warehouse

insbesondere zur Befriedigung der Nachfrage nach zeitpunktaktuellen Daten immer

moglichst zeitnah nachgefiihrt werden, andererseits verursachen die Aktualisierungs

laufe einen erheblichen Ressourcenverbrauch (Prozessorlast, erhohter Datenverkehr im

Netz etc.), verringern damit potentiell die Leistungsfahigkeit der operativen Systeme

und verursachen insbesondere Kosten. Damit muB zwischen den beiden denkbaren

Extrema "permanente, unmittelbare Aktualisierung"472 und "seltenes Uberspielen der

Datenbestande" ein technisch und wirtschaftlich sinnvoller, zielkonformer Mittelweg

gefunden werden, der iiblicherweise in der automatisierten, periodischen Ubernahme

471 472

Vgl. Inmon (1996), S. 77. Zur Online-Aktualisierung von Data Warehouse-Datenbanken vgl. Huyn (I 997b), S. 5.


der Daten zu Zeiten geringer Systemauslastung wie nachts oder am Wochenende be

steht.473

Bei der Dateniibernahme sind die operativen Datenbestande darauf zu untersuchen, ob

sie sich seit der ietzten Ubernahme verandert haben und damit fiir die Aktualisierung

relevant sind. In den folgenden Abschnitten werden einige Verfahren diskutiert, die

hierfiir genutzt werden konnen.

4.3 Gewinnung und Transformation von Daten fiir das Data Warehouse

Fiir die technische Ausgestaltung der Gewinnung der Daten aus den operativen Syste

men und deren Aufbereitung fiir das Data Warehouse sind verschiedene Konzepte

denkbar, die durch die Art der Aktivitaten zur Datengewinnung charakterisiert werden

konnen:

• Techniken, bei denen die operativen Systeme Daten unmittelbar oder iiber einen

Import-Puffer in die Data Warehouse-Datenbank "schieben" ("push-Techniken"),

• Techniken, bei denen Funktionen des Data Warehouse die Daten aus den operativen

Systemen holen und dabei entweder unmittelbar auf die originliren Daten oder auf

dafiir bereitgestellte Exportdaten zugreifen ("pull-Techniken"),

• Techniken, bei denen eine separate Komponente (Middleware) die Datengewinnung

steuert und, je nach Machtigkeit dieser Komponente, mehr oder minder komplexe

Transformationsfunktionen durchfiihrt.

In einer abstrakteren Betrachtung kann der Aufbau der Kommunikations- und Trans

formationskomponente zwischen dem operativen Datenbanksystem und dem Data

Warehouse auch anhand eines dreistufigen Schichtenmodells dargestellt werden.

Zu unterscheiden sind danach Schichten fiir:

• den Export der Daten aus den operativen Datenbanksystemen,

473 V gl. Inmon (1996), S. 281 f. Ais wichtige Restriktion ist allerdings zu beachten, daB die Dauer der Ubernahme die zur Verfiigung stehende Schwachlastzeit nicht iibersteigen darf, zumal die hier behandelten UbernahmeHiufe mit anderen typischerweise zu derartigen Zeiten durchgefiihrten Operationen wie Sicherungs-, Archivierungs- und Konsolidierungslaufen urn die Schwachlastzeit konkurrieren.

Gewinnung und Transformation von Daten flir das Data Warehouse 153

• die Durchftihrung von Schematransformationen und die Berechnung z.B. von Ag-

gregaten, d.h. die eigentliche Transformation,

• den Import der Daten in die Zielumgebung.

Diese modellmaBige Dreiteilung erlaubt die Anpassung der Verfahren an heterogene

Systemumgebungen. So kann z.B. die Exportschicht jeweils an die Systemumgebung

des verwendeten operativen Systems angepaBt werden. Die systemtechnische Umset

zung kann dagegen durchaus die Zusammenfassung der Schichten vorsehen. Insbeson

dere ist denkbar, daB die mittlere Schicht der eigentlichen Transformation bereits in

nerhalb der Data Warehouse-Umgebung stattfindet.

Zenlrale Dala Warehouse-Datenbank

Integration

Transformation i. e. S.

Operative Vorsysteme

Externe Daten

Abbildung 23: Drei-Schichten-Modell der Transformationskomponente

Abbildung 23 verdeutlicht die hier beschriebene und in den weiteren Abschnitten ver

folgte dreischichtige Architektur der Transformationskomponente, die zwischen den

internen und externen Vorsystemen und dem Data Warehouse eingeordnet ist, wobei

die Extraktionskomponente auch - zumindest teilweise - als Bestandteil des operativen

Systems realisiert sein kann.

154 Funktiona1e und inhaltliche Aspekte der Transformation

4.3.1 Aktivitliten auf Seiten des operativen Systems

Fur den Export der Daten aus den operativen Vorsystemen sind zwei grundlegende

Vorgehensweisen zu unterscheiden:

• Es k6nnen einerseits aile Datensiitze zu relevanten Betrachtungsgegenstiinden voll

stiindig aus den operativen Systemen kopiert (bulk copy) und zu einem analyse

orientierten Datenbestand weiterverarbeitet werden,

• andererseits k6nnen gezielt neue oder aktualisierte Datensatze zu den relevanten

Betrachtungsgegenstanden ("Deltas") in den operativen Systemen gesucht werden,

so daB nur diese zu einer inkrementellen Aktualisierung des Data Warehouse ver

wendet werden.

Das zuerst genannte bulk copy-Verfahren ist beim initialen Fullen des Data Warehouse

zu wahlen, urn einen grundlegenden Ausgangsdatenbestand zu erzeugen. In diesem

Projektstadium liegt ja eben noch kein zu aktualisierender Datenbestand vor, sondern

dessen Autbau ist das Ziel dieses Vorgehens.

Auch bei Aktualisierungsliiufen kann sich diese Vorgehensweise gegenuber der inkre

mentellen Ubernahme der relevanten Datenbestande als sinnvoll erweisen, wenn der

Ressourcenverbrauch fUr den Datentransport, die Schematransformationen und die

Neuberechnung von aggregierten Werten so niedrig ist, daB die Entwicklung ausge

feilter Methoden zur inkrementellen Datenubernahme sich als nicht zweckmaBig oder

wirtschaftlich herausstellt.474 Dieser Fall ist beim Vorliegen bestimmter Konstellatio

nen durchaus denkbar, etwa wenn die Umschlagshaufigkeit der operativen Datenbe

stande sehr hoch ist. Es muB allerdings sichergestellt werden, daB durch die vollstandi

ge Ubernahme der operativen Datenbestande bei der Aktualisierung des Data Ware

house die hier bereits vorhandenen Informationen erhalten bleiben, auch wenn die

zugrundeliegenden Daten aus den Vorsystemen bereits in Archive ausgelagert wurden.

Die zweite genannte Vorgehensweise, die gezielte Auswahl von Datensiitzen, bietet

sich aufgrund der genannten Einschrankungen fUr den Iaufenden Export der Daten aus

den operativen Vorsystemen zur Aktualisierung des Data Warehouse an. Das Kernpro

blem dabei besteht vor allem in der AuswahI der relevanten Daten, da Iediglich das

sogenannte Delta exportiert werden darf, also die Daten des OLTP-Systems, die seit

dem letzten Aktualisierungslauf neu entstanden sind (insert) oder sich verandert haben

474 Vgl. Huyn (1 997b), S. 3.

Gewinnung und Transformation von Daten fUr das Data Warehouse 155

(update). Auch Loschaktionen im OLTP-System miissen gegebenenfalls im Data Wa

rehouse nachgefiihrt werden.

Weitere Problembereiche bestehen insbesondere in der Notwendigkeit zur Schema

transformation und der Bildung von Aggregationen. Diese Aspekte sollten im nun

vorliegenden Stadium des Lebenszyklus des Data Warehouse durch Umwandlungs

und Rechenregeln abgedeckt sein, die sich bereits aus den Uberlegungen zur initialen

Bestiickung des Data Warehouse ergeben haben.

Es konnen flinf Techniken zur Extraktion der Anderungsdaten unterschieden wer

den:475

• Zeitstempel-gesteuerte Verfahren,

• Modifikationen der Anwendungsprogramme zur direkten Ubergabe der Extrakti

onsdaten,

• Protokollierung der relevanten Datenbank-Transaktionen,

• Auswertung der systemeigenen Log-Dateien,

• Vergleich von Schnappschiissen.

Diese Techniken werden in den folgenden Abschnitten naher diskutiert. Die Betrach

tung orientiert sich in erster Linie an transaktionsorientierten Datenbestanden, die in

relationalen Datenbanken vorgehalten werden. Die sorgfiiltige Auswahl und Imple

mentierung des jeweils problemadiiquaten Verfahrens ist sehr bedeutsam, da die Ak

tualisierungsliiufe die Qualitiit und Aktualitiit der Data Warehouse-Datenbestande

determinieren und auch unter Kostengesichtspunkten optimiert werden sollten.

Insbesondere in heterogenen Systemumgebungen ist es nicht notwendigerweise sinn

voll, die Dateniibernahme nur auf eines der dargestellten Konzepte zu stiitzen. Viel

mehr konnen sich flir die Teildatenbestiinde auch unterschiedliche Methoden als ad

iiquat erweisen.

Weiterhin werden sich bei der tatsiichlichen Implementierung durchaus auch Misch

formen ergeben, so daB sich die hier dargestellten Grundkonzeptionen nicht immer

scharf voneinander trennen lassen werden.

475 Vgl. Inmon (1996). S. 77.


4.3.1.1 Zeitstempel-gesteuerte Verfahren

Die Dimension "Zeit" spielt bei der Verwendung von Daten in einem Data Warehouse

in der Regel eine groBe Rolle, da der Zeitraumbezug der Daten als zentrale Eigenschaft

des Data Warehouse gesehen wird.476 Die Bildung und Auswertung von Zeitreihen und

von Aggregaten tiber verschiedene Perioden stellt eine Standardfunktion analyseorien

tierter Datenbanksysteme dar. Daher ist davon auszugehen, daB auch die flir das Data

Warehouse relevanten Quelldaten aus den operativen Systemen mit Attributen verse

hen sind, die die Zeitdimension beschreiben. Alternativ konnen diese Attribute 1m

operativen System aus den (relationalen) Verkntipfungen hergeleitet werden.

In diesem Fall kann der ftir eine Aktualisierung des Data Warehouse relevante Daten

bestand einfach durch eine Auswertung dieser Zeitstempel gewonnen werden, indem

genau die Datensatze verwendet werden, deren Zeitstempel anzeigt, daB sie seit dem

vorhergehenden Aktualisierungslauf angelegt wurden. So kann z.B. flir in das Data

Warehouse zu tibernehmende Auftragsdaten das Attribut "Auftragsdatum" der Auf

tragstabelle als Zeitstempel verwendet werden. Die zu dieser Tabelle in einer Master

Detail-Beziehung stehende Tabelle mit den einzelnen Auftragspositionen wird dagegen

wohl tiblicherweise kein eigenes Datumsfeld mitflihren, allerdings kann hier tiber die

relationalen Verkntipfungen zur Auftragskopftabelle der zugehorige Zeitstempel er

mittelt werden. Damit konnen dann, bei entsprechend gestalteten Exportprozeduren,

nach dem Auffinden eines flir den Export relevanten Master-Datensatzes anhand des

Zeitstempels tiber die Verkntipfungen die entsprechenden Detail-Datensatze dazuse

lektiert werden. Abbildung 24 verdeutlicht diese Vorgehensweise an einem kleinen

Beispiel.

Vor einem praktischen Einsatz bleibt jedoch zu prtifen, ob nicht das Ermitteln der

Relevanz eines Datensatzes mit der Zeitstempelmethode tiber verkntipfte Tabellen

hinweg sehr ressourcenverbrauchend sein wird, da komplexe Select- und Join

Anweisungen auf der Datenbank durchzuflihren sind.

476 Vgl. Inmon (1996), S. 36; Holthuis (1997), S. 2.

Gewinnung und Transformation von Daten ftir das Data Warehouse 157

Auftrag Position

Auftr_Nr Kd_Nr Auftr_Datum Auftr_Nr Pos_Nr Art_Nr Menge

155 4732 16 . 05 . 1997 155 1 767 2 156 4732 21 . 05.1997 156 1 737 10 , 156 2 747 3

- -insert into Export_Artikel_verkauf select Kdjlr, Artjlr, Menge

from Auf trag, Position where Auftrag .Auftr_Nr = Position.Auftr_Nr and Auftrag.Auftr_Datum > [letzter_Updatelaufl;

H

Kd_Nr Art_Nr Menge

4732 737 10 4732 747 3

Abbildung 24: Extraktion von Detail-Datensatzen tiber Zeitstempel am Master-Datensatz

Es sollte mit Hilfe des dem operativen System zugrundeliegenden Daten- und Funktio

nenmodells kontrolliert werden, ob bei dieser Methode Update-Hille richtig in das

Data Warehouse tibertragen werden. In dem oben skizzierten kleinen Beispiel wird bei

einer Veranderung eines bereits bestehenden Auftrages, etwa dem Hinzuftigen einer

weiteren Position oder der Anderung der Zahlungsbedingungen, das Attribut

"Auftragsdatum" moglicherweise - semantisch korrekt - unverandert gelassen. Ftir das

Data Warehouse ergibt sich allerdings die Folge, daB dieser Datensatz bei der Aktuali

sierung dann falschlicherweise unberticksichtigt bleibt. Allgemein ist, wie mit diesem

Beispiel verdeutlicht, bei der Auswahl von Zeitattributen des operativen Systems sorg

faltig zu prtifen, ob sich diese bei Update- oder auch Loschoperationen so verhalten,

daB diese Operationen bei der zeitstempelgesteuerten Aktualisierung des Data Ware

house korrekt ausgewertet werden.

Die ohnehin im operativen Anwendungssystem geftihrten Zeitfelder konnen, etwa

aufgrund der obigen Dberlegungen, nicht grundsatzlich zur Bestimmung des "Delta"

verwendet werden. Zudem verftigen nicht alle Teile der Datenbestande tiber Zeitfelder.

Es besteht jedoch die Moglichkeit, das operative Datenmodell im Rahmen der Einftih-

158 Funktionale und inhaltIiche Aspekte der Transformation

rung des Data Warehouse urn derartige Zeitstempelfelder fUr die Aktualisierung der

Warehouse-Datenbestande zu erweitem. Dabei wird allerdings mit Widerstanden sei

tens der fUr das OLTP-System Verantwortlichen zu rechnen sein, da tiefgreifende

Anderungen am Daten- und Funktionenmodell ein groBeres, fehler- und kostentrachti

ges Projekt darstellen. Die Risiken, die mit einem solchen Projekt verbunden sind,

mtissen dann den aus der Sicht eines die operativen Systeme administrierenden Re

chenzentrums moglicherweise geringen Prioritaten der EinfUhrung einer Data Ware

house-Losung gegentibergestellt werden.

4.3.1.2 Dateniibergabe durch Anwendungsprogramme

Ein weiterer denkbarer Weg besteht in der Modifikation der auf die operative Datenba

sis zugreifenden Programme in der Weise, daB die fUr das Data Warehouse relevanten

Daten auf Anwendungsebene protokolliert und an die Zielumgebung weitergereicht

werden. Daneben kommt auch ein unmittelbares Update der Data Warehouse

Datenbank in Frage, womit allerdings yom normalerweise verfolgten Konzept der

zyklischen Updates und Neuberechnungen in analyseorientierten Datenbanksystemen

abgewichen wird. Abbildung 25 zeigt schematisiert beide Varianten: Zusatzlich zu

dem herkommlichen Zugriff auf die operative Datenbank durch das Anwendungspro

gramm wird eine Protokolldatei erzeugt oder auch direkt auf die Data Warehouse

Datenbank zugegriffen.

Diese Vorgehensweise bietet den Vorteil einer moglicherweise groBeren Flexibilitat

bei der Ubergabe der Daten an das Data Warehouse, da bei der Datenextraktion nicht

auf die mit einem nur engen Funktionsumfang versehenen Schnittstellen des Daten

banksystems aufgesetzt werden muB. Auf diese Weise konnen Datenextrakte erzeugt

werden, die schon sehr gut an die Erfordemisse des Data Warehouse angepaBt sind und

den weiteren Transformationsaufwand minimieren.

Erhebliche Nachteile relativieren jedoch diesen Vorteil. Der Aufwand zur Anpassung

der Anwendungsprogramme wird sehr groB sein, da jedes Programm-Modul, das

schreibend auf Data Warehouse-relevante Daten zugreift, modifiziert werden muB.

Dieses Argument trifft insbesondere fUr Systemumgebungen zu, in denen heterogene

und alte Anwendungsprogramme laufen. Diese sind zudem haufig ohnehin nicht sehr

stabil und schlecht wartbar, so daB das EinfUgen neuer und durchaus komplexer Funk

tionen zur Untersttitzung eines Data Warehouse sehr problematisch erscheint. Unbe

dingt notwendig ist daneben auch, daB tiberhaupt die Moglichkeit besteht, die Anwen-


dungen zu verandern oder zumindest Programmerweiterungen zu erstellen. Auch diese

Voraussetzung wird nicht immer erftillt sein.

Operative Datenbank

Kd_Nr AreNr Menge 4732 737 10

Export-Datei

Abbildung 25: Dateniibergabe durch das Anwendungsprogramm

Data Warehouse

Ein weiterer sehr wesentlicher Problembereich bei der Modifikation der Anwendungs

programme zur Extraktion der flir das Data Warehouse relevanten Daten liegt in der

Sicherstellung der Konsistenz dieser Daten. Dem Vorgehen immanent ist, daB die

Extraktion dezentral erfolgt. Konsistenzprobleme entstehen dann, wenn in der

(typischerweise vorhandenen) Vielfalt der Anwendungsprograrnme nicht durchgangig

Extraktionsmodule gleicher Funktionalitat geschaffen werden. Diese mtissen nicht nur

vollstandig sein, d.h. an allen Stellen mit Schreibzugriff auf flir die Extraktion rele

vante Daten vorhanden sein, sondern auch zur Sicherstellung einer auf einheitlichen

Grundsatzen basierenden Datenbasis mit analogen Algorithmen implementiert sein.

Diese Uberlegung sei an drei kurzen Beispielen illustriert:

160 Funktionale und inhalt1iche Aspekte der Transformation

• Das Abgreifen der Daten muB immer zum funktionslogisch gleichen Zeitpunkt

erfolgen, und zwar moglichst im Gleichlauf mit der Ubertragung an die operative

Datenbank,

• in den Extraktionsmodulen implementierte Aggregationsverfahren mtissen zueinan

der konsistent sein,

• es sind konsistente Fehlerbehandlungsstrategien notwendig, die z.B. dann aktiviert

werden mtissen, wenn Datenbanktransaktionen mit bereits fUr den Export selektier

ten Daten scheitern. MuB eine begonnene Transaktion zuruckgesetzt werden (undo),

ist auch der Exportvorgang ruckgangig zu machen.

Als Fazit bleibt festzuhalten, daB die direkte Extraktion der Daten aus den Anwen

dungsprogrammen weniger geeignet erscheint und aus den dargestellten Grunden die

Wartbarkeit der "Datenpumpe" deutlich erschwert sein dtirfte. Dennoch handelt es sich

urn eine Alternative, die sicherlich fUr Ausnahmefalle ihre Daseinsberechtigung hat,

etwa wenn eine weitere Datenquelle einbezogen werden soli und andere Methoden nur

mit groBerem Programmieraufwand realisierbar sind. Auch wenn eine moderne, inte

grierte betriebswirtschaftliche Standardsoftware vorhanden ist, die auf einer speziell

angepaBten Datenbank basiert, wird sich dieses Vorgehen moglicherweise als sinnvoll

erweisen. Vereinfachend wirken sich dann die Schnittstellen des Anwendungspro

grammes aus, die sich tiber eine prozedurale oder deskriptive Programmiersprache

anpassen lassen, insbesondere wenn diese auf objektorientierten Konzepten basiert, die

es erlauben, zentralisiert gehaltene Methoden zu entwickeln oder zu verandern.477

4.3.1.3 ProtokolIierung relevanter Datenbank-Transaktionen

Transaktionsorientierte Datenbanksysteme, die auf dem relationalen Modell basieren,

enthalten sehr groBe, tiber viele Tabellen verteilte Datenbestande. Relevant fUr das

Data Warehouse sind aber tiblicherweise nur verhaltnismaBig kleine Ausschnitte des

Datenmodells und mithin nur Daten aus bestimmten, eher wenigen Tabellen.478 Daher

liegt es nahe, durch gezielte Anderungen am Daten- und Funktionenmodell Tabellen

oder Dateien zu definieren, die fUr aile Insert- oder Update-Zugriffe auf den relevanten

477

478

Allerdings werden sich sicherlich gerade fUr moderne Systemumgebungen zweckmaBigere Wege zur Extraktion der Data Warehouse-relevanten Daten finden lassen. Trotzdem kann das Datenvolumen sehr groB sein, da es sich typischerweise urn Tabellen mit einer groBen Anzahl von Datensatzen handeln wird, wie z.B. urn eine Tabelle mit Auftragsdaten.

Gewinnung und Transformation von Daten fur das Data Warehouse 161

Tabellen einen Protokolldatensatz aufnehmen. Dieser kann, abhangig von den im Ein

zelfall auftretenden Implikationen auf Performance und Ressourcenverbrauch, entwe

der aus einem reinen Verweis auf die entsprechenden Satze der Originaltabelle beste

hen oder aber redundant zur Originaltabelle aile spater fUr das Data Warehouse rele

vanten Werte enthalten. 1m Rahmen der zyklischen Aktualisierungslaufe fUr das Data

Warehouse sind diese Logdateien auszuwerten. Diese bieten dann die Moglichkeit, auf

die relevanten Datensatze der Quelltabellen zuzugreifen, ohne daB der gesamte Daten

bestand durchsucht werden muB. Sofern der Aktualisierungslauf erfolgreich beendet

werden konnte, kann dann das Protokoll zurtickgesetzt oder archiviert werden.

Vorteilhaft an diesem Ansatz erscheint insbesondere, daB die Protokollierung zentral

bei den betroffenen Daten erfolgt, die durch ein (in der Theorie) konsistentes Daten

mode II definiert sind. Durch diese Unabhangigkeit von den Anwendungsprogrammen

werden die Gefiihrdungen der Datenintegritat, die bei der oben erorterten Protokollie

rung auf der Anwendungsebene auftreten, eliminiert. Es muB fUr jeden Entitatstyp des

Datenmodells, dessen Auspragungen Eingang in das Data Warehouse finden sollen,

nur ein Log definiert werden. So ist sichergestellt, daB die in das Data Warehouse zu

tibertragenden Daten einheitlich sind, auch wenn sie von verschiedenen Anwendungs

programmen oder Modulen verandert wurden. Weiterere Vorteile dtirften in der einfa

cheren und kostengtinstigeren Implementierung und der besseren Wartbarkeit liegen.

Als Nachteil ist dagegen ein gewisser zusatzlicher Ressourcenverbrauch des Transak

tionssystems zu sehen, wenn bei Insert- oder Updateoperationen zusatzlich weitere

Datensatze in anderen Tabellen erzeugt werden mtissen. Inwieweit hierdurch merkli

che Performanceverluste bei der DurchfUhrung von Transaktionen auftreten, dtirfte

sehr stark von der konkreten Systemarchitektur abhangig sein, so daB eine pauschale

Bewertung dieses Aspektes nicht zweckmaBig erscheint.

Sofern das transaktionsorientierte Datenbanksystem tiber die herkommlichen

(passiven) Funktionen der Datenspeicherung und TransaktionsdurchfUhrung hinaus

auch ohne unmittelbaren AnstoB durch ein Anwendungsprogramm Funktionen ausfUh

ren kann, spricht man von aktiven Datenbanken.479 Die erforderliche Verarbeitungslo-

479 Nahere Erlauterungen zu aktiven Datenbanken finden sich z.B. in ElmasriINavathe (1994), S. 778ff.

162 Funktionale und inhaltIiche Aspekte der Transformation

gik ist in den aktue11en Versionen der bekannten relationalen Datenbankrnanagement

systeme implementiert.48o

Die Realisierung der hier diskutierten protokollierenden Tabe11en kann so mit Hilfe der

aktiven Funktionalitat tiber sogenannte Datenbanktrigger erfolgen. Dabei handelt es

sich urn kleine Programme in einer aus SQL-Anweisungen und prozeduralen Elemen

ten481 bestehenden Sprache. Diese werden dann zu einem definierten Zeitpunkt in der

Reihenfolge der Transaktionsverarbeitung abgearbeitet, wenn in der Datenbank be

stimmte Ereignisse (events) auftreten. Ais Ereignis kommt z.B. das Anlegen oder Ver

andem eines Datensatzes in einer bestimmten Tabe11e in Frage. Dabei gilt das Erste11en

von Audits oder Protoko11en als ein verbreitetes Anwendungsbeispiel flir Daten

banktrigger.482 So liiBt sich mit Hilfe eines einfachen Triggers festlegen, daB nach dem

Anlegen eines Datensatzes aus einigen Werten (Primarschltissel des Datensatzes, Da

tum, Uhrzeit) ein Datensatz in der Protoko11datei erzeugt werden sol1. Ein schemati

siertes Beispiel ist in Abbildung 26 dargeste11t.

Die Entwicklung der Spezifikation flir solche Protoko11dateien zur Untersttitzung des

Data Warehouse kann dann in den folgenden Schritten vo11zogen werden:

• Bestimmung der Tabe11en im OL TP-System, aus denen Inkremente in das Data

Warehouse tibemommen werden sol1en,

• Festlegung der im Protoko11 zu flihrenden Spalten und des Grades der dadurch auf

tretenden Redundanz zu den originaren Daten,

• Spezifikation des Triggers unter Beriicksichtigung des genauen Ausflihrungszeit

punktes, des Algorithmus und von Fehlerbehandlungsroutinen, die verhindem sol1-

ten, daB im Faile eines Problems mit dem Log die Durchflihrung der eigentlichen

Transaktion scheitert,

• Spezifikation der Routinen, die mit Hilfe der Protoko11e und evtl. der Ursprungsta

be11en die zu exportierenden Daten bereitste11en,

• Bestimmung von Verfahren zur Archivierung oder Loschung der Protoko11e nach

der erfolgreichen Aktualisierung des Data Warehouse.

480 481 482

Vgl. Fischer (1996), S. 436. Sofern der Sprachumfang des Datenbanksystems dies unterstiitzt. V gl. Froese et al. (1996), S. 231.

Gewinnung und Transformation von Daten ftir das Data Warehouse 163

Bei diesen Schritten handelt es sich urn die Entwicklung von Metadaten, die entspre

chend auch Eingang in das semantische Daten- und Funktionenmodell finden sollten.

Protokollierte Transaktionen

Export Artikel_ Verkauf -Kd_Nr Art_Nr Menge

4732 737 10 4732 747 3

Operative

t-- Datenbank ---Auftrag

Auftr_Nr Kd_Nr Auftr _Datum LieC Bed

----..... 155 4732 16.05.1997 1

.,.... 156 4732 ~1. 05 .1997 1

Position

Auftr_Nr Pos_Nr Art_Nr Menge

155 1 767 2 156 1 737 10 156 2 747 3

~

• after insert on Position for each row declare Fk_Kd_Nr number; begin

• select Kd_Nr into Fk_Kd_Nr from Auf trag where :new.Auftr_Nr=Auftrag Auftr_Nr;

insert into Export-firtikel_Verkauf values

(Fk_Kd_Nr. :new.Art_Nr. :new ,Menge) ; end;

Abbildung 26: Protokollierung von Transaktionen mit Hilfe von Datenbanktriggem483

Zusammenfassend erscheint die Implementierung eigenstiindiger Protokolle fUr die

Bereitstellung der Anderungsdaten fUr das Data Warehouse als eine geeignete Metho

de, die, sofern die Datenbestande in modernen, re1ationalen Datenbanken voriiegen,

mit vergleichsweise geringem Aufwand realisiert werden kann und die kompatibel ist

zu den Integritatserfordernissen der operativen Systeme.

483 Die dargestellte Syntax des Triggers entspricht Oracle PUSQL 2.3 fiir Oracle-Datenbankserver Version 7.3.


4.3.1.4 Auswertung der Logdateien

Zur Wahrung der Datensicherheit flihren Datenbankverwaltungssysteme tiblicherweise

Logdateien (Journale), die alle Transaktionen protokollieren.484 1m Falle von System

abstiirzen oder Hardwaredefekten laBt sich damit der Zustand der Datenbank auf den

letzten konsistenten Zustand zurticksetzen (undo) oder alle Anderungen, die sich seit

der letzten Datensicherung ergeben haben, nachvollziehen (redo). Sogenannte Audit

Trails beinhalten dagegen Protokolle, die bestimmte, yom Systemadministrator festge

legte Ereignisse auf Benutzer- oder Datenbankobjektebene protokollieren, urn System

fehler oder Sicherheitslticken aufzusptiren.485 Damit lieBe sich das Problem der Ex

traktion der zur Aktualisierung des Data Warehouse relevanten Daten gut lOsen, da ja

ohnehin in diesen Dateien die Schreibaktionen auf der transaktionsorientierten Daten

bank mitprotokolliert werden.

Die daher auf den ersten Blick naheliegende Idee, diese Dateien zur Aktualisierung des

Data Warehouse-Datenbestands zu nutzen, verliert bei naherem Hinsehen deutlich an

Attraktivitat. Gerade Logdateien werden tiblicherweise in einem Datenformat aufge

baut sein, das flir die Verwendung mit den Recovery-Tools des entsprechenden Daten

banksystems gedacht ist. Dieses Format eignet sich aber nicht unbedingt zum Auswer

ten durch andere Programme, da es zu problemspezifisch angelegt ist und auBerdem

eine Vielzahl von Daten enthalt, die flir den hier verfolgten Zweck nicht relevant

sind.486 Durch den proprietaren Charakter der Logdateien entsteht dartiber hinaus eine

starke Abhangigkeit zwischen der Exportkomponente und dem Quellsystem, so daB bei

einem Wechsel der Datenbank oder auch nur der Version damit zu rechnen ist, daB

eine Neudefinition der Schnittstelle erforderlich wird. Weiterhin ist zu beachten, daB

die Logdateien insbesondere aus Grunden der Datensicherheit angelegt werden und es

problematisch erscheint, wenn sie regelmaBig auch durch andere Programme gelesen

(und moglicherweise beschadigt) werden.

ZweckmaBiger ersch@int die Verwendung der Auditing-Funktion, sofern diese es beim

verwendeten Datenbankverwaltungssystem erlaubt, entsprechend genaue Protokolle zu

definieren. Die Audits werden (zumindest beim relationalen Datenbankmanagementsy

stem Oracle 7.x) in relationalen Strukturen angelegt und konnen tiber spezielle Daten-

484

485

486

Vgl. Elmasri/Navathe (1994), S. 535f. Vgl. ElmasrilNavathe (1994), S. 598. Vgl. Inmon (1996), S. 77.


bankviews mit Hilfe der tiblichen Methoden abgefragt werden.487 Damit kommt man

tiber das Zweckentfremden der Audit-Funktion zu einer ahnlichen Vorgehensweise

wie bei den oben dargestellten dedizierten Protokollen. Ob die Vorteile der Nutzung

solcher vorgefertigter Audits die Nachteile aufwiegen, die im Vergleich mit speziell

fUr den vorliegenden Zweck programmierten Protokollen erkennbar werden, wird yom

Einzelfall abhangig sein. Insbesondere ist man auf die vordefinierten Auditing

Funktionen beschrankt und hat nicht die Moglichkeit, genaue Definitionen tiber die zu

protokollierenden Daten vorzunehmen.

4.3.1.5 Schnappschu8-Vergleichsverfahren

In der Terminologie relationaler Datenbanksysteme versteht man unter einem

SchnappschuB (snapshot) eine zu einem definierten Zeitpunkt angelegte, nur fUr Le

seoperationen zugelassene Kopie von Datenbanktabellen. Der tibliche Anwendungsfall

liegt im lokalen Vorhalten eines Tabellenreplikates innerhalb einer verteilten Daten

bank, urn fUr Leseoperationen die Antwortzeiten bei Anfragen nach eigentlich auf

einem entfernten Netzknoten liegenden Daten zu verringern. Schnappschtisse werden

in regelmaBigen AbsUinden neu aufgebaut, urn sie aktuell zu halten. Relationale Da

tenbanksysteme enthalten entsprechende Mechanismen, urn derartige Spiegelbilder des

Datenbestands automatisiert zu erzeugen und zu verwalten.488

Der Vergleich von zwei nacheinander erstellten Snapshots kann die in der Zwischen

zeit durchgefUhrten Transaktionen (und damit die Bewegungsdaten fUr das Data Ware

house) zutage fOrdern. 489 Dieses Verfahren ist jedoch mit erheblichen Nachteilen be

haftet, so daB es in jedem Fall zweckrnaBig erscheint, eine effizientere Losung zu

suchen.490 Es ist mit einem Durchsuchen des gesamten Datenbestands verbunden und

damit auBerst ressourcenverbrauchend. Zudem mtissen eigens zu diesem Zweck immer

mindestens zwei Kopien der Daten auf Speichermedien mit hoher Zugriffsgeschwin

digkeit vorgehalten werden. Dies ist gleichfalls unter Umstanden ein nicht zu ver

nachlassigender Ressourcenverbrauchs- und damit Kostenfaktor.

Auch aus technischen Grunden erscheint die Verwendung dieses Verfahrens proble

matisch. Sind die zu duplizierenden Tabellen durch referentielle Integritatsregeln mit-

487

488

489

490

Vgl. Oracle Corporation (1993), Kapite1 14. V gl. Oracle Corporation (1993), S. 16-lff. V gl. Welch (1997), S. 175. Vgl.1nmon (1996), S. 78f.


einander verkniipft, wie es in der Regel der Fall sein diirfte, miissen wlihrend der Er

stellung der Schnappschiisse zur Wahrung der Integritlit aIle betroffenen Tabellen mit

einer Schreibsperre versehen werden, was einer weitgehenden Stillegung des Systems

flir das "Tagesgeschlift" gleichkommen diirfte.

Bei einer Sichtweise, die nicht allein auf die Betrachtung relationaler Datenbanksyste

me fokussiert, kann unter einem SchnappschuB allgemein eine Kopie des Datenbe

stands (dump file) eines Anwendungssystems verstanden werden, wobei die Schnapp

schiisse analog zu den obigen Uberlegungen genutzt werden konnen. V orteilhaft ist,

daB entsprechende Funktionen in vielen Systemen bereitgestellt werden, da diese

Technik auch zur Datensicherung eingesetzt wird.

Trotz der oben bereits angeflihrten Nachteile besitzt das SchnappschuB

Vergleichsverfahren daher eine gewisse praktische Relevanz, da somit auch Daten

quellen ausgewertet werden konnen, die keine Schnittstellen zur Implementierung

altemativer Methoden aufweisen.491 Das snapshot differential problem, das im effizi

enten Auffinden von Einflige-, Update- und Loschereignissen anhand des Vergleiches

zweier Schnappschiisse besteht, ist daher auch Gegenstand aktueller Forschung.492

4.3.1.6 Unterstiitzung durch Werkzeuge

Die in den vorhergehenden Abschnitten genannten flinf Verfahren sind in verschiede

nen Ausprligungen und Varianten auch Bestandteil der am Markt verfiigbaren kom

merziellen Tools zur Fiillung eines Data Warehouse, die meist als Komponenten einer

Data Warehouse-Komplettlosung angeboten werden. Dabei werden oft verschiedene

Konzepte unterstiitzt, so daB unterschiedliche, heterogene Datenquellen auch in ver

schiedenen Varianten angesprochen werden konnen. Es werden nach der am Anfang

von Kapitel 4.3 vorgenommenen Klassifikation als Middleware zu bezeichnende Tools

vermarktet, die als eigenstlindige Programme auf die Quelldatenbanken zugreifen,

nach einem der vorgestellten Verfahren die Daten extrahieren und in die Zielumge

bung transportieren. Diese Werkzeuge dienen nicht nur der Datenversorgung von Data

Warehouse-Losungen, sondem konnen auch z.B. flir Migrationen auf andere operative

Umgebungen genutzt werden. Erlaubt das verwendete Tool die Definition von Regeln

flir die selektive Ubemahme von Daten (z.B. ETI Extract Toolsuite, Evolutionary

491

492 Vgl. Zhuge/Garcia-MolinalWiener (1998), S. 9. Vgl. Hammer et al. (1995), S.44f. Auf einen (schwierigen) Spezialfall bezogene Ergebnisse finden sich in Chawathe/Garcia-Molina (1997).


Technologies International, Austin), wird offensichtlich der oben als zeitstempel

gesteuertes Verfahren beschriebene Weg gegangen, indem fUr das Update des Data

Warehouse als Regel definiert wird, die seit dem letzten Extraktionslauf geschriebenen

oder geanderten Datensatze zu verwenden. Andere Produkte (z.B. die Changed Data

Capture Modules, Prism Solutions, Sunnyvale) konnen die Logdateien gangiger Da

tenbanksysteme auswerten.493

Ein weiteres Konzept besteht in der Bereitstellung offener Schnittstellen (z.B. Source

point, Software AG, Darmstadt), die es ermoglichen, zusammen mit Produkten dessel

ben Herstellers oder tiber Standardprogrammiersprachen Extraktionsprogramme zu

erstellen. Dabei konnen auch diese wiederum auf den dargestellten Konzepten bas ie

ren. Die Extraktionsprogramme werden durch das Transformationsprogramm gesteuert

und liefern tiber die Schnittstellen die Daten zur weiteren Bearbeitung an dieses.

Diese Konzepte haben gemeinsam, daB die Transformationskomponente als Middlewa

re die Extraktionsvorgange steuert und den AnstoB zur Ubergabe der Daten liefert.

Somit ist ein "pull-Verfahren" erkennbar, bei dem die Middleware die Daten innerhalb

der Informationspyramide nach oben zieht. Die exakte Ausgestaltung der Extraktions

komponente ist jedoch bei den verschiedenen Produkten unterschiedlich realisiert:

Neben Tools, die Daten- und Steuerungsschnittstellen zu separaten Extraktionspro

grammen bereitstellen, treten Werkzeuge, die mit den entsprechenden Funktionen zur

Auswahl der relevanten Datensatze ausgestattet sind.

4.3.2 Transformation im engeren Sinne

Nach der Extraktion der relevanten Daten aus - moglicherweise verschiedenen - ope

rativen Datenquellen mtissen diese Daten den Erfordernissen des Data Warehouse

angepaBt werden. Dieser Schritt wird - homonym zur Benennung des gesamten Pro

bletnkomplexes - in der Literatur vielfach als Transformation bezeichnet.494 Daten

strukturen, Ziele der Datenspeicherung und Verdichtungsgrad der Daten in den trans-

493

494

Zu den hier und im folgenden genannten Produkten vgl. die Informationen der genannten Hersteller im WWW, z.B. unter http://www.evtech.com (ETI) , http://www.prismsolutions.com (Prism Solutions), http://www.sag.de (Software AG). So definiert Devlin (1997) Transformation als "A component of data replication that converts data between different logical or physical structures according to predefined rules" (S. 205). Ahnliche Auslegungen verfolgen z.B. Inmon (1996); Glassey-Edholm (1997), S. 107; Brackett (1996).


aktionsorientierten und den analyseorientierten Datenbestanden unterscheiden sich

wesentlich, so daB allein aus diesem Grunde zahlreiche Autbereitungsschritte des

Datenmaterials erforderlich sind. Allenfalls in kleineren Data Warehouse-Projekten

sind, abhangig von der Art der Quelldaten, moglicherweise nur wenige Anderungen

erforderlich, etwa wenn lediglich einigen wenigen Nutzern eine Kopie der Daten eines

operativen Systems zur Verfiigung gestellt werden sol1.495 Aus dem Charakter der

Autbereitungsschritte ergibt sich, daB die notwendige Programmlogik fiir das Autbe

reiten jedoch deutlich an Komplexitat zunimmt, wenn mehrere Datenquellen verarbei

tet und zusammengefiihrt werden miissen. Heterogene Modelle, die den Quelldaten

zugrunde liegen, fiihren zu einer weiteren Erhohung des Schwierigkeitsgrades.496 Der

erforderliche Arbeitsaufwand steigt dann wesentlich an.497 Hier soli vom Fall mehrerer

sich iiberlappender heterogener Datenquellen ausgegangen werden. Sofern nur Daten

aus einer Quelle fiir das Data Warehouse autbereitet werden sollen, entscharft sich die

Problematik deutlich. Dieses Szenario kann allerdings als Grenzfall von eher theoreti

schem Wert betrachtet werden, da das Data Warehouse-Konzept ja generell auch die

Integration externer Datenquellen vorsieht, so daB zumindest diese mitberiicksichtigt

werden miissen.

Methodische Basis fiir die Autbereitungsfunktionen ist erneut das Metadatenmodell

des Data Warehouse, das Informationen iiber die Datenquellen und die jeweils erfor

derlichen Transformationsschritte enthalten und fiir die Umwandlungsprogramme

zuganglich machen muB.

1m folgenden werden die einzelnen Transformationsschritte zunachst gruppiert und

einzeln diskutiert. Eine Reihenfolge der Bearbeitungsschritte soll aus der folgenden

Darstellung nicht abgeleitet werden; es handelt sich urn Prozesse von sehr interdepen

dentem Charakter. An spaterer Stelle wird zu priifen sein, wie sich diese Transformati

onsschritte synchronisieren lassen.

Es lassen sich trennen:

• Schritte zur Vereinheitlichung der Syntax (Abschnitt 4.3.2.2),

• Schritte zur Datenautbereitung, d.h. zur Beseitigung von Fehlern und nicht relevan

ten Datenobjekten sowie zur Behandlung fehlender Werte (Abschnitt 4.3.2.3),

495 496 497

V gl. Devlin (1997). S. 205f. V gl. Davidson/Buneman/Kosky (1998), S. 55f. V gl. Anahory/Murray (1997), S. 40.

Gewinnung und Transformation von Daten fiir das Data Warehouse 169

• Schritte zur Konvertierung des Datenbestands in das Datenmodell des Data Ware

house (Abschnitt 4.3.2.4),

• Schritte zur Schaffung eines konsistenten, tiber die verschiedenen Quellen inte

grierten Datenbestands (Abschnitt 4.3.2.5).

Diese Teilaspekte der Transformation werden nun naher beleuchtet. Insgesamt kann

dabei von Qualitatsverbesserung und -sicherung der Datenbestande gesprochen wer

den.498 Bedeutsam ist in diesem Zusammenhang, daB nicht nur die tatsachliche, son

dern auch die wahrgenommene Datenqualitat durch diese MaBnahmen verbessert wird.

Dabei bemiBt sich die wahrgenommene oder subjektive Datenqualitat aus der Meinung

der Entscheider tiber den Nutzen der im Data Warehouse bereitgestellten Daten. Dieser

Aspekt determiniert damit letztlich die Akzeptanz des analyseorientierten Informati

onssystems. Die tatsachliche oder objektive Datenqualitat bezieht sich dagegen auf die

Ubereinstimmung mit den Sachverhalten der realen Welt. Dabei muB das Ziel der

Transformation darin liegen, die tatsachliche Datenqualitat zu verbessern und dies den

Nutzern der Daten zur Erh6hung der wahrgenommenen Qualitat auch zu verdeutli

chen, damit die Daten als Basis zur Versorgung mit richtigen, entscheidungsrelevanten

und akzeptierten Informationen genutzt werden.

Zur Beschreibung der notwendigen Schritte werden zunachst in einer technischen Sicht

tiberblicksartig die zugrundeliegenden Basisfunktionen diskutiert, bevor in den folgen

den Abschnitten auf die mit Hilfe dieser Basisfunktionen durchzufiihrenden Transfor

mationsschritte eingegangen wird.

4.3.2.1 Basisfunktionen zur Durchfiihrung der Transformationsschritte

Es soli in Anlehnung an Devlin499 zwischen den folgenden Basisfunktionen unter

schieden werden:

• Auswahl (selection),

• Separieren und Zusammenfiihren (separation/concatenation),

• Normalisieren und Denormalisieren (normalization/denormalization),

• Aggregieren (aggregation),

498

499 Zum Aspekt der QualiUit von Daten vgl. Abschnitt 1.3.4. V gl. zu den in diesem Abschnitt erHiuterten Funktionen Devlin (1997), S. 206ff. und S. 256ff.


• Umwandeln (conversion),

• Erganzen (enrichment).

Die Mehrzahl dieser Funktionen liefert als Ergebnis Datensatze zurtick, lediglich bei

den beiden zuletzt genannten werden einzelne Datenfelder bearbeitet. Alle Funktionen

werden nun naher erlautert. Die spater diskutierten notwendigen Transformationen

lassen sich im wesentlichen auf Kombinationen aus dies en Grundfunktionen zuriick

fUhren.

- Auswahl

Diese eher einfache Funktion erzeugt anhand von Kriterien eine Teilmenge aus dem

Quelldatenbestand. Die Auswahl kann sich dabei auf Datensatze beziehen (horizon tale

Auswahl), auf Felder innerhalb der Datensatze (vertikale Auswahl) oder auch auf

ganze Datenobjekte (z.B. durch Weglassen einer relationalen Tabelle).500 Auswahl

findet bereits bei der Definition der aus den operativen Datenbestanden zu erzeugen

den Extrakte statt. Sie ist jedoch auch hier relevant, da nicht immer alle extrahierten

Daten auch im Data Warehouse verwendet werden (vgl. Abschnitt 4.3.2.3.2).

- Separieren und Zusammenfiihren

Separierung erzeugt mehrere Datensatze aus einem Ausgangsdatensatz, etwa zur ver

einfachten Darstellung verschiedener Sichten eines Sachverhalts. So werden bei

spielsweise in auf dem relationalen Modell basierenden Systemen mehrere Tabellen

mit kleinen Tupeln anstelle einer groBen Tabelle mit vie len Spalten gebildet. Umge

kehrt werden durch das ZusammenfUhren Informationen tiber einen Sachverhalt ge

btindelt. Dies wird im Data Warehouse-Kontext regelmaBig der relevantere Fall sein,

da es hier ja gerade das Ziel ist, themenorientiert zusammengestellte Informationen

vorzuhalten.

- Normalisieren und Denormalisieren

Diese Funktionen stehen in einem engen Zusammenhang zu den letztgenannten, lassen

sich aber dennoch von dies en trennen. Bei der Normalisierung ist das Ziel nicht wie

bei der Separierung die Bildung moglichst kleiner Tabellen, sondern die Redundanz

vermeidung durch gezielte Verteilung der Daten auf verschiedene Tabellen entspre

chend der Normalformenlehre. Normalisierung ist im Rahmen der Aufbereitung von

500 Zur genauen Definition dieser Auswahlfunktionen eignet sich im Kontext relationaler Datenbanksysteme die Relationenalgebra.


Daten fiir ein Data Warehouse durchzufiihren, wenn nicht-normalisierte Quelldaten in

ein auf dem relationalen Modell basierendes Data Warehouse tiberftihrt werden sollen.

Dies ist etwa dann der Fall, wenn hierarchisch organisierte Quelldateien verarbeitet

werden sollen, oder solche, die in an das relationale Modell angelehnten Strukturen

sogenannte Wiederholgruppen aufweisen.501 Denormalisierung lOst dagegen Relatio

nen auf und tiberfiihrt zusammengehorende Informationen in gemeinsame Datensatze.

Redundanzen werden dabei in Kauf genommen. Dies entspricht analog zum Zusam

menfiihren eher dem Data Warehouse-Gedanken als die gegenteilige Operation.

- Aggregieren

Bei der Aggregation werden aus Detail-Datensatzen Zusammenfassungen nach ent

sprechenden Rechenregeln gebildet, wobei fiir betriebswirtschaftliche Zusammenhan

ge in erster Linie Summen und Durchschnittswerte relevant erscheinen.502 An welcher

Stelle im Ablauf der Datentibernahme Aggegationen gebildet werden, wird von Prakti

kabilitatstiberlegungen abhangig sein. Sofern bereits im Data Warehouse vorhandene

Werte in die Berechnungen einflieBen sollen, erscheint es zweckmaBig, die Aggrega

tionen erst nach dem Einfiigen der neuen Werte in das Data Warehouse durchzufiih

ren.503

- Umwandeln

Diese Feldfunktion verandert den Wert eines Datenfeldes, und zwar entweder nach

mathematischen Regeln (z.B. bei der Umwandlung eines Wertes der MaBeinheit "Zoll"

in einen Wert der MaBeinheit "Meter") oder durch die Anwendung von Konversi-

501

502

503

Wiederholgruppen werden z.B. durch die meisten Versionen des verbreiteten Datenbankmanagementsystems ADABAS (Software AG) unterstiitzt. Teilweise wird in der Literatur von "Summation" anstelle von "Aggregation" gesprochen, da sich auch die Rechenschritte in den anderen Grundrechenarten auf die mathematische Operation der Addition zuriickfUhren lassen. Johnson (1970), S. 644f., etwa sieht "summation" als Oberbegriff zu "aggregation" (Addition oder Durchschnittsbildung aus einze1nen Zahlenreihen), "combination" (Bildung von Beziigen aus unterschiedlichen MaBgraBen) und "composition" (Bildung von Beziigen aus MaBgrai3en unterschiedlicher Charakteristik) und unterscheidet weiterhin fUr "aggregation" und "combination" jeweils GraBen zeit- und subjektbezogener Charakteristik. HavelkaiKhazanchi (1994) verwenden "aggregation" und "summation" dagegen synonym. Ijiri (1967), S. 120, sowie Sorter (1969), S. 14, weisen zudem darauf hin, daB durch Aggregation ein Informationsverlust entsteht, wenn die Einzelwerte nicht mehr verfiigbar sind. Devlin (1997), S. 209, unterscheidet allerdings zwischen dem Business Data Warehouse (BDW) und dem Business Information Warehouse (BIW) und bestreitet die Notwendigkeit aggregierter Werte im BDW. Aggregierte Werte seien im (dem Data Mart vergleichbaren) BIW zu speichem.


onstabellen, die fiir die moglichen EingangsgroBen der Umwandlungsfunktion jeweils

einen Ergebniswert beinhalten.

- Erganzen

Durch Ergiinzung werden die Datensiitze urn zusiitzliche Werte angereichert, urn den

Informationsgehalt zu steigern. So werden z.B. Datensiitze tiber Auftragspositionen,

welche die Werte fiir "Einzelpreis" und "Menge" enthalten, urn einen Wert

"Positionswert" ergiinzt, der das Produkt dieser Daten enthiilt. Komplexer wird diese

Funktion, wenn der neu zu bildende Wert aus Feldinhalten verschiedener Datensiitze

gebildet werden soli (z.B. Berechnung eines Auftragswertes als Summe der Produkte

aus Preis und Menge aller Auftragspositionen).504

1m folgenden wird dargestellt, welche Verarbeitungsschritte mit Hilfe dieser Funktio

nen durchzufiihren sind.

4.3.2.2 Beseitigung syntaktischer Heterogenitat

Ein erster, sicherlich mit vergleichsweise einfacher Programmlogik zu realisierender

Schritt erfordert die Homogenisierung des Datenmaterials auf syntaktischer Ebene. Ein

in der Literatur vielfach zitiertes Beispiel hierfiir ist die Vereinheitlichung der Reprii

sentation von Datums- und Uhrzeitwerten.505 Diese konnen etwa in verschiedenen der

zahlreichen denkbaren alphanumerischen Darstellungsweisen vorliegen oder auch in

internen Datumsformaten, wie sie von den relationalen Datenbankmanagementsyste

men verwendet und erst bei der Ausgabe in ein lesbares Format umgesetzt werden.506

Ftir die Verwendung der Daten im Data Warehouse ist es notwendig, eine einheitliche

Repriisentation dieser Werte unter Berticksichtigung der moglicherweise zu bildenden

verschiedenen Hierarchien zu erzielen.

Ahnliche Uberlegungen wie fiir die Umstellung von Datumsformaten lassen sich etwa

fiir die folgenden Bereiche anstellen (vgl. Abbildung 27):

504

505 506

Der Komplexitatsgrad wird we iter gesteigert, wenn die EingangsgroBen dieser Funktion aus Datensatzen unterschiedlicher Quellen stammen. Vgl. z.B. Inmon (1996), S. 117. Erschwerend ist zu beach ten, daB verschiedene relationale Datenbankmanagementsysteme nicht unbedingt iiber kompatible Datumszahlensysteme verfiigen oder auch teilweise Uhrzeit und Datum in zwei Spalten schreiben. Ein Beispiel hierfiir liefern AnahorylMurray (1997), S. 157.

Gewinnung und Transfonnation von Daten fUr das Data Warehouse 173

'rn ' ... 1

030599 ... 05 - MAR - 1999

PLZ_ORT ... PLZ ORT

44795 Bochurn 44795 Bochurn

Abbildung 27: Beispiele syntaktischer Umwandlung von Datenbestanden

• In den Datenbestanden enthaltene Abktirzungen sind zu decodieren und zu verein

heitlichen.507 Es sind viele Bereiche denkbar, in denen Abktirzungen oder sonstwie

codierte Informationen spater moglicherweise zur Bildung von Aggregationen aus

gewertet werden mtissen: Landerkennungen, MaBeinheiten, Farben, Verweise auf

Personen oder Abteilungen (Verkaufer, Vertreter etc.). Auch wenn diese Codes im

Rahmen einer normalisierten Datenhaltung innerhalb eines Subsystems einheitlich

genutzt werden,508 ergeben sich Unterschiede zwischen den Teildatenbestanden der

verschiedenen Datenquellen.

• Die verschiedenen Computersysteme verwenden unterschiedliche Zeichensatze fUr

die Darstellung von Informationen numerischer oder alphanumerischer Datentypen,

da einerseits mit zunehmenden Speicherkapazitaten neuerer Rechner die Moglich

keiten zur seman tisch vollstandigen Reprasentation verbessert wurden und anderer

seits fUr die verschiedenen Rechnerklassen mehrere Codierungssysteme nebenein

ander existieren.509 Hier muB eine Normierung auf den yom Betriebssystem und

Datenbanksystem des Data Warehouse verwendeten Zeichensatz erfolgen. Ver

scharft wird dieses auf den ersten Blick triviale Problem, wenn, etwa in einem inter

national operierenden Konzern, lander- bzw. fremdsprachlich spezifische Varianten

507 508 509

Vgl. z.B. Burch (1997), S. 81. Selbst diese Minimalannahme diirfte teilweise realitatsfern sein. Vgl. Bohn (1997), S. 15 Iff. Gangige alphanumerische Zeichensatze sind insbesondere 7-bit oder 8-bit ASCII (American Standard Code for Information Interchange) und EBCDIC (Extended Binary Coded Decimal Interchange Code) Code Page 500, aber auch ISO 8859/1 und JEUC (Japan Extended UNIX Code). Der Buchstabe "AU wird beispielsweise in 7- und 8-bit ASCII durch den numerischen Wert 65 und in EBCDIC durch 193 reprasentiert. Auch fUr die DarsteUung von Zahlen gibt es unterschiedliche Codierungsweisen (vgl. Bohn (1997), S. 160f.).


dieser Zeichensatze beriicksichtigt werden mtissen oder gar multimediale Informa

tionen, die als Bild- oder Tondateien in einer Vielzahl von Formaten vorliegen kon

nen, verwendet werden sollen.5lO

• Weiterhin sind MaBeinheiten anzupassen.511 In landeriibergreifenden Informations

sammlungen werden moglicherweise metrische und nicht-metrische GroBen auftre

ten, vor allem sind aber auch innerhalb dieser Systeme gleiche Einheiten zu ver

wenden sowie branchen- oder unternehmensspezifische MaBgroBen exakt zu defi

nieren und zu homogenisieren.

• In Hinblick auf die spatere Verwendung der Daten fUr Berechnungen mtissen Da

tentypen vereinheitlicht werden. Insbesondere sollten numerische Werte einen ent

sprechenden, zu den Datentypen anderer Werte kompatiblen Datentyp aufweisen.512

• Die Datensatze mtissen in moglichst sorgfaltig und konsistent strukturierter Form

vorliegen. So sollten als relevant erachtete Merkmale immer in eigenen Datenfel

dern gespeichert werden, da sonst der Zugriff auf die entsprechenden Informationen

erschwert wird.513 Beipielsweise ist es sinnvoll, sofern spater entsprechende Diffe

renzierungen moglich sein sollen, die Farbe eines Produktes als eigenstandiges At

tribut zu speichern und diese Information nicht in einem nicht weiter strukturierten

Textfeld mit dem Produktnamen, der Farbe und moglicherweise weiteren Attributen

abzuspeichern. Gegebenenfalls sind Algorithmen vorzusehen, urn derartige Felder

in separate Elemente zu zerlegen.514 Dariiber hinaus erscheint es zweckmaBig, wenn

Daten ahnlichen Typs aus verschiedenen Quellen auch in gleichem Atomizitatsgrad

vorliegen.

Bei der Beseitigung syntaktischer Heterogenitat ist darauf zu achten, daB sowohl in

nerhalb einer Datenquelle Werte aller Datensatze im gleichen Format vorliegen als

auch die verschiedenen Quellen das gleiche Format verwenden. Die hier dargestellten

Vereinheitlichungsschritte werden in ahnlicher Form teilweise auch als Auspragungen

der Bildung referentieller Integritat angesehen. Dabei wird zwischen "utilization inte

grity" (gleiche Formate in Hinblick auf Kompatibilitat der Werte bei der spateren Nut-

510

511

512

513

514

Einen Uberblick tiber Codierungsformen von Daten verschiedener Informationstypen geben DavislNeumann (1997). Vgl. z.B. Inmon (1996), S. 75. Beispielsweise mtissen fiir die Berechnung eines Wertes mit ganzzahligem Datentyp auch die EingangsgroBen ganzzahlig sein. V gl. Gabriel/Rohrs (1995), S. 56. Vgl. Burch (1997), S. 77.


zung), "population standardization" (identische Darstellungsform fUr identische Sach

verhalte) und "interfile standardization" (systemweit, nicht nur dateiweit einheitliche

Darstellung) unterschieden.515 Allerdings erscheint der Begriff "referentielle Integri

tat" in diesem Zusammenhang nicht unbedingt geeignet, da er sich in der deutsch- wie

auch in der englischsprachigen Literatur eher auf die semantische Richtigkeit und

Vollstandigkeit normalisierter Datenbestande bezieht.516 Hier geht es dagegen eher urn

syntaktische Aspekte der Vereinheitlichung eines Datenbestands; und auch ein Daten

bestand, der die oben dargestellten Mangel in der Eignung fUr die Dbernahme in ein

Data Warehouse aufweist, kann referentielle Integritat aufweisen.517

Die einzelnen genannten MaBnahmen stellen, fUr sich betrachtet, keine groBen An

spriiche an die notwendigen Verarbeitungsalgorithmen und deren Methodenbasis. Die

Problematik ergibt sich daraus, daB die erforderlichen Schritte fiir verschiedene Daten

quellen und fUr jedes einzelne Datenobjekt erkannt und unter Beachtung der entste

henden Interdependenzen festgelegt werden miissen. Bei einem gr6Beren Data Ware

house-Projekt wird bereits dieser Schritt einen erheblichen Komplexitatsgrad aufwei

sen. Daher wird schon hier deutlich, daB eine leistungsfahige Metadatenverwaltung

notwendig ist, welche die Informationen zur Planung dieser Umwandlungsschritte

enthalt und Algorithmen zu deren DurchfUhrung generieren kann.

4.3.2.3 Datenaufbereitung

Die im vorherigen Abschnitt diskutierten MaBnahmen zur Erzielung syntaktisch ho

mogener Datenbestande beinhalteten noch keine Prozesse, die dem Erzielen und der

Kontrolle einer syntaktischen Richtigkeit und Vollstandigkeit der Datenbestande die

nen. Hier ist eine Reihe weiterer Priifungen und Bearbeitungsschritte vorzunehmen,

urn dieses Ziel zu gewahrleisten. Von dies en Bearbeitungsschritten zu trennen ist je

doch eine semantische, inhaltliche Priifung der Daten. Dieser Aspekt wird etwas spater

in Abschnitt 4.3.2.5 erlautert.

515

516

517

V gl. Mattison (1996), S. 137. V gl. z.B. Date (1995), S. 120; Elmasri/Navathe (1994), S. 147ff.; KemperlEickler (1997), S. 134ff.; Snyder (1993), S. 227. Weiterhin ist zu beachten, daB referentielle Integritiit im herkiimmlichen Sinne im Data Warehouse nicht unbedingt eine mit groBer Prioritiit zu erzielende Eigenschaft ist. Bedingt durch die (noch zu diskutierende) Denormalisierung und den speziellen Charakter der Anfragen an das Data Warehouse ist sie in der in den operativen Systemen vorliegenden Form weder erwlinscht noch gegeben. Vgl. Inmon (1996), S. 105ff.; Glassey-Edholm (1997), S. 113.


Dnter "Datenaufbereitung" werden im einzelnen diskutiert:

1) MaBnahmen zur Erkennung und Beseitigung von Fehlern in den Datenbestanden,

die sich aufgrund von Integritatsregeln erkennen lassen,

2) MaBnahmen, die aus den Extrakten der operativen Systeme die nicht relevanten

Teile entfernen,

3) MaBnahmen zur Behandlung fehlender Werte.

Die folgende Abbildung 28 visualisiert die Bearbeitungsschritte, die unter diesem

Punkt zu subsumieren sind. Sie werden in den folgenden Abschnitten naher beschrie

ben.

Betrag Betrag

175.00 DM 175,00

__ ~_N_e_"_O~r-_U_S_t' __ r-B_r_U_"_o-+ __ ~ __ ~ ___ N_e_t_to ____ +I __

100,00 16,00 116,00 100 .00

Datum Kurs Datum Kurs -----+--~-_+__ ~ -----+----t--_t__

10.3 . 1 . 829 10.3. 1.829 11.3. 11.3. 1 . 830 12.3. 1,841 12.3. 1.841

Abbildung 28: Schritte zur Datenaufbereitung

Auch im Rahmen dieser Arbeitsschritte kommt einer leistungsfahigen Metadatenver

waltung eine groBe Bedeutung zu.

4.3.2.3.1 Datenreinigung

1m Rahmen eines Datenreinigungsprozesses sollen die Quelldaten ftir das Data Ware

house einer Priifung unterzogen werden, urn sicherzustellen, daB sie den Qualitatsan

forderungen flir die spatere Verwendung entsprechen.518 Es findet eine erste inhaltliche

518 Vgl. Burch (1997), S. 76f.


Kontrolle der Daten anhand der in den Modellen fUr das operative System und das

Data Warehouse festgelegten IntegriUltsregeln statt.519

Zunachst sind syntaktisch offensichtlich falsche Datensatze zu bearbeiten. Diese ent

stehen, wenn die Integritatsregeln der operativen Systeme nicht sehr eng ausgelegt sind

und die Benutzer aus Unkenntnis oder mangelndem ProblembewuBtsein heraus Daten

felder mit nicht zulassigen Werten fUlien konnen.520 Als typische Beispiele sollen hier

nur genannt werden: 521

• Mit alphanumerischen Werten gefUlite numerische Felder wie etwa Kommentare in

Telefonnummernfeldern oder - fUr Anwendungsfalle im Rahmen eines analyseori

entierten Informationssystems vielleicht relevanter - Wahrungsktirzel in Betragsfel

dern, welche die Bildung berechneter Werte erschweren,

• Datenfelder, fUr die kein Wert vorliegt, die aber mit Texten wie "nicht vorhanden"

oder einem Strich gefUlit wurden.

Ein weiterer wesentlicher Aspekt ist die sogenannte Domanenintegritat (domain inte

grity522). Es ist zu prtifen, ob Werte innerhalb der zulassigen, durch entsprechende

Metadaten definierten Wertebereiche liegen.

Als Reinigungsstrategie fUr diese Problembereiche kommen die manuelle oder auto

matisierte Korrektur oder das Loschen der entsprechenden Datensatze in Frage.523

Letzteres erscheint unbefriedigend, da dieses Vorgehen zu einem in nicht kontrollier

barer Form unvollstandigen Datenbestand fUhrt. Automatisierte Korrekturverfahren

setzen komplexe Programme voraus, die in der Lage sind, den richtigen Wert oder den

Zustand "kein Wert" zu ermitteln oder einen geeigneten Standardwert zu setzen. In

diesem Zusammenhang wird auch Software, die sich der Methoden der ktinstlichen

Intelligenz bedient, als geeignet bezeichnet. 524

519

520

521

522

523

524

V gl. Inmon (1996), S. 117ff. Brachman/Anand (1996), S. 50, wei sen darauf hin, daB aus der Art und Menge der fehlerbehafteten Daten wertvolle Rlickschli.isse auf mogliche Verbesserungen in den Prozessen, welche die Daten erzeugen, gewonnen werden konnen. V gl. Mattison (1996), S. 135f. Vgl. Burch (1997), S. 77. V gl. Mattison (1996), S. 136. Vgl. Inmon (1996), S. 117. Unter klinstlicher Intelligenz wird die Abbildung men schlicher Denk-, Entscheidungs- und Probleml6sungsverhalten verstanden, urn sie durch computergestlitzte Losungsverfahren nutzen zu konnen. Eine wesentliche Komponente von Software, die auf diesen Ansatzen basiert, ist die Wissensbasis, die durch ein nach verschiedenen Strategien


4.3.2.3.2 Entfernung irrelevanter Datenobjekte

In Abhangigkeit von der verwendeten Strategie zur Extraktion der Daten aus den ope

rativen Systemen sind moglicherweise Daten im Extrakt enthalten, die fUr das Data

Warehouse nicht relevant sind. Besonders bei der Verwendung von Techniken, die

zunachst groBe Teile des operativen Datenbestands ohne ausgefeilte Auswahlmecha

nismen kopieren (bulk copy), erscheint diese Form der Bereinigung des Datenbestands

erforderlich. Uber das Data Warehouse-Datenmodell ist erkennbar, we1che Daten

benotigt werden. Die restlichen sind zu loschen, damit das Data Warehouse nur mit

den relevanten Daten bestiickt wird.525 Analog zur oben beschriebenen Auswahlfunk

tion kann dieses Loschen innerhalb der einzelnen Schemaobjekte horizontal oder verti

kal notwendig sein oder auch ganze Schemaobjekte betreffen.

Auch auf Datensatzebene treten Konstellationen auf, die ein Entfernen von Teilen des

Datenbestands nahelegen. Sollen etwa Buchungssatze ausgewertet werden, erscheint es

zweckmliBig, Fehlbuchungen und die entsprechenden Stornobuchungssatze aus dem

analyserelevanten Datenbestand zu eliminieren.526

4.3.2.3.3 Behandlung fehlender Werte

Eine weitere Problemquelle stellen fehlende Werte (null values)527 in den Datenbe

standen dar.528 Hier ist das Phanomen angesprochen, daB Datenbestlinde nur selten

wirklich aile relevanten Werte enthalten werden. Vielmehr ist damit zu rechnen, daB

Felder in den Quelldatenbestlinden teilweise nicht gefUllt werden. Aus der Vielzahl der

hierfiir denkbaren Griinde lliBt sich eine Typisierung der Nullwerte ableiten.529

525 526 527

528

529

getriebenes Folgern auf ein Problem angewendet wird, urn eine Losung zu ermitteln. Vgl. zu dieser Thematik z.B. Gabriel (1992), Lehner (1997) und Das (1997). Vgl. Anahory/Murray (1997), S. 50; Devlin (1997), S. 207. Vgl. Brachman/Anand (1996), S. 50. Diese leeren Felder diirfen nicht mit Feldern verwechselt werden, die den Zahlenwert "Null" enthalten. Hier soli es urn fehlende einzelne Werte in prinzipiell vorhandenen Informationstypen gehen. Mattison (1996), S. 59f., spricht unter dem Stichwort "missing data" dagegen das Problem an, daB zu Informationen, die die Benutzer dem Data Warehouse entnehmen mochten, moglicherweise keine Quelldaten vorliegen, die den operativen Systemen entnommen werden konnen. Dieser Aspekt ist eher der Problemsphiire der anforderungsadiiquaten Modellierung zuzuordnen. Vgl. zu den Nullwertarten, deren Implikationen auf Anfragen an Datenbanken und den Informationsgehalt der Daten Codd (1979), S. 403ff.; Maier (1983), S. 372ff.; Codd (1986), S. 56ff., sowie Libkin (1994), S. 3ff. Zu Aspekten der Semantik von Nullwerten in Datenbanken vgl.


- Nichtexistierende Werte (nonexisting nulls, ne)530

Dieser Fall ist gegeben, wenn fUr einzelne Datensatze bestimmte Attribute nicht zutref

fen, wei I entsprechende, zu beschreibende Merkmale nicht existieren. Beispiele hierfUr

gibt es zahlreiche. So mag zu einer Adresse nicht immer eine Telefonnummer gehoren,

und auch nicht jeder Mensch hat einen yom aktuellen Namen abweichenden Geburts

namen. Als wei teres Beispiel sei ein Informationssystem mit Personaldaten genannt, in

dem unterschiedliche Zu- und Abschlage zum Grundgehalt (Vermogenswirksame

Leistungen, Uberstundenzuschlage, Kirchensteuer, diverse Sozialabgaben) zu beriick

sichtigen sind, die aber in Abhangigkeit von den personlichen Voraussetzungen nicht

bei jedem Mitarbeiter zutreffen.

- Existierende, aber unbekannte Werte (existing unknown values, un)531

Hier ist bekannt, daB ein entsprechender Wert existiert und relevant ist, dieser jedoch

im Datenbestand nicht enthalten ist. Die Ursachen fUr diesen Problemtyp konnen etwa

darin liegen, daB bei der Datenerfassung mit mangelnder Sorgfalt vorgegangen wurde

oder der entsprechende Wert zu diesem Zeitpunkt nicht voriag und auch nicht nachge

tragen wurde. Insgesamt JaBt dieser Problemtyp auf Mangel in der Konsistenzsiche

rung der Datenbestande oder auf nicht vollstandig an das Datenmodell angepaBte An

wendungsprogramme schlieBen. Als Beispiel seien etwa fehlende Preise oder Buch

werte in Bestell- bzw. Bestandsdaten genannt.

- Fehlende Informationen (no information nulls, ni)

In diesem Fall fehlt zusatzlich die Information, ob ein Wert tiberhaupt relevant ist, d.h.,

es ist unbekannt, ob der fehlende Wert yom Typ un oder ne ist. In Fortsetzung des

Personalbeispiels ist dieser Fall etwa gegeben, wenn fUr einen Mitarbeiter die Konfes

sion nicht bekannt ist und somit keine Informationen vorliegen, ob (ne) und in welcher

Hohe (un) Kirchensteuern abzufUhren sind.

Die genannten verschiedenen Nullwerte beinhalten ein unterschiedliches MaB an In

formation. Der erste Fall (ne) enthalt vollstandige Information,532 da hier ja bekannt

530

531 532

Gottlob/Zicari (1988), S. 53f., sowie Libkin (1998), S. 177ff. Spezielle Integritatsbedingungen fiir Datenbanken mit Nullwerten werden von LevenelLoizou (1998) diskutiert. Lerat/Lipski (1986) diskutieren diese Problemstellung ausfiihrlich und zeigen mit Hilfe der Relationenalgebra spezifische Anfragen an Schemaobjekte, die diesen Nullwerttyp enthalten. Vgl. Maier (1983). S. 372; Grahne (1991). S. 33ff.; Libkin (1994). S. 8. Vgl. Libkin (1994). S. 8.

180 Funktionale und inhal!liehe Aspekte der Transformation

ist, daB kein Wert vorliegt.533 Semantisch weniger wertvoll sind dagegen die beiden

letztgenannten Hille. Der un-Fall beinhaltet immerhin noch die Information, daB ein

Wert vorliegen mUBte, wahrend ein ni-Nullwert in dieser Klassifikation den geringsten

Informationsgehalt aufweist.

Es ist nun zu diskutieren, inwieweit Nullwerte dieser Typen im Rahmen der Daten

transformation flir ein Data Warehouse zu beseitigen sind.

Kein Handlungsbedarf besteht offensichtlich bei den ne-Nullen. Es ist allenfalls zu

fordern, zur deutlichen Unterscheidung von den Typen un und ni einen Wert einzutra

gen, der genau diesen Sachverhalt der fehlenden Anwendbarkeit ausdriickt und so auch

eventuelle verarbeitungs- und rechentechnische Probleme beseitigt.

Fiir die iibrigen Hille ist zu priifen, ob ein Nachtragen der entsprechenden Werte sinn

voll und erforderlich ist. Einerseits erscheint das Problem mangelhaft genauer Detail

werte aufgrund des eher an iibergreifenden Zusammenhiingen orientierten Nutzungs

charakters des Data Warehouse auf den ersten Blick wenig relevant. Andererseits

verringern fehlende Werte dennoch die Genauigkeit spiiterer maglicher Auswertungen

und kannen zu Schwierigkeiten bei der Bildung aggregierter Werte flihren. So sind

rechentechnische Starungen zu erwarten, die sich aus der Verwendung undefinierter

Werte ergeben, wie z.B. Divisionen durch Null. AuBerdem entstehen deutliche Unge

nauigkeiten, etwa bei der Bildung von Summen- und Durchschnittswerten.534

Neben diese auf der Wertebene angesiedelten Probleme treten Riickwirkungen, die

Nullwerte auf die entsprechenden Datensiitze haben kannen. Wird etwa in einem rela

tionalen Datenbestand eine Auswahl von Datensiitzen anhand eines Kriteriums durch

geflihrt, des sen Wertemenge undefinierte Elemente enthiilt, werden die entsprechenden

Datensiitze nicht in der Auswahl enthalten sein: Die Summe der Partitionen einer nach

einem bestimmten Kriterium partitionierten Datenmenge ist dann kleiner als die Aus

gangsmenge.535 1m Rahmen einer Data Warehouse-Lasung flihrt dies potentiell zu

falschen Analyseergebnissen, etwa wenn die Summe der Umsiitze nach Produktgrup-

533

534

535

Aus semantiseher Sieht handel! es sieh damit genaugenommen nieht urn einen fehlenden Wert, hier sol1 jedoeh auf den Saehverhalt abgestel1t werden, daB (syntaktiseh) das entspreehende Feld leer is!. Weitere Implikationen von Nul1werten fiir die Bildung von aggregierten Werten diskutieren DatelDarwen (1992), S. 302ff. Vgl. Codd (1979), S. 403ff.; Libkin (1994), S. 2.


pen nicht dem Gesamtumsatz entspricht. Insgesamt wird also die Notwendigkeit zur

Korrektur fehlender Werte vor der Durchfiihrung von Berechnungen sichtbar.

Zur Behandlung der Nullwerte kommen verschiedenene Strategien in Frage. Die sicher

genaueste, wenn wohl auch im Regelfall nur schlecht praktikable Losung ist das nach

tragliche Ermitteln und Einfiigen der fehlenden Werte. Dabei ist jedoch davon auszu

gehen, daB dies zumindest bei einem MindestmaB an Qualitat bei den Quelldatenbe

standen nicht ohne weiteres moglich sein wird, da sie sich aus den vorhandenen Daten

nicht oder nur mit einem unverhaltnismaBig hohen Aufwand ableiten lassen. Daher ist

nach Alternativstrategien zu suchen. Diese konnen in der Bildung eines Ersatzwertes

oder in der Anpassung der nachgelagerten Verarbeitungsvorschriften fiir die Daten

liegen.

Zur Korrektur eines nicht definierten Feldwertes kommen verschiedene Strategien in

Frage. Das Ziel wird darin bestehen, durch den gewahlten Ersatzwert die Genauigkeit

und Aussagekraft von spater berechneten Werten moglichst wenig einzuschranken. Je

nach Art der Daten und der Berechnungsvorschriften kommen so etwa die Werte 0 (flir

additive Verkntipfungen) oder 1 (flir multiplikative Verkntipfungen) in Frage. Alterna

tiv konnen auch aus vorhandenen Werten zum gleichen Sachverhalt Durchschnitts

werte oder auf andere Weise extrapolierte Werte gebildet werden.536 Hier ist flir jedes

einzelne Informationsobjekt festzulegen, nach welchen Regeln derartige Werte zu

erzeugen sind. 53? Nachteilig erscheint, daB nachtraglich gebildete Ersatzwerte eine

nicht vorhandene Genauigkeit vortauschen konnen, sofern sie nicht mehr von "echten"

Werten unterscheidbar sind. Die Information, daB ein bestimmter, echter Wert nicht

verfligbar ist, geht verloren.

Als Alternative zur Bildung von Ersatzwerten konnen die Verarbeitungsvorschriften

flir die Data Warehouse-Daten so gestaltet werden, daB fehlende Werte keinen EinfluB

auf die Genauigkeit gebildeter aggregierter Werte haben und Rechenprozesse nicht

beeintrachtigt werden. Dies setzt moglicherweise von der Transformationskomponente

536

53? Vgl. Hackathorn (1993), S. 256. Brachman/Anand (1996), S.50, schlagen fiir bestimmte Problemkonstellationen die Bildung von Schatzwerten vor. In ihrem Beispiel fiihren sie aus, daB bei der Ermittlung von Verkaufsdaten im Handel iiber Scannerkassen sperrige Produkte nur unzureichend erfaBt werden, da hier die Preise aus Praktikabilitatsgriinden manuell, ohne Scanner und damit ohne Artikeldaten erfaBt werden. Aus diesem Wissen heraus soli eine geschatzte Korrektur der Umsatzzahlen der betroffenen Produkte erfolgen.


gesteuerte, dynamische Berechnungsvorschriften voraus, da Art und Umfang der feh

lenden Werte variabel sein werden.

Diese Uberlegungen seien an einem kleinen Beispiel verdeutlicht. Es soli im Data

Warehouse etwa eine Wertereihe mit tagesaktuellen Kursen einer Fremdwahrung, z.B.

des US-Dollars, gepfJegt werden. Weiterhin sei festgelegt, daB ein Wochenmittelkurs

errechnet wird, der als arithmetisches Mittel der Tageskurse von Montag bis Freitag

(Summe der Tageskurse + 5) definiert ist.538 Liegt nun flir einen Wochentag keine

Kursinformation vor, wird der Mittelwert erheblich verzerrt, sofern nicht entweder die

Berechnungsvorschrift dahingehend angepaBt wird, daB der Durchschnitt nur tiber die

verfligbaren Werte gebildet wird, der fehlende Wert vor der Berechnung nachgetragen

oder durch einen geeigneten Ersatzwert substituiert wird.

4.3.2.4 Modellkonvertierung

Die Struktur der aus den operativen Datenbestanden extrahierten Daten entspricht noch

nicht dem Modell des Data Warehouse. Die Unterschiede finden sich sowohl in der Art

als auch in der Auspragung der jeweiligen, den Datenbestanden zugrundeliegenden

Datenmodelle. Unter der Modellart soli hier das logische Datenmodell als Struktur

konzept flir die Reprasentation von Datenbankschemata verstanden werden, unter

Auspragung das Modell als Abbildung des problemrelevanten Realitatsausschnittes mit

Hilfe der Strukturelemente der gewahlten Modellart.

Hinsichtlich der Art ist davon auszugehen, daB sich die aus den operativen Systemen

extrahierten Daten in ihrer Struktur an einem der flir solche Systeme tiblichen, her

kommlichen Datenmodelle orientieren, also als relationale, hierarchische, netz

werkformige Datenbank, oder auch in einfachen Textdateien vorliegen. Diese Daten

sind so umzustrukturieren, daB sie dem Datenmodell des Data Warehouse entsprechen,

das tiblicherweise in relationaler oder mehrdimensionaler Form vorliegen wird.539

Abbildung 29 zeigt ein schematisiertes Beispiel.

538

539

Diese Berechnungsformel ist modellhaft vereinfacht, je nach Zweck dieser Berechnung kame auch ein unter Berticksichtigung der jeweils getatigten Umsatze gewichteter Mittelwert in Frage. Ein relationaler Datenbestand fUr analytische Zwecke muB dabei nicht unbedingt normalisiert sein. Als Beispiel konnen Daten angefUhrt werden, die im Data Warehouse in einem relationalen Datenbanksystem in Star Schema-Struktur vorliegen, vgl. hierzu Abschnitt 3.2.2. Somit sind gegebenenfalls Denormalisierungsschritte erforderlich.


Region West Vertreter _10 Name Region

107 Langner West 108 Schneider West 109 R15der West .. . .. . ...

Kunde_IO . .. Vertreter _10

6438 107 6439 107 6440 107 .. . . . .

I I I I I /1/ /

ITrJ )// )/

V /

Abbildung 29: Modellkonvertierung

Die Auspragung der Datenmodelle ist naturgemaB unterschiedlich, da sich die Pro

blemstruktur bei der Abbildung von Daten zu operativen Zwecken einerseits und ana

lytischen Zwecken andererseits wesentlich unterscheidet. Soll das Data Warehouse mit

Daten aus verschiedenen operativen Quellen gespeist werden, mtissen zusatzlich die

verschiedenen Quelldatenbestande auch hinsichtlich ihrer Modelle konsolidiert wer

den.

Es lassen sich zur Transformation der Datenbestande aus den operativen Quellen in das

Data Warehouse modellseitig damit die folgenden Schritte als notwendig identifizie-

ren:

• Gegentiberstellung und Verkntipfung von Quell- und Zieldatenobjekt ( .. Mapping"),

• Analyse und Konsolidierung der Modelle der Quelldaten,

• Umstrukturierung der Daten zur Anpassung an das Zieldatenmodell, insbesondere

Denormalisierungen.

1m Rahmen des Mapping wird die Verbindung zwischen einem Quell- und einem

Zie1datenobjekt hergestellt. Es ist zu definieren, an welcher Stelle im Modell des Data

Warehouse die Datenobjekte aus den Quelldatenbestanden einzuftigen sind. Diese


Aufgabe erscheint verhaltnismaBig einfach, so lange Daten aus einem in sich konsi

stenten relationalen Modell in ein gleichfalls relationales Data Warehouse

Datenmodell ubernommen werden sollen. In dies em Fall sind einfach ganze Tupel

oder mit Hilfe der Relationenalgebra erzeugte Teilmengen daraus in die entsprechen

den Spalten der Zieltabellen zu kopieren. Diese Operationen konnen mit Hilfe von

SQL-Befehlen leicht durchgefiihrt werden. Aufgrund der groBen Menge der Datenob

jekte zeigt sich an dieser Stelle aber einmal mehr, daB eine leistungsfahige Metadaten

verwaltung unbedingt erstrebenswert ist, urn die erforderlichen Mapping-Operationen

zu dokumentieren.540 Weiterhin bietet eine leistungsfahige Verwaltungskomponente

auch die Moglichkeit, die entsprechenden Befehlsskripte automatisiert zu erzeugen.

Die Durchfiihrung des Mapping ist eine der Kerntatigkeiten beim Aufbau der Trans

formationskomponente, da dabei zumindest modellmaBig die Verknupfung zwischen

den Datenbestanden vollzogen und damit die Vollstandigkeit des Data Warehouse

Datenbestands determiniert wird.541

Die Komplexitat der Problematik steigt, wenn verschiedene Datenquellen zusammen

gefiihrt und zu einem Zieldatenbestand fUr das Data Warehouse konsolidiert werden

mussen.542 Neben der im nachsten Abschnitt zu diskutierenden Vereinheitlichung der

Datensatze mussen auch die verschiedenen Modelle konsolidiert werden. So ist es

notwendig, Objekte in den verschiedenen Modellen zu identifizieren, die gleiche

Sachverhalte beschreiben (Abbildung 30). Insbesondere in heterogenen Umgebungen

mit vielen Altsystemen ist zu erwarten, daB diese zudem mit unterschiedlichen Be

zeichnern versehen sind, nicht identische Formate haben und moglicherweise in

Strukturen unterschiedlicher Modellierungskonzepte vorliegen.

Sollen beispielsweise Umsatzdaten verschiedener Tochterunternehmen, die separate

betriebliche Softwaresysteme verwenden, Eingang in ein Konzern-Data Warehouse

finden, mussen diese Daten zunachst in unterschiedlichen Datenmodellen mit unter

schiedlichen Tabellenstrukturen und jeweils eigenen Felddefinitionen identifiziert und

zusammengefUhrt werden. Hier sind also neben den Kopier- auch Umwandlungsope

rationen erforderlich. Weiter erschwert wird das Mapping, wenn nicht aile Quelldaten

in relationaler Form vorliegen, sondern auch nach anderen Modellen strukturierte

Daten verarbeitet werden sollen.

540

541

542

Vgl. Inmon (1996), S. 186. Vgl. Mattison (1996), S. 149. Vgl. Inmon (1996), S. 74; Hammer (1997), S. 36ff.


Kunde

Kd_Nr Name StraBe HausNr PLZ Ort

37865 Gottschalk Mozartstr. 15 44795 Bochum

Customer

Cust_ID Name Adress City State I7IP-CodE

25874 Friedman 358 .Iest Av. Berkeley CA 90066 ~

Alle_Kunden ., Ir ., r Kd_Nr ID_Alt Name StraBe HausNr PLZ PLZ_Zusatz Ort Land

1001 37865 Gottschalk Mozartstr. 15 44795 Bochum DE 1002 25874 Friedman Wes Av . 358 90066 CA Berkeley US

Abbildung 30: Modellkonsolidierung von Datenbestiinden unterschiedlicher Quellen

SchlieBlich ist die Notwendigkeit einer Umstrukturierung der Datenbestande von Be

deutung. Es ist, auch unabhangig von den obigen UberJegungen zur Problematik ver

schiedener Datenquellen, nicht davon auszugehen, daB die zu einem Modellobjekt

gehorigen Daten in einer 1: I-Relation auf ein Zielobjekt gemappt werden konnen.

Vielmehr wird es notwendig sein, die Daten in ihrer Anordnung in den Modellobjekten

zu verandern. Insbesondere miissen die Datenbestande denormalisiert werden, damit

sie in das Data Warehouse mit seinem an den spezifischen Problemstrukturen orien

tierten Datenmodell eingefiigt werden konnen.543 Gleichfalls von Bedeutung ist in

dies em Zusammenhang etwa der Ubergang von einem hierarchischen auf ein relatio

nales Datenmodell. Hier sind dann die Konstrukte der Modellwelt des Quelldatenbe

stands (bzw. die darin enthaltenen Daten) auf die vom Zie1system bereitgestellten

Strukturelemente umzusetzen.

Analoge UberJegungen lassen sich anstellen, wenn das Data Warehouse mit Hilfe einer

multidimensionalen Datenbanksoftware realisiert ist. In diesem Fall sind entsprechend

auch aile relationalen Modellobjekte durch komplexere Transformationsrege1n zu

543 V gl. Devlin (1997), S. 256f.


beschreiben. In dem - als typisch anzunehmenden - Fall uberwiegend relationaler

Quelldatenbestande kann also verallgemeinert davon ausgegangen werden, daB zumin

dest aus theoretischer Sicht die Transformation der Datenbestande auf der Modellebe

ne komplexer wird, wenn die relationale Modellwelt verlassen wird und die Daten an

andere Modellkonstrukte angepaBt werden mussen.

4.3.2.5 Homogenisierung des Datenbestands

Mit den bisher diskutierten Vorgehensweisen konnten die Datenbestande in syntakti

scher Form gereinigt und die zugrundeliegenden Datenmodelle aneinander angepaBt

werden, urn zu einem integrierten Datenbestand flir das Data Warehouse zu gelangen.

Als letzter wesentlicher Problemkreis in diesem Umfeld bleibt eine Aufgabe, die hier

als Homogenisierung des Datenbestands bezeichnet wird.

Wesentlich flir die Qualitat der Daten im Data Warehouse und damit flir dessen Nutz

barkeit ist, daB inhaltlich zusammengehorende Sachverhalte auch als solche erfaBt und

dargestellt werden konnen. In einer idealtypischen Situation ist dieser Zustand gege

ben, wei 1 ein konsistentes Datenmodell vorhanden ist und auch jedes Objekt der Rea

Jitat nur einmal abgebildet wird, so daB erkennbar ist, wenn sich mehrere Sachverhalte

auf ein identisches Realweltobjekt beziehen.

In der Praxis jedoch werden regelmaBig identische Objekte der Realwelt auch mehr

fach abgebildet sein, und zwar sowohl innerhalb eines Datenbanksystems wie auch in

verschiedenen, flir das Data Warehouse zu integrierenden Datenbestanden.544

Die Griinde flir die Mehrfacherfassung von Datensatzen sind vielfaltig. Mangelnde

Sorgfalt bei der Prufung bereits existenter, zu referenzierender Datensatze kann ebenso

zur Bildung von Duplikaten flihren wie unterschiedliche Schreibweisen von Namen,

verschiedene Adressen derselben Institution oder Person, orthografische Fehler oder

Fehlbedienung der Software.545 In den operativen Datenbestanden sind diese Duplikate

innerhalb eines Datenbestands nicht von so groBer Bedeutung, daB sie die Effizienz

544

545 Vgl. Mattison (1996), S. 138. Devlin (1997) nennt ein Beispiel (S. 214), wie unterschiedlich selbst der Name eines allgemein bekannten Untemehmens (The Coca Cola Corp.) geschrieben werden kann; vgl. auch Hammer (1997), S. 28. RegelmaBig vorkommen werden wohl Fiille, wo etwa ein Kunde sowohl unter einer Postfach- als auch unter einer StraBenadresse erfaBt is!. Diese Mehrfacherfassungsproblematik kann im taglichen Leben beobachtet werden, etwa wenn man regelmaBig mehrere Exemplare von Werbesendungen erhalt, die sich nur minimal in der Schreibweise des Namens oder der Adresse unterscheiden.


des Gesamtsystems in Frage stellen, so daB die Vermeidung oder Beseitigung solcher

Duplikate dort nicht als Aufgabe mit hoher Prioritat erscheint.546

Weiter deutlich verschlirft wird das Problem der Mehrfacherfassung, wenn mehrere

Teildatenbestande zum gleichen Sachverhalt fUr ein Data Warehouse konsolidiert

werden sollen und diese moglicherweise sogar in verschiedenartigen Systemen vorlie

gen. Dieser Fall tritt auf, wenn innerhalb des Unternehmens mehrere voneinander

getrennte Datenbestande mit sich sachlich liberschneidenden Inhalten gepflegt werden.

Dieses Problem taucht auch auf, wenn verschiedene Unternehmen innerhalb eines

Konzerns jeweils eigenstandige Datenbestande mit eigenen Schliisseln pflegen. Dies

wird typischerweise z.B. dann der Fall sein, wenn die verschiedenen Konzernunter

nehmen ursprlinglich voneinander unabhangige Firmen waren.547

Auch fUr diesen Fall gilt die Uberlegung, daB fUr den operativen Betrieb kaum StOrun

gen durch die Redundanzen in den Datenbestanden zu erwarten sind, da keine Verbin

dungen zwischen den Teildatenbestanden bestehen.548

In Abhangigkeit von den zu bearbeitenden Fragestellungen konnen derartige Mangel

im Datenbestand die Nutzbarkeit eines Data Warehouse aber erheblich einschranken.

Flir die Zusammenfassung der Daten fUr das Data Warehouse sind also Datensatze zu

erkennen und zu konsolidieren, die sich auf das gleiche Objekt der Realweh beziehen,

aber unterschiedliche Schliissel und moglicherweise sich widersprechende Merkmals

auspragungen enthalten.

Aus diesen Uberlegungen ergeben sich zur Homogenisierung der Datensatze die fol

genden Aufgaben:

• Erkennen redundanter Datensatze,

• Auflosen inhaltlicher Widerspruche in den als redundant erkannten Datensatzen.

546

547

548

Allerdings sind auch hier Problemstellungen denkbar, die das Vermeiden von Duplikaten wichtig erscheinen lassen. So wird z.B. ein Lieferant seinen Kunden nur im begrenzten Umfang Lieferantenkredite gewahren, urn notleidende Forderungen zu vermeiden. Diese Kreditlinie wird aber umgangen, wenn der Kunde mehrfach erfaBt ist und wissentIich oder unwissentIich unter verschiedenen Kundennummem bestellt. Vgl. Devlin (1997), S. 2l3f. Hier kann aber das Beispiel aus FuBnote 546 fortgefiihrt werden, wenn eine sogenannte "Konzemevidenzzentrale" aufgebaut werden soli, die konzemweit einheitIiche Bonitatspriifungen der Kunden ermoglichen und die Einhaltung entsprechender KreditIinien fur die Kunden uberwachen soli. Ein Anwendungsbeispiel beschreiben WatzlaweklFronhoff (1998), S. 28.


Das Kernproblem beim Erkennen redundanter Datensatze liegt darin, daB die Informa

tion extrahiert werden muB, daB es sich trotz verschiedener Schliissel und moglicher

weise unterschiedlichen Feldinhalten urn Datensatze handelt, die sich auf das gleiche

Objekt der Realwelt beziehen. Andererseits konnen auch sehr ahnlich erscheinende

Datensatze durchaus auf unterschiedliche Objekte verweisen.

Name Vorname Str_HNr ...

Schmidt Friedrich Dusseldorfer Str . 10 Schmidt Fritz Dusseldorfer Stral?e 10 ...

? •

Name Vorname Str_HNr

Schmidt Friedrich Dtisseldorfer Stral?e 10 ... .. .

Abbildung 31: Inhaltliche Homogenisierung von DatenbesUinden

Inhaltliche Widersprtiche in den als mehrfach vorhanden erkannten Datensatzen sind

dann in einem nachsten Schritt zu beseitigen. Hier miissen Prioritatsregeln verwendet

werden, in denen festgelegt ist, we1che Variante als richtig akzeptiert werden soIl.

Abbildung 31 zeigt ein einfaches Beispiel, bei dem jedoch ohne zusatzliche Informati

on nicht herleitbar ist, ob die durchgefiihrte Transformation sachlich richtig ist. Denk

bar ist hier die Verwendung einfacher, statischer Verfahren, die die als redundant er

kannten Datensatze nach verschiedenen Kriterien (z.B. Datenquelle, Erfassungsdatum)

in ihrer Glaubwiirdigkeit hierarchisieren und die jeweils hierarchisch hochste vorhan

dene Information als giiltig deklarieren. Ausgefeiltere Verfahren konnten aufgrund von

Haufigkeitsverteilungen wahrscheinlichere Varianten erkennen und bevorzugen oder

auch durch Hinzunahme externer Informationen die Zulassigkeit von Werten in den

Datenbanken prtifen. So lassen sich etwa verschiedene Schreibweisen von Adressen

durch StraBen- und Postleitzahlenverzeichnisse normieren und richtigstellen.


Der hier dargestellte Problembereich wird insbesondere bei der erstmaligen Ubernah

me von Datenbestanden in das Data Warehouse von Bedeutung sein. Dabei ist sofort

erkennbar, daB eine automatisierte Homogenisierung der verschiedenen Quellen sehr

groBe Anforderungen an die zu verwendende Software stellt. Es miissen anspruchs

volle Techniken zur Mustererkennung fiir diesen in der englischsprachigen Literatur

auch als "data cleansing" oder "data scrubbing" bezeichneten ProzeB verwendet wer

den.549 Ein m6glicher Ansatz zur Implementierung derartiger Verfahren liegt in der

Nutzung der Expertensystemtechnologie.550 Dariiber hinaus k6nnen statistische Ver

fahren verwendet werden, die anhand der Priifung vordefinierter Kriterien Wahr

scheinlichkeiten fiir die Zusammengeh6rigkeit von Daten bestimmen k6nnen.551 Ein

Zielkonflikt ist bei automatisierten Konsolidierungsversuchen erkennbar: Wenig er

folgreich sind diese, wenn der Vergleichsalgorithmus so "eng" ausgelegt ist, daB etwa

unterschiedliche Schreibweisen desselben Kunden nicht erkannt werden. Andererseits

diirfen aber auch nicht durch eine zu groBziigige Interpretation des Vergleichskriteri

urns inhaltlich falsche Konsolidierungen vorgenommen werden.

Auch ausgefeilte Analyseprogramme werden jedoch in diesem Zusammenhang die

Notwendigkeit eines gewissen Grades an manueller Interaktion nicht vermeiden k6n

nen. Daher wird das Ergebnis dieser Prozedur kein "fertiger" Datenbestand sein, son

dern eher einen Zwischenstand wiedergeben, in dem fragliche Faile zur Kliirung fiir

den Benutzer markiert sind.

1m Rahmen der regelmaBigen Aktualisierung des Data Warehouse werden diese Auf

gaben einen weniger breiten Raum einnehmen, da nicht mehr sehr groBe Mengen an

Anderungsdaten entstehen, wenn einmal ein integrierter und konsistenter Datenbestand

erstellt ist. Hier liegt es zudem nahe, die Ergebnisse der verschiedenen Reinigungs-,

Aufbereitungs- und Homogenisierungsschritte in die Quelldatenbestande zuriickzufiih

ren, urn so auch dort die Datenqualitat fiir die operativen Zwecke zu verbessern und

spatere Aktualisierungslaufe zu vereinfachen.552 Gegebenenfalls wird die Erkenntnis,

mangelhafte operative Datenbestande zu haben, auch ein AnlaB sein, etwa durch die

549

550

551

552

Vgl. Devlin (1997), S. 214; Inmon (1996), S. 117. Ein Beispiel fOr ein Expertensystem, das ahnliche Datensatze finden soli (wenn auch in einem anderen Problemumfeld), ist in Mertens (1998a), S. 69f., beschrieben. Vgl. Burch (1997), S. 82f. Strehlo (1996), S. 35, weist jedoch darauf hin, daB diese Moglichkeiten aus Grunden fehlender Ressourcen kaum genutzt wird. Weiterhin ist anzunehmen, daB divergierende Zustandigkeiten und Kompetenzen hier eine regelmaBige und effiziente Nutzung der durch die Transformation entstandenen Nutzenpotentiale erschweren werden.


Dberarbeitung der Benutzungsschnittstellen auf bessere Datenqualitat bei der Eingabe

hinzuwirken.553

4.3.2.6 Gesamtsicht

In den vorangegangenen Abschnitten wurden verschiedene Schritte der Transformation

operativer Daten fUr analytische Zwecke diskutiert. Diese verschiedenen Schritte besit

zen einen sehr interdependenten Charakter, und es erscheint auch nicht sinnvoll, pau

schal eine bestimmte Reihenfolge zu deren Abarbeitung festzulegen. Vielmehr wird

sich in Abhangigkeit von der konkreten Auspragung der Problemstellung eines An

wendungsfalles an ZweckmiiBigkeitsiiberlegungen orientieren, welche Schritte in wel

cher Reihenfolge durchzufUhren sind. Der GesamtprozeB wird in der folgenden

Abbildung 32 nochmals visualisiert.

Anzumerken bleibt, daB insbesondere die Schritte zur inhaltlichen Homogenisierung

der Daten und zur Anpassung der Modelle Aufgaben darstellen, bei denen die Grenzen

maschineller Verarbeitbarkeit erreicht werden.554 Hier werden insbesondere bei der

erstmaligen Dbernahme von Datenbestanden in ein Data Warehouse verstarkt Fahig

keiten zur Modellierung von Sachverhalten und zur Interpretation relevanter Elemente

der Wirklichkeit gefragt sein, die das Problemlosungsvermogen qualifizierter mensch

licher Bearbeiter voraussetzen. Dieser Umstand erklart zudem, daB, wie bereits er

wahnt, der TransformationsprozeB innerhalb eines Data Warehouse-Projekts als au

Berst ressourcenintensiv angesehen wird.

Aus dieser Erkenntnis lassen sich auch Implikationen fUr ein Vorgehensmodell fUr

Data Warehouse-Projekte ableiten. So darf der personelle und zeitliche Bearbeitungs

aufwand an dieser Stelle nicht unterschatzt werden.

553

554 Vgl. Devlin (1997), S. 214. Vgl. auch Brodie/Stonebraker (1995), S. 155ff.


1 Einfiigen der Daten in das OW I

* aD l "I I~ I -t=-=t-- f-='7.:-:t 1-:: 1"-",1-",::,,, I I ..

. .. , · · .. 1 ... ,.. ..... - .... ~- ... -..

1-1-·1-·1 - -f-=;::-t ::l 'l ,7'1 .? '" m-m ITTI] ..........., I·:: 1"-'"1-,,,::,- -I I •• , 1 _·

EIEI ... -v

.... ." - - ~ ~

-... .. _,,- I ''''1-''-' I .. · .... I "I '''"I' r-N-I~ I- I - - --,,- .- " .. p . -.. -

r "'1"'-1"-· T'''''' I" 1- 1 --..... III . ~ ~- -r :::1 :;~ I;;='~':: 1 ,::j :::'+ 1=- 1= 1

* I Extraktion der Daten I

Abbildung 32: Gesamtsicht des Umwandlungsprozesses

4.3.3 Aktivitaten auf Seiten der Zielumgebung

Der letzte Schritt im TransformationsprozeB besteht in der Erzeugung des Data Ware

house-Datenbestands aus den nach den obigen Schritten entstandenen Daten sowie aus

externen Werten und abgeleiteten, berechneten Werten. In einer sehr abstrakten Inter

pretation HiBt sich ein Data Warehouse als persistent vorgehaltener Datenbankview,

der sich auf die Quelldatenbanken bezieht, betrachten. Aus dieser Sichtweise sind in

der Literatur verschiedenene Ansatze zu finden, das Problem des Updates von Data

Warehouse-Datenbestanden unter unterschiedlichen Annahmen tiber die Verftigbarkeit

der Quelldatenbanken durch Algorithmen zu 16sen.555 Die Sichtweise des Data Ware-

555 Vgl. Zhuge/Garcia-MolinaiWiener (1998), Zhou et al. (1995a) und Huyn (1997a),


house als Datenbankview beinhaltet jedoch sehr restriktive Pramissen tiber die Basis

tabellen, denen hier nicht gefolgt werden soll.556

Zunachst werden daher verschiedene technische Strategien erortert, urn Daten in die

Data Warehouse-Datenbank zu tibernehmen, bevor in einem zweiten Schritt auf die

abgeleiteten Werte eingegangen wird.

4.3.3.1 Dateniibernahme

Die Aufgabe der Datentibernahme besteht im Einftigen der Daten, die mit Hilfe der in

den vorherigen Abschnitten erorterten Techniken aufbereitet wurden, in die Data Wa

rehouse-Datenbank. Sofern dem Data Warehouse ein relationales oder auch multidi

mensionales Datenbanksystem zugrundeliegt, kann der EinftigeprozeB tiber die ent

sprechende Datenmanipulationssprache des Zielsystems erfolgen. Dies setzt voraus,

daB die Werkzeuge, mit denen die Transformationsschritte durchgeftihrt werden, tiber

die entsprechenden Funktionen verftigen, die etwa ftir das Einftigen in ein relationales

Data Warehouse die entsprechenden SQL-Anweisungen erzeugen.

Besteht diese Moglichkeit nicht, weil das eigentliche Transformationstool keine aus

reichend engen Schnittstellen zu der Datenbank des Data Warehouse aufweist, konnen

die bei der Transformation erzeugten Daten von speziellen Importwerkzeugen der Data

Warehouse-Datenbank ge1esen werden,557 so daB der Einftigevorgang aus technischer

Sicht nur wenig problembehaftet erscheint. Unabhangig von diesen Fragen des techni

schen Datentransportes ist jedoch an dieser Stelle zu kliiren, we1che Funktionen noch

ausgeftihrt werden mtissen, damit im Data Warehouse ein vollstiindiger Datenbestand

entsteht. Der einfachste Fall liegt hier beim erstmaligen Bestticken des Data Ware

house vor. Es sind dabei lediglich die durch die vorhergehenden Schritte "veredelten"

Daten sowie eventuell aus diesen errechnete aggregierte Werte in die entsprechenden

Schemaobjekte der Data Warehouse-Datenbank einzuftigen. 1m Rahmen der dann im

Lebenszyklus folgenden regelmiiBigen Aktualisierungslaufe jedoch muB darauf ge

achtet werden, daB die bereits im Data Warehouse vorhandenen historischen Daten

556

557

Insbesondere werden bei diesen Ansatzen die zahlreichen Implikationen der Heterogenitat der Quellsysteme und die Notwendigkeit der Integration der Teildatenbestande weitgehend auBer acht gelassen, wahrend hier diese Aspekte einen sehr breiten Raum einnehmen. Fiir das Oracle-Datenbanksystem kommt z.B. der dazugehorende .. SQL *Loader" in Frage. V gl. Corey/Abbey (1997), S. 94ff.


nicht zerstCirt werden und daB nicht unmittelbar in den operativen Daten enthaltene

Werte im Data Warehouse weiterhin in konsistentem Zustand vorliegen.

Aufgrund dieser Uberlegungcn k6nnen verschiedene Datenbank-Grundoperationen

wie "EinfUgen" und "Aktualisieren" sowie einige Varianten dieser Grundoperationen

fUr die Anwcndungsfalle beim EinfUgen von Daten in ein Data Warehouse gepriift und

bewertet werden.558 Wo dies sinnvoll erscheint, dienen kleine Beispieie zur Illustrati

on.

- Einfiigen neuer Datensiitze (insert)

Das EinfUgen neuer Datensatze ist der Regelfall beim Aktualisieren des Data Ware

house. Es werden die sich aus der Fortschreibung der operativen Datenbestande entste

henden Daten den Schemaobjekten des Data Warehouse hinzugefUgt. So wird ein

Geschaftsvorfall, der einen Umsatz erzeugt, dazu fUhren, daB im Data Warehouse

Datensatze angelegt werden, die Details zu diesem Produktverkauf enthalten.

- Aktualisieren vorhandener Datensiitze (update)

1m Rahmen des Updates von Datensatzen werden bereits im Data Warehouse vorhan

dene Datensatze geandert, sofern im Rahmen des Aktualisierungslaufes dazu AnlaB

besteht. Enthait beispielsweise das Data Warehouse in bezug auf den Auftragsbestand

auch die Farbe der bestellten Produkte, so muB ein Update auch im Data Warehouse

erfolgen, wenn der Kunde seinen Farbwunsch andert.

Eine wichtige Eigenschaft der Update-Operation ist, daB die bisherigen Werte des

Datensatzes verlorengehen, sofern die Anderungen nicht zusatzlich protokolliert wer

den - dies fiihrt dann zu Insert-Operationen in den Protokolltabellen.

- Ersetzen vorhandener Datensiitze (replace)

Alternativ zu Update-Operationen k6nnen Datensatze auch ge16scht und mit den gean

derten Werten neu angelegt werden.559 Der Unterschied zum Update liegt in erster

Linie in technischen Aspekten. So ist die Kombination aus L6sch- und Anlegebefehl

558

559 V gl. Welch (1997), S. 189ff. Damit lassen sich automatische PrUfungen referentieller Integritat jedoch nicht mehr uneingeschrankt nutzen, da zwischen der Losch- und der Insert-Transaktion ein Zustand eintreten kann, der gegen diese Integritiitsbedingung verstoBt. Auch erscheint es notwendig, hier Funktionen zur Erzeugung von Schliisselwerten zu deaktivieren. Allerdings ist abzuwagen, ob diese integritatssichernden Elemente eines Datenbanksystems fUr die spezifischen Charakteristika einer Data Warehouse-Anwendung Uberhaupt relevant sind.

194 Funktionale und inhalt1iche Aspekte der Transformation

moglicherweise effizienter abzuwickeln als ein Update.560 Dagegen abzuwagen ist

jedoch der Aufwand zur Eingrenzung der zu loschenden Datensatze. Weiterhin werden

die bei Updates konsistenzsichernden Mechanismen des Datenbankverwaltungssy

stems umgangen.

- Ersetzen des Datenbestands (full replace)

Gegenstand dieser Vorgehensweise ist das vollstandige Neuerstellen des Data Ware

house-Datenbestands aus den operativen Daten im Rahmen eines Aktualisierungs

laufs.561 Sofern die Eingangsdaten in guter Qualitat vorliegen, erscheint dies als eine

Losung, die den Vorteil bietet, ohne ausgefeilte Updateprozeduren auf Objektebene

auszukommen. Es wird jedoch der Zeitraumbezug als wesentliche Eigenschaft des

Data Warehouse dahingehend vernachlassigt, als historische, aus den operativen Da

tenbestanden entfernte Daten auch nicht in das Data Warehouse iibernommen werden.

Der auf den ersten Blick naheliegende Ansatz, deshalb die Aufbewahrungsdauer der

Daten in den operativen Systemen zu verlangern, filhrt zu einer konzeptionell uner

wiinschten Vermischung der Aufgaben operativer und analyseorientierter Datenhal

tungssysteme und ist daher nicht als geeignet zu klassifizieren.562 Weiterhin sind tech

nische Grenzen erkennbar, wenn regelmaBig sehr groBe Datenbestande extrahiert und

zu einem Data Warehouse-Datenbestand aufbereitet werden sollen.

Bei der Auswahl der anzuwendenden Strategie zum Laden von Daten III das Data

Warehouse ist als gewichtige Restriktion auBerdem zu beachten, daB hier, zumindest

wenn keine ausgefeilten Update-Mechanismen angewendet werden, typischerweise

sehr groBe Datenvolumina bewegt werden miissen. Diese tibersteigen aufgrund der

Nutzungscharakteristik wesentlich die bei Ladevorgangen in operativen Datenbanken

anfallenden Mengen. Es werden, vor allem bei sequentiellen Ladevorgangen, dann

Ladezeiten benotigt, die tiber ein herkommliches, nachtliches "Offline-Fenster" weit

hinausgehen.563 Ftir diese Problematik erscheint die Verwendung parallelisierter Ver

fahren zum Laden der Datenbestande als ein moglicher Losungsansatz. 564

560

561

562

563

564

Vgl. Welch (1997), S. 196f. V gl. Abschnitt 4.3. \. Vgl. Welch (1997), S. 195. Vgl. Chaudhuri/Dayal (1997), S. 67. Dort wird von Ladezeiten gesprochen, die Gr6Benordnungen von mehreren Tagen und Wochen erreichen k6nnen. Einen Uberblick iiber Verfahren zur parallelisierten Bestiickung von Datenbanksystemen mit Daten geben Barclay et al. (1994).


Neben der beschriebenen technischen Schnittstelle zum Laden von Daten, die aus den

operativen Vorsystemen extrahiert wurden, sollte auch eine Benutzungsschnittstelle

vorhanden sein, die es erlaubt, externe Daten, die nicht automatisiert bereitgestellt

werden konnen, in das Data Warehouse einzupflegen. Dabei sind vielfaltige Formen

externer Informationen, die von Interesse sind, denkbar. Ais Beispiele seien ge

nannt 565

• Devisen- und Aktienkurse (die auch als Bewertungsbasis von Bedeutung sein kon

nen),

• Marktanalysen,

• Kreditausktinfte.

Charakteristisch ist, daB diese Daten durch eine Vielzahl von Quellen beschafft werden

und auf unterschiedlichen Medien und in sehr heterogenen Strukturen vorliegen. Teil

weise werden sich diese Daten an die Struktur des Data Warehouse anpassen lassen

und in dieses integriert werden konnen. In diesem Fall lassen sich die obigen Uberle

gungen zur Datenaufbereitung und -integration in das Data Warehouse analog verwen

den, da dann flir diese Prozesse kein grundlegender Unterschied zu den Daten aus

unternehmensinternen Quellen vorliegt.

Andere externe Daten werden jedoch in Strukturen und Formaten vorliegen, die sich

nicht problemlos in eine - relationale oder mehrdimensionale - Datenbank einpassen

lassen. Beispiele hierflir sind Bilder, Grafiken, nicht weiter strukturierte Texte oder

auch Video- oder Tondokumente. Soil deren Informationsgehalt nicht in die normalen

Datenbankstrukturen tibertragen werden, konnen diese Dokumenttypen digitalisiert als

separates Dokument oder auch im Ursprungszustand verwahrt werden.566 Enthalt das

Data Warehouse oder dessen Metadatenverwaltung einen Querverweis auf diese In

formationsquellen, sind diese flir den Nutzer leichter erschlieBbar, und die Entschei

dungstrager arbeiten mit der gleichen Datenbasis. Dieses Vorgehen erscheint effizien

ter und konsistenter als die tibliche Form der dezentralen Informationssuche und

-aufbereitung, die unterschiedliche Daten zu gleichen Sachverhalten erwarten laBt,567

565

566 567

Weitere Beispie1e und Quellen extemer Daten, die sich allerdings an amerikanischen Verha1tnissen orientieren, finden sich in Inmon (1996), S. 262ff. Vgl. Mucksch (1998), S. 132. V gl. Kaiser (1998), S. 453.


so daB auch hier ein Nutzen erkennbar ist, obwohl die genannten Dokumente nicht in

einer in das Data Warehouse integrierten Form vorliegen.568

4.3.3.2 Erzeugen abgeleiteter Werte

Aus der Charakteristik der mit einem Data Warehouse zu bearbeitenden Frage

stellungen ergibt sich, daB Daten mit niedrigerem Detaillierungsgrad (hoherer Granula

ritat) als der elementaren Transaktion benotigt werden.569 Aus den den operativen

Quellen entnommenen Daten sind also berechnete Werte zu ermitteln und zu spei

chern, damit diese bei entsprechenden Anfragen fertig voriiegen und die Anfragebear

beitung so performanter erfolgen kann.570 Damit sinkt also die Rechenlast auf dem

Data Warehouse-Server, da haufig nachgefragte Werte nur einmal berechnet wer

den.57l Die Ermittlung und Speicherung berechneter Werte wird als Aggregation,

Verdichtung oder auch Anreicherung bezeichnet.572 Als Bespiele fUr derartige berech

nete Werte konnen etwa genannt werden:

• Gesamt-Umsatzzahlen pro Produkt, Warengruppe oder geographischem Raum,

• Zeitreihenwerte wie Monats- oder kumulierte lahreswerte,

• Durchschnittswerte.

Diese Werte werden erstmalig berechnet, wenn das Data Warehouse mit seinem An

fangsdatenbestand bestiickt wird. Aus der Charakteristik der aggregierten Werte und

der zugrundeliegenden Berechnungsformein ergibt sich, daB die Werte neu berechnet

568

569

570

57l

572

Weitere Aspekte der Bedeutung externer Informationen im Data Warehouse beschreiben BarquinlPallerlEdelstein (1997), S. 15lf. V gl. Levin (1997), S. 59. Die Werte konnten auch innerhalb einer konkreten Anfrage berechnet werden, allerdings wird sich dadurch das Antwortzeitverhalten verschlechtern, so daB es zweckmaBig erscheint, haufig genutzte aggregierte Werte in berechneter Form abzuspeichern. Dieses ist ein weiterer Aspekt der Abkehr yom Wunsch nach normalisierter und redundanzarmer Datenhaltung. Durch die zumindest implizit mitgespeicherten Berechnungsformeln wird auch das Paradigma der Trennung von Daten und Verarbeitungslogik aufgehoben, vgl. KemperlFinger (1998), S. 73f. V gl. Edelstein (1997), S. 42. Dieser Effekt kann allerdings ins Gegenteil verkelut werden, wenn zu viele nicht benotigte Werte vorausberechnet werden, so daB hier eine sorgfaltige Planung erforderlich erscheint. Vgl. Kemper/Finger (1998), S. 72ff. Hier werden unter Verdichtung Summenbildungen innerhalb der Dimensionshierarchien verstanden, wah rend im Rahmen der Anreicherung Informationen z.B. auf Basis betriebswirtschaftlicher Kennzahlen ermittelt und gespeichert werden. Diese Unterscheidung soli hier nicht weiterverfolgt werden, da die funktionale Komplexitiit der Berechnungen fiir die hier zu diskutierenden Aspekte von untergeordneter Bedeutung ist.


werden mtissen, wenn das Data Warehouse aktualisiert wird. Daher mtissen diese

Berechnungsfunktionen bei Zugrundelegung des hier vorgestellten Schichtenmodells

zumindest flir die Updates im Data Warehouse implementiert sein. Ein wesentlicher

Bestandteil dieser Berechnungen sind vorhandene Werte, die im Data Warehouse

gespeichert sirrd. Sollten diese Berechnungen bereits in der vorgelagerten Schicht

durchgeflihrt werden, so mtiBten wesentliche Eingangsvariablen aus der Zielumgebung

in die Transformationskomponente "zuruckgeholt" werden, was nicht wtinschenswert

ist. 1m Sinne einer moglichst effizienten und konsistenten Verwaltung der Berech

nungsfunktionen ist es dann kaum sinnvoll, flir das erstmalige (idealtypisch einmalige)

Bestticken des Data Warehouse zusatzliche Funktionen zur Durchflihrung der Berech

nungen auBerhalb des Data Warehouse zu implementieren.

Die notwendigen Berechnungen ergeben sich aus dem Warehouse-Daten- und Funk

tionenmodell. Die technische Umsetzung kann z.B., wenn das Data Warehouse auf

einer relational en Datenbank basiert, tiber Datenbankprozeduren bzw. -funktionen oder

Trigger erfolgen, die durch den Ladevorgang angestoBen werden. Hierbei erweist sich

als vorteilhaft, daB SQL als die Standardsprache flir relationale Datenbanksysteme

tiber vordefinierte Funktionen verfligt, die gangige Aggregationsschritte durchflih

ren.573 Diese Vorgehensweise erlaubt es, die entsprechenden Berechnungsvorschriften

zentral in der Datenbank zu hinterlegen und durch die yom Datenbanksystem unter

sttitzte Programmiersprache zu implementieren.574

Sofern im Data Warehouse viele berechnete Werte vorgehalten werden, wird das Pro

blem der benotigten Verarbeitungszeit flir das Neuberechnen nach einem Update der

Data Warehouse-Datenbank relevant.575 Werden beispielsweise jede Nacht die aus den

operativen Systemen extrahierten Anderungsdaten transformiert und in das Data Wa

rehouse eingepfJegt, sind bis zur Wiederaufnahme des regularen Betriebes am folgen

den Arbeitstag auch die abgeleiteten Werte neu zu ermitteln. Bei groBen Datenbestan

den im Data Warehouse setzt dies eine ausreichend hohe Verarbeitungskapazitat der

573

574

575

So stellt beispie1sweise der SQL-Standard 1992 fUnf Aggregationsfunktionen bereit, u.a. von Summen und arithmetischen Mitteln. Herstellerspezifische SQL-Implementierungen erweitern den Standard vielfach urn statistische und finanzmathematische Funktionen, vgl. Gray et al. (1998), S. 556f. Hier werden dartiber hinaus zusatzliche Operatoren entwickelt, die mehrdimensionale Aggregationen erlauben. Oracle verwendet z.B. die Programmiersprache PLlSQL, bei der SQL urn die Elemente einer prozeduralen Programmiersprache erweitert wurde. V gl. Madsen (1996), S. 48f.


verwendeten Systemumgebung und vor allem effiziente Algorithmen voraus.576 Hier

wird angestrebt, diese Berechnungen inkrementell durchzuflihren, d.h. im wesentlichen

den alten aggregierten Wert und die Anderungsdaten zu nutzen. So laBt sich ein voll

standiges Verarbeiten der unter Umstanden sehr umfangreichen, gesamten Basisdaten

flir die aggregierten Werte vermeiden.577

Ein Sonderfall im Rahmen der Extraktion, Transformation und Integration von Daten

in Data Warehouse-Umgebungen liegt vor, wenn diese Operationen nicht nur zur Be

schaffung der Daten aus den operativen Systemen durchgeflihrt werden, sondern auch

zur Versorgung von datenspeichernden Komponenten, die dem Data Warehouse inner

halb des analyseorientierten Informations systems nachgelagert sind, dienen. Die be

sonderen Merkrnale dieser Anwendungsform werden im folgenden Abschnitt, wieder

urn anhand des Schichtenmodells, diskutiert.

4.4 Datentransformation zwischen Komponenten des analyseorientierten

Informationssystems

1m Rahmen der Gesamtarchitektur eines analyseorientierten Informationssystems ist

vorgesehen, Teilmengen des Datenbestands nochmals separat und redundant in soge

nannten Data Marts vorzuhalten.578 Damit ergibt sich auch an der Schnittstelle zwi

schen Data Warehouse und den Data Marts die Aufgabe, Daten zu replizieren. 1m

folgenden werden die im bisherigen Verlauf dieses Kapitels angestellten Oberlegungen

nochmals aufgegriffen und flir die nun vorliegende Aufgabenstellung erweitert.

Die grundlegende Charakteristik dieses Dateniibertragungsprozesses entspricht den

Oberlegungen, die im bisherigen Verlauf dieses Kapitels angestellt wurden: Auch hier

miissen Daten aus einer Quelle ausgewahlt, extrahiert, modifiziert und in eine Zielda

tenbank eingefligt werden. Charakterisierendes Merkrnal des Data Warehouse, das hier

576

577

578

Vgl. Ester/Wittmann (1998), S. 136. V gl. Huyn (I 997a), S. 27ff.; Ester/Wittmann (1998), S. 136. Die Relevanz dieses Aspektes zeigen Akinde/Jensen/Bohlen (1998), S. 296, anhand eines Zahlenbeispiels. V gl. hierzu auch Kimball (1996), S. 46f. Zu Details zum Architekturkonzept und zur Begrundung dieser Aufteilung vgl. Abschnitt 3.3. Hier wird der Fall zugrundegelegt, daB die Data Marts aus Komplexitatsreduktions- oder Performancegriinden Teilmengen eines existenten Data Warehouse reprasentieren. Der umgekehrte Fall, daB als Entwicklungsstrategie fUr eine Data Warehouse-Losung zunachst Data Marts erstellt und dann integriert werden (vgl. Behme (1996), S. 35), soli hier nicht verfolgt werden, da dann die Oberlegungen aus den vorhergehenden Abschnitten angewendet werden konnen.

Datentransformation zwischen Komponenten des analyseorientierten Informationssystems 199

nun als Datenquelle dient, ist jedoch, daB es bereits eine integrierte und homogene

Datenstruktur aufweist, so daB wesentliche Teile der oben dargestellten Problemberei

che an dieser Stelle nicht relevant werden. Weiterhin liegt der Gedanke nahe, daB die

Systemkomponenten der Data Warehouse-Datenbank und der Data Marts aufeinander

abgestimmt sein werden, wenn das Gesamtsystem zur analyseorientierten Datenhaltung

dient. Daher sind Schwierigkeiten, die sich aus der technischen HeterogeniUit der Teil

systeme ergeben, gleichfalls nicht zu erwarten. Es steigt jedoch durch die zusatzlichen

Modelle und Komponenten und den damit einhergehenden Koordinierungsbedarf die

Komplexitat des Gesamtsystems.S79

Der erste Schritt bei der Bestiickung eines Data Mart mit Werten besteht in der Ex

traktion der relevanten Daten aus dem Data Warehouse. Ais wesentliche Veranderung

in der Problemstruktur gegeniiber den bisherigen UberJegungen ist erkennbar, daB

lediglich eine Datenquelle verwendet wird. Dariiber hinaus ist der Zeitpunkt, zu dem

Updates flir die Data Marts anfallen, klar durch die Zyklen festgelegt, in denen das

Data Warehouse aktualisiert wird. Festzulegen ist im Zuge der Entwicklung der Data

Mart-Lasung jedoch, ob die durch die Updates am Data Warehouse vorgenommenen

Anderungen standardmaBig auch zur Aktualisierung der Data Marts flihren sollen und

somit das Data Warehouse zentralisiert auch die Datenversorgung der diesem nachge

ordneten Data Marts steuert, oder ob die Update-Laufe flir die Data Marts durch diese

autonom und nach eigenen Zyklen angestoBen werden. Diese Varianten kannen auch

als Push- bzw. Pull-Strategien bezeichnet werden.s8o

Einige UberJegungen sollen der zunehmenden Redundanz in der Datenhaltung des

Gesamtsystems und der daraus resultierenden Geflihrdung der Datenintegritat gelten.

Wenn ein Data Mart als redundanter Ausschnitt aus einem integrierten und konsisten

ten Data Warehouse definiert ist, sind die Datenbestande zunachst widerspruchsfrei.

Dies gilt jedoch nur, wenn im Data Warehouse und auch im Data Mart nur lesende

Zugriffe auf den Datenbestand zugelassen sind. Diese wichtige Eigenschaft der Wider

spruchsfreiheit der Daten geht verloren, wenn die Datenbestande nicht synchronisiert

werden. Sofern es nun wiinschenswert ist, daB das Data Warehouse und aile vorhande-

579

580 V gl. Strehlo (1996). S. 36. V gl. Devlin (1997). S. 248. Die dort angestellten Uberlegungen konnen tibertragen werden. obwohl dieser Autor eine andere Begriffsabgrenzung zwischen den verschiedenen Instanzen analyseorientierter Datenhaltung vomimmt.


nen Data Marts tiber konsistente Datenbestande verfiigen,581 ist zu fardern, daB die

Aktualisierung der Data Warehouse-Datenbank unmittelbar aueh Updates aller vor

handenen Data Marts auslost und analog zur Transaktionsverarbeitung in den operati

yen Systemen die Aktualisierung aller analyseorientierten Datenbestande als Einheit

betraehtet wird. Daraus ergibt sieh, daB die oben genannten Pull-Strategien, die ein

autonomes Aktualisieren der Data Marts mit Daten aus dem Data Warehouse vorsehen,

aus Konsistenzgesiehtspunkten weniger zweekmaBig sind als die Push-Strategien, bei

denen das Data Warehouse die naehgelagerten Datenspeieher aueh aktualisiert.582

Bei den Aktualisierungslaufen fiir die Data Marts bleibt die im Rahmen der Uberle

gungen zur Aktualisierung der Data Warehouse-Datenbank bereits erorterte Problema

tik der Erkennung geanderter Daten bestehen. Die dart genannten versehiedenen Al

ternativen sind im Grundsatz aueh an dieser Stelle giiltig, allerdings soli ten sie auf

grund der veranderten Problemparameter anders bewertet werden. Zeitstempel

gesteuerte Update-Verfahren bieten sieh insofern an, als - eher als bei den operativen

Datenquellen des Data Warehouse - die entspreehenden Zeitinformationen ohnehin

vorhanden sein werden und somit ohne weitere Veranderungen in den Datenquellen

aueh ausgewertet werden konnen. Als weitere mogliehe Vorgehensweise bietet sieh

das genannte bulk eopy-Verfahren an, naeh dem im Rahmen der Aktualisierung die

Data Mart-Datenbank aus den Data Warehouse-Daten komplett neu gefiillt wird, in

dem aile Daten, die im Data Mart enthalten sein sollen, aus dem Data Warehouse

tibertragen und samtliehe abgeleiteten Werte neu bereehnet werden. Hier gewinnt

dieser Ansatz im Vergleieh zur Aktualisierung des Data Warehouse aus den operativen

Daten an Attraktivitat. Einerseits ist hier das genannte Problem des Verlustes alterer

Daten aufgrund der Charakteristik des als Datenquelle fungierenden Data Warehouse

nieht gegeben, da aueh dieses Zeitreihen und damit die alteren Daten enthalt. Weiter

hin wird ein Data Mart typiseherweise einen eher kleinen Datenbestand enthalten, der

sieh mit akzeptabler Ressoureenbelastung aus dem Data Warehouse extrahieren und

tibertragen laBt. SehlieBlieh ist zu prtifen, ob nieht ohnehin wesentliehe Teile des Data

581

582

Dies ist regelmiiBig der Fall, weil nur so sichergestellt ist, daB Auswertungen, die auf verschiedenen Data Marts basieren, miteinander vergleichbare Ergebnisse liefern und die Bereitstellung unternehmensweit einheitlicher entscheidungsrelevanter Daten zu den Kerngedanken des Data Warehouse-Konzepts ziihlt. Ais allgemeines Problem erscheint in diesem Zusammenhang, daB Aktualisierungsliiufe dazu flihren, daB einmal erzeugte Analyseergebnisse moglicherweise nicht mehr nachvollziehbar sind, da hier die hiiufig als Vorteil einer Data Warehouse-Losung angesehene Eigenschaft der Nicht-Volatilitiit des Data Warehouse durchbrochen wird.

Datentransformation zwischen Komponenten des analyseorientierten Informationssystems 20 I

Mart aus berechneten Werten bestehen, die bei AktualisierungsUiufen neu erzeugt

werden mtissen, so daB ausgefeiltere Vorgehensweisen zur Aktualisierung nur wenig

Nutzen briichten.583 Die weiteren genannten Techniken zur Extraktion der Anderungs

daten bieten sich hier weniger an, da bei deren Verwendung die Notwendigkeit ent

sttinde, die entsprechende Funktionslogik zu implementieren, ohne daB im Vergleich

zu den vorgenannten, einfacheren Verfahren hier Vorteile erkennbar waren.

Als weitere Variante zur Population und Aktualisierung von Data Marts kann auch in

Erwiigung gezogen werden, die aus den operativen Systemen extrahierten und trans

formierten Werte nicht nur in die Data Warehouse-Datenbank, sondern zusiitzlich auch

unmittelbar in die Data Marts einzufligen (Abbildung 33, rechte Seite). Diese Gestal

tungsform der Datenversorgung flir Data Marts impliziert dann, daB die extrahierten

Daten mehreren Zieldatenbanken zur Verftigung gestellt werden. Hier ist auf den er

sten Blick der Vorteil erkennbar, daB zur Population der Data Marts der Umweg tiber

das Data Warehouse gespart wird. Somit konnen parallel die Daten in das Data Ware

house und in die Data Marts importiert werden, so daB potentiell das benotigte Zeitfen

ster zur Datenpflege flir die analytischen Informationssysteme kleiner wird. Insbeson

dere die Verftigbarkeit des Data Warehouse steigt, da sich an die Importprozeduren

nicht noch die Exporte flir die Data Marts anschlieBen mtissen. Es sind jedoch auch

gravierende Nachteile dieses Gedankens erkennbar. Oben wurde erliiutert, daB die

Datentransformation flir die analyseorientierten Informationssysteme ein komplexes

Problem darstellt, insbesondere wenn verschiedene, heterogene und teilweise disjunkte

Datenquellen integriert werden sollen. 1st es nun erforderlich, verschiedene Zieldaten

banken jeweils mit Teilmengen der Datenextrake zu bestticken, steigt die Komplexitiit

dieser Aufgabe weiter an. Hier ist dann jeweils noch zu steuern, welche Daten in die

einzelnen Data Marts einflieBen sollen und (bei tatsiichlicher Parallelverarbeitung) sind

Koordinationsmechanismen zum gleichzeitigen Bestticken der unterschiedlichen

Zieldatenbanken zu implementieren. Je nach der systemtechnischen Ausgestaltung der

entsprechenden Funktionen werden zudem die operativen Systeme starker in Anspruch

genommen als bei einer Vorgehensweise, welche die Data Marts auf der Basis des

Data Warehouse besttickt. Dies ist der Fall, wenn auch die Extraktion der Daten flir die

583 Devlin (1997), S. 250ff., unterscheidet vier Methoden zur Aktualisierung nachgelagerter analyseorientierter Datenbestiinde ("Business Information Warehouse", S. 223ff.). Neben der kompletten Neuerzeugung des Datenbestands unterscheiden sich die verbleibenden drei Varianten in der exakten Ausgestaltung der Update-Operationen, insbesondere in der Behandlung veriinderter Datensiitze.


einzelnen Zieldatenbestande separat und, zumindest im FaIle von Uberlappungen, auch

wiederholt erfolgt. Dieser Aspekt ist insbesondere dann von Bedeutung, wenn das

Zeitfenster, das bei den operativen Systemen fUr Zugriffe verfiigbar ist, die auBerhalb

des normalen Betriebes erfolgen, ohnehin klein oder auch durch andere Systempflege

prozesse belegt ist.

Insgesamt scheint hier die Abwagung der Vor- und Nachteile zugunsten der sequenti

ellen Bestiickung (Abbildung 33, linke Seite) von Data Warehouse und Data Marts

auszugehen.

Front-End-Werkzeuge

Updates

Transformationskomponente

Zentrale

Dezentrale Data Marts

Data Warehouse-Datenbank

Updates

Transformationskomponente

Abbildung 33: Alternative Konzepte zur Data Mart-Population584

Die in den AusfUhrungen zur Transformation der Daten aus den operativen Systemen

als komplex klassifizierten Schritte zur Erzeugung eines homogenen und integrierten

Datenbestands sind bei der Ableitung von Data Mart-Datenbestanden aus dem Data

Warehouse iiberwiegend nicht relevant, da eben diese Schritte bereits erledigt sind. Es

verbleibt moglicherweise, in Abhangigkeit von der konkreten Ausgestaltung der Sy

sterne, die Notwendigkeit zur Modelltransformation. Eine entsprechende Umsetzung

584 Die Komponente der Metadatenverwaltung (vgl. Abbildung 14) ist in dieser Grafik iediglich zur Wah rung der Ubersichtlichkeit nicht enthalten.

Datentransformation zwischen Komponenten des analyseorientierten Informationssystems 203

ist etwa erforderlich, wenn Daten aus einem auf einem relationalen Datenbanksystem

basierenden Data Warehouse in einen Data Mart iiberfiihrt werden sollen, dem eine

multidimensionale Datenbank zugrundeliegt. Das Herstellen der entsprechenden Ver

kniipfungen erscheint jedoch auch in dies en Fallen nicht als sehr problematisch. Ent

sprechende Werkzeuge, die dies unterstiitzen und sogar den fallweisen Durchgriff des

Data Mart-Anwenders auf die Datenbestande des Data Warehouse ermoglichen, sind

auf dem Markt erhaltlich und Bestandteil der kommerziellen Data Mart

Entwicklungsumgebungen, die auf einem mehrdimensionalen Datenmodell basieren.

Beide Datenbestande beruhen dann auf demselben semantischen Datenmodell,585 so

daB auch in dieser Hinsicht (zumindest theoretisch) keine Probleme zu erwarten sind.

Ein letzter wesentlicher Schritt beim Aufbau des Data Mart-Datenbestands besteht in

der Erzeugung abgeleiteter Werte, die im Data Warehouse nicht enthalten sind.586

Hierfiir werden die bereits beschriebenen Aggregations- und Erganzungsfunktionen

verwendet. Je nach konkreter Ausgestaltung des Gesamtsystems sind im Data Mart

gegebenenfalls auch zu bestimmten Sachverhalten nur aggregierte Werte, nicht aber

die Detailwerte enthalten. Der durch die Aggregation entstehende Informationsver

lust587 ist hier nicht weiter bedeutsam, da bei Bedarf die Detaildaten durch einen

Riickgriff auf das Data Warehouse ermittelt werden konnen.588

Zusammenfassend kann festgehalten werden, daB die Datentransformation innerhalb

des Analysesystems einen deutlich geringeren Komplexitatsgrad aufweist als die

Ubernahme der Daten aus den operativen Vorsystemen. Der hierfiir wesentliche Ge

sichtspunkt ist, daB an dieser Stelle der ProzeB der Modellierung und Erzeugung eines

integrierten Gesamtdatenbestands bereits abgeschlossen ist. Als neues Problem tritt

jedoch hinzu, daB in einer Systemstruktur mit einem Data Warehouse und mehreren

Data Marts auch die analyserelevanten Daten mehrfach redundant gehalten werden.

Hier ist zu fordern, daB durch koordinierte Replikationsvorgange die Einheitlichkeit

des Datenmaterials sichergestellt wird.

Sofern den Anwendern gestattet wird, auf die Data Marts auch schreibend zuzugreifen,

ist weiterhin dafiir Sorge zu tragen, daB auch im Rahmen von Updatelaufen die so

585

586 587

588

Vgl. Mucksch (1998), S. 126. V gl. Devlin (1997), S. 257ff. Vgl. Ijiri (1967), S. 120; Sorter (1969), S. 14; HavelkaiKhazanchi (1994), S. 73. Dies kann auch "transparent" geschehen, d.h. ohne daB der Benutzer merkt, daB er nun seinen Data Mart verlaBt. Damit kommen auch hier Konzepte der Architektur verteilter bzw. fOderierter Datenbanksysteme zum Einsatz, wie sie in Abschnitt 2.3.3 beschrieben wurden.


entstandenen Daten in konsistenzerhaltender Weise behandelt werden, gegebenenfalls

sind sie in die anderen Analysedatenbestande zu replizieren. Dieser Fragestellung wird

hier jedoch nicht weiter nachgegangen, da in den derzeit verfolgten Konzepten analy

seorientierter Datenhaltung schreibende Zugriffe durch die Anwender ohnehin kaum

vorgesehen und nur wenige ziel- und anwendungsbezogen sinnvolle Auf

gabenstellungen daftir denkbar sind. AuBerdem handelt es sich hierbei auch in erster

Linie urn eine organisatorische Frage, und die Behandlung der durch die Anwender

erzeugten Daten wird kaum Probleme aufwerfen, wenn diese ordnungsgemaB doku

mentiert werden. Die Dokumentation jedoch ergibt sich beinahe implizit schon da

durch, daB den Anwendern die entsprechenden Schreibrechte erteilt werden mlissen.

4.5 Schlu8folgerungen

In den vorangegangenen Kapiteln wurde diskutiert, welche Schritte im einze1nen bei

der Transformation operativer Daten flir ein analyseorientiertes Informationssystem

durchzuftihren sind. Dabei wurde gezeigt, daB zumindest unter der Annahme heteroge

ner und "unsauberer" Datenbestande in den Vorsystemen eine ganze Reihe von Funk

tionen notwendig sind, welche die teilweise nicht-trivialen Umwandlungsschritte

durchflihren. Diese Annahme, daB die operativen Datenbestande keineswegs in inte

grierter und konsistenter Form vorliegen, wird in der Literatur immer wieder als Regel

fall in der Praxis bezeichnet, so daB davon ausgegangen werden kann, daB es sich hier

urn relevante Fragestellungen handelt.

Flir die genannten Umwandlungsschritte konnen jeweils einzelne Werkzeuge verwen

det werden, die - selbsterstellt oder als standardisierte Software gekauft - einen Teil

dieser Funktionen abarbeiten. Damit steigt jedoch der Verwaltungsaufwand erheblich,

so daB es zweckmaBiger erscheint, aIle benotigten Funktionen in eine Gesamtarchi

tektur einzubetten, die als Middleware-Schicht zwischen den operativen und den ana

lyseorientierten Informationssystemen angesiedelt wird. Standardisierte Schnittstellen

zu den angeschlossenen Informationssystemen, ein breiter Funktionsumfang und eine

leistungsfahige Metadatenkomponente als zentrale Verwaltungsinstanz sind hier als

Voraussetzungen ftir eine flexible und effiziente Datenlibernahme zu fordern.

Innerhalb der Gesamtarchitektur eines analyseorientierten Informationssystems sind

die Komponenten zur Versorgung des Data Warehouse mit Daten aus den operativen

Vorsystemen erfolgskritische Bausteine, da nur mit qualitativ hochwertigen Daten die

SchluBfolgerungen 205

Ziele erreicht werden konnen, die mit dem Aufbau solcher Systeme verfolgt werden.

Gleichzeitig wird immer wieder betont, daB die Aufbereitung der operativen Daten

vielfach die groBte Aufgabe innerhalb eines Data Warehouse-Projekts ist und zudem

erheblichen Anteil an den Gesamtkosten hat.

Wahrend Aspekte der Modellierung von Data Warehouse-Datenbanken sowie der

Auspragungen der Endbenutzerwerkzeuge vielfach Gegenstand der Diskussion sind,

werden Fragen der Datenversorgung bisher vorrangig aus einer Sichtweise betrachtet,

die Fragen der Synchronisation verteilter Datenbestande in den Mittelpunkt stellt, die

inhaltliche ZusammenfUhrung heterogener und sich iiberlappender Daten jedoch weni

ger beriicksichtigt.

Es erscheint jedoch lohnenswert, bei der Planung eines Data Warehouse-Projekts nicht

nur der angestrebten Funktionalitat des analyseorientierten Informationssystems und

den dafUr benotigten Endbenutzer-Softwareprodukten hohe Aufmerksarnkeit zu wid

men, sondern auch die Fragen der Datenversorgung systematisch und planvoll zu be

antworten.

Daher wird im folgenden Kapitel ein Lebenszyklusmodell fUr den Aufbau und den

Betrieb eines analyseorientierten Informationssystems entwickelt, welches es erlaubt,

fUr die einzelnen Phasen jeweils charakteristische Eigenschaften zu definieren, die fiir

Komponenten zur Datentransformation bedeutsam erscheinen.

Anforderungen an die Transformationskomponente

5 Anforderungen an die Transformationskomponente im Rahmen der Entwicklung und Nutzung eines analyseorientierten Informationssystems

207

1m vorhergehenden Kapitel wurde eine Vielzahl von Einzelaspekten diskutiert, die bei

der Transformation von Daten aus operativen Systemen flir die Datenbank analyseori

entierter Informationssysteme zu beach ten sind. Der Schwerpunkt betraf dabei die

Frage, wie die relevanten Daten flir das Data Warehouse aus den operativen Datenbe

standen extrahiert werden konnen und we1che Transformationsschritte zur Reinigung

sowie zur strukturellen und inhaltlichen Anpassung der Daten erforderlich sind, bevor

diese in den Data Warehouse-Datenbestand integriert werden.

Die Reihenfolge, in der die beschriebenen Transformationsschritte ablaufen mtissen,

IaBt sich modellhaft nur sehr grob umreiBen. So erscheint es insbesondere dann, wenn

mehrere Quellsysteme in die Betrachtung einbezogen werden sollen, nicht pauschal

festlegbar, wie die einzelnen Schritte und die Integration der Teildatenbestande syn

chronisiert werden sollen.

Ftir die Durchflihrung dieser Aufgaben werden Softwarewerkzeuge eingesetzt, we1che

die entsprechenden Prozesse teilweise automatisieren konnen. 1m folgenden sollen nun

Anforderungen formuliert und diskutiert werden, die tiber die Moglichkeit zur Adres

sierung der genannten Aufgabenstellung hinaus von derartigen Werkzeugen erflillt

werden soil ten, damit diese erfolgreich im Gesamtzusammenhang des Aufbaus sowie

der Einflihrung und Nutzung eines analyseorientierten Informationssystems eingesetzt

werden konnen. Sie erganzen und spezifizieren die Anforderungen, die gemeinhin an

Software gestellt werden und tiber deren Erflillung eine hohe Qualitat des entwickelten

Programms gewahrleistet werden soli. Haufig in diesem Zusammenhang genannte

Merkmale sind beispielsweise Korrektheit, Robustheit, Erweiterbarkeit, Wiederbe

nutzbarkeit, Kompatibilitat, Effizienz, Portabilitat und Benutzungsfreundlichkeit.589

Die Prioritaten, unter denen die einzelnen Punkte eines problemspezifischen Anforde

rungskataloges gesehen werden konnen, verschieben sich im Veri auf der Entwicklung

einer Data Warehouse-Losung von der Projektplanung bis zur Phase des Einsatzes und

der Wartung dieses Systems. Daher wird in dies em Kapitel als Strukturierungsrahmen

589 Vgl. zu diesen Merkmalen z.B. Mayer (1997), S. 3ff.

208 Anforderungen an die Transformationskomponente

ein einfaches Lebenszykiusmodell590 filr ein solches analyseorientiertes Informations

system gewiihlt.

1m folgenden Abschnitt 5.1 wird zunachst begrundet, warum herkommliche, sequenti

elle Vorgehensmodelle filr die Entwicklung von Softwaresystemen filr den Aufbau

eines analyseorientierten Informationssystems nicht als geeignet erscheinen. In Ab

schnitt 5.2 wird daher auf prototyping-orientierte Ansatze zuruckgegriffen, urn die

Entwicklungsschritte zu beschreiben. Daraus lassen sich Riickschliisse auf die Werte

der Parameter "Datenvolumen" und "Nutzerzahl" ableiten, durch die die Phasen des

Lebenszyklusmodells beschrieben werden konnen (Abschnitt 5.2.3).

Die Anforderungen, die an die Komponenten des Data Warehouse und insbesondere

der Transformationskomponente zu stellen sind, verschieben sich im Verlauf dieses

Lebenszyklus. Daher werden in Abschnitt 5.4 filr die zuvor beschriebenen Phasen

Anforderungen diskutiert, die als jeweils besonders relevant gelten konnen.

Diese Anforderungen sind zueinander nicht widerspruchsfrei. Konflikte, die sich erge

ben konnen, und Losungsansatze hierzu werden zum SchluB des Kapitels in Abschnitt

5.5 aufgezeigt.

5.1 Besonderheiten bei der Entwicklung von Komponenten fur analyse

orientierte Informationssysteme

Fiir die Entwicklung und den Aufbau von Software-Systemen werden im Rahmen des

Software Engineering die bereits im zweiten Kapitel beschriebenen Vorgehensmodelle

angewendet. Die operativen Systeme, deren Charakteristik Grundlage des Entwurfs der

590 Vnter einem Lebenszyklus wird ein Konzept verstanden, das davon ausgeht, daB die Entwicklung eines Objektes im Zeitablauf in charakteristische Phasen unterteilt werden kann. Zeitreihen der Ausprligungen wichtiger Merkmale dieses Objektes ergeben idealisiert vielfach glokkenfOrmige Kurven. So wird z.B. von Produktlebenszyklen gesprochen, die sich tiber Zeitreihen der GraBen "Absatzmenge" und "Sttickgewinn" beschreiben lassen. Vgl. zu diesem Konzept z.B. Gabler Wirtschaftslexikon (1997), S. 2422f. In Analogie zum biologischen Lebenszyklus ist immer auch eine degenerative Phase Bestandteil solcher Konzepte. Diese wird im Zusammenhang mit dem "Data Warehouse-Lebenszyklus" im folgenden nicht betrachtet, da (optimistisch) davon ausgegangen wird, daB sich das Data Warehouse als Konzept zu einem festen, sich mit zunehmender Reife immer weiter etablierenden Instrument betrieblicher Informationsversorgung entwickelt. Auf den Begriff des Software-Lebenszyklus (vgl. Abschnitt 2.1.3, phasenorientierte Modelle) wird hier dagegen nicht zuriickgegriffen, weil dieser ftir ein streng sequentielles Vorgehen belegt ist (vgl. Hansen (1996), S. 137).

Besonderheiten bei der Entwicklung 209

verschiedenen Vorgehensmodelle war, unterscheiden sich jedoch hinsichtlich der Aus

gangssituation und der Entwicklungsziele deutlich von den analyseorientierten Syste

men. Wahrend die Entwicklung eines operativen Systems mit der Erkenntnis eines

Problems und der Definition daraus resultierender Anforderungen beginnt und mit

einem lauffahigen Anwendungsprogramm endet, das dann tiber einen langeren Zeit

raum ohne groBe Modifikationen eingesetzt werden kann, beginnt ein Data Ware

house-Projekt mit Daten und endet mit Benutzeranforderungen.59 ! Diese etwas plaka

tive Beschreibung drtickt aus, daB ein Data Warehouse - im Gegensatz zu einem ope

rativen System - permanent an die wechselnden inhaltlichen Anforderungen angepaBt

werden muB und so ein hohes MaB an Flexibilitat erforderlich ist. Wechselnde Anfor

derungen entstehen dabei zum einen aus dem dynamischen Umfeld, in dem die Ent

scheider als Nutzer entsprechender Informationssysteme agieren und das durch sich

andernde Informationsbedarfe manifest wird. Andererseits mag auch hier die alte

Weisheit gelten, daB sich jedes Angebot seine Nachfrage schafft, so daB mit zuneh

mender Erfahrung mit einem modernen analyseorientierten Informationssystem und

den Moglichkeiten, die es bietet, auch das Bedtirfnis nach zusatzlichen Funktionen und

Themenbereichen entsteht.

Die phasenorientierten Modelle mit ihrem sequentiellen Charakter, die sich zwar eines

fortgeschrittenen Diskussionsstandes in der Literatur und auch eines breiten Einsatzes

in der Praxis erfreuen, erscheinen daher jedoch ftir die Entwicklung eines analyse

orientierten Informationssystems auf der Basis eines Data Warehouse als alleinige

methodische Grundlage nicht ausreichend. Gegen ein Vorgehen nach einem solchen

herkommlichen Modell, das zunachst die Entwicklung eines voll funktionalen Systems

und erst dann des sen Einftihrung vorsieht, lassen sich weitere Grtinde anftihren.

Der Aufbau eines Data Warehouse und damit die Zusammenftihrung heterogener Sy

sterne stellt ein komplexes Problem dar, das zu entsprechend lang en Projektlaufzeiten

ftihren kann. Allgemein kann an groBen, lang laufenden DV-Projekten z.B. kritisiert

werden, daB hohe Kosten bereits eintreten, lange bevor ein Erfolg des Projekts erkenn

bar ist, und daB sich organisatorische Probleme durch lange Projektlaufzeiten verschar

fen.592 Bezogen auf den Aufbau eines analyseorientierten Informationssystems lassen

sich diese Problembereiche konkretisieren.

59! 592

"DSS processing begins with data and ends with requirements." Inmon (1996), S. 291. Vgl. zu Problemen beim Management von Softwareentwicklungsprojekten z.B. Brack/Koppe (1990), S. 304f.


• Aufgrund der relativen Neuheit der Data Warehouse-Thematik, insbesondere bei

Projekten, die nur mit unternehmensinternen Mitarbeitern durchgeflihrt werden,

kann tiblicherweise nicht auf eine breite Erfahrungsbasis in bezug auf die Spezifika

der hier vorliegenden Aufgabenstellung zuruckgegriffen werden.593 Insbesondere

die Integration zahlreicher, bis dahin getrennt betriebener Komponenten beschert

Probleme. Zum einen fehlt es an Erfahrungswissen flir die Integrationsproblematik

seiber, zum anderen ist es insbesondere gegentiber sonstigen DV -Projekten notwen

dig, auch innerhalb der DV-Abteilung bis dahin getrennte Zustandigkeiten flir die

unterschiedlichen Systeme zu tiberwinden. Die Integrationsproblematik erfahrt eine

zusatzliche organisatorische Dimension innerhalb der DV -Abteilung selbst.

• Der angestrebte Nutzen des Produktes laBt sich noch schwerer als bei einer operati

ven Anwendung quantifizieren: Letztere dient der Abbildung bestimmter, konkret

benennbarer und beschreibbarer Funktionen. Ein Data Warehouse hat dagegen

hauptsachlich die bessere Fundierung von Entscheidungen zum Ziel. Es entfaltet ei

nen Nutzen primar langerfristig tiber die Wirkung dieser Entscheidungen. Eine Be

wertung des Projekts tiber die Messung von WirtschaftlichkeitsgraBen fallt daher

sehr schwer.

• Auch die fehlende aktive Beteiligung der Fachanwender im Entwicklungsverlauf

erscheint problematisch. Die Angst vor dem Verlust wahrgenommener oder tatsach

lich bestehender Wissensmonopole kann den Projekterfolg dann in Frage stellen,

wenn dies zu mangelnder Akzeptanz des fertigen Systems oder gar zu Abwehrreak

tionen in der Unternehmensorganisation flihrt.

• SchlieBlich bergen die langen Projektlaufzeiten im Kontext analyseorientierter In

formationssysteme noch ein spezielles Problem: Sie lassen sich nur schwer mit dem

sich im Laufe der Zeit - analog zu der einem steten AnpassungsprozeB ausgesetzten

Geschaftstatigkeit - wandelnden Informationsbedarf in Einklang bringen. Je mehr

Zeit zwischen Anforderungsdefinition und Einflihrung des Data Warehouse vergeht,

desto haher ist die Wahrscheinlichkeit, daB unmittelbar nach der Einflihrung die

Notwendigkeit von Modifikationen erkennbar wird. Da kurzfristig nach der Anfor

derungsdefinition mangels eines Prototypen auch keine praxisbezogene Kontrolle

stattfinden kann, besteht die Gefahr, an den Bedtirfnissen der Nutzer vorbeizuplanen

und zu viele oder falsch ausgewahlte Daten in die Betrachtung einzubeziehen.

593 Vgl. Fiiting (1998), S. 338.

Vorgehen bei der Data Warehouse-Entwicklung 211

• Eine herkommliche Vorgehensweise laBt zudem die Gefahr erkennen, daB ein zu

starres entscheidungsunterstiitzendes System entsteht, das einer Verfestigung vor

handener Strukturen im Unternehmen Vorschub lei stet, anstatt Flexibilitat durch

leichte AnpaBbarkeit zu unterstiitzen.

Diese Problembereiche verschlirfen die bei langeren DV-Projekten ohnehin vorhande

ne Gefahr, daB ein solches Projekt eingestellt wird, etwa weil es aufgrund unter

schatzter Komplexitat zu Zeit- und Budgetiiberschreitungen kommt oder wei I durch

geanderte Prioritaten die Unterstiitzung fUr das Projekt im Unternehmen verlorengeht.

Ein festes Vorgehen, wie es durch die sequentiellen Modelle vorgegeben wird, er

scheint aus diesen Griinden nicht geeignet, eine Entwicklung hoher Komplexitat in

einem sich schnell wandelnden Umfeld durchzufUhren. Daher legen es diese Uberle

gungen nahe, eine Vorgehensweise in kleineren Schritten zu wahlen, urn so der Dyna

mik im Umfeld des Projekts, den technischen Problemen, den verschiedenen Aspekten

der Unternehmenspolitik und der Budgetierung sowie nicht zuletzt der Akzeptanzpro

blematik Rechnung zu tragen. Eine solche Vorgehensweise wird im folgenden be

schrieben.

S.2 Vorgehen bei der Data Warehouse-Entwicklung

In der Literatur findet sich eine Vielzahl von Vorgehensmodellen fUr Data Warehouse

Projekte.594 Sie zeigen gewisse A.hnlichkeiten zu den herkommlichen Modellen. So gilt

insbesondere die grundsatzliche Vorgehensweise in einer Reihenfolge Analyse - De

sign - Implementierung, die sich wohl auf jede Informationssystementwicklung an

wenden laBt, auch hier. Es werden jedoch aufgrund der beschriebenen Nachteile einer

rein sequentiellen Strategie iterative Elemente einbezogen, so daB cine Vorgehenswei

se entsteht, die A.hnlichkeit mit prototyping-orientierten Ansatzen, insbesondere mit

dem beschriebenen Spiralmodell, aufweist.595 Auf diese Weise lassen sich bereits nach

kurzer Projektlaufzeit konkrete Ergebnisse erzielen, die auch fUr die Anwender und die

Budgetverantwortlichen erkennbar sind. Als typischer Zeitraum bis zur Bereitstellung

eines nutzbaren Ergebnisses werden Zeiten von einigen Wochen bis zu wenigen Mo

naten genannt, wobei auch die nachfolgenden Schritte nach ahnlichen Zeitraumen

594

595

Vgl. z.B. Mattison (1996), S. 46ff.; AnahorylMurray (1997), S. 28ff.; W.-R. Hansen (1998), S. 326ff.; WeberlStriingmann (1997), S. 34; Ladley (1997), S. 102ff.; Levin (1997), S. 74ff. V gl. zu den genannten Vorgehensmodellen Abschnitt 2.1.3.


wiederum eine Erweiterung oder Verbesserung bringen sollen.596 Hierbei mag eine

Rolle spielen, daB die beschriebenen Vorgehensweisen haufig aus dem Umfeld von

Produktanbietern oder Unternehmensberatern stammen. Es ist leicht nachvollziehbar,

daB hier das Erreichen kurzfristig sichtbarer Ergebnisse ein wichtiges Kriterium fUr die

Auswahl einer Entwicklungsstrategie ist.

Eine einheitliche Benennung der zu durchlaufenden Entwicklungsphasen ist in der

Literatur genausowenig vorzufinden wie ein breit anerkanntes Vorgehensmodell, das

einen allgemeinen Rahmen fUr Data Warehouse-Projekte liefert. 1m folgenden werden

daher die charakteristischen Entwicklungsschritte identifiziert und beschrieben. Die

Bestandteile lassen sich inhaltlich in den verschiedenen Ansatzen zu dieser Thematik

wiederfinden. Unterschiede sind jedoch in den Bezeichnungen der Phasen vorhanden,

ebenso wie Differenzen hinsichtlich der Abgrenzungen der Phasen zueinander erkenn

bar sind. Der Schwerpunkt der Betrachtung liegt hier auf den Aspekten, die fUr die

Transformation operativer Daten von Bedeutung sind. Dies fUhrt nicht zu einer unzu

lassigen Einengung des Betrachtungsfeldes, da diese Thematik ohnehin einen ganz

wesentlichen Teil des Gesamtproblems ausmacht.

Zunachst werden Uberlegungen zur Projektplanung im Kontext eines Data Warehouse

Projekts angestellt. Betont wird dabei auch die besondere Bedeutung der fortdauernden

Akzeptanz des Projekts bei den spateren Anwendern und den Budgetverantwortlichen.

In Abschnitt 5.2.2 wird dann auf die Umsetzungs- und EinfUhrungsschritte eingegan

gen.

5.2.1 Planung und Entwurf

Eine sorgfaltige Planung des Projekts stellt eine wesentliche Bedingung fUr die erfolg

reiche Entwicklung und EinfUhrung eines Data Warehouse und der vor- und nachgela

gerten Komponenten dar. Wesentlich erscheint dabei, daB ein kontinuierlicher Pla

nungsprozeB stattfindet, der auch sich wandelnden Anforderungen wahrend der Um

setzungsphasen Rechnung tragt. 1m folgenden wird der Planungs- und EntwurfsprozeB

unter Beriicksichtigung des Umfeldes der angestrebten U:isung sowie unter dem

Aspekt der fUr die Umsetzung und den Betrieb eines Data Warehouse benotigten tech

nischen Infrastruktur betrachtet. Fur die gesamte Dauer des Projekts ist daruber hinaus

596 V gl. Anahory/Murray (1997), S. 331 f.


zur Sicherstellung der Akzeptanz durch die Zielgruppe die Partizipation der Benutzer

und der Fachverantwortlichen bedeutsam.

5.2.1.1 Umfeldanalyse

Als Ausgangspunkt eines Data Warehouse-Projekts sind strategische Uberlegungen

anzustellen. Das Data Warehouse muB in den Gesamtkontext der Informationstechno

logie-Strategie des Unternehmens eingebettet werden, di(1 einen Teil der (funktionalen)

Informationssystemstrategie des Unternehmens bildet.597 Insbesondere ist das Ziel der

Entwicklung zu definieren und aus der betrieblichen Notwendigkeit und dem daraus

resultierenden Anwendungsbereich abzuleiten.598 Weil das Data Warehouse einer

verbesserten Informationssammlung und -analyse sowie der fundierteren Entschei

dungsunterstiitzung dient, kann es auch als eigenstandiger Wettbewerbsfaktor einge

schatzt werden, dessen Einsatz in die Unternehmensstrategie eingebettet werden muB

und diese bei einer erfolgreichen Nutzung moglicherweise verandert.599

Eine 1st-Analyse kann die vorhandenen Systeme in bezug auf die Defizite bei der Ver

sorgung mit entscheidungsrelevanten Daten untersuchen. Hier sollte insbesondere der

zukiinftige Anwender eingebunden werden, da nur er in der Lage ist, seinen Informati

onsbedarf zu bestimmen und zu beschreiben, we1che Daten fUr die konkreten Aufga

ben erforderlich sind.6oo Wesentlich im Rahmen einer 1st-Analyse ist auch die Unter

suchung der moglichen Quellen fUr die in das Data Warehouse einzubringenden Daten.

Auch in bezug auf diesen Aspekt erscheint es zweckmaBig, auf das Wissen der An

wender zuriickzugreifen, da diese zumindest teilweise beschreiben konnen, aus wel

chen Quellen sie bisher ihre Informationen beschaffen, so daB erkennbar wird, we1che

Datenquellen in das Data Warehouse einbezogen werden miissen. Dieser Analyse

schritt kann etwa nach inhaltlichen, qualitativen und technischen Aspekten strukturiert

werden.601 Dariiber hinaus kann durch die bereits in den friihen Projektphasen erfol

gende Partizipation der Benutzer die spatere Akzeptanz des Systems erhoht werden.602

597

598

599

600

601

602

V gl. dazu ErlerlSchelp (1998), S. 8ff. Vgl. Holthuis (I 998a), S. 217. Beispiele, die eine Charakterisierung als eigenstandiger Wettbewerbsfaktor erlauben, finden sich z.B. in ErlerlSchelp (1998), S. 29ff. Vgl. W.-R. Hansen (1998), S. 327. V gl. Holthuis (I 998a), S. 220f. V gl. zur Akzeptanz- und Partizipationsproblematik im Umfeld einer Systementwicklung auch Gluchowski/Gabriel/Chamoni (1997), S. 135ff. sowie Knittel (1995), S. 50ff.


Bei der inhaltlichen Datenanalyse ist festzustellen, welche Daten flir die angestrebte

Analysefunktionalitat benotigt werden und aus welchen operativen Systemen sie ge

wonnen werden konnen. Sollten nicht alle erforderlichen Daten verfligbar sein, ist es

zudem erforderlich, externe Quellen flir diese Daten zu identifizieren oder Uberlegun

gen zur Modifikation der Quellsysteme, urn diese Daten in Zukunft zu erzeugen, anzu

stellen. Weiterer Handlungsbedarf besteht, wenn flir bestimmte Daten mehrere, nicht

zueinander konsistente Quellen identifiziert werden konnen, die zunachst konsolidiert

werden mlissen.603

In Hinblick auf die Qualitat der als grundsatzlich verfligbar identifizierten Daten kann

festgestellt werden, ob diese hinreichend genau, aktuell und vollstandig vorhanden

sind. Gegebenenfalls sind umfangreichere Transformationsfunktionen in das Projekt

einzubeziehen.

Bei einer technischen Analysesicht stehen die Fragen der Kommunikation mit den

librigen Informationssystemen im relevanten Umfeld im Vordergrund. Bei den in die

ser Arbeit mit Prioritat betrachteten Schnittstellen zu den Vorsystemen sind etwa tech

nische Aspekte wie Kommunikationswege und Ubertragungsprotokolle zu berlicksich

tigen. Ahnliche Uberlegungen mlissen darliber hinaus auch den Schnittstellen zu den

aufsetzenden Systemen und peripheren Systemkomponenten gelten.

1m Rahmen der Planung des Gesamtprojekts mlissen konkurrierende Ziele beachtet

werden: Einerseits flihrt eine Vorgehensweise in kleinen Schritten zu kurzen Ent

wicklungszeiten je Ausbaustufe, damit zu schnellen Erfolgen und niedrigeren Vorlauf

kosten und insgesamt wohl zu hoherer Akzeptanz des Projekts und des zu entwickeln

den Systems. Andererseits ist eine sorgfaltige Durchflihrung der Planung und Analyse

unter Beachtung der spateren Ausbaustufen erforderlich, urn ein nahtloses Einpassen

der Folgeprojekte in die bereits fertiggestellten Teile zu ermoglichen und den Aufwand

flir Nachbesserungen zu minimieren. Konkret bedeutet dies, daB kleine und liberschau

bare Teillosungen zu entwickeln sind, ohne dabei den Bezug zum (in der Frlihphase

des Projekts erarbeiteten) Gesamtkonzept zu verlieren - ein Vorgehen, daB sich durch

einen Leitsatz wie "Think Big - Start Small!" ausdrucken laBt.

603 V gl. zu der hier nur schlaglichtartig beschriebenen Problematik Abschnitt 4.3.2.5.


5.2.1.2 Architekturplanung

Auf der Basis der Planung fUr das Gesamtprojekt kann die Architektur des Data Ware

house entworfen werden. Hier erscheint es wichtig, bereits vor den ersten Implemen

tierungsschritten eine Vision tiber die gewtinschte Endausbaustufe hinsichtlich des

Umfangs des Data Warehouse zu entwickeln. Als MeBgroBen hierfUr eignen sich z.B.

die Anzahl der Schemaobjekte im Data Warehouse-Datenmodell als Indikator ftir

des sen Komplexitat, geschatzte Datenmengen und angestrebte Nutzerzahlen. Auf

dieser Basis konnen von Anfang an Infrastrukturkomponenten wie Hardware oder

Datenbankmanagementsystem-Software ausgewlihlt werden, die auch in spateren Aus

baustufen ausreichend leistungsHihig sind oder in geplanter und gezielter Form erwei

tert werden konnen. Ftir derartige Auswahlentscheidungen ist damit einerseits eine

moglichst konkrete Vision erforderlich, andererseits soli sie genugend Spielraume

lassen, urn auch die beschriebenen Effekte eines dynamischen Anforderungsprofiles

adressieren zu konnen.

Mit der Frage nach der Auswahl und Beschaffung der Infrastrukturkomponenten und

dem geeigneten Zeitpunkt sind jedoch weitere Uberlegungen verbunden. Gewichtige

Grunde sprechen fUr die Schaffung einer Infrastruktur, die fUr die Endausbaustufe

ausgelegt ist, schon bevor die ersten Teilprojekte realisiert werden:

• Es entflillt die Notwendigkeit zu einem Systemwechsel, der erforderlich ist, wenn

zunachst Technologie verwendet wird, die nur fUr die ersten Ausbaustufen lei

stungsfahig genug ist und mit steigender Datenmenge und Nutzerzahl an ihre Gren

zen stoBt.

• Sofern Komponenten eingesetzt werden, die zuvor im Unternehmen nicht vorhan

den waren (z.B. andere Hardwareplattformen wie etwa Parallelrechner, neue Daten

banksysteme) besteht bei einer Beschaffung zu Projektbeginn eher die Moglichkeit,

ausreichend Erfahrungen fUr einen sicheren Produktivbetrieb zu sammeln als bei ei

ner spateren EinfUhrung dieser Systeme.

Auf der anderen Seite durfen auch die Nachteile einer solchen Strategie nicht verkannt

werden:

• Die beschriebene Vorgehensweise ist mit hohen Anfangsinvestitionen verbunden,

die zu Beginn eines Data Warehouse-Projekts nicht immer durchsetzbar sein werden

und die aufgrund der frtihen Kapitalbindung und des entstehenden Abschreibungs

bedarfes zu insgesamt hoheren Kosten fUhrt.


Dartiber hinaus ergeben sich aus drei Perspektiven Investitionsrisiken:

• Die Investition in spezialisierte, besonders problemadaquate Systeme erweist sich

als Fehlschlag, wenn das Projekt vor dem Erreichen des Status einer produktiven

Anwendung eingestellt wird.

• Die Einschatzungen tiber eine problemadaquate Infrastruktur fUr eine Endausbaustu

fe konnen im Projektverlauf und dem entstehenden Zuwachs an Wissen tiber die

Anforderungen und an Erfahrungswissen revidiert werden, so daB bereits ange

schaffte Hard- und Software nicht mehr als zweckmaBig erscheint.

• Nicht zuletzt darf nicht verkannt werden, daB eine Beschaffung derartiger Investiti

onsgtiter "auf Zuwachs" angesichts des raschen technischen Fortschritts und des

damit einhergehenden Preisverfalls fragwtirdig erscheint, insbesondere, wenn von

einer Laufzeit des Gesamtprojekts tiber mehrere Jahre ausgegangen werden kann.

Ein geeigneter Weg zur Vermeidung dieser Nachteile kann in der Auswahl von Hard

und Software liegen, die einen hohen Grad an Skalierbarkeit aufweist, also unter Bei

behaltung bestehender Komponenten so erweitert werden kann, daB gestiegene Lei

stungsanforderungen erftillt werden. Dies kann etwa durch parallelisierbare Systeme

oder zumindest durch Softwarekomponenten, die ftir unterschiedliche Rechnertypen

mit verschiedenen Betriebssystemen verfUgbar sind, geschehen.

Die beschriebenen Uberlegungen treffen auch auf die Transformationskomponenten

zu. Diese werden in engem Zusammenhang mit dem Data Warehouse entwickelt und

beanspruchen einen wesentlichen Teil der insgesamt fUr das Projekt aufzuwendenden

Ressourcen.

5.2.1.3 BegJeitende akzeptanzsichernde Ma6nahmen

Neben der Planung der technischen Realisierung des Data Warehouse und seiner Ein

bettung in das organisatorische Umfeld im Unternehmen erscheint das Werben urn

Akzeptanz fUr das Projekt als eine zentrale Aufgabe, die sowohl in den Anfangsphasen

als auch wahrend der Realisierung wichtigen EinfluB auf den Erfolg hat. Als Adressa

tenkreis sind dabei sowohl die spateren Anwender des Systems als auch Budgetver

antwortliche, die regelmaBig tiber die FortfUhrung des Projekts zu entscheiden haben,

bedeutsam.

Ein analyseorientiertes Informationssystem lebt yom Interesse seiner Nutzer und deren

Erkenntnis, daB es sich urn ein attraktives und effizientes Werkzeug zur Informations-


beschaffung handelt.604 Daher ist es erforderlich, von Projektbeginn an realistische

Vorstcllungen iiber Maglichkeiten und Leistungspotentiale des projektierten Systems

zu vermitteln. Dies fiihrt insofern zu besseren Projekterfolgen, als das Ergebnis von

der Zielgruppe auch angenommen und genutzt wird.

Dariiber hinaus kann so aber auch dazu beigetragen werden, daB entsprechendes An

wendungswissen und praxisgerechte Anforderungen in die Entwicklung eingebracht

werden und sich die spatere Wahrnehmung des Ergebnisses als "niitzlich" noch ver

starkt. Dies bezieht sich sowohl auf das Requirements Engineering beziiglich der

Funktionalitat der Endbenutzerwerkzeuge als auch auf das Anwendungswissen beziig

lich der Beschaffung der Daten. Insbesondere in Umgebungen mit Altsystemen, die

schlecht dokumentiert sind, erscheint es zweckmaBig, sich des Erfahrungswissens der

Anwender zu bedienen, die - wie im Rahmen der 1st-Analyse bereits angesprochen -

vielfach wohl sehr genau wissen, wo die Daten zu finden sind, die sie fiir ihre Aus

wertungsaufgaben benatigen.

Nicht nur der Zielgruppe der Anwender, sondern dariiber hinaus auch den Budgetver

antwortlichen, die als Topmanager maglicherweise nur sekundar zum Anwenderkreis

geharen, soUte fortlaufend der Nutzen vermittelt werden, nicht nur zur Sicherstellung

eines ausreichenden Budgets. Auch angesichts der maglicherweise implizit entstehen

den neuen Kultur des Umgangs mit Informationen, die kein funktions- oder bereichs

bezogenes, abgeschottetes Berichtswesen mehr kennt, erscheint eine Unterstiitzung

von oberster Ebene angemessen.

5.2.2 Entwicklung und Betrieb

Aus den bereits beschriebenen Griinden wird ein iterativer, prototypisch orientierter

Ansatz zur Entwicklung und Einfiihrung einer Data Warehouse-Lasung beschrieben.

Wie in den vorhergehenden Abschnitten erfolgt auch hier vielfach eine gemeinsame

Betrachtung der Transformationskomponenten und des Data Warehouse, da aufgrund

des engen Zusammenhangs bei der Entwicklung eine isolierte Sichtweise nicht

zweckmaBig erscheint.

604 Uberlegungen zur Akzeptanzproblematik im vorliegenden Kontext steHt Kaiser (1998), S. 454ff., an.


5.2.2.1 Auswahl und Entwicklung eines Prototypen

Die Umsetzung eines Softwareentwicklungsprojekts nach einem iterativen Vorge

hensmodell beginnt mit der Erstellung eines ersten Prototypen. Dieser soli hier bereits

eine funktionsfahige Data Warehouse-Anwendung flir einen abgegrenzten Themenbe

reich liefern und als Anschauungsobjekt flir Projektverantwortliche, Anwender und

auch die Entwickler dienen. Daher kommt ihm eine besondere Bedeutung zu.

Wesentlich erscheint die sorgfaltige Auswahl des Anwendungsfeldes flir diesen

Schritt. Es soli einerseits hinsichtlich des Datenmodells und der Endbenutzeranwen

dungen keinen zu hohen Komplexitatsgrad aufweisen, urn der Tatsache Rechnung zu

tragen, daB dieser Prototyp auch als Trager zum Sammeln von Erfahrungen flir die

Entwickler erforderlich ist. Aus den gleichen Grunden kann in die Auswahlentschei

dung einbezogen werden, ob flir den gewahlten Themenbereich in den operativen

Systemen Daten angemessener Qualitlit vorhanden sind, die leicht iibernommen wer

den konnen. 1st dies der Fall, miissen flir den Prototypen noch keine allzu komplexen

Transformationsfunktionen entwickelt werden.

Andererseits bietet es sich an, ein Anwendungsfeld auszuwahlen, das flir die Nutzer

von hoher Relevanz ist und in dem besonders groBe Informationsdefizite vorliegen, so

daB den Anwendern und den ProjektfOrderern in der Unternehmensleitung sehr schnell

der praktische Nutzen demonstriert und so zur Akzeptanzsteigerung beigetragen wer

den kann. LaBt sich anhand des Prototypen zeigen, daB eine Data Warehouse-Losung

zu tatsachlichen Verbesserungen flihrt, so wird insbesondere die Position des Budget

verantwortlichen gestarkt, der auf dieser Basis die Weiterflihrung des Projekts leichter

durchsetzen kann.

Neben diesem als durchaus bedeutsam anzusehenden "politischen" Nutzen der ersten

Implementierungsstufe dient dieses Teilsystem auch als Erfahrungstrager, aus dem

wertvolle Erkenntnisse flir die Folgemodule gewonnen werden konnen. Diese lassen

sich nach entwicklungsbezogenen, benutzerbezogenen und technischen Aspekten

differenzieren:

• Die Entwickler - sofern es sich nicht urn unternehmensexterne Spezialisten handelt

- konnen aufgrund der relativen Neuheit des Data Warehouse-Gedankens nur selten

auf Erfahrungen mit derartigen Projekten mit ihren spezifischen Datenmodellen,

Datenbanksystemen und Werkzeugen sowie der insgesamt von der Softwareent

wicklung im operativen Bereich abweichenden Problemstruktur zuriickblicken. Da-


her muB auf Seiten der Entwickler zunachst entsprechendes Wissen akquiriert wer

den, das sich an diesem ersten Modul gut anwenden und vertiefen laBt.

• Die Anwender sind im Rahmen des Entwicklungsprozesses gefordert, ihre Wiinsche

hinsichtlich der erforderlichen Datenbestande und der abzubildenden Funktionalitat

zu spezifizieren. Dabei erscheint ein "Requirements Engineering" in herkommlicher

Form, das vorsieht, bereits vor dem Beginn der Imp1ementierung aile Anforderun

gen an das Zielsystem zu ermitteln und zu einer vollstandigen, in sich konsistenten

Produktdefinition zusammenzustellen,605 aus den bereits beschriebenen Griinden

nicht adaquat. Vielmehr werden mit dem sich entwickelnden Erfahrungswissen

neue, bis dato nicht erkannte Anforderungen formuliert, bestehende prazisiert oder

es wird vielleicht auch von Maximalforderungen abgeriickt, so daB realistische Vor

stellungen gebildet werden. Dies betrifft dann unmittelbar nicht nur die funktionale

und ergonomische Ausgestaltung der Endbenutzerwerkzeuge, sondem auch die Da

tenquellen, die benotigt werden und zu deren ErschlieBung geeignete Transformati

onsfunktionen bereitgestellt werden miissen.

• In technischer Hinsicht liefert ein erstes funktionales Modul beispielsweise Hinwei

se auf Mangel im Antwortzeitverhalten, die dann durch entsprechende Verbesse

rungsmaBnahmen beseitigt werden konnen. Weitere Probleme, die unter Umstanden

erst in dieser Phase erkannt werden, ergeben sich aus unzureichender Datenqualitat.

Ein erstes benutzbares Modul des analyseorientierten Informationssystems kann hier

Transparenz liefem, etwa wenn sich herausstellt, daB Daten entgegen den Erwartun

gen z.B. syntaktisch unkorrekt, inhomogen oder unvollstandig sind, so daB zusatzli

che Transformationsfunktionen zur Verbesserung der Datenqualitat, wie sie im vor

hergehenden Kapitel beschrieben wurden, implementiert werden miissen.

Bei der Planung und Realisierung weiterer Module kann dann von den gewonnenen

Erfahrungen profitiert werden, so daB zu erwarten ist, daB die Projektlaufzeiten und

-kosten tendenziell sinken.

5.2.2.2 Systemausbau

Nach der erfolgreichen Einfiihrung des ersten Moduls lassen sich weitere Entwick

lungsschritte realisieren, wobei flir die einzelnen weiteren Schritte beachtet werden

muB, daB sie sich in den Gesamtprojektplan einfiigen miissen, damit nicht statt einer

605 Zum Requirements Engineering vgl. Mittermeir (1990), S. 239[f.

220 Anforderungen an die Transforrnationskornponente

konsistenten, inkrementell erstellten Gesamtlosung eine Vielzahl von nicht oder nur

lose miteinander verkntipften Einzellosungen entsteht. Daneben sollte auch der Ent

wicklung der Module se1bst wiederum ein Vorgehensmodell zugrunde1iegen, urn eine

systematische DurchfUhrung des Teilprojekts zu gewlihrleisten.

Bezogen auf die Gesamtentwicklung des Data Warehouse-Projekts entsteht so ein

Vorgehen, das Ahnlichkeiten zum bereits beschriebenen Spiralmodell aufweist: Einer

seits wird fiir das Gesamtprojekt ein zyklisches Vorgehen verfolgt, andererseits inner

halb der einzelnen Zyklen, die zu den Modulen fUhren, ein phasenorientiertes Vorge

hen gewlihlt, das eine systematisierte Erarbeitung und Umsetzung der Erfordernisse

ermoglicht. 606

Der Ausbau des Gesamtsystems durch die Erweiterung urn ein Modul umfaBt die fol

genden Teilaspekte, die stark miteinander verzahnt sind und sich jeweils durch Pla

nung, Anforderungsanalyse, Modellierung und Implementierung strukturieren lassen:

• Erweiterung der Transformationskomponente fUr das zusatzliche Modul. Sofern

Anwendungsbereiche abgedeckt werden sollen, fUr die Daten benotigt werden, die

bisher nicht im Data Warehouse verftigbar sind, mtissen diese aus den operativen

Quellsystemen beschafft werden. Dazu ist es notwendig, die Daten dort zu lokalisie

ren, die Hardwareinfrastruktur zu deren Ubernahme zu schaffen, sofern sie nicht

vorhanden ist, und Transformationskomponenten zu entwickeln, welche die Daten

nach den im vorhergehenden Kapitel dargelegten Uberlegungen so umwandeln, daB

sie im Data Warehouse verwendet werden konnen. In bezug auf die operativen Sy

sterne mtissen zudem Verfahren implementiert werden, welche die relevanten Daten

fiir die Aktualisierungslaufe des Data Warehouse dort extrahieren.607

• Dariiber hinaus muB das Datenmodell des Data Warehouse so erweitert werden, daB

die zusatzlichen Daten durch entsprechende Schemaobjekte reprasentiert werden.

Hier dart nicht etwa ein separates Datenmodell fUr die Daten der neuen Anwendung

geschaffen werden, vielmehr ist eine integrierte Losung anzustreben, die bereits

vorhandene Datenbestande nutzt, die urspriinglich fUr andere Anwendungen in das

Data Warehouse eingefUgt wurden. Freilich setzt dies voraus, daB im Rahmen der

Weiterentwicklung profunde Kenntnisse tiber das vorhandene Datenmodell vorlie-

606

607

Fiiting (1998), S. 340, zeigt ein ahnliches Vorgehen, erweitert dieses aber urn die Miiglichkeit der teilweise parallelen Entwicklung der einzelnen Module. Vgl. Abschnitt 4.3.1.


gen. Uber entsprechende "Mappings" werden die neu hinzugekommenen Daten

quellen mit den (gleichfalls neuen oder schon bestehenden) Schemaobjekten im

Data Warehouse-Datenmodelliogisch verkntipft.

• SchlieBlich sind auch fUr die neuen Anwendungsfelder gegebenenfalls zusatzliche

Endbenutzerwerkzeuge zu entwickeln bzw. an die neuen Gegebenheiten anzupas

sen. Dieser Aspekt soli hier zugunsten einer schwerpunktmaBigen Betrachtung der

Versorgung des Data Warehouse mit Daten nicht weiter verfolgt werden.

Die neu hinzugekommenen Module sind vor ihrer EinfUhrung zu testen. Spatestens in

diesem Entwicklungsstadium wird es notwendig, das Data Warehouse initial mit den

Daten zu bestticken, die fUr den zusatzlichen Anwendungsbereich benotigt werden.608

In dieser Phase des Ausbaus des Data Warehouse werden so nach und nach weitere

Anwendungsbereiche mit der Data Warehouse-Losung abgedeckt, bis der gewtinschte

Grad an FHichendeckung erreicht ist. Dabei steigt konsequenterweise mit jedem einge

fUhrten Modul die Nutzerzahl weiter an. Daraus ergeben sich unter technischen und

organisatorischen Aspekten Implikationen hinsichtlich der Charakteristik des analyse

orientierten Informationssystems:

• Die erforderliche Leistungsfahigkeit der eingesetzten DV-Infrastruktur steigt, damit

sich das Antwortzeitverhalten durch die steigende Auslastung nicht in einer Weise

verschlechtert, die zu storenden Effekten fUhrt.

• Organisatorische Aspekte gewinnen an Bedeutung. So erfordern groBe Systeme mit

hohen Benutzerzahlen vor allem auch systematische Schulungs- und Benutzerbe

treuungsmaBnahmen, damit allseits akzeptierte und effizient genutzte Systeme ent

stehen. Auch Fragen der technischen SystemverfUgbarkeit, der Datensicherheit und

des Datenschutzes gewinnen an Bedeutung.

Mit dem Ausbau des Systems und dartiber hinaus durch die Aktualisierungen im

Zeitablauf steigen auch die vorgehaltenen Datenmengen an. Dies ergibt sich einerseits

aus dem Hinzukommen neuer Themenbereiche, fUr die im Data Warehouse Daten

vorgehalten werden sollen. Andererseits nimmt die Datenmenge auch durch die regel

maBige Aktualisierung der Datenbestande zu, die sich aus den Veranderungen in den

operativen Daten ergeben. Auch unter diesem Gesichtspunkt steigen somit die Anfor

derungen an die Leistungsfahigkeit der verwendeten Datenbanksysteme, insbesondere

608 V gl. Abschnitt 4.2.1.

222 Anforderungen an die Transforrnationskomponente

mtissen aber aueh die Transformationskomponenten adaquate Qualitatsmerkmale auf

weisen, wie in den folgenden Absehnitten ausfiihrlieher diskutiert wird.

5.2.2.3 Betrieb

1st der flaehendeekende Ausbau des analyseorientierten Informationssystems abge

sehlossen, besteht - bei idealisierter Betraehtung - aus der Sieht des Data Warehouse

und der datenzuliefernden Transformationskomponenten ein weitgehend stabiles Sy

stem. Hinsiehtlieh der Endbenutzerwerkzeuge fiihrt die (durehaus erwtinsehte) Flexi

bilitat zwar zu laufenden Erweiterungen und Anderungen, urn das System an neue

Anforderungen anzupassen, jedoeh sollte das Datenmodell des Data Warehouse im

Sinne eines konzeptionellen Datenmodells so ausgereift und stabil sein, daB diese

Anforderungen im wesentliehen aus den in diesem Modell vorhandenen Daten bedient

werden konnen. Damit liegt aueh eine zumindest weitgehend stabile Struktur der

Transformationskomponenten vor. Anpassungen konnen hier allerdings aus zwei

Riehtungen induziert werden. Von "oben" kann ein zusatzlieher Informationsbedarf,

der an das Data Warehouse geriehtet wird, zu Anderungen fiihren, falls die verlangten

Informationsstrukturen aus den vorhandenen Daten nieht gewonnen werden konnen.

Dies ftihrt nieht nur zu Modifikationen am Data Warehouse-Datenmodell, sondern

entspreehend aueh an der Transformationskomponente. 1m Idealfall besteht dariiber

hinaus die Mogliehkeit zur Erweiterung der operativen Systeme, urn fiir Analysezwek

ke benotigte, aber bisher nieht vorhandene Daten zu erzeugen. Umgekehrt fiihren aueh

Anderungen, die "unten" in den operativen Systemen vorgenommen werden, zu einem

Anpassungsbedarf in den Modellstrukturen des Data Warehouse sowie den Transfor

mationsmeehanismen.

In bezug auf diesen Gesiehtspunkt erseheint es von besonderer Bedeutung, aueh den

organisatorisehen Rahmen, unter dem Veranderungen an den operativen Systemen

vorgenommen werden, an das Vorhandensein eines analyseorientierten Informations

systems anzupassen. Bei Altanwendungen, die z.B. auf dateiorientierten Datenstruktu

ren basieren, ist vielfaeh keine Unabhangigkeit zwischen den physisehen Datenstruktu

ren und den Sehnittstellen gegeben, tiber die ein Zugriff auf diese Daten erfolgt. Wer

den hier nun - aueh nur geringfiigige - Anderungen vorgenommen, mtissen alle An

wendungen, die auf diese Daten zugreifen, also aueh die Werkzeuge zur Datenextrak

tion fiir das Data Warehouse, entspreehend angepaBt werden. Sofern versehiedene

organisatorisehe Einheiten fiir die Pflege der operativen und der analyseorientierten


Informationssysteme zustandig sind, erscheint es notwendig, einen entsprechend tiber

greifenden Anderungsdienst zu institutionalisieren. Dieses Problem erscheint insofern

als besonders relevant, als derartige Altsysteme vielfach laufend an die sich andernden

(z.B. gesetzlichen) Rahmenbedingungen angepaBt werden mtissen und dies wohl nahe

zu immer auch Auswirkungen auf die Speicherung der Daten hat.

Die Betriebsphase ist also in bezug auf die Transformationskomponente in erster Linie

durch das regelmaBige Durchftihren der Aktualisierungslaufe gekennzeichnet. Veran

derungen ergeben sich einerseits aus der Notwendigkeit zur Anpassung an Modifika

tionen der operativen Vorsysteme, und andererseits auch in begrenztem Umfang durch

Modifikationen am Data Warehouse selbst. Diese wirken sich dann aus, wenn sich

dadurch der Bedarf an zu importierenden Daten verandert oder durch Anpassungen am

Data Warehouse-Datenmodell das "Mapping" tiberarbeitet werden muB. Auch eine

Veranderung der technischen Basis des Data Warehouse kann dazu fiihren, daB trotz

einer ClientlServer-Architektur, die eine gewisse Unabhangigkeit zwischen den Kom

ponenten gewahrleistet, Inkompatibilitaten auftreten, etwa wenn die benotigten Midd

leware-Komponenten, die zur Kommunikation mit dem Datenbankmanagementsystem

erforderlich sind, sich nicht zur Verwendung mit den vorhandenen Transformations

tools eignen.

5.2.3 Zusammenfassende Betrachtung

Die Durchfiihrung eines schrittweisen Einfiihrungsprozesses bietet den Vorteil, daB auf

dem in vielen Unternehmen sic her fremden Terrain analyseorientierter Informationssy

sterne Erfahrungen mit tiberschaubaren Teilprojekten gesammelt werden konnen, die

zudem schnell zu prasentier- und anwendbaren Losungen fiihren. Dadurch wird nicht

nur ein positives internes Marketing ausgelOst. Gleichzeitig konnen die Hemmnisse,

die bei umfangreichen Projekten mit unklaren Zielvorstellungen auftreten, abgebaut

werden. Sofern bei der vorgeschlagenen Vorgehensweise einer kleinschrittigen Reali

sierung das Ziel des Aufbaus einer Gesamtlosung nicht zugunsten einer Vielzahl iso

lierter MinilOsungen vergessen wird, erscheint dieser Weg als erfolgversprechend ftir

den Aufbau eines Data Warehouse mit den dazugehorenden vor- und nachgelagerten

Komponenten. Abbildung 34 stellt die Projektschritte zusammenfassend dar.


I Gesamtplanung, Partizipation I

1st-Analyse, Infrastruktur-planung

Prototyp • Entwurf • Implementierung • Laden der Daten • EinfOhrung Modul1

• Entwurf • Implementierung • Laden der Daten ... • Einfuhrung Modul n

• Entwurf • Implementierung • Laden der Daten • Einfuhrung

It

• • • » EinfUhrungspunkte der Module im Zeitablauf

Nutzung, regelmaBige Datenaktualisierung

Abbildung 34: Vorgehen im Rahmen von Data Warehouse-Projekten

5.3 Lebenszyklusmodell fUr analyseorientierte Informationssysteme

Aus den in den vorhergehenden Abschnitten dargestellten Entwicklungsschritten laBt

sich unter Zuhilfenahme der GroBen "Nutzerzahl" und "Datenvolumen im Data Ware

house" ein Lebenszyklus flir das analyseorientierte Informationssystem ableiten. Diese

GroBen erscheinen als Indikator flir die notwendige Leistungsflihigkeit des Gesamtsy

stems gut geeignet. Das Datenvolumen kann insofern als Anforderungskriterium die

nen, als die Daten einerseits gespeichert und in geeigneten Strukturen vorgehalten,

anderseits aber auch tiber die Transformationskomponente in einem gegebenen

Zeitrahmen extrahiert und aufbereitet werden mtissen. GroBe Datenmengen lassen

Lebenszyklusmodell fUr analyseorientierte Informationssysteme 225

dartiber hinaus den RtickschluB zu, daB graBere Teile der operativen Daten in das Data

Warehouse iibernommen wurden und entsprechend auch die AktualisierungsHiufe

wesentliche Teile der Quelldatenbestande betreffen. Die Nutzerzahlen kannen eher in

bezug auf die Leistungsanforderungen an den Data Warehouse-Datenbankserver und

die angeschlossene Netzinfrastruktur als Kriterium dienen. Hier ist zu berticksichtigen,

daB mit steigenden Nutzerzahlen auch die Anzahl der von der Datenbank in angemes

senen Antwortzeiten zu bearbeitenden Anfragen steigt. Hinsichtiich der Anforderun

gen an die Transformationskomponente ist dieser Aspekt gleichfalls von Bedeutung,

z.B. weil mit steigenden Nutzerzahlen auch die Ausfallsicherheit des Gesamtsystems

und die VerfUgbarkeit aktueller Daten an Relevanz gewinnt.

Die Veranderungen, denen die genannten GraBen im Verlauf der Umsetzungsphase der

Systementwicklung und der spateren Nutzung unterliegen, werden im folgenden be

schrieben. In der davor erfolgenden Planungsphase sind diese GraBen zwar als Kriteri

urn bedeutsam, konkrete Werte nehmen sie jedoch naturgemliB noch nicht an. Aus

diesen Uberlegungen werden Phasen im Lebenszyklus abgeleitet, die spater in Ab

schnitt 5.4 als Strukturierungsrahmen fUr die Anforderungen an die Transformations

komponente dienen.

5.3.1 Nutzungscharakteristik im Entwicklungsverlauf

1m Rahmen der Entwicklung des ersten Prototypen spielen die Datenmengen, die

transformiert und verwaltet werden, zunachst eine untergeordnete Rolle. Mit fort

schreitendem Entwicklungsstand des Prototypen werden Tests durchgefUhrt, so daB

hier erstmals Transformationsaufgaben durchzufUhren sind und die Menge der bear

beiteten und verwalteten Daten steigt. Entsprechend kann auch von einer zunachst sehr

geringen Nutzerzahl ausgegangen werden.

Mit der initialen Besttickung des Prototypen mit den aus den operativen Systemen

entnommenen Daten und des sen Freigabe zur Nutzung durch Endanwender steigen

beide Parameter zwar an, bleiben jedoch in bezug auf die geplante Endausbaustufe auf

einem niedrigen Niveau, da nur ein beschranktes Anwendungsgebiet durch die Daten

abgebildet wird und der Prototyp in erster Linie einem kleinen, ausgewahlten Nutzer

kreis zuganglich ist.

1m Rahmen der Nutzung dieses Prototypen steigt die Datenmenge aufgrund des be

schrankten Anwendungsbereichs nur leicht an, wobei der Zuwachs durch die stattfin-


denden AktualisierungsHiufe entsteht. Auch die Nutzerzahl kann als weitgehend stabil

angenommen werden, wobei als Argument fUr steigende Zahlen etwa ein fortschrei

tender Ausbau der fUr einen Zugang zum Data Warehouse erforderlichen DV

Infrastruktur angefUhrt werden kann. Ebenso konnen SchulungsmaBnahmen, die weite

re Anwender zum Umgang mit dem System qualifizieren, hier zu steigenden Zahlen

fUhren.

1m Rahmen des Systemausbaus werden schrittweise neue Module entwickelt, die das

Data Warehouse urn zusatzliche Anwendungsbereiche erweitern. Hier ist zu erwarten,

daB fUr diese Module auch Daten zu anderen als den bisher abgebildeten Themenge

bieten benotigt werden, fUr die entsprechende Transformationskomponenten angepaBt

werden mUssen. Damit steigt bei der Inbetriebnahme der zusatzlichen Module das

Datenvolumen durch das initiale Laden der benotigten Daten sprunghaft an, wahrend

sie im Rahmen der normalen Nutzung wiederum durch die regelmaBigen Aktualisie

rungen nur langsam steigen. Analog kann fUr die Anwenderzahlen argumentiert wer

den: Auch hier steigen die Zahlen mit der Inbetriebnahme neuer Module an, zumindest

wenn dadurch das Data Warehouse fUr zusatzliche Anwendergruppen relevant wird.

Realistisch erscheint eine gewisse zeitIiche Verzogerung gegenUber dem Ansteigen der

Datenmenge, die sich etwa durch TestIaufe und SchulungsmaBnahmen vor der eigent

lichen produktiven Nutzung der neuen Systembausteine erklaren laBt.

Sind aIle wesentlichen Module in das Gesamtsystem integriert worden, ist ein Zustand

erreicht, der in dem Sinne als "fertig" bezeichnet werden kann, daB nach dem dann

aktuellen Planungstand keine grundlegenden Erweiterungen mehr vorgenommen wer

den sollen. Modifikationen werden allerdings dennoch erforderlich sein, urn das analy

seorientierte Informationssystem permanent an die sich wandelnden Informationsbe

darfe anzupassen. 1m Hinblick auf die beschriebenen KenngroBen bedeutet dies, daB

eine Stabilisierung auf hohem Niveau eintritt. Somit ist die geplante Auslastung nach

dies en KenngroBen weitgehend erreicht. Die Nutzerzahlen steigen gegebenenfalls

langsam weiter, wenn sich das Data Warehouse als Werkzeug zur Informationsversor

gung dahingehend etabliert, daB es auch Anwendergruppen erreicht, die moglicherwei

se nicht zum ursprUnglichen Adressatenkreis gehorten.609 In bezug auf das Datenvo

lumen kann festgehalten werden, daB Zuwachse sich in erster Linie nur noch durch

609 Dies ftihrt moglicherweise dazu, daB die Gesamtstrategie der Informationsversorgung neu tiberdacht wird und auch eine Neupositionierung des analyseorientierten Informationssystems erfolgt.

Lebenszyklusmodell fUr analyseorientierte Informationssysteme 227

AktualisierungsHiufe ergeben. Hier ist zu erwarten, daB die Wachstumsrate trotz der

regelmaBig hinzukommenden neuen Werte sinkt, wenn parallel damit begonnen wird,

altere, nicht mehr relevante Daten auszulagern.

1m folgenden Abschnitt werden aus diesen Uberlegungen charakteristische Phasen im

Data Warehouse-Lebenszyklus abgeleitet.

5.3.2 Typische Phasen im Lebenszyklus

Die beschriebene Entwicklung hinsichtlich der GroBen "Datenmenge im Data Ware

house" und "Nutzerzahl" laBt sich grafisch wie in Abbildung 35 darstellen. Erkennbar

ist ein ansteigender Verlauf der Kurven mit zunachst niedrigen Wachstumsraten auf

niedrigem absoluten Niveau, dann hoheren Wachstumsraten und schlieBlich wieder

niedrigen Wachstumsraten, jetzt jedoch auf hohem absoluten Niveau. Er entspricht -

abgesehen von der hier fehlenden degenerativen Phase - der charakteristischen Glok

kenform der Kurven in Lebenszyklusmodellen.

Aus dem Verlauf der Kurven konnen die dargestellten vier Phasen im Lebenszyklus

modell abgeleitet werden:

- Pilotphase

Die Durchfiihrung des Data Warehouse-Projekts beginnt mit der Planung und Ent

wicklung eines Prototypen. Aktive Nutzer, die bereits mit dem System arbeiten und

nicht nur an dessen Konzeption partizipieren sowie das tatsachlich gespeicherte Daten

volumen spielen hier eine untergeordnete Rolle, da noch keine Module des Data Wa

rehouse im Unternehmen im produktiven Einsatz sind.

- Erfahrungsphase

Mit der Freigabe des Prototypen fiir einen Einsatz durch die Anwender in den Fachab

teilungen findet erstmalig eine produktive Verwendung des Data Warehouse statt, auch

wenn es in dieser Phase zunachst nur einen abgegrenzten Anwendungsbereich unter

sttitzen kann. Entsprechend mtissen fiir den Anwendungsbereich, den der Prototyp

abdeckt, die relevanten Daten im Data Warehouse enthalten sein und auch regelmaBig

aktualisiert werden, damit ein sinn voller Einsatz moglich ist. Diese Phase dient insbe

sondere dazu, auf Anwender- und Entwicklerseite Erfahrungen zu sammeln und so die

Konzepte zur Funktionalitat, zur Benutzerfiihrung und auch zur Datentransformation

in Hinblick auf die weiteren Entwicklungsschritte zu verfeinern. So stellt sich etwa


vielfach erst nach der Inbetriebnahme des Data Warehouse heraus, daB die Qualitat der

operativen Daten nicht den Erfordernissen entspricht, so daB die Funktionen zur Auf

bereitung dieser Daten angepaBt werden mussen. Diese Phase ermoglicht es somit,

Probleme besser zu erkennen, die beim Ausbau des Data Warehouse urn weitere The

menbereiche potentiell auftreten, und fUr die Ausbaustufen eine insgesamt anforde

rungsgerechtere Planung vorzunehmen.

Daten· menge

Nutzeranzahl

Pilot· phase

Erfahrungsphase

--- Datenmenge

Abbildung 35: Data Warehouse-Lebenszyklus

- Ausbauphase

Ausbau· phase

--- Nutzeranzahl

Betriebs· phase

Zeit

In der Ausbauphase wird das Gesamtsystem durch weitere Module erganzt, die Daten

fUr zusatzliche Themenbereiche verfugbar machen. Damit wachst mit jeder weiteren

Ausbaustufe die funktionale Breite des Gesamtsystems. Entsprechend nimmt auch die

Menge der gespeicherten Daten zu. Damit steigt auch der administrative Aufwand fUr

die Beschaffung der Daten und deren regelmaBige Aktualisierung. Auch die Proble

matik, die sich aus der Verwendung heterogener DatenqueUen ergibt, gewinnt an Re

levanz. Dadurch, daB mit den neu in Betrieb gehenden Modulen jeweils auch zusatzli

che Datenbestande im Data Warehouse benotigt werden, mussen entsprechend auch an

Lebenszyklusmodell fiir analyseorientierte Informationssysteme 229

den Transformationskomponenten Erweiterungen vorgenommen werden, die Quellsy

sterne erschlieBen oder zusatzliche Datenobjekte aus bereits vorher genutzten Quellen

extrahieren, aufbereiten und fiir das Data Warehouse verfiigbar machen.

Die Anzahl der Schritte, in denen diese Ausbauphase vollzogen wird, ist yom Einzel

fall abhangig. Hier ist eine Zielkonkurrenz erkennbar, die durch ein Abwagen aufge

lOst werden muB: Einerseits fiihren kleine Erweiterungsschritte zu einer Zergliederung

des Projekts in viele, jedoch iiberschaubare Teilprojekte, die jeweils wiederum einen

schnell sichtbaren Erfolg bringen, andererseits wirft die Integration vieler kleiner Mo

dule zu einem konsistenten Gesamtsystem Probleme auf und es besteht die Gefahr, daB

eher eine Sammlung von Einzelfall-U:isungen aufgebaut wird als ein konsistentes,

integriertes System. Umgekehrt fiihrt ein Vorgehen in wenigen, groBen Erweiterungs

schritten zu den bereits diskutierten Nachteilen komplexer und langwieriger Teilpro

jekte.

- Betriebspbase

Sind aile geplanten Anwendungsbereiche des analyseorientierten Informationssystems

abgedeckt und werden sie durch die entsprechenden Datenbestande im Data Ware

house unterstiitzt, liegt ein in den Grundstrukturen stabiles System vor, das auch in

Hinblick auf die beschriebenen KenngroBen keinen groBen Veranderungen mehr un

terworfen ist. 1m idealisierten Fall finden regelmaBig weitgehend automatisierte Up

dates der Data Warehouse-Datenbank statt. Der Handlungsbedarf an dieser Stelle be

schrankt sich aus administrativer Sicht auf kleinere Anpassungen, die sich aus der

Anforderung zusatzlicher oder anderer Daten ergeben, die aus den operativen Syste

men beschafft werden miissen.

GroBere AnpassungsmaBnahmen werden erforderlich, wenn das Gesamtsystem oder

ein Teil des analyseorientierten Informationssystems z.B. auf andere Hardware- oder

Betriebssystem-Plattformen verlagert werden soli. Da davon ausgegangen wird, daB es

sich bei einem analyseorientierten Informationssystem urn ein eher "langlebiges" Pro

dukt handelt, kann dieser Fall durchaus relevant werden, etwa urn gestiegenen Anfor

derungen in bezug auf das Antwortzeitverhalten durch die Verwendung zwischenzeit

lich erhaltlicher, modernerer Systemkomponenten nachzukommen. Auch das Anwach

sen des Datenvolumens oder des Nutzerstammes kann zu der Notwendigkeit fiihren,

z.B. das Data Warehouse auf anderer, leistungsfahigerer Hardware zu implementieren.

Analog kann flir die Transformationskomponenten argumentiert werden: Auch hier

kann das groBe Datenvolumen, das aus den operativen Systemen in begrenzten Zeit-


fenstern zu iibernehmen und zu verarbeiten ist, dazu fiihren, daB schnellere Architektu

ren notwendig werden. Eine Lasung kann z.B. in einer Portierung der Transformati

onskomponenten bzw. der Data Warehouse-Datenbank auf leistungsfahigere Hardware

und Betriebssysteme, die etwa parallelisierte Verarbeitung ermaglichen, liegen.6lO

Wie bereits kurz angemerkt,611 soil die degenerative Phase, in der in einem Lebenszy

klusmodell iiblicherweise von einem Sinken der betrachteten KenngraBen ausgegangen

wird, hier nicht weiter betrachtet werden. Versteht man ein analyseorientiertes Infor

mationssystem optimistisch als ein Konzept, das dauerhaft die Informationsversorgung

im Unternehmen sicherstellen soil, so ist nicht zu erwarten, daB es zu einem relevanten

Sinken der Datenmengen oder Nutzerzahlen kommt. Damit soil nicht ausgedriickt

werden, daB nicht einzelne Komponenten des Systems "altern", bei einer isolierten

Betrachtung das Ende ihres Lebenszyklus erreichen und ausgetauscht werden. Der

Aspekt der Anpassung des Gesamtsystems an sich wandelnde Anforderungen oder

Umgebungsbedingungen wurde jedoch oben bereits beriicksichtigt, so daB daraus

keine Degeneration des Gesamtsystems abgeleitet werden soil.

5.4 Phasenspezifische Anforderungen

Fiir die zuvor erlauterten Ph as en sollen nun Anforderungen beschrieben werden, die

fiir die Transformationskomponenten bedeutsam sind. Die Strukturierung anhand der

Phasen erlaubt es, die sich wandelnden Prioritaten in bezug auf die Anforderungen im

Verlauf des Lebenszyklus zu beriicksichtigen.

5.4.1 Pilotphase

Es wurde bereits betont, daB es zumindest aus projektpolitischen Griinden geboten

erscheint, bereits nach kurzer Entwicklungsdauer den Benutzern einen funktionalen

Prototypen der Data Warehouse-La sung bereitstellen zu kannen. Dies impliziert auch,

daB ein entsprechend groBer Datenbestand schon in diesem friihen Stadium in das Data

Warehouse eingefiigt wird. Dabei kannen Testdaten, die mit einem entsprechenden

610

611

Zur Parallelisierung des Transformationsprozesses vgl. Kimball et al. (1998). S. 644f. Die Verwendung paralleler Systeme fur die Data Warehouse-Datenbank wird in LaRue (1997), S. 24 Iff., und in Yevich (1997), S. 236, beschrieben. V gl. FuBnote 590.

Phasenspezifische Anforderungen 231

Generator auf Zufallsbasis erzeugt werden, lediglich in einem Testbetrieb Anhalts

punkte fUr das Leistungsverhalten des sich in der Entwicklung befindlichen Systems

liefem. Sie sind jedoch zur Nutzung in einem Prototypen, der den Nutzem fUr erste

"Gehversuche" mit dem neuen System in der betrieblichen Praxis an die Hand gegeben

werden soli, ungeeignet.

Entsprechend ist notwendig, daB bereits nach dieser kurzen Entwicklungszeit eine

Transformationskomponente verfUgbar ist, die zumindest aus einzelnen Datenquellen

aktuelle und historische DatenbesUinde extrahieren, umwandeln und in das Data Ware

house einfUgen kann. Dies setzt (neben Quelldaten hinreichender Qualitat) voraus, daB

die verwendeten Werkzeuge tiber ausgereifte Benutzungsoberflachen verfUgen, die es

den Administratoren der operativen und der Data Warehouse-Datenbanken erlauben,

im Sinne eines "Rapid Prototyping" in deskriptiver oder graphisch untersttitzter Form

die notwendigen Verkntipfungen herzustellen. 1st dies nicht moglich, werden umfang

reiche und zeitaufwendige Programmierarbeiten erforderlich, die dem Ziel des schnel

len Aufbaus eines funktionierenden Prototypen zuwiderlaufen.

Die problemlose Einbettung in die vorhandene DV-Infrastruktur einschlieBlich des

einfachen Zugriffs auf die mit Prioritat zu beriicksichtigenden Datenquellen, eine

schnelle Erlembarkeit der Benutzungsoberflache und nicht zuletzt auch ein niedriger

Anschaffungspreis612 sind Anforderungen, die in dieser Phase eines Data Warehouse

Projekts als besonders bedeutsam erscheinen. Es darf jedoch auch nicht verkannt wer

den, daB die Vorteile von Tools, die einfach zu bedienen und zu niedrigen Anschaf

fungspreisen erhaltlich sind, wohl oft dadurch erkauft werden, daB sie vielfach ent

sprechend auch nur einen eingeschdinkten Funktionsumfang besitzen und daher mit

dem Anwachsen des Projektumfangs an Leistungsgrenzen stoBen konnen. Dieser Fall

kann eintreten, wenn beispielsweise in heterogenen Umgebungen Quellsysteme ange

sprochen werden sollen, fUr die derartige einfachere Werkzeuge nicht tiber Schnitt

stellen verfUgen. Ein Tool, das nur fUr Personal Computer mit grafischer Benutzungs

oberfhche verfUgbar ist, kann gegebenenfalls die Transformation groBer Datenmengen

aufgrund der beschrankten Rechenkapazitat nicht in der erforderlichen Geschwindig-

612 In bezug auf den Anschaffungspreis von Softwareprodukten kann argumentiert werden, daB diese hinsichtlich der Gesamtkosten fur den Aufbau und den Betrieb der Systeme, in die sie einflieBen, nur eine untergeordnete Rolle spielen. Hier wird jedoch eine kleinschrittige Vorgehensweise betrachtet, die entsprechend auch von schmalen Budgets in den einzelnen Phasen ausgeht, in denen durch den Kauf kommerzieller ETL-Werkzeuge (Extraction, Transformation, Loading) ein relevanter Budgetposten entsteht.


keit bewerkstelligen. Hier wirkt es sich nachteilig aus, wenn keine Versionen fiir Be

triebssysteme verfiigbar sind, die fiir diese Tools schnellere oder parallelisierbare

Hardware erschlieBen konnen. SchlieBlich ist der Zielkonflikt zwischen einer breiten

Funktionalitat und einer einfachen, grafisch unterstiitzten Bedienung unmittelbar er

kennbar, da die im vorhergehenden Kapitel angesprochenen, oftmals komplexen

Funktionen sich vielfach eher iiber eine Programmierschnittstelle als iiber ein "Point

and-Click"-Bedienungskonzept realisieren lassen.

Umgekehrt darf jedoch nicht iibersehen werden, daB Transformationswerkzeuge, die

sich unter den genannten Aspekten als offener erweisen und damit im Sinne eines

groBer werdenden Data Warehouse iiber mehr Zukunftssicherheit verfiigen, groBere

Anstrengungen vor dem Erzielen erster Ergebnisse erfordern. Daher sind diese weniger

zielkonform in bezug auf einen schnell und kostengiinstig zu erstellenden Prototypen.

Durch den Ausbau des Data Warehouse verschieben sich aufgrund der veranderten

Projektcharakteristik die Prioritaten hinsichtlich der Anforderungen an die Transfor

mationswerkzeuge. Die Komplexitat des Datenmodells sowie die im Data Warehouse

enthaltene Datenmenge und die Nutzerzahlen steigen, so daB insgesamt Funktionalita

ten zum Management der Daten und Prozesse bedeutsamer werden.

5.4.2 Erfahrungsphase

Mit der Freigabe des Data Warehouse fiir einen breiteren Nutzerkreis werden Instru

mente fiir die Navigation in den Datenbestanden relevant. 1st wahrend der Entwicklung

eines kleinen, prototypischen Projekts die Annahme noch realistisch, daB die Ent

wickler und auch die wenigen bereits beteiligten Nutzer schnell durch Erfahrung den

Uberblick iiber die gespeicherten Daten, ihre Quellen und die Funktionalitat erlangen,

gewinnt eine toolgestiitzte Metadatenverwaltung spates tens mit der Bereitstellung des

Systems fiir einen breiteren Nutzerkreis schnell an Bedeutung. In Abschnitt 3.4.1 wur

de die groBe Breite der im Data Warehouse-Umfeld anfallenden Metadaten beschrie

ben. Idealerweise sollten aile Metadaten durch ein einziges Tool verfiigbar sein, das

zudem eine Konsolidierung von Veranderungen auf den einzelnen Modellebenen un

terstiitzt. Wird also beispielsweise - durch eine Modifikation der Metadaten - das

Modell der Data Warehouse-Datenbank verandert, so ist es zweckmaBig, wenn zu

gleich die logische Zuordnung der Quelldaten zu den Schemaobjekten des Data Ware-


house angepaBt wird. Dariiber hinaus erscheinen Funktionen erstrebenswert, die es - in

Analogie zu den flir operative Datenbanksysteme verfligbaren CASE-Systemen613 -

gestatten, aus den Metadaten entsprechenden Programmcode zur Implementierung von

Datenmodellen oder Transformationsfunktionen zu erzeugen.

Komfortable Benutzungsschnittstellen erlauben, gegebenenfalls tiber ein Rollenkon

zept, den unterschiedlichen Benutzerklassen wie Entwicklern, Administratoren und

Endbenutzern den Zugriff auf die Metadaten. Aus der Sicht der Endbenutzer ist ein

einfaches "Browsen" durch zielgruppenspezifische, an geschaftsrelevanten Aspekten

orientierten Metadaten erstrebenswert, urn so einen besseren Zugang zu den Inhalten

zu erhalten. Damit konnen die Akzeptanz und die Nutzbarkeit des Data Warehouse

verbessert werden, wenn auf diese Weise Wissen tiber die verfligbaren Informationen

vermittelt werden kann.614 Eine solehe Endbenutzerschnittstelle zu den Metadaten im

Sinne einer Suchhilfe und ErkHirungskomponente kann dariiber hinaus den

(kostenverursachenden) Benutzersupport durch das Data Warehouse-Projektteam

entlasten, wenn Fragen des Anwenders auf diese Weise gekHirt werden konnen.

Auch in Hinblick auf die Schnittstellen zu den Vorsystemen ist eine ausgefeilte Meta

datenverwaltung zweckmaBig. Sie bietet die Basis zur effizienten Nutzung der Sche

mata der Vorsysteme flir die Definition der Extraktions- und Umwandlungsschritte.

Tools, die mit "Reverse Engineering"-Funktionen ausgestattet sind, bieten die Mog

lichkeit, Strukturen der operativen Systeme und deren Metadatenkomponenten auszu

werten und daraus die Metadaten zu entnehmen, die etwa flir das Verkntipfen der

Schemaobjekte der beiden Systemklassen erforderlich sind.615

Insgesamt sollte der Forderung nach einer moglichst ausgepragten Untersttitzung des

Benutzers durch Metadaten bei der Administration und Nutzung des Data Warehouse

eine groBe Bedeutung bei der Auswahl von Werkzeugen zur Datentransformation

beigemessen werden. Sie stellen ein wesentliches Hilfsmittel bei der Administration

der Datenversorgung flir das Data Warehouse dar. Problematisch erscheint die man

gelnde Interoperabilitat, wenn mehrere Werkzeuge eingesetzt werden sollen: Das Feh

len standardisierter Metadatenaustauschformate flihrt vielfach dazu, daB kein gemein-

613

614

615

V gl. Abschnitt 2.4.2. Ein Beispiel fUr ein metadatengestiitztes Entwicklungssystem mit umfangreichen Generatorfunktionen ist Oracle Designer/2000, vgl. hierzu AndersonlWendelken (1996). Vgl. Gleason (I 997b), S. 149. Auf diese Weise lassen sich etwa strukturorientierte Metadaten fUr das Data Warehouse und die Transformationskomponenten gewinnen, wie sie in Abschnitt 3.4.1.1 beschrieben worden sind.


samer Metadatenbestand aufgebaut werden kann. Ohne entsprechende Maglichkeiten,

Metadaten nach auBen weiterzugeben, ist auch die Integration etwa eigenerstellter

Programme, die spezifische Funktionen abdecken, nur schwer maglich.

Ein geringerer Stellenwert kommt einer ausgepragten Metadatenorientierung der ver

wendeten Werkzeuge aufgrund dieser UberJegungen nur in Ausnahmefallen zu. So

erscheint sie bei sehr spezialisierten, eng begrenzten Anwendungsfallen fUr ein analy

seorientiertes Informationssystem mit nur geringer Breite der vorgehaltenen Datenbe

stande und wenigen Benutzern oder auch bei insgesamt kleinen Data Mart-Projekten

als von nachrangiger Bedeutung.

Eine ausgepragte Verwendung von Metadaten kann also vielfaltige Hilfestellung bei

der Nutzung des Data Warehouse und bei seiner Administration leisten. In engem

Zusammenhang damit stehen auch weitere Funktionen, die - wiederum auf der Basis

entsprechender Metadaten - die Systemverwaltung und -wartung in bezug auf die

Beschaffung der benatigten Daten unterstiitzen kannen. Diese werden im folgenden

beschrieben.

Mit der Etablierung einer Data Warehouse-La sung und ihrer regelmaBigen Nutzung

durch einen breiten Anwenderkreis gewinnt eine planvolle Wartung und Pflege dieser

Systeme an Bedeutung, so daB dauerhaft ein anforderungsgerechter, konsistenter und

aktueller Zustand erzielt wird. 1m Hinblick auf die Beschaffung der Daten fUr das Data

Warehouse sind insbesondere Komponenten zweckmaBig, die automatisiert auf die

Quellsysteme zugreifen und die Warehouse-relevanten Daten extrahieren, transformie

ren und in das Data Warehouse einfUgen. ZweckmaBig erscheint eine flexible Ausge

staltung der Update-Zyklen: So kann im Faile einer Zeitsteuerung, wenn das Werkzeug

eine variable Zyklizitat ermaglicht, auf jede Datenquelle in Abhangigkeit von dort

verfUgbaren Schwachlastzeiten, der Relevanz und der Anderungscharakteristik der

Quelldaten zu einem spezifischen Zeitpunkt und in anforderungsgerechten Abstanden

zugegriffen werden. Noch graBere Flexibilitat wird erreicht, wenn neben einer varia

bien Zeitsteuerung tiber eine Scheduling-Komponente auch andere Ereignisse definiert

werden kannen, die ein Update auslOsen. Dies kann sich insbesondere dann als wert

voll erweisen, wenn mehrere unterschiedlich ausgelastete Quellen ausgewertet werden

sollen. Eine Festlegung, daB aile Anderungsdaten aus den Quellsystemen etwa ab

Mitternacht extrahiert werden sollen, urn die Schwachlastzeit auszunutzen, ist etwa

dann zu pauschal, wenn auch weitere Prozesse auf den entsprechenden Systemen wah-

Phasenspeziflsche Anforderungen 235

rend der knappen Zeitspanne ohne regular-en Transaktionsbetrieb durchgefUhrt werden

sollen.

Automatisierte Funktionen zur Aktualisierung des Data Warehouse erfordern tiber die

genannten Steuerungsaspekte hinaus auch definierte Vorgehensweisen fUr den Fall des

Fehlschlagens der Extraktion des Deltas aus einer der Datenquellen oder der Trans

formationsschritte. Hier ist zur Verringerung der Notwendigkeit manueller Interaktion

Funktionalitat wichtig, die auftretende Fehlersituationen zumindest protokolliert und

gegebenenfalls tiber die Scheduling-Komponente nach einer Wartezeit einen neuen

Versuch startet.

Aile Updatevorgange - automatisiert oder yom Administrator angestoBen - erfordern

eine genaue BuchfUhrung tiber den exakten Zeitpunkt der letzten Aktualisierung. Dies

betrifft einerseits Datum und Uhrzeit, andererseits aber auch den Bezug zu geschaftli

chen Ereignissen, die EinfluB auf das Datenmaterial haben, wie etwa ein taglicher oder

wochentlicher RechnungsabschluB. Variable Updatezeitpunkte gemaB den obigen

Uberlegungen erfordern dariiber hinaus die Synchronisation der Updates aus den un

terschiedlichen Datenquellen dergestalt, daB moglichst nur Daten derselben Peri ode

zusammengefUhrt werden. Ein Beispiel mag die Uberlegungen hinsichtlich der Anfor

derungen an Managementfunktionen fUr groBere Data Warehouse-Umgebungen illu

strieren:

Ein zentrales Data Warehouse sei mit bestimmten Daten tiber die Geschaftsvorfalle

eines international operierenden Unternehmens besttickt. Zur Aktualisierung des Data

Warehouse werden als Quellsysteme wochentlich die operativen Systeme der einzelnen

Landergesellschaften abgefragt, nachdem RechnungsabschluBarbeiten fUr die abgelau

fene Woche durchgefUhrt worden sind. Die Vorgabe eines festen, durch Datum und

Uhrzeit bestimmten Aktualisierungszeitpunktes greift hier zu kurz, da so weder die an

den einzelnen Standorten unterschiedlichen Zeiten mit hoher Systemauslastung durch

das Tagesgeschaft noch die Geschaftsregel "Update nach dem RechnungsabschluB"

berticksichtigt werden. Erforderlich erscheint daher die funktionale Verkntipfung des

Updatezeitpunktes mit dem genannten vorhergehenden Ereignis der Vollendung des

Rechnungsabschlusses, so daB auch etwa vorkommende Verzogerungen an einzelnen

Standorten berticksichtigt werden und zu der in diesem Szenario zweckrnaBigen Ver

schiebung der Datenextraktion fUr das Data Warehouse fUhren. Dann ist allerdings zu

beachten, daB der verspatete Eingang eines Teils der Quelldaten bei den Aktualisie-


rungsUiufen im Data Warehouse BerUcksichtigung finden muB, da sonst unvollstandi

ges Zahlenmaterial zu Fehlinterpretationen flihren kann.

Daher kann als weitere Anforderung postuliert werden, daB zwar der Extraktionszeit

punkt aus den Quellsystemen aus den vorgenannten GrUnden variabel sein sollte, je

doch eine Ubernahme der Daten in das Data Warehouse in Abhangigkeit von der Art

und Bedeutung der Daten gegebenenfalls erst erfolgen darf, wenn aile Teildatenbe

stande aus den unterschiedlichen Quellen vorliegen und integriert werden konnen.616

Die beschriebenen Funktionen dienen der Untersttitzung des Betriebs des Data Ware

house. Hier kann die Automatisierung von Routineaufgaben, die zur Aufrechterhaltung

eines aktuellen Datenbestands notwendig sind, entsprechende personelle Ressourcen

entlasten.

In engem Zusammenhang mit den oben postulierten Anforderungen hinsichtlich der

Metadatenverwaltung steht eine Untersttitzung der Wartung und Pflege der Transfor

mationsfunktionen. Es ist zu fordern, daB im Faile sich andernder umgebender Systeme

eine moglichst einfache Anpassung untersttitzt wird. So kann etwa ein Werkzeug,

dessen Konzept weitgehend vorgefertigte Module vorsieht, die hinsichtlich der Quell

systeme und der flir eine Datenextraktion vorgesehenen Schemaobjekte nur parametri

siert werden mUssen, leicht an Veranderungen in den Quellsystemen angepaBt werden.

Aufwendige Modifikationen erscheinen dagegen bei Systemen erforderlich, die aus

spezifischen, stark an eine konkrete Situation angepaBten Programmen bestehen.

Analog soUte eine Anpassung der Transformationswerkzeuge auch dann ohne groBen

Aufwand moglich sein, wenn hinsichtlich der Struktur des Data Warehouse oder seiner

technischen Basis Anderungen auftreten. Dieser Aspekt erscheint jedoch weniger

bedeutsam, da hier ein groBer Teil des Problembereichs der Heterogenitat wegfallt und

nur eine einzelne Schnittstelle zu berticksichtigen ist.

Zusammenfassend kann festgehalten werden, daB ein Kernerfordernis darin besteht,

das Data Warehouse und damit auch die Komponenten zu dessen Datenversorgung

einfach an veranderte Rahmenbedingungen anpassen zu konnen. MUssen dagegen auch

bei kleinen Veranderungen an den Quelldatenbestanden aufwendige Anpassungen oder

Neuentwicklungen der Transformationskomponente vorgenommen werden, so entste

hen hohere Kosten, welche die Wirtschaftlichkeit des Gesamtsystems verschlechtern.

616 Dies setzt voraus, daB Mbglichkeiten zur Zwischenspeicherung der extrahierten Daten vorhanden sind.


Dariiber hinaus besteht die Gefahr, daB die Strukturen der Transformationskomponente

zu starr ausgelegt sind und eine zeitnahe Versorgung mit Daten bereits nach kurzer

Zeit nicht mehr gewahrleistet werden kann. Dies stellt den Gesamtnutzen des Data

Warehouse in Frage und kann so zum Scheitern des Projekts flihren.

5.4.3 Ausbauphase

Einer der Kerngedanken einer Data Warehouse-Umgebung liegt in der Verwendung

von Daten, die aus verschiedenen Quellsystemen stammen. Dieser Aspekt gewinnt an

Bedeutung, wenn im Rahmen der Ausbauphase zusatzliche Datenquellen flir die brei

ter werdende thematische Basis des Data Warehouse erschlossen werden. Vorausset

zung hierflir ist, daB neben den im vierten Kapitel ausflihrlich erorterten syntaktischen

und semantischen Heterogenitaten auch die technischen Heterogenitaten iiberbriickt

werden konnen, die zwischen den einzelnen im Unternehmen vorhandenen Systemen

bestehen. Extraktionstools miissen also auf im Unternehmen vorhandene Quellsysteme

zugreifen konnen. Hierbei sollte moglichst keine Beschrankung auf die Systeme, die zu

Projektbeginn flir das Data Warehouse als relevant erachtet werden, erfolgen. Viel

mehr ist dem Umstand Rechnung zu tragen, daB durch wachsende oder sich wandelnde

Themenbereiche, die mit dem Data Warehouse abgedeckt werden sollen, eventuell

auch Datenquellen verwendet werden miissen, die iiber die zunachst erforderlichen

hinausgehen. Diese wichtige Anforderung laBt sich in zwei Teilaspekten konkretisie-

reno

Als elementare Voraussetzung ist erstens anzusehen, daB iiberhaupt die technischen

Moglichkeiten zum lesenden Zugriff auf die verschiedenen Datenquellen gegeben

sind. Dies setzt voraus, daB einerseits die - auBerhalb des Kernbereichs dieser Be

trachtung liegenden - Infrastrukturvoraussetzungen gegeben sind, also zu allen Quell

systemen zumindest irgendeine Form von Netzwerkverbindung besteht.617 Daneben

miissen auch die entsprechenden Softwarekomponenten verfligbar sein, die es erlau

ben, iiber Schnittstellen zumindest lesend auf die Daten in diesen Systemen zuzugrei

fen.

617 Das Vorliegen dieser Voraussetzung kann keineswegs als von vornherein selbstverstandlich angesehen werden, wenn etwa GroBrechnersysteme angeschlossen werden sollen, die in erster Linie fUr eine Kommunikation mit den angeschlossenen Benutzerterminals ausgelegt sind. V gl. zu Infrastrukturaspekten Kimball et al. (1998), S. 511 f.


Zweitens sollten die Schnittstellen in dem Sinne transparent sein, daB sich der Zugriff

auf die verschiedenen Datenquellen tiber eine einheitliche BenutzungsoberfHiche reali

sieren laBt. Mtissen dagegen mehrere Middleware-Komponenten mit jeweils eigen

standigen Benutzungsoberflachen zu deren Parametrisierung verwendet werden, steigt

der erforderliche Lernaufwand fUr die Administratoren, die zusatzliche Datenquellen

in das Data Warehouse integrieren wollen, an. Homogene Losungen, die tiber eine

gemeinsame Benutzungsoberflache aile relevanten Datenquellen verftigbar machen

konnen, erleichtern dagegen im UmkehrschluB die Integration heterogener Systeme im

Data Warehouse.

Ein geeigneter technischer Weg, den Zugriff auf eine moglichst hohe Zahl von Daten

quellen zu ermoglichen, kann in der Spezifikation einer Programmierschnittstelle

(API) liegen, die es erlaubt, Middleware-Module fUr nicht unmittelbar untersttitzte

Quellsysteme zu erstellen und in die Transformationskomponente zu integrieren.

Ein moglichst homogener Zugriff auf die verschiedenen Datenquellen, bei dem tiber

leistungsfahige Middleware-Komponenten Transparenz hergestellt wird, indem von

den technischen Besonderheiten beim Zugriff auf die unterschiedlichen Systeme ab

strahiert wird, ist bereits bei der Erstellung der ersten Data Warehouse-Prototypen von

Interesse, wird doch auf diese Weise der einfache und damit schnell zu realisierende

Zugriff auf mehrere Quellsysteme ermoglicht. Genauso relevant erscheint dieser

Aspekt jedoch im Hinblick auf die Ausbau- und Erweiterungsmoglichkeiten des Sy

stems. Die Flexibilitat der Datenversorgung fUr das Data Warehouse erscheint deutlich

eingeschrankt, wenn fUr zusatzliche Datenquellen eigenstandige Middleware

Komponenten beschafft, installiert und in die Gesamtarchitektur der Transformations

komponente integriert werden mtissen.

Wird die Anforderung eines hohen Grades an Interoperabilitat nicht in ausreichendem

MaBe erfUllt, besteht daher die Gefahr, daB der flexible Ausbau des Data Warehouse

gehemmt wird, wenn weitere Vorsysteme als Datenlieferanten erschlossen werden

mtissen, da prohibitiv hohe Kosten oder Probleme bei der Umsetzung auftreten. So

wtirden von vornherein die Ausbaumoglichkeiten eingeschrankt.

Weniger bedeutsam ist diese Anforderung dagegen, wenn ohnehin aile Datenbestande,

die auch bei visionarer Betrachtung zur Dbernahme in das Data Warehouse in Frage

kommen, in nur wenigen unterschiedlichen Systemen vorliegen. In einem solchen

Anwendungsfall - der etwa dann gegeben sein kann, wenn bereits in breitem MaBe fUr


die operativen Anwendungen eine integrierte Standardsoftware verwendet wird - kann

dieses Kriterium mit untergeordneter Prioritat behandelt werden.

Mit zunehmendem Umfang des Data Warehouse steigt auBerdem die Notwendigkeit,

komplexere Verknupfungen (Mappings) zwischen Schemaobjekten in den Quelldaten

bestanden und dem Data Warehouse vorzunehmen. Die ersten Prototypen, die - wie

beschrieben - eher einfache Themenbereiche abdecken, erfordern zunachst entspre

chend nur wenig komplexe Funktionen zur Abbildung der Quelldaten auf das Daten

modell des Data Warehouse. Werden jedoch zusatzliche Themenbereiche mit dem

graBer werdenden Data Warehouse abgedeckt und mussen die entsprechenden Daten

aus verschiedenen Quellsystemen akquiriert werden, steigen die Anforderungen an die

dazu notwendigen Schematransformationen. Besondere Bedeutung gewinnt dieser

Aspekt, wenn nicht-relationale Datenquellen auf die Strukturen eines relationalen Data

Warehouse-Datenmodells umgesetzt werden mussen, oder wenn fUr ein Data Ware

house, dem eine mehrdimensionale Datenbank zugrundeliegt, wohl nahezu aile Quell

daten in dieser Hinsicht umgewandelt werden mussen.

Neben den Schematransformationen gewinnen mit dem Wachsen der Anzahl verwen

deter Datenquellen auch Funktionen zur Datenaufbereitung und zur Homogenisierung

des Datenbestands an Relevanz.618 Auch fUr diese Funktionen gilt, daB die dabei zu

beseitigenden Heterogenitaten bei anfanglichen Prototypen einer Data Warehouse

Lasung weniger bedeutsam sind, wei I die Anzahl verwendeter Datenquellen kleiner ist

und bei einem prototypischen Vorgehen zweckmaBigerweise Themenbereiche mit

problembehafteten Daten gezielt ausgeblendet werden. Sie rucken jedoch mit zuneh

mender Breite des Data Warehouse in den Mittelpunkt der Betrachtung.

Hier ist ein Zielkonflikt zu den anfangs insbesondere fUr die Prototyp-Phase geforder

ten Aspekten der schnellen Erzielbarkeit von Ergebnissen erkennbar, da die Funktio

nalitat zu Bewaltigung komplexer Schematransformationen nicht unbedingt dazu fUhrt,

daB ein entsprechendes Werkzeug fUr den Benutzer leicht erlernbar und schnell ein

setzbar ist; etwa wenn Programmcode in einer prozeduralen Programmiersprache ge

schrieben werden muB, urn komplexere Funktionen abzubilden.

Insgesamt kann wohl davon ausgegangen werden, daB zur Problemanalyse und Imple

mentierung komplexer Transformationsfunktionen generell Programmierarbeiten er

forderlich sind, da vorgedachte Umwandlungsroutinen, die nur noch konfiguriert wer-

618 V gl. Abschnitt 4.3.2.3.


den mtissen, ab einem gewissen Schwierigkeitsgrad der Konvertierung an Grenzen

stoBen. Damit tritt der Aspekt der leichten Bedienbarkeit zwangsHiufig in den Hinter

grund.

Bedeutsam erscheint dagegen auch an dieser Stelle, daB die implementierten Funktio

nen etwa tiber die Metadatenkomponente sorgfaltig dokumentiert werden konnen, so

daB die durchgefiihrten Transformationsschritte nachvollziehbar sind und die Software

wartbar bleibt. So besteht beispielsweise die Gefahr spater nicht erkannter Abhangig

keiten, wenn Transformationsfunktionen durch viele einzelne Datenbanktrigger im

plementiert werden, die nicht miteinander verkntipft sind. Dies verschlechtert die

Moglichkeiten, die ausgefiihrten Funktionen nachzuvollziehen und erschwert die

Wartung und Erweiterung der Transformationskomponente erheblich.

Auch diese Anforderung gewinnt erst dann an Prioritat, wenn das Data Warehouse zu

einer groBeren Losung ausgebaut wird. Kann hier die Funktionalitat nicht befriedigen,

besteht die Gefahr, daB zusatzliche Programme erforderlich werden, urn die notwendi

gen Transformationsschritte durchzufiihren. Deren Beschaffung oder Erstellung und

Integration in das Gesamtsystem fiihrt jedoch zu weiteren Kosten und mag aufgrund

fehlender Ressourcen nicht immer durchfiihrbar sein. Zudem wird die Nutzung und

Wartung der Transformationskomponente in ihrer Gesamtheit deutlich erschwert,

wenn hier mehrere eigenstandige Tools verwendet werden mtissen. In diesem Fall

treten wiederum Heterogenitaten auf, die tiber entsprechend zu schaffende, zusatzliche

Schnittstellen oder Datenaustauschformate tiberbriickt werden mtissen.

5.4.4 Betriebsphase

Die Investition in ein analyseorientiertes Informationssystem kann aufgrund der erziel

baren Wettbewerbsvorteile als strategisch bedeutsam fiir das Unternehmen angesehen

werden. Die im Data Warehouse hinterlegten Daten bleiben auch und gerade fiir zu

ktinftige Auswertungen tiber Vergangenheitsdaten eine wertvolle Analysebasis. Ein

einmal erfolgreich entwickeltes und eingefiihrtes Data Warehouse wird daher wohl

tiber einen langeren Zeitraum eingesetzt. Es ist somit zu erwarten, daB die Datenbasis

zwar durch die AktualisierungsHiufe einerseits und das Auslagern alter Detaildaten

andererseits sowie durch Modifikationen am Datenmodell einem steten Veranderungs

prozeB unterworfen ist, in einer Gesamtbetrachtung aber eine lange Lebensdauer hat,

die tiber die Nutzungszeitraume von Infrastrukturkomponenten wie z.B. der Hardware

oder dem Betriebssystem hinausgehen. Ein Wechsel der Infrastrukturkomponenten


kann - auBer aus Modernisierungsgrunden - auch erwogen werden, urn veranderten

unternehmensweiten Standards hinsichtlich der verwendeten Hardware, Software oder

verwendeter Systemarchitekturen Rechnung zu tragen.

Diese Falle machen es notwendig, das Data Warehouse in eine andere Hard- oder

Softwareumgebung oder auf ein anderes Datenbankmanagementsystem zu iibertragen

und entsprechende Anpassungen auch hinsichtlich der vorgelagerten Transformations

komponente vorzunehmen. Migrationserfordernisse konnen sich dariiber hinaus etwa

auch ergeben, wenn das Data Warehouse in eine verteilte Systemarchitektur iiberflihrt

werden soli oder wenn es aufgrund zu knapper Offline-Zeiten der operativen Systeme

notwendig wird, die Transformationskomponente auf einen Rechner mit besonders

hoher Verarbeitungsleistung zu verlagern.

Diese im Interesse einer hohen Zukunftssicherheit der Data Warehouse-Losung be

deutsamen Aspekte erfordern ein moglichst hohes MaE an Unabhangigkeit der Sy

stemkomponenten zueinander. In bezug auf die Transformationskomponente ist hier

zunachst zu fordern, daB Unabhangigkeit von der Data Warehouse-Datenbank besteht,

so daB bei einem Austausch des dem Data Warehouse zugrundeliegenden Datenbank

managementsystems oder anderer Systemkomponenten aus den genannten Grunden die

bereits vorhandene Transformationskomponente ohne wesentliche Anpassungen funk

tionsfahig bleibt.

AuBerdem sollte auch das Transformationstool flir verschiedene Hardware- und Be

triebssystem-Plattformen verfiigbar bzw. mit Systemen auf anderen Plattformen kom

patibel sein. Dies betrifft sowohl die Administrationsschnittstelle, die der Definition

und Implementierung der erforderlichen Extraktions- und Transformationsfunktionen

dient, als auch die Module, die diese Funktionen, primiir im Zuge regelmiiBiger Aktua

lisierungslaufe flir das Data Warehouse, ausflihren. Insbesondere bei den letztgenann

ten Modulen erscheint eine AnpaBbarkeit an steigende Anforderungen hinsichtlich der

Verarbeitungsgeschwindigkeit bedeutsam. Insofern ist hier die Hardwareunabhangig

keit als wesentliche Anforderung zu klassifizieren. Sie kann durch die Verwendung

standardisierter, flir verschiedene Betriebssysteme verfligbarer Programmiersprachen

zur Implementierung der Funktionen erreicht werden. Ein weiterer Losungsansatz ist

in der Nutzung von Werkzeugen erkennbar, die flir mehrere Betriebssysteme angebo

ten werden und eine leichte Ubertragung der konkreten Problemstrukturen ermogli

chen.


1m Faile der Verwendung standardisierter, von einem entsprechenden Produktanbieter

bezogener Software ist als weitere wesentliche Anforderung die wirtschaftliche Stabi

liUit des Lieferanten und des sen strategische Ausrichtung zu beachten. Wichtig ist, daB

des sen Produktportfolio moglichst kontinuierlich an neu auf den Markt kommende,

relevant werdende Hardware-, Betriebssystem- und Datenbanksystemkomponenten

angepaBt wird.619 Die Bedeutung dieses Aspekts ist als hoch einzuschatzen, da der

Markt von kurzen InnovationszykIen gepragt ist und Investitionen in Softwareprodukte

und darauf basierende Entwicklungen zur Anpassung an die eigenen Anforderungen

schnell in eine Sackgasse fUhren konnen, wenn von Seiten des Herstellers keine Wei

terentwicklung mehr erfolgt, dieser vom Markt verschwindet oder er sich anderen

Produkten zuwendet.

5.5 Phasentibergreifende Aspekte

1m vorhergehenden Abschnitt wurden Anforderungen beschrieben, die sich in einzel

nen Phasen des Data Warehouse-Lebenszyklus jeweils als besonders relevant erwei

sen. Die isolierte Betrachtung der Phasen erscheint zur Strukturierung des Anforde

rungskataloges zweckmaBig. 1m Zuge der Entscheidungen tiber die Auswahl eines

Produktes oder die individuelle Programmierung der Software fUr die Transformati

onsaufgaben, die durch derartige UberIegungen untersttitzt werden konnen, darf eine

Betrachtung der Zusammenhange, die zwischen den Anforderungen bestehen, nicht

vergessen werden. Es werden Konflikte erkennbar, die sich z.B. aus dem Postulat

einfacher Bedienung fUr die frtihen Projektphasen und der Forderung nach der Mog

lichkeit zur Abbildung auch komplexer Transformationsfunktionen ergeben. Auch der

Aspekt der in fortgeschrittenen Projektphasen bedeutsamen Hardware- und Betriebssy

stemunabhangigkeit harmoniert nicht mit den zu Projektbeginn vorhandenen Priorita

ten, denn einfach zu bedienende Werkzeuge basieren heute zumeist auf grafischen

Benutzungsoberflachen. Dadurch ist eine Ubertragung auf andere Betriebssysteme in

der Regel jedoch problematisch.

Hier muB also im Rahmen des Projektplanungsprozesses sorgfaltig zwischen den An

forderungen abgewogen werden, damit nicht einzelnen Aspekten zu Lasten der erfor

derlichen Gesamtfunktionalitat eine zu groBe Bedeutung beigemessen wird. Daher ist

619 V gl. Goranson (1998), S. 719f.

Phasenlibergreifende Aspekte 243

eine sorgfaltige Planung des gesamten Transformationsprozesses erforderlich, urn die

Gefahr nachtraglich nur schwer korrigierbarer Fehlentwicklungen zu verringern. Dem

gegeniiber darf aber nicht verkannt werden, daB dies aufgrund der beschriebenen Cha

rakteristika cines Data Warehouse-Projekts mit den in der Planungsphase eher diffusen

Spezifikationen des gewiinschten Funktionsumfangs und der mangelnden Erfahrung

mit Data Warehouse-Projekten problematisch ist. Als Indiz fUr diese Schwierigkeiten

kann angefiihrt werden, daB Untersuchungen zufolge in Data Warehouse-Projekten

sehr haufig die Qualitat der operativen Daten iiberschatzt und der Aufwand fUr die

Transformation unterschatzt wird.62o

Ein Ansatz zur U:isung dieser Problematik kann in der Modularisierung der Transfor

mationskomponente liegen. Diese Vorgehensweise erlaubt es, jeweils besonders anfor

derungsadaquate Werkzeuge zu verwenden. Erforderlich ist dann jedoch, die Einzel

werkzeuge so in die Gesamtarchitektur einzubetten, daB ein konsistentes System ent

steht und nicht nur eine Sammlung von Einzelprogrammen, die neue, zusatzliche Hete

rogenitatsprobleme aufwirft. Dies wiederum erfordert standardisierte Schnittstellen

und eine moduliibergreifende Verwaltungskomponente. Hier bietet es sich an, eine

Kombination von Produkten desselben Herstellers einzusetzen, urn ein zumindest

weitgehend reibungsloses Zusammenspiel der Module zu gewahrleisten. Herstel

leriibergreifend ist zwar der Datenaustausch leicht realisierbar, die Forderung nach

gemeinsamer Administration und der Sicherstellung konsistenter Funktionalitat diirfte

mangels anerkannter Standards fUr entsprechende Metadaten jedoch nur schwer erfUll

bar sein, so daB an dieser Stelle Raum fUr weiterc Entwicklungen bleibt.

AbschlieBend erfolgt eine Zusammenfassung der Ergebnisse sowie ein Ausblick auf

weiterfUhrende Fragestellungen, die sich im Zusammenhang mit der Transformation

und Integration von Daten zu ihrer Nutzung in Informationssystemen ergeben.

620 Vgl. Soeffky (1999), S. 14.

Zusammenfassende Bewertung und Ausblick 245

6 Zusammenfassende Bewertung und Ausblick

Eine der groBten Herausforderungen beim Aufbau eines analyseorientierten Informati

onssystems liegt in der Beschaffung aktueller und integrierter Daten in angemessener

Qualitat flir das Data Warehouse, das als zentrale datenspeichernde Komponente dieser

Systeme dient. Die Quelldaten stammen aus den verschiedenen operativen Systemen

und miissen umfangreichen Transformationsprozessen unterzogen werden, damit sie

den genannten Anforderungen entsprechen. Dies ist von groBer Bedeutung, weil sich

nur Daten adaquater Qualitat als Basis flir Informationen zur fundierten Entschei

dungsunterstiitzung eignen. Fehler in den Data Warehouse-Datenbestanden wirken

sich zwangslaufig auch auf aggregierte oder in anderer Form abgeleitete Werte aus und

beeintrachtigen so die Analysefunktionalitat und flihren zu ungenauen oder gar un

brauchbaren Ergebnissen. Letztlich sinkt die Akzeptanz des Systems durch die An

wender, so daB durch schlechte Datenqualitat der Erfolg eines Data Warehouse

Projekts in Frage gestellt sein kann.

Die Relevanz von Fragestellungen, die sich mit der Extraktion, Transformation und

Integration operativer Daten flir ein Data Warehouse beschaftigen, wird durch Unter

suchungen belegt, nach denen ca. 70 % der gesamten Dauer eines Data Warehouse

Projekts auf diese Aufgaben entfallen. Die Modellierung und Implementierung der

Data Warehouse-Datenbank und der Werkzeuge flir die Endbenutzer lassen sich dage

gen in den verbleibenden 30 % der Zeit bewerkstelligen.621

Die Ursachen flir die Probleme, die beim Fiillen des Data Warehouse auftreten, lassen

sich auf verschiedene Formen von Heterogenitat zurUckfiihren, durch welche die ope

rativen Systeme im Unternehmen und damit die Daten gekennzeichnet sind. Zur An

naherung an die Thematik wurden im zweiten und dritten Kapitel die Kerncharakteri

stika der operativen und der analyseorientierten Informationssysteme beschrieben.

Breiten Raum nahm in bezug auf die operativen Systeme neben der Beschreibung der

Ursachen und Erscheinungsformen der Heterogenitat auch die Diskussion verschiede

ner Formen der verteilten und fOderierten Datenspeicherung ein, da in den hier zu

grundeliegenden Konzepten der Bildung iibergreifender Schemata zur Verkniipfung

auch heterogener Systeme analoge Probleme auftreten.

621 Vgl. Soeffky (1999), S. 14.

246 Zusammenfassende Bewertung und Ausblick

Auf der Grundlage der gewonnenen Erkenntnisse tiber die Charakteristika der Quell

daten und die Anforderungen an den Data Warehouse-Datenbestand, der sich aus den

Zielen und Aufgaben eines analyseorientierten Informationssystems herleiten BiBt,

konnte im vierten Kapitel eine Problemanalyse vorgenommen werden. Die erforderli

chen Schritte zur Uberfiihrung der Daten in das Data Warehouse wurden dabei in die

Teilaufgaben der Extraktion, der Transformation im engeren Sinne und der Integration

in den Zieldatenbestand strukturiert. 1m Fall der Transformation wurden zahlreiche

EinzelmaBnahmen beschrieben, die der Uberwindung der unterschiedlichen Arten der

Heterogenitat und der Verbesserung der Datenqualitat dienen.

Ftir die Durchfiihrung dieser MaBnahmen werden Softwarewerkzeuge eingesetzt. Da

die Transformation den beschriebenen groBen Anteil an der Projektdauer hat und damit

auch einen entsprechenden Anteil der Kosten verursacht, und zudem das Ergebnis, das

sich in der Qualitat des Data Warehouse-Datenbestands ausdrtickt, erheblich zum

Projekterfolg beitragt, ist dieser Software groBe Bedeutung zuzumessen. Daher wurden

im fiinften Kapitel Anforderungen beschrieben, deren Erftillung einen positiven Er

gebnisbeitrag zum Projekterfolg liefern kann. Diese beziehen sich nicht auf die zuvor

bereits beschriebene Kernfunktionalitiit, sondern auf Aspekte, welche die Einbettung

dieser Tools in ein langerfristig angelegtes Data Warehouse-Projekt und damit in das

analyseorientierte Informationssystem betreffen.

In den letzten Jahren hat sich die Anzahl der am Markt verfiigbaren Werkzeuge stark

erhoht. Die sehr unterschiedlichen Funktionsschwerpunkte dieser Tools lassen jedoch

erkennen, daB vielfach mehrere Werkzeuge von verschiedenen Herstellern oder eigen

programmierte Erganzungskomponenten eingesetzt werden mtissen, urn aile erforderli

chen Transformationsschritte abzudecken. Problematisch daran erscheint, daB so wie

derum neue Heterogenitaten aufgebaut werden. Zwar ist die Ubergabe von Daten zwi

schen den Tools moglich, von einer integrierten Losung konnte jedoch erst dann die

Rede sein, wenn die einzelnen Werkzeuge durch eine gemeinsame, zentralisierte Me

tadatenkomponente gesteuert werden. Diese setzt jedoch einheitliche Schnittstellen

auch auf Metadatenebene voraus. Nach dem derzeitigen Stand der Diskussion scheint

auf diesem Gebiet jedoch noch erheblicher Forschungs- und letztlich auch Normie

rungsbedarf zu bestehen. DaB hier vie I im FluB ist, laBt sich aus den Aktivitaten her

stellertibergreifender Gremien und auch aus Herstellerpublikationen ableiten, in denen

die entsprechenden Themen breiten Raum einnehmen.

Zusammenfassende Bewertung und Ausblick 247

In diesem Zusammenhang kann auch die Frage aufgeworfen werden, inwieweit die

Funktionalitat zum Zugriff auf die operativen Systeme nicht nur den Entwicklern in

einem Data Warehouse-Projekt, sondern auch den Endanwendern zuganglich gemacht

werden kann und sollte. Diese Moglichkeit ist zweckmaBig, urn dem Nutzer den Zu

gang zu Daten zu eroffnen, die zwar nicht im Data Warehouse, wohl aber in den Vor

systemen vorhanden sind. Ebenso konnte eine Riickwrutstransformation erfolgen,

wenn Analyseergebnisse auch in die operativen Systeme Eingang finden sollen. Es

erscheint auf der anderen Seite problematisch, dorthin Wege durch unterschiedliche

Tools mit jeweils eigenstandigen Bedienungskonzepten zu eroffnen, die bei unsach

gemaBer Nutzung auch die Betriebssicherheit der operativen Systeme gefahrden. Eine

zentrale Metadatenverwaltung konnte es erlauben, iiber eine komfortable Benutzungs

schnittstelle unter Einhaltung der gleichfalls metadatengesteuert iiberwachten Datensi

cherheits- und Datenschutzfunktionen durch die Datenbestande im Unternehmen zu

Fragestellungen der Transformation und Integration von Daten werden derzeit iiber

wiegend im Zusammenhang mit Data Warehouse-Projekten diskutiert. Die sich daraus

ergebenden Erkenntnisse konnen jedoch auch fiir zahlreiche andere Aufgabenstellun

gen Anwendung finden, die sich im Rahmen der Informationsverarbeitung im Unter

nehmen ergeben und die unter dem Oberbegriff der Migration zusammengefaBt wer

den. Als Beispiel sei die AblOsung alter Informationssysteme durch eine Standardan

wendungssoftware genannt. Hier sind hinsichtlich der Aufgabenstellung der Integrati

on der Daten und der Verbesserung ihrer Qualitat Parallelen zur Data Warehouse

Thematik erkennbar.

In der Einleitung dieser Arbeit wurde die These der Ubersummativitat eines Systems

erwahnt, nach der ein System mehr umfaBt als die Summe seiner Teilsysteme. Diese

erfahrt im vorliegenden Zusammenhang eine praktische Bestatigung, wenn bei einer

iibergreifenden Nutzung der Datenbestande aller Informationssysteme im Unterneh

men durch ihre Integration im Data Warehouse ein Zusatznutzen dadurch entfaltet

wird, daB hochwertige Informationen zur Entscheidungsunterstiitzung gewonnen wer

den konnen.


Literaturverzeichnis

ABERDEEN GROUP (1995): Aberdeen Profile: Exploring Intersolv's Virtual Data Warehouse, Aberdeen Group, Inc., 0.0. 1995. http://www.aberdeen.com!secure/profileslintersolv/interslv.htm, 24.06.1996.

AEBI, DANIEL (1998): Zeitsprung 2000: Beispiele, Checklisten, Losungen fUr Manager und Informatiker, Mtinchen, Wien 1998.

AKINDE, MICHAEL 0.; JENSEN, OLE G.; BOHLEN, MICHAEL H. (1998): Minimizing Detail Data in Data Warehouses, in: Schek et al. (1998), S. 293 - 307.

ALLEN, FRANK W.; LOOMIS, MARY E. S.; MANNINO, MICHAEL V. (1982): The Integrated Dictionary/Directory System, in: ACM Computing Surveys, Vol. 14, No.2, June 1982, S. 245 - 286.

ANAHORY, SAM; MURRAY, DENNIS (1997): Data Warehouse, Planung, Implementierung und Administration, Bonn et al. 1997.

ANDERSON, CARRIE; WENDELKEN, DAVID (1996): The Oracle Designer/2000 Handbook, Reading et al. 1996.

ApPELRATH, HANS-JORGEN (Hrsg.) (1991): Datenbanksysteme in Btiro, Technik und Wissenschaft, Berlin et al. 1991.

BALDERJAHN, INGO; GABRIEL, ROLAND (Hrsg.) (1995): Aktuelle Aufgaben und Entwicklungen der Betriebswirtschaft. Beitrage zu einem Symposium. Arbeitsbericht Nr. 61 des Institutes fUr UnternehmungsfUhrung und Unternehmensforschung, Ruhr-Universitat Bochum, Bochum 1995.

BALZERT, HELMUT (1982): Die Entwicklung von Software-Systemen, Mannheim et al. 1982.

BALZERT, HELMUT (Hrsg.) (1 992a): CASE: Systeme und Werkzeuge, 4. Auflage, Mannheim 1992.

BALZERT, HELMUT (1992b): Ein Dberblick tiber die Methoden- und Werkzeuglandschaft, in: Balzert (1992a), S. 29 - 104.

BALZERT, HELMUT (1996): Lehrbuch der Software-Technik: Software-Entwicklung, Heidelberg et al. 1996.

BALZERT, HELMUT (1998): Lehrbuch der Software-Technik: Software-Management, Software-Qualitatssicherung, Unternehmensmodellierung, Heidelberg et al. 1998.

BANCILHON, FRAN<;:OIS; DEWITT, DAVID J.(Hrsg.) (1988): Very Large Data Bases: Proceedings of the Fourteenth International Conference on Very Large Data Bases, Palo Alto 1988.

250 Literaturverzeichnis

BARCLAY, TOM ET AL. (1994): Loading Databases Using Dataflow Parallelism, in: SIGMOD Record, Vol. 23, No.4, December 1994, S. 72 - 83.

BARKER, RICHARD (1990): CASE*Method Tasks and Deliverables, Wokingham et al. 1990.

BARKOW, GEORG ET AL. (1989): Begriffliche Grundlagen fUr die friihen Phasen der Softwareentwicklung, in: Information Management, 4. Jg., Nr. 4, 1989, S. 54 - 60.

BARQUIN, RAMON c.; EDELSTEIN, HERBERT A. (Hrsg.) (1997a): Building, Using and Managing the Data Warehouse, Upper Saddle River 1997.

BARQUIN, RAMON c.; EDELSTEIN, HERBERT A. (Hrsg.) (1997b): Planning and Designing the Data Warehouse, Upper Saddle River 1997.

BARQUIN, RAMON c.; PALLER, ALAN; EDELSTEIN, HERBERT A. (1997): Ten Mistakes to Avoid for Data Warehousing Managers, in: BarquinlEdelstein (I 997b), S. 145 - 156.

BARTSCH-SPORL, BRIGITTE (1989): Der relationale Ansatz, in: Neumaier (1989), S.9-21.

BATINI, CARLO; CERI, STEFANO; NAVATHE, SHAMKANT B. (1992): Conceptual Database Design: An Entity-Relationship Approach, Redwood City et al. 1992.

BATINI, CARLO; LENZERINI, MAURIZIO; NAVATHE, SHAMKANT B. (1986): A Comparative Analysis of Methodologies for Database Schema Integration, in: ACM Computing Surveys, Vol. 18, No.4, December 1986, S. 323 - 364.

BEHME, WOLFGANG (1996): Business-Intelligence als Baustein des Geschiiftserfolgs, in: Mucksch/Behme (1996), S. 27 - 45.

BEHME, WOLFGANG; MUCKSCH, HARRY (1998a): Auswahl und Klassifizierung externer Informationen zur Integration in ein Data Warehouse, in: UhrlBreuer (1998), S. 85 - 104.

BEHME, WOLFGANG; MUCKSCH, HARRY (l998b): Die Notwendigkeit einer entscheidungsorientierten Informationsversorgung, in: Mucksch/Behme (1998a), S.3-31.

BERG, DENNIS; HEAGELE, CHRISTOPHER (1997): Improving Data Quality: A Management Perspective and Model, in: BarquinlEdelstein (1997a), S. 85 - 99.

BERNUS, PETER; MERTINS, KAI; SCHMIDT, GUNTER (Hrsg.) (1998): Handbook on Architectures of Information Systems, Berlin et al. 1998.

BERTHEL, JURGEN (1992): Informationsbedarf, in: Frese (1992), Sp. 872 - 886.

BERTINO, ELISA; MARTINO, LORENZO (1993): Object-Oriented Database Systems: Concepts and Architectures, Wokingham et al. 1993.


BIETHAHN, JORG; MUCKSCH, HARRY; RUF, WALTER (1997): Ganzheitliches Informationsmanagement, Band II: Entwick1ungsmanagement, Miinchen, Wien 1997.

BISCHOFF, JOYCE (1994): Achieving Data Warehouse Success, in: Database Programming & Design, No.7, July 1994, S. 27 - 33.

BISCHOFF, JOYCE; ALEXANDER, TED (1997): Data Warehouse: Practical Advice from the Experts, Upper Saddle River 1997.

BISCHOFF, RAINER (1990): Die Auswahl von Informatikprodukten, in: KurbeIJStrunz (1990), S. 793 - 811.

BISSANTZ, NICOLAS (1998): Aktive Managementinformationen und Data Mining: Neuere Methoden und Ansatze, in: ChamonilGluchowski (1998a), S. 321 - 338.

BISSANTZ, NICOLAS; HAGEDORN, JURGEN (1993): Data Mining (Datenmusterer-kennung), in: Wirtschaftsinformatik, 35. Jg., Nr. 5, Oktober 1993, S. 481 - 487.

BISSANTZ, NICOLAS; HAGEDORN, JORGEN; MERTENS, PETER (1998): Data Mining, in: MuckschlBehme (1 998a), S. 445 - 474.

BOEHM, BARRY W. (1986): Wirtschaftliche Software-Produktion, Wiesbaden 1986.

BOEHM, BARRY W. (1988): A Spiral Model of Software Development and Enhancement, in: IEEE Computer, Vol. 21, No.5, May 1988, S. 61 - 72.

BOHN, WILHELM FRIEDRICH (1997): Zeichen- und Zahlendarstellungen, in: Rechenberg/Pomberger (1997), S. 151 - 164.

BOHNLEIN, PETER G.; NITTEL, SILVIA; DITTRICH, KLAUS R. (1990): Semantische Datenmodelle, in: Handbuch der modernen Datenverarbeitung (HMD), 27. Jg., Nr. 152, 1990, S. 116 - 127.

BONTEMPO, CHARLES; ZAGELOW, GEORGE (1998): The IBM Data Warehouse Architecture, in: Communications of the ACM, Vol. 41, No.9, September 1998, S. 38 - 48.

BOWMAN, JUDITH S.; EMERSON, SANDRA L.; DARNOVSKY, MARCY (1996): The Practical SQL Handbook: Using Structured Query Language, 3rd ed., Reading et al. 1996.

BRACHMANN, RONALD J.; ANAND, TEl (1996): The Process of Knowledge Discovery in Databases, in: Fayyad et al. (1996), S. 37 - 57.

BRACK, WERNER; KOPPE, WOLFGANG (1990): Organisation und Management von Softwareentwicklungsprojekten, in: Kurbel/Strunz (1990), S. 289 - 307.

BRACKETT, MICHAEL H. (1996): The Data Warehouse Challenge - Taming Data Chaos, New York, 1996.


BRODIE, MICHAEL L. (1984): On the development of data models, in: Brodie/Mylopoulos/Schmidt (1984), S. 19 - 47.

BRODIE, MICHAEL L.; MYLOPOULOS, JOHN; SCHMIDT, JOACHIM W. (Hrsg.) (1984): On Conceptual Modeling, New York, Berlin, 1984.

BRODIE, MICHAEL L.; STONEBRAKER, MICHAEL (1995): Migrating legacy systems: gateways, interfaces & the incremetal approach, San Francisco 1995.

BROOKS, PETER (1997): Data Mining Today, in: DBMS online, February 1997, o.S., http://www.dbmsmag.coml9702dI6.html. 31.07.98.

BUDDE, REINHARD ET AL. (1992): Prototyping: An Approach to Evolutionary System Development, Berlin et al. 1992.

BULLINGER, HANS-JORG (Hrsg.) (1993): Objektorientierte lnformationssysteme: Neue Trends und aktuelle Applikationen, 3. lAO Forum, Berlin et al. 1993.

BULOS, DAN (1996): A New Dimension, in: Database Programming & Design, Vol. 9, No.6, June 1996, S. 33 - 38.

BUNDESMINISTERIUM DES lNNEREN (1997): V-Modell: Entwicklungsstandard fijr ITSysteme des Bundes, Bonn 1997.

BURCH, GEORGE (1997): Building High Data Quality Into Your Data Warehouse, in: BarquinlEdelstein (1997a), S. 69 - 83.

BUSSE VON COLBE, WALTHER; LABMANN, GERT (1991): Betriebswirtschaftstheorie, Band 1: Grundlagen, Produktions- und Kostentheorie, 5. Auflage, Berlin et al. 1991.

BUYTENDUK, FRANK A. (1995): OLAP: Playing for Keeps: Maintenance and Control Aspects of OLAP Applications, White Paper, 0.0., 1995. http://www.xs4-all.nU-fab/olapkeep.zip, 10.02.98.

CANNATA, PHILIP EUGENE (1991): The Irrestible Move Towards Interoperable Database Systems, in: Kambayashi (1991), S. 2 - 5.

CELKO, JOE; McDoNALD, JACKIE (1995): Don't warehouse dirty data, in: Datamation, October 15, 1995, S. 42 - 52.

CHAMONI, PETER (1998): Entwicklungslinien und Architekturkonzepte des OLAP, in: Chamoni/Gluchowski (1998a), S. 231 - 250.

CHAMONI, PETER; GLUCHOWSKl, PETER (Hrsg.) (1998a): Analytische Informationssysterne: Data Warehouse, On-Line Analytical Processing, Data Mining, Berlin et al. 1998.

CHAMONI, PETER; GLUCHOWSKl, PETER (1998b): Analytische Informationssysteme - Einordnung und Oberblick, in: Chamoni/Gluchowski (1998a), S. 3 - 25.


CHAMONI, PETER; GLUCHOWSKI, PETER (1998c): On-Line Analytical Processing (OLAP), in: MuckschlBehme (l998a), S. 401 - 444.

CHAN, RINGO (1997): 12 Steps of Creating a Successful Data Warehouse, in: Siu et al. (1997), S. 227 - 248.

CHAUDHURI, SURAJIT; DAYAL, UMESHWAR (1997): An Overview of Data Warehousing and OLAP Technology, in: SIGMOD Record, Vol. 26, No. I, March 1997, S. 65 -74.

CHAWATHE, SUDARSHAN. S.; GARCIA-MoLINA, HECTOR (1997): Meaningful Change Detection in Structured Data, in: Peckham (1997), S. 26 - 37.

CHEN, PETER P.-S. (1976): The Entity-Relationship Model - Toward a Unified View of Data, in: ACM Transactions on Database Systems, Vol. I, No. I, March 1976, S. 9 - 36.

CHEN, PETER P.-S. (1991): Der Entity-Relationship-Ansatz zum logischen Datenbankentwurf, in: Chen/Knoll (1991), S. 15 - 109.

CHEN, PETER P.-S.; KNOLL, HEINZ-DIETER (1991): Der Entity-Relationship-Ansatz zum logischen Systementwurf, Mannheim 1991.

CHIANG, ROGER H. L. (1997): Data Dictionary, in: Davis (1997a), S. 40 - 41.

CHMIELEWICZ, KLAUS (1993): Handworterbuch des Rechnungswesens, 3. Auflage, Stuttgart 1993.

CODASYL (1978): Reports of the Data Description Language Committee, in: Information Systems, Vol. 3, No.4, 1978, S. 247 - 320.

CODD, EDGAR F. (1970): A Relational Model for Large Shared Data Banks, in: Communications of the ACM, Vol. 13, No.6, June 1970, S. 377 - 387.

CODD, EDGAR F. (1979): Extending the Database Relational Model to Capture More Meaning, in: ACM Transactions on Database Systems Vol. 4, No.4, December 1979, S. 397 - 434.

CODD, EDGAR F. (1982): Relational Database: A Practical Foundation for Productivity, in: Communications of the ACM, Vol. 25, No.2, February 1982, S. 109 - 117.

CODD, EDGAR F. (1986): Missing Information (Applicable and Inapplicable) in Relational Databases, in: SIGMOD Record, Vol. 15, No.4, December 1986, S. 53 - 78.

CODD, EDGAR F. (1990): The Relational Model for Database Management: Version 2, Reading et al. 1990.

CODD, EDGAR F.; CODD, SHARON B.; SALLEY, CLYNCH T. (1993): Providing OLAP (On-Line Analytical Processing) to User-Analysts: An IT Mandate, White Paper, E. F. Codd & Associates 1993.


CONRAD, STEFAN (1997): FOderierte Datenbanksysteme: Konzepte der Datenintegration, Berlin, Heidelberg et al. 1997.

CONRAD, STEFAN; TURKER, CAN (1997): Unternehmensweite Datenkonsistenz durch Integration bestehender Informationssysteme, in: Krallmann (1997), S. 345 - 356.

COREY, MICHAEL J.; ABBEY, MICHAEL (1997): Oracle Data Warehousing, Berkeley 1997.

DADAM, PETER (1996): Verteilte Datenbanken und ClientlServer-Systeme: Grundlagen, Konzepte und Realisierungsformen, Berlin et al. 1996.

DAS, AMIT (1997): Expert Systems, in: Davis (1997a), S. 78 - 81.

DATE, CHRISTOPHER J. (1985): An Introduction to Database Systems, Vol. II, Reprint with Corrections, Reading et al. 1985.

DATE, CHRISTOPHER J. (1986): Relational Database: Selected Writings, Reading et al. 1986.

DATE, CHRISTOPHER J. (1990): Relational Database Writings, 1985 - 1989, Reading et al. 1990.

DATE, CHRISTOPHER J. (1993): How SQL Missed the Boat, in: Database Programming & Design, Vol. 6, No.9, September 1993, S. 19 - 24.

DATE, CHRISTOPHER J. (1995): An Introduction to Database Systems, 6th ed., Reading et al. 1995.

DATE, CHRISTOPHER J.; DARWEN, HUGH (1992): Relational Database Writings, 1989 - 1991, Reading et al. 1992.

DATE, CHRISTOPHER J.; DARWEN, HUGH (1997): A Guide to the SQL Standard: A User's Guide to the Standard Database Language SQL, 4th ed., Reading et al. 1997.

DAVIDSON, SUSAN B.; BUNEMAN, PETER; KOSKY, ANTHONY (1998): Semantics of Database Transformations, in: ThalheimlLibkin (1998), S. 55 - 91.

DAVIDSON, SUSAN B.; KOSKY, ANTHONY S. (1996): Effecting Database Transformations Using Morphase, University of Pennsylvania, Philadelphia 1996.

DAVIS, GORDON B. (Hrsg.) (1997a): The Blackwell Encyclopedic Dictionary of Management Information Systems, Oxford et al. 1997.

DAVIS, GORDON B. (1997b): Information Concepts, in: Davis (1997a), S. 108 - 113.

DAVIS, GORDON B. (1997c): Management Information System, in: Davis (1997a), S. 138 - 145.

DAVIS, GORDON B.; NEUMANN, DAVID J. (1997): Coding of Data for Information Processing, in: Davis (1997a), S. 26 - 28.


DAVIS, GORDON B.; OLSON, MARGRETIIE H. (1985): Management Information Systems: Conceptual Foundations, Structure and Development, 2nd ed., New York 1985.

DEEN, S. MISBAH; AMIN, R.R.; TAYLOR M.e. (1987): Data Integration in Distributed Databases, in: IEEE Transactions on Software Engineering, Vol. 13, No.3, July 1987, S. 860 - 864.

DEMARCO, TOM (1978): Structured Analysis and System Specification, Englewood Cliffs 1978.

DEVLIN, BARRY (1997): Data Warehouse: From architecture to implementation, Reading et al. 1997.

DEVLIN, BARRY; MURPHY, PAUL T. (1988): An Architecture for a Business and Information System, in: IBM Systems Journal, Vol. 27, No. I, 1988, S. 60 - 80.

DIN ISO 9126 (1991): Informationstechnik - Beurteilen von Softwareprodukten: Qualitatsmerkmale und Leitfaden zu deren Verwendung, Berlin 1991.

DITIRICH, KLAUS R.; SCHERRER, STEFAN (1993): Objektorientierte Datenbanksysteme: Leistungsflihige Basis komplexer Anwendungssysteme, in: Bullinger (1993), S. 33 - 59.

DUDEN (1996): Die deutsche Rechtschreibung, 21. Auflage 1996, CD-ROM-Version, Mannheim 1996.

ECKERSON, WAYNE (1994): Data-Warehouses, Product Requirements, Architectures, and Implementation Strategies, in: Open Information Systems, No.8, 1994, Special Reprint, S. I - 27.

EDELSTEIN, HERBERT A. (1995): Technology Analysis: Faster Data Warehouses, New tools provide high-performance querying through advanced indexing, 0.0. 1995. http://techweb.cmp.comliw/556/560Ibit.htrn, 12.05.1997.

EDELSTEIN, HERBERT A. (1997): An Introduction to Data Warehousing, in: BarquinlEdelstein (1997b), S. 31 - 50.

EICKER, STEFAN (1994): IV-Dictionary: Konzepte zur Verwaltung der betrieblichen Metadaten, Berlin et al. 1994.

EICKER, STEFAN; SCHUNGEL, MARTIN (1998): Stand der UnternehmensdatenModellierung in der Praxis, in: Information Management & Consulting, 13. Jg., Nr. 4, 1998, S. 78 - 85.

ELMASRI, RAMEZ A.; NAVATIIE, SHAMKANT B. (1994): Fundamentals of Database Systems, 2nd ed., Redwood City et al. 1994.

EL-REWINI, HESHAM (Hrsg.) (1998): Proceedings of the 31 st Hawaii International Conference on System Sciences (HlCSS-31), Volume 7: Software Technology Track, Los Alamitos et al. 1998.


ENGELHARDT, WERNER HANS (1995): Qualitat - ein Marketing-Thema, in: Balderjahn/Gabriel (1995), S. 1 - 16.

ENSLOW, PHILIP H. (1978): What is a Distributed Data Processing System? In: IEEE Computer, Vol. 11, No.1, January 1978, S. 13 - 21.

ERLER, THOMAS; SCHELP, JOACHIM (1998): Das Data Warehouse im Kontext der strategischen Bedeutung betrieblicher Informationssysteme, 2. Auflage, Arbeitsberichte des Lehrstuhls fUr Wirtschaftsinformatik 98-32, RuhrUniversitat Bochum, Bochum 1998.

ERNST, JOHANNES (1997a): Introduction to CDIF, White Paper, 0.0. 1997. http://www.cdif.org/intro.html. 19.08.1998.

ERNST, JOHANNES (1997b): Using the CDIF Transfer Format to exchange UML models, EIA/CDIF Technical Committee - Working Document CDIF-JE-N34-V2, 0.0. 1997. http://www.cdif.org/liaisons/CDIF-JE-N34-V2.pdf, 19.08.1998.

ESTER, MARTIN; WITTMANN, RUDIGER (1998): Incremental Generalization for Mining in a Data Warehousing Environment, in: Schek et a1. (1998), S. 134 - 149.

FAIRLEY, RICHARD E. (1985): Software Engineering Concepts, New York et a1. 1985.

FASNACHT, DANIEL (1993): Koordination verteilter und heterogener Datenbanksysteme, Bergisch Gladbach, Ko\n 1993 (zug1. Bern, Universitat, Diss. 1993).

FAYYAD, USAMA M. ET AL. (1996): Advances in Knowledge Discovery and Data Mining, Menlo Park 1996.

FAYYAD, USAMA M.; PIATETSKY-SHAPIRO, GREGORY; SMYTH, PADHRAIC (1996): From Data Mining to Knowledge Discovery: An Overview, in: Fayyad et a1. (1996), S. 1 - 34.

FERSTL, OTTO K.; SINZ, ELMAR J. (1998): Grundlagen der Wirtschaftsinformatik, 3. Auflage, Mtinchen 1998.

FISCHER, JOACHIM (1996): Aktive Datenbankmanagementsysteme, in: Wirtschaftsinformatik, 38. Jg., Nr. 4, August 1996, S. 435 - 438.

FRESE, ERICH: (1992): Handworterbuch der Organisation, 3. Auflage, Stuttgart 1992.

FROESE, JDRGEN ET AL. (1996): Effiziente Systementwicklung mit ORACLE 7.1, 2. Auflage, Bonn 1996. FUTING, ULRICH CHRISTIAN (1998): Projektmanagement und -controlling von Data Warehouse-Projekten, m: MuckschIBehme (1998a), S. 337 - 357.

GABLER WIRTSCHAFfSLEXIKON (1997), 14. Auflage, Wiesbaden 1997.

GABRIEL, ROLAND (1990): Software Engineering, in: KurbellStrunz (1990), S. 257 - 273.


GABRIEL, ROLAND (1992): Wissensbasierte Systeme in der betrieblichen Praxis, Hamburg et al. 1992.

GABRIEL, ROLAND (1997): Betriebssystem, in: Mertens et al. (1997), S. 63 - 65.

GABRIEL, ROLAND; CHAMONI, PETER; GLUCHOWSKI, PETER (1995): Einsatz von IuKSystemen zur Unterstiitzung des Managements - Management Support Systerne I, Arbeitsbericht Nr. 95-14 des Lehrstuhls fUr Wirtschaftsinformatik, Ruhr-Universitat Bochum, Bochum 1995.

GABRIEL, ROLAND; GLUCHOWSKI, PETER (1997): Semantische Modellierungstechniken fUr multidimensionale Datenstrukturen, in: Handbuch der modernen Datenverarbeitung (HMD), 34. Jg., Nr. 195, 1997, S. 18 - 37.

GABRIEL, ROLAND; ROHRS, HEINZ-PETER (1995): Datenbanksysteme: Konzeptionelle Datenmodellierung und Datenbankarchitekturen, 2. Auflage, Berlin 1995.

GARDNER, STEPHEN R. (1997): Data Warehouses and Metadata: The Importance of Metadata Management, in: Siu (1997), S. 61 - 71.

GARDNER, STEPHEN R. (0. J.): Data Warehouses - The Importance of Metadata Management. Information Management Perspective Series, NCR Worldwide Services, 0.0., o.J.

GAUSDEN, SUSAN; MASON, TERRY (1997): Middleware: Gluing the Warehouse Together, in: Bischoff! Alexander (1997), S. 252 - 273.

GEMUNDEN, HANS GEORG (1993): Information: Bedarf, Analyse und Verhalten, in: Wittmann et al. (1993a), Sp. 1725 - 1735.

GLASSEY-EDHOLM, KATHERINE (1997): Bringing User Perspective to Data Warehouses: Twenty-one Points of Consideration, in: BarquinlEdelstein (1997a), S. 103 - 120.

GLEASON, DAVE (1997a): Data Transformation, in: Bischoff!Alexander (1997), S. 160 - 173.

GLEASON, DAVE (1997b): Metadata, in: Bischoff!Alexander (1997), S. 135 - 150.

GLUCHOWSKI, PETER (1997): Data Warehouse, in: Informatik Spektrum, 20. Jg., Nr. 1, Februar 1997, S. 48 - 49.

GLUCHOWSKI, PETER (l998a): Werkzeuge zur Implementierung des betrieblichen Berichtswesens, in: WISU - Das Wirtschaftsstudium, 27. Jg., Nr. 10, Oktober 1998, S. 1174-1188.

GLUCHOWSKI, PETER (1998b): Analyseorientierte Datenbanksysteme, Lehrmaterialien im Studienfach Wirtschaftsinformatik, 24/98, Ruhr-Universitat Bochum, Bochum 1998.

GLUCHOWSKI, PETER (l998c): Techniken und Werkzeuge zum Aufbau betrieblicher Berichtssysteme, in: Chamoni/Gluchowski (l998a), S. 179 - 200.


GLUCHOWSKI, PETER (1998d): Schnelle Zugriffe bei Analyse-Datenbanken: Antwortzeit als Erfolgsfaktor, in: Datenbank Fokus, Nr. 3, M1irz 1998, S. 16 - 22.

GLUCHOWSKI, PETER; GABRIEL, ROLAND; CHAMONI, PETER (1997): Management Support Systeme: Computergestiitzte Informationssysteme fUr Fiihrungskrafte und Entscheidungstrager, Berlin et al. 1997.

GLUCHOWSKI, PETER; HAHNE, MICHAEL (1998): Benchmarking fUr dispositive Datenbanken: Vergleich der Benchmarks TPC-D und APB-l, in: Datenbank Fokus, Nr. 10, Oktober 1998, S. 72 - 76.

GOLFARELLI, MATIEO; MAIO, DARIO; RIZZI, STEFANO (1998): Conceptual Design of Data Warehouses from EIR Schemes, in: EI-Rewini (1998), S. 334 - 343.

GOODHUE, DALE L.; WYBO, MICHAEL D.; KIRSCH, LAURIE J. (1992): The Impact of Data Integration on the Costs and Benefits of Information Systems, in: MIS Quarterly, Vol. 16, No.3, September 1992, S. 293 - 311.

GORANSON, TED (1998): Architectural Requirements of Commercial Products, in: BernusIMertins/Schmidt (1998), S. 711 - 731.

GOTTLOB, GEORG; ZICARI, ROBERTO (1988): Closed World Databases Opened Through Null Values, in: BancilhonlDeWitt (1988), S. 50 - 61.

GRAHNE, GbSTA (1991): The Problem of Incomplete Information in Relational Databases, Berlin et al. 1991.

GRAY, JIM (1981): The Transaction Concept: Virtues and Limitations, in: Zaniolo (1981), S. 144 - 154.

GRA Y, JIM ET AL. (1998): Data Cube: A Relational Aggregation Operator Generalizing Group-By, Cross-Tab, and Sub-Totals, in: Stonebraker/Hellerstein (1998a), S. 555 - 567.

GRAY, JIM; REUTER, ANDREAS (1993): Transaction Processing: Concepts and Techniques, corrected third printing, San Francisco 1993.

GROCHLA, ERWIN (1974): Integrierte Gesamtmodelle der Datenverarbeitung, Miinchen, Wien 1974.

GROCHLA, ERWIN (Hrsg.) (1980): Handworterbuch der Organisation, 2. Auflage, Stuttgart 1980.

GUPTA, ASHISH; MUMICK, INDERPAL SINGH (1995): Maintenance of Materialized Views: Problems, Techniques, and Applications, in: Bulletin of the Technical Committee on Data Engineering, IEEE Computer Society, Vol. 18, No.2, June 1995, S. 3 - 18.

HABERMANN, HANS-JOACHIM; LEYMANN, FRANK (1993): Repository - Eine EinfUhrung, Miinchen, Wien 1993.

HACKATHORN, RICHARD D. (1993): Enterprise Database Connectivity. The Key to Enterprise Applications on the Desktop, New York et al. 1993.


HACKATHORN, RICHARD D. (1995): Data Warehousing Energizes Your Enterprise, in: Datamation, February 1, 1995, S. 38 - 42.

HAHN, DIETGER; LAHMANN, GERT (1993): Produktionswirtschaft - Controlling industrieller Produktion, Band 3, Zweiter Teilband: Informationssystem, Heidelberg 1993.

HAHNE, MICHAEL (1998a): Logische Modellierung fiir das Data Warehouse - Bestandteile und Varianten des Star Schemas, in: Chamoni/Gluchowski (1998a), S. 103 - 122.

HAHNE, MICHAEL (1998b): Modellierung mehrdimensionaler Datenstrukturen in OLAP-Datenbanken: Eine vergleichende Analyse von drei ausgewahlten Systemprodukten, Arbeitsberichte des Lehrstuhls fiir Wirtschaftsinformatik 98-30, Ruhr-Universitat Bochum, Bochum 1998.

HAHNE, MICHAEL; SCHELP, JOACHIM (1997): Semantische und logische Modellierung mehrdimensionaler Datenstrukturen, Arbeitsberichte des Lehrstuhls fiir Wirtschaftsinformatik 97-26, Ruhr-Universitat Bochum, Bochum 1997.

HAMMER, JOACHIM ET AL. (1995): The Stanford Data Warehousing Project, in: Bulletin of the Technical Committee on Data Engineering, IEEE Computer Society, 18. Jg., Nr. 2, June 1995, S. 41 - 48.

HAMMER, KATHERINE (1997): Migrating Data from Legacy Systems: Challenges and Solutions, in: BarquinlEdelstein (1997a), S. 27 - 40.

HANSEN, HANS ROBERT (1996): Wirtschaftsinformatik I: Grundlagen der betrieblichen Informationsverarbeitung, 7. Auflage, Stuttgart 1996.

HANSEN, WOLF-RUDIGER (1996): Erfahrungen mit unterschiedlichen Ansatzen und Li:isungswegen in Data-Warehouse-Projekten, in: MuckschlBehme (1996), S. 425 - 454.

HANSEN, WOLF-RUDIGER (1998): Vorgehensmodell fiir die Entwicklung einer Data Warehouse-La sung, in: MuckschIBehme (1998a), S. 319 - 326.

HARS, ALEXANDER (1994): Referenzdatenmodelle: Grundlagen effizienter Datenmodellierung, Wiesbaden 1994 (zugl. Saarbriicken, Universitat, Diss. 1993).

HAVELKA, DOUGLAS; KHAZANCHI, DEEPAK (1994): An "Events" Model for Information Aggregation, in: Journal of Computer Information Systems, Vol. 35, No.2, 1994, S. 72 - 8l.

HEIMBIGNER, DENNIS; McLEOD, DENNIS (1985): A Federated Architecture for Information Management, in: ACM Transactions on Office Information Systems (TOIS), Vol. 3, No.3, July 1985, S. 253 - 278.

HEINRICH, LUTZ J. (1986): Wirtschaftsinformatik in Forschung und Ausbildung, in: Information Management, l. Jg., Nr. 1, 1986, S. 63 - 69.


HEINRICH, LUTZ J. (1993): Wirtschaftsinformatik: Einflihrung und Grundlegung, Miinchen, Wien 1993.

HEINRICH, LUTZ J.; ROITHMAYR, FRIEDRICH (1995): Wirtschaftsinformatik-Lexikon, 5. Auflage, Miinchen, Wien 1995.

HESSE, STEFAN (1995): Strategische Datenbanken: Kernelemente computergestiitzter Informationssysteme zur Unterstiitzung des strategischen Controllings, Heidelberg 1995.

HESSE, WOLFGANG ET AL. (1994): Terminologie der Softwaretechnik: Ein Begriffssystem flir die Analyse und Modellierung von Anwendungssystemen, Teil 1: Begriffssystematik und Grundbegriffe, in: Informatik-Spektrum, Band 17, Nr. 1, Februar 1994, S. 39 - 47.

HEUER, ANDREAS (1997): Objektorientierte Datenbanken: Konzepte, Modelle, Standards und Systeme, 2. Auflage, Bonn et al. 1997.

HEUER, ANDREAS; SAAKE, GUNTER (1995): Datenbanken: Konzepte und Sprachen, Bonn et al. 1995.

HILDEBRAND, KNUT (1990): Software Tools: Automatisierung im Software Engineering, Berlin et al. 1990.

HOLLER, ELMAR (1989): Verteilte Systeme: Entwicklung und Perspektiven, in: Handbuch der modernen Datenverarbeitung (HMD), 26. Jg., Nr. 150, 1989, S. 86 - 97.

HOLTHUIS, JAN (1997): Modellierung multidimensionaler Daten - Modellierungsaspekte und Strukturkomponenten, Arbeitsbericht des Lehrstuhls flir Informationsmanagement und Datenbanken 97-1, European Business School, Oestrich-Winkel 1997.

HOLTHUIS, JAN (1998a): Der Aufbau von Data Warehouse-Systemen: Konzeption -Datenmodellierung - Vorgehen, Wiesbaden 1998 (zugl. Gottingen, Universitat, Diss. 1997).

HOLTHUIS, JAN (1998b): Multidimensionale Datenstrukturen: Modellierung, Strukturkomponenten, Implementierungsaspekte, in: MuckschIBehme (1998a), S. 143 - 193.

HOLTHUIS, JAN; MUCKSCH, HARRY; REISER, MARCUS (1995): Das Data Warehouse Konzept. Ein Ansatz zur Informationsbereitstellung fiir Managementunterstiitzungssysteme, Arbeitsbericht des Lehrstuhls flir Informationsmanagement und Datenbanken 95-1, European Business School (ebs), OestrichWinke11995.

HUFFORD, DUANE (1997): Metadata Repositories: The Key to Unlocking Information in Data Warehouses, in: BarquinlEdelstein (1997b), S. 225 - 262.

HUGHES, JOHN G. (1992): Objektorientierte Datenbanken, Miinchen, Wien 1992.


HURWICZ, MIKE (1997): Take Your Data to the Cleaners, in: Byte, January 1997, o.S., http://www.byte.com/artl9701/sec7/art4.htm. 20.01.98.

HUYN, NAM (1 997a): Multiple-View Self-Maintenance in Data Warehousing Environments, in Jarke et al. (1997), S. 26 - 35.

HUYN, NAM (1997b): Maintaining Data Warehouses under Limited Source Access, Ph.D. Thesis, Stanford Computer Science, Stanford 1997.

InRI, Yun (1967): The Foundations of Accounting Measurement, Reprint of the 1967 Edition, Houston 1978.

INMON, WILLIAM H. (1996): Building the Data Warehouse, 2nd ed., New York et al. 1996.

INMON, WILLIAM H. (1997a): Does your datamart vendor care about your architecture? In: Datamation, March 1997, o. S., http://www.datamation.comIPlugIniissues/1997/marchl03dmarts.html, 06.01.1999.

INMON, WILLIAM H. (1997b): Are multiple data warehouses too much of a good thing? In: Datamation, April 1997, S. 94 - 96.

INMON, WILLIAM H.; HACKATHORN, RICHARD D. (1994): Using the Data Warehouse, New York et al. 1994.

INMON, WILLIAM H.; ZACHMAN, JOHN A.; GEIGER, JONATHAN G. (1997): Data Stores, Data Warehousing, and the Zachman Framework: Managing Enterprise Knowledge, New York et al. 1997.

JABLONSKI, STEFAN (1990): Datenverwaltung in verteilten Systemen: Grundlagen und L6sungskonzepte, Berlin et al. 1990 (zugl. Erlangen, Niirnberg, Universitat, Diss.1989).

JACKSON, GLENN A. (1990): Entwurf relationaler Datenbanken, Miinchen, Wi en 1990.

JAHNKE, BERND; GROFFMANN, HANS-DIETER; KRUPPA, STEFAN (1996): On-Line Analytical Processing (OLAP), in: Wirtschaftsinformatik, 38. Jg., Nr. 3, Juni 1996, S. 321 - 324.

J ARKE, MATTHIAS ET AL. (Hrsg.) (1997): Proceedings of the twenty-third International Conference on Very Large Databases, San Francisco 1997.

JEUSFELD, MANFRED A.; JARKE, MATTHIAS (1997): Suchhilfen flir das World Wide Web: Funktionsweisen und Metadatenstrukturen, in: Wirtschaftsinformatik, 39. Jg., Nr. 5, Oktober 1997, S. 491 - 499.

JOHNSON, ORACE (1970): Towards an "Events" Theory of Accounting, in: The Accounting Review, Vol. 45, No.4, October 1970, S. 641 - 653.

KAISER, BERND-ULRICH (1998): Kritische Reflexion von Informationssystemen flir das obere Management, in: Chamoni/Gluchowski (1998a), S. 447 - 458.


KAMBAYASHI, YAHIKO (Hrsg.) (1991): IMS '91 - First International Workshop on Interoperability in Multidatabase Systems, Los Alamitos et al. 1991.

KEMPER, ALFONS; EICKLER, ANDRE (1997): Datenbanksysteme: Eine Einfiihrung, Miinchen, Wi en 1997.

KEMPER, HANS GEORG; FINGER, RALF (1998): Datentransformation im Data Warehouse. Konzeptionelle Uberlegungen zur Filterung, Harmonisierung, Verdichtung und Anreicherung operativer Datenbestande, in: Chamoni/Gluchow ski (1998a), S. 61 - 77.

KENAN TECHNOLOGIES (1995): An Introduction to Multidimensional Database Technology, Whitepaper, Kenan Systems Corporation, 0.0.1995.

KIEBACK, ANTOINETIE ET AL. (1992): Prototyping in industriellen SoftwareProjekten - Erfahrungen und Analysen, in: Informatik-Spektrum, 15. Jg., Nr. 2, April 1992, S. 65 - 77.

KIM, WON; SEO, JUNGYUN (1991): Classifying Schematic and Data Heterogenity in Multidatabase Systems, in: IEEE Computer, Vol. 24, No. 12, December 1991, S. 12 - 18.

KIMBALL, RALPH (1996): The Data Warehouse Toolkit: Practical Techniques for Building Dimensional Data Warehouses, New York et al. 1996.

KIMBALL, RALPH ET AL. (1998): The Data Warehouse Lifecycle Toolkit: Expert Methods for Designing, Developing and Deploying Data Warehouses, New York et al. 1998.

KIRCHNER, JOACHIM (1996): Datenveredelung im Data-Warehouse, in: MuckschIBehme (1996), S. 265 - 299.

KIRCHNER, JOACHIM (1998): Transformationsprogramme und Extraktionsprozesse entscheidungsrelevanter Basisdaten, Ill: MuckschlBehme (1998a), S. 245 - 273.

KLAGGE, DIETER; NETT, WALTER; WINDLER, ALBRECHT (1998): Leitfaden - Electronic Data Interchange (EDI) im mittelstandischen Betrieb: Organisation und Technik, Chancen und Risiken, Lohmar, Kaln 1998.

KLEINSCHMIDT, PETER; RANK, CHRISTIAN (1997): Relationale Datenbanksysteme: Eine praktische Einfiihrung, Berlin et al. 1997.

KNITTEL, FRIEDRICH (1995): Technikgestutzte Kommunikation und Kooperation im Buro: Entwicklungshindernisse - Einsatzstrategien - Gestaltungskonzepte, Bochumer Beitrage zur Unternehmungsfiihrung und Unternehmensforschung, Band 47, Wiesbaden 1995 (zugl. Bochum, Universitat, Diss. 1994).

KONIG, WOLFGANG (Hrsg.) (1995): Wirtschaftsinformatik '95: Wettbewerbsfahigkeit, Innovation, Wirtschaftlichkeit, Heidelberg 1995.


KOREIMANN, DIETER S. (1971): Methoden und Organisation von ManagementInformations-Systemen, Berlin, New York 197I.

KRALLMANN, HERMANN; RIEGER, BODO (1987): Vom Decision Support System (DSS) zum Executive Support System (ESS), in: Handbuch der modernen Datenverarbeitung (HMD), 24. Jg., Nr. 138, 1987, S. 28 - 38.

KRALLMANN, HERRMANN (Hrsg.) (1997): Wirtschaftsinformatik '97: Internationale Geschaftstatigkeit auf der Basis flexibler Organisationsstrukturen und leistungsfahiger Informationssysteme, Heidelberg 1997.

KRCMAR, HELMUT (1997): Informationsmanagement, Berlin et al. 1997.

KUNG, PETER (1994): Datenbanksysteme: Entwicklungsstand, Anforderungen und Bedeutung neuerer Konzepte, Zurich 1994 (zugl. Freiburg (Schweiz), Universitat, Diss. 1993).

KURBEL, KARL; STRUNZ, HORST (Hrsg.) (1990): Handbuch Wirtschaftsinformatik, Stuttgart 1990.

KUTING, KARLHEINZ (1983): Kennzahlensysteme in der betriebswirtschaftlichen Praxis, in: WiSt - Wirtschaftswissenschaftliches Studium, Nr. 6, Juni 1983, S. 291 - 296.

LADLEY, JOHN (1997): A Flexible Approach to Developing a Data Warehouse, in: Bischoff/Alexander (1997), S. 100 - 119.

LAMERSDORF, WINFRIED (1994): Datenbanken in verteilten Systemen: Konzepte, Losungen, Standards, Braunschweig, Wiesbaden 1994.

LANG, STEFAN M.; LOCKEMANN, PETER C. (1995): Datenbankeinsatz, Berlin et al. 1995.

LARSON, JAMES A.; NAVATHE, SHAMKANTB.; ELMASRI, RAMEZA. (1989): A Theory of Attribute Equivalence in Databases with Application to Schema Integration, in: IEEE Transactions on Software Engineering, Vol. 15, No.4, April 1989, S. 449 - 463.

LARuE, TRINA (1997): Implementing a Warehouse in a Multiserver Environment Using Parallel Technology, in: Bischoff/Alexander (1997), S. 238 - 25 I.

LAUDON, KENNETH c.; LAUDON, JANET P. (1994): Management Information Systems: Organization and Technology, New York 1994.

LAUFMANN, STEVE; SPACCAPIETRA, STEFANO; YOKOI, TOSHIO (Hrsg.) (1995): Proceedings of the Third International Conference on Cooperative Information Systems (CoopIS-95), Wien 1995.

LEHMANN, PETER; ELLERAU, PETER (1997): Implementierung eines Data Warehouse fUr die Verpackungsindustrie, in: Handbuch der modernen Datenverarbeitung (HMD), 34. Jg., Nr. 195, 1997, S. 76 - 93.

LEHNER, FRANZ (1997): Kunstliche Intelligenz, in: Mertens et al. (1997), S. 237 - 238.


LEHNER, FRANZ; HILDEBRAND, KNUT; MAIER, RONALD (1995): Wirtschaftsinformatik: Theoretische Grundlagen. Miinchen, Wien 1995.

LEHNER, FRANZ; MAIER, RONALD (1994): Information in Betriebswirtschaftslehre, Informatik und Wirtschaftsinformatik, Forschungsbericht Nr. 11 der Schriftenreihe des Lehrstuhls fiir Wirtschaftsinformatik und Informationsmanagement, Wissenschaftliche Hochschule fiir Unternehmensfiihrung - Otto-Beisheim-Hochschule, Koblenz 1994.

LERAT, NADINE; LIPSKI, WITOLD (1986): Nonapp1icable Nulls, in: Theoretical Computer Science, Vol. 46, 1986, S. 67 - 82.

LEVENE, MARK; LOIZOU, GEORGE (1998): The Additivity Problem for Data Dependencies in Incomplete Relational Databases, in: ThalheimlLibkin (1998), S. 136 - 169.

LEVIN, ELLEN 1. (1997): Developing a Data Warehousing Strategy, in: BarquinlEdelstein (1997b), S. 53 - 89.

LmKIN, LEONID (1994): Aspects of Partial Information in Databases, Dissertation, Department of Computer and Information Science, University of Pennsylvania, Philadelphia 1994.

LmKIN, LEONID (1998): A Semantics-Based Approach to Design of Query Languages for Partial Information, in: ThalheimlLibkin (1998), S. 170 - 208.

LITWIN, WITOLD; ABDELLATIF, ABDELAZIZ (1986): Multidatabase Interoperability, in: IEEE Computer, Vol. 19, No. 12, December 1986, S. 10 - 18.

LOCKEMANN, PETER C.; RADERMACHER, KLAus (1990): Konzepte, Methoden und Modelle zur Datenmodellierung, in: Handbuch der modernen Datenverarbeitung (HMD), 27. Jg., Nr. 152, 1990, S. 3 - 16.

LOCKEMANN, PETER C.; SCHMIDT, JOACHIM W. (1987): Datenbankhandbuch, Berlin et al. 1987.

LUFrER, JENS; SCHAARSCHMIDT, RALF; KOSPERT, KLAus (1997): Aktive Datenbankmechanismen: Stand in Forschung, Produkten und Entwicklung, in: Handbuch der modernen Datenverarbeitung (HMD), 34. Jg., Nr. 195, 1997, S. 102 - 127.

MADSEN, MARK (1996): Warehouse Design in the Aggregate, in: Database Programming & Design, No.7, July 1996, S. 45 - 5l.

MAIER, DAVID: (1983): The Theory of Relational Databases, Rockville 1983.

MAIER, RONALD (1996): Qualitat von Datenmodellen, Wiesbaden 1996 (zugl. Koblenz, Wissenschaftliche Hochschule fiir Unternehmensfiihrung, Diss. 1996).

MARCH, SALVATORE (1997): Data Modeling, Logical, in: Davis (1997a), S. 41 - 47.


MARTIN, JAMES (1981): Design and Strategy for Distributed Data Processing, Englewood Cliffs 1981.

MARTIN, JAMES (1988): Einfiihrung in die Datenbanktechnik, 5. Nachdruck, Mtinchen, Wien 1988.

MARTIN, WOLFGANG (Hrsg.) (1997): Congressband VIII: Data Warehousing. Fortschritte des Informationsmanagements, Velbert 1997.

MARTIN, WOLFGANG (1998): Data Warehousing und Data Mining: Markttibersicht und Trends, in: MuckschlBehme (1998a), S. 125 - 139.

MATTISON, ROB (1996): Data Warehousing: Strategies, Technologies and Techniques, New York et al. 1996.

MA YER, BERTRAND (1997): Object-oriented Software Construction, Upper Saddle River 1997.

MAYR, HEINRICH C.; DITTRICH, KLAUS R.; LOCKEMANN, PETER C. (1987): Datenbankentwurf, in: LockemanniSchmidt (1987), S. 481 - 557.

MCCLAIN, GARY (Hrsg.) (1993): OLTP Handbook, New York et al. 1993.

MCGUFF, FRANK (1998): Designing the Perfect Data Warehouse, White Paper, Telos Solutions Inc., 0.0. 1998. http://www.aol.comlfmcguffldwmodeUindex.htm. 10.11.1998.

MEIER, ANDREAS (1997): Datenbankmigration - Wege aus dem Datenchaos, in: Handbuch der modernen Datenverarbeitung (HMD), 34. Jg., Nr. 194, 1997, S. 24 - 36.

MELLIS, WERNER (1997): Strategien der Systementwicklung, in: Mertens et al. (1997), S. 383 - 384.

MELTON, JIM (1996): An SQL3 Snapshot, in: Su (1996), S. 666 - 672.

MELTON, JIM (1998): Database Language SQL, in: BernuslMertins/Schmidt (1998), S. 103 - 128.

MERTENS, PETER (1993): EDV, in: Chmielewicz (1993), Sp. 415 - 422.

MERTENS, PETER (1997a): Integrierte Informationsverarbeitung 1: Administrationsund Dispositionssysteme in der Industrie, II. Auflage, Wiesbaden 1997.

MERTENS, PETER (1997b): Integrierte Informationsverarbeitung, in: Mertens et al. (1997), S. 208 - 209.

MERTENS, PETER (1998a): Peter Mertens besucht bei Swissair Klaus Bena und die Expertensystemgruppe der atraxis ag, in: Wirtschaftsinformatik, 40. Jg., Nr. 1, Februar 1998, S. 68 - 72.

MERTENS, PETER (1998b): Integration interner, externer, qualitativer und quantitativer Daten auf dem Weg zum Aktiven MIS, in: UhrlBreuer (1998), S. 9 - 30.


MERTENS, PETER ET AL. (Hrsg.) (1997): Lexikon der Wirtschaftsinformatik, 3. Auflage, Berlin et al. 1997.

MERTENS, PETER ET AL. (1998): Grundztige der Wirtschaftsinformatik, 5. Auflage, Berlin et al. 1998.

MERTENS, PETER; BISSANTZ, NICOLAS; HAGEDORN, JORGEN (1997): Data Mining im Controlling - Dberblick und erste Praxiserfahrungen, in: Zeitschrift fUr Betriebswirtschaft' 67. Jg., Nr. 2, Februar 1997, S. 179 - 201.

MERTENS, PETER; GRIESE, JOACHIM (1993): Integrierte Informationsverarbeitung 2: Planungs- und Kontrollsysteme in der Industrie, 7. Auflage, Wiesbaden 1993.

MERTENS, PETER; HOLZNER, JOCHEN (1992): WI State of the Art: Eine Gegentiberstellung von Integrationsansatzen der Wirtschaftsinformatik, in: Wirtschaftsinformatik, 34. Jg., Nr. 1, Februar 1992, S. 5 - 25.

MERTES, HELMUT; KLONKI, ULRICH (1991): Vorgehensweise fUr die Erstellung eines unternehmensweiten Datenmodells bei der Hoesch AG, in: Wirtschaftsinformatik, 33. Jg., Nr. 4, August 1991, S. 308 - 315.

METADATA COALITION (1996): Proposal for Version 1.0 Metadata Interchange Specification, Metadata Coalition, Draft Paper, 0.0. 1996.

MEYER, CLAUS (1994): Betriebswirtschaftliche Kennzahlen und Kennzahlensysteme, 2. Auflage, Stuttgart 1994.

MEYER, DON; CANNON, CASEY (1998): Building a Better Data Warehouse, Upper Saddle River 1998.

MICROSOFf (1997): OLE DB for OLAP Design Specifications, Beta 3, October 1997, 0.0.1997.

MILEY, MICHAEL (1998): Making the Mart Decision, In: Oracle Magazine, Vol. XII, No.1, JanuarylFebruary 1998, S. 74 - 86.

MITTERMEIR, ROLAND T. (1990): Requirements Engineering. In: Kurbel/Strunz (1990), S. 237 - 256.

MOLLER, FRANK (1998): Data Warehouse als Warnsignal an die Datenschutzbeauftragten, in: Datenschutz und Datensicherheit, 22. Jg., Nr. 10, Oktober 1998, S. 555 - 560.

MONCKE, ULRICH (1998): Data Warehouses - eine Herausforderung fUr den Datenschutz? In: Datenschutz und Datensicherheit, 22. Jg., Nr. 10, Oktober 1998, S. 561 - 569.

MORIARTY, TERRY; GREENWOOD, RICHARD P. (1996): Data's Quest - From Source to Query: Exploring the five functional divisions of the data warehouse infrastructure, in: Database Programming & Design, No. 10, October 1996, S. 78 - 81.


MORIARTY, TERRY; MANDRACCHIA, CHRISTINE (1996): Heart of the Warehouse: Exploring a tool framework for getting meta-data to warehouse users, in: Database Programming & Design, No. 11, November 1996, S. 70 - 74.

MOXON, BRUCE (1996): Defining Data Mining, in: DBMS online, Data Warehouse Supplement, August 1996, o.S., http://www.dbmsmag.coml9608d53.html. 31.07.98.

MUCKSCH, HARRY (1997): Das Management von Meta-Informationen im Data Warehouse, in: Martin (1997), S. C811.01 - C811.11.

MUCKSCH, HARRY (1998): Das Data Warehouse als Datenbasis analytischer Informationssysteme - Architektur und Komponenten, in: Chamoni/Gluchowski (1998a), S. 123 - 140.

MUCKSCH, HARRY; BEHME, WOLFGANG (Hrsg.) (1996): Das Data-WarehouseKonzept: Architektur - Datenmodelle - Anwendungen, Wiesbaden 1996.

MUCKSCH, HARRY; BEHME, WOLFGANG (Hrsg.) (1998a): Das Data WarehouseKonzept: Architektur - Datenmodelle - Anwendungen, 3. Auflage, Wiesbaden 1998.

MUCKSCH, HARRY; BEHME, WOLFGANG (1998b): Das Data Warehouse-Konzept als Basis einer unternehmensweiten Informationslogistik, in: MuckschIBehme (1998a), S. 33 - 100.

MUCKSCH, HARRY; HOLTHUIS, JAN; REISER; MARCUS (1996): Das Data WarehouseKonzept: Ein Uberblick, in: Wirtschaftsinformatik, 38. Jg., Nr. 4, August 1996, S. 421 - 433.

MOLLER, JOCHEN (1998): Datenbeschaffung fUr das Data Warehouse, in: Chamonil Gluchowski (1998a), S. 79 - 101.

MOLLER-MERBACH, HEINER (1992): Vier Arten von Systemansatzen, dargestellt in Lehrgesprachen, in: Zeitschrift fUr Betriebswirtschaft, 62. Jg., Nr. 8, August 1992, S. 853 - 876.

MYRACH, THOMAS (1994): Konzeption und Stand des Einsatzes von Data Dictionaries, Heidelberg 1994 (zugl. Bern, Universitat, Diss. 1993).

NANCE, WILLIAM D. (1997): Make or Buy for Software, in: Davis (1997a), S. 137 - 138.

NAYER, M. (1993): Achieving Information Integrity: A Strategic Imperative, in: Information Systems Management, Vol. 10, No.2, 1993, S. 51 - 58.

NEUMAIER, HERBERT (Hrsg.) (1989): Relationale Datenbanken, Miinchen, Wien 1989.

NIESCHLAG, ROBERT; DICHTL, ERWIN; HORSCHGEN, HANS (1994): Marketing, 17. Auflage, Berlin 1994.

o.v. (1994): Data Management Review's two Categories of Data Warehouse Products, in: Data Management Review, Vol. 4, No.5, May 1994; S. 14 - 19.


O.V. (1996): Unter der Lupe: Tools zum Hillen von Data-Warehouses, in: Computerwoche, 23. Jg., Nr. 42,1996, S. 17 - 18.

O.V. (1997): Compendium Data Mining, Beilage zu: Computerwoche, 24. Jg., Nr. 49, 1997.

O'NEILL, PATRICK; QUASS, DALLAN (1998): Improved Query Performance with Variant Indexes, in: Stonebraker/Hellerstein (1998a), S. 543 - 554.

OBERSCHULTE, HANS (1994): Organisatorische Intelligenz: Ein integrativer Ansatz des organisatorischen Lernens, Mtinchen, Mehring 1994 (zugl. Saarbrucken, Universitat, Diss. 1994).

OLAP COUNCIL (1995): OLAP and OLAP Server Definitions, The OLAP Council, 0.0. 1995. http://www.olapcouncil.org/glossary.html.24.11.98.

OLAP COUNCIL (1997): The OLAP Council: Our Mission, 0.0. 1997. http://www.olapcouncil.org/index.html.24.11.98.

ORACLE CORPORATION (1993): Oracle7 Server-Administration. Bestandteil der Systemdokumentation zu Oracle 7,0.0. 1993.

bSTERLE, HUBERT; RIEM, RAINER; VOGLER, PETRA (Hrsg.) (1996): Middleware: Grundlagen, Produkte und Anwend\1ngsbeispiele fUr die Integration heterogener Welten, Braunschweig, Wiesbaden 1996.

bzsu, M. TAMER; VALDURIEZ, PATRICK (1991): Principles of Distributed Database Systems, Englewood Cliffs 1991.

PALFFY, THOMAS (1991): Denormalisierung beim Datenbankentwurf, in: Information Management, 6. Jg., Nr. 1, 1991, S. 48-55.

PECKHAM, JOAN M. (Hrsg.) (1997): SIGMOD 1997: Proceedings ACM SIGMOD International Conference on Management of Data, New York 1997 (zugl. SIGMOD Record, Vol. 26, No.2, June 1997).

PICOT, ARNOLD (1990): Der Produktionsfaktor Information in der UnternehmensfUhrung, in: Information Management, 5. Jg., Nr. 1,1990, S. 6 - 14.

PICOT, ARNOLD; FRANCK, EGON (1988): Die Planung der Unternehmensressource Information (1), in: WISU - Das Wirtschaftsstudium, 17. Jg., Nr. 10, Oktober 1988, S. 544 - 549.

PICOT, ARNOLD; MAIER, MATTHIAS (1994): Ansatze der Informationsmodellierung und ihre betriebswirtschaftliche Bedeutung, in: Zeitschrift fUr betriebswirtschaftliche Forschung zfbf, 46. J g., Nr. 2, Februar 1994, S. 107 - 126.

PICOT, ARNOLD; NEUBURGER, RAHILD; NIGGL, JOHANN (1993): Electronic Data Interchange (EDI) und Lean Management, in: Zeitschrift Ftihrung + Organisation, 62. Jg., Nr. 1, Januar 1993, S. 20 - 25.

POE, VillETTE (1996): Building a Data Warehouse for Decision Support, Upper Saddle River 1996.


POMBERGER, GUSTAV (1987): Softwaretechnik und Modula 2, 2. Auflage, Mtinchen 1987.

POMBERGER, GUSTAV (1990): Methodik der Softwareentwicklung, in: KurbeUStrunz (1990), S. 215 - 236.

RADEN, NEILL (1995): Data, Data Everywhere, in: Information Week, October 30, 1995, S. 6lff., http://users.aol.comlnradenliw_mct01.htm, 20.06.1996.

RADEN, NEILL (1996): Star Schema 101, White Paper, Archer Decision Sciences, Santa Barbara 1996. http://members.aol.comlnradenlstrlO1.htm, 10.11.1998.

RAHM, ERHARD (1994): Mehrrechner-Datenbanksysteme: Grundlagen der verteilten und parallelen Datenbankverarbeitung, Bonn et al. 1994.

RAUH, OTTO; STICKEL, EBERHARD (1997): Konzeptuelle Datenmodellierung, Stuttgart, Leipzig 1997.

RECHENBERG, PETER; POMBERGER, GUSTAV (1997): Informatik-Handbuch, Mtinchen, Wi en 1997.

RED BRICK SYSTEMS (1995): Star Schemas and ST ARjoin Technology, Whitepaper, Los Gatos 1995.

REDMAN, THOMAS C. (1996): Data Quality for the Information Age, Boston, London 1996.

RHO, SANGKYU (1997): Distributed Systems, in: Davis (1997a), S. 57 - 61.

RIEM, RAINER; VOGLER, PETRA (1996): Middleware: Infrastruktur fUr die Integration, in: OsterlelRiemIVogler (1996), S. 25 - 135.

RIGNEY, THERESA; FRANK, MAURICE (1996): DBMS Interview: Standardizing Metadata, in: DBMS online, February 1996, o.S., http://www.dbmsmag.coml int9602.html, 06.01.1997.

ROEING, FRANK (1996): Oracle7 Datenbanken erfolgreich einsetzen, Braunschweig, Wiesbaden 1996.

RUDIN, KEN (1996): What's New in Data Warehousing, in: DBMS online, Data Warehouse Supplement, August 1996, o.S., http://www.dbmsmag.coml 9608dOO.html, 17.09.97.

ROHLING, JURGEN (1996): Projektmanagement - Werkstattgepflegt: Das V-Modell in der Projektpraxis, in: iX - Magazin fUr professionelle Informationstechnik, Nr. 6, Juni 1996, S. 88 - 93.

SAPIA, CARSTEN; HOFLING, GABRIELE; DINTER, BARBARA (1997): OLAP-Architekturen: Eine Klassifikation jenseits von ROLAP, MOLAP, COLAP, HOLAP, Whitepaper, Bayerisches Forschungszentrum fUr wissensbasierte Systeme (FORWISS), Mtinchen 1997.


SCALZO, BERT (1996): Improving Oracle Data Warehouse Performance via Partitioning, in: Oracle Magazine, Vol. X, No.5, September/October 1996, S. 67 -70.

SCHEER, AUGUST-WILHELM (1996): Data Warehouse und Data Mining: Konzepte der Entscheidungsuntersttitzung, in: Information Management, 10. J g., Nr. 1, 1996, S. 74 - 75.

SCHEER, AUGUST-WILHELM (1997): Wirtschaftsinformatik: Referenzmodelle fUr industrielle Geschaftsprozesse, 7. Auflage, Berlin et al. 1997.

SCHEER, AUGUST-WILHELM (1998): ARIS - Modellierungsmethoden, Metamodelle, Anwendungen, 3. Auflage, Berlin et al. 1998.

SCHEK, HANS-JORG ET AL. (Hrsg.) (1998): Advances in Database Technology: Proceedings EDBT '98, 6th International Conference on Extending Database Technology, Berlin et al. 1998.

SCHEK, HANS-JORG; WEIKUM, GERHARD (1991): Erweiterbarkeit, Kooperation, F6deration von Datenbanksystemen, in: Appelrath (1991), S. 38 - 7l.

SCHELP, JOACHIM (1998): Konzeptionelle Modellierung mehrdimensionaler Datenstrukturen, in: Chamoni/Gluchowski (1998a), S. 263 - 276.

SCHIEMENZ, BERND (1993): Systemtheorie, betriebswirtschaftliche, in: Wittmann et al. (1993b), Sp. 4127 - 4140.

SCHINZER, HEIKO D. (1996): Entscheidungsorientierte Informationssysteme: Grundlagen, Anforderungen, Konzepte, Umsetzung, Mtinchen 1996 (zugl. Diss., Universitat Mtinchen 1995).

SCHINZER, HEIKO D. ET AL. (1997): Mangement mit Maus und Monitor: Ausgewahlte Business Intelligence-, OLAP- und Data Warehouse-Werkzeuge im Vergleich, Mtinchen 1997.

SCHINZER, HEIKO D.; BANGE, CARSTEN (1998): Werkzeuge zum Aufbau analytischer Informationssysteme - Markttibersicht, in: Chamoni/Gluchowski (1998a), S. 41 - 58.

SCHLAGETER, GUNTER; STUCKY, WOLFFRIED (1983): Datenbanksysteme: Konzepte und Modelle, 2. Auflage, Stuttgart 1983.

SCHMITZ, PAUL (1990): Softwarequalitatssicherung, in: KurbeUStrunz (1990), S. 309 - 320.

SCHNEIDER, DIETER (1997): Betriebswirtschaftslehre, Band 3: Theorie der Unternehmung, Mtinchen, Wi en 1997.

SCHNUPP, PETER (Hrsg.) (1991): Moderne Programmiersprachen, Mtinchen 1991.

SCHREIER, ULF (1996): Verarbeitungsprinzipien in Data-Warehousing-Systemen, in: Handbuch der modernen Datenverarbeitung (HMD), 33. Jg., Nr. 187, 1996, S. 78 - 93.


SCHREIER, ULF(1997): Data Dictionary, in: Mertens et al. (1997), S. 103 - 104.

SCHUMANN, MATTHIAS (1992): Betriebliche Nutzeffekte und Strategiebeitdige der groBintegrierten Informationsverarbeitung, Berlin et al. 1992 (zugl. Erlangen, Universitat, Habil.-Schr. 1990).

SCHUMANN, MATTHIAS (1997): Wirtschaftlichkeitsrechnung in der Informationsverarbeitung, in: Mertens et al. (1997), S. 436 - 437.

SCHWARZE, JOCHEN (1984): Mathematik ftir Wirtschaftswissenschaftler, Band 1: Grundlagen, 6. Auflage, Herne, Berlin 1984.

SCHWARZE, JOCHEN (1994): Einftihrung in die Wirtschaftsinformatik, 3. Auflage, Herne, Berlin 1994.

SCHWARZKOPF, A. B. (1997): The Virtual Data Warehouse for Small Business, Conference Paper, Association for Information Systems (AIS), Third Americas Conference on Information Systems, Indianapolis, August 15-17, 1997, http://hsb.baylor.edu/ramsower/ais.ac.97/papers/schwarz.htm, 15.05.98.

SHARP, BILL (1993): Managing a Merger: HR Systems Migration, in: Datamation, February 15, 1993, S. 71 -74.

SHETH, AMIT P.; LARSON, JAMES A. (1990): Federated Database Systems for Managing Distributed, Heterogenous, and Autonomous Databases, in: ACM Computing Surveys, Vol. 22, No.3, 1990, S. 183 - 236.

SILVERSON, LEN; INMON, WILLIAM H.; GRAZIANO, KENT (1997): The Data Model Resource Book: A Library of Logical Data Models and Data Warehouse Designs, New York et al. 1997.

SINZ, ELMAR J. (1990): Das Entity-Relationship-Modell und seine Erweiterungen, in: Handbuch der modernen Datenverarbeitung (HMD), 27. Jg., Nr. 152, 1990, S. 17 - 29.

SIU, BRIAN ET AL. (Hrsg.) (1997): Data Mining, Data Warehousing & Client/Server Databases, Proceedings of the 8th International Database Workshop, Industrial Volume, Singapore 1997.

SMALL, ROBERT D.; EDELSTEIN, HERBERT A. (1997): Scalable Data Mining, in: BarquinlEdelstein (1997a), S. 151 - 172.

SNYDER, MICHAEL (1993): A Data Integrity Tutorial. In McClain (1993), S. 225 - 239.

SOEFFKY, MANFRED (1999): Datenaufbereitung fi.ir das Data Warehouse, in: it Fokus, Magazin fi.ir Intelligent Enterprise Computing, Nr. 3, Mlirz 1999, S. 14 - 22.

SOMMERVILLE, IAN (1987): Software Engineering, Bonn et al. 1987.

SORTER, GEORGE H. (1969): An "Events" Apporach to Basic Accounting Theory, in: The Accounting Review, Vol. 44, No.1, January 1969, S. 14 - 19.


STAHLKNECHT, PETER; HASENKAMP, ULRICH (1997): EinfUhrung in die Wirtschaftsinformatik, 8. Auflage, Berlin et al. 1997.

STICKEL, EBERHARD ET AL. (1995): Verfahren zur werkzeuggesttitzten Integration von Datenbankschemata, in: Konig (1995), S. 205 - 222.

STONEBRAKER, MICHAEL; HELLERSTEIN, JOSEPH M. (Hrsg.) (1998a): Readings in Database Systems, 3rd ed., San Francisco 1998.

STONEBRAKER, MICHAEL; HELLERSTEIN, JOSEPH M. (1998b): Distributed Database Systems, in: Stonebraker/Hellerstein (1998a), S. 321 - 328.

STREHLO, KEVIN (1996): Data Warehousing: Avoid Planned Obsolescence, in: Datamation, January 15, 1996, S. 32 - 36.

STREUBEL, FRAUKE (1996): Theoretische Fundierung eines ganzheitlichen Informationsmanagements, Arbeitsberichte des Lehrstuhls fUr Wirtschaftsinformatik 96-21, Ruhr-Universitat Bochum, Bochum 1996.

STUCKY, WOLFFRIED; KRIEGER, RUDOLF (1990): Datenbanksysteme, in: Kurbell Strunz (1990), S. 837-856.

STULPNAGEL, ALEXANDER VON (1984): Data Dictionary, in: Handbuch der modernen Datenverarbeitung, Nr. 118 (1984), S. 59-70.

STURNER, GUNTHER (1991): SQL - Die Datenbanksprache, in: Schnupp (1991), S.205-232.

SU, STANLEY Y. W. (1996): Proceedings of the Twelfth International Conference on Data Engineering, Los Alamitos et al. 1996.

SZYPERSKI, NORBERT (1980): Informationsbedarf, in: Grochla (1980), Sp. 904 - 914.

TESCHKE, MICHAEL (1997): SQL, in: Mertens et al. (1997), S. 377 - 378.

THALHEIM, BERNHARD; LIB KIN, LEONID (Hrsg.) (1998): Semantics in Databases, Berlin et al. 1998.

TOTOK, ANDREAS (1998): Controllinganwendungen mit OLAP, in: Zeitschrift fUr Planung, Nr. 9, September 1998, S. 161 - 180.

TOTOK, ANDREAS; JAWORSKI, RAMON (1998): Modellierung von multidimensionalen Datenstrukturen mit ADAPT: Ein Fallbeispiel, Berichte des Instituts fUr Wirtschaftswissenschaften der Technischen Universitat Braunschweig Nr. 98/11, Braunschweig 1998.

TRESCH, MARKUS (1996): Middleware: Schliisseltechnologie zur Entwicklung verteilter Informationssysteme, in: Informatik-Spektrum, 19. Jg., Nr. 5, Oktober 1996, S. 249 - 256.

UHR, WOLFGANG; BREUER, SVEN-EINAR (Hrsg.) (1998): Integration externer Informationen in Management Support Systems, Tagungsband zur Wirtschaftsinformatik-Fachtagung, Technische Universitat Dresden, Dresden 1998.


VEUALAINEN, JARI (1989): Transaction Concepts in Autonomous Database Environments, Miinchen, Wien 1989 (zugl. Berlin, Technische Universitat, Diss. 1989).

VERSTEEGEN, GERHARD (1994): Projektmanagement - Von Amts wegen: Softwareerstellung nach dem V-Modell, in: iX - Magazin fUr professionelle Informationstechnik, Nr. 11, November 1994, S. 162 - 166.

VERSTEEGEN, GERHARD (1996): V-gefertigt - Das fortgeschriebene Vorgehensmodell, in iX - Magazin fUr professionelle Informationstechnik, Nr. 9, September 1996, S. 140 - 147.

VETTER, MAX (1990): Konzeptionelle Datenmodellierung, in: KurbellStrunz (1990), S. 383 - 401.

VETTER, MAX (1991): Aufbau betrieblicher Informationssysteme mittels objektorientierter, konzeptioneller Datenmodellierung, 7. Auflage, Stuttgart 1991.

VETTER, MAX (1993): Strategie der Anwendungssoftware-Entwicklung: Methoden, Techniken, Tools einer ganzheitlichen, objektorientierten Vorgehensweise, 3. Auflage, Stuttgart 1993.

VETTER, MAX (1990): Informationssysteme in der Unternehmung: Eine EinfUhrung in die Datenmodellierung und Anwendungsentwicklung, Stuttgart 1990.

VOSSEN, GOTTFRIED (1994): Datenmodelle, Datenbanksprachen und DatenbankManagement-Systeme, 2. Auflage, Bonn, Paris 1994.

WACKER, WILHELM H. (1971): Betriebswirtschaftliche Informationstheorie: Grundlagen des Informationssystems, Opladen 1971.

WAND, YAIR; WANG, RICHARD Y. (1996): Anchoring Data Quality Dimensions in Ontological Foundations, in: Communications of the ACM, Vol. 39, No. 11, November 1996, S. 86 - 95.

WANG, RICHARD Y.; STOREY, VEDA c.; FIRTH, CHRISTOPHER P. (1995): A Framework for Analysis of Data Quality Research, in: IEEE Transactions on Knowledge and Data Engineering, Vol. 7, No.4, August 1995, S. 623 - 640.

WARDEN, ANDREW (1990): Adventures in Relationland, in: Date (1990), S. 451 - 521.

WATSON, HUGH; HALEY, BARBARA J. (1998): Data Warehousing: A Framework and Survey of Current Practices, in: Chamoni/Gluchowski (1998a), S. 27 - 39.

WATZLAWEK, N.; FRONHOFF, S. (1998): Objektorientierte Detektivarbeit, in: Computerwoche Extra: Software-Trends - zwischen alten und neuen Welten, Nr. 1, 20.02.98, S. 27 - 29.

WEBER, HANS WERNER; STRUNGMANN, UWE (1997): Data Warehouse und Controlling: Eine vielversprechende Partnerschaft, in: Controlling, 9. Jg., Nr. 1, Januar/Februar 1997, S. 30 - 36.

WEDEKIND, HARTMUT (1991): Datenbanksysteme, 3. Auflage, Mannheim et al. 1991.


WEDEKIND, HARTMUT (1997): Datenmodell, in: Mertens et al. (1997), S. 118 - 120.

WELCH, J.D. (1997): Updating the Data Warehouse, in: BarquiniEdelstein (1997a), S. 173 - 210.

WELLS, DAVID; CARNELLEY, PHILIP (1996): Ovum Evaluates: The Data Warehouse, Ovum Ltd., London 1996.

WHITE, COLIN (1995): The Key to a Data Warehouse, in: Database Programming & Design, No.2, February 1995, o.S., http://www.dc.enews.comJdataimagazines/alphaldf/data_pd/Archive/020195.2, 17.02.97.

WIEKEN, JOHN-HARRY (1998): Meta-Daten fUr Data Marts und Data Warehouses, in: MuckschlBehme (1998a), S. 275 - 315.

WINTERKAMP, TIEMO (1995): OLAP: Prazisere Information durch mehrdimensionale Sicht, in: Computerwoche, Nr. 41,13. Oktober 1995, S. 50 - 51.

WISSENSCHAFfLICHE KOMMISSION WIRTSCHAFfSINFORMATIK (1994): Profil der Wirtschaftsinformatik, in: Wirtschaftsinformatik, 36. Jg., Nr. 1, Februar 1994, S. 80 - 81.

WITTMANN, WALDEMAR (1959): Unternehmung und unvollkommene Information, KOln,Opladen 1959.

WITTMANN, WALDEMAR ET AL. (Hrsg.) (1993a): Handworterbuch der Betriebswirtschaft, Teilband 2, 5. Auflage, Stuttgart 1993.

WITTMANN, WALDEMAR ET AL. (Hrsg.) (1993b): Handworterbuch der Betriebswirtschaft, Teilband 3, 5. Auflage, Stuttgart 1993.

YAZDANI, SIMA; WONG, SHIRLEY S. (1998): Data Warehousing with Oracle: An Administrator's Handbook, Upper Saddle River 1998.

YEVICH, RICHARD (1997): VLDBs and Parallelism, in: Bischoff! Alexander (1997), S. 226 - 237.

ZANIOLO, CARLO (Hrsg.) (1981): Proceedings of the 7'h International Conference on Very Large Data-Bases, Los Angeles 1981.

ZEHNDER, CARL AUGUST (1989): Informationssysteme und Datenbanken, 5. Auflage, Stuttgart 1989.

ZEHNDER, CARL AUGUST (1998): Informationssysteme und Datenbanken, 6. Auflage, Stuttgart 1998.

ZELL, MICHAEL (1997): Informationstechnische Gestaltung von Fiihrungsinformationssystemen, in: Controlling, 9. Jg., Nr. 4, Juli/August 1997, S. 290 - 301.

ZHOU, GANG ET AL. (1995a): Data Integration and Warehousing Using H20, in: Bulletin of the Technical Committee on Data Engineering, IEEE Computer Society, Vol. 18, No.2, June 1995, S. 29 - 40.


ZHOU, GANG ET AL. (1995b): Using Object Matching and Materialization to Integrate Heterogeneous Databases, in: LaufmanniSpaccapietralYokoi (1995), S. 4 - 18.

ZHUGE, YUE; GARCIA-MOLINA, HECTOR; WIENER, JANET L. (1998): Consistency Algorithms for Multi-Source Warehouse View Maintenance, in: Journal of Distributed and Parallel Databases, Vol. 6, No.1, January 1998, S. 7 -40.

Documents

Transformation operativer Daten zur Nutzung im Data Warehouse