transformation operativer daten zur nutzung im data warehouse
Post on 11-Sep-2021
0 Views
Preview:
TRANSCRIPT
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
Abkiirzungsverzeichnis
Abkiirzungsverzeichnis
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
Abkiirzungsverzeichnis
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.
Begriffsbestimmungen 7
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.
Begriffsbestimmungen 9
(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.
Begriffsbestimmungen 11
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.
Begriffsbestimmungen 13
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.
Begriffsbestimmungen 15
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.
Begriffsbestimmungen 17
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
2 Operative Informationssysteme
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.
20 Operative Informationssysteme
2.1 Bedeutung und Ziele
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.
22 Operative Informationssysteme
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.
Bedeutung und Ziele 23
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.
24 Operative Informationssysteme
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.
Bedeutung und Ziele 25
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.
26 Operative Informationssysteme
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.
Bedeutung und Ziele 27
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.
Bedeutung und Ziele 29
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.
30 Operative Informationssysteme
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).
Bedeutung und Ziele 31
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.
32 Operative Informationssysteme
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.
34 Operative Informationssysteme
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.
Datenmodelle und Reprasentationsformen 35
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.
36 Operative Informationssysteme
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.
Datenmodelle und Reprasentationsformen 37
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.
38 Operative Informationssysteme
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.
Datenmodelle und Reprasentationsformen 39
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.
40 Operative Informationssysteme
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.
42 Operative Informationssysteme
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.
Datenmodelle und Reprasentationsformen 43
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).
44 Operative Informationssysteme
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.
Architekturen und Komponenten 47
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.
48 Operative Informationssysteme
• 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.
Architekturen und Komponenten 49
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.
50 Operative Informationssysteme
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.
52 Operative Informationssysteme
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.
Architekturen und Komponenten 53
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.
54 Operative Informationssysteme
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.
Architekturen und Komponenten 55
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.
56 Operative Informationssysteme
• 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.
Architekturen und Komponenten 57
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.
58 Operative Informationssysteme
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.
Architekturen und Komponenten 59
• 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.
60 Operative Informationssysteme
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.
Architekturen und Komponenten 61
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.
62 Operative Informationssysteme
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.
Architekturen und Komponenten 63
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
lokales internes Schema
lokales internes 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.
64 Operative Informationssysteme
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.
Architekturen und Komponenten 65
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.
66 Operative Informationssysteme
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.
Architekturen und Komponenten 67
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.
68 Operative Informationssysteme
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.
72 Operative Informationssysteme
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.
Metadatenverwaltung transaktionsorientierter Informationssysteme 73
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.
74 Operative Informationssysteme
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".
76 Operative Informationssysteme
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.
Metadatenverwaltung transaktionsorientierter Informationssysteme 77
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.
78 Operative Informationssysteme
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.
82 Analyseorientierte Informationssysteme
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).
3.1 Bedeutung und Ziele
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.
Bedeutung und Ziele 83
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.
84 Analyseorientierte Informationssysteme
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.
Bedeutung und Ziele 85
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.
86 Analyseorientierte Informationssysteme
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.
Bedeutung und Ziele 87
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.
88 Analyseorientierte Informationssysteme
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.
Bedeutung und Ziele 89
- 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.
90 Analyseorientierte Informationssysteme
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.
Datenmodelle und Reprasentationsformen 91
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.
92 Analyseorientierte Informationssysteme
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.
Datenmodelle und Reprasentationsformen 93
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.
94 Analyseorientierte Informationssysteme
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.
Datenmodelle und Reprasentationsformen 95
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.
96 Analyseorientierte Informationssysteme
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.
Datenmodelle und Reprasentationsformen 97
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).
98 Analyseorientierte Informationssysteme
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.
Datenmodelle und Reprasentationsformen 99
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.
100 Analyseorientierte Informationssysteme
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.
102 Analyseorientierte Informationssysteme
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.
Architekturen und Komponenten 103
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.
Architekturen und Komponenten 105
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.
106 Analyseorientierte Informationssysteme
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.
Architekturen und Komponenten 107
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).
Architekturen und Komponenten 109
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.
110 Ana1yseorientierte Informationssysteme
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.
112 Analyseorientierte Informationssysteme
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.
Architekturen und Komponenten 113
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.
114 Analyseorientierte Informationssysteme
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.
Architekturen und Komponenten 115
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.
116 Analyseorientierte Informationssysteme
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!.
Architekturen und Komponenten 117
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.
118 Analyseorientierte Informationssysteme
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.
Architekturen und Komponenten 119
(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.
120 Analyseorientierte Informationssysteme
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.
122 Analyseorientierte Informationssysteme
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).
Metadatenverwaltung analyseorientierter Informationssysteme 123
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
124 Analyseorientierte Informationssysteme
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).
Metadatenverwaltung analyseorientierter Informationssysteme 125
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.
126 Analyseorientierte Informationssysteme
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.
Metadatenverwaltung analyseorientierter Informationssysteme 127
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.
128 Analyseorientierte Informationssysteme
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-
Metadatenverwaltung analyseorientierter Informationssysteme 129
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).
130 Analyseorientierte Informationssysteme
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
132 Ana1yseorientierte Informationssysteme
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.
134 Analyseorientierte Informationssysteme
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.
Metadatenverwaltung analyseorientierter Informationssysteme 135
• 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:
136 Analyseorientierte Informationssysteme
"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.
Metadatenverwaltung analyseorientierter Informationssysteme 137
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).
138 Ana1yseorientierte Informationssysteme
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.
140 Analyseorientierte Informationssysteme
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.
146 Funktionale und inhaltliche Aspekte der Transformation
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.
150 Funktionale und inhaltliche Aspekte der Transformation
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.
152 Funktionale und inhaltliche Aspekte der Transformation
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.
156 Funktionale und inhaltliche Aspekte der Transformation
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-
Gewinnung und Transformation von Daten fUr das Data Warehouse 159
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.
164 Funktionale und inhaltliche Aspekte der Transformation
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.
Gewinnung und Transformation von Daten fUr das Data Warehouse 165
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.
166 Funktionale und inhaltliche Aspekte der Transformation
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).
Gewinnung und Transformation von Daten fur das Data Warehouse 167
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).
168 Funktiona1e und inhaltliche Aspekte der Transformation
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.
170 Funktionale und inhaltliche Aspekte der Transformation
• 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.
Gewinnung und Transformation von Daten fUr das Data Warehouse 171
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.
172 Funktionale und inhaltliche Aspekte der Transformation
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.).
174 Funktionale und inhaltliche Aspekte der Transformation
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.
Gewinnung und Transformation von Daten fUr das Data Warehouse 175
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.
176 Funktionale und inhaltliche Aspekte der Transformation
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.
Gewinnung und Transformation von Daten fUr das Data Warehouse 177
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
178 Funktionale und inhaltliche Aspekte der Transformation
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.
Gewinnung und Transformation von Daten fiir das Data Warehouse 179
- 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.
Gewinnung und Transformation von Daten fiir das Data Warehouse 181
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.
182 Funktionale und inhaltliche Aspekte der Transformation
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.
Gewinnung und Transformation von Daten fur das Data Warehouse 183
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
184 Funktionale und inhaltliche Aspekte der Transformation
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.
Gewinnung und Transformation von Daten fiir das Data Warehouse 185
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.
186 Funktionale und inhaltliche Aspekte der Transformation
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.
Gewinnung und Transformation von Daten fiir das Data Warehouse 187
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.
188 Funktionale und inhaltliche Aspekte der Transformation
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.
Gewinnung und Transformation von Daten fur das Data Warehouse 189
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.
190 Funktiona1e und inhaltliche Aspekte der Transformation
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.
Gewinnung und Transformation von Daten fUr das Data Warehouse 191
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),
192 Funktionale und inhaltliche Aspekte der Transformation
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.
Gewinnung und Transformation von Daten fUr das Data Warehouse 193
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).
Gewinnung und Transformation von Daten fUr das Data Warehouse 195
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.
196 Funktionale und inhaltliche Aspekte der Transformation
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.
Gewinnung und Transformation von Daten fUr das Data Warehouse 197
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.
198 Funktionale und inhaltliche Aspekte der Transformation
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.
200 Funktionale und inhaltliche Aspekte der Transformation
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.
202 Funktionale und inhaltliche Aspekte der Transformation
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.
204 Funktionale und inhaltliche Aspekte der Transformation
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.
210 Anforderungen an die Transformationskomponente
• 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.
212 Anforderungen an die Transformationskomponente
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.
Vorgehen bei der Data Warehouse-Entwicklung 213
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.
214 Anforderungen an die Transformationskomponente
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.
Vorgehen bei der Data Warehouse-Entwicklung 215
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.
216 Anforderungen an die Transformationskomponente
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-
Vorgehen bei der Data Warehouse-Entwicklung 217
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.
218 Anforderungen an die Transformationskomponente
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-
Vorgehen bei der Data Warehouse-Entwicklung 219
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.
Vorgehen bei der Data Warehouse-Entwicklung 221
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
Vorgehen bei der Data Warehouse-Entwicklung 223
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.
224 Anforderungen an die Transformationskomponente
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-
226 Anforderungen an die Transformationskomponente
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
228 Anforderungen an die Transformationskomponente
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-
230 Anforderungen an die Transformationskomponente
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.
232 Anforderungen an die Transformationskomponente
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-
Phasenspezifische Anforderungen 233
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.
234 Anforderungen an die Transformationskomponente
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-
236 Anforderungen an die Transformationskomponente
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.
Phasenspezifische Anforderungen 237
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.
238 Anforderungen an die Transformationskomponente
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
Phasenspezifische Anforderungen 239
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.
240 Anforderungen an die Transformationskomponente
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
Phasenspezifische Anforderungen 241
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.
242 Anforderungen an die Transformationskomponente
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 249
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.
Literaturverzeichnis 251
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.
252 Literaturverzeichnis
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.
Literaturverzeichnis 253
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.
254 Literaturverzeichnis
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.
Literaturverzeichnis 255
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.
256 Literaturverzeichnis
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.
Literaturverzeichnis 257
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.
258 Literaturverzeichnis
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.
Literaturverzeichnis 259
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.
260 Literaturverzeichnis
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.
Literaturverzeichnis 261
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.
262 Literaturverzeichnis
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.
Literaturverzeichnis 263
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.
264 Literaturverzeichnis
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.
Literaturverzeichnis 265
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.
266 Literaturverzeichnis
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.
Literaturverzeichnis 267
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.
268 Literaturverzeichnis
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.
Literaturverzeichnis 269
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.
270 Literaturverzeichnis
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.
Literaturverzeichnis 271
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.
272 Literaturverzeichnis
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.
Literaturverzeichnis 273
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.
274 Literaturverzeichnis
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.
Literaturverzeichnis 275
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.
top related