Sie sind auf Seite 1von 695

Der Data Warehouse Spezialist

Die Integrata Qualifizierung


Herausgegeben von der Integrata Training AG
und Dr. Ingrid Mikosch
Reinhard Höhn

Der Data Warehouse


Spezialist
Entwurf, Methoden und Umsetzung
eines Data Warehouses

ADDISON-WESLEY
An imprint of Pearson Education
München • Boston • San Francisco • Harlow, England
Don Mills, Ontario • Sydney • Mexico City • Madrid • Amsterdam
Die Deutsche Bibliothek – CIP-Einheitsaufnahme

Ein Titeldatensatz für diese Publikation ist bei


der Deutschen Bibliothek erhältlich.

Die Informationen in diesem Produkt werden


ohne Rücksicht auf einen eventuellen Patentschutz veröffentlicht.
Warennamen werden ohne Gewährleistung
der freien Verwendbarkeit benutzt.
Bei der Zusammenstellung von Texten und Abbildungen
wurde mit größter Sorgfalt vorgegangen.
Trotzdem können Fehler nicht vollständig ausgeschlossen werden.
Verlag, Herausgeber und Autoren
können für fehlerhafte Angaben und deren Folgen weder eine
juristische Verantwortung noch irgendeine Haftung übernehmen.
Für Verbesserungsvorschläge und Hinweise
auf Fehler sind Verlag und Herausgeber dankbar.

Alle Rechte vorbehalten, auch die der fotomechanischen Wieder-


gabe und der Speicherung in elektronischen Medien.
Die gewerbliche Nutzung der in diesem Produkt
gezeigten Modelle und Arbeiten ist nicht zulässig.

Fast alle Hardware- und Softwarebezeichnungen, die in diesem


Buch erwähnt werden, sind gleichzeitig auch eingetragene Waren-
zeichen oder sollten als solche betrachtet werden.

Umwelthinweis:
Dieses Produkt wurde auf chlorfrei gebleichtem Papier gedruckt.
Die Einschrumpffolie – zum Schutz vor Verschmutzung – ist aus
umweltverträglichem und recyclingfähigem PE-Material.

10 9 8 7 6 5 4 3 2 1
03 02 01 00

ISBN 3-8273-1445-3

© 2000 by Addison-Wesley Verlag,


ein Imprint der Pearson Education Deutschland GmbH
Martin-Kollar-Straße 10–12, D-81829 München/Germany
Alle Rechte vorbehalten
Einbandgestaltung: niesner & huber, Wuppertal
Lektorat: Dr. Ingrid Mikosch, Rudolf Krahm, Bonn,
Christian Schneider, cschneider@pearson.de
Herstellung: Anna Plenk, aplenk@pearson.de
Satz: reemers publishing services gmbh, Krefeld
Gesetzt aus der Stone Serif 9 pt.
Druck: Schoder Druck, Gersthofen
Printed in Germany
Meinen lieben Eltern
Meinen Töchtern Juliane, Sabrina und Antonia
Meiner Frau Martina
Inhaltsverzeichnis 7

Inhaltsverzeichnis
Vorwort 11

Einleitung 15
Welche Themenkomplexe umfasst dieses Buch? 15
Wie ist das Buch aufgebaut? 18
Zeichenerklärung 20
Das durchgängige Übungsbeispiel 20

1 Orientierung zum Thema Data Warehouse 23


1.1 Wie unterscheidet sich der Data Warehouse Ansatz von früheren
Ansätzen? 25
1.2 Wie sind Markttendenzen im Umfeld des Data Warehouse zu
erkennen? 43
1.3 Wie ist das Vorhaben Data Warehouse im
Unternehmenszusammenhang zu sehen? 65
1.4 Übungen 85
1.5 Zusammenfassung der Entscheidungsgänge 87

2 Was ist eine Architektur eines Informationssystems? 91


2.1 Systemanalyse 93
2.2 Beispiele von Architekturen 96
2.3 Die Architekturkategorien von DWH 104
2.4 Die Gestaltungszyklen des DWH 109
2.5 Fortsetzungsbeispiel InDaWa 117
2.6 Übungen 119
2.7 Zusammenfassung 120

3 Welche betriebswirtschaftlichen Komponenten hat ein DWH? 121


3.1 Betriebswirtschaftliche Funktionalität 125
3.2 Branchen 138
3.3 Hierarchieebenen 144
3.4 Fortsetzungsbeispiel InDaWa 153
3.5 Übungen 156
3.6 Zusammenfassung der Entscheidungsgänge 157

4 Welche Softwarekomponenten sind für ein DWH einzusetzen? 163


4.1 Die softwaretechnischen Komponenten und Tools des DWH 165
4.2 Die Funktionalität des DWH 193
4.3 Die softwaretechnischen Technologietypen 211
4.4 Fortsetzungsbeispiel InDaWa 221
4.5 Übungen 225
4.6 Zusammenfassung der Entscheidungsgänge 226
8 Inhaltsverzeichnis

5 Welche Hardwarekomponenten und Netzinfrastrukturen sind für den


Betrieb eines DWH erforderlich?231
5.1 Netzkomponenten für den Betrieb des DWH 233
5.2 Rechnerkonfiguration für den Betrieb des DWH 254
5.3 Bestimmung der Betriebssysteme 272
5.4 Bestimmung der Peripheriekomponenten 282
5.5 Allokation der Softwarekomponenten 288
5.6 Exkurs Client/Server-Architektur 293
5.7 Fortsetzungsbeispiel InDaWa 297
5.8 Übungen 301
5.9 Zusammenfassung der Entscheidungsgänge zur
Hardwaregestaltung 302

6 Welche Organisationsstruktur muss für ein Data Warehouse System


implementiert werden? 307
6.1 Welcher Umweltausschnitt ist für den Entwurf eines
DWH relevant? 309
6.2 Welcher Umfeldausschnitt ist für den Entwurf eines
DWS relevant? 313
6.3 Grundbegriffe zur Organisation 317
6.4 Organisation des Betriebes des DWH 335
6.5 Exkurs: IT- Strategie und Unternehmensstrategie 350
6.6 Fortsetzungsbeispiel InDaWa 353
6.7 Übungen 356
6.8 Zusammenfassung des Entscheidungsganges 358

7 Das Vorgehensmodell zum Aufbau von DWH-Systemen 361


7.1 Wie wird ein DWH-Vorhaben abgewickelt? 364
7.2 Wozu dienen Softwaremodelle und wie ist ein Softwaremodell
aufgebaut? 386
7.3 Wie sieht ein DWH-Konzept aus? 393
7.4 Wie wird ein DWH-System spezifiziert? 414
7.5 Das Fortsetzungsbeispiel InDaWa 441
7.6 Übungen 444
7.7 Zusammenfassung 445

8 Projektierung und Betrieb eines Data Warehouse Systems 447


8.1 Wie wird ein DWH-Vorhaben projektiert? 449
8.2 Wie wird ein DWH-Projekt organisiert? 489
8.3 Wie wird ein DWH-Projekt umgesetzt? 513
8.4 Fortsetzungsbeispiel InDaWa 524
8.5 Übungen 527
8.6 Zusammenfassung 529
Inhaltsverzeichnis 9

9 Data Warehouse Produkte 531


9.1 Welche Produktreihen bieten die Hersteller an? 533
9.2 Wie wird ein DWH-Softwaremodul evaluiert? 538
9.3 Die Nutzenanalyse am Beispiel der Client/Server-
Architekturentscheidung 554
9.4 Welche Lösungskonzepte bieten die Hersteller von
DWH-Produkten? 566
9.5 Fortsetzungsbeispiel InDaWa 582
9.6 Übungen 585
9.7 Zusammenfassung 586

10 Betrieb und Abbau eines Data Warehouse Systems 589


10.1 Wie wird das DWH betrieben? 591
10.2 Organisation des Abbaus des DWH 614
10.3 Fortsetzungsbeispiel InDaWa 626
10.4 Übungen 628
10.5 Zusammenfassung 629

A Anhang 631
A.1 Zusammenfassung der Ergebnisse der Gestaltung 631
A.2 Ausblick und Randthemen 637
A.3 Schluss 641

B Anhang 645
B.1 Beispiel für Stellenbeschreibungen 645

Lösungen 652
B.2 Lösungen ausgewählter Übungen Kapitel 1 652
B.3 Lösungen ausgewählter Übungen Kapitel 4 653
B.4 Lösungen ausgewählter Übungen Kapitel 5 656
B.5 Lösungen ausgewählter Übungen Kapitel 6 657
B.6 Lösungen ausgewählter Übungen Kapitel 7 657

Literaturverzeichnis 662
B.7 Monographien 662
B.8 Zeitschriften 676
B.9 Schwerpunkthefte der Zeitschriften 677
B.10 DWH-Studien 678
B.11 Abbildungsverzeichnis 680

Index 681
11

VORWORT
Vorwort
Das Data Warehouse
»Data Warehouse«, »Data Mart«, »Information Warehouse«, »Data Mining«,
OLAP, ROLAP, MOLAP – allesamt sind Modeworte, die zu den Lieblingsthemen
der Marktforscher gehören. Data Warehouse hat als Beratungsprodukt den Auf-
stieg in die erste Liga des Consulting geschafft und gehört zu den Pflichtthe-
men der EDV-Abteilungsleiter. Es ist sogar zu einem Kapitel in der Wirtschafts-
informatik-Vorlesung der Hochschulen avanciert. Wenn sich so viele Parteien
einig sind, dann liegt dies entweder an der Suggestivkraft der Begriffe oder es
liegt an der tatsächlichen Leistungsfähigkeit der dahinter stehenden Konzepte
und Produkte. Immer dort, wo das Interesse der Kunden groß ist, wächst auch
der Einfallsreichtum der Werbespezialisten. Plötzlich und fast aus dem Nichts
heraus entstehen neue Produkte, um die sich schnell Erfolgsgeschichten ran-
ken, und schneller als man wünscht befindet man sich auf einem Tummelplatz
der Schönmalerei. Es ist ein Anliegen dieses Buches, so viel Transparenz in das
Thema Data Warehouse zu bringen, dass man vor den Versprechungen der
Hochglanzprospekte gefeit ist und bei Entscheidungen kühlen Kopf behalten
kann.
Das »Data Warehouse« wird von Herstellern häufig heruntergespielt nach dem
Motto: »Kaufen Sie meinen OLAP-Server, meine Consultants bauen Ihren Mul-
tiwürfel in zwei Wochen auf und Sie haben ein unternehmensweites Data Ware-
house.« Um es vorwegzunehmen: Ein Data Warehouse ist kein Produkt, das
schnell über den Ladentisch geht, sondern ein höchst komplexes Vorhaben.
Dieses Vorhaben umfasst unter anderem
✔ die Beschaffung von Softwareprodukten
✔ die Beschaffung neuer Hardware
✔ die Eigenentwicklung von Software
✔ das Customizing von Softwarekomponenten
✔ die Anwendung von Methoden der Systemanalyse
✔ Anpassungen der Organisationsstruktur (zum Beispiel wird eine Reihe
neuer Spezialisten und eine Stelle namens Data Warehouse Spezialist
nötig)
und sogar Änderungen in der Geisteshaltung konventioneller EDV. Ohne
bereits eine Definition vorwegzunehmen, sei gleich am Anfang das diesem
Buch zugrunde liegende Verständnis des Begriffs »Data Warehouse« dargelegt.
12 Vorwort

Ein Data Warehouse wird hier als ein mit allen operativen Daten eines Unter-
nehmens arbeitendes, integrierendes System aus Softwarekomponenten auf-
gefasst, das mittels einer Hardware-Infrastruktur betrieben wird. Ein Data
Warehouse durchläuft einen Lifecyle aus Initiierung, Projektierung, Konzep-
tion, Spezifikation, Beschaffung, Realisierung, Implementierung, Betrieb und
Abbau. Ein Data Warehouse reiht sich somit in die Gruppe der beratungsinten-
siven Produkte ein.
Das Thema Qualifizierung
Eine neue Qualifikationssituation erfordert eine neue Ausbildungskonzeption.
Viel stärker als in früheren Berufszeiten muss die Qualifikation der Mitarbeiter
ein mit dem Ausüben des Berufes verzahnter und kontinuierlicher Prozess sein.
Der Schwerpunkt für eine neue Qualifkationskonzeption liegt daher nicht
mehr in der reinen Wissensvermittlung und dem Abfragen durch Übungen.
Neue Ausbildungskonzeptionen konzentrieren sich auf das Durchspielen der
Praxis, das Üben von Entscheidungssituationen, die Vermittlung von Hilfestel-
lungen bei der Zielefindung, angepasst an die Praxissituation und auf die
Bereitstellung der Mittel, die nötig sind, um diese Ziele erreichen zu können.
Das Buch hat sich daher die Aufgabe gestellt, einen diesen neuen Lernanforde-
rungen entsprechenden Qualifizierungsansatz für eine neue Berufsgruppe, die
Data Warehouse Spezialisten, darzustellen. Diese sind im Einzelnen der Data
Warehouse Konzeptionist, der Data Warehouse Consultant, der Data Ware-
house Manager, der Data Warehouse Administrator, der Data Warehouse Trainer
und der Data Warehouse Projektleiter.
Die Konzeption des Buches
Das Ziel dieses Buches ist die Vermittlung des Grundwissens zu dieser moder-
nen Berufsgruppe aus der Welt der Informationstechnologie in Form eines
autodidaktischen Seminars. Das vorliegende Buch kann daher in einem Inten-
sivseminar von etwa fünf Tagen an exemplarischen Entscheidungssituationen
eines Beispielprojekts durchgespielt werden. Der Aufbau folgt einer Gliederung
in Lernstufen.
Das Buch soll nach dem Durcharbeiten nicht in einem Schrank abgelegt wer-
den, sondern auch im Berufsalltag verwendbar sein. Es ist Ausbildungshilfe und
Nachschlagewerk für die Praxis. Es dient dem Data Warehouse Spezialisten
dazu, eine vorliegende Projektsituation zu identifizieren und das entsprechende
Hilfsmittel im Buch zu finden. Dieses Hilfsmittel kann z.B. eine Tabelle mit
durchdachter Struktur, eine Checkliste mit Einträgen, eine Übersichtsgrafik
oder ein Symbolevorrat zur Visualisierung sein. Das Buch ist damit viel mehr
methodische Hilfe als Lehrmittel.
Projekte sind immer einmalig. Kunden, Projektteam, Ort, Mittel und nicht
zuletzt die Aufgabenstellung sind immer unterschiedlich. Kein Projekt ist von
Beginn an klar definiert, auch wenn es sehr große Ähnlichkeit mit bereits abge-
wickelten Projekten haben sollte. Jedes Projekt ist ein kontinuierliches Dazu-
lernen, ein umfassender Lernvorgang. Jede neue Erkenntnis kann zu einer
Vorwort 13

Neuausrichtung der Projekttätigkeiten, zu einer Kurskorrektur der anfänglich


formulierten Aufgabenstellung zwingen. Von Projektetappe zu Projektetappe
wird der nächste Projektabschnitt präziser definiert. Deshalb wird jedes Projekt
in Etappen abgewickelt. Etappen sind Konsolidierungsphasen des Hinzugelern-
ten. Diese Genese des DWH-Wissens über Projektetappen wird in diesem Buch
nachvollzogen. Dadurch wird das Buch als Guideline für die Abwicklung eines
DWH-Projekts verwendbar.
Das Buch muss leider einen selektiven Weg durch das umfassende Thema
»Data Warehouse« wählen, da nahezu die gesamte EDV-Thematik berührt ist.
Dies wird dadurch erreicht, dass aus der Fülle aller methodischen Hilfsmittel
jeweils eine effiziente Methode zu jedem Problem dargestellt wird.
Für wen ist das Buch geschrieben?
Mit diesem Buch sollen Projektmanager und Teamleiter angesprochen werden,
deren erste Aufgabe die Projektierung, d.h. die Definition von Projektabschnit-
ten mit definierten Phasenergebnissen ist. Aus den angestrebten Phasenergeb-
nissen berechnet der Projektmanager die dafür erforderlichen Ressourcen mit
Aufwand, Dauer, Mittel und Qualifikation. Mit dem Buch wird daher auch das
Ziel »Bildung einer Projektgruppe zum Aufbau eines Data Warehouse« unter-
stützt.
Ein Data Warehouse ist wegen hoher Beschaffungskosten und Bindung nicht
unerheblicher Personalkapazität für Qualifizierung, Entwicklung und Betrieb
Chefsache und wird in der Regel nicht mehr alleine vom EDV-Abteilungsleiter
entschieden. Für IT-Manager und EDV-Leiter ist das Buch zur Zielbestimmung
von internen Data Warehouse Vorhaben und den daraus abzuleitenden Budgets
nützlich, da alle Schritte, die zum Aufbau eines Data Warehouse gegangen wer-
den müssen, chronologisch aufgezeichnet sind. Die damit aufgeführten Aufga-
ben sind Qualifikationselemente zum Beherrschen der einzelnen Projektstre-
cken und können als Bestandteil für Stellenbeschreibungen und
Stellenanzeigen genutzt werden. Die Bewertung der Arbeitsschritte mit Kosten
führen zu einem Budget.
Wertvoll ist dieses Buch auch für Data Warehouse Trainer, die den kompletten
Ablauf eines Data Warehouse Seminars im Umfang von fünf Seminartagen vor-
gezeichnet bekommen. Für diesen Zweck findet sich im Anhang ein Muster für
die Einteilung der Seminartage in Lernabschnitte, ein Seminarplan.
Des Weiteren gehört auch der angehende Data Warehouse Spezialist zu den
Ansprechpersonen des Buches. Ein Data Warehouse Manager kann sich nicht
auf Softwarewissen beschränken, sondern muss die gesamte Komplexität an
Hard- und Softwarekomponenten bis zu einer entscheidbaren Tiefe über-
schauen. Das Buch dient als Katalog aller Aktivitäten und Entscheidungen
eines Data Warehouse Spezialisten.
Bleibt am Ende dieser Erklärungen noch die Danksagung an alle diejenigen
betriebsinternen wie externen Teilnehmer, Aushilfsstudenten wie EDV-Leiter,
14 Vorwort

die meinen »Seminarexperimenten« mit Skepsis, aber auch mit Geduld und
Ausdauer gefolgt sind; die viel konstruktive Kritik eingebracht haben und am
Ende zu lebhaften und informations- und erkenntnisintensiven Seminarwo-
chen beigetragen haben. So wünsche ich dem Leser, dass er mit ähnlicher Leb-
haftigkeit, der nötigen Gelöstheit und einem Quäntchen Vergnügen an seine
Weiterbildung herangehen kann. Mit Freude erarbeitet, wird das Lernergebnis
besser ausfallen.
Besonderer Dank gilt meinen ehemaligen Arbeitskollegen der Integrata
Deutschland, Thomas Gueffroy, Manfred Richter und unserem Mitstreiter auf
dem Weg zu einer modernen Unternehmensinformatik, Dr. Frank Müller-Dahl,
ehemals DEG, Köln. Mit ihnen wurde so manches an nützlichen Projekthilfs-
mitteln für DWH entwickelt. Dank gilt auch Franz Bauer von der Integrata
Österreich und Robert Neundlinger, früher AI Informatics, jetzt MicroStrategy,
für die intensive Kritik. Bedanken möchte ich mich auch bei den im Text
genannten Firmen für die Überlassung von Informationsmaterial. Ich danke
Hannes Kriegbaum, früher Computer Associates Austria, jetzt Brokat, für den
tiefen Einblick in das Systemmanagement komplexer EDV-Systeme und mei-
nen jetzigen Projektkollegen der AI Informatics für die Verifizierung einiger
Verfahrensschritte. Hervorheben möchte ich Virginia Stanger für Korrektu-
rarbeiten. Dem Lektor Herrn Christian Schneider und der Projektleitung Frau
Anna Plenk danke ich für die gute Beratung und Nachsicht bezüglich ausge-
fallener Gestaltungswünsche. Ganz besonderer Dank gebührt Frau Dr. Ingrid
Mikosch, Integrata Training, ohne deren fürsorgliche Betreuung und unendli-
che Geduld dieses Buch bestimmt nicht entstanden wäre.
Für Verbesserungsvorschläge und positive wie negative Kritik
(mailto: Reinhard.Hoehn@wien.ilf.com) bedanke ich mich bereits im voraus.
Reinhard Höhn, Perchtoldsdorf, Wien, März 2000
Vorwort 15

Einleitung
Ein Buch soll dem Leser etwas vermitteln. Jedes Buch folgt dabei einem
bestimmten Stil, einer gewissen Methodik. Im Folgenden wird kurz dargestellt,
wie diese Vermittlung in diesem Buch arrangiert ist.

Welche Themenkomplexe umfasst dieses Buch?


Die einzelnen Themenkomplexe sind der logischen Folge der Abwicklung eines
EDV-Projekts entsprechend hintereinander gereiht.
Die Themenabgrenzung: Einführung und Überblick (Kapitel 1)
Bevor man sich näher mit einer Thematik auseinandersetzt, versucht man
einen Überblick zu gewinnen, einzuordnen in die eigenen Erfahrungen, worum
es sich handelt, ob die Auseinandersetzung persönlichen Nutzen bringt.
✔ Wie unterscheidet sich der Data Warehouse Ansatz von früheren Ansätzen
wie Management Information Systems, Decision Support Systems, Execu-
tive Information Systems, Knowledge Databases?
✔ Welche Umwelt- und Markttendenzen sind im Umfeld des Data Warehouse
zu erkennen und wie ist Data Warehouse zukünftig einzuordnen?
✔ Welche Ziele kann man mit dem Aufbau eines Data Warehouse verfolgen?
Die Architekturen von Data Warehouses (Kapitel 2-6)
Nachdem das Interessenfeld erkannt ist, kann man sich dem zu gestaltenden
System widmen. Im Kapitel Architekturen sind die Bestandteile des Data Ware-
house Gesamtsystems sowohl aus der Sicht der Hardware als auch aus der Sicht
der Software dargestellt.
✔ Welche Architekturen haben Informationssysteme? Woraus bestehen diese
Architekturen?
✔ Welche Organisation ist zum Betrieb eines DHW erforderlich?
✔ Welche betriebswirtschaftlichen Komponenten können in einem Data Ware-
house System implementiert sein? Wie werden betriebswirtschaftliche
Funktionen in einem Data Warehouse abgebildet?
✔ Welche Softwarekomponenten können in einem Data Warehouse imple-
mentiert sein?
✔ Aus welchen funktionalen Modulen und Werkzeugen besteht ein Data Ware-
house?
✔ Welche Hardwarekomponenten und Netzinfrastrukturen sind für den Ein-
satz eines Data Warehouse erforderlich?
16 Vorwort

✔ Welche Aufgaben sind für den Aufbau, den Betrieb und den Abbau eines
Data Warehouse abzuwickeln? Mit welchen Hilfsmittel können diese Aufga-
ben unterstützt werden?
✔ Welche Rollen sind für den Betrieb eines Data Warehouse erforderlich? Wel-
che Schulungen sind zum Aufbau der Rollen für ein Data Warehouse ratsam?
Das Vorgehensmodell zum Aufbau eines Data Warehouse (Kapitel 7)
Ein Vorhaben wie ein Data Warehouse aufzubauen ist sehr komplex und erfor-
dert eine Menge gut durchdachter Schritte. Die richtige Reihenfolge dieser
Schritte und die Hilfsmittel, die dieses Vorgehen vereinfachen, werden in einem
Vorgehensmodell festgehalten.
✔ Wie wird ein Software- und Hardwarevorhaben »Data Warehouse« abgewi-
ckelt, bzw. wie geht man am besten methodisch vor?
✔ Wozu dienen Softwaremodelle und wie ist ein Softwaremodell aufgebaut?
✔ Wie sieht speziell ein Data Warehouse Vorgehensmodell aus? Welche Ergeb-
nisse produzieren die Vorgehensphasen?
✔ Wie werden betriebswirtschaftliche Modelle entworfen? Welche Methoden
stehen bei der Modellierung eines Data Warehouse zur Verfügung?
Die Projektierung und der Betrieb eines Data Warehouse (Kapitel 8)
Mit der Projektierung wird das erarbeitete Wissen logisch in eine abwickelbare
Reihenfolge gebracht und mit Anforderungen an Ressourcen beurteilt. Es wird
Stellung bezogen, mit welchen Arbeitsmitteln, von welchem Personal, in wel-
cher Zeit die Aktivitäten für ein Data Warehouse umgesetzt werden können.
✔ Welche Phasen hat ein Data Warehouse Projekt? In welchen Schritten und
Meilensteinen wird ein Data Warehouse Projekt abgewickelt?
✔ Wie ist ein DWH-Projekt zu terminieren und zu budgetieren?
✔ Wie kann kann ein DWH-Projekt verfolgt werden?
Produktspektrum des Data Warehouse (Kapitel 9)
Wenn die Gestaltungsentscheidungen getroffen sind, hat man einen Wunsch-
zettel, dessen Umsetzung zur Realität ansteht. Mit diesen »Idealvorstellungen«
ist nun der Markt nach DWH-Produkten, die diese Anforderungen erfüllen, zu
untersuchen.
✔ Welche Tools unterstützen die Entwicklung eines Data Warehouse? Welche
Methoden sind als Tools realisiert? Wie wird eine dem Vorhaben angemes-
sene Toolauswahl evaluiert?
✔ Welche Produkte gibt es auf dem Markt und wie kann man diese beurteilen?
Wie sieht der Beschaffungsvorgang aus?
✔ Mit welchen Informationsquellen kann man die zukünftigen Bewegungen
im Data Warehouse Umfeld effizient verfolgen?
Vorwort 17

Der Betrieb und Abbau des Data Warehouse (Kapitel 10)


Wenn der Wunschzettel zur Realität geworden ist, steht Hardware und Soft-
ware für die Nutzung bereit. Die Nutzbarkeit wird von qualifiziertem Personal
aufrechterhalten. Die Anwendung fördert Unzulänglichkeiten zu Tage, die
beseitigt werden müssen. Im Laufe der Zeit wird der Fortschritt der neuen
Technologien so groß werden, dass mit den vorhandenen Produkten keine der
bei neuen Produkten entdeckten Leistungen durch Verbesserungen zu erzielen
ist. Das DWH wird teilweise oder ganz abgebaut.
✔ Welche Services unterstützen den Betrieb eines Data Warehouse?
✔ Welche Weiterentwicklung ist erforderlich?
✔ Wie wird ein DWH abgebaut?
Die folgende Grafik »Aufbau des Buches« soll noch einmal die Bearbeitungs-
stufen visualisieren:

Orientierung Produkttypus

Interessen

Betriebsfunktion

Architektur
Software

Hardware

Organisation

Vorgehen Modelle, Phasen

Methoden, Ergebnisse

Projektierung A u f g a b e n , Te r m i n e

Personal, Qualifikation

Budget

Produkte Markt

Evaluation

Betrieb Service, Administration

Erneuerung, Abbau

Abb. 0.1: Aufbau des Buches

Die Literaturliste
Kein Buch ist erschöpfend in allen Fragestellungen und deshalb ist je nach
Interesse vertiefende Literatur vonnöten. Einige Bücher unterliegen allerdings
einer solchen Zitierfreude, dass man sich fragen muss, ob ein Menschenleben
überhaupt ausreicht, um die genannten Quellen alle zu beschaffen. Sorgfältiges
Lesen allein reicht nicht aus. Hier wurde Mut gefasst, dem Trend nach immer
umfassenderen Literaturlisten nicht zu folgen, und statt dessen eine effiziente
Auswahl an kompetenten Titeln aus der unüberschaubaren Vielfalt der Veröf-
fentlichungen zu treffen. Weniger ist hier mehr. Diese kleine Literaturliste ist
dafür kommentiert und erlaubt eine schnelle Beurteilung, welches Buch für
den augenblicklichen Zweck am besten geeignet ist.
18 Vorwort

Wie ist das Buch aufgebaut?


Alle Kapitel sind ähnlich aufgebaut. Jedes Thema wird mit einer Begründung
eingeleitet, die eine Einordnung in den Gesamtzusammenhang erlaubt und
eine Zielsetzung klarstellt. Mit der Zielsetzung wird fixiert, was am Ende der
Bearbeitung eines Kapitels erreicht sein soll. Die Zielsetzung dient als Maßstab
des erreichten Wissenszuwachses. Ist die Zielsetzung erreicht, kann das
nächste Kapitel erarbeitet werden. Ist sie nicht erreicht, sollte eine Wiederho-
lung stattfinden (eventuell mit Erläuterungen durch einen Trainer). Die Ziel-
setzung ist in Form von Lernzielen am Anfang jedes Kapitels festgehalten.
Im Abschnitt Problemstellung und Motivation jedes Kapitels wird eine Pro-
blemlage und der aktuelle Erkenntnisstand zur Lösung der Problemlage darge-
stellt. Es wird außerdem eine Motivation gegeben, diese Problemlage aufzulö-
sen. Mit der Problemstellung wird das für eine DWH-Lösung benötigte
Grundlagenwissen dargestellt.
In der Regel gibt es keinen eindeutigen Lösungsweg, sondern eine Auswahl von
Lösungswegen. Bevor man sich für einen von ihnen entscheidet, müssen die
möglichen Lösungen bzw. die Freiheitsgrade, Lösungen zu erzielen, erkannt
werden. Über Tabellen und Übersichten werden Entscheidungsmöglichkeiten
zur Auswahl dargestellt und die zur Lösung vorhandenen Methoden erwähnt.
Der sogenannte Gestaltungsspielraum und die damit verbundenen Lösungs-
möglichkeiten müssen festgestellt werden.
Stehen der Gestaltungsspielraum und die möglichen Lösungen fest, geht das
Buch auf die Frage ein, wie die Lösungen zu erzielen sind. Der Weg zu diesem
Ziel wird in Form von Verfahrensschritten aufgezeigt. Diese folgen bestimmten
Regeln, die bei der Umsetzung eingehalten werden müssen. Als Unterstützung
der Verfahrensschritte dienen Hilfsmittel wie z.B. Methoden und Werkzeuge,
Erfahrungsdaten, Muster-Sheets. Das Buch wird damit zu einer Verfahrensbe-
schreibung.
Zur Erprobung des Gelernten werden die vorgestellten Mittel, Regeln und
Begriffe am Beispiel eines Projekts eingesetzt. Das Beispielprojekt ist ein
Industrieprojekt, ein Data Warehouse für ein Instandhaltungssystem für einen
Kraftwerkspark, mit dem Projektnamen InDaWa. Dieses Beispiel wird Kapitel
für Kapitel – so wie die Entwicklung eines realen Projekts verläuft – als »Fort-
setzungsbeispiel« erarbeitet.
Der Leser kann sich seiner zukünftigen eigenen Projektsituation durch Abän-
derung der im Buch geübten Beispielsituation annähern. Dadurch werden die
im Buch erarbeiteten Mittel und Werkzeuge in höchstem Maße wiederverwend-
bar.
Mittels Übungen wird abschließend die Erfahrung im Einsatz der Problemlö-
sungsmittel weiter gefestigt. Dies dient natürlich auch der Kontrolle bzw.
Selbstkontrolle des erreichten Wissensfortschritts. Die Lösungen ausgewählter
Vorwort 19

Übungen sind im Anhang gesammelt. Lösungen der verbleibenden Übungen


können im Text nachgeschlagen werden.
Der Aufbau der Kapitel folgt im Wesentlichen immer dem Schema der folgen-
den Abbildung »Aufbau der Kapitel«. Das heißt, jedes Kapitel wird durch eine
Einleitung, die einen Kapitelüberblick enthält und die Lernziele nennt,
beschrieben. Das Kapitel wird abhängig von den zu bewältigenden Themen in
Unterkapitel gegliedert, die mit einer Problemstellung und der Motivation,
diese zu lösen, starten. Aus der Problemstellung werden die Gestaltungsschritte
abgeleitet, zu denen im Einzelnen Lösungswege und Hilfsmittel zur Lösung
dargestellt werden. Am Ende jedes Kapitels sind Übungen zu den behandelten
Themen gesammelt.




      


   

 
! !
"#$


%&
    


'(
(')*%
+
+, $


 

-
(')*, $
.

Abb. 0.2: Aufbau der Kapitel

Über alle Etappen der Aufbereitung eines Themas werden, wenn nützlich, Defi-
nitionen eingesetzt. Definitionen dienen der Präzisierung der Begriffe und
durch die Verwendung präziser Begriffe werden Zuordnungen und Einordnung
in Bekanntes erleichtert und Missverständnisse reduziert. Mit Definitionen
werden Sachverhalte vergleichbar gemacht.
20 Vorwort

Zeichenerklärung
Gegenüber dem allgemeinen Text sollen bestimmte Aussagen zur besseren Ori-
entierung optisch hervorgehoben werden. Hierfür werden die folgenden Sym-
bole verwendet.
Das jeweils angestrebte Lernziel wird durch ein aufgeschlagenes Buch symboli-
siert:
 Lernziel
Die bei einer Problemlösung abzuwickelnden Verfahrensschritte sind mit dem
folgenden Symbol gekennzeichnet:
❖ Verfahrensschritt
Ein wichtiger Begriff wird mittels einer Erklärung, einer Definition, präzisiert,
die durch eine schattierte Box hervorgehoben ist.
Für einen Literaturhinweis wird als Symbol der Aktendeckel verwendet.
 Literaturhinweis
Auf einen Gestaltungshinweis wird durch eine Pfeilspitze aufmerksam
gemacht.
➢ Gestaltungshinweis
Eine wichtige Feststellung wird mit einem fetten Pfeil symbolisiert.
➡ Feststellung
Einige wenige Texte werden als Exkurs durch halbfetten Schriftsatz und Ein-
rahmung gekennzeichnet. Diese Informationen können auch zu einem späte-
ren Zeitpunkt gelesen werden.

Das durchgängige Übungsbeispiel


Das in dem Buch vorgestellte Verfahren wird von einem durchgängigen
Übungsbeispiel begleitet. Das Übungsbeispiel ist der Branche Energieversor-
gung zuzuordnen und behandelt ein Data Warehouse für die Optimierung der
Instandhaltung von Kraftwerken: Instandhaltungs Data Warehouse, »InDaWa«.
Die Stromverteilung, d.h. die Aufteilung des Abnehmermarktes, war bis vor
kurzem staatlich geregelt. Alle nationalen und einige internationale Betreiber
lieferten Strom in ein bundesweit verteiltes Netz und wurden einem definierten
Schlüssel entsprechend vergütet. Einen Wettbewerb von Betreibern um End-
verbraucher, wie im Handel oder in der Konsumgüterindustrie bekannt, gab es
nicht. Energieerzeuger produzierten in einem Quasimonopol. Für die Energie-
versorger war das Betriebsziel bisher also weniger, den Markt der Stromab-
nahme aktiv zu erweitern, sondern vielmehr, die Kosten zu verringern, bzw. die
Vorwort 21

Effizienz der Stromerzeugung zu erhöhen. Mit der Liberalisierung hat sich das
geändert und die Zukunft wird einen verstärkten Wettbewerb um Kunden auch
mit ausländischen Mitbewerbern bringen. Es ist bereits Direktbestellung von
Strom möglich. In Skandinavien sind sogar schon Strombörsen, die einem
Abnehmer erlauben, ganz gezielt einen Strom mit einer definierten Qualität
von einem von ihm bestimmbaren Hersteller zu einem bestimmten Tagespreis
zu beziehen, in die Praxis umgesetzt. Der Strompreis hängt maßgeblich von
der Effizienz der Produktion ab. Die Effizienz kann durch Verkürzung von Pro-
duktionsstillständen und Verringerung der Instandhaltungskosten erreicht
werden. Da die Instandhaltungskosten einen beträchtlichen Anteil an den Kos-
ten des Kraftwerksbetriebes betragen, sind diese von besonderem Interesse.
Eine technische Anlage wie ein Kraftwerk ist der Dynamik eines ständigen
Wandels ausgesetzt, die Instandhaltung ist deshalb ein permanenter Optimie-
rungsprozess. Zur Optimierung müssen Kenntnisse zum Verhalten der Anlagen
gesammelt werden. Zeiterscheinungen müssen anhand der gesammelten Werte
frühzeitig und voraussehend erkannt werden. Hier ist ein aussichtsreicher
Anwendungsbereich für Data Warehouse Funktionen.
Durch die Öffnung des Energiemarktes und die neuen Vertriebsformen, wie
Bestellung an der Tankstelle und über Internet, wird die Data Warehouse
Thematik auch für die Energieversorger für Marketingfragen interessant.
23

KAPITEL 1
1 Orientierung zum Thema Data Warehouse
Wenn man beschließt, sich mit einem neuen Thema zu befassen, dann mangelt
es noch an einer ausgereiften konkreten und vollständigen Vorstellung zu des-
sen Inhalten. Der erste Schritt soll daher das Ausleuchten des Themenumfelds
und das Feststellen der Beweggründe, sich mit dem Thema zu befassen, sein.
Anschließend wird eine Entscheidung getroffen, wie intensiv das Thema bear-
beitet werden soll. Dies mündet in die Definition einer Zielsetzung. Beschäftigt
man sich beruflich mit der Thematik, sind noch die Interessen des Arbeitgebers
von Bedeutung. Diese Fragen werden in drei Schritten abgearbeitet:
✔ Wie präsentiert sich das Thema Data Warehouse der Öffentlichkeit und um
welchen Gegenstand geht es bei diesem Thema grundsätzlich?
✔ Wie sind die Tendenzen aus dem Kontext der Data Warehouse Märkte und
wie werden diese das Thema zukünftig verändern?
✔ Welches sind die persönlichen Ziele und welches sind diejenigen Ziele, die
für den Auftraggeber erreicht werden sollen?
Das Kapitel ist entsprechend dieser Schritte gegliedert, wie in der folgenden
Abbildung »Kapitelübersicht« dargestellt ist.


 
 



 

  




  $
% 


   




 



 !"   #







   

  
  

     &   



 


  # 


Abbildung 1.1: Kapitelübersicht


24 Kapitel 1 • Orientierung zum Thema Data Warehouse

Lernziel
Das Ziel des ersten Abschnitts ist die Orientierung im Umfeld des Themas und
die Einordnung des Themas in den eigenen Erfahrungsraum. Dies dient der
Vorbereitung für die Feststellung und Einordnung der persönlichen Situation
und der Unternehmenssituation, der Definition der Ziele und der Vorbereitung
des Data Warehouse Projekts.
Die Lernziele des zweiten Abschnitts konzentrieren sich auf die Orientierung
im Markt, die Einschätzung von technischen Tendenzen und die Frage, welche
Informationsquellen dabei hilfreich sein können.
Die Lernziele dieses Abschnitts bestehen außerdem aus der Befähigung, die
eigenen Ziele zu erkennen und diese klar darstellen zu können. Sie bestehen des
weiteren in der Ermittlung der Unternehmensziele und der Erkenntnis, dass die
Ziele des Unternehmens verfolgt werden müssen und nach außen zu vertreten
sind. Als Lernziel soll auch das Bewusstsein geweckt werden, dass Zielkonflikte
projektgefährdend sind und vor Projektbeginn aufgelöst werden müssen.
Nicht zuletzt geht es um die Erkenntnis, dass nicht jedes beliebige Ziel erreich-
bar ist und die Erreichbarkeit wesentlich von der eigenen Startqualifikation wie
auch von der Disposition des Unternehmens abhängt.

Lernziele
 Kategorisierung des Themas Data Warehouse
 Abgrenzung
Typisierung
von Data Warehouse gegen andere ähnliche Produkte,

 Abgrenzung
Warehouse
des Marktsegmentes und der Konsumenten eines Data

 Kennen und Ausnutzen der Informationsquellen zu Data Warehouse


Entwicklungen
 Monitoring von Umwelt- und Markttendenzen
 Beurteilung der Auswirkung von Markt- und Umwelttendenzen auf das
Data Warehouse Vorhaben
 Einschätzung des eigenen Standpunkts (Qualifikation, Erfahrungen)
 Festlegung der persönlichen Ziele
 Definition der Qualifikationsziele
 Ziele des Unternehmens bezüglich eines Data Warehouse Projekts
 Feststellung der Zielverträglichkeit der persönlichen Ziele mit den
Unternehmenszielen
 Einschätzung des Unternehmensstatus für Data Warehousing
Kapitel 1 • Orientierung zum Thema Data Warehouse 25

1.1 Wie unterscheidet sich der Data Warehouse Ansatz von


früheren Ansätzen?
Einleitung
Der Data Warehouse Ansatz ist aus einer Historie ähnlicher Ansätze entstan-
den, deren Entwicklung teilweise in Produkten mündete. Wie so oft, wenn ein
Produkt nicht mehr das erwünschte Umsatzwachstum zeigt, wird es einge-
stampft oder bekommt eine neue Verpackung mit einem neuen, wohlklingen-
den Namen. Der Entscheidungsträger steht dann vor dem Problem, sich mit
neuen Begriffen auseinandersetzen zu müssen, und dafür bleibt ihm in der
Regel wenig Zeit. Um von einem neuen Produkt-Outfit nicht geblendet zu wer-
den, muss er nach messbaren Kriterien suchen, um eine Entscheidung abzulei-
ten. Er muss sich soweit in dem neuen Thema orientieren können, dass er ent-
scheiden kann, was für seine Belange relevant ist. Dazu ist es erforderlich, eine
Abgrenzung des Themenfeldes vorzunehmen und, wenn Beschaffungen anste-
hen, eine Produkttypenbestimmung zu finden.

1.1.1 Kategorien von Beschäftigungsgegenständen


Problemstellung und Motivation
Natürlich muss man sich, bevor man sich entschließt, aus einer unendlichen
Vielfalt an Themen eines auszuwählen, Fragen stellen wie: »Worum geht es hier
überhaupt?« – »Was verbirgt sich hinter diesen Begriffen?« – »Ist das nicht
alter Wein in neuen Schläuchen?«. Erst mit der Einordnung in den eigenen
Erfahrungsraum kann die Frage beantwortet werden, ob sich hinter einem
neuem Begriff eine altbekannte Thematik verbirgt oder ob es tatsächlich etwas
Neues ist. Neu kann die Thematik bezogen auf den eigenen Erfahrungsbereich
wie auch bezogen auf das Betätigungsfeld des Unternehmens sein. Die Ein-
schätzung des eigenen Standpunkts (Qualifikation, Erfahrungen) wie auch die
Einschätzung des Unternehmenstandpunkts sind die Basis für die Zielsetzung.
Die Lösungsaufgabe besteht zunächst in der Erkenntnis des Gestaltungsobjekts
»Data Warehouse«, seiner Materie, seines Gegenstandes, seiner Abgrenzung als
»philosophische« Kategorie. Dazu ist die Kenntnis von Kategorien erforderlich.
Die Kategorie präsentiert sich der Öffentlichkeit durch Werbeanzeigen von
Herstellern, Präsentationen auf Messen, Stellenbeschreibungen in den Zeitun-
gen und in den Auslagen der Buchhändler. Dies geschieht nicht in der
gewünschten Einheitlichkeit, dient aber doch einer gewissen Orientierung
(siehe Abbildung 1.2).
Die Abgrenzung innerhalb der gefundenen Kategorie gegen andere gleichartige
oder ähnliche Gestaltungsobjekte derselben Kategorie ist dann der zweite und
konkretere Schritt.
26 Kapitel 1 • Orientierung zum Thema Data Warehouse

Abbildung 1.2: Ausgewählte Abschnitte aus Zeitungsartikeln zum Data Warehouse

Mit welcher Kategorie von Gegenständen, Handlungen oder Ideen muss man
sich auseinandersetzen, um ein Data Warehouse aufzubauen? Handelt es sich
um etwas Reales, aus Einzelteilen Zusammenbaubares? In diesem Fall braucht
man im Prinzip nur die einzelnen Bausteine zu beschaffen und die Konzentra-
tion der Arbeit kann auf den Zusammenbau gelegt werden. Oder handelt es sich
eher um etwas Ideelles? Dann kann die Beschäftigung mit dem Thema besten-
Kapitel 1 • Orientierung zum Thema Data Warehouse 27

falls zu einer Denkhaltung und zu Handlungsorientierungen führen. Handelt


es sich um die Beschreibung von etwas Realem wie zum Beispiel einer Entwick-
lungsanleitung, so kann der Lerneffekt zu einer Bauanleitung führen. Ist das
reale Etwas eher dem Bereich Hardware zuzuordnen oder handelt es sich um
Software? Im ersten Fall liegt der Schwerpunkt auf Lieferantensuche und
Beschaffung. Im zweiten Fall ist zwar zunächst eine Hardware, also eine
Betriebsplattform erforderlich, die beschafft werden muss, doch ist diese »nur«
ein Mittel zum Zweck, die Software zu betreiben. Diese Software kann entweder
bereits beschafft werden oder muss erst produziert, also programmiert oder
vielmehr entwickelt werden.
Ist die Kategorie festgestellt, d.h. in diesem Falle mit Schlagworten abgegrenzt
und definiert, ist eine gezielte Suche nach Informationen möglich.

Gestaltungsraum und Lösungswege


Wie man sieht, ist also je nach »Denkkategorie« eine Erschließung des Themas
in Mittel und Methoden verschieden und das Ergebnis der Auseinandersetzung
etwas Funktionierendes, benutzbares Reales oder Ideelles. Leider ist die Präsen-
tation des Themas in den Medien nicht eindeutig, so dass man sich doch einmal
die Mühe machen sollte, wenigstens für die eigene Einstellung Klarheit zu
schaffen.
➢ Die zur Abgrenzung nützlichen öffentlichen Informationen müssen
entdeckt werden.
➢ Es sind Hilfsmittel zur Kategorisierung zu finden.
➢ Es ist eine Kategorisierung des Themas mittels der gefundenen Hilfsmittel
zu erarbeiten.

Problemlösung: Regeln und Hilfsmittel


Das Verfahren
Als bewährte Methode der Kategorisierung wird der Kategorien-Check vorge-
stellt. Der Kategorien-Check ist eine Sammlung von Kategorien von Beschäfti-
gungsgegenständen. Zu jeder Kategorie ist eine Erklärung ausgewiesen, die
erlauben soll, den Beschäftigungsgegenstand darauf zu prüfen, welche Erklä-
rung am besten auf ihn zutrifft. Die zur Erklärung gehörige Kategorie ist dann
die Kategorie des Beschäftigungsgegenstandes.

Definition: Kategorien-Check
Der Kategorien-Check ist eine nach Abstraktionsgrad geordnete Liste von
Kategorien von Beschäftigungsgegenständen oder Denkkategorien mit Kri-
terien zur Beurteilung der Zugehörigkeit eines Sachverhalts zu den einzel-
nen Kategorien.
28 Kapitel 1 • Orientierung zum Thema Data Warehouse

Die Methode der Kategorisierung besteht nun einfach in der Auswertung des
eigenen Informationsumfelds bezüglich der Anzeichen des Themas und der
Zuordnung anhand der Kriterien. Wie oben schon erwähnt, sind die Anzeichen
in den Medien, in Schaufenstern von Geschäften, in Büchern und auch in
Gesprächen und auf Informationsabenden zu finden. Die Anzeichen der Spalte
»Präsentation« der Kategorienskala sind mit den »Entdeckungen« zu verglei-
chen. Es kann selbstverständlich jedes Thema mehrere Erscheinungsbilder in
den Medien haben und damit auch mehreren Kategorien genügen. Das fol-
gende Verfahren ist zu empfehlen:

Verfahren: Kategorien-Check
❖ Definition des Problems: Zu welcher Kategorie gehört ein Data Ware-
house?
❖ Auswahl der Medien (Internet, Bibliotheken, Zeitschriften, Berater...)
❖ Sammlung der Aussagen in den Medien
❖ Prüfung der Aussagen mittels Kategorienkriterium in der Kategorien-
skala

Kategorienliste
Dem Kategorien-Check liegt eine Kategorienliste zugrunde. Diese ist eine
Tabelle zur Einordnung eines Themas mittels einer geordneten Liste von Kate-
gorien und einiger unvollständiger, aber hinreichend vieler Kriterien zu den
Kategorien. Die Liste ist in dem Sinn geordnet, dass die Kategorien von oben
nach unten gelesen realer, anfassbarer werden. Der Abstraktionsgrad der Kate-
gorien dieser Liste ist also von oben nach unten abnehmend. Die Liste ist eine
Kategorienskala (siehe Tabelle 1.1).
Eine weitere Vertiefung des Themas Kategorisierung ist nicht erforderlich. Es
geht hier nur um den Nutzen für die folgenden Erörterungen und zu diesem
Zweck genügt eine erste Annäherung. Die Kategorienliste ist auch nicht allge-
meingültig, sondern bereits auf den Erfahrungsbereich der EDV zugeschnitten,
mit dem wir uns ja hier beschäftigen wollen.

Beispiel zur Kategorisierung des Begriffes »Data Warehouse«


Ein Beispiel dafür, wie sich das Thema in der Öffentlichkeit präsentiert, sind
Zeitungsartikel. Die Frage, die mit den vorne gezeigten Zeitungsartikeln und
der Kategoriencheckliste beantwortet werden soll, lautet: Wie ist der Begriff
Data Warehouse einzuordnen, bzw. zu welcher Kategorie gehört der Begriff
Data Warehouse? Die Anwort ergibt sich aus dem Auffinden der folgenden
Begriffe. Jeder weist auf eine Kategoriezuordnung des Begriffes »Data Ware-
house« hin:
Kapitel 1 • Orientierung zum Thema Data Warehouse 29

✔ Kategorie Phänomen
Data Warehousing
✔ Kategorie Arbeitsprogramm
Data Warehouse Kooperationen, Standardisierungsgremium für Data
Warehouse, Data Warehouse Council
✔ Kategorie Methodik
Data Warehouse Vorgehensmodell, Methode ... des Data Warehousing
✔ Kategorie Prinzip
Data Warehousing Prinzip
✔ Kategorie Konzept
Data Warehouse Konzept, DWH-Richtlinien der ...
✔ Kategorie Organisationsform
Data Warehouse Spezialist, Data Warehouse Programmierer, Abteilung
für Data Warehouse Entwicklung
✔ Kategorie Technologie
Data Warehouse Herstellungsverfahren, ... zu kombinierende Rohpro-
dukte..., Data Warehouse Einbaukomponenten in ...
✔ Kategorie Software
Data Warehouse Programm
✔ Kategorie Softwaresystem
Data Warehouse Module, Data Mining Modul, Data Warehouse Kompo-
nente
✔ Kategorie Rechnersystem
Data Warehouse Rechner, Data Warehouse Server, Zugriffsperformance
✔ Kategorie Netzwerk
Data Warehouse Netzwerk, Data Warehouse Protokollschicht
✔ Kategorie EDV-Architektur
Data Warehouse Architektur, Data Warehouse Komponenten,
Kombination
✔ Kategorie EDV-Infrastruktur
Data Warehouse System
Man sieht, dass das Thema Data Warehouse viele Facetten hat. Es lässt sich
nicht einfach einer Kategorie zuordnen.

Einen umfassenden Einblick in die Anfänge des Themas »Management-Infor-


mationssysteme« findet man in:
 Grochla, Management-Informationssysteme
30 Kapitel 1 • Orientierung zum Thema Data Warehouse

Kategorie Kriterium Präsentation Stufe

Phänomen? • Erscheinungsbild Hochschulen Ideal


• gesellschaftliches Ereignis Zeitschriften, Seminare
• öffentliches Thema Managementdiskussion

Arbeitsprogramm? • Abfolge von Arbeitsschritten Forschungsprojekte


zum Erzielen eines Arbeits- Institutsankündigungen
ergebnisses Kooperationen

Methodik? • planmäßiges Vorgehen Empfehlungen


• Lehre der Verfahren Anleitungen
Vorgehensmodell

Prinzip? • Grundsatz Gestaltungsrahmen von


• Grundlage Unternehmen
• Orientierungslinie

Konzept? • Anforderungsskizze eines Werks Konzeptionen Real


oder Produkts Richtlinien
• Lösungsbeschreibung mit
Umsetzungsplan

Organisation? • Rollen, Stellen, Richtlinien Stellenbeschreibungen


• laufende Prozesse Ankündigungen

Technologie? • Gesamtheit der Prozesse einer Technische Anlage mit Faktor-


Fertigung kombination
• technisches Verfahren
• Rohstoffumwandlung zu Produkten

Software? • Computerprogramm Programmangebot Soft


• für Rechner lesbare Anweisungsfolge

Softwaresystem? • Computerprogramm aus Prospekt zu Programmmodulen


Komponenten

Rechner- • neue Prozessorstruktur Rechnertypus Hard


generation? • Verbund von Prozessoren
• Prozessortechnologie

Netzwerk? • Infrastruktur kommunizierender HW+SW-Komponenten


Einzelteile Infrastruktur, Protokolle,
• gegenseitig aufeinander Verkabelung
einwirkende Komponenten

EDV-Architektur? • Schichten Schichtenmodell


• planmäßig zusammengebaute Bauplan, Stücklisten
Komponenten

EDV-Infrastruktur? • Gesamtheit von Rechnern, Netzplan mit Komponentenlisten


Netzen, Softwarekomponenten

Tabelle 1.1: Kategorienskala Data Warehouse

1.1.2 Produkttypisierung
Problemstellung und Motivation
Steht die Kategorie fest, kann man sich mit den Arten der Gegenstände der
Kategorie auseinandersetzen. Da sich die Kategorie des Data Warehouse aus
den Zeitungsartikeln als etwas Handfestes wie ein System aus Hardware und
Software zu erkennen gegeben hat, als ein Etwas, das sogar auf Märkten gehan-
delt wird, bietet sich als weitere Eingrenzung die Feststellung des Produkt-
Kapitel 1 • Orientierung zum Thema Data Warehouse 31

typus an. Wäre als Kategorie »Phänomen« festgestellt worden, wäre das natür-
lich nicht möglich gewesen und die weitere Arbeit am Thema eher abstrakt und
visionär geblieben.
Die kategorielle Einordnung ist bewusstseinsprägend für die gesamte Projekt-
zeit. Die Vorstellung eines Projektmanagers, eines zukünftigen Data Warehouse
Spezialisten und auch des IT-Vorstandes, ein komplexes System aus Software,
Hardware und Organisationsstrukturen zu entwerfen, führt zu ernsthafteren
Diskussionen als zum Beispiel bei Projekten, deren Ziel eine Studie ist. Studien
sind eher geistige Spielwiesen zur Generierung von Ideen und zur Findung von
Maßnahmen und Vorhaben. Ein Data Warehouse zu bauen ist bereits eine von
einem Vorstand veranlasste Maßnahme.
Die Erkenntnis des Produkttypus ist auch insofern nützlich, als sie bereits eine
Fokussierung der Aktivitäten auf ein Marktsegment und damit ein besseres
Haushalten mit den einzusetzenden Ressourcen ermöglicht. Aber auch die
organisatorische Zuständigkeit ist damit erkannt. Es ist klar, ob sich die Abtei-
lung Anwendungsentwicklung, das Rechenzentrum oder die Fachabteilung um
die Thematik kümmern muss. Bei der Fülle der heute gebotenen Informations-
möglichkeiten und den in immer kürzeren Zeitspannen zu erreichenden Pro-
jektzielen ist es nötig, schnell zum Punkt zu kommen.
Eine kleine Auswahl bekannter verwandter Systemtypen, bzw. der sie bezeich-
nenden Begriffe aus dem historischen Umfeld der Data Warehouse Systeme,
mag belegen, dass es der Mühe wert ist, etwas genauer abzugrenzen, was unter
dem Begriff Data Warehouse System zu verstehen ist.
✔ Management-Informationssysteme
✔ Decision Supporting Systems
✔ Executive Information Systems
✔ Knowledge Databases
✔ Frühwarnsystem
✔ Electronic Shopping System
Alle genannten Systeme lassen schon vom Namen her auf die Verfügbarkeit von
Informationen schließen. Das heißt, dass die Informationen nicht durch diese
Systeme durchgeschleust und umgewandelt werden oder zum Beispiel bei einer
Maschine einen Vorgang auslösen, sondern dass sie zum Aufruf, zur Verwen-
dung vorgehalten werden. Für das Lagern von Informationen sind heute Daten-
haltungssysteme zuständig. Die Verwandtschaft bzw. Ähnlichkeit der aufge-
zählten Systeme besteht also mindestens darin, dass sie datenbankbasiert sind.
Zum Verständnis: Es gibt auch Systeme ohne Schwerpunkt auf einer Basis-
Datenbank wie Produktionssteuerungssysteme, Prozesssteuerungssysteme. Es
gibt Systeme ohne Basisdatenbank wie zum Beispiel Kommunikationssysteme
32 Kapitel 1 • Orientierung zum Thema Data Warehouse

(Virtual Private Network), Signalsysteme, und es gibt auch datenbankbasierte


Systeme ohne Managementinformationen wie CAD, Archivierung, Workflow.

Definition: Datenbankbasierte Informationssysteme


Die datenbankbasierten Informationssysteme sind Informationssysteme mit
einer dauerhaften, erweiterbaren, strukturierten Datenhaltung mit Funktio-
nalität für Eingabe, Auswahl und Abruf von Daten.

Diese Abgrenzung ist wissenschaftlich nicht ganz einwandfrei, soll aber


zunächst auch nur zur Einstimmung auf ein Marktsegment dienen. Ohne die
saubere Abgrenzung und deren Vermittlung durch einen Projektleiter bzw.
einen Data Warehouse Spezialisten in das Team hat jedes Teammitglied von
Anfang an eine andere Vorstellung von dem, was entstehen soll. Auch die für die
Projektinvestition verantwortlichen Führungskräfte haben Klarheit und
Schutz vor falschen Erwartungen verdient.
Diese Klarstellung, die Abgrenzung des Betätigungsfeldes, kann mittels der
Typisierung von Produkten, der Segmentierung von Märkten, der Einordnung
von Anwendern und Konsumenten vorgenommen werden.
Die Produkttypisierungen genügen nicht dem Anspruch der exakten Definiert-
heit. Sie entsprechen auch nicht dem Anspruch der Überschneidungsfreiheit.
Damit ist die Möglichkeit der eindeutigen Zuordnung eines realen Produkts zu
einem Produkttyp selten. Die Produkttypisierungen sind mehrdeutig. Das lässt
sich nicht vermeiden und liegt schon darin begründet, dass neue Produkttypen
als Verbesserung und Erweiterung von alten Produkttypen entstehen und
nahezu alle Eigenschaften der alten Produkttypen mitnehmen. Hier genügt es,
ein Produkt einem oder mehreren Produkttypen zuordnen zu können. Dies ist
nicht weiter schlimm, da ein Data Warehouse aus Bestandteilen verschiedener
Produkttypen komponiert werden kann.
Typisierung von Management-Unterstützungssystemen nach Kleinhans
Die Produkttypisierung bezüglich der DWH-Systeme ist in der Literatur nicht
einheitlich dargestellt. Aus der Vielzahl der Ansätze sei hier nur einer ausge-
wählt, die Typisierung von Management-Unterstützungssystemen mit den
Merkmalsgruppen von Kleinhans:
 Kleinhans, Seite 5 in Hichert, Management-Informationssysteme
Kleinhans gibt an, dass man die Unterscheidungsmerkmale von MUS, Data
Warehouse, MIS usw. in sechs Gruppen zusammenfassen kann:
✔ Problemorientierung: Unterstützung der Problemlösungsphase Planung,
Entscheidung, Durchsetzung, Kontrolle
✔ Anwenderorientierung: Einzelbenutzer, Gruppe, Abteilung, Bereich,
Unternehmen
Kapitel 1 • Orientierung zum Thema Data Warehouse 33

✔ Rechnertechnik: Parallelität, Softwaretechnologie, Userinterface


✔ Datentechnik: Erfassung, Speicherung, Umsetzung, Abfrage, Transport,
Sortierung, Verarbeitung
✔ Organisationstechnik: Isolation, Integration
✔ Betriebsfunktion: Produktion, Marketing, Logistik, Verwaltung, Vertrieb
Diesen interessanten Merkmalsgruppen werden hier noch weitere hinzugefügt,
die ebenfalls für die Abgrenzung von Informationssystemen nützlich und mit-
unter sogar ausschlaggebend sind:
✔ Organisationsebene: operativ, taktisch, strategisch
✔ Verdichtungsform: Basisdaten, Replikation, Aggregation
✔ Softwarefunktionalität: Logische Regeln, genetische Algorithmen, Fuzzy
Sets, Formelgenerator, Mustererkennung, Businessgrafik, Datennavigation,
Modellbildung, Hypertextlinking, Multimedia
Ein Beispiel für eine Aufteilung wichtiger marktgängiger Produkte ist in der
folgenden Grafik in Form einer Portfoliodarstellung abgebildet. Die Darstellung
ist der Studie
 Bullinger, Marktstudie Führungsinformationssysteme
entnommen.

Abbildung 1.3: Portfolio der Produkte der Führungsinformationssysteme


34 Kapitel 1 • Orientierung zum Thema Data Warehouse

Gestaltungsraum und Lösungswege


Die Gestaltungsaufgabe besteht hier aus der Abgrenzung des angestrebten Sys-
tems gegen die außerhalb des Interesses liegenden Systeme. Das Ergebnis der
Abgrenzung ist Benennung nach marktgängigem Sprachgebrauch. Das System
muss einen Namen bekommen, der eine Einordnung als Produkttyp ermög-
licht.
➢ Finden eines Hilfsmittels zur Einordnung des Produkttyps
➢ Einordnung des Produkttyps

Problemlösung: Regeln und Hilfsmittel


Das Verfahren
Bei einer Produkttypisierung nutzt man vorhandene Typisierungen und Markt-
segmentierungen aus der Betriebswirtschaftslehre oder aus den meist weniger
bekannten Dissertationen zum Thema. Hier ist schon ein wenig Spürsinn
gefragt, will man aus der Vielfalt der Veröffentlichungen diejenigen mit einer
nützlichen Typisierung herausfinden. Am schnellsten hilft hier die Befragung
eines Lehrstuhls weiter, der sich ja zwangsläufig mit der Systematisierung sei-
nes Arbeitsgebiets auseinandersetzen muss.

Verfahren: Typisierung Informationssysteme


❖ Definition des Problems: Zu welchem Produkttyp gehören Data Ware-
house Systeme?
❖ Sammlung der Aussagen in den Medien
❖ Prüfung der Aussagen mittels Kommentar des Produkttypen-Chart
datenbankorientierter Informationssysteme

Produkttypen-Chart datenbankbasierter Informationssysteme


Für die Einordnung des gewünschten Systems kann man sich auf die sogenann-
ten Informationssysteme konzentrieren. Dies heißt, dass Prozesssteuerung,
Signalverarbeitung und Analogsysteme nicht in Data Warehouse Systemen ent-
halten sind. Zur Auffindung der erforderlichen Komponenten für ein Data Ware-
house genügt die grobe Typisierung. Mittels der groben Typisierung wird ein
Assoziationsfeld für Recherchen geschaffen. Als effizientes Hilfsmittel sei hier ein
kommentiertes Produkttypen-Chart datenbankbasierter Informationssysteme
vorgestellt (siehe Tabelle 1.2).
Kapitel 1 • Orientierung zum Thema Data Warehouse 35

Short Cut Produkttyp Erklärung

MIS Management Information System für alle Managementebenen, Gesamtheit aller


FIS Führungsinformationssystem Informationen verdichtet wie auch unverdichtet

DSS Decision Support System Operation Research, Modell- und Methoden-


EUS Entscheidungsunterstützungssystem banken, What-if-Abfragen

EWS Early Warning System Parameterabfragen, aktive Warnung, Trend-


FWS Frühwarnsystem analyse, Prognosen, Schwellenwertdefinition

EIS Executive Information System Planung, Ad-hoc-Abfrage, Hypertext-Linking,


CIS Chefinformationssystem flexible Reportgenerierung, Unternehmens-
gestaltung

KBS Knowlege Based System Fachwissendarstellung mit Faktenwissen,


WBS Wissenbasiertes System Regelwissen

XPS Expert System Expertenwissen mit Aussagen aus logischen


EPS Expertensystem Regeln, Ableitung neuer Aussagen

ODB Online Databases Auskunftsystem zu öffentlichen gebührenpflich-


ODB Online-Datenbank tigen Datenbanken von Instituten und Behörden

DBMS Database Management System System zur Definition von Datenstrukturen und
DBMS Datenbankmanagementsystem Verwaltung von Daten und deren Zugriffen

OLAPS Online Analytical Processing System Mehrdimensionale Datenwürfel, Hierarchische


Filter- und Aggregationsfunktionen über Dimen-
sionen

OLTPS Online Transaction Processing System flache satzorientierte Datenablage, Trans-


aktionen als Zugriff

ROLAPS Relational Online Analytical OLAP-System mit multidimensionalem Zugriff,


Processing System aber relationaler Speicherung

MOLAPS Multidimensional Online Analytical OLAP-System mit multidimensionalem Zugriff,


Processing System aber multidimensionaler Speicherung

EUT Office System mit Enduser Tools Textverarbeitung, Kalkulationsblätter, Busi-


nessgrafik
Makrosprache

IRS Information Retrieval System Auffindung von archivierten Informationen mit-


tels Schlagworten

ARS Archiving System langfristige Speicherung und Suche von Doku-


Archivierungssystem menten, nicht auf elektronische Informationen
begrenzt

OIS Office Information System Unterstützung von Bürotätigkeiten wie Kommu-


BIS Büroinformationssystem nikation, Ablage, Versand, Terminabstimmung
und -planung

WFMS Workflow Management System System zur aktiven Steuerung der Aktivitäten
arbeitsteiliger Prozesse

Data Data Warehouse gesamter Datenhaushalt eines Unternehmens,


Warehouse Datenmustererkennung und Standardreporting

Data Mart Data Mart Ein auf einen Nutzerkreis, wie zum Beispiel
eine Abteilung, eingeschränktes Data Ware-
house

Tabelle 1.2: Produkttypen-Chart datenbankorientierter Informationssysteme


36 Kapitel 1 • Orientierung zum Thema Data Warehouse

Die Einordnung findet mit Hilfe einer Produkttypen-Charakterisierung statt.


Die Elemente der Charakterisierung sind dabei:
✔ leichte Erlernbarkeit für einen Anwender ohne Programmierkenntnisse
✔ anwendbar für Führungsebene, mittleres Management oder auf operativer
Ebene
✔ Verdichtung von Originaldaten und Ableitung von Daten
✔ fest vorprogrammiert oder flexible Datenbanken mit anpassbaren Abfragen
✔ besondere Funktionen zur Datenauswertung und Datenerzeugung wie
Databases, Regellogik, Aggregation, Navigation, Fuzzy Set, genetische Algo-
rithmen, Multiwürfel, neuronale Netze
Für den Leser ist der Beschäftigungsgegenstand das Data Warehouse. Es ist
aber mit dem Orientierungsschritt klar geworden, dass neben dem Aufbau eines
Data Warehouse auch ein Decision Supporting System und ein Executive Infor-
mation System in Frage kommen könnten.
In diesem Zusammenhang ist noch interessant:
 Krallmann, Rechnergestützte Werkzeuge

1.1.3 Ausblick: Die Organisationsform eines Data Warehouse Vorhabens


Der zu organisierende Gegenstand »Data Warehouse Vorhaben«
Die Erkenntnis, ein Data Warehouse gestalten zu wollen, lässt schon eine erste
grobe Struktur für die Organisation des Gesamtvorhabens »Data Warehouse
Aufbau« ableiten. Da ein Data Warehouse wenigstens ein Softwaresystem ist, ist
auch die Betrachtung der Hardware samt Betriebssystem und des in der Regel
lokalen Netzes zum Betrieb dieses Softwaresystems erforderlich. Damit sind
bereits zwei Entscheidungsbereiche aus einem Gestaltungsraum definiert:
➡ Ein Data Warehouse hat eine Infrastruktur aus Rechnern, Betriebssyste-
men, lokalen Netzen und eventuell regionalen Netzen.
➡ Ein Data Warehouse umfasst ein Softwaresystem aus Anwendungen, Bedie-
nungsoberflächen, Datenbanken.
Mit der Kenntnis dieser beiden Gestaltungsentscheidungen kann das allgemein
bekannte Wissen um Softwareprojekte und das Wissen um die Struktur von
Rechnernetzen beansprucht werden. Das bedeutet jedoch nicht, dass diese
Bereiche komplett ausgearbeitet werden müssen, sondern dass das dort vorhan-
dene Wissen aufgespürt, auf seine Verwendung für die Data Warehouse Konzep-
tion beurteilt, selektiert und zur Gestaltung des Gesamtsystems angewendet
werden kann.
Kapitel 1 • Orientierung zum Thema Data Warehouse 37

Für die Durchführung einmaliger Vorhaben wird in der Regel keine dauerhafte
Organisation, sondern eine temporäre Organisation eingerichtet. Es ist also ein
relativ umfangreiches Projekt zu definieren.
➡ Der Aufbau eines DWH ist ein solcher einmaliger und länger dauernder Vor-
gang
– über mehrere Monate,
– mit Beteiligung mehrerer Personen unterschiedlicher Qualifikation aus
unterschiedlichen Abteilungen,
– die vorübergehend und wiederholt und zu unterschiedlichen Zeitpunkten
mit wechselnder Kapazität zusammenzuführen sind,
– ohne die Linienzuordnung aufzuheben,
– um einmalig verwendbare Ergebnisse zu produzieren.
Es muss daher eine neben der bestehenden Organisation funktionsfähige, tem-
poräre Teamorganisation mit eigenen Weisungswegen und Berichtswegen ein-
gerichtet werden. Eine bewährte Möglichkeit ist die Projektorganisation. Da die
Projektmitglieder zweifach unterstellt sind, nämlich dem Projektleiter und
dem Abteilungsleiter, und dies übersichtlich in einer Matrix dargestellt werden
kann, spricht man auch von einer Matrixorganisation.

Definition: Projekt und Matrixorganisation


Ein Projekt ist eine einmalige, zeitlich begrenzte (temporäre) Organisations-
form mit Strukturen, Abläufen, Berichten, Weisungen, mit vorübergehender
Ressourcenabstellung und einem individuellen Ergebnis. Bleiben die Wei-
sungsrechte der Linienorganisation im Laufe eines Projekts erhalten, han-
delt es sich um eine Matrixorganisation.

Eine Projektorganisation ist die Basis für die Abwicklung von Projektaufgaben.
Für die Gestaltung der Projektorganisation muss daher Klarheit über die Auf-
gabenpakete, die Projektstruktur, gewonnen werden. Die Aufgaben der Projekt-
struktur werden zu zeitlich zusammengehörigen und gemeinsam abzuwickeln-
den Paketen gebündelt. Die Zeitabschnitte eines Aufgabenpakets werden
Phasen genannt.

Definition: Projektphase
Ein Projekt wird zur Überprüfung der Erreichbarkeit der gesetzten Ziele und
einer Bestimmung der nächsten Ziele in Arbeitsschritte mit einem definier-
ten Ergebnis zerlegt. Diese Arbeitsschritte heißen Projektphasen.
38 Kapitel 1 • Orientierung zum Thema Data Warehouse

Der Projektaufbau nach Phasen, die Phasenaufteilung, ist nicht eindeutig. So


kann man zum Beispiel Implementierung noch in der Phase Realisation abwi-
ckeln, da häufig die Fehler erst nach der Implementierung in die Betriebsum-
gebung sichtbar werden. Die Realisierungsergebnisse werden wiederum in die
Realisation zurückgegeben, korrigiert, getestet und reimplementiert, bis ein
stabiler, den Anforderungen entsprechender Betrieb möglich ist.
Exkurs zur Phasenstrukturierung von Projekten
Im folgenden Exkurs wird eine Phasenstrukturierung von Projekten darge-
stellt.

Exkurs: Projektaufbau
Umfangreiche Projekte werden erfahrungsgemäß in überschaubare Schritte
eingeteilt und abgewickelt. Diese Schritte werden Projektphasen genannt. Es
gibt keine Faustregel, ab welcher Projektgröße (oder aufgrund welches ande-
ren Kriteriums) die Phasenstruktur erforderlich wäre. Daher gibt es Pro-
jekte, die Phasen noch weiter detaillieren, und andere Projekte, die kom-
plette Phasen überspringen. Die Abwicklung der Projektphasen besteht aus
der Erzeugung definierter Phasenergebnisse. Die Struktur des Phasenergeb-
nisses, also gewissermaßen seine Definition oder auch seine Spezifikation,
heißt Ergebnistyp.
Dem Projekt geht die Orientierung bezüglich der Aufgabenstellung, die
Suche nach Interessenten an den zukünftigen Ergebnissen und die Suche
nach Geldgebern, die Akquisition, die strategische Vorbereitung, die Defini-
tion unternehmerischer Ziele, Budget und Zeitrahmen, die Bestimmung
eines Vorstandssponsors bzw. die Zuordnung des Themas zu einem Vor-
standsressort und die Ernennung eines Projektverantwortlichen voraus.
Diese Vorphase heißt Projektinitiation. Ist das Projekt initiiert, bilden sich
die Projektphasen analog dem Ablauf einer Problemlösung.
Zuerst steht die Einordnung der Sache, Definition der Projektziele und eine
Grobbudgetierung und Rahmenterminierung, die sogenannte Projektierung
an.
Nach der Projektierung sind die fachlichen Inhalte und Ergebnisse zu akqui-
rieren und in einer verabredeten Form zu fixieren. Diese Phase besteht aus
der notwendigen Ist-Erhebung und Analyse bzw. der Interpretation der der-
zeitigen Situation. Ist man mit der Situation zufrieden oder stellt sich her-
aus, dass das Projekt zu keiner besseren Lösung führt, oder ist sogar die
Machbarkeit in Frage gestellt, wird das Projekt beendet. Diese Phase heißt
gewöhnlich Statusanalyse oder Ist-Erhebung. Werden sogar noch die Anfor-
derungen der Interessenten, wie bei einer Software zum Beispiel die Anwen-
derwünsche, miterhoben, spricht man auch von einer Anforderungsanalyse.
Kapitel 1 • Orientierung zum Thema Data Warehouse 39

Ist man mit dem augenblicklichen Zustand nicht zufrieden und ist die Mach-
barkeit ausreichend begründet, werden die Lösungsmöglichkeiten ermittelt.
Die Lösungsmöglichkeiten werden gegeneinander abgewogen, Vor- und
Nachteile festgestellt und die Entscheidung für eine Lösungsvariante gefällt.
Diese Variante wird gemäß den Anforderungen in einer ersten Annäherung
formuliert. Das Ergebnis ist in einer noch für Entscheider und Anwender
verständlichen Sprache und Symbolik gehalten, um deren Einverständnis für
die nächste Phase einholen zu können. Das Ergebnis ist eine fachliche Wis-
sensdarstellung, nicht zu verwechseln mit den fachlichen Anforderungen.
Diese Phase wird Konzeption oder Fachkonzeption, manchmal unglückli-
cherweise auch Grobkonzeption genannt.
Die Konzeption ist zwar noch in einer für Entscheider und Anwender ver-
ständlichen Sprache gehalten, aber für die Umsetzung ist diese Sprachart zu
ungenau. Der nächste Schritt besteht daher in der Präzisierung, z.B. in der
Formulierung klarer Handlungsanweisungen für Programmierer, Hersteller
oder Beschaffer. Je nachdem, ob beschafft wird, programmiert wird oder nur
Anpassungsarbeiten an einem gekauften Produkt zu leisten sind, ist die Ver-
wendung einer speziellen »Terminologie« erforderlich, die auch aus For-
meln, Strukturgrafiken oder Tabellen bestehen kann. Diese Phase wird Spe-
zifikation, Design oder Entwurf, manchmal unglücklicherweise auch
Feinkonzeption genannt.
Die Umsetzung der Spezifikation umfasst das Codieren in einer Program-
miersprache, das Testen in einer Laborumgebung, die Installation und das
Testen in der Betriebsumgebung. Diese Phase wird Realisation genannt.
Manchmal wird die Implementierung getrennt von der Realisation als eigene
Phase genannt, wenn zum Beispiel ein Probebetrieb durchgeführt wird.
Sind alle Tests abgeschlossen, die Entscheider zufrieden mit der Überein-
stimmung zwischen Konzeption und Lösung, die Anwender über Ergonomie
und Nutzen im Bilde, wird das System für den Betrieb freigegeben. Der
Betrieb umfasst wie bei einer gewöhnlichen Maschine Wartungsarbeiten,
Ausbesserung kleiner Fehler, Erneuerung und Austausch, aber auch die
Anwenderbetreuung und die Kontaktpflege zu den Herstellern. Diese Phase
wird Betrieb genannt.
Besteht keine ausreichende Nutzungsnachfrage mehr, wird der Betrieb ein-
gestellt und die Systeme werden abgebaut. Der Abbau umfasst die Migration
der Daten auf andere Systeme, die Destallation der Programme, das Abmon-
tieren der Hardware und den Weiterverkauf oder die Verschrottung. Diese
Phase wird Abbau genannt.

Die Projektphasen sind in Kapitel 8, Abbildung 8.2 dargestellt.


Die Ergebnisse der Projektphasen eines Data Warehouse Projekts werden in
einem sogenannten Vorgehensmodell definiert. Es ist bekannt, dass es ver-
schiedene Vorgehensmodelle gibt, die alle vom zu gestaltenden Gegenstand
40 Kapitel 1 • Orientierung zum Thema Data Warehouse

abhängen. Ein wichtiger Schritt im DWH-Projekt ist daher die Definition des
zu gestaltenden Gegenstandes, seiner Bestandteile, seiner Architektur. Ist die
Architektur klar, werden zu ihrer Herstellung Methoden überlegt.
Mit dem Vorgehensmodell wird sich später ein ganzes Kapitel (7) auseinander-
setzen; die Ergebnisse sollen hier nicht vorweggenommen werden, da sie ein
tieferes Verständnis darüber voraussetzen, woraus ein Data Warehouse besteht.

1.1.4 Fortsetzungsbeispiel InDaWa


Einleitung
Das in diesem Buch systematisch vertiefte Beispiel, Data Warehouse für die Ver-
besserung der Instandhaltungsmaßnahmen, genannt »Instandhaltungs Data
Warehouse«, kurz »InDaWa«, steht am Start.
Zu diesem Zeitpunkt besteht der Beitrag zu einem Projekt alleine in der
Abgrenzung des Beschäftigungsgegenstandes. Also zunächst in der Orientie-
rung: »Ist das Produkt des Vorhabens eine Erkenntnis, ein Papier mit Empfeh-
lungen oder Handlungsanleitungen, eine Organisation, eine Software oder eine
Hardware?« Und dann genauer in der Feststellung, »Ist das, was ich mit dem
Vorhaben aufbauen möchte, ein Management-Informationssystem, ein Füh-
rungsinformationssystem, ein Expertensystem, ein Data Warehouse, nur ein
Data Mart oder ist es von allem etwas?«.

Beispiel
Die Kategorie des Vorhabens ist eine erste Annäherung an die noch zu treffen-
den Gestaltungsentscheidungen.

Beispiel: Produkttyp
Für das Instandhaltungsprojekt steht fest, dass für die gewünschten Erkennt-
nisse die gesamte Datenbasis, die zu einer kompletten Instandhaltungslösung
gebraucht wird, erforderlich ist. Auf dieser Datenbasis werden die Planung,
Kalkulation, Genehmigung, Durchführung, Verfolgung und Auswertung wie
auch die Ermittlung neuer Instandhaltungsstrategien, z.B. durch intelligente
Schadensauswertungen und Ausfallprognosen, operieren.
Spezielle Fragen, die mit dem System beantwortet werden sollen, sind:
✔ Welche Komponenten werden am häufigsten defekt?
✔ In welchen Anlagenteilen entstehen die meisten Reparaturen?
✔ Welche Komponenten werden unter welchen Umständen schneller
defekt?
✔ Kann für den ganzen Kraftwerkspark eine verteilte Ersatzteilhaltung
realisiert werden, ohne die Reparaturzeit zu verlängern?
✔ Welche Umwelteinflüsse spielen für den Bauteileausfall eine Rolle?
Kapitel 1 • Orientierung zum Thema Data Warehouse 41

Damit sind alle Merkmale eines Data Warehouse vorhanden:


✔ umfangreiche Datenbasis über mehrere Betriebsfunktionen: Kosten,
Personal, Material und Logistik, Produktion und technische Anlagen
✔ operative Daten, aggregierte Daten
✔ Plan-, Ist-, Abweichungs-, Prognosedaten
✔ Planungsvergleiche, Strategiedefinition
✔ Standardreporting, regelbasierte (Schadens-) Auswertung
Im weiteren stufenweisen Aufbau des Projekts ist die Erkenntnis, ein Data
Warehouse bauen zu wollen, gleich der Erkenntnis, welcher Systemtyp im
zukünftigen Projekt konstruiert, entwickelt oder beschafft werden soll. Aus
der oben aufgeführten Auswahl kommen mit der Entscheidung, ein Data
Warehouse zu bauen, nur der umfassende Ansatz »Data Warehouse » oder
der eingeschränkte Ansatz »Data Mart« in Betracht. Dies schließt nicht aus,
dass auch Decision Supporting Komponenten oder Experten Module inte-
griert sind. Aber das gesuchte System ist eben kein reines Expertensystem
und kein reines Decision Supporting System. Es wird die Entscheidung Data
Warehouse gegenüber Data Mart getroffen.
Mit dem Entschluss, ein Data Warehouse gestalten zu wollen, konnte die
Einordnung des Produkttyps als umfassendes, datenbankbasiertes Informati-
onssystem getroffen werden. Damit sind zwei Gestaltungsbereiche definiert:
✔ Infrastruktur aus Rechnern, Betriebssystemen, lokalen Netzen und even-
tuell regionalen Netzen
✔ Softwaresystem aus Anwendungen, Bedienungsoberflächen, Datenbanken
Mit der Kenntnis dieser beiden Gestaltungsbereiche konnte die Entschei-
dung für die Organisationsform, eine relativ umfangreiche Projektorganisa-
tion, wie sie für große IT-Vorhaben bekannt ist, getroffen werden.

Für das betrachtete Beispielprojekt ist noch keine Projektorganisation vorhan-


den. Die Rollen müssen noch erarbeitet werden, die Möglichkeiten sind aus
ähnlichen Projekten anderer Unternehmen nur namentlich bekannt. Die Vor-
gehensweise für ein solches Projekt ist unklar. Es ist bekannt, dass größere Pro-
jekte im Rahmen eines Vorgehensmodells abgewickelt werden und ein solches
für das Vorhaben definiert werden muss.

Gestaltungsentscheidungen
Die bisher getroffenen Entscheidungen sind im Sinne eines Projektfortschritts
in der folgenden Tabelle »Entscheidungschart InDaWa Abgrenzung« festgehal-
ten. Diese Projektfortschrittsskala oder auch das Entscheidungschart, hat zu
diesem Zeitpunkt drei Ergebnisse aufzuweisen: die Kategorieeinordnung, den
Produkttyp und den Organisationstyp.
42 Kapitel 1 • Orientierung zum Thema Data Warehouse

Gestaltungsaspekt Entscheidung Begründung

ORIENTIERUNG

Abgrenzung

Kategorie Komplexe EDV-Architektur Software, Hardware, Konzepte, Rollen

Produkttyp Data Warehouse Mehrere Datenhaltungssysteme

Organisationstyp Projekt einmaliges, zeitlich begrenztes Vorhaben


mit wechselndem Ressourceneinsatz

Markttendenzen
...
Zielsetzung
...
ARCHITEKTUR
...
VORGEHENSMODELL
...
PROJEKTIERUNG
...
BETRIEB
...

Tabelle 1.3: Entscheidungschart InDaWa Abgrenzung

Es ist einfach abzuleiten, dass die Qualität eines Data Warehouse und der Fort-
schritt des Aufbaus von der Zulieferung von Produkten abhängig ist und damit
den Schwankungen der Märkte unterworfen ist. Der »Skalenstrich« Marktten-
denzen deutet an, dass hier ein Ergebnis zu erarbeiten ist. Auch die Erkenntnis,
wie weitergearbeitet werden muss, ist ein Projektfortschritt, der sich als neuer
Eintrag in der Projektfortschrittsskala zeigt.
Ebenso ist klar, dass ein Data Warehouse in eine bestehende Organisation ein-
gepasst werden muss und dass der Erfolg der Umsetzung von den Vorstellungen
und Widerständen der betroffenen Mitarbeiter aller Führungsebenen abhängt.
Ein Data Warehouse kann nur dann erfolgreich sein, wenn die Unternehmens-
ziele unterstützt werden und die persönlichen Ziele der Beteiligten berücksich-
tigt werden. Für die Projektfortschrittsskala bedeutet dies einen Eintrag »Ziel-
setzung«.
Es wurde festgestellt, dass ein Data Warehouse aufzubauen ein komplexes Vorha-
ben ist, das der Steuerung durch ein Vorgehensmodell mit definierten Zwischen-
ergebnissen und methodischen Hilfen bedarf. Das Vorgehensmodell ist von den
zu produzierenden Komponenten des Data Warehouse Systems abhängig.
Es wurde auch festgestellt, dass die Organisationsform »Projekt« erforderlich
ist. Ein Projekt muss mit Zielen, Terminen, Leistungen, Teilnehmern, Arbeits-
mitteln definiert werden. Für die Fortschrittsskala ergibt dies damit einen Ein-
trag »Projektierung«.
Damit sind die nächsten Projektetappen in Sicht.
Kapitel 1 • Orientierung zum Thema Data Warehouse 43

1.2 Wie sind Markttendenzen im Umfeld des Data Warehouse zu


erkennen?
Jedes Unternehmen setzt, auch wenn es noch so klein ist, im eigenen Leis-
tungsprozess Fremdprodukte ein. Damit sind die Tendenzen der Märkte dieser
Produkte und die unternehmerischen Aktivitäten ihrer Hersteller interessant,
weil sie Einblick in die Zukunft dieser Produkte erlauben. Die Verfolgung dieser
Tendenzen mittels der Informationsmedien hilft bei der Ausrichtung der Ent-
scheidungen zum Aufbau und zum Betrieb des Data Warehouse. Nicht nur Ten-
denzen in den Produktmärkten sind interessant, auch Data Warehouse Vorha-
ben der Konkurrenten können höchst aufschlussreich sein und die eigenen
Entscheidungen beflügeln. Die meisten Unternehmen veröffentlichen diese
Vorhaben als »Erfolgsstories« in den gleichen Medien.
Zeit ist ein knappes Gut. Man kann nicht jeder Tendenz bedingungslos unter
großem Zeitaufwand folgen, sondern muss sich entscheiden, welche Tendenz
schärfer beobachtet und welche Tendenz sofort mit Maßnahmen flankiert wer-
den soll. Das Ziel dieses Kapitels besteht in der Hervorhebung der Bedeutung
der kontinuierlichen, aber geplanten Verfolgung der Bewegungen der Märkte
im Umfeld des Data Warehouse.
Dazu ist eine Bestimmung der Informationsquellen und die Auswertung der
dort gefundenen Informationen erforderlich.

1.2.1 Informationsfindung
Problemstellung und Motivation
Ob man will oder nicht, man wird täglich pausenlos mit Informationen kon-
frontiert. Der Radiowecker mit neuesten Nachrichten, die Plakate, die Schlag-
zeilen der Tageszeitung, Verkehrssignale, die Gespräche mit Arbeitskollegen,
die Mail-Listen – man kann sich der Informationsflut kaum entziehen. Und es
bereitet Mühe, aus dieser großen Menge an Informationen diejenigen herausfil-
tern, die für die Arbeit benötigt werden. Man muss seinen Informationshaus-
halt organisieren, um effizienter zu den Informationen zu kommen, die wirk-
lich relevant sind.
➡ Informationen müssen selektiert werden.
Informationen können von einem Informationsmarkt bezogen werden, z.B.
durch ein Zeitungsabonnement oder über einen Fernsehanschluss. Diese Infor-
mationen haben einen Preis, sie müssen gekauft werden. Mit Informationen
wird gehandelt. Informationen sind eine begehrte Ware, wie die Abbildung
»Nutzung des Internets« unterstreichen soll (siehe Abbildung 1.4).
➡ Informationen sind eine Ware.
44 Kapitel 1 • Orientierung zum Thema Data Warehouse

Abbildung 1.4: Nutzung des Internets

Informationen haben eine Qualität wie reale Produkte. Sie können wider-
sprüchlich oder sogar völlig falsch sein. Sie können unsinnig und nichtssagend
sein, wie zum Beispiel die Aussage aus einem Buch zur Trainingslehre: »Taktik
sind taktische Situationen«. Sie können überfrachtet sein, wie in Pleonasmen
wie »weißer Schimmel«. Informationen können gehaltlos sein, wie zum Bei-
spiel die Aneinanderreihungen der allseits bekannten »Phrasendreschma-
schine«. Informationen können permanent und aufdringlich wiederholt wer-
den, wie zum Beispiel in Werbespots.
➡ Informationen haben einen Inhalt mit einem Wahrheitsgehalt und einem
Neuigkeitsgrad.
Kapitel 1 • Orientierung zum Thema Data Warehouse 45

Bis zum Mittelalter waren die Möglichkeiten der Weitergabe von Informationen
noch weitgehend begrenzt: Neben der mündlichen Mitteilung gab es z.B. akus-
tische Signale, Symbole oder handschriftliche Aufzeichnungen. Als dann im
Jahr 1450 der Buchdruck erfunden wurde, war erstmals die Massenauflage von
Informationen und damit ein höherer Verbreitungsgrad möglich, der noch
dazu wesentlich schneller erreicht wurde. Wie die folgende Grafik »Historische
Entwicklung der Medien« noch einmal unterstreicht, haben sich seitdem die
Träger der Information, die Aufbewahrungsmöglichkeiten, der Zugriff bzw. die
Zulieferung in rasender Geschwindigkeit weiterentwickelt. Die Technik hinter
den Datenträgern und der Zulieferung der Information wird durch neue techni-
sche Erfindungen auch weiterhin rasant fortschreiten.
➡ Informationen sind mittels Medien zu einem Transportgut geworden.

Abbildung 1.5: Historische Entwicklung der Medien


46 Kapitel 1 • Orientierung zum Thema Data Warehouse

Informationen sind wichtige Faktoren in einem Herstellungsprozess von Pro-


dukten. Informationen müssen Arbeitsprozessen im richtigen Moment beige-
steuert werden können, sonst müssen ganze Arbeitsgruppen die Arbeit nieder-
legen. Informationen steuern den Start und die Bewegung von Maschinen.
➡ Informationen sind Produktionsfaktoren, sie haben eine Lieferfrist und eine
Wirkung.
Informationen werden in einer bestimmten Form geliefert. Sie können als ana-
loge oder digitale Signale übertragen werden, wie zum Beispiel als Ton, als Bild,
als Text, in Rundfunk und Fernsehen. Sie können codiert, zum Beispiel als Zah-
lenkolonnen, und verdichtet geliefert werden, was einen Aufbereitungs- und
Entpackungsprozess erfordert. Informationen können symbolisiert weitergege-
ben werden, wie in Piktogrammen. Sie können zwischen anderen Informatio-
nen versteckt sein, wie in Rätseln, und müssen dann erst entschlüsselt werden.
Informationen können dauerhaft auf Papier oder CD-ROM oder vergänglich als
Radiosendung geliefert werden. Sie müssen empfangen und aufbewahrt werden.
➡ Informationen haben eine Darstellungsform, eine Lieferform; sie befinden
sich auf einem Medium und können nachbearbeitet werden.
Zum Auffinden von Informationen kann man aus Zeitgründen und aus man-
gelndem Wissen, wo die Information zu finden ist, Berater und Services bean-
spruchen. Informationen können außerdem eine Bedeutung haben, die nicht
immer sofort ersichtlich ist. Ihre Interpretation kann so viel Insiderwissen vor-
aussetzen, dass man der Erklärung durch Consultants bedarf. Die Bedeutung
von bestimmten Informationen wird oftmals erst mit zusätzlichen Informatio-
nen und im richtigen Kontext erkannt.
➡ Information bedarf der Aufbereitung, der Kombination und der Interpreta-
tion.
Informationen sollen in Handlungsanweisungen umgesetzt werden können.
Das heißt, sie müssen in einer Form aufbereitet werden, die ein Handeln
ermöglicht. Das wiederum heißt, in Informationen müssen konkrete Anwei-
sungen eingebracht werden können, die bei Aufgabenträgern Handeln auslö-
sen. Auch hier hilft wieder der Zukauf von Erfahrung.
➡ Informationen müssen operationalisiert werden.
Zuverlässigkeit von Informationen
Informationen sind nicht immer zuverlässig. Wenn die Informationsbasis eines
Vorhabens nicht stimmt, sind Fehler in der Konzeption, in der Konstruktion
und in der Realisierung unvermeidlich. Oft ist nur unter großem Aufwand ein
Rückführen der Fehlsituation möglich. Mitunter muss sogar das ganze Vorha-
ben abgebrochen werden. Das ist der Fall, wenn man die falsche Methodik ein-
setzt, wenn man das Know-how der Firma nicht einfließen lassen kann, wenn
die Teammitglieder falsch geschult sind und vieles mehr. Deshalb müssen die
Informationen verschiedener voneinander unabhängiger Quellen miteinander
verglichen werden.
Kapitel 1 • Orientierung zum Thema Data Warehouse 47

Auf eine gute Informationsbasis ist größte Sorgfalt zu legen. Ein Unternehmen,
das auf Informationssorgfalt keinen Wert legt, braucht auch kein Data Ware-
house. Ein Unternehmen, das auf Informiertsein Wert legt, muss das Informie-
ren organisieren. Eine hohe Form der Informationsorganisation ist die Infor-
mationsproduktion des Data Warehouse.
Gestaltungsraum und Lösungswege
Das hier diskutierte Gestaltungsobjekt betrifft also die Organisation des Infor-
miertseins, die Auswahl der Informationsquellen, die Bezugsform und den Pro-
zess der Auswertung. Hierzu gehört die Beantwortung der folgenden Fragen:
➢ Wo sind Informationen zu finden?
➢ Auf welchen Trägern bzw. Trägersystemen soll meine Information geliefert
werden?
➢ Welche Informationen sind zuverlässig? Welche Güte haben die Informatio-
nen? Wie aktuell sind die Informationen? Sind die Informationen handhab-
bar aufbereitet?
➢ In welchem Rhythmus muss ich meine Informationsrecherchen wiederho-
len?
➢ Wie sind die Informationen auszuwerten? Wie soll mit den Informationen
umgegangen werden? Wer soll die Informationen aufbereiten?
Es gibt noch eine Reihe weiterer Gestaltungsfragen im Umgang mit dem Roh-
stoff Information:
➢ Wer muss zu welchem Zeitpunkt welche Informationen zugeliefert bekom-
men?
➢ Wie präzise muss die Information sein?
➢ Was ist zu tun, wenn die Information nicht rechtzeitig vorliegt?
➢ Welchen Nutzen bietet die Information und zu welchem Preis muss ich sie
erwerben?
➢ Wie lange dauert die Nachbearbearbeitung und Aufbereitung der Informa-
tion?
➢ Unterliegt die Information der Hol- oder Bringschuld?

Problemlösung: Regeln und Hilfsmittel


Das Verfahren
Das Thema Data Warehouse entwickelt sich so schnell weiter, dass ein kontinu-
ierliches Informieren unvermeidlich ist. Um nicht im Wald der Informationen
am einzelnen Baum Data Warehouse vorbeizulaufen, ist das Einholen der Infor-
mation zu organisieren. Informationssuche ist übrigens nicht nur zur Orientie-
rung wichtig, sondern später zur Anreicherung des DWH mit Daten. Das fol-
gende Verfahren zur Informationsplanung ist dabei hilfreich.
48 Kapitel 1 • Orientierung zum Thema Data Warehouse

Verfahren: Informationsplanung
❖ Definition des Informationsproblems »Zu welchem Problem ist zu
recherchieren?«, und Definition der Schlagworte zur Suche mit Check-
liste Schlagworte Data Warehouse
❖ Auswahl der Informationsquellentypen mit Checkliste Medientypen und
Checkliste ausgewählte Zeitschriften
❖ Auswahl der speziellen Lieferanten mit einer Checkliste Zeitungen, einer
Checkliste Beratungsunternehmen und einem Literaturverzeichnis
❖ Entscheidung über Kontinuität, Frequenz und Bearbeiter der Auswertun-
gen im Informationsplan

Checkliste Schlagworte Data Warehouse


Der erste Schritt besteht in der Festlegung, welche Informationen für die Pro-
blemlösung nötig sind und wo die geeigneten Informationen zum Thema Data
Warehouse zu finden sind. Geeignet bedeutet: im Hinblick auf Inhalt, Zuverläs-
sigkeit, Güte der Präsentation, Möglichkeit der Weiterverarbeitung sowie Trä-
gersysteme und Aktualität. Hierfür war schon die Kategorienfindung richtung-
weisend. Bei der Kategorienbestimmung setzt man sich mit einer Menge von
Begriffen auseinander, die zum Teil als zum Thema gehörig erkannt und zum
Teil ausgegrenzt werden. Das Ergebnis kann in einer Schlagwortliste für
zukünftige Recherchen zusamengestellt werden.
✔ Definition der Information für die Problemlösung
✔ Festlegung einer Schlagwortliste
Als erste Annäherung ist die folgende kleine Schlagwortliste Data Warehouse
und DWH-ähnlicher Systeme aufgeführt.

Data Mart, Data Mining, Data Warehouse, Information Warehouse


Decision Support, Executive Information
DSS, EIS, EUS, MIS, MOLAP, MUS, OLAP, ROLAP
Tabelle 1.4: Checkliste: Schlagworte Data Warehouse

Checkliste Medientypen
Mit Hilfe der Schlagworte wird in Informationsquellen oder Medien nach Infor-
mationen gesucht. Das setzt allerdings eine Entscheidung voraus, welche
Medien man auswerten möchte. Die Auswahl der Typen von Quellen ist über-
sichtlich in der Checkliste Medientypen dargestellt.
Kapitel 1 • Orientierung zum Thema Data Warehouse 49

Mediumtyp Arten, Quellen L M P E

Fernsehsendung Reportage, Serie, Videotext u

Rundfunk Reportage, Serie u

Zeitschrift Abonnement, Bibliothek, Kiosk, Firmenheft, Institutsorgan p

Zeitung Abonnement, Bibliothek, Kiosk p

Beratung Einzelberatung, Abruf, Period. Beratung, Task Force, Coaching a

Konferenz Forum, Podiumsdiskussion u

Seminar Workshop a

Messe Workshop, Ausstellung, Präsentation, Demonstration p

Präsentation Firmen-Präsentation, Kunden-Präsentation, Road Show p

Internet-Seite Verlag, Hersteller, Institut a

Online-DB Hersteller, Institut, Behörde, Kammer, Nachrichtengesellschaft a

CD-ROM Buch, Produktdemo, Katalog, Buchbeilage a

Videoband Verlag, Sendeanstalt a

Audiokassette Verlag a

Plakat Plakatwände u

Schwarzes Brett Firmengebäude u

Mailing Internet, Intranet u

Novellen Gesetze, Verordnungen

Archiv Bibliothek, Privat, Firmen, Behörde, Verein, Institut, Abtei

Prospekt Geschäftsbericht, Pressemitteilung a

Buch Monographie, Tagungsband, Studie, Evaluation a

Katalog Branchen-, Produkt-, Herstellerkatalog, Adressbücher a

Register Handelsregister

Gespräch Erfahrungsaustausch, Arbeitskreis, Interessengruppen a

M – mündlich, P – Papier, E – elektronisch, L – Lieferung: a – Anfrage, p – periodisch, u – unregelmäßig

Tabelle 1.5: Checkliste Medientypen

Zu einem Eintrag in die Checkliste führt die Beantwortung der folgenden Fra-
gen:
✔ Ist Data Warehouse Thema in Anzeigen der Hersteller und EDV-Zeitschrif-
ten? Ist Data Warehouse auch schon als Sonderteil der Zeitschrift xxx
behandelt worden? Hat die Zeitschrift die Artikel auch auf elektronischen
Medien zur Verfügung?
✔ Was sagen die Marktbeobachter? Für welche Marktbeobachter sollte man
sich interessieren? Wie äußern sie ihre Erkenntnisse und wie stark sind ihre
Erkenntnisse belastbar?
50 Kapitel 1 • Orientierung zum Thema Data Warehouse

✔ Wie sehen die Beratungsportfolios von Unternehmens- und EDV-Beratern


aus? Bieten die Berater auch Coaching, Projektbegleitung und Ausbildung
an? Sind die Berater unabhängig oder unterliegen sie einer Beteiligung?
Haben sie ein periodisches Informationsmedium?
✔ Ist das Thema auch in den öffentlich-rechtlichen Sendeanstalten präsent?
Gibt es eine periodische Sendereihe zu diesem Thema, eventuell mit Aus-
kunftsdiensten?
Checkliste ausgewählte Zeitschriften
Das einfachste Mittel ist hin und wieder der Weg zum Kiosk und der unregel-
mäßige Kauf einer entsprechenden Zeitschrift. Man wird sehr schnell vor der
Fülle des Angebots an EDV-Zeitschriften zurückschrecken und feststellen, dass
➡ speziell für das Data Warehousing keine Zeitschrift aufliegt,
➡ das Thema Data Warehousing in den allgemeinen EDV-Zeitschriften unre-
gelmäßig behandelt wird.
Es bleibt nichts anderes übrig, als die Inhalte der EDV-Zeitschriften regelmäßig
durchzusehen. Ein weiteres Problem ist, dass nicht alle Zeitschriften, die Kom-
petentes zum Thema Data Warehouse beizutragen haben, über Kioske vertrie-
ben werden. Viele Zeitschriften sind Organe von Vereinen und Gesellschaften
und nur per Bestellung zu beziehen. Zur Orientierung im deutschsprachigen
Zeitschriftenmarkt dient die Checkliste Ausgewählte Zeitschriften zum Thema
DWH. Auswahlkriterium war dabei, dass in den letzten zwölf Monaten dem
Thema Data Warehouse wenigstens einmal ein ausführlicher Aufsatz gewidmet
wurde.
Trotz Internet, CD-ROM und Konferenzen sind Zeitschriften immer noch das
ergiebigste Informationsmittel mit beharrlicher Kontinuität. Deshalb ist eine
Checkliste Zeitschriften nützlich, mit einer Auswahl derjenigen deutschspra-
chigen Zeitschriften, die erstens herstellerneutral sind und zweitens in den
letzten zwölf Monaten wenigstens einmal ein Data Warehouse Thema ausführ-
lich behandelt haben. Ergänzend sind noch ausgewählte amerikanische Hefte
angegeben (siehe Tabelle 1.6).
Neben diesen unabhängigen Zeitschriften gibt es auch Herstellerzeitschriften,
die allerdings nur auf ihre eigenen Produkte eingehen und diese nicht immer
neutral darstellen können. Sie sind aber doch sehr informativ, so dass es sich
lohnt, die Hersteller darauf anzusprechen.
Die Hersteller versenden auch Produktinformationen, Flyer und Produktbe-
schreibungen, die eher als Kaufanreiz denn als Sachinformation fungieren sol-
len. Die nicht immer sachlichen Farbglanzprospekte geben jedoch mindestens
einen Eindruck von den Komponenten der angebotenen Lösungen und ihrer
Funktionalität.
Kapitel 1 • Orientierung zum Thema Data Warehouse 51

Tabelle 1.6: Checkliste ausgewählte Zeitschriften

Man sollte auch nach sogenannten »White Papers« fragen, in denen wesentlich
tiefer auf technische Details eingegangen wird. Die eigentliche Absicht der White
Papers ist, eine Zukunft der eigenen Produkte und Technologien zu entwerfen.
Der bekannteste deutschsprachige Katalog für Software ist der ISIS-Report. Der
am meisten verbreitete Katalog über Unternehmen und Unternehmensbeteili-
gungen ist das Hoppenstedt Unternehmensverzeichnis.
52 Kapitel 1 • Orientierung zum Thema Data Warehouse

Neben Katalogen können auch spezielle Adressbücher weiterhelfen. In jedem


Land gibt es ein Behördenverzeichnis, das wiederum ein Hochschulverzeichnis
enthält. Das in der BRD am meisten verbreitete Verzeichnis dieser Art ist der
»Oeckl«. Gute Informationsquellen sind in diesem Zusammenhang die Ver-
bände mit ihren Adressbüchern und Branchenübersichten.
Elektronische Medien
Immer häufiger wird auch das Internet als Informationsmittel genutzt. Nahezu
alle Hersteller bieten ihre Informationen im Internet an. Auch die Hochschulen
verbreiten ihre Forschungsergebnisse im Internet und Buchverlage bieten
schon Buchseiten per Internet an. Der Vorteil des Internets besteht in der Mög-
lichkeit, Informationen schneller als durch Drucke zur Verfügung stellen zu
können. Deshalb wird eine neue Information in der Regel zuerst im Internet zu
finden sein.
Einige Zeitschriften, zum Beispiel c't, ix und GW, werden als komplette Jahr-
gänge auf CD-ROM und auf DVD angeboten, um eine komfortable, umfassen-
dere Suche gegenüber dem Papierexemplar zu ermöglichen. Der Nachteil ist,
dass in der Regel die CD-ROM erst am Ende eines Quartals oder eines Jahrgan-
ges erscheint. Audiokassetten, Videokassetten und DVD können gegenüber der
Internetnutzung unabhängig von PC und Büroöffnungszeit in der Freizeit am
heimischen Fernseher genutzt werden.
Der oben genannte ISIS-Report, wie auch das Hoppenstedt Unternehmensver-
zeichnis sind ebenfalls auf CD-ROM erhältlich und erscheinen quartalsweise.
Informationsveranstaltungen
Den Veranstaltern von Seminaren, Konferenzen, Foren und Workshops
kommt man über Zeitschriften auf die Spur. Die Qualität ist von Anbieter zu
Anbieter und von Veranstaltung zu Veranstaltung sehr unterschiedlich. Hier
kann man sich leider nur auf einen Ruf verlassen. Eine gute Orientierung ist
die Autorenliste. Leider werden immer häufiger zugkräftige Autorennamen für
einen Eröffnungsvortrag als Köder ausgerufen, und alle anderen Vortragenden
kommen eher zur Selbstdarstellung und Unternehmenspräsentation als zur
Informationsvermittlung.
Interessant sind auch einige Arbeitskreise und Gesprächsrunden, die von anwen-
denden Firmen, von Instituten und Vereinen eingerichtet werden. Interessen-
schwerpunkt ist der Erfahrungsaustausch. Leider erfährt man nur über Umwege,
meistens über die Vertriebsleute der Hersteller, von solchen Kooperationen.
Als direkte Ansprechpartner sind Universitäten zeitweise und als gesponsorte
Kooperationspartner in Projekten dauerhaft, sehr interessant. Der Vorteil
gegenüber anderen Informationsträgern ist, dass immer die Sicherheit einer
wissenschaftlichen Fundierung und Aktualität der Forschungsergebnisse gege-
ben ist. Der Nachteil ist die mangelnde Praxis. Alle Hochschulen mit einem
Bereich Wirtschaftsinformatik setzen sich mit dem Thema Data Warehouse
auseinander.
Kapitel 1 • Orientierung zum Thema Data Warehouse 53

Informationsplan
Nach der Entscheidung, welche Informationsquellentypen eingesetzt werden
sollen (wer zum Beispiel keinen Internetanschluss hat, kann sich nicht auf
Internetrecherchen beziehen), muss aus dem Angebot der Verlage, Hersteller,
Berater usw. eine konkrete Auswahl von Lieferanten ausgewählt werden.
Weiterhin ist zu unterscheiden, ob gezielt Information zu einem Problem
gesucht werden soll, oder ob regelmäßig der Überblick über die Neuerungen
eines Fachgebiets behalten werden soll. Der erste Fall ist eine gezielte Informa-
tionsrecherche. Im zweiten Fall handelt es sich um ein kontinuierliches Markt-
Monitoring, bestehend aus der Beobachtung des Marktes, der Marktteilnehmer,
der Konkurrenz, der Lieferanten, der Produzenten, der Institutionen und deren
Veröffentlichungen.
Ein nicht unerhebliches Problem bei der Auswertung der Informationen ist die
zunehmende Frühankündigung von Produkten. Mittlerweile ist die Produktan-
kündigung zum taktischen Instrument gegen den Mitbewerb geworden. Der
Unterschied zwischen der Verkündung des Erscheinungsdatums und dem tat-
sächlichen Erscheinen des Produkts ist oft groß und mitunter gibt es gar kein
Produkt. Es ist anzuraten, nach Messepräsentationen das besagte neuangekün-
digte Produkt probeweise zu bestellen. Ist es nicht wie versprochen lieferbar,
sollte man die Zusammenarbeit mit diesem Hersteller meiden. Unter Verspre-
chungen und falschen Erwartungen wird man über den gesamten Lebenszyklus
des Produkts leiden.
Informationssammlung und -aufbereitung ist aufwendig und ein Ressourcen-
problem und bedarf damit sorgfältiger Planung. In welchem Rhythmus muss
ich meine Informationsrecherchen wiederholen, zu welchem Termin muss die
benötigte Information verfügbar sein? Beschaffe ich die Informationen selbst
oder schalte ich einen Informationsbroker ein, der zwar teuer ist, aber doch viel
schneller das begehrte Objekt Information aufspürt?
Als Methode für das Marktmonitoring wie auch für die gezielte Informationsre-
cherche dient ein Informationsplan mit
✔ Nennung der Quellen (z.B. mit den Kürzeln der Lieferantenlisten)
✔ der beabsichtigten Auswertung (k – kontinuierlich, e – einmalig)
✔ Namen der auswertenden Bearbeiter
✔ Termin des Berichtens
Checkliste Beratungsunternehmen
Einige Informationsquellen können nur mit Hilfe kompetenter Berater ausge-
wertet werden. Die Charakteristik der Checkliste Beratungsunternehmen ist ein
Schnappschuss, ein Anhaltspunkt für eine Auswahl, da die Unternehmen ihr
Leistungsspektrum ständig den Forderungen des Marktes anpassen und auf
Anfrage sogar individuell und einmalig einen bestimmten Leistungstyp anbie-
54 Kapitel 1 • Orientierung zum Thema Data Warehouse

ten. Ein Kreuz in der Liste bedeutet, dass sich das Beratungsunternehmen durch
eine Publikation in dieser Sache geoutet hat. Die Auswahl wurde auf die ersten
zehn Unternehmen der sogenannten »Lünendonk-Liste 1998« eingeschränkt
(siehe Tabelle 1.7).

Firma Charakteristik A B C P K T S L M E

Gartner Group Strategieberater + Marktanalyst

META Group Strategieberater + Marktanalyst

Butler Bloor Group Produktanalyst

Forrester Research Marktanalyst, Produktanalyst

Frost & Sullivan Marktanalyst

IDC Marktanalyst

Ovum Marktanalyst, Produktanalyst

Andersen Consulting Strategie-Consulting, Wirtschaftprüfung

Schitag Ernst & Young Strategie-Consulting, Wirtschaftprüfung

KPMG Strategie-Consulting, Wirtschaftprüfung

Coopers & Lybrand Strategie-Consulting, Wirtschaftprüfung

Arthur D. Little Strategie-Consulting

Roland Berger Strategie- und IT-Consulting

Diebold Strategie- und IT-Consulting

CSC Ploenske AG IT-Consulting

Plaut-Gruppe IT-Consulting

gedas GmbH IT-Consulting

Softlab GmbH IT-Consulting

debis Systemintegrator

EDS Holding Systemintegrator

Datev eG Systemintegrator

tele daten service GmbH Systemintegrator

A – Ad hoc Anrufung, B – Body Leasing, C – Coaching, P – Projektmanagement, K – Konferenzen,


T – Technologieanalysen, M – Marktstudien, S – Statistiken, E – Evaluationsstudien, L – Letter

Tabelle 1.7: Checkliste Beratungsunternehmen

1.2.2 Trendanalyse
Problemstellung und Motivation
Der Markt ist bezüglich Produkttypen und Herstellern unüberschaubar groß
geworden und entzieht sich für Endkäufer der unmittelbaren Beobachtung.
Was ein Endkäufer vom Markt sieht, ist unvollständig und erklärungsbedürftig.
Kapitel 1 • Orientierung zum Thema Data Warehouse 55

Die Verpackung der Produkte wird immer verlockender, die Versprechen des
Vertriebs sind beharrlich. Das erste Problem, das es für den Data Warehouse
Manager zu lösen gilt, ist also die Objektivierung der Sichtweise. Die Aufgabe
dieses Projektschritts besteht damit aus der Festlegung
✔ der Quellenrecherche
✔ der Informationsbeschaffung
✔ der Informationsaufbereitung
✔ der Informationsauswertung
Das Data Warehouse besteht aus vielen unterschiedlichen technologischen
Komponenten. Die Komplexität der Komponentenstruktur zwingt dazu, die
Marktentwicklung der einzelnen Komponenten zu verfolgen. Es ist per se nicht
vorauszusehen, welche technologische Entwicklung in die Data Warehouse
Produkte einzieht bzw. welche Auswirkungen sie auf die technologische Ent-
wicklung von Data Warehouse hat. Daher ist es vorteilhaft, um Überraschungen
zu vermeiden, ein umfassendes Technologiemonitoring aufzubauen und perio-
disch die Relevanz der Strömungen für das Unternehmens-Data-Warehouse zu
hinterfragen.
Die Zukunft des Themas Data Warehouse ist leider nicht die Zukunft eines ein-
zelnen Produkts. Wie man im nächsten Kapitel sehen wird, sind im Data Ware-
house mehrere Produkttypen integriert und die Trends jedes dieser Produktty-
pen beeinflussen Erfolg und Misserfolg von Data Warehouse Projekten.
Solche Trendsituationen gab es zum Beispiel 1983, als das erste relationale
Datenbankmanagementsystem (Oracle) herauskam, 1989, als das erste Daten-
bankmanagementsystem (INGRES) einen Datenbank-Client mit grafischer
Bedienungsoberfäche auslieferte (unter OSF-Motif) und 1992, als der erste
Datenbank-Client mit grafischem, teilweise objektorientiertem 4GL Userinter-
face unter MS-Windows herauskam. Die Verkaufszahlen belegten, dass die
Unternehmen bereits gestartete Projekte nicht stoppten und auf die neue Tech-
nologie neu ausrichteten. Die Folge davon war, dass Standardsoftwarehersteller
Applikationen sogar dann noch mit zeichenorientierten Clients herausbrach-
ten, als die grafischen Oberflächen schon etabliert waren. Sehr viele Unterneh-
men haben demzufolge heute noch veraltete Technologien im Einsatz.
Die Informationsquellen-Recherche wurde im vorigen Kapitel behandelt. Man
hat nun eine Fülle von Informationen auszuwerten, bedient sich eines erfahre-
nen Beraters oder macht sich selbst an die Arbeit. Die Informationsaufberei-
tung besteht jetzt aus der Interpretation der Glaubwürdigkeit der Aussagen, der
Nachvollziehbarkeit der Schlüsse und der Belegbarkeit der Grundlagen. Man
wird hierbei mehrere Quellen nebeneinander legen, deren Erkenntnisse und
Empfehlungen vergleichen und sich eine eigene Meinung bilden, die dann
Grundlage für weitere Entscheidungen wird.
56 Kapitel 1 • Orientierung zum Thema Data Warehouse

Gestaltungsraum und Lösungswege


Der Gestaltungsvorgang besteht aus dem Festhalten der eigenen Erkenntnis in
einer übersichtlichen Form und der Angabe von Quellenreferenzen. Damit
kann man immer belegen, wie und auf der Basis welcher Informationen eine
Meinung zustande gekommen ist. Ändert sich eine Basisinformation durch eine
neue Tendenz, ist es nur noch erforderlich, diesen einen Gedankenfaden wieder
aufzunehmen und die Auswirkung auf die in der Vergangenheit getroffenen
Entscheidung zu beurteilen.
➡ Das Ergebnis wird dann zwischen folgenden zwei Extremen liegen:
– Der neue Trend ist ohne Einfluss auf die Entscheidung und die damit aus-
gelösten Maßnahmen; das Projekt kann weiterlaufen wie bisher.
– Der neue Trend stellt die getroffene Entscheidung völlig in Frage, alle
Maßnahmen müssen gestoppt werden, statt dessen sind neue Maßnah-
men zu treffen.
Die Gestaltungsaufgaben sind damit:
➢ Bestimmung der relevanten Trendthemen
➢ Auswahl der Informationsquellen nach den Anforderungen an Aktualität,
Kontinuität, Qualität
➢ Herstellen der Trendkarten einzelner Trends
➢ Zusammenführen der Trendkarten im Trendprofil
➢ Entscheidung zum Abwarten, Einsteigen oder zur Nichtbeachtung einzel-
ner Trends
Problemlösung: Regeln und Hilfsmittel
Das Verfahren
Was ist wie zu beobachten? Wie werden die Beobachtungen ausgewertet? Ist der
Markt im Aufschwung oder zeichnen sich bereits Tendenzen zur Ablösung einer
Produktgeneration ab? Ein Mittel der Marktanalysten hierfür ist die Portfolio-
analyse mit Abschätzung der Produktlebensphase. Aber auch die Ankündigun-
gen der Hersteller zeigen Wechsel von Produktgenerationen an. Für den DWH-
Spezialisten ist die Portfolioanalyse zu aufwendig. Er wird die Ergebnisse von
Marktanalyseunternehmen beziehen können. Mit weniger Aufwand ist die
Trendanalyse zu handhaben.
Die Trendanalyse für Data Warehouse Entscheidungen ist also nicht nur eine
Trendanalyse von Data Warehouse als Produkttyp, sondern sie ist für jeden der
entscheidenden Produkttypen, die ein Data Warehouse umfasst, integriert oder
anlagert, durchzuführen, und ihre Wechselwirkungen sind sorgfältig zu analy-
sieren. Der Ablauf der Trendanalyse ist wie folgt zu empfehlen.
Kapitel 1 • Orientierung zum Thema Data Warehouse 57

Verfahren: Trendanalyse
❖ Bestimmung der relevanten Trendthemen
❖ Auswahl der Informationsquellen nach den Anforderungen an Aktualität,
Kontinuität, Qualität,
❖ Herstellen der Trendkarten einzelner Trends
❖ Zusammenführen der Trendkarten im Trendprofil

Die Trendschätzung
Die vom Management zu treffenden Entscheidungen zielen auf Maßnahmen
mit zukünftigen Wirkungen, basieren aber zwangsläufig auf den Erkenntnissen
aus Vergangenheit und Gegenwart. Die Methodenklasse der Extrapolation der
Erfahrungen auf die Zukunft ist die Trendschätzung. Die zukünftigen Auswir-
kungen der Maßnahmen sind in gleichem Maße von externen Tendenzen und
Trends wie von internem Bedarf abhängig. Der Erfolg der getroffenen Maßnah-
men hängt deshalb stark von der Genauigkeit der Einschätzung der Trends der
Unternehmensumwelt ab. Das sind aus der Sicht der EDV die innovativen Infor-
matiktechnologien und ihre Durchsetzung als Produkte auf dem Markt.
Voraussetzung für die Einschätzung von Trends ist
✔ Klassifizierung von Systemarten
✔ Klassifizierung von Schlüsseltechnologien
✔ eine Klassifizierung von Trends
✔ eine Darstellung der gegenseitigen Beeinflussung der Trends
✔ ein Katalog mit Umweltsignalen für die Einschätzung der Bewegung jedes
Trends
✔ Kategorisierung des Trends für das Betätigungsfeld des Unternehmens
Trendkarte
Die Methodenklasse Trendschätzung soll hier durch einen effizienten Vertreter,
die Trendkarte, repräsentiert werden. Das Ziel der Analyse der Technologie-
trends ist die Einschätzung der für die Erfüllung der Unternehmensaufgaben
relevanten Trends zur Stützung der Entscheidung, für welche Trends in wel-
chem Umfang (Aktivitäten, Budgets) die Zukunft der DV geöffnet werden sollte.
58 Kapitel 1 • Orientierung zum Thema Data Warehouse

Trendkarte: Technologiethema xxx


Trend:
Der Markt entwickelt sich …
Konkurrierende Unternehmen betreiben bereits …
Die XXX-Produkte zeigen bereits die Funktionalität von …
Die Produkte sind abhängig von der Standardisierungseinigung zwischen …
Unternemenssituation:
Das Unternehmen ist in der Evaluation ..., hat bereits im Einsatz …, im Test …
Das Unternehmen hat einen Sponsor ernannt …, hat Erfahrung mit …, hat
budgetiert für …
Aktivität:
Die Anschaffung von ... bis …
Weiterbeobachten bis …
Tabelle 1.8: Muster Trendkarte

Die Ausarbeitung dieser Musterstruktur zu einer Trendbeurteilung soll im Fol-


genden am Beispiel einer fundamentalen Komponente des DWH, der Technolo-
gie der Datenbankmanagementsysteme, verdeutlicht werden.

Beispiel: Trendkarte für die Technologie Datenbankmanagementsysteme


Es ist klar, dass Data Warehouses nur mit einer Form von Datenspeicherung
funktionieren können. Ein Trend, der für viele Gestaltungsentscheidungen
wesentlich ist, ist daher die Technologie der Datenbanksysteme.
Trendkarte Datenbankmanagementsysteme
Trend:
DBMS bilden den Kern der Datenbankanwendung. Ihre Leistungsfähigkeiten
begrenzen die Möglichkeiten der Anwendungsgestaltung. Im Markt der
DBMS hat sich die relationale Technik mit Data-Dictionary, Queryoptimizer,
Backup und Recovery-Funktionalität, Transaktionsverwaltung und Dead-
lock-Entsperrung und Verteilte Datenhaltung auf der Basis einer standardi-
sierten SQL durchgesetzt. Einige Hersteller bieten zudem eine Replikations-
mechanik an, die es erlaubt, auf einem Client losgelöst vom Zustand eines
Netzes unabhängig zu arbeiten.
Tabelle 1.9: Trendkarte Datenbankmanagementsysteme
Kapitel 1 • Orientierung zum Thema Data Warehouse 59

Über die Normalisierung hinausreichende Integrität wird von einigen Her-


stellern durch die Programmierkonzepte Trigger, Alerter, Rules, DB-Proce-
dures unterstützt. Für die Einführung des objektorientierten Paradigma in
DBMS sind zwei Wege beschritten worden: Verhaltensorientierte DB-
Objekte durch die Möglichkeit der Definition eigener Datentypen und Ope-
rationen analog dem Konzept der abstrakten Datentypen und struktur-
oder datenorientierte Objekte durch die Bündelung von Tabellen und
Attributen zu komplexen Einheiten. Die Zukunft der OODBMS liegt in der
Zusammenführung beider Wege zu voller Objektorientierung. Der Erfolg der
OODBMS wird von der Kompatibilität mit einem bereits standardisierten
Objektorientierten SQL (OOSQL) abhängen, da nur diese die Investition in
die SQL-Anwendungen erhalten. Die derzeit auf dem Markt angebotenen
OODBMS werden sich wegen ihrer Inkompatibilität zu den SQL-RDB nicht
für betriebswirtschaftliche Anwendungen durchsetzen.
Unternehmenssituation:
Unternehmen mit großen Datenbeständen auf konventionellen Datenbanken
und Filesystemen sind auf einen Datenaustausch mit RDBMS angewiesen.
Der Parallelbetrieb der alten Systeme zu den Neuanwendungen setzt in der
Regel die Pflege einer Minimalmenge gleicher Daten und Datenstrukturen
auf beiden Systemen voraus. Hierfür ist eine bidirektionale Migrationssoft-
ware erforderlich, die über Ereignisse gesteuert werden kann. Neben der
Möglichkeit, vom Client aus über das RDBMS auf konventionelle Daten
zuzugreifen, kann auch der Direktzugriff über ein Gateway, z.B für Ad-hoc-
Anfragen über ein EIS oder ein OLAP-Tool, nützlich sein. Der Bedarf für den
Einsatz von Gateways für die Zukunft sollte erwogen werden.
Aktivität:
Die Auswahl eines RDBMS soll die Öffnung in Richtung OOSQL und OLAP
sicherstellen, die Möglichkeit der Replikation, Triggerung, Alerter, Rules,
DB-Procedures enthalten, bidirektionale automatische Migrationswerk-
zeuge bieten und über Gateways oder Middleware erreichbar sein.
Tabelle 1.9: Trendkarte Datenbankmanagementsysteme (Forts.)

Trendprofil
Die einzelnen Trendkarten sollten noch einmal übersichtlich in einem Trend-
profil zusammengefasst werden. Im folgenden Muster Trendprofil allgemeine
Technologien werden nur so viele technologische Felder aufgezählt werden, wie
sie aus Zeitschriften und Lehrbüchern zur Informatik bekannt sind und mit
den bisherigen Kenntnissen einen Einfluss auf die Technologie von Data Ware-
house vermuten lassen. Die genaue Bestückung des Trendprofils ist erst mit
dem Wissen der folgenden Kapitel, die sich mit den Architekturkomponenten
befassen, möglich.
60 Kapitel 1 • Orientierung zum Thema Data Warehouse

Maßnahme
Technologie Relevanz Trend
für DWH
Werkstoffe Keramik ohne
Erinnernde Metalle
Kristalline Gele
Makroformmoleküle

Physik-Verfahren Supraleiter ohne


Laser

Bio-Verfahren Bio Chips ohne

Provider Liberalisierung Eventuell


DWH-Dienste

Netze ATM beobachten


Giga Ethernet

Hardware Multiprocessing beobachten


Clustering

Peripherie Spracherkennung beobachten

Betriebssystem Verteilte Betriebssysteme beobachten

Datenhaltung Datenbankmaschinen auswerten

Softwareentwicklung Objektorientierung auswerten,


Java beschaffen
XML

Online-Datenbanken Internet-Anbindung auswerten

DSS, EIS In Data-Warehouse-Markt auswerten,


übergegangen beschaffen

Middleware Öffnung der Herstellerstandards auswerten

Workgrouping auswerten

Workflow Dialogsteuerung auswerten


Supply Chain

Endusertools Intelligente Tutorials auswerten,


Einheitliche Makrosprachen beschaffen

Image Processing Mustererkennung mit auswerten


Künstlicher Intelligenz
auswerten
Expertensystem In Data-Warehouse-Markt
übergegangen

Neue Technologien Nanotechnologie ohne


Optotransistoren

Tabelle 1.10: Muster Trendprofil allgemeine Technologien

Strategische Allianzen
Für die Beurteilung der Durchsetzungsfähigkeit eines vermuteten Trends ist
die Betrachtung der strategischen Allianzen ein gutes Hilfsmittel. Die Faustfor-
mel lautet:
➡ Wenn sich die großen Hersteller, die Key Player, einig sind, wird sich der
Trend in Form eines umfassenden Produktspektrums etablieren.
Kapitel 1 • Orientierung zum Thema Data Warehouse 61

Diese Einigkeit drückt sich zum Beispiel in der Zusammenarbeit und noch
deutlicher in der Neugründung von Standardisierungsgremien aus. Dies ist
noch keine Garantie für die Akzeptanz des Nachfragemarktes. Oft genug sind
diese Gremien auch genauso schnell wieder ohne Produkte von der Bildfläche
des EDV-Marktes verschwunden, wie sie aufgetaucht sind, wie zum Beispiel das
von IBM getriebene Projekt »Talligent«. Deshalb ist abzuwarten, bis die Mehr-
zahl der Mitbewerber mit Produkten aufwartet.
Schwieriger ist die Beurteilung konkurrierender Allianzen. Die Einschätzung
von Trends auf der Basis von gegenseitigen Wechselwirkungen ist äußerst auf-
wendig und Sache der Marktanalysten. Die Ergebnisse sollten in Form von Markt-
studien beschafft werden. Zur Analyse der Allianzsituation dient eine Bezie-
hungsmatrix der Kooperationen, was hier aber nicht weiter vertieft werden soll.
Schwierig ist ebenfalls die Beurteilung der Auswirkung eines sich durchsetzen-
den Trends auf andere Trends. So hat zum Beispiel der Bedarf nach grafischen
Oberflächen auch die Nachfrage nach Objektorientierung beflügelt. Für Analy-
sen dieser Art können sogenannte »Wirkungsgefüge« dargestellt werden. Der
Aufwand hierfür rechtfertigt das Ergebnis jedoch nicht.


Für IT-Trends sind lesenswert:


Hanker, Strategische Bedeutung
König, Informationstechnologie
Für IT-Trendanalysen sind nicht nur die IT-Trends zu beachten, sondern auch


politische und gesellschaftliche Strömungen, zu lesen in:
Kennedy, 21. Jahrhundert

1.2.3 Fortsetzungsbeispiel InDaWa


Einleitung
Zu diesem Zeitpunkt kann zwar noch keine Zielsetzung erfolgen, wohl aber
eine zielbestimmende Kraft ausgemacht werden, nämlich die Bewegungen der
Märkte. Wo sich Märkte verändern, sind Konsumenten, welche die Produkte
der Märkte abnehmen, und im Falle der EDV-Systeme sind da immer auch kon-
kurrierende Hersteller, welche die Produkte anbieten.
Marktbeobachtung heißt auch die eigene Konkurrenz betrachten. Je stärker
sich die Konkurrenz mit neuen Technologien rüstet, umso größer ist die
Gefahr, dass deren Möglichkeiten für ein neues Pricing durch effizientere
Geschäftsprozesse Umsatzeinbußen zur Folge hat. Deshalb ist in den Gang der
Gestaltungsentscheidungen die Beobachtung von Märkten, Herstellern und
Konkurrenten aufgenommen worden. Die Entscheidung umfasste die Informa-
tionsquellen und die Auswertung der Informationen auf einem rudimentären
Level, hauptsächlich als Merkpunkt. Für die detaillierte Ausarbeitung einer
Marktbeobachtung muss nicht nur auf Marketingliteratur verwiesen werden,
sondern auch darauf, dass dies die Aufgabe der Marketingabteilung ist.
62 Kapitel 1 • Orientierung zum Thema Data Warehouse

Beispiel für ein Trendprofil der Informatiktechnologien für InDaWa


Die Stromversorger hatten bis vor kurzem ein Quasimonopol in einer für die
Versorgung aufgeteilten Bundesrepublik. Derzeit befindet sich der Strom-
markt in einem Umverteilungsprozess, besonders durch den neuerdings mög-
lichen Direktbezug von Strom bei beliebigen Herstellern. Ein Endabnehmer
kann sich seinen Stromlieferanten selbst auswählen. Ein Konkurrenzmonito-
ring wird allmählich für das DWH eines Versorgers interessant. Das Beispiel-
projekt InDaWa zielt aber nicht auf den Absatz, sondern auf die Produktion.

Technologie Rel. Trend Maßnahme

Hardware + Multimedia Einführung Client-Server-Technologie


kleinere Einheiten Vernetzung
Dezentralisierung Parallelbetrieb vorhandener proprietärer
Systeme

Betriebs- + Multimedia Sicherstellung Kooperation mit


system 32Bit proprietärem System
Multitasking Offenhaltung für multimedialen Einsatz
Integration von Sub-Betriebssystemen
Objektorientierte Oberfläche

DBMS ++ Datenorientierte OO relational mit Data Dictionary, SQL


OOSQL Gateway-Angebot beachten
Multiplattform Kompatibilität mit Standardsoftware
Kompatibilität mit Entwicklungstoolkit
Bidirektionale Migration

SWEToolkits ++ Integration mit CASE-Tool konsequente Trennung Client von Server-


bidirektional-DataDictonary-ERM funktionen
OO-Programmiersprache konsequent OO
4Gl Offenhaltung Multimedia
GUI Möglichkeit 4Gl-Einsatz erhalten
Softwarefactory Einbindung Terminalemulation
Java, VBA, ODBC, CORBA, DCE Einbindung Transaktionsmonitor,
Konfigurationsverwaltungstool anbinden

OnlineDB 0 bessere Dienste Recherchen-Integration


umfangreiche Informationen Formatkonversion
GUI

DSS, EIS ++ Funktionalität geht in Data Ware- Integriert in SSW


house Toolsets ein, Trennung Middleware erforderlich
von operativen Daten

OLAP ++ als Ergänzung zu DB Middleware und Server erforderlich


relational und multidimensional Entscheidung über relational versus
multidimensional finden

Workflow – gemeinsame Dokumentbearbeitung Bedeutung für Data Warehouse nicht


für Dialogsteuerung eingesetzt klar, deshalb eruieren

BWSSW 0 OO, GUI Schnittstellenanbindung zur Individual-


offene RDB software
modular Parametrisiertes Customizing
marktgängiges DBMS
komfortables Toolkit
Client-Server-Architektur

ExpertenSyst – Standardisierung nicht vorhanden weiter verfolgen


Neuron. Netze Funktionalität wird zusammen mit Nützlichkeit und Notwendigkeit
Fuzzy Sets anderen Produkten offeriert herausarbeiten
in Evaluationen eventuell einbeziehen

Tabelle 1.11: Trendprofil: IT-Technologien mit Data Warehouse Relevanz


Kapitel 1 • Orientierung zum Thema Data Warehouse 63

Auch für das Data Warehouse des Beispielprojekts ist erst die Komponenten-
struktur herauszuarbeiten, bevor die relevanten Trends zur Beobachtung
ausgewählt werden können. Mit dem derzeitigen Wissensstand ist allerdings
schon eine erste Annäherung möglich, die im »vorläufigen« Trendprofil her-
ausgearbeitet ist.

Das folgende Beispiel stellt die weiteren Informationsentscheidungen zum Bei-


spielprojekt des Data Warehouse für die Instandhaltung der Kraftwerke eines
Versorgers dar.

Beispiel: Informationsentscheidungen Instandhaltung


Die Recherche, ihre Auswertung und die Aufbereitung für eine Teampräsen-
tation nehmen zunächst viel Zeit in Anspruch, bis sich nach ca. drei Monaten
Routine einstellt. Viel wichtiger ist allerdings, dass die Aufgabenträger mit
Engagement recherchieren und dafür die nötige Zeit eingeräumt bekom-
men. Die Informationsorganisation ist allerdings unverzichtbar.
✔ Über die Randthemen, die eventuell einmal Einfluss auf den Aufbau und
die eingesetzten Werkzeuge des Data Warehouse nehmen könnten, sollen
kontinuierlich Informationen eingeholt werden. Der Schwerpunkt soll
weniger auf die Unternehmenssituation als vielmehr auf Praxistests
gelegt werden. Die Produkte sollen eher die Serverseite und dort die
UNIX und NT-Plattform umfassen. Im Beispielprojekt wurde ein Abonne-
ment einer UNIX-Zeitschrift bestellt.
✔ Über Hard- und Softwareprodukte der Enduser-Arbeitsplätze unter Win-
dows-Releases soll ein Abonnement einer monatlichen PC-Zeitschrift
bestellt und monatlich für die Abteilungsssitzung ausgewertet und von
einem Mitarbeiter vorgetragen werden.
✔ Besonders interessante Produkte sollen in einer das Marktgeschehen
beleuchtenden Zeitschrift verfolgt werden. Außerdem sollen die Herstel-
ler der bereits installierten Produkte einer kontinuierlichen Beobachtung
unterzogen werden. Im Beispielprojekt wurde ein Abonnement einer
EDV-Wochenzeitschrift bestellt.
✔ Bei konkretem Bedarf an einer neuen speziellen Softwarelösung sollen
Produktstudien von zwei konkurrierenden Beratungsunternehmen mit
Technologiekompetenz eingeholt werden.
✔ Für die Problematik der Migration und der Gestaltungsmethodik von
Daten und Prozessen sollen gezielt Hefte auf akademischem Niveau mit
Praxisbezug, also keine Grundlagentheorie, ausgewählt, bestellt und von
Systemanalytikern aufbereitet werden.
✔ Zu den branchenübergreifenden Informationen sind noch die Tendenzen
des Softwareeinsatzes im Instandhaltungssektor über Zeitschriften und
Besuch von Konferenzen zu beobachten.
64 Kapitel 1 • Orientierung zum Thema Data Warehouse

Bear-
K Medium Bearbeitung Termin beiter
1 CT monatliche Auswertung mit Vortrag in Abteilungsbesprechung 1. Montag Müller
im Monat

2 iX monatliche Auswertung mit Vortrag in Abteilungsbesprechung 1. Montag Meier


im Monat

3 CW Einschätzung der Unternehmen, die in 1. und 2. im Vortrag bei Bedarf Schmidt


empfohlen wurden

4 BB, OV Beschaffung und Auswertung der Studie zu Entwicklungswerk- bis 3. Schmidt


zeugen für Data-Warehouse-Anwendungen Quartal

5 IM, IS, WI Auswertung der methodologischen Aufsätze für die Integration bis Jahres- Müller
in ein bestehendes Vorgehensmodell ende

6 Instandhaltg. Auswertung der Aufsätze für Software zum Instandhaltungs- laufend Müller
mi management 2monatlich

Tabelle 1.12: Informationsplan InDaWa

Gestaltungsentscheidungen
Zusammengefasst ergeben sich die folgenden (hellgrau hinterlegten), das Pro-
jekt oder das Data Warehouse gestaltenden Entscheidungen. Für die Beobach-
tung der Markttendenzen werden kontinuierlich Informationsquellen ausge-
wertet und Trendcharts und Trendprofile erarbeitet. Die Projektvorbereitung
soll zunächst mit der Feststellung der persönlichen Zielsetzung starten, um sie
dann mit der Unternehmenszielsetzung zu vergleichen.

Gestaltungsaspekt Entscheidung Begründung

ORIENTIERUNG

Abgrenzung

Markttendenzen

Quellen Informationsorganisation nach starker Wandel, kontinuierliche Verfolgung


Informationsplan

Trends Verfolgung mit Trendchart und hohe Relevanz bezüglich Revision von
Technologiekarte Entscheidungen

Zielsetzung

Persönliche Zielsetzung

Unternehmenszielsetzung
ARCHITEKTUR
...

Tabelle 1.13: Entscheidungschart InDaWa, Markttrends


Kapitel 1 • Orientierung zum Thema Data Warehouse 65

1.3 Wie ist das Vorhaben Data Warehouse im


Unternehmenszusammenhang zu sehen?
Der Aufbau eines Data Warehouse ist kein isoliertes Vorhaben, sondern in einen
Unternehmenszusammenhang eingebunden. Das Unternehmen arbeitet ausge-
richtet an einer Zielsetzung, welche die Geschäftsleitung jährlich ausgibt und
stufenweise detailliert auf die Hierarchieebenen umlegen lässt.
Je besser die Übereinstimmung der Zielvorstellungen mit persönlichen Zielen
der Mitarbeiter harmoniert, je besser sich die Mitarbeiter mit der Unterneh-
menszielsetzung identifizieren können, desto besser werden die qualitativen
und quantitativen Ergebnisse ihrer Arbeit sein. Vor jedem Vorhaben sollte des-
halb die private Zielsetzung von den Teammitgliedern an die Projektleitung
kommuniziert werden. Ebenso muss auch die Zielsetzung der Firma unmiss-
verständlich und ausführbar bekannt werden.
Der Unternehmenszusammenhang wird in den vier Schritten persönlicher Sta-
tus, persönliche Zielsetzung, Unternehmensstatus und Unternehmenszielset-
zung erarbeitet.

1.3.1 Der Qualifikationsstatus


Problemstellung und Motivation
Nur auf ein Ziel ausgerichtete Mitarbeiter führen ein Projekt zum Erfolg. Des-
halb ist es für jeden einzelnen Projektteilnehmer wichtig zu erkennen, mit
welchen persönlichen Zielen er die Projektaufgaben erledigt. Das heißt, die per-
sönliche Startposition, die Einordnung des eigenen Standpunkts und die Fest-
legung der persönlichen Ziele stehen am Anfang des Projekterfolges.
Nicht jedes Wunschziel ist erreichbar und erreichbare Ziele sind nicht unbe-
dingt in einem vorgegebenen Zeitraum zu erreichen. Qualifikationsaufbau
benötigt einen der Sorgfalt genügenden Zeitrahmen. Ist das Erfahrungslevel zu
weit vom Qualifikationsziel bzw. von dem für das Projekt erforderlichen Qualifi-
kationsniveau entfernt, ist ein Projektmitglied mit den anstehenden Aufgaben
überfordert. Die Folge ist, dass das Projekt qualitativ in Schieflage gerät oder
der Projektfortschritt einen Stillstand erleidet, bis die erforderliche Qualifika-
tion aufgebaut ist. Beides kann die ursprüngliche Zielsetzung gefährden.

Gestaltungsraum und Lösungswege


Zur Erreichbarkeit von Zielen gehört die Feststellung des Ausgangspunkts. Zur
Erreichbarkeit eines Qualifikationszieles gehört damit auch die Feststellung
des Qualifikationsstatus. Als Gestaltungsaufgabe ist daher wichtig:
➢ Feststellung des eigenen Qualifikationslevels bzw. des Qualifikationslevels
der Teammitglieder
66 Kapitel 1 • Orientierung zum Thema Data Warehouse

Problemlösung: Regeln und Hilfsmittel


Das Verfahren
Für die Erhebung des eigenen aktuellen Kenntnisstandes und des Kenntnis-
standes der Mitarbeiter ist die folgende Vorgehensweise zu empfehlen:

Verfahren: Qualifikationsstatus
❖ Auswahl eines Kenntnisfeldes und Zuordnung des bisherigen Tätigkeits-
feldes bzw. der Projektphase (Planung, Betrieb, Training) zu einem oder
mehreren Spalten mit Hilfe des Musters persönliches Kenntnisprofil
❖ Feststellen des »Ausprägungsgrades« durch Eintrag des Beschäftigungs-
levels
(K – Kenntnis, L – Leitung, M – Mitarbeit, D – Durchführung)
❖ Eintragung der Rolle
(P – Projektleitung, A – Analytiker, B – Berater...)
und der Branche
(F – Finanzdienstleister, I – Industrie, L – Landwirtschaft, H – Handel, Ö
– Öffentlicher Dienst)

Kenntnisprofil
Eine geeignete Methode zur Feststellung des persönlichen Startpunkts ist das
Kenntnisprofil. Ein Kenntnisprofil ist eine Matrix mit einer sortierten Liste von
Kenntnisfeldern (z.B. Sachthemen) und einem Maßstab für die Beschäfti-
gungstiefe der Kenntnis und deren Ausprägungsgrad. Hierfür ist das Muster
persönliches Kenntnisprofil entwickelt worden.
Für die Beschäftigungstiefe ist einmal die Phase des Projekts oder des Betriebs
ein Hinweis. Die fachliche Tiefe ist z.B. in der Konzeptionsphase stärker als in
der Planungsphase. Die Zuordnung der Tätigkeiten ist nicht immer ganz ein-
deutig möglich, deshalb sei eine kleine Zuordnungshilfe durch die folgende
Auflistung beigestellt.
✔ Unter Weiterbildung werden Lehrgänge, Zeitschriftenbezug, Teilnahme an
Arbeitskreisen, Mitgliedschaften subsumiert.
✔ Unter Strategische IT-Planung werden das Erstellen von Strategiepapieren,
DV-Rahmenplänen, Verwaltung eines IT-Projekteportfolios, Erstellung von
Vorstandsvorlagen subsumiert.
✔ Unter Projektierung werden Projektantrag, Planung, Budgetierung,
Beschaffung, Organisation subsumiert.
✔ Zur Konzeption gehört der fachliche Entwurf, die Erhebung des Informati-
ons- und Systembedarfes, Ist-Analyse und Wissensakquisition.
Kapitel 1 • Orientierung zum Thema Data Warehouse 67

✔ Unter Spezifikation wird das Design, die EDV-technische Konzeption und


die Produkt-Evaluation verstanden.
✔ Unter Realisation werden Aufbau von Entwicklungs- und Betriebshardware,
Test, Programmierung, Implementierung, Testinstallation, subsumiert.
✔ Unter Implementierung ist Installation der Betriebsumgebung, Testbetrieb,
Parametereinstellung einzuordnen.
✔ Unter Betrieb ist die laufende Administration, Tuning, Monitoring, Datensi-
cherung, Berechtigungsverwaltung zu verstehen.
✔ Unter Training ist die Aufbereitung von Schulungsunterlagen, die Einfüh-
rung von Nutzern und das Abhalten eines Seminars zu verstehen.
✔ Unter Service ist Wartung, Austausch, Reparatur, Problembehandlung, Task
Force zu subsumieren.
Um einer Kenntnisausprägung einen Grad zuordnen zu können, stehen quali-
tative Kriterien zu den Graden zur Verfügung. Der Grad der Kenntnis hängt
von der Tiefe der Auseinandersetzung mit dem Thema ab. Für die Tiefe ist fol-
gende Skala ausreichend, wobei von oben nach unten gelesen der Grad der
Kenntnistiefe steigt:
✔ K – Kenntnis, z.B. durch Lesen von Literatur, Einführungsseminar
✔ L – Leitung, Planung und Steuerung der Abwicklung
✔ M – Mitarbeit in einem Projekt, Zulieferung von Teilergebnissen
✔ D – Durchführung, Ergebnisproduktion zum Betätigungsfeld in voller Tiefe
Mögliche Rolleneinträge sind: Projektmanager, Teamleiter, Teilprojektleiter, IT-
Stratege, Systemanalytiker, Berater, Systemingenieur, Programmierer, Beschaf-
fer, Organisator. Dabei kommt es nicht auf die Stellung in der Firma an, son-
dern vielmehr auf die Funktion im Rahmen eines Vorhabens oder eines Pro-
jekts in der Firma bezüglich der in der Spalte eingetragenen IT-Komponenten.
So kann zum Beispiel der Projektleiter für ein WAN-Projekt als Systemanalyti-
ker für eine Office-Lösung eingesetzt sein und bezüglich CASE nicht mehr als
private Weiterbildung über Zeitungsabonnements betreiben.
Die Quelle für die Informationen kann eine Selbstauskunft mittels eines Inter-
views wie z.B. bei Einstellungsgesprächen sein oder eine Lebenslaufanalyse.
Am besten kombiniert man beide Auskünfte.
68 Kapitel 1 • Orientierung zum Thema Data Warehouse

Kenntnisprofil

Ausprägungsgrad

keine

Weiterbildung

Strategische Planung

Projektierung

Konzeption

Spezifikation

Realisation

Implementierung

Betrieb, Administration

Training

Service

Kenntnisse 0 1 2 3 4 5 6 7 8 9 10 Rolle, Branche


Enduser-Tools
PM-Tools
CASE
BPR-Tool
DBMS
SSW
Programmiersprache
Intranet
Internet
CAD
CAE
DMS
PPS
CIM
Archivierung
Workflow Tool
Data Warehouse
Organizer
PC+ BS
WS
SV + LAN-BS
Host + OS
Peripherie
LAN
LAN-Komponenten
WAN

Tabelle 1.14: Muster persönliches Kenntnisprofil


Kapitel 1 • Orientierung zum Thema Data Warehouse 69

1.3.2 Die persönliche Zielsetzung


Problemstellung und Motivation
Eine der schwerwiegendsten Ursachen für Projektmisserfolge ist der unbe-
wusste Verlust der Zielsetzung durch die Verfolgung von Nebenzielen. Am
sichersten ist man, wenn man sich der eigenen Intentionen bewusst ist. Das
muss auch im Team diskutiert und regelmäßig geprüft werden. Hier hilft ein
offener Projektführungsstil weiter.
Nur wenige Projektmitglieder können auf die Frage nach ihren Erwartungen
eine konkrete Antwort geben:
✔ »Was will ich überhaupt mit diesem Thema anfangen?«
✔ »Aus welchem Grund beschäftige ich mich mit der Thematik bei meiner
ohnehin schon knappen Zeit?«
✔ »Was will ich am Ende der Auseinandersetzung mit dem Thema erreicht
haben?«
Eine Zielsetzung ist klar: Im Laufe des Projekts soll so viel Wissen und Können
aufgebaut sein, dass man ein Data Warehouse aufbauen und betreiben kann.
Mit ausschlaggebend für die Ziele der Qualifikation ist selbstverständlich auch
eine gewisse Orientierung an den Anforderungen des Personalmarktes. Was aus
der Sicht einiger Arbeitgeber dazu gehört, soll die Sammlung der Stellenanzei-
gen unterstreichen. Qualifikation heißt auch Erhöhung des Marktwertes der
eigenen Arbeitskraft, d.h. bei einer Stellensuche mehr bieten zu können und
dadurch bessere Erfolgsaussichten zu haben (siehe Abbildung 1.6).

Abbildung 1.6: Ausgewählte Stellenanzeigen zum Thema Data Warehouse


70 Kapitel 1 • Orientierung zum Thema Data Warehouse

Will man nicht planlos umherirren, ist persönliche Zielsetzung gefordert. Wer
ein Data Warehouse managen will, muss auch geplant vorgehen. Nur mit Pla-
nung ist das komplexe Gebilde auf überschaubare Handlungseinheiten und
Arbeitsschritte zu reduzieren. Planung setzt Zielsetzung voraus. Das Objekt der
Gestaltung ist zunächst einmal die persönliche Zielsetzung.
Zielsetzung beginnt oft mit einer kleinen Notiz auf einem Notizblock nach
einem Gespräch, während einer Geschäftsbesprechung, als spontane Idee oder
auf einem Spaziergang. Zielsetzungen werden aus Vorstellungen gewonnen,
von Gesprächspartnern übernommen oder auch angelesen. Zielfindung ist ein
kreativer Prozess.
Es empfiehlt sich, die gefundenen Projektziele schriftlich festzuhalten; das ent-
lastet das Erinnerungsvermögen und macht die Ziele für andere besser nach-
vollziehbar. Um auch später noch zu wissen, wie die Ziele zustande gekommen
sind, sollte neben dem Ziel noch eine Begründung mit aufgeführt werden. Der
Gestaltungvorgang umfasst also neben der Zielfindung auch die Zieledokumen-
tation.
Die Ziele müssen erreichbar sein. Zum Prozess der Zielsetzung gehört damit
auch die Umsetzbarkeitsprüfung. Die Umsetzbarkeit hängt vom Startpunkt ab.
Für den Projekterfolg kann es zwei Hindernisse geben. Einmal kann der man-
gelnde Reifegrad des Unternehmens zu Fehlentscheidungen und Projekt-
hemmnissen führen. Der Reifegrad des Unternehmens ist eine nur sehr schwer
messbare Eigenschaft. Zum anderen kann die Konfliktsituation zwischen per-
sönlicher Zielsetzung und Zielsetzung der Unternehmung zum Stillstand des
Projekts führen.
Ziele einer Zieleliste können schon in sich logisch widersprüchlich sein, sich
gegenseitig ausschließen, im Konflikt zueinander stehen. Die Zieleliste bedarf
dann einer Aufhebung der im Konflikt stehenden Ziele, einer Zielkonfliktberei-
nigung.
Zusammengefasst müssen Ziele folgende Eigenschaften erfüllen:
✔ Definiertheit, Nachvollziehbarkeit, Dokumentiertheit
✔ Verfolgbarkeit, Überprüfbarkeit, Messbarkeit
✔ Widerspruchsfreiheit
✔ Konfliktfreiheit
✔ Erreichbarkeit
✔ Umsetzbarkeit

Gestaltungsraum und Lösungswege


Der Gestaltungsraum ist die Analyse der Zielesituation (Konflikt oder nicht)
und die Feststellung der Reife für ein Data Warehouse Projekt bzw. der Voraus-
setzungen für eine erfolgreiche Abwicklung.
Kapitel 1 • Orientierung zum Thema Data Warehouse 71

Der Gestaltungsvorgang der Zielsetzung umfasst daher mit dem vorher Gesag-
ten die Arbeitsschritte
➢ Findung von Zielen
➢ Definition der Zielsetzung
➢ Bereinigung der Zielkonflikte
➢ Dokumentation der vereinbarten Ziele
Problemlösung: Regeln und Hilfsmittel
Das Verfahren
Die Zielsetzung wird also in zwei Schritten erreicht. Zunächst wird die allge-
meine persönliche Zieleliste aufgestellt und im zweiten Schritt wird ein beson-
deres Ziel, das Qualifikationsziel, detailliert herausgearbeitet. Der Projekterfolg
ist ganz erheblich von der Qualifikation der Mitarbeiter und deren Lernbe-
reitschft abhängig. Deshalb wird dem Ziel »Höherqualifizierung« besondere
Aufmerksamkeit gewidmet.

Verfahren: Persönliche Zielsetzung


❖ Zielfindung mit Kreativitätsmethoden
❖ Definition der Ziele, Dokumentation der Ziele in der Zieleliste mit einer
Begründung mittels der Checkliste persönliche Ziele
❖ Eintragung der zukünftigen Tätigkeiten in das Kenntnisprofil
❖ Beurteilung der Erreichbarkeit, der Machbarkeit der Ziele, Streichung
der nicht erreichbaren Ziele
❖ Abgleich der inneren Zielkonflikte
❖ Prüfung der Messbarkeit der Ziele

Checkliste persönliche Ziele


Um die Weiterbewegung im Projekt feststellen zu können, müssen Status erho-
ben werden; der Startpunkt des Projekts wird durch eine Zwischenbeurteilung
bzw. einen Zwischenstatus mit den gesetzten Zielen verglichen, um deren
Annäherungsgrad festzustellen. Für die allgemeinen persönlichen Ziele ist die
Checkliste persönliche Ziele bezüglich eines DV-Vorhabens nützlich.
Die Zielfindung ist ein kreativer Prozess. Die Methoden hierfür sind moderier-
tes Gespräch und Kreativitätsmethoden wie Mindmapping, morphologische
Ableitung und andere. Zur Vertiefung sei auf die Literatur wie zum Beispiel


Nagel, Brauchlin verwiesen.


Nagel, 200 Strategien
Brauchlin, Problemlösung
72 Kapitel 1 • Orientierung zum Thema Data Warehouse

Nr. Ziel Begründung Priorität

1 Vervollständigen des Kenntnisstands

2 Aufbauen der Führungsfähigkeiten

3 Erlernen der Budgetschätzung

4 Kennenlernen der Projektmanagement-Mittel

5 Kennenlernen eines Vorgehensmodells

6 Steigerung des Ansehens

7 Kommunikation mit Mitarbeitern des Unternehmens

8 Übung in Präsentationen

9 Erreichen einer weiteren Karrierestufe

10 Kennen lernen neuer Methoden

11 Übernahme von Verantwortung

12 Gewinnen eines Literaturüberblicks

13 Korrektur einer DV-Strategie

14 Erlernen des Grundwortschatzes

15 Ausbildungsplanung für Teamaufbau

16 Definition des Projektplans

17 Erfahrungsaustausch mit Seminarmitgliedern

18 Aufbau eines Projektteams

19 Erarbeitung von Stellenanzeigen

20 Erstellung eines konkreten Projektbudgets

21 Erstellung einer Vorstands- oder Aufsichtsratsvorlage

22 Aufbau eines Systems für Technologiemonitoring

Tabelle 1.15: Checkliste persönliche Ziele

Mittel und Methode zur Festlegung und laufenden Überprüfung des Fort-
schritts nach jedem Seminarabschnitt ist die persönliche Zieleliste. Die Ziele
müssen aber auch überprüfbar formuliert werden. Nicht überprüfbar ist z.B.
Wissensgewinn, bessere Orientierung oder verbesserter Überblick aufgrund der
zu großen Allgemeinheit der Formulierung. Für die Prüfung der Wider-
spruchsfreiheit hilft nur logisches Denkvermögen.
Qualifikationsziel
Die Erreichbarkeit der Qualifikationsziele hängt, wie bereits dargestellt, auch
vom persönlichen Kenntnisstand ab. Dieser Ausgangszustand, die augenblickli-
che Qualifikation, der Wissenstand wurde im Kenntnisprofil dargestellt.
Für die Auseinandersetzung mit einem neuen Gegenstand muss zunächst ein
entsprechendes Wissen aufgebaut werden. Dies muss als persönliche Ziel-
Kapitel 1 • Orientierung zum Thema Data Warehouse 73

setzung zur Qualifikation als zweite Kurve in dem bereits für den Qualifikati-
onsstatus verwendeten Kenntnisprofil festgehalten werden. So kann zum Bei-
spiel ein Ziel darin bestehen, dass im Kenntnisprofil zu einem Eintrag »keine
Kenntnis« bezüglich Zeile »Data Warehouse » ein Eintrag »Projektierung«
gesellt wird. Neben diesem Ziel, das z.B. Jahresziel sein kann, kann dann noch
eine weitere Kurve mit der Kennzeichnung »Konzeption« oder sogar »Betrieb«
als Fernziel eingetragen werden. Das Kenntnisprofil kann für die drei Kurven
✔ der Qualifikationsstatus als Qualifikations-Ist-Kurve
✔ das Qualifikationssoll als Qualifikationszielkurve
✔ das Jahresqualifikationsziel in einer Jahresqualifikationszielkurve
verwendet werden.
Mittels der Zielkurve kann der Abstand zur Statuskurve, das Kenntnisprofil,
gemessen werden. Die Differenzen entsprechen dem Ausbildungs- und Praxis-
bedarf.

1.3.3 Die Zielsetzung des Unternehmens


Problemstellung und Motivation
Bevor ein Data Warehouse Projekt gestartet wird, muss natürlich auch für das
Unternehmen erst einmal klar sein, wohin das Projekt führen soll. Genauer, es
muss klar sein, welche Ziele für das Unternehmen, das ja viel Geld dafür aus-
gibt, erreicht werden sollen, und im zweiten Schritt, ob diese überhaupt
erreicht werden können.
Was sind die Ziele eines Unternehmens und wie äußern sich diese? Ein Unter-
nehmen kann man nicht befragen. Aber ein Vertreter des Unternehmens mit
Budgetkompetenz vergibt ja den Auftrag, ein Data Warehouse aufzubauen und
zu betreiben. Diese interne Beauftragung ist Ziel und Wille des Unternehmens.
Unternehmen formulieren oft zur Ausrichtung des Handelns und der inneren
Einstellung ihrer Mitarbeiter untereinander und gegenüber Kunden und
Öffentlichkeit eine Unternehmensphilosophie. Die Unternehmensphilosophie
ist der Rahmen für eine Unternehmenspolitik. Mit einer Unternehmenspolitik
werden die allgemeinen Unternehmensziele verfolgt. Die Unternehmenspolitik
ist oft in Leitfäden, die auch den Kunden ausgehändigt werden, ausgeführt. In
der Unternehmenspolitik ist oftmals dargestellt, welche Interessentengruppen
die unternehmerische Tätigkeit auf welche Weise zufriedenzustellen sucht. Das
folgende Beispiel »Unternehmensphilosophie: Integrata-Gruppe« soll dies
unterstreichen (siehe Abbildung 1.7).
Eine andere aufschlussreiche Quelle kann auch ein Unternehmenskodex sein,
in dem das Verhalten der Unternehmensmitglieder untereinander und auch
nach außen, zum Beispiel gegenüber Kunden, definiert ist. Ein Projekt muss
sich im Rahmen des Unternehmenskodex bewegen.
74 Kapitel 1 • Orientierung zum Thema Data Warehouse

Abbildung 1.7: Beispiel einer Unternehmensphilosophie: Integrata-Gruppe

Neben den Zielen des Unternehmens und der zuständigen Abteilungen hat das
Projekt selbst auch Ziele, die Projektziele. Die Projektziele sind den Unterneh-
menszielen untergeordnet. Sie müssen mit den Unternehmenszielen harmo-
nieren. Sie sind eine Verfeinerung der Unternehmensziele und als solche wie-
der Unternehmensziele. Sie müssen vom Projektleiter in das Projektteam
kommuniziert werden.
Das Beispiel »Unternehmenszielsetzung: Zieldreieck der Integrata-Gruppe«
stellt einen Interessen-Tripol in den Mittelpunkt der Unternehmenszielsetzung.
Die Zielsetzung des Unternehmens richtet sich aus
✔ auf die Zufriedenheit der Kunden mit den Leistungen des Unternehmens
✔ auf die Versorgung der Mitarbeiter als soziale Aufgabe des Unternehmens
✔ auf die Erfüllung der Vorstellung der Gesellschafter zur wirtschaftlichen
Zielsetzung
Kapitel 1 • Orientierung zum Thema Data Warehouse 75

Abbildung 1.8: Beispiel einer Unternehmenszielsetzung: Zieldreieck der Integrata-Gruppe

Nur wenn persönliche Ziele und Unternehmensziele zusammenpassen, kann


ein Projekt reibungslos und effizient durchgeführt und erfolgreich beendet
werden.

Gestaltungsraum und Lösungswege


Aus der Unternehmenssicht werden die Ziele nicht gestaltet – sie sind ja schon
in irgendeiner Weise vorhanden –, sondern sie sind in Erfahrung zu bringen.
Der Gestaltungsraum, in dem man sich hierbei bewegen muss, ist also die Wahl
der Mittel, diese Ziele zusammenzutragen. Die Logik der Gestaltung der Ziel-
setzung und ihrer Erhebung wurde schon beim Thema »persönliche Ziele« dar-
gestellt.
Das heißt, dass die Ziele des Unternehmens bezüglich eines Data Warehouse
Projekts festgelegt und nachvollziehbar dokumentiert werden müssen. Das
heißt auch, dass die Dokumentation so genau sein muss, dass eine Verfolgung
im Laufe des Projekts möglich ist.
➢ Feststellung der Ziele des Unternehmens und der beteiligten Organisations-
einheiten
76 Kapitel 1 • Orientierung zum Thema Data Warehouse

Die Projektziele sind den privaten Zielen übergeordnet. Sie müssen mit den
privaten Zielen der Projektteilnehmer harmonieren. Der Gestaltungsraum defi-
niert sich hierbei in der Wahl der Mittel zur Überprüfung der Konfliktfreiheit.
➢ Feststellung der Zielkonflikte der beteiligten Organisationseinheiten und
Personen

Problemlösung: Regeln und Hilfsmittel


Das Verfahren
Es ist nicht beabsichtigt, hier eine Methode zur Ableitung von Firmenzielen
vorzustellen. Es sei nur noch einmal verdeutlicht, dass es ohne Zielsetzung
nicht geht. Das Ziel des Abschnitts ist es, die Erhebung der Firmenziele und die
Beurteilung, soweit sie für das Data Warehouse erforderlich sind, methodisch
zu unterstützen. Hierbei kann man dem folgendem Verfahren folgen.

Verfahren: Definition der Unternehmensziele


❖ Erstellung der Zieleliste mit einer nachvollziehbaren Begründung mittels
der Checkliste Firmenziele
❖ Zielebereiningung
Beurteilung der Erreichbarkeit der Ziele, Streichung der nicht erreichba-
ren Ziele
Abgleich der inneren Zielkonflikte
Beurteilung der Definiertheit, Messbarkeit und Verfolgbarkeit
❖ Erstellung der Zieleharmoniematrix

Checkliste Firmenziele
Die Firmenziele entdeckt man unter anderem im Jahresbericht der Firma, in
Aushängen am schwarzen Brett, in Pressemitteilungen, in Vorträgen der
Geschäftsführung, in einem Firmenkodex, in der Unternehmenspolitik. Dies
weist auf die bereits behandelte Problematik der Informationsfindung hin und
wird nicht weiter erörtert.
Bleibt noch zu definieren, mit welcher Methode die aus den Informationsquel-
len abgeleiteten Ziele zu dokumentieren sind. Der hier vorgestellte Vorschlag
ist die Checkliste Firmenziele, die die Projektziele bereits umfasst. Zur Orien-
tierung wurden einige aus der Praxis bekannte Ziele eingetragen, die es im rea-
len Projekt noch einmal zu prüfen, zu kürzen und auch zu ergänzen gilt (siehe
Tabelle 1.16).
Zieleharmoniematrix
Für die kritische Prüfung der Harmonie zwischen Firmenzielen und Privatzie-
len ist hier eine Zieleharmoniematrix ausgewählt worden, da ja jedes Privatziel
gegen jedes Firmenziel diskutiert werden muss. Die Anwendung ist einfach, es
ist jedes Feld der Matrix mit einem Urteilskennzeichen entsprechend der eige-
nen Einschätzung zu versehen (siehe Tabelle 1.17).
Kapitel 1 • Orientierung zum Thema Data Warehouse 77

Nr. Ziel Relevanz für Data Warehouse

1 Kostenreduktion für Prozess xxx Kostenrechnung

2 Verkürzung der Servicezeiten für xxx

3 Kundenanalyse Kundendaten, Marktdaten,


Mitbewerberdaten

4 Technologieeinstieg

5 Erfahrungen sammeln durch Pilotprojekt

6 Know-how-Aufbau Know-how-Profil

7 Entwicklung Data-Warehouse-Produkt

8 Verbesserung Kundenauskünfte Kundendaten

9 Bereinigung Produktefeld Produktbeziehungsdaten,


Absatzlebenslauf

Tabelle 1.16: Checkliste Firmenziele

Privatziele
Unternehmenziele 1 2 3 4 5 6 7 8 9 10 11
Kostenreduktion für Prozess xxx
Verkürzung der Servicezeiten für xxx
Kundenanalyse
Technologieeinstieg
Erfahrungen sammeln durch Pilotprojekt
Know-how-Aufbau
Entwicklung Data Warehouse Produkt
Verbesserung Kundenauskünfte
Bereinigung Produktefeld

Tabelle 1.17: Muster Zieleharmoniematrix

Bei großen Projekten ist das Risiko, aufgrund einer Zieldisharmonie in Schief-
lage zu geraten, groß. Die Einschätzung sollte deshalb von der Projektleitung
durchgeführt werden. Ebenso ist die Beurteilung der Startqualifikation eine
Aufgabe der Projektleitung.

1.3.4 Die kritischen Erfolgsfaktoren


Problemstellung und Motivation
Die Übereinstimmung von Unternehmenszielen mit persönlichen Zielen, wie in
der Übersicht am Anfang dieses Buches dargestellt, ist eine wichtige Bedingung
für den Projekterfolg. Wo eine Zielvorstellung umgesetzt werden soll, ist eine
detaillierte, kritische Betrachtung der Erreichbarkeit nötig. Das heißt, beglei-
tend zur Betrachtung der Ziele müssen die Risiken des Vorhabens Data Ware-
house Aufbau abgeschätzt werden. Man nennt diese Risiken die kritischen
Erfolgsfaktoren, kurz KEF.
78 Kapitel 1 • Orientierung zum Thema Data Warehouse

Einige dieser kritischen Erfolgsfaktoren sind mit weiteren Mitteln detaillierter


zu betrachten. Dies ist zum Beispiel die EDV-Bedarfslage des Unternehmens.
Diese wird gewöhnlich in einer Ist-Erhebung der EDV-Ausstattung erfasst, den
Bedarfsanforderungen der Anwender gegenübergestellt, bewertet und zu einem
EDV-Maßnahmenplan ausgearbeitet. Ein kritischer Erfolgsfaktor ist die Bereit-
schaft, bei Bedarf in die EDV-Ausstattung zu investieren.
➡ KEF: Ausreichendes flexibles Budget
Das Data Warehouse Projekt zieht große Kreise im Unternehmen und hat nicht
nur Freunde und Helfer, sondern auch Neider und Bedenkenträger. Ein neues
Vorhaben wird immer von einem Teil des Unternehmens als Chance und von
einem anderen Teil der Unternehmerschaft als Gefahr gesehen. Ein neues Vor-
haben erzeugt große Widerstände, gegen die es sich mit Erfolgen zu behaupten
gilt. Die besten Erfolge sind nutzlos, wenn die Führungsebene zerstritten ist
und das auch noch in die unteren Ebenen kommuniziert. Ein K.o.-Kriterium
ist zum Beispiel mangelnde Rückendeckung aus der Führungsetage. Ein wich-
tiger Erfolgsfaktor, vielleicht der kritischste überhaupt, ist die Ernennung eines
Vorstandssponsors.
➡ KEF: Ernennung eines Vorstandssponsors
Ein Projekt ist in Bewegung, macht im Laufe der Zeit Fortschritte, aber mitun-
ter auch Rückschritte. Ohne Führung verändert sich ein Projekt willkürlich
oder tritt auf der Stelle. Die Projektmitarbeiter bedürfen der kontinuierlichen
Pflege und der Organisation ihrer Weiterentwicklung. Ein Projekt muss nach
außen in die Unternehmensumwelt kommuniziert werden. Zusammengefasst
heißt das, ein Projekt vom Umfang eines Data Warehouse erfordert die Freistel-
lung eines Projektleiters vom Tagesgeschäft.
➡ KEF: Freistellung eines Projektleiters
Zur Beurteilung der Fortschrittslage ist in angemessenen Abständen ein Pro-
jektstatus festzustellen. Der Projektstatus wird an der Zielsetzung gemessen,
das heißt, es wird geprüft, ob das Projekt noch fähig ist, die gesetzten Ziele zu
erreichen. Die Methodik der Projektverfolgung eines Data Warehouse Vorha-
bens wird in Kapitel 8 »Die Projektierung von Data Warehouse Systemen« aus-
gearbeitet. Das Vorhaben muss verfolgt werden können. Hierzu ist ein Berichts-
wesen erforderlich und die Bereitschaft, dieses auch einzusetzen.
➡ KEF: Etablierung eines Projektberichtswesen
Jeder Projektteilnehmer ist in ein Kunden-Lieferanten-Verhältnis eingebunden.
Einige Projektteilnehmer erzeugen Ergebnisse, die andere Projektteilnehmer
verarbeiten müssen. Die Lieferanten der Ergebnisse müssen eine Bringschuld
spüren und ein Qualitätsbewusstsein entwickeln für die Qualität der Weiterver-
arbeitung.
➡ KEF: Etablierung eines Kunden-Lieferanten-Denkens im Projekt und für
die Anwender
Kapitel 1 • Orientierung zum Thema Data Warehouse 79

Jeder Angestellte einer Firma hat private Ziele. Diese Ziele müssen nicht immer
die Ziele der Firma sein. Doch die Firmenziele sollen Vorrang haben. Ein desin-
teressierter oder überforderter Data Warehouse Projektleiter wird das Projekt
»Aufbau eines unternehmensweiten Data Warehouse« nicht realisieren kön-
nen. Sollten Firmenziele und eigene Zielsetzung absolut nicht zusammenpas-
sen, kann das nur die Zuteilung der Aufgabe zugunsten einer anderen Person
bedeuten. Ein kritischer Erfolgsfaktor ist damit die Verträglichkeit der privaten
Ziele mit den Firmenzielen.
➡ KEF: Harmonie zwischen privaten Zielen und Projektzielen
➡ KEF: Qualifikationslevel und Lernbereitschaft
Hier sei noch einmal verdeutlicht, dass es Widerstände zu besänftigen gilt, dass
die »Neinsager« positiv überzeugt werden müssen, dass Projekterfolge bekannt
werden müssen. Hierfür ist eine Kommunikationsplattform und die Erlaubnis,
diese für das Projekt einsetzen zu dürfen, erforderlich. Solche Kommunikati-
onsmöglichkeiten sind zum Beispiel Artikel in der Hauszeitschrift, schwarzes
Brett, Mailings, Intranetseite, interne Präsentationen für zukünftige Anwender
und für die Führungsbene.
➡ KEF: Kommunikationsmöglichkeit der Projektergebnisse
Ein DWH kann nur das auswerten, was in Datenbeständen verfügbar ist.
Abschottung von Datenbeständen, schlecht gepflegte, unvollständige Daten-
sammlungen kann das beste DWH nicht ausgleichen.
➡ KEF: Datenqualität
Know-how-Level, Kultur und Bereitschaft, neue Projekte durchzuführen, sind
Nährboden oder Risiken. Nur wenn beide Faktoren
✔ Zielsetzung ist sinnvoll
✔ Startposition ist aussichtsreich
zusammenpassen, kann man von der Durchführbarkeit eines Vorhabens ausge-
hen.

Gestaltungsraum und Lösungswege


Neben der Erhebung der Ziele ist, wie bereits angekündigt, noch eine weitere
Erhebung erforderlich, nämlich die Erhebung der Risikolage des Unterneh-
mens, die Unternehmensdisposition bezüglich des Data Warehouse Vorhabens.
Hierfür hat sich das Aufspüren der bereits genannten »kritischen Erfolgsfakto-
ren« (KEF) bewährt. Es gibt bereits Übersichten zu solchen KEF, die in den ver-
schiedenen Quellen aufgespürt werden müssen. Die Gestaltungsaufgabe, die
sich daraus ergibt, ist die Erhebung des Unternehmensstatus bezüglich der
Erfolgsaussichten des Data Warehouse Vorhabens.
➢ Aufstellung der kritischen Erfolgsfaktoren des DWH-Vorhabens
80 Kapitel 1 • Orientierung zum Thema Data Warehouse

Problemlösung: Regeln und Hilfsmittel


Das Verfahren
Nicht jedes Unternehmen ist disponiert für einen erfolgreichen Weg zu einem
Data Warehouse. Als Methode zur Feststellung des Unternehmensstartpunkts
bezüglich des Data Warehouse Projekts sind eine »Checkliste kritische Erfolgs-
faktoren« und die EDV-Bedarfsanalyse ausreichend. Das folgende Verfahren ist
hierfür anwendbar:

Verfahren: Kritische Erfolgsfaktoren


❖ Aufstellung der Liste der kritischen Erfolgsfaktoren
mittels Recherche in Literatur und vorhandenen Projektabschlussberichten
mit Hilfe von Kreativitätstechniken wie Mindmapping
mittels der Checkliste kritische Erfolgsfaktoren
❖ Prüfen der Erfolgsvoraussetzungen mittels der Liste der kritischen
Erfolgsfaktoren
❖ Entscheiden, ob Abbruchkriterium enthalten ist

Checkliste kritische Erfolgsfaktoren


Wird die Checkliste mit einem Ausprägungsgrad der Checkpositionen ausge-
stattet, liegt ein Reifeprofil kritische Erfolgsfaktoren des Unternehmens vor.
Bei der Suche nach KEF können die Erklärungen des vorangegangenen
Abschnitts verwendet werden. Für die weiteren Betrachtungen genügt es, die
Checkliste zu besprechen (siehe Tabelle 1.18).
Kritische Erfolgsfaktoren werden aus vergangenen Projekten und aus der prog-
nostischen Betrachtung, was so alles im Projekt passieren kann, erkannt. Das
heißt, dass jedes Projekt einer Nachbetrachtung inklusive einer Know-how-
Sicherung bedarf, um diese Erkenntnisse im Laufe der Zeit nicht in Vergessen-
heit geraten zu lassen.
Für die Dokumentation der Erkenntnisse eignet sich der in Kapitel 8 »Projek-
tierung« besprochene Projektabschlussbericht. Auch andere Unternehmungen
haben Erfahrungen gemacht, sind oft gerne bereit, über diese zu berichten, und
damit eine gute Informationsquelle. Für den Vergleich mit Erfahrungen ande-
rer Unternehmen ist wieder der Weg über die bereits besprochene Informati-
onsrecherche erforderlich.
Das prognostische Durchspielen des Projektverlaufes ist ein kreativer Prozess.
Hierfür werden gerne hier nicht weiter behandelte Kreativitätstechniken einge-
setzt. Zur Vertiefung soll nur auf eine beliebte Methode, das Mindmapping, und
eine weniger bekannte Methode aus den Ingenieurswissenschaften, den mor-
phologischen Kasten, hingewiesen werden. Näheres hierzu ist zu finden in:
 Brauchlin, Problemlösung
Kapitel 1 • Orientierung zum Thema Data Warehouse 81

Nr. Erfolgsfaktor Firmenzustand

Vorstandssponsor engagiert, erkennbar, still, nicht vorhanden

Vorstandsprojekt erklärt, nicht erklärt

Lenkungsausschuss aktiv, vorhanden, nicht vorhanden

Budget zu klein, erweiterbar, ausreichend

Projektleiter hauptamtlich, ernannt, nicht möglich

Projektteam freigegeben, definiert, zu klein, nicht vorhanden

Fach-Know-how-Träger erreichbar, verfügbar, desinteressiert

Equipment modern, vorhanden, beschaffbar

Entwurfswerkzeuge vorhanden, nicht vorhanden

Datenbasis 1 gepflegt, ungepflegt, leer

Datenbasis 2 integriert, isoliert

Methodik Vorgehensmodell, Einzelmethoden, ohne

IT-Know-how vollständig, unvollständig, Neuland

Projektberichtswesen etabliert, definiert, ohne

Lernbereitschaft ernsthaft, mangelhaft, null

Tabelle 1.18: Checkliste kritische Erfolgsfaktoren

1.3.5 Die Aufgaben des Data Warehouse Spezialisten


Aus den Erkenntnissen über die Kategorisierung des Themas DWH und den
Produkttyp, sowie über die Grundstruktur eines Data Warehouse Projekts kann
man schon eine Bestandsaufnahme zu den Aufgaben des Data Warehouse Spe-
zialisten gewinnen.

Exkurs: Qualifikation zum Data Warehouse Spezialist


Der Aufbau eines Data Warehouse ist ein umfangreiches Projekt, das von der
Ideenkonsolidierung zu einer Projektdefinition, von der Beschaffung bis zur
Eigenentwicklung annähernd alles enthält, was jedes andere EDV-Projekt
auch enthält. Das Zusammenspiel dieser Projektaktivitäten muss geführt
werden. Das bedeutet, dass ein Data Warehouse Manager die Kenntnisse und
Fähigkeiten eines Projektleiters haben muss.
✔ Projektmanagement: Projektcontrolling, Budgetierung, Teamführung
82 Kapitel 1 • Orientierung zum Thema Data Warehouse

In einem Data Warehouse ist fachliches Wissen abgebildet. Dieses Wissen muss
allerdings erst in den Fachabteilungen ermittelt werden. Die Fachleute müssen
motiviert werden, ihr Wissen preiszugeben und dokumentieren zu lassen. Das
ist nicht immer einfach, da dieses Wissen ihren Arbeitsplatz sichert. Wenn diese
Fachleute ihr Wissen in einem EDV-System verwirklicht sehen, werden sie
Ängste entwickeln, ihre Arbeitsleistung messbar zu machen und ersetzbar zu
sein. Sie bangen um ihre Existenzgrundlage, ihren Arbeitsplatz. Der Data
Warehouse Manager muss sich also in die Lage seiner Interviewpartner ver-
setzen können und sie zur Mitarbeit motivieren können. Dies sind sehr hohe
Ansprüche an die kommunikativen Fähigkeiten und die soziale Kompetenz.
✔ Systemanalyse: Kommunikation, Sozialkompetenz, Präsentation, Statu-
serhebung, Wissensakquisition, Fachkonzeption
Das Ergebnis eines Data Warehouse ist ein aus Hardware- und Softwarekom-
ponenten zusammengesetztes System, das über eine IT-Infrastruktur, wie
zum Beispiel öffentliche Netze oder Firmennetze, kommuniziert. Die Soft-
warekomponenten werden entsprechend der Fachkonzeption definiert und
gekauft oder selbst entwickelt. Kaufentscheidungen erfordern eine Marktbe-
trachtung auf der Basis einer Kriterienliste. Selbst bei einem Kauf werden
noch Anpassungsarbeiten erforderlich sein. Anpassungsarbeiten, Eigenent-
wicklung wie auch die Beschaffungskriterien müssen in einer Spezifikation
von Hardware und Software fixiert werden. Der Data Warehouse Manager
muss daher Kenntnisse über das Arbeitsfeld des Systemingenieurs besitzen.
✔ Systemengineering: Spezifikation von Hardware- und Softwarekompo-
nenten, Netzkenntnisse, Beschaffung, Evaluation, Schnittstellendefinition
Die spezifizierten Komponenten werden programmiert oder beschafft. Die
selbstentwickelten Programme müssen unter Ausschluss der Öffentlichkeit
getestet, korrigiert und wie auch die gekauften Programme in die bestehende
EDV integriert werden. Der Anwender wird eine Testphase mit Verbesserungs-
vorschlägen begleiten. Es ist nicht wünschenswert, einem Data Warehouse
Manager bei der Vielfalt seiner Anforderungen auch noch Programmierarbei-
ten (C, C++, 4GL, SQL, ...) abzuverlangen. Er muss allerdings selbst das Data
Warehouse anwenden können, und dazu gehören die Enduser-Programmier-
arbeiten mit einer Makrosprache bzw. mit programmierfreien Tools.
✔ Realisierung: Customizing, Reporterstellung, Datennavigation
Das fertige System wird dann für den Betrieb freigegeben und Wartungsar-
beiten und Auskunftsdienste stehen an. In dieser Phase muss der Data Ware-
house Manager den Systembetrieb, die Anrufung der Herstellerservices und
die Anwenderbetreuung beherrschen.
✔ Betrieb: Systemadministration, Helpdesk, Datenbankadministration,
Hardwareservice, Tuning

Die Rolle eines Data Warehouse Spezialisten ist also eine Vereinigung mehrerer
Rollen. Wie tief das Wissen, wie gut die Fertigkeit im Umgang mit diesen Rollen
sein muss, ist von Unternehmen zu Unternehmen, von Projekt zu Projekt ver-
schieden. Genauer wird dies in Kapitel 6 »Organisation« behandelt.
Kapitel 1 • Orientierung zum Thema Data Warehouse 83

1.3.6 Fortsetzungsbeispiel InDaWa


Einleitung
Nach der Bestimmung der Abgrenzung des im Beispielprojekt zu bearbeitenden
Themas, durch grundsätzliche Kategoriebestimmung und Bestimmung des
Produkttyps, folgt nun die Zielsetzung.

Beispiel
Für das Beispielprojekt ist die Zielsetzung des Unternehmens – es handelt sich
um ein Stromversorgungsunternehmen mit mehreren Kraftwerken – von
Bedeutung. Der Betreiber beabsichtigt, einen Auftrag für ein umfassendes Aus-
wertungssystem von Instandhaltungsdaten zu vergeben. Jedes Kraftwerk ist ein
betriebswirtschaftliches Unternehmen, das heißt, es muss unter dem optimalen
Einsatz von Ressourcen einen Output, in diesem Falle Strom, erzeugen. Durch
technologische Neuerungen in Bauteilen, Komponenten, durch Qualifizierung
von Mitarbeitern, Verbesserung von Arbeitsprozessen, Verkürzung von Still-
standszeiten kann der Ressourceneinsatz ständig optimiert werden. Hierzu ist
allerdings eine größere Transparenz der Produktionsfaktoren des Gesamtsys-
tems erforderlich. Ein großer Kostenfaktor davon ist die Instandhaltung.

Beispiel: Ziele des Kraftwerkbetreibers


Übergreifendes Ziel des Kraftwerkbetreibers ist es, ein EDV-System zu entwi-
kkeln zur Analyse der Prozesse und der eingesetzten Ressourcen wie Perso-
nal, Bauteile, Anlagenteile, Zeiten, mit einem detaillierten und aggregierten
Berichtswesen und einer Frühwarnkomponente für Systemausfälle.

Nr. Ziel Relevanz für Data Warehouse

1 Potential der Kostenreduktion für Transparenz der Kostenentstehung, detail-


Instandhaltungsprozesse eruieren lierte Aufzeichnung über alle Kraftwerke
genormt

2 Verkürzung der Bearbeitungszeiten für Zeitaufzeichnung von Reparaturarbeiten


Reparaturaufträge und Genehmigungsprozessen

3 Kostenanalyse bei Fremdvergabe von Unterscheidung zwischen internen und


Reparaturaufträgen externen Kosten

4 Kostenvergleich gleicher Reparaturen Unterscheidung zwischen Regionen und


verschiedener Kraftwerke Kraftwerkstypen

5 Verkürzung der Stillstandszeit bei Kraft- Detaillierte Ablaufanalyse bezüglich Arbei-


werksrevisionen ten-Parallelisierung und Verzögerungen

6 Prognosen von Anlagenausfällen Indikatorensammlung und Interpretation


für Ausfälle

7 Erfahrungen sammeln durch Pilotprojekt Start mit einem horizontalen Ausschnitt,


da keine Erfahrung mit neuen EDV-
Technologien

8 Know-how-Aufbau und eventuell Konzeption mit Wiederverwendbarkeit der


Produktentwicklung, da Partner- Module und Einsetzbarkeit für Partner-
unternehmen Interesse zeigen unternehmen

Tabelle 1.19: Checkliste Ziele des Kraftwerbetreibers


84 Kapitel 1 • Orientierung zum Thema Data Warehouse

Als kritische Erfolgsfaktoren sieht man die Dauer des Projekts an.
Die Datensammlung ist vollständig und detailliert. Personelle Interessen-
konflikte sind nicht zu befürchten. Die Budgetierung des Projekts ist unge-
fährdet, da alle Verbesserungen unmittelbare Kosteneinsparungen bei
Instandhaltungskosten haben. Ein Vorstandsmitglied ist nicht erforderlich,
das Sponsoring übernimmt der Instandhaltungsleiter.

Zu diesem Zeitpunkt ist der gesamte Umfang des Projekts noch nicht bekannt
und deshalb kann noch kein einigermaßen stabiler Projektumfang definiert
werden. Aber der Wille kann mit der Zieldefinition dargestellt werden. Die Ziel-
definition ist die Voraussetzung für ein Commitment der Entscheidungsebene:
»Jawohl, wir sehen diese Ziele genauso, hätten aber gerne noch diese und jene
Korrektur und stellen dafür erst einmal ein Budget von xxx Euro zur Verfü-
gung.«
Die Hauptzielsetzung ist, ein »Projekt zum Aufbau und Betrieb eines Data
Warehouse« abzuwickeln. Um die Möglichkeit des Abbrechens überhaupt zu
bekommen, wird ein Projekt in Abschnitte eingeteilt, die Phasen genannt wer-
den, wie bereits im Exkurs »Projektphasen« dargestellt wurde.

Beispiel: Projektphasen
Der »Rahmenplan des Projekts«, der noch keine für ein Data Warehouse spe-
zifischen Schritte enthält, soll die allseits bewährten Projektstrukturen aus
Individualentwicklung, Standardsoftwareprojekten und Infrastrukturvorha-
ben aufnehmen. Im Einzelnen sind dies also die im Exkurs »Projektphasen«
aufgezählten Phasen:
✔ Projektinitiation und Projektierung
✔ Anforderungsanalyse
✔ Konzeption
✔ Spezifikation
✔ Realisierung
✔ Betrieb
Es gibt derzeit im Kraftwerksunternehmen kein Vorgehensmodells für die
Softwareentwicklung. Deshalb muss mit dem Projektstart eine Ausarbeitung
der Phaseninhalte im Rahmen eines schlanken »Vorgehensmodells« durch-
geführt werden.
✔ Vorgehensmodell
Der Gegenstand des Vorgehensmodells wird mit den Architekturentschei-
dungen des Data Warehouse bestimmt. Das bedeutet für die Projektfort-
schrittsskala, dass vor dem Schritt »Vorgehensmodell« ein Schritt »Architek-
turabgrenzung« erfolgen muss.
Kapitel 1 • Orientierung zum Thema Data Warehouse 85

✔ Architektur
Vor diesen Strukturfestlegungen wird das eigentliche Data Warehouse Pro-
jekt mit den bekannten Aufgaben von Softwareprojekten projektiert.

Gestaltungsentscheidungen
Mit diesen Festlegungen sind zwar keine Gestaltungsentscheidungen getroffen
worden, aber die weiteren Projektschritte definiert, und diese können als wei-
tere Skaleneinträge des Projektfortschritts festgehalten werden.
Alle Entscheidungen der noch folgenden Kapitel zum Beispielprojekt InDaWa
werden weiterhin musterhaft in dem vorgestellten Entscheidungschart
»Gestaltungsentscheidungen und Projektfortschritt InDaWa« festgehalten. Das
Entscheidungschart ist eine Checkliste mit Gestaltungsaspekten, der zugehöri-
gen Entscheidung und einer Begründung dieser Entscheidung. Mit Hilfe des
Entscheidungscharts bleiben die Entscheidungen langfristig nachvollziehbar
und können bei Veränderungen von Rahmenbedingungen gezielt auf weiteren
Bestand geprüft werden. Die Verwendung einer solchen Entscheidungsdoku-
mentation ist jedem Projekt anzuraten.

Gestaltungsaspekt Entscheidung Begründung

ORIENTIERUNG

Abgrenzung

Markttendenzen

Zielsetzung

persönliche Ziele Data-Warehouse-Spezialist Verantwortung

Kenntnisstand Ausbildungskonzept erforderlich

Unternehmensziele Start mit Pilotprojekt Erfahrung nicht ausreichend

Unternehmensstatus Erfolgskriterien erfüllt


ARCHITEKTUR
...

Tabelle 1.20: Entscheidungschart InDaWa Zielsetzung

1.4 Übungen
Übung 1.1: Stellenbeschreibung
Leiten Sie aus der folgenden Stellenanzeige ab, zu welcher Kategorie der
Beschäftigungsgegenstand »Data Warehouse« nach Meinung des Inserenten
gehört und welchen Produkttyp er darin sieht.
86 Kapitel 1 • Orientierung zum Thema Data Warehouse

Abbildung 1.9: Stellenbeschreibung DWH-Leiter

Übung (mit Lösungsbeispiel) 1.2: Charakteristische Eigenschaft Systemtypen


Geben Sie jeweils den Begriff und eine charakteristische Eigenschaft für jeden
der in der folgenden Tabelle mit seinem Kürzel aufgeführten Systemtyp an:

Systemtyp Begriff Charakteristische Eigenschaft

MIS

OLAPS

DSS

XPS

Data Warehouse

EIS

Übung 1.3: Kategorienskala


Kategorisieren Sie das Thema Data Warehouse mit Hilfe der Kategorienskala.
Übung 1.4: Projektphasen
Was sind Projektphasen? Wie heißen die wichtigsten Projektphasen und welche
Aufgaben werden in diesen Projektphasen abgewickelt?
Übung 1.5: Maßnahmenplan Markteinschätzung
Bilden sie einen Maßnahmenplan zur Beobachtung und Einschätzung des
Marktes nach dem folgenden Schema:

Quelle Maßnahme Begründung


Kapitel 1 • Orientierung zum Thema Data Warehouse 87

Übung (mit Lösungsbeispiel) 1.6: Trendkarte Executive Information Systems


Erstellen Sie eine Trendkarte zur Technologie der Executive Information
Systems.
Übung 1.7: Trendprofil
Erstellen Sie ein Trendprofil (ohne Trends) der Ihrer Meinung nach für Ihr
Unternehmen relevanten Technologien.
Übung 1.8: Kenntnisstand
Zeichnen Sie Ihre Einschätzung Ihres derzeitigen Kenntnisstandes als Kurve in
das Formular für das Erkenntnisprofil ein.
Übung 1.9: Kenntnisstand-Fernziel
Zeichnen Sie Ihre Einschätzung Ihres angestrebten Kenntnisstand-Fernziels
durch eine zweite Kurve in das Formular für das Erkenntnisprofil ein.
Übung 1.10: Persönliche Ziele
Definieren Sie Ihre persönlichen Ziele, die Sie mit der Beschäftigung mit dem
Thema Data Warehouse verfolgen.
Übung 1.11: Unternehmensziele
Erstellen Sie eine Liste der Unternehmensziele, die Ihrer Meinung nach ein
Interview mit den Führungskräften bringen würde. Vergleichen Sie Ihre Ziele
mit den Firmenzielen: Sehen Sie Zielkonflikte? Tragen Sie die Konfliktein-
schätzung in die Felder Zieleharmoniematrix ein. Machen Sie zu jedem Konf-
likt einen Vorschlag, wie dieser zu beheben ist.
Übung 1.12: KEF
Stellen Sie die kritischen Erfolgsfaktoren (KEF) ihres Unternehmens fest.
Übung 1.13: Reifeprofil kritische Erfolgsfaktoren
Ergänzen sie das Formular Checkliste kritische Erfolgsfaktoren durch Ausprä-
gungsgrade zu einem »Reifeprofil kritische Erfolgsfaktoren«.

1.5 Zusammenfassung der Entscheidungsgänge


Zum Abschluss des Kapitels sei noch ein Blick auf die bisherigen Schritte
geworfen und zusammenfassend dargestellt.
Ausgangspunkt war die Orientierung, was »Data Warehouse« ist. Diese Orien-
tierung wurde in Teilschritten erreicht. Der erste Schritt bestand aus einer
quasi-philosophischen Kategorisierung des Themas.
88 Kapitel 1 • Orientierung zum Thema Data Warehouse

Mit Hilfe von in Zeitungsanzeigen veröffentlichten Darstellungen von Herstel-


lern wurde festgestellt, dass die Kategorie des Data Warehouse nicht durch ein
abstraktes Denkobjekt charakterisiert werden kann. Sie ist vielmehr ein kom-
plexes Gebilde aus Software- und Hardwarekomponenten und Organisation:
mehr real als ideell, sowohl Software als auch Hardware, eher komplex als sim-
pel, Mensch und Maschine im Wechselspiel.
Des weiteren wurde festgestellt, dass der Begriff Data Warehouse zwar neu ist,
aber die Produkte aus dem Umfeld der früher als Management-Unterstützungs-
systeme bezeichneten Informationssysteme kommen und teilweise nur um
neue Technologien erweitert wurden. Es wurde gefolgert, dass alle Komponen-
ten dieser Produkte gewissen Technologietendenzen unterliegen und diese Ten-
denzen eines Marktmonitorings bedürfen, will man nicht auf alten Entschei-
dungen sitzenbleiben. Es wurde aber auch erkannt, dass zu diesem Zeitpunkt
noch nicht genug Wissen über die ein Data Warehouse beeinflussenden Tech-
nologien vorliegt und dafür eine Projektetappe »Architektur« eingerichtet wer-
den muss.
Damit ist also der beispielhafte Durchlauf durch die Gestaltungs-Entscheidun-
gen wie folgt:

Kategorie

Komplexes Mensch-
Maschine-EDV-System

DB-basiertes Informations-
system

Umweltausschnitt

IT-Markt

Umfeldausschnitt

Unternehmenszielsetzung

Personenziele

Kritische Erfolgsfaktoren

Durch die Produkttypisierung als ein Informationssystem für verschiedene


Organisationsebenen mit Datenhaltung und diversen mit dem Zugriff und der
Verwendung der Daten verbundenen Funktionen ist klar geworden, dass die
Organisationsform für den Aufbau eines Data Warehouse ein umfassendes Pro-
jekt ist. Damit konnten bekannte Erkenntnisse über die Phasenstruktur von
Projekten verwendet werden, um einige Projektschritte vorauszusehen.
Im darauf folgenden zweiten Schritt wurde die Umwelt des Data Warehouse
betrachtet. Es wurde festgestellt, dass ausgewählte Informationen in verschie-
denen Zeitabständen zu beziehen sind, um die Veränderungen der Umwelt, die
ständig neue Entscheidungen bewirken können, wahrzunehmen. Hierzu gehö-
ren z.B. die Technologieneuerungen und die Produktmärkte.
Kapitel 1 • Orientierung zum Thema Data Warehouse 89

Der dritte Schritt endlich ließ die Zielsetzung formulieren. Die Zielsetzung ist
vom Status, also der augenblicklichen Situation von Unternehmen und von den
Umwelttendenzen abhängig. Der Erfolg ist von den Fähigkeiten und vom Wil-
len des Projektleiters abhängig. Die Zielsetzung betrifft den Umfeldausschnitt
aus Unternehmen und Personen. Die Erreichung der Zielsetzung hängt von
sogenannten kritischen Erfolgsfaktoren (KEF) ab.
Aus den bisherigen Erkenntnissen konnte bereits ein einigermaßen genaues
Qualifikationsbild vom Data Warehouse Manager und ein, wenn auch nicht tief-
gehendes, Qualifikationsbild für andere Data Warehouse Spezialisten gezeich-
net werden.
91

KAPITEL 2
2 Was ist eine Architektur eines
Informationssystems?
Überblick
Zunächst wird der Begriff »Architektur« vorgestellt. Danach wird die Frage
nach der Nützlichkeit des Denkens in Architekturen gestellt. Dies wird einmal
für die EDV allgemein und danach für das Data Warehouse im Speziellen
durchgeführt.
Architekturen von Informationssystemen
IT-Systeme sind komplexe Mensch-Maschine-Systeme. Es wird gezeigt, dass
Architekturkonzepte ein nützliches Mittel zur Strukturierung solcher komplexer
Systeme bzw. zur Gewinnung eines besseren Überblickes über bestehende Sys-
teme sind. Es wird weiter gezeigt, dass das Denken in Architekturen die Thematik
von IT-Systemen kategorisieren lässt. Dies bedeutet, dass alle IT-Systeme, und
damit auch DWH, weitgehend schrittweise durch Bearbeitung der IT-Kategorien
analysiert und auch aufgebaut werden können. Diese Kategorien oder Architek-
tursichten sind Betriebswirtschaft, Software, Hardware und Organisation.
Die erste dieser wesentlichen IT-Kategorien, in der Reihenfolge der Analyse, ist
zunächst die Kategorie, die den Zweck des IT-Systems bestimmt. Für betriebs-
wirtschaftliche Anwendungen ist dies die Definition der betriebswirtschaftli-
chen Aufgabenstellung. Dieser Begriff wird hier sehr allgemein verwendet, also
übergreifend auch für die Aufgaben Prozesssteuerung und Signalgebung. DWH
wird in der Literatur eher auf die Beantwortung von Fragen aus dem Control-
ling oder Marketing fokussiert. Die Nützlichkeit von DWH wird an ihrem Bei-
trag zur Verbesserung von Unternehmensprozessen gemessen. Die Gesamtheit
der betriebswirtschaftlichen Funktionen ist die betriebswirtschaftliche Struk-
tur oder betriebswirtschaftliche Architektur des DWH.
Die betriebswirtschaftliche Aufgabenstellung wird durch Funktionen von Pro-
grammen unterstützt und mitunter vollkommen ersetzt. Man denke etwa an
den Versand eines Serienbriefes durch eMails anstelle des Postweges. Die
betriebswirtschaftliche Aufgabenstellung schränkt das Feld der Möglichkeiten
auf bestimmte Programmtypen und bestimmte Softwaretechnologien ein. Für
jeden Anwendertyp ist eine andere Softwaretechnologie geeignet. So kann z.B.
einer Führungskraft nicht zugemutet werden, mit einer Programmiersprache
eine Datenbankabfrage durchzuführen. Ein Anwender der Führungsebene
sollte die Möglichkeit bekommen, mit einer Fachsprache auf Daten zugreifen
zu können. Die betriebswirtschaftliche Aufgabenstellung gibt die Bedingungen
für die Software-Architektur vor.
92 Kapitel 2 • Was ist eine Architektur eines Informationssystems?

Software wird auf einem Rechnersystem ausgeführt, das im einfachsten Fall ein
isolierter Rechner in einem Gehäuse und im komplexen Fall ein weltweit ver-
netztes System mehrerer Rechner ist. Die Softwaretypen stellen wiederum
besondere Anforderungen an die Hardware und die Betriebssysteme dieser
Rechnersysteme. Wenn also die IT-Kategorie der Softwaretypen festgelegt ist,
kann die IT-Kategorie Hardware aus den noch frei bleibenden Möglichkeiten
bestimmt werden. Die Gesamtheit der Hardwarekomponenten und ihrer Ver-
netzung ist die Hardware-Architektur.
Als letzte Kategorie ist die Organisation, die zum Betreiben des komplexen Sys-
tems DWH erforderlich ist, herauszufinden. Die Rechner müssen beschafft, die
Software installiert, die Anwender geschult werden. Bei allem Fortschritt in der
Automatisierung ist der Mensch doch noch nicht ersetzbar und für die Durch-
führung dieser Tätigkeiten sind Handlungen von Menschen zu koordinieren.
Dazu müssen Kompetenzen eingeräumt und Know-how aufgebaut werden. Es
ist zu organisieren und Organisationsstruktur zu schaffen.
Die Architektur des DWH-Systems besteht damit aus Komponenten, Modulen,
Baugruppen, Einheiten der vier IT-Kategorien
✔ Betriebswirtschaftliche Komponenten
✔ Softwarekomponenten
✔ Hardwarekomponenten
✔ Organisationsstruktur
Der Aufbau der Kapitel zur Architektur
Die Architekturen werden demzufolge nach einer allgemeinen Darstellung der
Bedeutung von Architekturen in vier Schritten entwickelt. Die folgende Abbil-
dung gibt einen Überblick über die Gliederung der Kapitel zur Architektur von
DWH-Systemen, die (in Kapitel 2-6) dieser IT-kategorialen Betrachtungsweise
folgt.

 


 
  

  



    









Abbildung 2.1: Gliederung der Kapitel zur Architektur von Data Warehouse Systemen
Kapitel 2 • Was ist eine Architektur eines Informationssystems? 93

Die weitere Aufgabe des Kapitels »Architekturen« ist die Aufschlüsselung dieser
vier IT-Kategorien in Systeme, Teilsysteme, Komponenten und Module. Das
Ziel ist ja der Aufbau eines DWH. Ein DWH gibt es nicht »von der Stange« zu
kaufen, sondern es muss aus »Einzelteilen« zusammengesetzt werden. Einige
dieser Einzelteile können gekauft, andere müssen als Einzelstück entwickelt
werden. Das Ziel der weiteren Zerlegung ist damit abgesteckt: Die Betrachtung
der IT-Kategorien muss so weit detailliert werden, dass am Ende Einheiten in
der Größe definierter erwerbbarer Marktprodukte oder spezifizierbarer Einzel-
fertigungen vorliegen. Dieses Vorgehen stellt einen Mikrozyklus innerhalb des
Makrozyklus dar.

Lernziel
Das Lernziel dieses Abschnitts ist damit die Erschließung des Architekturbe-
griffes und die Anwendung des Denkens in Architekturen auf die Ausgestaltung
der Data Warehouse Lösungen.

Lernziele
 Erkennen und Bedeutung des Architekturbegriffes
 Kennenlernen
Systems
der Schichten der Architektur eines komplexen EDV-

 Erkennen der Architekturlevel eines DWH


 Erkennen der Reihenfolge zur Bearbeitung der Architekturfragen eines
Data Warehouse
 Anwenden der Vorgehensweise zur Analyse einer DWH-Architektur
2.1 Systemanalyse

2.1.1 Ansätze einer Analyse


Die Zerlegung des Gesamtsystems eines Data Warehouse in seine Bestandteile
ist die Aufgabe einer Systemanalyse. Im folgenden Abschnitt wird erläutert,
dass es verschiedene Ansätze für eine Systemanalyse gibt und dass in diesem
Kapitel ein strukturorientierter Ansatz angewendet wird.
Man kann sich jedem Sachverhalt auf verschiedenen Wegen oder auch aus
verschiedenen Blickwinkeln nähern. In der Systemanalyse gehören folgende
Ansätze zum Standardrepertoire:
✔ Der funktionale Ansatz versucht die Frage »Was tut das System und wie
funktioniert es?« zu beantworten. Das Ergebnis der Suche ist eine Liste
oder sogar ein Hierarchiebaum von Funktionen.
94 Kapitel 2 • Was ist eine Architektur eines Informationssystems?

✔ Der prozessuale Ansatz fragt: »In welcher Folge passiert etwas oder in
welcher Reihenfolge laufen Aktionen oder Aktivitäten des untersuchten Sys-
tems ab?«. Das Ergebnis dieser Sichtweise ist eine Ablaufdarstellung.
✔ Der strukturale Ansatz fragt danach, woraus das System besteht. Er fragt
nach den Bestandteilen des Systems und wie diese Bestandteile zusammen-
gehören. Das Ergebnis ist eine Komponentenliste oder ein Strukturdia-
gramm, eine Architektur.
✔ Der datenorientierte Ansatz fragt nach den zu verarbeitenden Daten. Das
Ergebnis dieser Sichtweise ist eine Datensammlung oder sogar ein Daten-
modell.
Diese Liste ist nicht vollständig. Es gibt auch noch andere Ansätze, wie zum
Beispiel der Input-Output-Ansatz, der die Unterschiede zwischen eingehenden
und herauskommenden Daten oder Stoffen untersucht. Der Input-Output-
Ansatz verfolgt dies mit dem Ziel herauszufinden, was diese Unterschiede
bewirkt hat, oder anders gesagt, was im System ist und wie es die Daten verar-
beitet.
Es gibt auch Ansätze, die nicht nach den »gegenständlichen Eigenschaften« des
Untersuchungsgegenstandes (Funktion, Struktur, Prozess, Information) geglie-
dert sind, sondern nach der Perspektive der Vorgehensweise wie Bottom-Up,
Top-Down, Inside-Out, Outside-In. Beim Top-Down-Prinzip wird von der
Gesamtsicht zu immer feineren Details vorgangen. Beim Bottom-Up-Prinzip
wird von den Details eines Systems der Gesamtzusammenhang erarbeitet. Das
Outside-In-Prinzip startet mit der Sicht von »außen« auf das System und
nähert sich dem inneren Aufbau über die von außen sichtbaren Bestandteile
und Reaktionen. Beim Inside-Out-Prinzip, nimmt man sich der Reihe nach die
inneren Bestandteile des Systems vor, geht zu den Schnittstellen zur Außen-
welt und betrachtet dann die Systemumgebung und deren Aufbau.
Es gibt einzelne Typologien für die Systemanalyse, aber es ist leider keine voll-
ständige Klassifikation von Ansätzen zu einer Analyse von Systemen und einer
entsprechenden Ableitung für DV-Systeme bekannt. Es ist auch nicht bekannt,
ob es eine solche vollständige Typisierung geben kann, oder ob es unendlich
viele Möglichkeiten gibt. Man muss sich aus bekannten Ansätzen den der Situa-
tion entsprechend geeignetsten Ansatz auswählen.
Hier kann nicht weiter auf das Thema Systemanalyse eingegangen werden. Wer
sich intensiv mit dem Thema Systemanalyse oder der übergreifenden Thematik
der allgemeinen Problemlösung auseinandersetzen möchte, dem sei empfoh-
len:
 Daenzer, Systems Engineering
 Brauchlin, Problemlösung
Kapitel 2 • Was ist eine Architektur eines Informationssystems? 95

2.1.2 Reihenfolge der Analyseschritte


Eine Untersuchung kann mit allen genannten Ansätzen gemacht werden. Eine
Reihenfolge der Anwendung bezüglich der »gegenständlichen« Eigenschaften
✔ Funktionen
✔ Daten und Informationen
✔ Strukturen
✔ Prozesse
ist nicht zwingend. Jeder der Ansätze hat Vor- und Nachteile, die sich der Analy-
sesituation und deren Randbedingungen entsprechend auswirken. Es haben
sich viele Möglichkeiten in der Anwendung bewährt, von denen beispielhaft die
folgenden drei ausgewählt sind:

Ablauf 1 Ablauf 2 Ablauf 3

Schritt 1 Daten und Informationen Feststellung aller Prozesse Feststellung der Funktionen

Schritt 2 Aufnahme der Funktionen Ableitung der Gesamt- Ermittlung der von den Funk-
struktur tionen verarbeiteten Daten

Schritt 3 Bündelung der Funktionen zu Feststellung der Funktionen Feststellung der Koppelung
Modulen und einer Gesamt- von Funktionen zu Prozessen
struktur

Schritt 4 Prozesse über alle Teile der Feststellung der von den Funk- Zusammenführung von Funk-
Struktur tionen verarbeiteten Daten tionen zu Funktionsgruppen
und Strukturen

Tabelle 2.1: Reihenfolge der Systemanalyse

Es gibt jedoch eine günstige Reihenfolge, die im Kapitel 7 »Vorgehensmodell«


begründet wird. Es ist sogar sinnvoll, ohne die Kenntnis des Ergebnisses einer
Sichtweise noch einmal mit einer zweiten, dritten oder vierten Sichtweise her-
anzugehen und die so gewonnenen Ergebnisse mit denen der ersten Sichtweise
zu vergleichen, sie zu verifizieren oder zu kombinieren, zu verschmelzen oder
zu addieren.

2.1.3 Gegenstand der Analyse


Die spezielle Vorgehensweise, das ist die Reihenfolge des Einsatzes von Metho-
den und Werkzeugen, ist von dem zu bearbeitenden Gegenstand abhängig. Des-
halb muss, bevor man das Vorgehensmodell definiert, zuerst dieser Gegenstand
des Vorgehens, der in unserem Fall das Data Warehouse System ist, erkannt
und erklärt werden. Diese Erklärung ist die Beschreibung der Struktur des zu
Untersuchenden, seine Bestandteile, wie diese in Verbindung stehen, wie sie
zusammengefügt sind oder sich gegenseitig enthalten, also die Architektur.
Zuerst soll daher erklärt werden, was eine Architektur ist, wie man den Archi-
tekturbegriff auf die DWH-Thematik ansetzt, und wozu es nützlich ist zu wis-
sen, was eine DWH-Architektur ist.
Die Analyse der Architektur ist der obigen Aufzählung nach ein strukturaler
Ansatz.
96 Kapitel 2 • Was ist eine Architektur eines Informationssystems?

2.2 Beispiele von Architekturen


Bevor nun näher auf das DWH eingegangen wird, wird zunächst der Begriff der
Architektur genauer beleuchtet.

2.2.1 Übersicht
Die Welt ist zu komplex, um sie als Ganzes begreifen oder gar als Ganzes gestal-
ten zu können. Aber man möchte ja nicht die ganze Welt, sondern nur einen
interessanten Ausschnitt der Welt verstehen und davon wiederum nur einen
kleineren Ausschnitt gestalten. Bezüglich des Themas DWH ist dieser Weltaus-
schnitt ein komplexes EDV-System eines Unternehmens. Den »Rest der Welt«
darf man nicht völlig außer Acht lassen. Ganz ohne Betrachtung der Umwelt ist
keine EDV-Systemgestaltung möglich. Das EDV-System und besonders ein
Informationssystem muss ja mit der Umwelt im Datenaustausch stehen.
Der zu gestaltende Weltausschnitt wird in handhabbare, begreifbare Teile zer-
legt, die man nacheinander analysiert. Um das zerlegte Etwas wieder zu einem
Ganzen zusammenfügen zu können, merkt man sich, wie die Teile zusammen-
gehören. Die einzelnen Scheiben und der Bauplan ihres Zusammenfügens zu
einem Ganzen ist eine Architektur. Die Betrachtung eines Gegenstandes als
Architektur ist ein Mittel, ein komplexes unüberschaubares Gebilde in kleinere,
behandelbare Teile zu zerlegen, ein Mittel der Komplexitätsreduktion.
Der Architekturbegriff ist als Mittel der Komplexitätsreduktion in allen Wissen-
schaftsbereichen verwendbar und keineswegs eine Spezialität der EDV. In der
Biologie spricht man z.B. vom Aufbau oder der »Architektur« einer Zelle, in der
Medizin von der Anatomie oder »Architektur« des menschlichen Gehirns. Am
gebräuchlichsten jedoch ist der Architekturbegriff im Baubereich, ob man nun
von der Architektur eines Hauses oder einer technischen Großanlage, von Gar-
ten- oder von Landschaftsarchitektur, von Außen- oder von Innenarchitektur
spricht.
Auch in abstrakteren Bereichen lässt sich der Architekturbegriff anwenden.
Zum Beispiel kann in der Betriebswirtschaft von der Architektur eines Kon-
zerns die Rede sein. In der Politik wird von der Architektur eines Staates, in der
Rechtswissenschaft von der Architektur von Verträgen gesprochen.
Immer dient die Verwendung des Architekturbegriffs zur Beschreibung der
Gestalt und Funktion eines komplexen Gegenstandes anhand seiner Bestand-
teile und seines Zusammenbaus. Die Teile werden aufgezählt und in einer Liste
geführt, die nach einer bestimmten Systematik erstellt ist. Für den Zusammen-
bau dient ein Bauplan.
Kapitel 2 • Was ist eine Architektur eines Informationssystems? 97

Definition: Architektur
Eine Architektur ist die Gesamtheit von definierten einzelnen Elementen
und die Beschreibung ihrer Zusammensetzung zu einer Struktur. Die
Beschreibung der Zusammensetzung der Architektur ist der Bauplan.

Im folgenden Beispiel aus dem Industriebereich wird die Architekturzerlegung


einer Kraftwerksanlage vorgestellt und die Darstellung dieser Zerlegung durch
ein Kennzeichnungssystem der Anlagenteile.

Beispiel: Architekturzerlegung einer Kraftwerksanlage und


Kraftwerk Kennzeichen System
Eines der am detailliertesten durchstrukturierten Beispiele einer Zerlegung
in Bauteile und Komponenten ist das Kraftwerk Kennzeichen System, kurz
KKS. Das KKS wurde entwickelt, um eine anlagenweit eindeutige Identifizie-
rung der Anlagenteile bzw. Bauteile und Räume einer technischen Großan-
lage durchführen zu können. Technische Großanlagen sind z.B. Raffinerien,
Kern-, Kohle- und Wasserkraftwerke, Entsorgungsanlagen, Müllverbren-
nungsanlagen.
Die Kraftwerksanlage ist aus Gesamtanlagen, wie z.B. Kraftwerksblöcken,
zusammengesetzt. Die Gesamtanlage besteht aus Funktionen, wie z.B. einer
Sprühwasserlöschanlage, und eine Funktion setzt sich aus Aggregaten
zusammen.
Ein Aggregat der Sprühwasserlöschanlage ist die Pumpenanlage, die das
Löschwasser in die Rohrleitungen pumpt. Ein Aggregat ist aus Betriebsmit-
teln zusammengesetzt.
Die letzte Zerlegungsstufe des KKS ist das Betriebsmittel und im Beispiel
der Pumpenanlage die Pumpe oder der Motor. Die Betriebsmittel bestehen
aus Bauteilen und Materialien.
Die Zerlegungshierarchie der technischen Anlage wird noch einmal tabella-
risch an drei Beispielen dargestellt.

Ebene Name Beispiel 1 Beispiel 2 Beispiel 3

0 Kraftwerk

1 Gesamtanlage Kraftwerksblock Kraftwerksblock Block

2 Funktion Sprühwasserlöschanlage Maschinenhaus Schrank

3 Aggregat Pumpenanlage Rolltor Etagen-Koordinate

4 Betriebsmittel Pumpe, Motor Motor

5 Bauteile, Material Flansch, Dichtung, ... Schraube, Motoröl

Tabelle 2.2: Ebenen des KKS


98 Kapitel 2 • Was ist eine Architektur eines Informationssystems?

Die folgenden beiden Abbildungen zeigen die Zerlegung der Beispiele 1 und 2.
Das Schema des Kennzeichnungssystems KKS ist im Kapitel 7 dargestellt, da es
dort zur Definition von Datenverdichtungsstufen dient. Das Beispiel belegt:
Architekturen sind Strukturen mit Funktionen. D.h. die Elemente der Archi-
tektur erfüllen eine Aufgabe oder Funktion.

Abbildung 2.2: Architekturgliederung Beispiel 1 Anlagentechnik

Abbildung 2.3: Architekturgliederung Beispiel 2 Anlagentechnik

Das KKS ist hier nicht nur wegen seiner konsequent strukturierten hierarchi-
schen Zerlegung und damit einer vollständigen Systematik aller Bestandteile
einer komplexen Kraftwerksanlage interessant. Die Hierarchie dient analog der
Gliederung einer Organisation nach Bereichen, Abteilungen und Stellen als
Vorlage zur Akkumulation von Zahlenwerten. Und das ist, wie noch gezeigt
wird, eine der Aufgaben eines DWH.
Als nächstes soll auf die Granularität und die Stufen der Zerlegung der Archi-
tekturen, die Architekturebenen, eingegangen werden.

2.2.2 Stufen der Architekturzerlegung


Der Begriff der Architektur hat je nach Zerlegungsstufe eine andere Ausprä-
gung. Ist man einem architektonischen Gebilde sehr nahe, sieht man zwar die
Feinstrukturen, aber die Gesamtarchitektur ist außerhalb des Blickwinkels.
Kapitel 2 • Was ist eine Architektur eines Informationssystems? 99

Der Blickwinkel, der ein Anlagenaggregat erfassen soll, umfasst die Gesamtan-
lage nicht mehr. Die Konstruktionszeichnung des Pumpenaggregates füllt ein
Zeichnungsblatt vollständig aus. Das Zeichnungsblatt der Gesamtanlage ist in
einem Maßstab gezeichnet, der die Pumpe nur als Punkt erscheinen lässt. Je
nach Detailierungsstufe konzentriert sich der Blick auf einen anderen Aspekt
der Struktur. Je nach Zielsetzung der Betrachtung ist eine mehr oder weniger
detaillierte Stufe der Betrachtung erforderlich. Um die Architektur als Gesam-
tes zu erfassen, sind mehrere Zerlegungsstufen zu analysieren.
Nicht nur der Blickwinkel verändert sich. Je nach Blickwinkel müssen auch
andere Darstellungs- und Analysemethoden herangezogen werden, um das
Wesentliche transparent werden zu lassen. Diesen Methoden ist das Kapitel 7
»Vorgehensmodell« gewidmet.

Beispiel: Betrachtungsnähe der Organisation


Wenn zum Beispiel die Betriebswirtschaft von der Architektur des Konzerns
spricht, meint sie die Zusammensetzung und Beteiligungsverhältnisse der
Gruppen- und Tochterunternehmen und die Organisationsstruktur der zuge-
hörigen Unternehmen. Die Struktur der Organisation nach Bereichen und
Abteilungen erfordert eine verfeinerte Sicht. Man kann daraus verschiedene
Ebenen einer Architektur erkennen.
Eine Betrachtungsebene ist die Makrosicht. Die Makrosicht der Unterneh-
mung ist die Beteiligungsstruktur, dargestellt im Beteiligungsdiagramm.
Die nächst detailliertere Sicht ist die Mesosicht: Sie zeigt die Organisations-
struktur der einzelnen Unternehmen dargestellt im Organigramm.
Soziologen haben auch eine Mikrosicht auf das Geschehen in der Organisa-
tion ausgemacht. Sie zeigt unter anderem private Interessenstrukturen,
Machtverhältnisse und deren Ausübung.

Die Architektur ist also von der Nähe der Betrachtung, der Feinheit, der Granu-
larität der Auflösung abhängig. Architekturen setzen sich aus feineren Archi-
tekturen zusammen. Diese Architekturzerlegung in immer detailliertere Teile
soll nun auf EDV-Systeme angewandt werden.

2.2.3 Architekturzerlegung von EDV-Systemen


An einem DWH sind Hardware, Software und Personen beteiligt. Ein DWH ist
als Informationssystem ein spezielles komplexes EDV-System und kann daher
in denselben Stufen zerlegt werden wie jedes EDV-System. Jedes EDV-System
hat eine Architektur und kann entsprechend allen Architekturen der Kompo-
nentenzerlegung unterzogen werden. Deshalb ist es nützlich, sich diese Zerle-
gungsmöglichkeiten näher zu betrachten und dann daraus den speziell für ein
DWH wichtigen Teilen und Zerlegungsebenen besonderes Augenmerk zu wid-
men. Die Grafik »Architektur-Zooming durch ein EDV-System« verdeutlicht
diese Auflösung in immer feinere Architekturbestandteile am Beispiel der EDV.
100 Kapitel 2 • Was ist eine Architektur eines Informationssystems?

Im Zeitalter der internationalen Öffnung und landesübergreifenden Koopera-


tion ist Kommunikation mittels EDV-Infrastrukturen bereits auf der Makroe-
bene interessant. Das ist das internationale Netz eines Unternehmens, das
Worldwide Area Network, kurz WAN.



 

    
    
 
 



        

    # $    




   
  
 

# $  !" %&$


 
  



  

Abbildung 2.4: Architektur-Zooming durch IT-Systeme

Ein WAN besteht aus den Strecken der Kommunikationsnetze der Länder.
Diese sind aufgrund völlig unterschiedlicher Historien technologisch und
rechtlich stark unterschiedlich und mühsam zu integrieren. Die WAN-Strecken
der Landesnetze und Interkontinentalstrecken sind über Kopplungskompo-
nenten, wie z.B. Router und Sendestationen, verbunden.
Die Landesnetze können privat (z.B. Firmenlandesnetze) und öffentlich (z.B.
das Postnetz) sein. Die Landesnetze setzen sich aus den Überlandnetzen und
Haus- oder Firmengeländenetzen, den Local Area Networks, kurz LAN, zusam-
men. Die LANs sind in Segmente unterteilt, die für sich wieder kleinere LANs
darstellen. Die LAN-Segmente sind mit aktiven und passiven Komponenten wie
Bridges, Router, Switches, Hubs miteinander verbunden.
Kapitel 2 • Was ist eine Architektur eines Informationssystems? 101

Über LANs werden einzelne Rechner (Computer) zu Rechnernetzen, bestehend


aus Rechnern unterschiedlicher Größe und Bauart und Peripheriekomponen-
ten wie Plotter, Scanner, Drucker für Ausgabe und Eingabe, zusammengebun-
den. Die Rechner und Peripheriegeräte werden über Modems, Multiplexer an
das LAN oder direkt an ein WAN angeschlossen.
Die Rechner und Peripheriekomponenten werden aus elektronischen, opti-
schen und mechanischen Baugruppen wie Platinen und Gehäusen zusammen-
gesetzt. Diese bestehen wiederum aus elektronischen, optischen und mechani-
schen Bauteilen wie Prozessoren, Motoren, Sensoren, Kabel, Kleinteilen.
Einige dieser Bauteile haben wieder eine Architektur, was besonders am Bei-
spiel der Prozessoren klar wird.
Für Entscheidungen, die zur Gestaltung eines DWH zu fällen sind, ist die
Ebene Baugruppen und Prozessorarchitektur nicht mehr interessant. Deshalb
soll auf eine weitere Zerlegung dieser Zerlegungslinie verzichtet werden.
Aber nicht nur die Hardware-Architekturen sind zerlegbar, auch softwareseitig
ist eine Zerlegung möglich, beziehungsweise eine zerlegende Betrachtung
nützlich.
Auf der Physik des Prozessors kommen Mikroprogramme und Betriebssysteme
zur Ausführung. Mittels Betriebssystemen werden Anwenderprogramme wie
zum Beispiel Datenbankanwendungen lauffähig.
Große Anwenderprogramme bestehen wiederum aus Modulen und Module sind
aus Objektklassen, Dateien, Funktionen zusammengesetzt. Funktionen sind
aus Elementarfunktionen zusammengesetzt. Dateien sind aus Datensätzen
zusammengesetzt, Objektklassen in Subklassen zerlegt und zu Objekten
instanziiert.

2.2.4 Beispiel einer Softwarearchitektur: Relationale Datenbank-


Managementsysteme
Neben den traditionellen hierarchischen Datenbank-Managementsystemen
haben die relationalen Datenbank-Managementsysteme das höchste Vorkommen
in den Unternehmen. Jedes DWH muss sich mit dem Problem der Integration
relationaler Basisdaten und den Komponenten, die diese Daten verwalten, ausei-
nandersetzen. Deshalb lohnt sich ein Blick auf die Architektur dieses Systems
und später, im Kapitel 7 »Vorgehensmodell«, auf die Struktur relationaler Daten.
Am Beispiel der Komponenten einer älteren Version des Datenbank-Manage-
mentsystems Ingres soll die Struktur eines komplexen Softwaresystems ver-
deutlicht werden. Dies bedeutet keine Einschränkung des Verständnisses, da
alle anderen Produkte dieser Klasse, der Klasse der sogenannten »Mission
Critical Databases«, ähnliche Komponenten haben. Unter Mission Critical ver-
steht man die Robustheit, große Anwenderzahlen (100-10.000) konkurrierend
zu bewältigen, große Datenmengen (Gigabyte bis Terabyte) zu verwalten und
bei Absturz konsistente Zustände zu erhalten.
102 Kapitel 2 • Was ist eine Architektur eines Informationssystems?

Beispiel: Architektur eines relationalen Datenbank-Managementsystems


Die Grafik am Ende dieses Beispiels visualisiert die Komponenten. Man sieht
in der Abbildung drei Komponentengruppen: Client, Netz, Server. Die
Client-Gruppe enthält Komponenten für verschiedene Betriebssysteme und
für grafische und zeichenorientierte Benutzeroberflächen. Die Netzgruppe
enthält Komponenten zur Verteilung und zur Transformation in verschie-
dene Formate. Die Server-Gruppe enthält Verwaltungskomponenten und
Zugriffskomponenten auf verschiedene Datenhaltungsprodukte.
Jede der genannten Komponenten ist weiter zerlegbar in Module. So enthält
zum Beispiel die Komponente »Ingres-Server« das Modul »Queryoptimizer«
zur Formulierung von Abfragestrategien und Multi-Server-Manager für die
Verteilung der Daten auf verschiedene Server. Das besondere Etwas, das rela-
tionale Datenbanken von anderen Filesystemen und Datenbanktypen unter-
scheidet, ist das Data Dictionary und die Speicherung der Daten in relationa-
len Tabellenstrukturen. Das Data Dictionary ist ein Verzeichnis aller Objekte
einer Datenbankanwendung: Applikationen, Masken, Maskenfelder, Reports,
Tabellen, Spalten.
Das relationale Prinzip ist die Minimierung aller Informationen oder anders
formuliert, die höchstmögliche Redundanzfreiheit von Informationen. Hier-
über wird im Vorgehensmodell weiteres ausgeführt. Anders als in anderen
Datenbanksystemen, die auch Verzeichnisse ihrer Bestandteile führen, ist
das Data Dictionary ebenfalls relational.
Die Module setzen sich aus verschiedenen Funktionsgruppen und Funktio-
nen zusammen. Der Queryoptimizer enthält die Funktion »kostenbasiertes
Abfrageoptimieren«.
Zusammengefasst sei noch einmal ein Weg durch die Stufen der Architektur-
zerlegung am Beispiel Ingres dargestellt:
Ingres Datenbank-Managementsystem
➥ Server-Komponente ➡ Client-Komponente ➡ Netzkomponente
➥ Servermanager ➡ Objektmanager ➡ Knowledgemanager
➥ Query Optimizer ➡ Data Dictionary
➥ kostenbasierte Optimierung ➡ regelbasierte Optimierung
Auf jeder Ebene dieser architektonischen Zerlegung des Gesamtsystems bie-
tet der Markt mehrere Gestaltungsalternativen an. So können z.B. die Platt-
formen zwischen DOS, UNIX und OS/2 variiert werden. Das gesamte Client-
Paket kann gegen die Client-Komponenten eines anderen Herstellers, z.B.
von Oracle, Sybase, Informix, IBM oder Software-AG ausgetauscht werden.
Unter dem Multiserver können auch die Datenbanken anderer Hersteller ein-
gesetzt werden. Diese Austauschbarkeit wird gerne unter dem Begriff »Open
Systems« vermarktet und soll Herstellerunabhängigkeit symbolisieren.
Kapitel 2 • Was ist eine Architektur eines Informationssystems? 103

Die Architekturkomponenten haben also auch den Zweck, Zusammenstel-


lungen von Komponenten zu variieren.

  


 

 
 
 







   
   
 
     


  
 

 
 

 

 
 




 
  

 

   

 
 

  


 

 
 
    
 

Abbildung 2.5: Architektur des Datenbank Managementsystems CA-Ingres

Je nach Betriebszweck des Unternehmens verdienen andere Ebenen der Zerle-


gung besonderes Augenmerk. Ein PC-Hersteller oder PC-Assembler ist zum
Beispiel nicht an LAN-Komponenten interessiert, dafür aber sehr an den Bau-
gruppen für Bus und Motherboard. Für die DWH-Gestaltung sind die Gestal-
tungsalternativen interessant, zwischen denen der DWH-Spezialist wählen
kann und die er in einer für seine Zwecke optimalen Form kombinieren kann.
Ein DWH-Spezialist soll einem Unternehmen Informationen bereitstellen. Das
zentrale Element wird daher eine Anwendung sein, die auf einem Rechnersys-
104 Kapitel 2 • Was ist eine Architektur eines Informationssystems?

tem läuft. Es wird nicht der Bau eines Rechners sein. Der Gestaltungsfrage
nähert man sich damit durch Beantwortung der Fragen:
✔ Welche Architekturebenen sind für ein Data Warehouse zu gestalten?
✔ Wie ist ein optimaler Weg durch diese Architekturebenen zu finden?
Aus den Zerlegungsschritten der Architektur sind über alle Beipiele hinweg je
nach Zerlegungstiefe verschieden große Granulate entstanden. Es ist daher ein
Sprachgebrauch nützlich, der unabhängig vom zu zerlegenden Objekt die Zer-
legungsstufe kennzeichnet. Für die weitere Gestaltungsthematik werden die
Begriffe der folgenden Abbildung »Namen der Zerlegungsstufen« verwendet.



      
   

Abbildung 2.6: Namen der Zerlegungsstufen

Am Ende dieses Weges soll man alle für ein DWH wichtigen Gestaltungsent-
scheidungen zur Architektur getroffen haben. Im folgenden Abschnitt sollen
diese Architekturkategorien ermittelt werden.
Diese Gestaltung ist übrigens, so wie sie hier für ein DWH vorgeschlagen wird,
genauso für klassische Datenbankanwendungen einsetzbar wie für Data
Warehouses.

2.3 Die Architekturkategorien von DWH

2.3.1 Abgrenzung des IT-Systems DWH


Die grundsätzliche Kategorie des DWH-Systems ist noch aus den Vorbetrach-
tungen zur Einordnung des Vorhabens bekannt. Ein DWH-System ist ein kom-
plexes datenbankbasiertes EDV-System, ein Informationssystem.
Was ist das Besondere an einem DWH-System gegenüber den anderen Informa-
tionssystemen? Den prinzipiellen Aufbau eines DWH zeigt die folgende Grafik
(Abbildung 2.7).
Ein DWH baut auf vorhandenen IT-Systemen auf. Diese Systeme dienen der
Datenhaltung. Es sind also Informationssysteme. Daten und allgemeine Infor-
mationen werden in diesen Informationssystemen gesucht, ausfindig gemacht,
ausgewählt und in das DWH kopiert. Da das DWH Daten in bestimmten Forma-
ten verwaltet, die in der Regel nicht mit den Formaten der Datenquellen über-
einstimmen, ist eine Formattransformation erforderlich. Die Strukturen der
Daten werden in einem Verzeichnis, dem Data Dictionary, registriert. Die erste
wesentliche Eigenschaft eines DWH ist also die Integration verschiedener
Datenquellen.
Kapitel 2 • Was ist eine Architektur eines Informationssystems? 105

               "  

 
   
     
   



    
  

    
 
  

  
 
 
  

     




 
 





  !
 
   
#      

Abbildung 2.7: Prinzipieller Aufbau von DWH-Systemen

Neben den eigentlichen Daten werden noch Modelle zur Interpretation der
Daten aufbewahrt. Die Daten des DWH werden auf logische Zusammenhänge
und Wechselwirkungen untersucht und dem Benutzer in Form hypothetischer
Erkenntnisse, wie zum Beispiel Prognosen für zukünftige Marktentwicklungen,
dargeboten. Hierfür sind in einem DWH besondere Analysewerkzeuge inte-
griert. Die zweite wesentliche Eigenschaft eines DWH sind die Auswertungs-
funktionen der Daten und Modelle.
Da die gesuchten Erkenntnisse oft sehr komplex sind, sind Visualisierungshil-
fen und eine große Bandbreite unterschiedlicher Darstellungsmittel erforder-
lich. Die DWH enthalten dazu Tools zur Präsentation von Modellen und Daten
wie Tabellen, Grafiken, multidimensionale Matrizen, Landkarten, Beziehungs-
netze. Die dritte wesentliche Eigenschaft eines DWH ist also die Darstellung
komplexer Datenstrukturen.
106 Kapitel 2 • Was ist eine Architektur eines Informationssystems?

Die Eigenschaften des Data Warehouse seien noch einmal abgrenzend zusam-
mengefasst. Eine genaue Definition kann erst später im Kapitel 4 »Software-
komponenten« gegeben werden.

Abgrenzung: Data Warehouse


Die wesentlichen Eigenschaften, die ein Data Warehouse von anderen daten-
bankbasierten Informationssystemen unterscheiden, sind:
✔ die Integration der Daten aus unterschiedlichen Quellen, in unterschied-
lichen Formaten und verschiedenen Strukturen in einer oder mehreren
Datenbanken
✔ die Verwaltung von Modellen zur Interpretation von Daten und die Ver-
fügbarkeit von Algorithmen zur Aufdeckung von Gesetzmäßigkeiten in
Datenmengen
✔ die Möglichkeit, Daten und Modelle in unterschiedlichen Präsentations-
formen darzustellen und deren Auswahl und Darstellung interaktiv zu
gestalten

Die zu bewältigende Aufgabe ist nun die Zusammenstellung derjenigen Kom-


ponenten zu einem integrierten Data Warehouse System, die den Betriebs-
zweck eines speziellen Unternehmens am besten unterstützen. Dies sind auf
den ersten Blick:
✔ Datenquellen
✔ Suchwerkzeuge
✔ Transformatoren
✔ Datenhaltungssysteme
✔ Modellgeneratoren und Analysatoren
✔ Präsentationstools
Da das DWH nicht nur ein EDV-System ist, sondern ein komplexes Mensch-
Maschine-System, gehören hierzu allerdings auch alle Personal-Ressourcen
und Sachmittel, die zum Aufbau und zum Betrieb des DWH benötigt werden,
wie:
✔ Rechner
✔ Netze
✔ Personal
Diese Komponenten der Architektur eines komplexen DWH können nach den
vorhergehenden Darstellungen zu vier zu gestaltenden, völlig voneinander ver-
schiedenen Kategorien von Informationssystem-Komponenten, kurz IT-Kate-
gorien, zusammengefasst werden. Jede dieser IT-Kategorien stellt ein anderes
Kapitel 2 • Was ist eine Architektur eines Informationssystems? 107

Gestaltungsproblem dar, dessen Beherrschung eine andere Qualifikation erfor-


dert und nicht von mehreren Spezialisten zusammen beherrscht werden kann.

2.3.2 Die IT-Kategorien der DWH-Gestaltung


Die zu lösende Aufgabenstellung ist nun die Feststellung der zu gestaltenden
IT-Kategorien und die Reihenfolge ihrer Gestaltung.
Das DWH erfüllt eine oder mehrere betriebswirtschaftliche Aufgaben. Alles
andere muss diesem Ziel untergeordnet werden. Die betriebswirtschaftliche
Aufgabe ist sinngebend für das DWH. Das heißt streng genommen, ohne die
Erfüllung einer betriebswirtschaftlichen Aufgabe bleibt das DWH Privatvergnü-
gen der DWH-Spezialisten. Der erste Schritt besteht deshalb in der Definition
dieser betriebswirtschaftlichen Aufgabe.
➡ Diese erste zu gestaltende IT-Kategorie ist die betriebswirtschaftliche Funk-
tion des DWH.
Die betriebswirtschaftliche Funktion des DWH soll weitgehend von Funktionen
von Programmen übernommen oder wenigstens unterstützt werden. Diese
Programme können mit unterschiedlichen Technologien wie Objektorientie-
rung, relationalen Datenbanken, Programmiersprachen der Vierten Genera-
tion, Algorithmen der Künstlichen Intelligenz, Fuzzy Sets und anderen Techni-
ken entwickelt worden sein bzw. weiterentwickelt werden. Zu jeder
Softwarekategorie können von Hilfswerkzeugen über Einzelprodukte bis hin
zur kompletten Lösung auf dem IT- und Dienstleistungsmarkt Komponenten
erworben werden. Zur Gestaltungsaufgabe gehört deshalb auch, die Entschei-
dung zu treffen, ob Software selbst herzustellen oder teilweise zu bestehenden
Lösungen hinzuzukaufen ist. Im Extremfall ist die Software komplett einzu-
kaufen und anzupassen, wie Standardsoftware. Auch der Kauf von Einzelpro-
dukten, sogenannten Businessobjekten, mit Assemblierung zu Applikationen
ist bereits möglich. Jede dieser Technologien bringt andere Vor- und Nachteile
und muss sorgfältig erwogen werden.
➡ Diese zweite zu gestaltende IT-Kategorie ist die Softwaretechnologie des
DWH.
Steht die einzusetzende Software fest, muss die Plattform, auf der diese Soft-
ware betrieben werden soll, definiert werden und aus der Vielfalt der Marktan-
gebote zu einem Produkttyp ausgewählt und installiert werden. Die Plattform
kann vom isolierten Rechner, der hin und wieder aus den Ursprungsdatenquel-
len Daten einsammelt, bis zu einem Rechnerverbund über hausinterne LAN
und internationale WAN-Strecken reichen. Die Rechner werden über diverse
Peripheriekomponenten für unterschiedliche Ausgabe- und Eingabetechniken
und die physikalische Aufbewahrung der Datenbestände angeschlossen. Welche
Hardwaretechnologien in Frage kommen, wird durch die Entscheidung der
Softwaretechnologie eingeschränkt.
108 Kapitel 2 • Was ist eine Architektur eines Informationssystems?

➡ Diese dritte zu gestaltende IT-Kategorie ist die Hardware- und Netzinfra-


struktur des DWH.
Betriebswirtschaftliche Inhalte, Programme und Hardwarekomponenten müs-
sen spezifiziert, evaluiert, beschafft, installiert, getestet, geschult, betrieben,
gepflegt und wieder abgebaut und entsorgt werden. Für diese Tätigkeiten sind
Menschen mit Befugnissen erforderlich. Die Tätigkeiten dieser Menschen müs-
sen über Organisationsstrukturen, vereinbarte Prozesse und Informationswege
koordiniert werden. Die zur Ausübung der Tätigkeiten erforderlichen Ressour-
cen müssen ermittelt werden. Zur Gestaltung eines komplexen DWH-Systems
gehört demnach auch die Implementierung einer geeigneten Organisations-
struktur.
➡ Diese vierte zu gestaltende IT-Kategorie ist die Organisationsstruktur des
DWH.
Die Gestaltungsaufgabe ist nicht selten so komplex, dass sie nur mit Methoden
in einer überschaubaren Weise dargestellt und gelöst werden kann. Für nahezu
alle Problemstellungen gibt es mehrere Methoden zur Auswahl. So gibt es z.B.
für das Problem der Spezifizierung der Datenstrukturen relationaler Datenban-
ken mit SERM, ERM, RM, ARIS-ERM und anderen mehrere Entwurfsmetho-
den.
Die Entscheidung, welche Methoden zum Einsatz kommen, hängt natürlich
von den zuvor zu treffenden Entscheidungen über die IT-Kategorien ab. So ist
z.B. die Entscheidung, welche Datenmodellierungsmethode zum Einsatz kom-
men soll, von der Entscheidung über den Datenbanktyp abhängig. Eine relatio-
nale Datenbank wird mit einem relationalen Datenmodell entworfen und eine
objektorientierte Datenbank mit einem Objektmodell.
➡ Zu den Gestaltungsaufgaben des DWH gehört die Auswahl der Methoden.
In einigen Fällen ist die Anwendung von Methoden selbst noch so umfangreich,
dass sie überhaupt nur mit Programmen bewältigt werden kann. Dies ist z.B.
bei vielen Datentabellen und deren wechselseitiger Abhängigkeit erforderlich.
Ein Datenmodell kann z.B. mehrere hundert Tabellen umfassen. Die Methoden
sind dann nur noch mit Tools effizient beherrschbar. Das bedeutet, dass die
Gestaltungsaufgabe noch um das Thema Tools erweitert ist:
Da die Tools quasi automatisierte oder elektrifizierte Methoden sind, muss die
Entscheidung »Welche Methode ist einzusetzen?« vor der Toolentscheidung
getroffen werden. Eine Toolentscheidung muss dann deswegen noch getroffen
werden, weil der IT-Markt nahezu zu jeder Methode mehrere Produkte anbietet.
Es kann allerdings auch eine Toollücke auftreten; dann ist zu der gewünschten
Methode kein Tool verfügbar. In diesem Fall muss die Entscheidung getroffen
werden, ob ein Tool selbst hergestellt wird. Tools sind ja Programme oder Dateien
und in den meisten Fällen Datenbankanwendungen. Als Tool wird hierbei auch
z.B. die automatische Auswertung von Interviewformularen verstanden.
Kapitel 2 • Was ist eine Architektur eines Informationssystems? 109

➡ Zu den Gestaltungsaufgaben des DWH gehört die Auswahl der Tools.


Zusammenfassend sei noch einmal der Durchlauf durch die Gestaltungskatego-
rien grafisch untermauert.


      







 



 






 



Abbildung 2.8: Entscheidungsgang der Gestaltung der IT-Kategorien

Dieses Diagramm symbolisiert die Struktur des Gestaltungsraumes der DWH-


Lösung. Die Verbindungspfeile symbolisieren die Reihenfolge des Gestaltungs-
ganges.

2.4 Die Gestaltungszyklen des DWH


Problemstellung und Motivation
Das gesamte Gestaltungsfeld hat zwei Gestaltungsdimensionen: die IT-Katego-
rien und die Zerlegungstiefe. Daher wird dieses Gestaltungsfeld in zwei Zyklen
durchlaufen. Ein Zyklus, der Makrozyklus der Gestaltung, durchläuft die IT-
Kategorien, später als Gestaltungslauf bezeichnet. Der zweite Zyklus, der
Mesozyklus der Gestaltung, durchläuft zu jeder IT-Kategorie die Zerlegungs-
hierarchie, später als Gestaltungsgang bezeichnet. Das Gestaltungsfeld wird
also in mehreren Gestaltungsläufen mit mehreren Gestaltungsgängen durch-
gespielt. Jeder Gestaltungsgang hat der Tiefe der Zerlegung entsprechend meh-
rere Gestaltungsschritte.
Ein solcher linearer Weg ist bis zur Komponentenebene bereits im Diagramm
»Struktur des Gestaltungsweges des Data Warehouse« dargestellt.
110 Kapitel 2 • Was ist eine Architektur eines Informationssystems?

          


 
     
   



 

     








   









 






   




 





 
 
     

  

 

Abbildung 2.9: Struktur des Gestaltungsweges des Data Warehouse

Das Diagramm kann zu diesem Zeitpunkt der Betrachtung nur eine erste Über-
sicht, eine Orientierungshilfe für den Durchlauf durch den Gestaltungsraum
sein. Die leeren Kästchen symbolisieren weitere hierarchische Zerlegungsstu-
fen. Die einzelnen Untergliederungen werden in den folgenden Kapiteln suk-
zessive erarbeitet und mit Entscheidungsalternativen gefüllt. Wenn die leeren
Kästchen mit Entscheidungsalternativen gefüllt sind, handelt es sich um den
Gestaltungsraum der DWH-Lösung.
Restriktionen der Gestaltungsentscheidung
Die Reihenfolge ist nicht in jeder Unternehmenssituation gleich. Restriktionen
durch bereits im Vorfeld oder auch außerhalb der DWH-Thematik getroffene
Kapitel 2 • Was ist eine Architektur eines Informationssystems? 111

Entscheidungen können dazu führen, dass bestimmte Gestaltungsfragen nicht


mehr gestellt werden müssen. Im Diagramm würde dies das Überspringen eines
Kästchens im Durchlauf bedeuten.
Gestaltungsfreiraum
Nach der Auswahl einer zu gestaltenden Komponentengruppe (z.B. Rechner
oder Individualsoftware) sind die dort verfügbaren Komponententypen (z.B.
Parallelrechner oder Datenbankanwendung) zu bestimmen. Hierzu ist ein Bün-
del von Kriterien und Randbedingungen erforderlich, die später diskutiert wer-
den. Die diversen Komponententypen können wiederum aus mehreren Modu-
len (z.B. Prozessor oder Datenbank) zusammengesetzt sein, die nicht beliebig
austauschbar sind, aber unterschiedliche Technologien (z.B. Multiprozessor
oder relationale DB) verwirklichen. Wenn dieser Entscheidungslauf hier ange-
langt ist, kann eine Produktevaluation einsetzen, also z.B. das passende Pro-
dukt »relationales Datenbank-Managementsystem« oder »Rechnersystem mit
mehreren Parallelprozessoren« gefunden werden.
Oftmals stellen die Hersteller nicht nur ein Produkt zu einem Modul her, son-
dern mehrere Produkte unterschiedlicher Technologien und sogar mehrere
verschiedene Module gleicher Technologien (z.B. alle Module einer Client/
Server-Lösung). Dann muss eine Evaluation mehrere Module umfassen.
Für diesen Entscheidungsschritt ist zu bestimmen, was der Gestaltungsumfang
ist. Das ist keinesfalls belanglos, da jedes Projekt unter restriktiven Vorausset-
zungen, wie z.B. den folgenden, abgewickelt werden muss
✔ Personaleinstellungen sind nicht möglich.
✔ Die vorhandene Hardware ist zu nutzen.
✔ Die Partnerschaft mit einem Softwarehersteller ist konsequent einzubezie-
hen.
✔ Auf riskanten Technologiewechsel ist zu verzichten.
Jede dieser Einschränkungen reduziert den Gestaltungsfreiraum. Für den Ent-
scheidungsgang entsprechend dem vorgestellten Schema bedeutet jede Rest-
riktion das Überspringen einer IT-Kategorie oder einer Komponentenauswahl.
Wenn zum Beispiel die Order »die vorhandene Hardware nutzen« ergeht, wird
der Schritt »Hardwareauswahl« übersprungen. Es hilft dem projektleitenden
DWH-Spezialisten nur eines: frühzeitig diese oft unausgesprochenen Restrikti-
onen in Erfahrung zu bringen.
Gestaltungsrestriktionen können widersprüchlich sein, wie z.B. keine Ausbil-
dung und Wechsel in der Technologie oder alter Host mit Terminalapplikation,
aber Software muss Objektorientierung beherrschen. Die Aufgabe des DWH-
Spezialisten ist damit auch, diese Widersprüche, die das Projekt unrealisierbar
machen, aufzudecken und den Auftraggebern deutlich zu machen.
112 Kapitel 2 • Was ist eine Architektur eines Informationssystems?

Mit dieser Folge von Schritten steht der Gang des Projekts zum Aufbau des
DWH im Groben fest. Die genauere Ausdifferenzierung der einzelnen IT-
Kategorien erfolgt in den folgenden Kapiteln.
Die Abhängigkeit noch nicht getroffener Entscheidungen von bereits getroffe-
nen Entscheidungen wird im folgenden Kapitel beispielhaft gezeigt.
Abhängigkeit der Komponentenentscheidungen
Die Komponentenentscheidungen gehorchen wechselseitigen Einschränkun-
gen. Das heißt, hat man sich bezüglich einer Komponente entschieden, dann
sind für die anderen Komponenten nicht mehr alle Möglichkeiten vorhanden.
Dies soll an einem Beispiel dargestellt werden.
Es soll eine Situation skizziert werden, aus der abgeleitet werden kann und
wird, welche Schritte übersprungen werden können, weil eine Unternehmens-
situation zu Restriktionen führt.

Beispiel: Beschaffungsentscheidung
Ein Unternehmen, das vor kurzer Zeit auf ein neues Datenbanksystem umge-
stellt hat, hat sich mit großer Wahrscheinlichkeit ein relationales Daten-
bank-Managementsystem beschafft. Die relationale Datenbank wird dann
entweder in einem Pilotprojekt für einen neuen Applikationsbereich aufge-
baut oder für die Ablösung alter Applikationen auf der Basis einer hierarchi-
schen Datenbank eingerichtet. In den meisten Fällen ist mit der Entschei-
dung, eine relationale Datenbank einzusetzen, die Folgeentscheidung, von
den bestehenden hierarchischen Datenbanken und File-Systemen in die rela-
tionale Welt zu migrieren, getroffen worden.
Wenn man neu entwickeln will, wird man dies mit neuen Werkzeugen
machen wollen. Also mit Objektorientierung, SQL-Abfragen, grafischen
Oberflächen, Programmiersprache der vierten Generation. Der Zugriff auf
die Daten der relationalen Datenbank erfordert Programme mit der Abfrage-
sprache SQL, was bedeutet, dass die Applikationen neu entwickelt werden
müssen.
Da die meisten relationalen Datenbanken in Client/Server-Technologie und
sogar mit objektorientierten Bedieneroberflächen hergestellt sind, zieht
diese Entscheidung eine Hardwarerestriktion nach sich: Es werden ein oder
mehrere zusätzliche Rechner für den Client-Teil benötigt. Objektorientie-
rung setzt immer anstelle eines Terminals einen Client-Rechner voraus.
Bezüglich des Server-Rechners bleibt noch die Freiheit, den vorhandenen
Host zu nutzen oder einen neuen Server für den Betrieb der relationalen
Datenbank zusätzlich zu installieren. Da die alten Terminal/Host-Anwendun-
gen noch eine ganze Weile betrieben werden müssen, heißt dies, dass auf
dem Client eine Terminalemulation installiert werden muss.
Kapitel 2 • Was ist eine Architektur eines Informationssystems? 113

Für die Data Warehouse Lösung bedeutet dies wiederum: Die Datenhaltung
des DWH muss Schnittstellen zum beschafften relationalen Datenbankpro-
dukt und zur Hostdatenhaltung bekommen. Die Client-Komponenten des
DWH müssen auf den Client-Rechnern der Datenbank-Clients installiert
werden können.
Für die Methodik ist die Entity-Relationship-Modellierung unumgänglich.
Bei großen Datenmodellen sollte die Tabelle des Textverarbeitungsprogram-
mes und die Bleistiftzeichnung dem Einsatz eines CASE-Tools oder eines
Datenmodell-Entwurfstools weichen.
Noch einmal übersichtlich zusammengefasst ergibt sich folgendes Argumen-
tationsschema, aus dem die Restriktionen hervorgehen. Aus den Restriktio-
nen ergibt sich der folgende Entscheidungsdurchlauf.
Entscheidung: Beschaffung relationales Datenbank-Managementsystem
➥ Migration von File-Systemen und hierarchischen Datenbanken
➥ Einsatz von 4GL oder OO-Technologien grafische Oberflächen
➥ Migration von Terminal/Host-Applikationen zu Client/Server-
Applikationen
➥ Installation von Client-Stationen
➥ Verwendung des Host als Server
➥ Terminalemulation alter Anwendungen auf grafischem Client
➥ DWH-Komponente mit Zugriff auf relationale Datenbank
➥ Client-Hardware für DWH möglichst wie Datenbank-Client
➥ Methodik: Entity Relationship Modellierung
➥ Einsatz von CASE-Tools
Die Einrückung der Pfeile zeigt die Abhängigkeit einer Entscheidung von
der in der vorangehenden Zeile getroffenen Entscheidung an.

Das Beispiel verdeutlicht die gegenseitige Abhängigkeit der Gestaltungsent-


scheidungen. Es zeigt aber auch, dass diese Abhängigkeit mit wenigen Ein-
schränkungen einen linearen Durchlauf erlauben, wenn man die richtige Rei-
henfolge findet. Man ist nicht von vornherein gezwungen, sich »im Kreise zu
drehen«.

Gestaltungs- und Lösungsmöglichkeiten


Welche der besagten Kategorien muss nun besonders vom DWH-Spezialisten
ausgestaltet werden? Der DWH-Spezialist gestaltet den unmittelbar die DWH-
Funktionalität ausmachenden Bereich selbst und wird von anderen Spezialis-
ten bezüglich der anderen Themen unterstützt. Damit stellt diese Kategorien-
bildung auch eine qualifikationsorientierte Aufgabenbündelung dar.
114 Kapitel 2 • Was ist eine Architektur eines Informationssystems?

Ein DWH ist also ein komplexes System, das teilweise durch Zukauf und teil-
weise durch Eigenentwicklung von Bestandteilen oder Komponenten aufge-
baut werden muss. Aus der Erfahrung mit anderen Informationssystemen
wurde festgestellt, dass sich die Bestandteile in vier wesentliche Kategorien
gruppieren lassen. Die Gestaltungsfrage lautet damit: »Welche Komponenten
sind zu gestalten?« und »In welcher Reihenfolge ist diese Gestaltung zu durch-
laufen?«
Die Gestaltungsaufgabe, ein DWH zu strukturieren, besteht also zunächst aus
den Schritten zur Bestimmung der IT-Kategorien:
➢ Bestimmung der betriebswirtschaftlichen Funktionen
➢ Festlegung der Softwaretechnologie und Auswahl der Softwaretools
➢ Auswahl der optimalen Hardware und Netzinfrastruktur
➢ Entwurf einer Organisationsstruktur
Alle Schritte werden von unterstützenden Methoden und Werkzeugen beglei-
tet. Die Auswahl dieser Methoden und der als Tools realisierten Methoden
gehört zur Gestaltungsaufgabe. Als Tool sollten dabei auch schon elektronische
Formulare, Formatvorlagen, Mustertexte und Tabellen mit Hilfswerten akzep-
tiert werden.
➢ Bestimmung oder Entwicklung der zu verwendenden Methoden
➢ Auswahl oder Eigenentwicklung der Tools zu den bestimmten Methoden
Diese Liste enthält nur konzeptionelle bzw. spezifizierende Aktivitäten. Mit der
Konzeption bzw. Spezifikation eines DWH ist noch kein Stück Software instal-
liert, keine Person eingestellt oder ausgebildet und noch kein Rechner aufge-
baut. Auf die Konzeption und Spezifizierung folgt also noch die Umsetzung.
Diese kann aus Beschaffung von Produkten und zugekauften Leistungen beste-
hen oder auch aus Eigenleistungen. Die Umsetzung folgt genau in umgekehr-
ter Reihenfolge wie die Konzeption. Zur Beschaffung ist Organisation erforder-
lich, für die Installation von Software muss Hardware aufgebaut sein, für die
Entwicklung von betriebswirtschaftlichen Programmen sind Software-
Entwicklungswerkzeuge zu installieren.
➢ Implementierung einer Organisationsstruktur
➢ Evaluation, Beschaffung und Installation der optimalen Hardware und
Netzinfrastruktur
➢ Evaluation, Kauf und Installation der Softwarekomponenten und
Softwaretools
➢ Programmierung oder Kauf und Integration der betriebswirtschaftlichen
Funktionen
Die Produktelandschaft wandelt sich heute so schnell, dass man bei der
Beschaffung bereits auch die Abschaffung in Betracht ziehen muss. Dies ist
umso wichtiger geworden, als die Bestimmungen zum Schutz der Umwelt
Kapitel 2 • Was ist eine Architektur eines Informationssystems? 115

umfangreicher und strenger geworden sind. Bereits in der Betriebsphase wird


der Austausch von Hardware- und Softwarekomponenten erforderlich sein.
Spätestens nach der Außerbetriebnahme sind die Komponenten zu entsorgen.
➢ Destallation der Software
➢ Abbau und Entsorgung der Hardware und des Verbrauchsmaterials
➢ Abbau der Organisation
Die Gestaltungsfrage, die jetzt noch verbleibt, heißt: »Welche IT-Kategorien
sind in welcher Reihenfolge zu gestalten?« Wie diese Gestaltungsfrage zu lösen
ist, zeigt das folgende Kapitel.

Problemlösung: Regeln und Hilfsmittel


Das Verfahren des Makrozyklus der DWH-Gestaltung
Die Lösung der gesamten Gestaltungsfrage ist so umfangreich, dass von Anfang
an eine Folge in der Bearbeitung der IT-Kategorien gefunden werden muss.
Hier wird das folgende Verfahren empfohlen, von dem man besonders im Falle
von Gestaltungsrestriktionen, wie sie im folgenden Absatz besprochen werden,
abweichen kann.

Verfahren: Makrozyklus des Gestaltungsganges der DWH-Architektur


❖ Feststellung der Gestaltungsrestriktionen auf den Ebenen Software,
Hardware, Organisation, Methoden, Tools
❖ Klärung der Restriktionswidersprüche
❖ Bestimmung der betriebswirtschaftlichen Aufgaben nach Nutzerebenen
❖ Festlegung der Softwaretechnologie und Auswahl der Softwaretools
❖ Auswahl der optimalen Hardware und Netzinfrastruktur
❖ Entwurf einer Organisationsstruktur
❖ Auswahl der Methoden zur Gestaltung
❖ Evaluation der optimalen Tools
❖ Aufbau der Organisationsstruktur
❖ Evaluation, Beschaffung und Installation der optimalen Hardware und
Netzinfrastruktur
❖ Evaluation, Kauf und Installation der Softwarekomponenten und Soft-
waretools
❖ Programmierung oder Kauf und Integration der betriebswirtschaftlichen
Funktionen

Der erste Schritt ist durch die Feststellung der zu gestaltenden Kategorien –
betriebswirtschaftliche Funktionen, Softwarekomponenten, Hardwarekompo-
116 Kapitel 2 • Was ist eine Architektur eines Informationssystems?

nenten, Organisationskomponenten – und der Reihenfolge ihrer Bearbeitung


bereits getan. Diese hier empfohlenene Reihenfolge sollte nun gegen die mögli-
chen Restriktionen geprüft werden. Steht z.B. die Hardware bereits fest, ist die
Hardwareverwendung restriktiv für die Softwareauswahl. Zusammen mit den
Restriktionen steht der Durchlauf durch die IT-Kategorien – der Makrozyklus –
fest.
Das Verfahren des Mikrozyklus der DWH-Gestaltung
Als nächster Schritt ist die Auswahl der in den Kategorien zusammengefassten
Komponenten durchzuführen. Hierfür ist das folgende Verfahren – der Mikro-
zyklus – empfohlen.

Verfahren: Mikrozyklus des Gestaltungsganges der DWH-Architektur


❖ Auswahl der IT-Kategorie aus dem Diagramm des Gestaltungsraums der
DWH-Lösung (im ersten Schritt die betriebswirtschaftlichen Aufgaben)
❖ Bestimmung aller Typen zur Systemtypisierung der ausgewählten IT-
Kategorie (System ist dabei ganz allgemein als Mensch-Maschine-
Organisation oder auch als Begriffesystem zu sehen)
❖ Auswahl eines Systemtyps und Bestimmung aller Komponenten des
jeweils ausgewählten Systemtyps
❖ Bestimmung aller interessanten Module zu jeder festgestellten Kompo-
nente
❖ Bestimmung der bevorzugten Technologie, der relevanten Eigenschaften
und gewünschten Funktionen jedes Moduls
❖ Evaluation des Herstellers bzw. Produkts zu einem Modul mit Hilfe der
im Schritt vorher erarbeiteten Anforderungen (Technik, Funktion,
Eigenschaften)
❖ Wiederholung mit den anderen Modulen, den Komponenten der
Komponentengruppen der IT-Kategorie

Als Hilfsmittel der Problemlösung ist zunächst eine Übersicht über die Katego-
rien und die ihnen zugeordneten, zu bestimmenden Komponenten erforderlich.
Die verschiedenen Komponenten können nicht unabhängig voneinander
gewählt werden, da die Wahl der einen Komponente die Auswahlmöglichkeiten
der anderen Komponenten wesentlich einschränken kann. Es wurde bereits die
gegenseitige Bedingungsfolge festgestellt. Aber nicht jede Komponente hat
Einfluss auf die Wahl der anderen Komponenten. Deshalb lässt sich ein linearer
Weg durch das Netz der Komponentenbeziehungen finden.
Die Struktur des Weges ist bis zur Komponentenebene bereits im Text im Dia-
gramm »Struktur des Gestaltungsweges des Data Warehouse« dargestellt
(Abbildung 2.9).
Kapitel 2 • Was ist eine Architektur eines Informationssystems? 117


Einen anderen Ansatz zur Gestaltung von Data Warehouse Systemen zeigt:
Gill, Computing Guide
Darstellungen zum Gesamtzusammenhang von Architekturkomponenten bei
betriebswirtschaftlichen Aufgabenstellungen, Rechnern, Software und Organi-


sation findet man in:
Hansen, Wirtschaftsinformatik

2.5 Fortsetzungsbeispiel InDaWa


Einleitung
Der Beitrag zum Musterprojekt ist die Definition des Verfahrens der Gestaltung
und daraus die Ableitung der Projektschritte. Das Verfahren gewährleistet Voll-
ständigkeit der abzuwickelnden Entscheidungsfragen und korrekte Reihen-
folge. Aus der Reihenfolge des Verfahrens kann jetzt die grobe Aktivitätenliste
eines Projektplanes »DWH-Aufbau« erstellt werden, und sie ist damit Grund-
lage für die Fortschrittsmessung des Projekts »DWH-Aufbau«.
✔ Bestimmung der betriebswirtschaftlichen Funktionen
✔ Festlegung der Softwaretechnologie und Auswahl der Softwaretools
✔ Auswahl der optimalen Hardware und Netzinfrastruktur
✔ Entwurf einer Organisationsstruktur
✔ Bestimmung oder Entwicklung der zu verwendenden Methoden
✔ Auswahl oder Eigenentwicklung der Tools zu den bestimmten Methoden
✔ Implementierung einer Organisationsstruktur
✔ Evaluation, Beschaffung und Installation der optimalen Hardware und
Netzinfrastruktur
✔ Evaluation, Kauf und Installation der Softwarekomponenten und Software-
tools
✔ Programmierung oder Kauf und Integration der betriebswirtschaftlichen
Funktionen
Was noch nicht geschehen kann, ist die Schätzung der Dauer und die erforder-
lichen Qualifikationen zur Abwicklung, da zwar feststeht was eine Aktivität
erreichen soll (Auswahl einer Hardware, Umsetzung einer Betriebsfunktion,
Spezifikation einer Softwarekomponente, Entwurf einer Datenbank, Definition
einer Stelle), aber noch nicht klar ist, wie diese Aktivität abgewickelt wird.
Es ist aber schon zu klären, welche Gestaltungsrestriktionen bestehen. Wird
z.B. die Auswahl einer Hardware entsprechend einer Empfehlung von Partnern
mittels einer Evaluation oder in einem Performance-Feldversuch getroffen?
118 Kapitel 2 • Was ist eine Architektur eines Informationssystems?

Wird der Datenbankentwurf als Referenzmodell zugekauft, wird er mit einem


Entity Relationship Modell selbst entworfen oder soll der Entwurf bereits objek-
torientiert erfolgen? Jede dieser Fragen führt zu anderen Aufwänden, zu ande-
ren Zwischenergebnissen und zu anderen Gestaltungsaufgaben.

Beispiel
Der nächste Schritt im Beispielprojekt ist also die Erfassung der Restriktionen,
um den Gestaltungsspielraum abzugrenzen.

Beispiel: Gestaltungsrestriktionen
Bezüglich des Beispielprojekts sind folgende Restriktionen, im Rahmen
derer alle Gestaltungsentscheidungen getroffen werden müssen, festgestellt
worden:
✔ IT-Kategorie: Betriebswirtschaftliche Aufgaben
Daten der Instandhaltung der Kraftwerksanlagen sollen ohne Prozessda-
ten, Analysen zur Optimierung der Ersatzteilvorhaltung, Reduktion der
Reparaturzeiten zu verschiedenen Ereignissen und Ausfallsprognosen
verfügbar gemacht werden.
Instandhaltung
✔ IT-Kategorie: Softwaretechnologie
Der Einstieg in eine neue Technologie mit Zukunft ist willkommen, soll
aber ausgereift sein, kein Experimentierfeld der Hersteller sein und die
Möglichkeit der Migration bieten, ohne viel Eigenentwicklung zu indu-
zieren. Die Daten sollen regional transparent verteilbar sein. Zugriff auf
kürzlich eingeführte relationale Datenbank muss möglich sein, Replika-
tion ist täglich erforderlich.
Replikative Schnittstelle zu relationaler Datenbank
Prototyping und Öffnung für Objektorientierung Client-seitig
✔ IT-Kategorie: Hardwaretechnologie
Da die Last der Anwendungen noch völlig unklar ist, soll die Hardware
erweiterbar, also skalierbar sein. Die bestehenden Hostnetze sollen nicht
verwendet werden.
Replikative Schnittstelle zu relationaler Datenbank
✔ IT-Kategorie: Organisation
Das Projektteam soll den Betrieb begleiten, das Betriebsteam soll im Pro-
jekt qualifiziert werden. Die Erkenntnisse von vielen Kraftwerken sollen
in das Projekt einfließen und umgekehrt sollen alle Kraftwerke die Pro-
jektergebnisse nutzen können.
Einsatz eines Lenkungsausschusses mit Vertretern
der einzelnen Kraftwerke
Abwicklung als Projekt mit Aufbau der Mitglieder für Betrieb
der Applikation
Kapitel 2 • Was ist eine Architektur eines Informationssystems? 119

Gestaltungsentscheidungen
Diese Erkenntnisse sind wohlgemerkt nur die Restriktionen für die in den
nächsten Kapiteln folgenden DWH-Gestaltungsentscheidungen des Instandhal-
tungssystems.

Entscheidung/
Gestaltungsaspekt Erkenntnis Begründung
ORIENTIERUNG
...

ARCHITEKTUR

Betriebswirtschafts- Instandhaltung Informationen für Schäden


komponenten Rückfluss von Empfehlungen für Schadens-
vermeidung

Softwarekomponenten relationale Datenbank Konsistenz, stabil, performant


OO-Client, SQL-Einbettung Komposition des Client, Zugriff auf RDB

Hardwarekomponenten Client/Server-Architektur Skalierbarkeit, relationale Datenbank

Organisationskomponenten Projektstruktur entsprechend Projektpersonal übernimmt Betrieb


Betriebsaufgaben
VORGEHENSMODELL
...

Tabelle 2.3: Entscheidungschart InDaWa, Architektur

2.6 Übungen
Übung 2.1: Architektur
Schildern Sie, was Sie unter dem Begriff »Architektur« verstehen, und zählen
Sie die Architekturkategorien von Informationssystemen auf.
Übung 2.2: Architektur-Zooming
Zählen Sie die im Bild des Architektur-Zooming vorgestellten Zerlegungsebe-
nen auf und ordnen Sie diese den IT-Kategorien in der Übersicht der Gestal-
tungsentscheidungen zu.
Übung 2.3: relationales Datenbank-Managementsystem
Erklären Sie die Besonderheiten eines relationalen Datenbank-Management-
systems und zählen Sie wichtige Komponenten dieses Informationssystems auf.
Übung 2.4: Makrozyklus, Mikrozyklus
Erläutern Sie, was bezüglich des Gestaltungsdurchlaufes in einem Makrozyklus
und was bezüglich des Gestaltungsdurchlaufes in einem Mikrozyklus erklärt
wurde.
120 Kapitel 2 • Was ist eine Architektur eines Informationssystems?

Übung mit Lösung 2.5: Entscheidungsdurchlauf IT-Kategorien


Versuchen Sie einen Entscheidungsdurchlauf für IT-Kategorien zu entwerfen,
indem Sie in die leeren Kästen des Diagrammes »Struktur des Gestaltungsweges
des Data Warehouse« die Ihnen bekannten Typen und Komponenten eintragen.

2.7 Zusammenfassung
In diesem Kapitel wurde gezeigt, dass ein DWH eine Architektur hat, die aus IT-
Komponenten zusammengesetzt ist und die Gestaltung eines DWH über die
Gestaltung einzelner IT-Kategorien erreicht wird.
Es wurde auch gezeigt, dass die Entscheidungen nicht unabhängig voneinander
getroffen werden können, sondern dass eine Gestaltungsentscheidung in der
Regel die Gestaltungsmöglichkeiten anderer Kategorien einschränkt.
Außerdem wurde deutlich, dass es einen günstigen Weg durch die zu treffenden
Gestaltungsentscheidungen gibt und dass dieser Weg Abkürzungen erfährt,
wenn außerhalb des DWH-Projekts bereits Entscheidungen umgesetzt wurden.
Dieser Weg muss in Mesozyklen an den konkreten Objekten der IT-Kategorien
durchlaufen werden. Deshalb wurde angekündigt, dass mit der Bestimmung
der IT-Kategorien die Gestaltungsarbeit noch nicht beendet ist und dass jede
der Kategorien auf verschiedene noch darzustellende Weise in Komponenten,
Module, Funktionsgruppen zerlegt werden muss. Es ist aber klar geworden,
dass sich die Zerlegung an dem orientieren muss, was der Markt der EDV-
Produkte zu bieten hat.
Es ist auch klar geworden, dass eventuell dieser Markt keine in aller Vollstän-
digkeit befriedigenden Lösungen liefern kann und dann eventuell Eigenent-
wicklung betrieben werden muss.
Eigenentwicklung macht ein Vorgehen nach einem definierten Modell mit
Methoden erforderlich, sowie einige die Methoden per EDV-Applikation unter-
stützende Tools. Die Methoden können jedoch erst dann ausgewählt oder selbst
entwickelt werden, wenn das zu gestaltende Objekt klar ist. Deshalb wird das
Thema Vorgehensmodell im Anschluss an die Gestaltungsentscheidungen der
Architektur behandelt.
In den folgenden Kapiteln wird das Schema der Struktur der Gestaltungsent-
scheidungen schrittweise zu einem Gestaltungsraum verfeinert.
121

KAPITEL 3
3 Welche betriebswirtschaftlichen Komponenten
hat ein DWH?
Einleitung
Unternehmen wickeln zur Erreichung definierter Ziele Prozesse ab. Solche
Prozesse sind z.B. Umsatzgenerierung, Erwirtschaftung von Gewinnen, Erzeu-
gung von Gütern und Schaffung von Werten. Geschäftsprozesse sind in Arbeits-
schritte unterteilt, zu denen Ressourcen wie Sachmittel, Personal und Roh-
stoffe beigestellt werden. Die Arbeitsschritte sind teils manuelle, teils
automatisierte Handlungen und zum Teil Softwareprozesse.
Software ist im Versenden elektronischer Dokumente schneller als Papierpost.
Sie arbeitet präzise, ermüdungslos und verschleißfrei. Mit Software kopierte
Daten sind von einer Fehlerfreiheit, die eine handschriftliche Übertragung
nicht erreichen kann. Daten sind schneller übertragbar als Briefe durch Post-
versand oder Rohrpost. Sie stehen einem Empfänger zur Weiterverarbeitung
zur Verfügung, während der Inhalt von Papierdokumenten erst wieder in Pro-
gramme übernommen werden muss, soll er noch einmal bearbeitet werden.
Software hat die Fähigkeit, Fehler zu finden und Verbesserungsvorschläge zu
machen, wie z.B. die Rechtschreibhilfe eines Textverarbeitungsprogrammes.
Software soll Aktivitäten und Unternehmensprozesse unterstützen. Sie soll ein
guter Ersatz für manuelle Handlungen sein.
Die Software übernimmt betriebswirtschaftliche Aufgaben von den Aufgaben-
trägern. Deren Handlung ist auf einen Tastendruck zum Starten der Pro-
gramme reduziert. Die Software übernimmt auf der Basis ihrer Hardwareplatt-
form den Auftrag und arbeitet diesen ihrer Funktionalität entsprechend ab. Der
Folge der Durchführung manueller Aktivitäten entspricht der Ablauf einer
Folge von Funktionen. Dies ist in der Abbildung »Die Entsprechung von manu-
ellem Ablauf und Programmablauf« verdeutlicht (siehe Abbildung 3.1).
Zur Erstellung oder Auswahl einer Software ist es daher erforderlich, einen
Überblick über die betriebswirtschaftlichen Aufgaben zu gewinnen, also über
die Aktivitäten oder Handlungen, die von der Software übernommen werden
sollen. Dies ist eine funktionale Sicht auf das Unternehmen.
Die Erledigung dieser Aufgaben geschieht in einer logisch zwingenden Reihen-
folge. Das heißt, die Funktionen müssen auch in der Software in einer
bestimmten Reihenfolge abgewickelt werden. Um eine betriebswirtschaftliche
Aufgabe zu definieren, sind Informationen über Aktivitäten, deren Aufeinander-
folge und die bei ihrer Durchführung verwendeten Informationen erforderlich.
122 Kapitel 3 • Welche betriebswirtschaftlichen Komponenten hat ein DWH?


 
 
  


  


   

     

 




Abbildung 3.1: Die Entsprechung von manuellem Ablauf und Programmablauf

Zu den Aktivitäten sind die Handlungsträger, die mit der Durchführung Beauf-
tragten, zu nennen. Dies ist eine prozessuale Sicht auf das Unternehmen.
Handlungsträger benötigen Hinweise, wo ihre Aufgaben mit welchen Werkzeu-
gen in welcher Reihenfolge und unter welchen Bedingungen ausgeführt wer-
den sollen. Sie benötigen Informationen. Für die Software, die diese Aufgaben
ersatzweise abwickeln soll, sind diese Informationen die zu verarbeitenden
Daten. Dies ist eine informationelle Sicht auf das Unternehmen.
Software ist also automatisierte Handlung und Funktionen sind automatisierte
Aktivitäten. Daten sind automatisiert verwaltete Informationen. Automatisie-
rung durch Software hat jedoch Grenzen. Dies sind zum einen ökonomische
Grenzen. Automatisierung ist teuer und amortisiert sich erst bei genügend
häufigen Wiederholungen. Zum anderen hat Automatisierung intellektuelle
Grenzen. Nicht jeder Sachverhalt ist prinzipiell so zu durchdringen, dass man
genaue Programmbeschreibungen gewinnen könnte.
Die wenigsten Aufgaben sind komplett an EDV-Systeme zu übertragen. Der
Fortschritt wird zwar das Spektrum der Funktionen ständig erweitern, es wird
aber immer ein Rest manueller, von einem Menschen auszuführender Tätigkei-
ten übrigbleiben. Eine betriebswirtschaftliche Anwendung und damit auch ein
DWH ist demnach ein Mensch-Maschine-System, ein System im menschliche
Aktivitäten und Programmfunktionen ineinandergreifen.
Kapitel 3 • Welche betriebswirtschaftlichen Komponenten hat ein DWH? 123

Kauft man die »Software von der Stange«, Standardsoftware genannt, hat man
bereits eine vorgefertigte Reihenfolge, eine begrenzte, genau definierte Infor-
mationsmenge und festgelegte Funktionen. Die Standardsoftware ist herge-
stellt worden für eine ganze Klasse von Unternehmungen, ohne die Abläufe des
individuellen Unternehmens wirklich genau zu treffen. Das Unternehmen muss
seine Arbeitsprozesse nach dem Kauf anpassen oder die Software muss ange-
passt werden. Ein Ausweg hieraus ist die totale Eigenentwicklung. Weil man
hierbei nur für seine eigenen individuellen Bedürfnisse entwickelt, wird sie im
Gegensatz zur fertigen Software Individualsoftware genannt. Eine Individual-
entwicklung kann maßgeschneidert auf die Prozesse des Unternehmens abge-
stimmt werden. Das ist allerdings teurer und erfordert eine längere Zeit bis zur
Implementierung. Innerhalb dieser beiden Pole, der vorgefertigten Standard-
software und der frei zu programmierenden Individualsoftware, gibt es Zwi-
schenlösungen, wie anpassbare Standardsoftware und Fertigbauweise mit Ein-
zelkomponenten.
Für den DWH-Spezialisten ist nun wichtig zu bestimmen, welche betriebswirt-
schaftlichen Aufgaben das DWH umfassen muss, d.h. welche betriebswirt-
schaftlichen Funktionen abgedeckt werden müssen, welche betriebswirtschaft-
liche Architektur abgebildet werden muss. Daraus kann die am besten
geeignete Softwaretechnologie abgeleitet werden.
Kapitelüberblick
Betriebswirtschaftliche Programme sind Softwarekomponenten, in denen
betriebswirtschaftliches Fachwissen nach Struktur, Ablauf und Informationsge-
halt abgebildet ist. Die Bedeutung der betriebswirtschaftlichen Komponenten
der Software wird in drei Schritten − Funktionen, Branchen, Hierarchieebene −
herausgearbeitet.

 


 










 


Abbildung 3.2: Überblick über das Kapitel »Betriebswirtschaftliche Funktionen«

Jeder Betrieb kann in Funktionsbereiche wie z.B. Marketing, Kostenrechnung,


Verwaltung, Produktion, Absatz organisiert werden. Ein Data Warehouse ope-
riert auf den Daten dieser Funktionsbereiche. Deshalb wird zunächst festge-
stellt, welche betriebswirtschaftlichen Funktionen es im Unternehmen gibt.
Für die Herstellung oder Auswahl einer Software muss danach entschieden
werden, welche dieser Funktionen mit in die Softwarefunktionalität aufgenom-
men werden soll. Ziel ist dabei auch die Gewinnung von Informationen.
124 Kapitel 3 • Welche betriebswirtschaftlichen Komponenten hat ein DWH?

Es ist ein Unterschied, ob sich ein Konzernchef, ein Bereichsleiter oder ein
Buchhalter die Daten der Kostenrechnung ansieht. Jeder dieser Benutzer benö-
tigt einen anderen Verdichtungsgrad und eine seiner Bedienung entsprechende
Ergonomie. Die Softwarefunktionalität ist deshalb auch von der Hierarchiee-
bene des Benutzers abhängig.
Die Unternehmen aller Branchen haben eine Mindestmenge gleicher Funktio-
nen, die alle erfüllen müssen, um ein Unternehmen führen zu können, z.B.
eine Kostenrechnung. Aber für jede Branche sind diese Grundfunktionen in
einer anderen Ausführung vorhanden. Deshalb kommen spezielle, nur für die
relevante Branche erforderliche, betriebswirtschaftliche Funktionen zum
Funktionsbedarf hinzu. Die Kostenrechnung einer Bank oder die eines Han-
delsunternehmens enthält z.B. keine Fertigungskosten wie die Kostenrech-
nung eines Industriebetriebs.
In diesem Kapitel wird die Thematik der betriebswirtschaftlichen Funktionen
als programmtechnische Entsprechung der betriebswirtschaftlichen Aufgaben
und deren Branchenbezug dargestellt. Die softwaretechnische Sicht folgt im
nächsten Kapitel.

Lernziel
Die Lernziele fokussieren zunächst die betriebswirtschaftlichen Funktionen
und die Umsetzung durch mittels Software automatisierte Funktionen und ihre
Zusammenführung zu betriebswirtschaftlichen Modulen und Softwarekompo-
nenten. Weitere Lernziele konzentrieren sich auf die Bedeutung der branchen-
spezifischen Unterschiede der betriebswirtschaftlichen Funktionen und auf die
speziell durch die hierarchiebezogenen Aufgaben im Unternehmen definierten
Anforderungen an die Funktionalität.

Lernziele
 Verstehen, was eine betriebswirtschaftliche Komponente der Software ist
 Überblick über die betriebswirtschaftlichen Komponenten einer Soft-
ware gewinnen
 Wissen was ein Referenzmodell ist
 Entscheiden
werden soll
können, ob Individual- oder Standardsoftware eingesetzt

 Überblick über Branchenklassifikation gewinnen


 Einordnung von Unternehmen in eine Branchenklassifikation
 Erkennen
luation
des Nutzens einer Branchenklassifikation für die Softwareeva-

 Erkennen der hierarchiebezogenen Funktionen


Kapitel 3 • Welche betriebswirtschaftlichen Komponenten hat ein DWH? 125

3.1 Betriebswirtschaftliche Funktionalität


Problemstellung und Motivation
Voraussetzung für eine effiziente betriebswirtschaftliche Software ist die
genaue Kenntnis der betriebswirtschaftlichen Funktionen.
Kölner Integrationsmodell
Einen ersten Einblick in die Funktionen eines Unternehmens aus der Sicht der
EDV lieferte das Kölner Integrationsmodell, kurz KIM, von Grochla. Das
Modell ist zu umfangreich, um es hier umfassend darzustellen, der Leser möge
nachlesen in
 Grochla, Kölner Integrationsmodell
Ein Ausschnitt aus dem gesamten Plan des Kölner Integrationsmodells lässt
das Prinzip und die Absicht erkennen (siehe Abbildung 3.3).
Das Ziel des Modells ist, einen Bauplan für eine Software zu liefern, die betriebs-
wirtschaftliche Aufgaben übernimmt. Das KIM hatte sogar den Anspruch, eine
vollständige Abbildung aller betriebswirtschaftlichen Prozesse zu erreichen. Man
kann das KIM als einen Versuch zur kompletten Darstellung eines Management
Informationssystems ansehen.
Das Prinzip der Modellierung im KIM ist die symbolische Darstellung der ein-
zelnen Teile dieser Software, die Ausgaben an Peripherie-Geräte, die Darstel-
lung ihres Bezugs zueinander und die Darstellung der betriebswirtschaftlichen
Architektur der Software. Die Hardwarekomponenten werden nicht mehr dar-
gestellt. Alle im Modell symbolisierten realen Objekte sind zu ihrer gegenseiti-
gen Referenzierung identifiziert durch eine Kennzeichnung mit Nummern und
Buchstaben. Mittels der Kennzeichnung kann man in einem Katalog die genau-
ere Beschreibung des Teiles, der in der grafischen Darstellung keinen Platz
mehr hat, nachschlagen.
Die folgenden Symbole werden im KIM verwendet:
✔ Rechtecke für Funktionen oder Funktionengruppen
✔ Rauten für Dateien
✔ Ausgang oder Eingang in den Modellausschnitt für Datengruppen
✔ Kleine Quadrate für Konnektoren zu anderen Diagrammen
✔ Kleine Kreise für Konnektoren innerhalb des Diagrammes, um lange, die
Übersichtlichkeit behindernde Linien zu ersparen
✔ Verbindungslinien für Datenflüsse
126 Kapitel 3 • Welche betriebswirtschaftlichen Komponenten hat ein DWH?

10 11 12 13 14

Anlagen- Artikel- Anlagen- 540


10 591 381 stamm-
stamm- stamm- 895
daten daten daten
518
35
89 105
580
1322
565 564
Personal- 567 367
Sortimentsplan Sortiments-
11 stamm- plan
daten
571 558

155

Ferti- 537 854


12 gungs- Vorratsplan 801 Sonstige
pläne Erlös-
242 596
215 565
minderungen
1291
562 358
1322
896
Artikel- Umsatzwertplan 386 Plan der Sonder-
stamm- 625 Absatzmengen- nach verschie- einzelkosten des
13 plan
daten 239 513 209 360 denen Merkmalen Vertriebs
897 35 76
392 579 527
76 209 20
380
Kunden- 807 Vertreter- 352 Vertreter- Kunden- 395 Plan der
14 stamm- einsatzplan einsatzplan stamm- Kundenskonti
daten 720 223 daten
1317 729
898 564 222 1354
569
362
353
559 386
1268
521
Werbeplan Werbeplan Plan der
15 Kundenboni
21
899 349
338 1380
232 194 570 388
748 29
8
365 Plan der
Artikel- 539 Plan der 204
16 stamm- Rabatte Deckungsbeiträge
daten 783 (kundenbezogen)
1273
560 209
242 76
367

368 271
Kunden- 14 Plan der Brutto- 1325
1366
17 stamm- 571 leistungserlöse 392
739
daten
255 576 825
256 1379 244
575

1400 1380 859


822
404 273 80
1386 Plan der 405 Plan der Plan der
18 573 Kreditgewährung
Zahlungeingänge Liquidität
407 397

406

408
810 396
1348 Plan der Zah- 838 Plan der 396
568 lungsausgänge 260 574
19 1396 Kreditaufnahme
1389 860

272 808

10 11 12 13 14

Abbildung 3.3: Bildausschnitt aus dem Kölner Integrationsmodell

Das Modell kann als Bauplan verwendet werden. Der Bauplan kann für einen
Programmierer als Vorlage zur Herstellung einer betriebswirtschaftlichen Soft-
ware dienen. Er kann auch als Vorlage oder Kriterienliste zur Auswahl für eine
zu beschaffende Standardsoftware dienen. Der Katalog ist eine Auswahl-Check-
liste für die Prüfung einer Standardsoftware auf die gewünschte Funktionalität.
Kapitel 3 • Welche betriebswirtschaftlichen Komponenten hat ein DWH? 127

Industrie-Referenzmodell von Scheer


Ein anderes moderneres Modell ist das Industrie-Referenzmodell von Scheer,
vom auf Grund des großen Umfangs hier ebenfalls nur ein Ausschnitt wiederge-
geben werden kann. Das Modell von Scheer hat seinen Schwerpunkt in der
Logistik von Produktionsprozessen. Es enthält unter anderem ein relationales
Datenmodell. Ein Datenmodell ist ein Bauplan für eine Datenbank, ein soge-
nanntes Datenbankschema. Es kann als Datenfile erworben und zur Generie-
rung einer Datenbank verwendet werden. In dem Buch
 Scheer, Wirtschaftsinformatik
sind die Datenstrukturen genau beschrieben.

Abbildung 3.4: Bildausschnitt aus dem Industriebetriebsmodell von Scheer


128 Kapitel 3 • Welche betriebswirtschaftlichen Komponenten hat ein DWH?

Die folgenden Symbole werden im Datenmodell des Industriebetriebsmodells


von Scheer verwendet:
✔ Rechtecke für Tabellen der Datenbank
✔ Rauten für Beziehungen zwischen den Tabellen
✔ Verbindungslinien für Schlüsselbeziehungen zwischen Tabellen
✔ Kleine Dreiecke für Generalisierungsbeziehungen
✔ Kleine Rechteecke mit abgerundeten Ecken für ausgewählte Daten bzw.
Tabellenspalten
Die Datenstrukturen werden durch funktionale und prozessuale Beschreibun-
gen fundiert. Auch hierfür hat Scheer eine Symbolik entwickelt. Scheer hat
auch das Zusammenspiel zwischen funktionaler Sicht, prozessualer Sicht und
Datensicht dargestellt. Die hierfür eingesetzte Dokumentationsmethodik des
Industrie-Referenzmodells von Scheer ist in einem umfassenden Vorgehensmo-
dell mit dem Namen ARIS zusammengefasst.
 Scheer, ARIS
Industrie-Referenzmodell von Kanter
Ein weiteres, weniger modernes aber sehr kompaktes Modell ist das Industrie-
Referenzmodell von Kanter. Es hat den Vorteil, überschaubar zu sein. Deshalb
kann dieses Modell ausgezeichnet als Start für die Entwicklung eines Unterneh-
mens-Datenmodells oder auch eines Funktionenmodells dienen.
Die Elemente des Kanter-Modells können als zu entwickelnde Module oder
auch als Kerntabellen verwendet werden. Die wesentlichen Kernelemente, die
betriebswirtschaftliche Funktionen vertreten, sind enthalten und können je
nach Bedarf weiter ausdifferenziert werden. Diese Ausdifferenzierung kann z.B.
mit dem entsprechenden Ausschnitt von Scheer oder anderen Modellen durch-
geführt werden. Die Bedarfe der Unternehmen nach einer solchen Ausdifferen-
zierung bzw. einer tieferen Detaillierung der Datenerfassung sind sehr unter-
schiedlich und stark von der Größe des Unternehmens abhängig. Ein sehr
kleines Unternehmen wird mit den Grundstrukturen des Modells von Kanter
auskommen, Kleinunternehmen werden Teile des Modells differenzieren, aber
bereits mittelständische Unternehmen benötigen die Detailtiefe des Scheer-
Modells in der gesamten Breite (siehe Abbildung 3.5).
Weitere Zusammenhänge sind in:
 Kanter, Managing with Information
Kapitel 3 • Welche betriebswirtschaftlichen Komponenten hat ein DWH? 129

Abbildung 3.5: Industriebetriebsmodell von Kanter


130 Kapitel 3 • Welche betriebswirtschaftlichen Komponenten hat ein DWH?

Modellierung
Man sieht, dass die angeführten Modelle eine gewisse Ähnlichkeit aufweisen
und eine Nachbildung betriebswirtschaftlicher Strukturen oder Architekturen
verfolgen. Für diese Nachbildung wird eine Symbolik eingesetzt. Alle Modelle
verwenden in ihrer Symbolik einen auf einen kleinen Umfang begrenzten Satz
von Symbolen. Die Symbole stehen für betriebswirtschaftliche Funktionalität,
Daten, EDV-Komponenten und Sachmittel. Die Symbole sind über Beziehungs-
linien verbunden und stellen so Bezüge dieser Objekte zueinander her. Bei den
repräsentierten EDV-Komponenten und Sachmitteln handelt es sich um Aus-
drucke, Tabellen, Programme.
Man kann auch erkennen, dass verschiedene Autoren bei ihrer Darstellung zu
verschiedenen Symbolen greifen. Von den Möglichkeiten dieser Darstellungen,
ihrer Symbolik und den Regeln der Umsetzung eines realen Sachverhalts in
eine Darstellung, vom Modellieren, handelt Kapitel 7 »Das Vorgehensmodell
für Data Warehouse Systeme«.
Die hier besprochenen Modelle haben die Absicht, einen betriebswirtschaftli-
chen Zustand oder eine betriebswirtschaftliche Struktur zu dokumentieren,
nachvollziehbar zu machen und zu kommunizieren. Gute Modelle enthalten
für viele Unternehmen interessantes Know-how und dienen so der Wiederver-
wendbarkeit und dem Know-how-Transfer. Sie dienen als Referenzmodelle.
Die Referenzmodelle geben eine Zielvorgabe für den betriebswirtschaftlichen
Umfang der zukünftigen Applikationen. Sie dienen als Bauplan oder als Evalua-
tionsgrundlage für einen Softwareeinkauf. Sie definieren noch nicht das DWH,
aber sie definieren die Basis, aus denen das DWH seine Daten bezieht. Was im
Basissystem nicht vorhanden ist, kann von einem DWH nicht geholt werden.
Soll ein DWH betriebswirtschaftliche Funktionen umfassen, die nicht vorhan-
den sind, müssen diese zunächst auf operativer Ebene eingeführt werden.
In einem Unternehmen mit einer bestehenden EDV ist bereits vieles in Ver-
zeichnissen und Dokumentationen vorhanden, so dass ein DWH-Spezialist die
für ihn relevanten Modelle nicht vollkommen neu erstellen oder beziehen
muss.
Terminologie
In einem Modell werden Sachverhalte beschrieben. Die Beschreibungen der
Sachverhalte bedienen sich einer Sprache, genauer einer Terminologie. Je grö-
ßer ein Unternehmen ist, um so vielfältiger ist die Interpretation von Fachbe-
griffen. Ist das Unternehmen aus Fusionen und Zukäufen entstanden, ist sogar
eine Mehrdeutigkeit der Begriffe zu erwarten. Der DWH-Spezialist muss dafür
sorgen, dass auf den Masken der DWH-Applikationen eine einheitliche und
weitgehend akzeptierte Sprache realisiert wird. Die in einem Unternehmen
uneinheitlich praktizierten Fachbegriffe lassen den DWH-Spezialisten nicht auf
Anhieb erkennen, ob es sich um unterschiedliche oder gleiche Dinge handelt.
Kapitel 3 • Welche betriebswirtschaftlichen Komponenten hat ein DWH? 131

Ein anderes Problem ist der unterschiedliche Sprachgebrauch bezüglich der


Granularität der Programme. Was bei Abteilung »A« Modul heißt, wird in Abtei-
lung »B« Funktion genannt und Abteilung »C« sagt Programm dazu. Je größer
das Unternehmen ist und je weniger eine zentrale Organisation mit der Durch-
setzung von Namenskonventionen erfolgreich ist, um so größer ist die Vielfalt.
Dies ist schon alleine durch die Vielzahl der eingesetzten Produkte und durch
die von den Herstellern uneinheitlich geführte Begriffsgebung verursacht.
Hinzu kommt die unterschiedliche Ausbildung und die Verschiedenheit der
Fachbegriffe der ausbildenden Lehrstühle. Zum gegenseitigen Verständnis
muss eine einheitliche Terminologie gefunden und verabredet werden. Ohne
ein gemeinsames Begriffsverständnis wird ein Meinungsaustausch unweiger-
lich zu Missverständnissen führen.
Es ist zu beachten, dass
✔ es zu einem Begriff mehrere gleichwertige, d.h. bedeutungsgleiche
Definitionen geben kann,
✔ es zu einer Definition mehrere Begriffe geben kann,
✔ ein Begriff mit unterschiedlichen Bedeutungen verwendet werden kann,
✔ für Begriffe auch Abkürzungen verwendet werden.
Bevor ein Modell erstellt wird, muss die unternehmensweite Einigung auf eine
einheitliche Terminologie erreicht werden. Dies ist um so schwieriger, je hete-
rogener die Unternehmensgruppe ist. Die von der vereinbarten Linie abwei-
chenden Unternehmen können nicht plötzlich alle Unterlagen umstellen. Die
Anpassung braucht Zeit zur Durchsetzung. Hier helfen Wörterbücher mit
Alternativen. In internationalen Unternehmen müssen diese Wörterbücher
mehrsprachig geführt werden.
➡ Für unternehmensweite Projekte ist die Führung und Pflege eines mehr-
sprachigen, die Begriffsvarianten der Gruppenmitglieder umfassenden
Unternehmenslexikons erforderlich.
Datengüte
Ein DWH soll ein Hilfsmittel sein, um betriebswirtschaftliche Prozesse zu ver-
bessern. Die Durchführung von betriebswirtschaftlichen Prozessen führt zu
Daten, die wiederum die Unternehmenssituation widerspiegeln. Für die Gewin-
nung von Erkenntnissen sind daher die vorhandenen Daten zu analysieren. Ein
großes Problem für die Aussagekraft der von einem DWH abgeleiteten Erkennt-
nisse ist die Güte dieser Daten. Die Daten müssen vollständig sein oder die
Lücken müssen mit Algorithmen geschlossen werden können.
Die Lückenschließung von Datensammlungen soll neutral sein, das heißt, sie
muss mit solchen Algorithmen durchgeführt werden, die das gesuchte Ergeb-
nis nicht in einer Interpretationsrichtung verfälschen. Ein Beispiel soll das
verdeutlichen:
132 Kapitel 3 • Welche betriebswirtschaftlichen Komponenten hat ein DWH?

Beispiel: Umsatzaggregation:
Es liegt die folgende lückenhafte Tabelle mit Umsatzwerten zu einzelnen
Monaten eines Jahres vor.
Umsätze
100 200 300 ??? ??? 200 300 300 ??? ??? 200 300
in TDM
Monate 1 2 3 4 5 6 7 8 9 10 11 12

Tabelle 3.1: Beispiel mit Umsatzwerten


Folgende Frage ist zu beantworten: Wie groß ist der durchschnittliche
Umsatz pro Monat? Zunächst ist zu entscheiden, wie mit den Datenlücken
umgegangen werden soll. Dazu gibt es zwei Möglichkeiten: die Ergänzung
mit Erfahrungswerten oder die Berechnung ohne die Lücken, hier zur
Unterscheidung »algorithmische Lösung« genannt.
Algorithmische Lösung: Addition der vorhandenen Monate durch
die Anzahl der erfassten Monate
Umsatzdurchschnitt 1 ist 1900/8 = 237,50 TDM
Datenergänzung mit Erfahrung: Monat 4, 9 und 10 = 300 TDM,
Monat 5 = 200 TDM
Umsatzdurchschnitt 2 ist 2900/12 = 233,33 TDM
Die Gestaltungsaufgabe des Beispieles oder die Entscheidung, die hier zu
treffen ist, lautet damit:
Schließung der Lücken mit Daten der fehlenden Monate oder mit Hilfe des
gezeigten Algorithmus

Die angebotenen Daten können auch unglaubwürdig sein, so dass man lieber
auf möglicherweise falsche Daten verzichtet.
Welches sind nun die vom DWH-Spezialist zu lösenden Gestaltungsfragen zur
betriebswirtschaftlichen Funktionalität und der Zuordnung zu Branchen?

Gestaltungs- und Lösungsmöglichkeiten


Die erste Gestaltungsaufgabe ist die Feststellung dessen, was an Basissystemen
vorhanden ist. Diese Aufgabe ist nicht trivial, da die wenigsten Unternehmen
ein vollständiges Verzeichnis aller Applikationen an einem Ort zur Verfügung
haben. Im zweiten Schritt dieser Gestaltungsaufgabe ist nun zu definieren, wel-
chen betriebswirtschaftlichen Umfang das DWH auf der Datenbasis erreichen
soll, das heißt, welcher Ausschnitt für die von den Anwendern gestellten Frage-
stellungen relevant ist.
➢ Ermittlung der vorhandenen Basissysteme
➢ Auswahl der relevanten Basissysteme
Kapitel 3 • Welche betriebswirtschaftlichen Komponenten hat ein DWH? 133

Dabei wird man möglicherweise feststellen, dass es die erforderlichen Basispro-


gramme für die im DWH zu beantwortenden Fragen noch nicht gibt. Der DWH-
Spezialist muss in diesem Falle definieren, was fehlt, und in das DWH-Projekt
muss die Schaffung der erweiterten Basis einbezogen werden.
➢ Charakterisierung der zur Lösung der DWH-Aufgabe fehlenden Basis-
systeme
Die Schließung der Datenlücke mittels Algorithmen führt zu einer funktiona-
len Anforderung. Ein Algorithmus muss entweder in der Software verfügbar
sein oder er muss programmiert und eingebunden werden. In das Spektrum
der Gestaltungsfragen des DWH-Spezialisten ist damit noch aufzunehmen:
➢ Prüfung der Datengüte
➢ Entscheidung über die Schließung der Lücken mit Daten und Vorschlag zur
Beschaffung der fehlenden Daten
➢ Entscheidung über die Schließung der Lücken mittels Algorithmus und
Definition zur Beschaffung oder Entwicklung des Algorithmus
Zu der von den Unternehmensteilen unterschiedlich verwendeten Terminologie
muss Vergleichbarkeit hergestellt werden und eine einheitliche Terminologie
eingeführt werden.
➢ Einheitliche Terminologie schaffen
Wie diese Gestaltungsfrage der betriebswirtschaftlichen Funktionen zu lösen
ist, zeigt der folgende Abschnitt.

Problemlösung: Regeln und Hilfsmittel


Das Verfahren
Um ein betriebswirtschaftliches Modell mit Systemen, Komponenten, Modulen
und Funktionen aufzustellen, kann man zwei Wege gehen. Ein Weg ist die
Erhebung und Dokumentation der betriebswirtschaftlichen Prozesse und die
Ableitung der Funktionen aus den Aktivitäten. Ein anderer Weg ist der Zukauf
eines bestehenden Modells. Hierzu ist das folgende Verfahren nützlich.

Verfahren: Betriebswirtschaftliche Module der DWH-Architektur


❖ Basissysteme erfassen
aus bestehenden Dokumentationen wie Modullisten, Funktionsdiagram-
men aus Systemverzeichnissen
❖ Auswahl der für das DWH relevanten Systeme
Erstellung eines Fragenkatalogs an das zu schaffende Anwendungssystem
❖ Charakterisierung der zur Lösung der DWH-Aufgabe fehlenden Basissys-
teme
❖ Prüfung der Datengüte
134 Kapitel 3 • Welche betriebswirtschaftlichen Komponenten hat ein DWH?

❖ Entscheidung über die Schließung der Lücken mit Daten und Vorschlag
zur Beschaffung der fehlenden Daten
❖ Entscheidung über die Schließung der Lücken mittels Algorithmus und
Definition zur Beschaffung oder Entwicklung des Algorithmus
❖ Einheitliche Terminologie schaffen
❖ Funktionale Charakterisierung des Unternehmens mittels Funktionen-
listen und Schalenmodell
❖ Auswahl eines geeigneten Referenzmodells

Für die systematische Abarbeitung der betriebswirtschaftlichen Funktionen


eines DWH dienen vorgefertigte Funktionslisten und Referenzmodelle.
Funktionenlisten
Zum Einen sind natürlich die vorhandenen Listen der bestehenden Funktiona-
lität zu verwenden. Es gibt ja schon Programme im Unternehmen, nämlich die
Basisprogramme, auf denen das DWH operieren, d.h. aus denen es Daten bezie-
hen soll. Ein nützliches Beispiel für die Ermittlung der Basissysteme sind ein
oder mehrere Systemverzeichnisse oder eine manuelle Liste der Basispro-
gramme, die das Rechenzentrum bzw. die unternehmensweit verteilten
Rechenzentren erstellen können. Zu den Systemen beschafft man sich aus der
Dokumentation die Funktionalitätsbeschreibung, die im Idealfall in Form von
in einer Datenbank strukturiert abgelegten Funktionenlisten verfügbar ist.
Noch besser ist es, wenn die Funktionalität mittels eines CASE-Tools grafisch,
als Funktionendiagramm und Modulbaum und damit auch als Datenbankre-
port verfügbar ist.
Für die Tabelle der Basisapplikationen für das DWH sind folgende Informatio-
nen zu erheben:
✔ Name der Applikation, Identifizierung auf dem Rechner
✔ Zweck der Applikation, Funktionen, Kurzbeschreibung mit Inhalt
✔ Lokation des Rechners
✔ Plattform, auf der die Applikation läuft: Rechnertyp, Betriebssystem
✔ Datenbank, auf der die Applikation operiert, Datenbezeichnungen
Ohne eine gute Checkliste wird man nicht alle Funktionsbereiche des Unter-
nehmens entdecken. Zur Prüfung der Vollständigkeit dient eine Gliederung von
betriebswirtschaftlichen Funktionen, wie das folgende Schalenmodell betriebs-
wirtschaftlicher Funktionen für einen Industriebetrieb.
Die Funktionslisten haben einen Nachteil: Sie erlauben im besten Falle eine
hierarchische Gliederung, aber keine Vernetzung.
Kapitel 3 • Welche betriebswirtschaftlichen Komponenten hat ein DWH? 135

Abbildung 3.6: Schalenmodell betriebswirtschaftlicher Funktionen für einen Industriebetrieb

Für einen umfassenden Überblick über die Funktionen eines Unternehmens ist
nützlich:
 Wöhe, Betriebswirtschaftslehre
Referenzmodelle
Seit sich Standardsoftware wider alle Individualitätsbestrebungen der Unter-
nehmen etabliert hat, haben sich auch Referenzmodelle durchgesetzt. Refe-
renzmodelle nehmen für sich in Anspruch, die grundsätzlichen Strukturfragen
gut gelöst zu haben und somit für einen großen Kreis von Anwendern einsetz-
bar zu sein. Wer sich nicht mit der Technologie der Standardsysteme zufrieden
geben will, kann ein Referenzmodell kaufen und es auf seine Bedürfnisse
zuschneiden oder mit anderen Werkzeugen programmieren.

Definition: Betriebswirtschaftliches Referenzmodell


Ein betriebswirtschaftliches Referenzmodell ist ein Muster einer Abbildung
betriebswirtschaftlicher Strukturen in eine DV-Spezifikation von
✔ betriebswirtschaftlichen Aufgaben als Funktionenmodell
✔ betriebswirtschaftlichen Informationen als Datenmodell
✔ betriebswirtschaftlichen Abläufen als Prozessmodell
oder alle drei Ansichten kombiniert in einem Objektmodell
136 Kapitel 3 • Welche betriebswirtschaftlichen Komponenten hat ein DWH?

Das Referenzmodell kann branchenspezifisch oder auch branchenübergreifend


ausgearbeitet sein.
Ein Referenzmodell bietet mehr Informationen als eine Funktionenliste. Refe-
renzmodelle gibt es unter anderem für Modulstrukturen von Programmen, von
Datenmodellen, zu Funktionsübersichten und zu betriebswirtschaftlichen Pro-
zessen. Im Referenzmodell sind, wie die vorher gezeigten Beispiele belegen,
auch die Wechselbezüge, das Zusammenspiel der Teile enthalten. Das Beispiel
der folgenden Abbildung »Referenz-Datenmodell« zeigt einen Ausschnitt aus
einem Datenmodell für Vertriebsdaten. Die Vierecke stellen die Tabellen einer
Datenbank dar. Die Überschriften in den Vierecken sind die Namen der Tabel-
len. Die Namen innerhalb des Vierecks sind die Namen der Tabellenspalten.
Eine Raute (#) vor dem Spaltennamen zeigt an, dass es sich um eine Spalte mit
Schlüsselwerten handelt.

Abbildung 3.7: Referenz-Datenmodell


Kapitel 3 • Welche betriebswirtschaftlichen Komponenten hat ein DWH? 137

Die Referenzmodelle können allgemein oder branchenspezifisch sein. Will man


sich auf ein branchenspezifisches Referenzmodell beziehen, muss man eine
Brancheneinordnung mittels einer Branchenklassifikation vornehmen.
Einige Universitäten haben sich auf bestimmte Branchen spezialisiert und
Referenzmodelle für diese Branchen erarbeitet. Der Markt bietet bereits einige
Referenzmodelle an, und es werden weitere hinzukommen.
In folgenden Büchern sind nützliche Referenzmodelle, bzw. Diskussionen zum
Aufbau von Referenzmodellen enthalten:
 Silverstone, Data Model Resource Book
 Scheer, Wirtschaftsinformatik
 Fowler, Analysemuster
Die Referenzmodelle sind nicht mehr länger »nur« Literatur, sie werden mit-
tlerweile sogar auf Datenträgern als Datenbank mit auswählbarem relationalem
Datenbank-Managementsystem angeboten. Die Dateien können dann in das
hauseigene Data Dictionary übernommen werden, um z.B. eine Datenbank dar-
aus zu generieren. Im Zuge des Fortschritts der objektorientierten Technolo-
gien wird es zukünftig die Funktionalität aus Referenzmodellen in kleinen Tei-
len zu kaufen geben.
Das »Stück« Funktionalität wird dann als Objekt in ein bestehendes System
eingebunden werden können, was heute bereits möglich ist. Wenn diese objekt-
orientierten Referenzmodelle konsequent weiterentwickelt werden, wird in
naher Zukunft ein Unternehmen in der Lage sein, die geforderten Anwendun-
gen aus bestehenden Funktionen und Modulen entsprechend einer Spezifika-
tion zu montieren.
Für die Methodik zur Erstellung von Referenzmodellen dient:
 Schütte, Referenzmodelle
 Becker, Referenzmodelle
Terminologie
Für die Definition der im Unternehmen gepflegten Fachbegriffe ist es nützlich,
ein Lexikon mit Definitionen anzulegen, ein sogenanntes Unternehmenslexi-
kon oder ein sogenanntes Unternehmens-Dictionary, wenn auch fremdsprach-
liche Entsprechungen mit aufgenommen werden sollen.
Auf die Definition ist besondere Sorgfalt zu legen. Sie ist der einzige Maßstab
für die Gleichheit zweier Begriffe. Das Lexikon soll auch die Grundlage für die
Namensgebung von Variablen, Funktionen, Modulen, Programmen und Syste-
men sein, um die Entsprechung zwischen Realität des Unternehmens und
Abbild in einem Programm nachvollziehbar zu machen.
Die Schaffung eines solchen Lexikons hat einen willkommenen Nebeneffekt:
Sie fördert die Zusammenarbeit zwischen den Abteilungen.
138 Kapitel 3 • Welche betriebswirtschaftlichen Komponenten hat ein DWH?

Das Unternehmenslexikon soll enthalten


✔ den Begriff in exakter Schreibweise
✔ alle Definitionen des Begriffs
✔ Verweis auf Synonyme, auch Abkürzungen
✔ Übersetzung des Begriffs
Die Anforderung an die Funktionalität einer DWH-Anwendung unterscheidet
sich in der Bearbeitung des gleichen Basisobjekts bezüglich der hierarchischen
Ebenen der Anwender. Die Thematik des funktionalen Bezugs zu den Hierar-
chieebenen wird im folgenden Kapitel dargestellt.

3.2 Branchen
Problemstellung und Motivation
Welche Gestaltungsfragen zur betriebswirtschaftlichen Funktionalität bezüg-
lich der Zuordnung zu Branchen hat der DWH-Spezialist nun zu lösen?
Je nach Branche wird eine Aufgabe etwas anders abgewickelt. Eine Kostenerfas-
sung z.B. hat in der Industrie mit Positionen zu rechnen, die für eine Kosten-
rechnung einer Bank nicht anfallen. Eine Bank hat z.B. keine Rohmaterialver-
arbeitung, keine Montage, keine Konstruktionsabteilung. Andererseits hat ein
Industriebetrieb keine Funktion für das Bankenclearing für internationalen
Zahlungsverkehr implementiert. Es genügt demnach nicht, ein auf der Kosten-
rechnung des Unternehmens basierendes DWH-Modul zu fordern. Vielmehr ist
jede Funktionsgruppe auf Branchenspezifität zu prüfen. Einige Funktionen
werden in der allgemeinen Form völlig ausreichend spezifiziert sein, andere
sind gegebenenfalls der Branche entsprechend näher zu bestimmen.
Statistiken
Für die Gliederung von Branchen gibt es im Detail ausgearbeitet Klassifizierun-
gen. Der volkswirtschaftliche Markt ist von statistischen Bundesämtern und
Marktforschungsinstituten auf unterschiedliche Weise in Branchen eingeteilt,
immer mit dem Ziel, die komplexe Struktur zu analysieren, Tendenzen in Pro-
duktion und Verteilung von Waren und Dienstleistungen zu entdecken.
Mit Branchenschlüsseln werden Märkte identifiziert und abgegrenzt. Will sich
ein Unternehmen mit anderen Unternehmen vergleichen, so wählt es Unter-
nehmen der gleichen Branche. Will das Unternehmen die Mitbewerber analy-
sieren, wird es seine Untersuchungen auf die in einem Marktsegment wirken-
den Unternehmen einschränken. Der Nutzen für das DWH ist, dass die
»Fremddaten« schneller einbezogen werden können als es eigene Erhebungen
ermöglichen könnten. Die verfügbaren Fremddaten sind zudem in erheblich
größerem Umfang vorhanden als die eigene Kapazität zu eruieren erlaubt.
Kapitel 3 • Welche betriebswirtschaftlichen Komponenten hat ein DWH? 139

Eine erste Gliederungsstufe der Branchen der Betriebe ist die Gliederung nach
Wirtschaftsbereichen, wie sie die statistischen Ämter der Länder verwenden.

Nummer Wirtschaftsbereich

1. Land- und Forstwirtschaft

2. Bergbau und Energie

3. Verarbeitendes Gewerbe

4. Baugewerbe

5. Großhandel

6. Handelvermittlung

7. Einzelhandel

8. Verkehr/Nachrichtenübermittlung

9. Kreditinstitute/Versicherungen

10. Sonstige Dienstleistungsunternehmen und freie Berufe

Tabelle 3.2: Gliederung der Wirtschaftsbereiche der statistischen Landesämter

Will man eine Katalogrecherche von Standardsoftwareprodukten auf die Pro-


dukte eingrenzen, die für die eigenen Belange wichtig sind, sucht man die dem
eigenen Branchenschlüssel zugeordneten Produkte. Ein Branchenschlüssel
erleichtert die Suche und vermindert den Suchaufwand. Ein Vergleich mit
Standardsoftware ist immer der Individualentwicklung voranzustellen. Der
Vorteil ist, dass mitunter die umfangreiche und langwierige Selbsterstellung
erspart bleiben kann. Die Alternative ist, dass der Check der Funktionalität der
Standardsoftware anhand der eigenen Checkliste oft eine Verbesserung dieser
Checkliste bewirkt, auch wenn sie für die Individualentwicklung genutzt wird.
Die Branchengliederung dient nicht nur der statistischen Auswertung. Sie
dient auch der Produktabgrenzung und, was für das DWH noch wichtiger ist,
der Zielgruppendefinition. Dies wiederum dient z.B. für die Auswahl der Stan-
dardsoftware aus dem Marktangebot. Ein Beispiel für eine Branchengliederung
ist die Gliederung nach der NACE, der Nomenclature générale des activités
économiques dans les Communautés Européennes.
Mit Hilfe der Branchenidentifizierung durch einen Schlüssel kann gezielt die
relevante Information zu Märkten, Produkten und Zuständigkeiten von Behör-
den gefunden werden.
Die Statistikinstitute wie Länderbank, Bundesbanken, Verbände, Universitäten
stellen ihre Informationen der öffentlichen Nutzung in Form von CDs, Websei-
ten, Papierkatalogen und Online-Datenbankzugriffen zur Verfügung.
140 Kapitel 3 • Welche betriebswirtschaftlichen Komponenten hat ein DWH?

Name der Stufe Bezeichnung Kennzahl Code

Abschnitte Land- und Forstwirtschaft A —

Unterabschnitte Land- und Forstwirtschaft AA —

Abteilung Landwirtschaft, Jagd 01 010000

Gruppen Pflanzenbau 01.1 011000

Klassen Dauerkulturbau 01.13 011300

Unterklassen Weinbau 01.13-01 011301

Tabelle 3.3: Gliederungsstufen nach NACE, 1995

Neben der Gliederung der Betriebe nach Wirtschaftbereichen gibt es noch die
Gliederung nach Sachleistungen bzw. nach Dienstleistungen. Die Gliederung


der Betriebe gehört zum Thema der Betriebstypologie, für deren Vertiefung auf
Wöhe, Einführung in die allgemeine Betriebswirtschaftslehre
verwiesen werden soll.

Gestaltungs- und Lösungsmöglichkeiten


Der DWH-Spezialist muss die Nützlichkeit der Zuordnung zu einer Branche
bemessen und entscheiden, ob die jeweils geforderte Funktionalität branchen-
spezifisch oder übergreifend ist. Ist die Branchenspezifität erkannt, muss ein
geeignetes Branchenklassifizierungssystem gefunden und angewendet werden.
Mit den Branchenschlüsseln kann in Produkt-Katalogen, Verzeichnissen von
Softwareherstellern und in Statistiken effizienter recherchiert werden.
➢ Findung des geeigneten Branchenklassifikationssystems
➢ Feststellung einer bestehenden Branchenzuordnung
➢ Ermittlung des oder der zugehörigen Branchenschlüssel
Hierfür ist erforderlich
➢ Recherchieren der Statistikinstitute und ihrer Angebote
➢ Zugriff auf die Informationen der Institute und Kopieren in das eigene DWH
Wie diese Gestaltungsfrage der Brancheneingliederung zu lösen ist, zeigt der
folgende Abschnitt.

Problemlösung: Regeln und Hilfsmittel


Das Verfahren
Branchenschlüssel sind ein Ordnungskriterium für Produkt-Kataloge, Ver-
zeichnisse von Softwareherstellern und Wirtschaftsstatistiken. Ein Unterneh-
men, das branchenspezifische Informationen auswerten möchte, muss sich
einen oder mehrere Branchenschlüssel zuordnen.
Kapitel 3 • Welche betriebswirtschaftlichen Komponenten hat ein DWH? 141

Verfahren: Brancheneinordnung des Unternehmens


❖ Entscheidung über den zu verwendenden Branchenschlüssel
❖ Kriterienfindung zur Branchenzuordnung bzw. Erkundigung in der Mar-
ketingabteilung mittels Branchengliederung
❖ Recherchieren der Statistikinstitute und ihrer Angebote
❖ Zugriff auf die Informationen der Institute und Kopieren in das eigene
DWH

Branchenklassifikationen
Zur Einordnung der Branchen gibt es verschiedene Branchenklassifikationen.
Ein Beispiel für eine Branchenklassifikation ist, wie bereits erwähnt, die NACE
für die europäischen Behörden für Wirtschaftsstatistiken. Die Struktur der
NACE wird von den einzelnen Ländern unterschiedlich verfeinert. So heißt z.B.
die von österreichischen Behörden eingesetzte Branchengliederung für Statis-
tiken ÖNACE. Die Gliederung der ÖNACE ist in der folgenden Tabelle »Bran-
chengliederung nach ÖNACE« dargestellt (siehe Tabelle 3.4).
Weitere Systematiken sind beschrieben in:
 Lippe, Wirtschaftsstatistik
Die Branchengliederung kann nicht nur für die eigene Einordnung interessant
sein, sie ist als Wertebereich in einer Datenbank nützlich, wenn das Unterneh-
men Daten zu mehreren Marktsegmenten erfassen muss.
Mit Hilfe der Branchengliederung ist eine gezielte Auswahl von externen
Datenquellen für die Befüllung des DWH mit Informationen möglich. Eine aus-
gezeichnete Übersicht über solche Informationsquellen aus dem Internet ist
dargestellt in:
 Wirtschaftsinformatik, Heft 5, 1999, 41. Jahrgang
142 Kapitel 3 • Welche betriebswirtschaftlichen Komponenten hat ein DWH?

g g
t g hnun t g hnun
nit un nit un
s ch bteil ez eic s ch bteil ez eic
Ab A B Ab A B

A Land- und Forstwirtschaft 19 Ledererzeugung und -verarbeitung

AA Land- und Forstwirtschaft DD Be- und Verarbeitung von Holz, ohne


Herstellung von Möbeln
01 Landwirtschaft, Jagd
20 Be- und Verarbeitung von Holz, ohne
02 Forstwirtschaft Herstellung von Möbeln

B Fischerei und Fischzucht DE Herstellung und Verarbeitung von


Papier, Pappe, Verlagswesen,
BA Fischerei und Fischzucht Druckerei und Vervielfältigung

05 Fischerei und Fischzucht 21 Herstellung und Verarbeitung von Papier,


Pappe
C Bergbau und Gewinnung von Steinen
und Erden 22 Verlagswesen, Druckerei und Verviel-
fältigung von bespielten Ton-, Bild- und
CA Kohlebergbau, Torfgewinnung, Datenträgern
Gewinnung von Erdöl und Erdgas
Bergbau auf Uran und Thoriumerze DF Kokerei, Mineralölverarbeitung,
Herstellung und Verarbeitung von
10 Kohlebergbau, Torfgewinnung, Spalt- und Brutstoffen

11 Erdöl und Erdgasbergbau sowie damit 23 Kokerei, Mineralölverarbeitung, Herstel-


verbundene Dienstleistungen lung und Verarbeitung von Spalt- und
Brutstoffen
12 Bergbau auf Uran und Thoriumerze
DG Herstellung von Chemikalien und
CB Gewinnung von Steinen und Erden, chemischen Erzeugnissen
sonstiger Bergbau
24 Herstellung von Chemikalien und
13 Erzbergbau chemischen Erzeugnissen

14 Gewinnung von Steinen und Erden DH Herstellung von Gummi- und Kunst-
stoffwaren
D Sachgütererzeugung
25 Herstellung von Gummi- und Kunststoff-
DA Herstellung von Nahrungs- und waren
Genussmitteln und Getränken,
Tabakverarbeitung DI Herstellung und Bearbeitung von
Glas, Herstellung von Waren aus
15 Herstellung von Nahrungs- und Genuss- Steinen und Erden
mitteln und Getränken
26 Herstellung und Bearbeitung von Glas,
16 Tabakverarbeitung Herstellung von Waren aus Steinen
und Erden
DB Herstellung von Textilien, Textilwaren
und Bekleidung DJ Metallerzeugung und -bearbeitung,
Herstellung von Metallerzeugnissen
17 Herstellung von Textilien, Textilwaren
ohne Bekleidung 27 Metallerzeugung und -bearbeitung

18 Herstellung von Bekleidung 28 Herstellung von Metallerzeugnissen

DC Ledererzeugung und -verarbeitung, DK Maschinenbau


Herstellung von Schuhen
29 Maschinenbau

Tabelle 3.4: Branchengliederung nach ÖNACE


Kapitel 3 • Welche betriebswirtschaftlichen Komponenten hat ein DWH? 143

g g
t g hnun t g hnun
nit un nit un
s ch bteil ez eic s ch bteil ez eic
Ab A B Ab A B

DL Herstellung von Büromaschinen, 50 Kraftfahrzeughandel; Instandhaltung


Datenverarbeitungsgeräten und und Reparatur von Kraftfahrzeugen;
-einrichtungen; Elektrotechnik, Tankstellen
Feinmechanik und Optik
51 Kraftfahrzeughandel; Instandhaltung
30 Herstellung von Büromaschinen, Daten- und Reparatur von Kraftfahrzeugen;
verarbeitungsgeräten und -einrichtungen Tankstellen

31 Herstellung von Geräten der 52 Einzelhandel (ohne Handel mit Kraft-


Elektrizitätserzeugung, -verteilung u.ä. fahrzeugen und ohne Tankstellen);
Reparatur von Gebrauchtgütern
32 Rundfunk-, Fernseh- und Nachrichten-
technik H Beherbergungs- und Gaststätten-
wesen
33 Medizin-, Mess-, Steuer- und Rege-
lungstechnik, Optik HA Beherbergungs- und Gaststätten-
wesen
DM Fahrzeugbau
55 Beherbergungs- und Gaststättenwesen
34 Herstellung von Kraftwagen und Kraft-
wagenteilen I Verkehr und Nachrichtenübermittlung

35 Sonstiger Fahrzeugbau IA Verkehr und Nachrichtenübermittlung

DN Herstellung von Möbeln, Schmuck, 60 Landverkehr; Transport in Rohrfern-


Musikinstrumenten, Sportgeräten, leitungen
Spielwaren und sonstigen Erzeug-
nissen; Rückgewinnung (Recycling) 61 Schiffahrt

36 Herstellung von Möbeln, Schmuck, 62 Flugverkehr


Musikinstrumenten, Sportgeräten,
Spielwaren und sonstigen Erzeugnissen 63 Hilfs- und Nebentätigkeiten für den
Verkehr; Reisebüros
37 Rückgewinnung (Recycling)
64 Nachrichtenübermittlung
E Energie- und Wasserversorgung
J Kredit- und Versicherungswesen
EA Energie- und Wasserversorgung
JA Kredit- und Versicherungswesen
40 Energieversorgung
65 Kreditwesen
41 Wasserversorgung
66 Versicherungswesen
F Bauwesen
67 Mit dem Kredit- und Versicherungswesen
FA Bauwesen verbundene Tätigkeiten

45 Bauwesen K Realitätenwesen, Vermietung beweg-


licher Sachen, Erbringung von unter-
G Handel; Instandhaltung und nehmensbezogenen Dienstleistungen
Reparatur von Kraftfahrzeugen und
Gebrauchtgütern KA Realitätenwesen, Vermietung beweg-
licher Sachen, Erbringung von unter-
GA Handel; Instandhaltung und nehmensbezogenen Dienstleistungen
Reparatur von Kraftfahrzeugen und
Gebrauchtgütern 70 Realitätenwesen

Tabelle 3.4: Branchengliederung nach ÖNACE (Forts.)


144 Kapitel 3 • Welche betriebswirtschaftlichen Komponenten hat ein DWH?

g g
t g hnun t g hnun
nit un nit un
s ch bteil ez eic s ch bteil ez eic
Ab A B Ab A B

71 Vermietung beweglicher Sachen ohne O Erbringung von sonstigen öffent-


Bedienungspersonal lichen und persönlichen Dienst-
leistungen
72 Datenverarbeitung und Datenbanken
OA Erbringung von sonstigen öffent-
73 Forschung und Entwicklung lichen und persönlichen Dienst-
leistungen
74 Erbringung von unternehmens-
bezogenen Dienstleistungen 90 Abwasser- und Abfallbeseitigung und
sonstige Entsorgung
L Öffentliche Verwaltung, Landesver-
teidigung, Sozialversicherung 91 Interessenvertretungen, kirchliche und
sonstige religiöse Vereinigungen,
LA Öffentliche Verwaltung, Landesver- sonstige Vereine (ohne Sozialwesen,
teidigung, Sozialversicherung Kultur und Sport)

75 Öffentliche Verwaltung, Landesver- 92 Kultur, Sport und Unterhaltung


teidigung, Sozialversicherung
93 Erbringung von sonstigen Dienst-
M Unterrichtswesen leistungen

MA Unterrichtswesen P Private Haushalte

80 Unterrichtswesen PA Private Haushalte

N Gesundheits-, Veterinär- und Sozial- 95 Private Haushalte


wesen
Q Exterritoriale Organisationen und
NA Gesundheits-, Veterinär- und Sozial- Körperschaften
wesen
99 Exterritoriale Organisationen und Körper-
85 Gesundheits-, Veterinär- und Sozial- schaften
wesen

Tabelle 3.4: Branchengliederung nach ÖNACE (Forts.)

3.3 Hierarchieebenen
Problemstellung und Motivation
Managementebenen
Im Gegensatz zu den aus der Sicht der Vertriebsabteilungen der Hersteller ver-
blühten Executive Information Systems ist ein DWH nicht nur für die Executi-
ves sondern für mehrere Managementebenen geeignet. Eine bewährte und in
vielen Standardwerken der Fachliteratur vertretene Einteilung der Manage-
mentebenen ist die folgende in
✔ Strategisches Management
✔ Taktisches Management
✔ Operatives Management
Kapitel 3 • Welche betriebswirtschaftlichen Komponenten hat ein DWH? 145

Selbst die Funktionalität mit Entscheidungsunterstützungsqualität wird nicht


mehr alleine nur für das Management eingerichtet. Im Laufe der letzten Jahr-
zehnte ist ein kontinuierlicher Prozess des Verlagerns von Verantwortung in die
operative Ebene nach dem sogenannten »Delegationsprinzip« zu beobachten.
Auch das ausführende Personal muss heute DV mit Managementfunktionen
einsetzen können. D.h. es ist nicht immer eindeutig definiert, ob eine
ursprünglich als Managementaufgabe definierte Tätigkeit nicht doch vom ope-
rativen Personal wahrgenommen wird. Deshalb wird hier operatives Personal
mit in den Nutzerkreis des DWH einbezogen.
✔ Operatives Personal
Es kommt für den Gestaltungsumfang eines DWH noch eine Nutzerschicht
oder Nutzerebene hinzu, die in vielen Lehrbüchern außer Acht gelassen wird:
die Unternehmensaufsicht. Die Unternehmensaufsicht kann eine Behörde, ein
Aufsichtsrat oder ein Überwachungsverein sein. Der Bedarf an Informationen
für diese Nutzerebene ist ausführlich in dem Buch
 Chini, Aufsichtsrats-Informationssystem
dargestellt. In den Nutzerkreis und auch in die Abbildung der »Management-
pyramide« wird daher noch die Unternehmensaufsicht aufgenommen. Von
einer Pyramide ist deswegen die Rede, weil sich die Anzahl Nutzer von Ebene
zu Ebene von oben nach unten vervielfacht. Eine Faustregel für die Abschät-
zung der Personenzahl der Ebenen ist die sogenannte Leitungsspanne von fünf
bis zehn Personen einer einem Manager direkt unterstehenden Ebene von
Mitarbeitern.
✔ Unternehmensaufsicht
Dem Nutzerkreis entsprechend ist eine andere Funktionalität und Ergonomie
erforderlich, sind andere Werkzeuge im Angebot, ist eine unterschiedliche Ver-
dichtung der Informationen vonnöten. Eine Darstellung der unterschiedlichen
Anforderungen wird durch die Aufgabendarstellung nach den drei Managemen-
tebenen von Kanter, hier um zwei Ebenen erweitert, deutlich.
Die Ergänzung der Managementebenen durch einen Aufsichtsrat ist für das
DWH nur insofern interessant, als der Aufsichtsrat spezielle Reports anfordert,
die erzeugt werden müssen und deshalb als Funktion einzurichten sind. Es ist
nicht üblich, dass ein Aufsichtsratsmitglied als Benutzer im DWH auftritt. Das
gilt besonders für den Aufsichtsrat von Großunternehmen.
Es gibt aber auch Aufsichtsräte von mittelständischen Unternehmen, z.B. in
Joint Ventures von Schwellenländern und Entwicklungsländern, die boden-
ständige Aufgaben wahrnehmen müssen. Eine Erweiterung der interaktiven
Nutzung von EDV-Systemen durch Aufsichtsratsmitglieder sollte deshalb für
die Zukunft nicht ausgeschlossen werden.
146 Kapitel 3 • Welche betriebswirtschaftlichen Komponenten hat ein DWH?

    

 


  
     

 
    

  

   


     




   


     

Abbildung 3.8: Aufgaben der Managementebenen, angelehnt an Kanter

Informationstiefe und regionale Reichweite


Es ist klar, je höher die Managementposition in der Führungshierarchie ange-
siedelt ist, um so größer ist die regionale und die funktionale Reichweite der
Verantwortung. Entsprechend der regionalen Reichweite ist dann auch der rele-
vante Basisumfang der Informationen größer, da dieser ja aus dem operativen
Geschäft der Regionen stammt. Und je mehr Regionen zum Verantwortungsbe-
reich zählen, umso mehr Daten entstehen. Mit der Menge der Daten wächst
aber auch die Unüberschaubarkeit und damit der Bedarf der Verdichtung.
Jeder Nutzer hat ein anderes Interesse an der Genauigkeit und Tiefe der Zerle-
gung von Daten. Als nächstes Problemlösungsmittel dient die Zuordnung der
Akkumulationsstufe des Fachmodules zu der Hierarchieposition des Anwenders,
die Informationstiefe. Die folgende Matrix zeigt exemplarisch die für die ent-
sprechenden Führungsebenen relevanten Verdichtungsgrade (siehe Tabelle 3.5).
Für den Abteilungsleiter bedeutet dies, wie in der Matrix ersichtlich, dass er die
Regionaldaten seiner Region sehen können muss. Die Daten zu den anderen
Regionen müssen eventuell sogar vor seinem Zugriff geschützt werden.
Kapitel 3 • Welche betriebswirtschaftlichen Komponenten hat ein DWH? 147

Konzern Länder Region Bezirk Kunde Projekte

Aufsichtsrat

Konzernvorstand

Bereichsleitung

Abteilungsleiter

Projektleiter

Projektmitarbeiter

Operative Mitarbeiter

Tabelle 3.5: Informationstiefe der Führungsebenen

Aber er muss die Zahlen der seiner Region zugehörigen Bezirke ansehen kön-
nen. Weitergehend soll er nach Auswahl eines Bezirkes die dort zugeordneten
Kunden sehen, aber nicht die Kunden anderer Regionen. Bezüglich der Pro-
jekte sind für ihn alle Informationen interessant, die seine Projekte und die
Projekte mit Auswirkungen auf seine Projekte (z.B. Terminabhängigkeiten)
betreffen.
Regionale Gliederung
Die regionale Gliederung ist ein Aspekt der funktionalen Anforderung »Ver-
dichtungsebenen« an das DWH. Die Daten des DWH werden in der Kompo-
nente »OLAP-System« in einem sogenannten »multidimensionalen Würfel«
organisiert. Die Gliederungsmatrix gibt die Struktur und Dimensionen des
Würfels an. Die Hierarchie-Gliederungsmatrix wird bei der Implementierung
des DWH als Benutzerprofil für die Zugriffsberechtigungen auf die Daten dieses
Würfels verwendet.
Gestaltungs- und Lösungsmöglichkeiten
Was hat nun der DWH-Spezialist bezüglich der hierarchischen Gliederung von
Unternehmen in seiner Gestaltung zu berücksichtigen?
Es ist nicht per se klar, welche Führungsebene zum Nutzerkreis des DWH
gehören soll. Für die einzelnen Führungspositionen muss die zunächst nur
vage vorhandene Vorstellung von den Möglichkeiten eines DWH konkretisiert
werden. Es müssen deren Verantwortungsbereiche einschließlich der zu ihrer
Führung erforderlichen Informationen festgestellt werden. Die Veranwortungs-
bereiche können dabei produktbezogen definiert sein, sie können regional und
über alle Produkte gelten, sie können über mehrere Produkte und Regionen
und auch für mehrere Projekte gelten.
Die Gestaltungsaufgabe lautet damit wie folgt:
➢ Feststellung, welche Regionen zu ihrem Verantwortungsbereich gehören
➢ Feststellung, welche Führungsebenen am DWH beteiligt sind
148 Kapitel 3 • Welche betriebswirtschaftlichen Komponenten hat ein DWH?

➢ Feststellung, aus welchen Fachmodulen sie ihre Informationen beziehen


müssen
➢ Feststellung, welche Produkte zu ihrem Verantwortungsbereich gehören
➢ Feststellung, welche Projekte zu ihrem Verantwortungsbereich gehören
➢ Definition Gliederungstiefe von Stufe x bis Stufe y zu jeder Hierarchieebene
bezüglich der Regionen, Produkte, Projekte, Funktionen, Zeitabschnitte
Wie diese Gestaltungsaufgabe durch die hierarchische Gliederung von Unter-
nehmen zu lösen ist, zeigt das folgende Kapitel.
Problemlösung: Regeln und Hilfsmittel
Das Verfahren
Für die Feststellung der Hierarchiedimensionen – wer wie tief welche Informa-
tionen verfolgen muss – sind verschiedene Gliederungen erforderlich. Zur Fin-
dung dieser Gliederungen ist folgendes Verfahren anwendbar.

Verfahren: Bestimmung der Hierarchieebenen des DWH


❖ Feststellung der zu versorgenden Managementebenen, der Einstiegsebe-
nen in den Navigationsdialog und der Navigationstiefe (Drill Down) mit
Hilfe des Unternehmens-Organigramms
❖ Feststellung, welche Regionen zu ihrem Verantwortungsbereich gehören
mit Hilfe einer Regionalgliederungssystematik
❖ Feststellung, aus welchen Fachmodulen sie ihre Informationen beziehen
müssen mit Hilfe einer Funktionalgliederungssystematik
❖ Feststellung, welche Produkte bzw. Anlagenteile zum Verantwortungsbe-
reich gehören mit Hilfe einer Produkt- bzw. Anlagengliederungssystematik
❖ Feststellung, welche Projekte zu ihrem Verantwortungsbereich gehören
mit Hilfe einer Projektgliederungssystematik
❖ Angabe der Gliederungstiefe von Stufe x bis Stufe y bezüglich der Regio-
nen, Produkte, Projekte, Funktionen, zu jeder Ebene mit Hilfe der Hier-
archie-Gliederungsmatrix für DWH-Anwender
❖ Angabe der Zeitebenen mit Hilfe einer Zeitgliederungssystematik

Gliederung der Dimension »Organisation«


Als erstes Problemlösungshilfsmittel für die hierarchische Gliederung ist
zunächst ein Organigramm oder eine Organisationsgliederungssystematik
erforderlich. Je nachdem wie groß ein Unternehmen ist, kann diese Informa-
tion in einer Grafik oder aber in vielen einzelnen Strukturgrafiken dargestellt
werden. Das Organigramm zeigt bereits die Zuständigkeit zu Fachbereichen
oder betriebswirtschaftlichen Funktionen, wie zum Beispiel Verwaltung und
Kapitel 3 • Welche betriebswirtschaftlichen Komponenten hat ein DWH? 149

Finanzierung, aber auch zu Regionen, Produkten und untergeordneten Hierar-


chieebenen. Dies ist aber zunächst nur als eine Hierarchie von Führungsebe-
nen anzusehen.

ORGANISATION

Unternehmensgruppe

Unternehmen

Division

Hauptabteilung

Abteilung

Gruppe

Person

Abbildung 3.9: Gliederungsschema der Dimension »Organisation«

Gliederung der Dimension »Produkt«


Analog hierzu gibt es eine hierarchische Produktgliederungssystematik. Die
Produktgliederung ist in den Unternehmen vorhanden und z.B. in der Kosten-
rechnung hinterlegt. Die Produktgliederung umfasst je nach der Größe des
Produkts – eine Schraube ist ein Produkt genauso wie ein komplettes Kraft-
werk – eine Zerlegung des Produkts in kleinere Baueinheiten, die ebenfalls
wieder Produkte sind.

PRODUKT

Wirtschaftszweig

Branchengruppe

Branchenklasse

Produktgruppe

Marke

Artikel

Erzeugnis

Bauteil

Material

Abbildung 3.10: Gliederungschema der Dimension »Produkt«


150 Kapitel 3 • Welche betriebswirtschaftlichen Komponenten hat ein DWH?

Gliederung der Dimension »Region«


Außerdem ist eine Systematik der Regionalgliederung, die ebenfalls wieder
eine hierarchische Zerlegung ist, in den Unternehmen vorhanden. Der Vertrieb
bearbeitet z.B. den Markt entsprechend der Regionalgliederung. Das Marketing
plant regionale Aktionen. Regionen sind nur soweit interessant, als sie vom
Unternehmen bearbeitet werden.

REGIONEN

Erdteil

Ländergruppe

Land

Bundesland

Region

Bezirk

Stadt

Stadtteil

Straße

Haus

Abbildung 3.11: Gliederungsschema der Dimension »Regionen«

Gliederung der Dimension »Anlagenstruktur«


Im Anlagengeschäft bekommt neben der organisatorischen Gliederung auch
die Gliederung der Anlage eine besondere Rolle, da sie zur örtlichen Identifizie-
rung der Anlagenteile benötigt wird und alle örtlichen Auswertungen diese
Technische Anlagengliederung zum Bezugspunkt haben.

ANLAGEN

Werk

Gesamtanlage

Funktion

Aggregat

Betriebsmittel

Bauteil

Abbildung 3.12: Gliederungsschema der Dimensionen »Anlagenstruktur«


Kapitel 3 • Welche betriebswirtschaftlichen Komponenten hat ein DWH? 151

Gliederung der Dimension »Vorhaben« oder »Projekt«


Auch Projekte können in Subprojekte, Teilprojekte und Projektaufgaben geglie-
dert sein. Das ist in einer sogenannten Projektstruktur definiert. Die Projekt-
struktur ist von Projekt zu Projekt verschieden. Ein Teilprojekt eines Subpro-
jekts eines großen Projekts kann größer sein als ein anderes Projekt des
Unternehmens. Hier ist auf die Vergleichbarkeit zu achten. Bei großen Projek-
ten spricht man oft von Vorhaben.

VORHABEN

Projekt

Subprojekt

Teilprojekt

Aufgabe

Aktion

Abbildung 3.13: Gliederungsschema der Dimension »Vorhaben«

Gliederung der Dimension »Perioden« oder »Zeiteinheiten«


Nicht jede Führungsebene muss die interessanten Daten auf die Genauigkeit
von Tagen verfolgen. Je höher die Ebene ist, umso größer ist der zu überschau-
ende Zeitraum und umso weniger detailliert ist die Zeiteinheit der Betrach-
tung. Deshalb ist noch eine Gliederung nach Zeiteinheiten oder Perioden
erforderlich.

PERIODEN

Jahrzehnt

Jahrestriade

Jahr

Halbjahr

Quartal

Monat

Woche

Tag

Stunde

Abbildung 3.14: Gliederungsschema der Dimension »Perioden«


152 Kapitel 3 • Welche betriebswirtschaftlichen Komponenten hat ein DWH?

Zusammenfassung der betriebswirtschaftliche Dimensionen


Jede der genannten Dimensionen kann unabhängig von den jeweils anderen
Dimensionen genutzt werden. Jede Dimension gibt eine eigene Perspektive auf
die zu analysierenden Zustände eines Unternehmens und die sie repräsentie-
renden Zahlen. Die Dimensionen der Gesamtgliederung sind in der folgenden
Tabelle betriebswirtschaftliche Dimensionen mit der Wurzel des Gliederungs-
baumes zusammengestellt.

PRODUKT Wirtschaftszweig ... ...

ORGANISATION Unternehmensgruppe ... ...

VORHABEN Projekt ... ...

REGIONEN Erdteil ... ...

PERIODEN Jahrzehnt ... ...

ANLAGEN Werk ... ...

Abbildung 3.15: Zusammenfassung der betriebswirtschaftlichen Dimensionen

Das Gliederungsschema der betriebswirtschaftlichen Dimensionen dient später


zur Darstellung des Star-Schemas, einer Besonderheit der Datendarstellung des
DWH.
Hierarchie-Gliederungsmatrix für DWH-Anwender
Die Informationsebenen sind nicht nur, wie schon gesagt, für die Ergonomie
und funktionelle Ausstattung des Arbeitsplatzes bezüglich Software wie auch
Hardware wichtig. Sie werden auch zur Definition der Aggregationsstufen
benötigt. Das heißt konkret, sie werden benötigt für die Feststellung, welcher
Arbeitsplatz welchen Verdichtungsgrad an Information bevorzugt sehen will.
Bevorzugt bedeutet hierbei, dass andere Sichten zwar nicht verwehrt werden,
aber die Standardeinstellung, der Einstieg in das DWH, auf der jeweils bevor-
zugten Ebene startet.
Es wird demzufolge ein Hilfsmittel benötigt, das die einzelnen Hierarchien der
Produkte, Regionen, Projekte und Führungsebenen zu einer einheitlichen Über-
sicht zusammenführt. Hierfür ist die Hierarchie-Gliederungsmatrix entwickelt
worden. Das Ergebnis der Einstufung der Benutzer nach einer Bedarfserfassung
zu den einzelnen Gliederungen wird in dieser Zuordnungstabelle eingetragen.
Kapitel 3 • Welche betriebswirtschaftlichen Komponenten hat ein DWH? 153

Ebene Projekt Region Funktion Produkt

Name Stufe Name Stufe Name Stufe


Name Stufe Name

Aufsichtsrat 0 Großprojekt 0-3 0-1 0-1

Technischer 0 Projekt 0-4 0-3 Produktion 0-4 Alle


Vorstand Entwicklung Produkte
Instand-
haltung

Bereichs- 1-2 Bereichs- 0-4 0-3 0-4


leitung projekt

Abteilungs- 1-2 Abteilungs- 2-5 4-5 4-6


leitung projekt

Projektleiter 1-5 3-5 4-5 --

Produkt- 1 Entwick- 1-6 Nur produkt- Marketing 3-9 Auswahl


manager lungsprojekte relevante Entwicklung
Regionen

Kaufm. Vor- 0 Projekt 0-4 0-3 Marketing 0-4 Alle


stand Produkte

Tabelle 3.6: Muster Hierarchie-Gliederungsmatrix für DWH-Anwender

Der Eintrag »0« bedeutet die Gesamtsumme bezüglich der Dimension. Die
Zahlen der Spalten »Stufe« geben die Stufe entsprechend der einzelnen Gliede-
rungen, wie sie oben angegeben wurden, an. Die erste Zahl ist dabei die höchste
Verdichtungsebene und die zweite Zahl gibt die feinste interessierende Detail-
lierung an.
Die erste Spalte zeigt die Hierarchieebene des Benutzers in der Unternehmens-
organisation an. Die zweite Spalte bezeichnet die Position des Benutzers.

3.4 Fortsetzungsbeispiel InDaWa


Einleitung
In diesem Schritt des Musterprojekts wird die Gestaltungs-Entscheidung
getroffen,
✔ welche betriebswirtschaftlichen Aufgaben das zukünftige Data Warehouse
übernehmen soll,
✔ welche betriebswirtschaftlichen Komponenten das DWH umfassen soll,
154 Kapitel 3 • Welche betriebswirtschaftlichen Komponenten hat ein DWH?

✔ welche Komponenten branchenspezifisch zu gestalten sind,


✔ welche Nutzerebenen einzubeziehen sind.
Es wurde noch nicht besprochen, wie diese Entscheidung dokumentiert wird,
deswegen eine kurze Bemerkung hierzu. Selbst wenn man nur den einen
Aspekt »betriebswirtschaftliche Architektur« betrachtet, hat man schon eine
schwer überschaubare Komplexität, die nach einer übersichtlichen Darstellung
verlangt. Das Darstellen der Erkenntnisse erfordert Regeln, ohne deren Einhal-
tung die Darstellung von der Realität zu weit abweichen würde. Diese Regeln
stehen in engem Zusammenhang mit der Darstellung und Verknüpfung ande-
rer Erkenntnisse auf dem Weg der Gestaltung. Es empfiehlt sich daher, diese
Darstellungsmöglichkeiten entlang einer Vorgehensfolge zu ordnen. Diese
Regeln und die Darstellungsmöglichkeiten sind Thema von Kapitel 7 »Das Vor-
gehensmodell für Data Warehouse Systeme«.

Beispiel
Das folgende Beispiel setzt auf der in Kapitel 1 getroffenen Entscheidung »ein
Data Warehouse für Schadensanalysen zur Optimierung der Instandhaltung
von Kraftwerken, Projekt InDaWa« zu implementieren, auf.

Beispiel: Betriebswirtschaftliche Komponenten der DWH-Schadensanalyse


Das beabsichtigte DWH soll über folgende Fragen Auskunft geben:
✔ Ist der Prozess der Instandhaltung der Kraftwerksanlagen zu verkürzen?
✔ Wirkt eine gemeinsame Lagerhaltung aller Kraftwerke kostenreduzie-
rend?
✔ Ist das Instandsetzungspersonal gut ausgelastet?
✔ Sind die verschiedenen anlagenbezogen Ereignisse früher zu erkennen
und kann man Ausfallprognosen erstellen?
Bezüglich des Musterprojekts sind damit folgende betriebswirtschaftlichen
Module betroffen:
✔ Instandhaltung, Materialwirtschaft, Lagerhaltung, Arbeitsplanung, Ereig-
nisverwaltung, Schadensanalysen, Personaleinsatzplanung, Anlagen-
struktur
Instandhaltungsdaten
➯ Alle BW-Module
➯ Instandhaltungsmodul
➯ Arbeitsaufträge
Bezüglich der Nutzerebene sind ermittelt:
Nutzerebene
➯ Kraftwerksleitung
➯ Instandhaltungsleitung,
➯ Schichtleitung
➯ Leitung Leittechnik
Kapitel 3 • Welche betriebswirtschaftlichen Komponenten hat ein DWH? 155

Die Branchenzuordnung bzw. die Branchengliederung ist bereits mit der


Wahl des Beispieles getroffen:
Branchengliederung
Industrie
➯ Versorgungsindustrie
➯ Energieversorger
➯ Kraftwerk
Die Regionalgliederung wird definiert entsprechend den Standorten der
Kraftwerke des Unternehmens. Die Optimierung der Ersatzteilhaltung soll
bundeslandübergreifend geschehen und auf die individuellen Unterschiede
der Standorte eingehen können. Eine Bundesland-Auswertung ist daher
uninteressant.
Regionalgliederung
Land: Bundesrepublik Deutschland
(➯ Bundesländer: Nordrhein-Westfalen, Niedersachsen, Hessen)
➯ Standorte: Hannover, Bremen, Hamburg, Essen, Köln,
➯ (Aus der Sicht des Versorgungsunternehmens sind Bremen
➯ und Hamburg der Region Niedersachsen zugeordnet.)
Aus der Erfahrung gibt es bezüglich des Verhaltens von Kraftwerken Tages-
verläufe und monatliche Perioden. Die Ereignisse werden alle mit Uhrzeit
erfasst, soweit das möglich ist. Die folgende Zeitgliederung wird gefordert,
um monatliche Perioden und Tageszeit-abhängige Belastungen feststellen
zu können:
Zeitgliederung
Jahr
➯ Monatsverläufe über das Jahr
➯ Tageszeiten in Stunden, Tagesverlauf
Hieraus ergibt sich die folgende Hierarchiegliederungsmatrix:

Ebene Region Funktion Anlagenteile

Name Stufe Name Stufe Name Stufe Name

GF-Versorg 0 bundesweit 0-1 BW-Module alle Gesamtanlage

KW-Leitg alle bundesweit 0-2 alle alle Gesamtanlage

Inst-Leitg alle bundesweit 1-2 Instandh alle Gesamtanlage

SchichtLtg 2 Kraftwerk 2 Inst-Aufträge alle Gesamtanlage

Schlosser -- -- --

Leittechnik- alle bundesweit 0-2 alle alle Gesamtanlage


Leitg

Tabelle 3.7: Hierarchiegliederungsmatrix InDaWa


156 Kapitel 3 • Welche betriebswirtschaftlichen Komponenten hat ein DWH?

Die operative Ebene (Schlosser) wird das System nicht einsetzen, sondern
die Erkenntnisse per Instandhaltungsauftrag umsetzen. Der Leiter der
Instandhaltung sowie der Leiter der Leittechnik sehen alle BW-Funktionen,
alle Kraftwerke des Landes und alle Anlagenteile-Ebenen. Die Geschäftsfüh-
rung des Versorgungsunternehmens wird nur die bundesweiten Erkennt-
nisse über alle Kraftwerke kennen. Projekte gibt es in diesem Zusammen-
hang keine. Die Spalte Produkte wurde durch Anlagenteile ersetzt.

Gestaltungsentscheidungen
Die herausgearbeiteten Gestaltungsentscheidungen des Projekts InDaWa sind
die Entscheidungen zum betriebswirtschaftlichen Umfang. Es sind dies die hie-
rarchischen Gliederungen, die später für die Verdichtung der Daten benötigt
werden, der betriebswirtschaftliche Umfang und die Branchenspezifität. Die
Ergebnisse werden in der folgenden Tabelle festgehalten.

Entscheidung/
Gestaltungsaspekt Erkenntnis Begründung

ARCHITEKTUR
Betriebswirtschafts-
komponenten
Fachkomponenten Instandhaltung Auftragsdefinition
Anlagenteile Ereignisdefinition
Materialwirtschaft Vorratsminimierung
Lagerhaltung Zustellungsoptimierung
Arbeitsplanung Auslastungsoptimierung
Ereignisverwaltung Ereignisanalyse
Schadensdaten Schadensanalysen
Personal Personaleinsatzplanung

Managementebene operative Managementebene Organisation der Erfassung von Schäden


taktische Managementebene Optimierung Lagerhaltung, Kostenreduktion

Branchengliederung bis Kraftwerk bis zur Bauteilebene kraftwerkstypisch


besondere Kostenstrukturen

Zeitgliederung Jahresverlauf in Monaten Belastungsvariation im Jahresverlauf


Tagesverlauf in Stunden Belastungsvariation im Tagesverlauf

Regionalgliederung Standorte KW sind standortindividuell


Landessummen uninteressant Ersatzteiloptimierung über alle Standorte
SOFTWAREKOMPONENTEN
...

Tabelle 3.8: Entscheidungschart in DaWa

3.5 Übungen
Übung 3.1: Betriebswirtschaftlicher Gestaltungsprozess
Durchlaufen Sie den Gestaltungsprozess mit den Ihrem Unternehmen eigenen
Angaben für ein ausgewähltes Fachgebiet oder einen Funktionsbereich.
Kapitel 3 • Welche betriebswirtschaftlichen Komponenten hat ein DWH? 157

Übung 3.2: DWH-Fragestellungen


Stellen Sie aus der Sicht ihres Unternehmens Fragestellungen an ein DWH
zusammen. Leiten Sie daraus die erforderlichen Basismodule ab und beurteilen
Sie, ob alle erforderlichen Daten in den Basismodulen zu finden sind.
Übung 3.3: DWH- Informationsquellen
Benennen Sie externe Informationsquellen zur Schließung der Datenlücken.
Bestimmen Sie die Managementebenen, die als Kunden der Data Warehouse
Module in Frage kommen, und leiten Sie daraus die betriebswirtschaftlichen
Funktionen ab. Definieren Sie Ihre Branchenzuordnung und leiten Sie daraus
branchenspezifische funktionale und fachinhaltliche Anforderungen ab. Ver-
wenden Sie dabei die im Kapitel vorgestellten Grafiken und Tabellen.
Übung 3.4: Referenzmodell
Erklären Sie, was ein »betriebswirtschaftliches Referenzmodell« ist, wie ein
Referenzmodell aufgebaut sein könnte, welche Referenzmodelle für Sie in
Frage kommen könnten und wie Sie ein Referenzmodell einsetzen würden.
Übung 3.5: Branchengliederung
Erklären Sie, was eine Branchengliederung ist, wie eine Branchengliederung
aufgebaut sein könnte, welche Branchengliederungen für Sie in Frage kommen
könnten und wie Sie eine Branchengliederung einsetzen würden.
Übung 3.6: Hierarchiegliederungsmatrix
Arbeiten Sie das folgende Kapitel »Beitrag zur Gestaltung des Musterprojektes«
durch und stellen Sie die zugehörige Hierarchiegliederungsmatrix auf.
Übung 3.7: Entscheidungsdurchlauf IT-Kategorie Betriebswirtschaft
Versuchen Sie mit Hilfe des Entscheidungsfeldes Betriebswirtschafts-Architek-
tur einen Entscheidungsdurchlauf mit folgenden Einschränkungen zu entwer-
fen:
✔ Für Betriebswirtschaftsmodule kommt nur Kostenrechnung für Industrie-
betriebe in Frage
✔ Kostenrechnung wird mit Marketing gekoppelt

3.6 Zusammenfassung der Entscheidungsgänge


Bereits in Kapitel 1 wurde, von der allgemeinen Kategorisierung ausgehend,
die Produktkategorie des Data Warehouse Systems festgestellt. Ein DWH ist ein
komplexes Informationssystem. Als komplexes Informationssystem kann das
DWH weiter nach IT-Kategorien zerlegt werden. Für jede IT-Kategorie ist ein
Entscheidungslauf mit mehreren Entscheidungsgängen erforderlich. Die erste
dieser IT-Kategorien ist die betriebswirtschaftliche Komponente. Wie in der
Grafik »Entscheidungsgang...« dargestellt ist, sind zur Festlegung der Ent-
158 Kapitel 3 • Welche betriebswirtschaftlichen Komponenten hat ein DWH?

scheidungen des Entscheidungslaufes der IT-Kategorie »betriebswirtschaftliche


Komponente« drei Entscheidungsgänge durchzuspielen:
✔ Betriebswirtschaftliche Funktionen
✔ Branchenspezifische Funktionen
✔ Hierarchiespezifische Funktionen
In der folgenden Grafik ist, als Beispiel für einen Entscheidungsgang, der Ent-
scheidungsgang der betriebswirtschaftlichen Komponenten durchgespielt.
Erster Entscheidungsgang
Im ersten Entscheidungsgang ist die allgemeine, branchenunabhängige
betriebswirtschaftliche Funktionalität zu bestimmen. Hierfür sind vier Schritte
durchzuspielen.

IT-Kategorie Erster Entscheidungsgang


Betriebswirtschaftl.
Komponenten 1. Schritt

Systemtyp
Kaufmännische
Funktionen 2. Schritt
Systemkompo-
nente
Kostenrechnung
3. Schritt

Systemmodul
Kostenarten-
rechnung 4. Schritt

Funktionen
Kostenrahmenplan
Übersicht Kostenart
elementare Kosten-
positionen

Abbildung 3.16: Erster Entscheidungsgang

Im ersten Schritt des ersten Entscheidungsganges wird auf der Ebene des
Systemtyps der betriebswirtschaftliche Funktionsrahmen (kaufmännisch,
technisch, bürotechnisch ...) abgegrenzt. Im obigen Beispiel wurde der System-
typ »kaufmännische Funktionen« ausgewählt.
Ist der Funktionsrahmen z.B. als »kaufmännische Funktionen« abgegrenzt,
kann dieser im zweiten Schritt weiter auf der Ebene der Komponenten detail-
liert werden. Zum Beispiel könnte die zum Systemtyp »kaufmännische Funkti-
onen« gehörige Komponente »Kostenrechnung« relevant sein.
Kapitel 3 • Welche betriebswirtschaftlichen Komponenten hat ein DWH? 159

Im dritten Schritt sind die funktionellen Anforderungen in Funktionsgruppen


oder Systemmodulen zu definieren, die durch die unterschiedlichen Aufgaben-
gruppen der Anwendergruppen der Kostenrechnung bedingt sind.
Im vierten Schritt ist die Funktion des Systems zu definieren, d.h. die funktio-
nellen Anforderungen, die durch die unterschiedlichen Aufgaben der Anwender
der Kostenrechnung bedingt sind.
Zweiter Entscheidungsgang
Je nach Branche des Unternehmens unterscheiden sich die Funktionen durch
branchenbedingte Ausprägungen. So ist z.B. für die Industrie für die Klassifi-
zierung von Kosten und damit auch von Kostenarten ein »Industriekostenrah-
men« üblich. Innerhalb der Branche »Industrie« haben sich wiederum je nach
Industriezweig detailliertere »Kostenrahmenpläne« z.B. für Energieversorger,
Fahrzeughersteller, Bauunternehmen, bewährt.

Funktionen
Industriekostenrahmen
Übersicht Kostenarten
Kostenbuchungen der
Fertigung

Abbildung 3.17: Zweiter Entscheidungsgang

Deshalb ist es erforderlich, nach dem vierten Schritt des ersten Entscheidungs-
ganges, also nach der Bestimmung der betriebswirtschaftlichen Funktionen,
deren charakteristische Ausprägung für die Branche in einem zweiten Ent-
scheidungsgang »Branchenzuordnung« festzustellen. Die funktionalen Anfor-
derungen bezüglich des Beispiels Kostenartenrechnung umfassen daher unter
anderem Industriekostenrahmen, Übersicht Kostenarten und Kostenbuchun-
gen der Fertigung. Hierbei wurde die Branchenspezifität auf den vierten Schritt
des ersten Entscheidungslaufes angewendet.
Die Branchenzuordnung kann sich schon auf den ersten Schritt des ersten Ent-
scheidungsganges auswirken. Deshalb ist zu empfehlen, den zweiten Entschei-
dungsgang schon beim ersten Schritt einzusetzen, also nicht erst bei dem
Schritt »Funktionen«.
Dritter Entscheidungsgang
In einem dritten Entscheidungsgang müssen die ebenenbedingten Anforde-
rungen, die Anforderungen der Nutzerebene, an die betriebswirtschaftliche
Funktionalität gefunden werden. So ist es z.B. für die Funktion »Kostendarstel-
lung« umso unwichtiger, die Details auf untersten Kostenebenen zu kennen, je
höher der Benutzer in der Hierarchie des Unternehmens positioniert ist.
160 Kapitel 3 • Welche betriebswirtschaftlichen Komponenten hat ein DWH?

Funktionen
Kostenrahmenplan
Übersicht Kostenarten
verdichtete Kostenpositionen

Abbildung 3.18: Dritter Entscheidungsgang

Die funktionalen Anforderungen bezüglich des Beispiels Kostenartenrechnung


umfassen daher unter anderem die geeignete Verdichtung der Kosten. Hierbei
wurde die Nutzerebene auf den vierten Schritt des ersten Entscheidungslaufes
angewendet.
Die schon besprochenen regionalen und temporalen Gliederungen stellen
heutzutage keine extra Anforderung an die Funktionalität, sondern an die
Daten. Da der Gestaltungslauf die Struktur des DWH bestimmen soll, sind diese
Informationen nicht in der Grafik als »Systemtyp« integriert worden.
Die verschiedenen Systemtypen-Elemente sind unterschiedlich tief zu detaillie-
ren. Dies liegt im Ermessen des DWH-Spezialisten. Diese unterschiedlichen
Detaillierungsgrade bringt die folgende Grafik durch die unterschiedliche Auf-
teilung der Boxen zum Ausdruck. Die Grafik gibt nicht in allen Detaillierungs-
stufen eine vollständige Klassifikation, sondern sie beschränkt sich der Über-
sichtlichkeit und der Erkenntnis des Zerlegungsprinzips zuliebe, auf die
wichtigsten Unterteilungen (siehe Abbildung 3.19).
Kapitel 3 • Welche betriebswirtschaftlichen Komponenten hat ein DWH? 161


    

   


 
     
   



 

 
    
!

 () 
*
  "   ! 
  
+ ! 
! 
 
!  
  2 
  !  
 
 
& 
1! 
.! 
 ! 

  "# $
 " 
0  
!   
-  1! 
  

+
"
 ! " %  


       
  
$ 
 !
 
 ! 
$     
 "!  %  '
! 
/ %  

&' % $! %
    ! 32 
   
 

  

  

  
 
$! ! 

  $! %
+   1'
 ,
 
- #
 . $
  

    /! 
  
  +! 
0!  $ 
 
 
))))))) 
  
 
 
   


   




 
 
     

  

 

Abbildung 3.19: Entscheidungsgang Data Warehouse Architektur: Betriebswirtschaftliche Komponenten


163

KAPITEL 4
4 Welche Softwarekomponenten sind für ein
DWH einzusetzen?
Einleitung
Alles bisher Gesagte war noch so allgemein, dass es nicht nur für Data Ware-
house, sondern ganz allgemein für alle komplexen Datenbankanwendungen
gültig ist. Jetzt stellt sich die Frage, welches denn die Besonderheiten sind, mit
denen sich ein DWH von anderen komplexen EDV-Systemen unterscheidet.
Einen Unterschied konnte man bisher erkennen: Basissysteme sind für sich
alleine anwendbar. Ein DWH baut auf Basissystemen auf, bezieht von Basissys-
temen Daten. DWH sind damit nur so gut wie die Daten der Basissysteme. Das
heißt aber auch, das DWH muss Funktionen bieten, die Basissysteme nicht
bieten können.
Neben den Softwarekomponenten mit betriebswirtschaftlichen Aufgaben gibt
es Software, die zum Umgang mit den Daten unabhängig von ihrer betriebs-
wirtschaftlichen Bedeutung nützlich ist. Diese Software enthält Funktionen,
die Daten wie Werkstücke suchen, bereitstellen, bearbeiten und weitergeben
lassen. Wegen dieses Werkzeugcharakters nennt man diese Art von Software
Tools. Ein DWH unterscheidet sich durch seine Ausstattung an solchen Tools
von den Basissystemen. Ein Kapitel ist deshalb diesen Tools oder Komponenten
des DWH gewidmet.
Die besonders wichtigen speziellen DWH-Systeme Online Analytical Proces-
sing System (OLAP) und Knowledge Discovery on Databases System (KDD)
werden in Unterkapiteln ausführlicher dargestellt.
Ein DWH-System enthält Funktionen zur Findung, Verwaltung, Transforma-
tion, Auswertung und Präsentation von Daten, die andere Datenbankanwen-
dungen nicht bieten. Diesem Gesichtspunkt der Funktionalität der DWH ist ein
Abschnitt dieses Kapitels gewidmet. Einige besondere Funktionen, die auf die
Abbildung komplexer Zusammenhänge in umfangreichen Datenmengen fokus-
sieren, sind ausführlich beschrieben.
Die DWH-Komponenten können auf verschiedene Weise hergestellt werden.
Sie können von einem Hersteller als Fertigprodukt und Standardlösung oder
von vielen verschiedenen Herstellern als kombinierbare und zusammenbau-
bare Einzelstücke geliefert oder als auszuprogrammierende Individuallösung
gekauft werden. Die Komponenten können fachspezifisch ausgeprägt und für
Verteilungszwecke in unterschiedlich große Einzelkomponenten, lauffähig für
unterschiedliche Rechnertypen, zerlegt sein. Deshalb wird diesem als Techno-
logietypus bezeichneten Aspekt ebenfalls ein Abschnitt gewidmet.
164 Kapitel 4 • Welche Softwarekomponenten sind für ein DWH einzusetzen?

Die folgende Abbildung zeigt den Kapitelaufbau.

 


 













 !






Abbildung 4.1: Aufbau des Kapitels Softwarekomponenten

Verschiedene Übersichten über Komponenten, Teilsysteme und verwandte


Ansätze zu Data Warehouse Systemen sind in folgenden Büchern zu finden:
 Chamoni, Analytische Informationssysteme
 Glukowski, Management Support Systeme
 Sing, Data Warehousing

Lernziel
Die Lernziele, die hier angestrebt werden, sind das Verständnis dieser Software-
komponenten, der Funktionalität aus der Sicht der drei Nutzerebenen und der
Bedeutung für die unterschiedlichen Aufgaben im Unternehmen.


Lernziele
Erklären können, was ein Data Warehouse ist, und welche dem DWH


ähnliche Systeme es gibt


Überblick gewinnen über die Komponenten, aus denen ein DWH besteht


Verstehen des Aufbaus eines DWH-Referenzmodells


Verstehen der funktionalen Prinzipien der DWH-Komponenten


Spezifikation auf Komponentenebene beherrschen


Überblick gewinnen über DWH-Tools und deren Eigenschaften
Vor- und Nachteile der softwaretechnischen Fertigungstypen beurteilen


können


Kennen des Funktionsumfanges eines Data Warehouse
Kennen des Aufbaus eines OLAP-Systems
Kapitel 4 • Welche Softwarekomponenten sind für ein DWH einzusetzen? 165



Kennen des Aufbaus eines Knowledge-Discovery-Systems


Definieren der zwölf Codd'schen OLAP-Regeln
Unterscheiden zwischen OLAP und OLTP

4.1 Die softwaretechnischen Komponenten und Tools des DWH


Einleitung
Die Komplexität eines DWH ist auch aus der Sicht der am Markt etablierten
Produkte so groß, dass die Hersteller das komplexe Softwaresystem nicht mehr
wie in früheren Zeiten als »Programm-Monolith« ausliefern. Das DWH wird
fast immer als ein über mehrere Komponenten oder Module zusammengesetz-
tes, getrennt voneinander erwerbbares System angeboten.
Die Thematik der softwaretechnischen Komponenten wird im folgenden Kapi-
tel am Beispiel eines Entscheidungsunterstützungssystems dargestellt.
Softwarekomponenten eines Entscheidungsunterstützungssystems
Ein Ansatz des Data Warehousing ist der Blick auf die Tätigkeit »Entschei-
dung«. Ein Beispiel für ein solches aus Komponenten zusammengesetztes Sys-
tem mit Blick auf die Tätigkeit »Entscheidungen treffen« zeigt die Abbildung
eines frühen Vorgängers des Data Warehouse, ein Decision Support System
oder Entscheidungsunterstützungssystem aus
 Spraque, Decision Support System.
Man kann hier schon die Absicht erkennen, aus verschiedenen Informations-
quellen Daten zu beziehen. Es werden interne und externe Datenbanken und
auch Dokumente aus Archivierungssystemen abgefragt. Die internen Daten
sind entsprechend der Funktionsbereiche (Finanzierung, Produktion, Marke-
ting, Personal) des Unternehmens in Gruppen oder Teildatenbanken abgelegt.

  
 
 
 



 
 
 


   
  


  
      

 




 

  
 
 





 



Abbildung 4.2: Softwarekomponenten eines Entscheidungsunterstützungssystems


166 Kapitel 4 • Welche Softwarekomponenten sind für ein DWH einzusetzen?

Das wesentliche Charakteristikum des Entscheidungsunterstützungssystems


gegenüber einem Basissystem mit Datenbankanwendung ist die Modellbildung
auf der Basis der Datenmengen. Deutlich zu erkennen ist auch das Konzept der
Ebenen-Orientierung der Benutzer (strategisch, taktisch, operativ).
Des weiteren steht eine Komponente mit Methoden zur Entscheidungsfindung
zur Verfügung, die über eine Dialogführungskomponente mit den Datenbank-
management- und dem Modellmanagementsystem verbunden ist. Im Modell-
managementsystem werden betriebswirtschaftliche Modelle wie Formel-Kaska-
den, Statistiken und logische Regeln verwaltet.
An diesem Ansatz wird die Komponentenstruktur eines Softwaresystems aus
dem Bereich der DWH Systeme schon sehr deutlich.
Die Thematik der softwaretechnischen Komponenten wird im Folgenden am
Beispiel der Softwarearchitektur eines Chefinformationssystems dargestellt.
Komponenten der Softwarearchitektur eines Chefinformationssystems
Das DWH ist ein Anwendungssystem, das teilweise auf einem Arbeitsplatz eines
Benutzers läuft. Um das DWH aus der Sicht der Komponenten für den Arbeits-
platz zu gestalten, wurde das Modell für den Chef-Arbeitsplatz, das Chefinfor-
mationssystem, entwickelt.
Ein Beispiel für ein solches aus Komponenten zusammengesetztes, positionso-
rientiertes Informationssystem, das auf einer Datenbasis arbeitet, ein Informa-


tionssystem der Position »Chef«, zeigt
Bullinger, Data Warehouse
Das Modell von Bullinger ist ein Vorschlag zur Lösung der Frage »Wie muss ein
System aufgebaut sein, das ein Chef des Unternehmens, bzw. ein Mitarbeiter
der obersten Führungsebene, benötigt?«. Dieses Modell umfasst neben den
DWH-Komponenten auch Officekomponenten und Kommunikationskompo-
nenten und ist damit ein integratives Modell.
Bei diesem Modell ist der Tatsache, dass der Position entsprechend eventuell
verschiedene Benutzertypen mit dem System arbeiten müssen, besonders
Rechnung getragen. Diese Fähigkeit liefert eine Komponente, die Benutzermo-
delle verwaltet: das »mentale Managermodell«. Benutzermodelle umfassen
dabei zum Beispiel Ausschnitte aus der Gesamtfunktionalität, Zugriff auf ausge-
wählte Komponenten, relevante Ausschnitte aus dem Datenpool, Erlaubnispro-
file und persönliche Einstellungen von Menüleisten und Oberflächen (siehe
Abbildung 4.3).
Kapitel 4 • Welche Softwarekomponenten sind für ein DWH einzusetzen? 167

  



   



       




 

   
  
  
  
 

#$ !" 
 
%


Abbildung 4.3: Komponenten der Softwarearchitektur eines Chefinformationssystems

Assistentenmodell der GMD


Das DWH ist ein Anwendungssystem, das mit einer Komponente auf einem
Arbeitsplatz dem Benutzer mit Diensten und Benutzungsauskünften assistiert.
Um das DWH aus der Sicht dieser assistierenden Komponenten zu gestalten,
wurde das Assistentenmodell der Forschungsgesellschaft GMD, der Gesell-
schaft für Mathematik und Datenverarbeitung, entwickelt.
Im Assistentenmodell der GMD wird der Aspekt des unterschiedlichen Bedarfes
der unterschiedlichen Benutzer an verschiedenen, sich der jeweiligen Situation
anpassenden Hilfesystemen besonders Rechnung getragen.
Das System des GMD-Modells ist eine Sammlung von bei Bedarf assistierenden
Programmen, sogenannten »Assistenten«. Assistenten sind intelligente Pro-
gramme, die sich auf Situationen und Nutzerverhalten einstellen können und
eine Auswahl von angemessenen Diensten, Informationen und Ratschlägen
anbieten. Die Assistenten sind in mehrere Gruppen eingeteilt, die sich wie-
derum über drei Ebenen verteilen.
Die erste Ebene besteht aus drei Gruppen. Eine Gruppe steht für Eingabemög-
lichkeiten aus unterschiedlichen Quellen, auf unterschiedlichen Datenträgern,
mit unterschiedlichen Formaten. Die zweite Gruppe ist zuständig für Ausgaben
zu verschiedenen Geräten. Die dritte Gruppe ist die Oberfläche für die Präsenta-
tion oder symbolische Darstellung aller Einheiten, Geräte und Funktionen. Die
zweite Ebene wird gebildet durch die eigentlichen funktionalen Assistenten für
Büroaufgaben, Fachaufgaben und Kommunikationsaufgaben. Die dritte Ebene
168 Kapitel 4 • Welche Softwarekomponenten sind für ein DWH einzusetzen?

umfasst die Dokumentationsdienste, Kommunikationsdienste und die System-


basis mit Datenbanken, Entwicklungswerkzeugen und Zugriffen zu Betriebs-
systemfunktionen.

       



 
         

  
   
        
     
      
    
     !   
   
 

    !   "  #    


 +
!   + 
  *
  
 #    $   $ & $ 
    .      
    +     $ 
 ,   -   /
 )!
  

       


 "      )  

      &  
 #  (     *)'  "%&"
    '
 $  & 

 

Abbildung 4.4: Assistentenmodell der GMD

Das Assistentenmodell enthält viele Funktionen, die für ein DWH System
unentbehrlich, aber nicht speziell auf das DWH ausgerichtet sind.
Data Warehouse Ansatz
Jeder der vorgestellten Ansätze liefert einen wichtigen Beitrag für DWH-Lösun-
gen. Die verschiedenen hier vorgestellten Modelle werden nun zu einem Kon-
zept, dem DWH-Referenzmodell, zusammengeführt. Einige der vorgestellten
Modelle umfassen Office-Funktionen und Kommunikationsfunktionen, andere
Modelle wiederum nicht. Einige der Modelle enthalten Fachmodelle, andere
sind fachneutral ausgestattet. Man sieht auch, dass einige Modelle die Datenba-
sis umfassen und andere die Datenbasis mit den Grunddaten ausschließen. Man
kann aber auch die Gemeinsamkeiten dieser Modelle erkennen: Alle Systeme
haben Entscheidungsunterstützung, die auf verschiedene Benutzertypen und
besonders die Benutzer der Führungsebenen zugeschnitten ist.
Kapitel 4 • Welche Softwarekomponenten sind für ein DWH einzusetzen? 169

Man kann also einen Data Warehouse Ansatz im engeren Sinne und einen Data
Warehouse Ansatz im weiteren Sinne feststellen.

Definition
Das Data Warehouse im engeren Sinn umfasst die Replikation vorhandener
Daten in einem DWH-Server mit Auswertungs- und Darstellungswerkzeu-
gen.
Das Data Warehouse im weiteren Sinn umfasst den gesamten Datenhaushalt
der Unternehmung, verdichtet, repliziert, unverdichtet, in elektronischen
Dokumenten vorliegend genauso wie in Files und Datenbanken, die Ergono-
mie-Funktionen ebenso umfassend wie die Auswertungs-, Analyse- und
Betriebswirtschaftsfunktionen.

Der umfassende Ansatz des DWH im weiteren Sinnn ist für die Evaluation von
neuen Produkten nützlicher, da er alle in Frage kommenden Kriterien umfasst
und dies, anders als bei Kriterienlisten anderer datenbank-basierter Informati-
onssysteme, aus der Sicht des DWH.

4.1.1 DWH-Referenzmodell
Allgemeines
Das DWH-Referenzmodell ist eine gute Vorlage für die Auswahl der Software-
komponenten des DWH. Zur Erklärung seien die Komponenten kurz und über-
sichtlich in der Folge von oben nach unten aus der Sicht des Benutzers vom
Desktop aus beschrieben.
Nicht jede Komponente ist für jedes Problem gleich gut geeignet, und nicht
jede Komponente wird gebraucht. Deshalb bieten die Hersteller Komponenten-
auswahl und Kombination an, mit der Möglichkeit, bei einer Änderung der
Anforderungen das DWH mit weiteren Komponenten nachzurüsten. Zu bestim-
men ist dabei, welche der Komponenten für eine bestimmte Problemstellung
am geeignetsten ist, und ob die Auswahl der Komponenten kombinierbar ist.
Die Gestaltungsaufgabe ist gelöst, wenn die Aufzählung der den erhobenen
Anwenderbedarf abdeckenden Module bzw. Komponenten vollständig ist.
Einige der genannten Komponenten finden nicht nur als Komponenten in
einem kompletten DWH-System Verwendung. Sie sind auch als zentrale Kompo-
nenten in verwandten kleineren Informations-Systemen enthalten, die vor dem
umfangreicheren und integrierenden DWH-Konzept bereits bekannt waren. Sol-
che Systeme sind zum Beispiel OLAP-System Executive Information System,
Knowledge Discovery System und Decision Supporting System. Soweit die Kom-
ponenten dieser Systeme noch nicht integriert sind, lässt sich vermuten, dass
deren Integration im Zuge der Zeit noch stattfinden wird, da die Hersteller die-
selben sind. Das hier vorgestellte »Referenzmodell für Data Warehouses« kommt
dem umfassenden Data Warehouse Ansatz, dem DWH im weiteren Sinne, nach,
indem es die sinnverwandten Komponenten mit aufnimmt.
170 Kapitel 4 • Welche Softwarekomponenten sind für ein DWH einzusetzen?


 
! " ' ,.#$

 )"
 ! + ! " 

"- "+ 
 ,    

 
 ,,# 
"  "  

  
   

        *  
        

% 
 

%
  !

       



      
 
 
 

 

       


 

*  *  *  *  (% *  *  * 


  

 &! "


    ( ' #$  

!  #$ %     #$  '
 
    
  
Abbildung 4.5: Referenzmodell des Data Warehouse

Das hier vorgestellte »Referenzmodell für Data Warehouses« ist eine aus den


Aufsätzen von
H.-D. Goffmann und von M. Tresch sowie M. Rys aus HMD, Seite 13 und
Seite 60,
weiterentwickelte Auffassung.
Im DWH-Referenzmodell sind alle möglichen Komponententypen zusammen
mit ihren Beziehungen zu den Nachbarkomponenten enthalten. So wird das
Kapitel 4 • Welche Softwarekomponenten sind für ein DWH einzusetzen? 171

Zusammenspiel der Komponenten, ihre Vernetzung, ersichtlich. Das Referenz-


modell zeigt die Notwendigkeit von kooperierenden Komponenten an, z.B. ob
für den Zugriff einer Komponente A auf eine Komponenten B eine vermittelnde
Komponente erforderlich ist. Weitere Data Warehouse Referenzmodelle sind


auch enthalten in:


von Hummeltenberg, in Martin, Data Warehousing, Seite 62


Kurz, Data Warehousing
Muksch u.a., Data Warehousing

4.1.2 Komponenten des DWH-Referenzmodells


DWH-Komponenten der Benutzerführung
Das DWH benötigt die folgenden Komponenten der Benutzerführung:
Navigator Der Navigator dient zur Suche von Datenfiles und
Programmen (die ja selbst auch wieder Files sind).
Der Navigator zeigt Strukturen der System- und
der Datenorganisation und erlaubt, ein Suchumfeld
schrittweise einzuschränken und ausgehend von
einem Treffer einer Suche andere Suchwege zu
beschreiten.
Customizer Der Customizer dient zur Anpassung der Benut-
zeroberfläche. Der Customizer stellt eine Menüge-
staltungsmöglichkeit mit Umplatzierung von Icons,
Erweiterung der Menüleisten, Integration neuer
Menüpunkte, Verändern der Farbdarstellung und
Schriftgrößen zur Verfügung.
Benutzerprofiler Der Benutzerprofiler dient zur Formulierung des
Benutzermodells. Der Profiler stellt eine struktu-
rierte Beschreibungsmöglichkeit mit Klassifizie-
rungsfähigkeiten zur Verfügung. Die Tendenz der
Technologien der Ebene der Benutzerführung geht
in Richtung der komfortablen Unterstützung des
Benutzers durch intelligente Agenten. Agenten sind
Programme, die das Benutzerverhalten erkennen
und typischen Unterstützungsbedarf ableiten und
sich danach selbst optimal für dieses Benutzerver-
halten konfigurieren. Der Fähigkeit liegt oft ein
sogenanntes Benutzermodell zugrunde, eine Meta-
struktur, die der Beschreibung eines Nutzers dient.
Browser Der Browser dient zur Anzeige von Webseiten und
zur Navigation zwischen Webseiten. Der Browser
bedient sich auch einiger Zugriffsfunktionen.
172 Kapitel 4 • Welche Softwarekomponenten sind für ein DWH einzusetzen?

Kommunikationsassistent Der Kommunikationsassistent dient zur Unterstüt-


zung der Kommunikation mit anderen Benutzern.
Der Kommunikationsassistent stellt Namenslisten,
Adressbücher mit Kommunikationsadressen und
Editoren für die Gestaltung von Nachrichten für
verschiedene Kommunikationsformen zur Verfü-
gung.
Groupworkassistent Der Groupworkassistent dient zur Unterstützung
der Zusammenarbeit von Benutzern. Der Group-
workassistent erlaubt die gemeinsame Bearbeitung
eines Dokuments durch mehrere Benutzer. Er stellt
Eigentums- und Bearbeitungshinweise zur Verfü-
gung.

DWH-Komponenten der Informationsveredelung


Die Daten des Data Warehouse werden besonderen Analyse- und Berechnungs-
methoden unterzogen, um auch nicht offensichtliche Folgerungen und Exper-
tenkenntnisse abzuleiten.
Formelgenerator Der Formelgenerator dient zur Formulierung
mathematischer Formeln, der Zuweisung von Wer-
ten zu den Variablen und zur Koppelung von For-
meln mittels Programmierbefehlen. Neben der
Eigenerstellung von Formeln gibt es Bibliotheken
mit mehr oder weniger komplizierten Formeln bis
hin zu statistischen Programmen.
Aggregator Der Aggregator dient zur Formulierung von Gliede-
rungen, der Zuweisung von Werten zu den Gliede-
rungspunkten und zur automatischen Aggregation
der Werte.
Makroprozessor Der Makroprozessor dient zur Formulierung klei-
ner interaktiver Programme auf dem Desktop
durch Aufzeichnen einer Folge von Bearbeitungs-
schritten oder Formulierung der Schritte mit Pro-
grammiersprache in einem Editor. Die Bearbei-
tungsschritte sind dann nicht nur wie beim
Formelgenerator mathematische Prozesse, sondern
umfassen beliebige Bedienungselemente.
Knowledge Discovery Die Knowledge Discovery on Databases Kompo-
nente, kurz KDD, ist wieder eine Kette von Kompo-
nenten zum Auffinden und Aufbereiten von Daten,
zum Entdecken von Wissen auf Grund von Angaben
allgemeiner Bedingungen und zur Entdeckung von
logischen Zusammenhängen dieser Daten. Das
Kapitel 4 • Welche Softwarekomponenten sind für ein DWH einzusetzen? 173

eigentliche Entdecken von Wissen nennt sich Data


Mining. Der Data Mining Prozess wird mittels Soft-
warekomponenten und mitunter sogar mit eigenen
Rechnern mit besonderer Hardware unterstützt, die
Neuronale Verarbeitung simulieren (Neuronale
Netze) und mit ungenauen Werten (Fuzzy Sets)
arbeiten können.
Der Data Mining Prozess wird im folgenden Kapitel ausführlicher beschrieben.
Fuzzy Set Analyse In konventionellen Abfragesystemen muss genau
angegeben werden, was gesucht werden soll. Unge-
naue Abfragen können nicht ausgeführt werden.
Auswertungen aufgrund ungenauer Abfragen sind
daher nicht möglich. Fuzzy-Systeme erlauben
ungenaue Anfragen.
Neuronale Netze Die Komponente Künstliches Neuronales Netz
setzt die Erkenntnisse des Lernens von (biologi-
schen) Neuronensystemen ein. Neuronensysteme
lernen aus der wiederholten Eingabe von
Ursprungsdaten und ihren zugehörigen Lösungsda-
ten, wie ein Algorithmus aussehen könnte, der die
Lösungsdaten aus den Ursprungsdaten erzeugt. Der
Algorithmus beschreibt dann die gesuchte Gesetz-
mäßigkeit einer Datenmenge.
OLAP Für das Online Analytical Processing, kurz OLAP,
dient ein System mit einer Server-Komponente,
dem OLAP-Server, und einer Client-Komponente,
eine Komponente mit einer Datendarstellung in
Form eines multidimensionalen Würfels. Die Dar-
stellung und ihre Präsentation auf dem Bildschirm
erlaubt einfaches Anlegen von Verdichtungshierar-
chien, Wechsel der Würfelansicht und Auswahl von
Würfelebenen. Das OLAP-System wird im folgenden
Kapitel ausführlicher beschrieben.
Simulator, Animator Mit Simulationsprogrammen wird eine Menge mit-
einander verknüpfter mathematischer Formeln mit
Beispielwerten durchgerechnet und die Ergebnisse
in mehreren zueinander in Beziehung stehenden
Grafiken dargestellt. Mit einem Animator können
die Eingangsgrößen der Berechnung kontinuier-
lich verändert werden, bei unmittelbarer Anzeige
der Veränderung der Ergebniswerte.
Officetools Die Officetools sind ein weit verbreitetes Pro-
grammset für Textverarbeitung, Kalkulationstabel-
174 Kapitel 4 • Welche Softwarekomponenten sind für ein DWH einzusetzen?

len, Kleindatenbanken, Grafikerzeugung, Präsenta-


tionsprogrammen und Dokumentenmontage.
Statistiktools Die Statistiktools sind eine Sammlung von mathe-
matischen Programmen für die Berechnung von
Zusammenhängen zwischen Daten wie Korrelatio-
nen, Verteilungen und Abweichungen von Werten.
Statistikprogramme sind mit vielfältigen grafischen
Darstellungen von Datenmengen in Koordinaten-
systemen ausgestattet.
Filter Mit Filterprogrammen kann ein gesamter Befehls-
vorrat auf einer Datenmenge mit einer durch eine
Filtereigenschaft eingegrenzten Menge operieren.
Mit Filtern können z.B. Qualitätsanforderungen an
die Daten gestellt werden.
Expertensystem Das Expertensystem ist ein System zur Definition
logischer Regeln, zur Verknüpfung von Aussagen,
Findung von Schlussfolgerungen und zur Prüfung
und Auswertung von Daten entsprechend den logi-
schen Regeln. Die Regeln arbeiten mit einer Fak-
tenbasis zusammen und lassen Aussagen über neue
Fakten und Regeln gewinnen.

DWH-Komponenten der Datenhaltung


Die Daten des Data Warehouse benötigen genau wie alle anderen Datenbankan-
wendungen auch eine Komponente zur Ablage und Aufbewahrung, die Daten-
haltung und eine Komponente zur Verwaltung der Daten, das Datenmanage-
ment. Neben der Haltung der reinen Daten kommt beim DWH noch die
Verwaltung von besonderen Daten, den Metadaten, dazu. Metadaten dienen zur
Beschreibung von anderen Daten und Zusammenhängen.
DWH-Datenbank Die zentrale Komponente des DWH ist die DWH-
Datenbank, in der alle aktuellen Daten aufbewahrt
werden. Die Datenbank ist entweder ein marktübli-
ches austauschbares Produkt aus der Gruppe der
relationalen Datenbanken oder eine proprietäre
Entwicklung des Herstellers, meist eine sogenannte
multidimensionale Datenbank, neuerdings auch
objektorientierte Datenbank. Die Datenbank kann
mehrere Datenbanken für spezielle Datentypen
umfassen, z.B. für Fuzzy Sets, Multimedia-Daten,
Multidimensionale Würfel.
DWH-DBMS Die Verwaltungsfunktionalität der DWH-Datenbank
stellt das Datenbankmanagementsystem, kurz
DBMS, zur Verfügung. Da das DWH mit einer übli-
Kapitel 4 • Welche Softwarekomponenten sind für ein DWH einzusetzen? 175

chen Datenbank ausgestattet ist, hat ein DWH-


DBMS die gleiche Funktionalität, die auch jedes
andere DBMS besitzt. Dies sind die Einrichtung der
Benutzerberechtigung, die Definition des Daten-
bankschemas, Funktionen zur Pflege und Siche-
rung der Daten und für das Tuning des Datenbank-
verhaltens bei Abfragen und Eingaben.
Data Mart Das Data Mart ist ein kleiner Ausschnitt eines
DWH, der nur für einen speziellen Unternehmens-
bereich interessant ist, aber in Funktionalität und
Ergonomie dem gesamten DWH entspricht. Ein
solcher Ausschnitt kann z.B. alle Daten einer
Region oder eines Produktbereichs umfassen. Data
Marts können variabel vergrößert und verkleinert
werden. Mit Hilfe der Einrichtung von Data Marts
kann der gesamte DWH-Umfang regional verteilt
werden. Der Begriff Data Mart ist unpräzise und
sollte nicht weiter verwendet werden. Viel nützli-
cher ist statt dessen die Bezeichnung nach dem
konkreten Ausschnitt aus dem DWH, also regional
z.B. als Europa-DWH oder funktional z.B. als
Marketing-DWH.
Modellkomponente Die Modellkomponente dient zur Formulierung
betriebswirtschaftlicher Modelle mittels mathema-
tischer Formeln sowie Kombinationen dieser For-
meln zu Formelketten oder Formelbäumen. Die
Modelle müssen genau wie »normale« Daten einge-
richtet, verwaltet, vor unbefugten Zugriffen
geschützt und gegenseitig stimmig oder konsistent
gehalten werden. Dafür ist die Komponente Modell-
Administrator erforderlich.
Archiv Je größer die Datenmenge in der Datenbasis des
Data Warehouse ist, umso länger dauern die
Zugriffe. Die Datenmenge wächst im Laufe der Zeit
mindestens proportional an. Einige große Unter-
nehmen müssen Datenmengen im Terrabytebereich
(1012 Byte = 1.000 Gigabyte) bewältigen. Für die
aktuelle Arbeit sind meistens nur aktuelle Daten
von Bedeutung. Deshalb sollen diese einen schnel-
leren Zugriff erlauben als die weniger oft benötig-
ten älteren Daten. Um die Datenbank von der
Menge der alten Daten zu entlasten, werden diese
vom Sekundärspeicher in einen Tertiärspeicher, ein
Archivsystem, ausgelagert. Wenn Trend-Analysen
oder andere über historische Daten erforderliche
176 Kapitel 4 • Welche Softwarekomponenten sind für ein DWH einzusetzen?

Auswertungen anstehen, werden die archivierten


Daten kurzfristig im Sekundärspeicher zur Verfü-
gung gestellt.
Integrator Mit einem Integrator werden die Daten von den
verschiedenen Datenquellen in verschiedenen For-
maten mit verschiedenen Bezeichnungen in ein
einheitliches Format überführt und einer einheitli-
chen Bezeichnung zugeordnet.

DWH-Komponenten der Zugriffsschicht


Dem Zugriff auf Daten eines Fremdsystems durch unterschiedlichste Hardware
und Netzstrecken und über verschiedene Betriebssysteme dienen Middleware-
komponenten. Middlewarekomponenten dienen zum Anzeigen der Daten eines
Fremdsystems mit Hilfe eines Monitors, sie dienen dazu, die interessanten
Strukturteile auszuwählen, die Daten dieser Strukturteile auszulesen und über
eine Infrastruktur-Verbindung an das fragende System zu übermitteln.
Die Middlewarekomponenten werden immer an den Schnittstellen zwischen
verschiedenen Komponenten benötigt. In erster Linie ist dies beim Zugriff auf
die verschiedenen Datenquellen erforderlich. Mittels Middleware wird das
Beschreibungsschema der Datenquelle in das Beschreibungsschema der Daten-
senken im DWH transformiert. Das hat gewisse Tücken. Wenn z.B. die Quelle
eine hierarchische DB ist und das DWH auf einer relationalen Datenbank auf-
baut, müssen hierarchische Strukturen widerspruchsfrei auf relationale Struk-
turen übertragen werden. In Kapitel 7 »Vorgehensmodell« ist am Beispiel der
Abbildung eines Würfels in verschiedenen Strukturen die Problematik darge-
stellt.
Monitor Der Monitor ist ein Programm, das in der Lage ist,
die Daten einer Datenquelle auf dem Bildschirm in
einer formatierten Form anzuzeigen. Der Monitor
versteht Eingaben, die ihn veranlassen, die gesuch-
ten Daten zu finden und zu präsentieren. Der
Begriff kommt aus dem Umfeld der Online Transac-
tion Processing Systems, kurz OLTP, auch kurz
als Transaktionssysteme bezeichnet. Es gibt SQL-
basierte Monitore für die Anzeige des Schemas
einer relationalen Datenbank, das sind Directory-
Editoren für die Einrichtung und die Anzeige der
baumartigen Strukturen von Dokumentenverzeich-
nissen. Zu jedem Datenverwaltungsprogramm wer-
den spezielle Monitore hergestellt und mitgeliefert.
Browser Der Browser ist ein spezielles monitorähnliches
Hilfsprogramm, das zusammen mit einer Web-Such-
maschine auf Web-Servern programmierte »Infor-
mationsseiten« findet und auf dem Monitor zur
Kapitel 4 • Welche Softwarekomponenten sind für ein DWH einzusetzen? 177

Anzeige bringt. Die Präsentationsschicht der Brow-


ser ist in Desktop-Betriebssysteme integriert. Der
Browser stößt Suchprozesse auf Web-Servern an.
Prozessmonitor Ein anderer spezieller Monitor ist der über physika-
lische Sensoren mit einem Produktionsprozess
gekoppelte Prozessmonitor. Die Prozessdaten fal-
len in Form analoger Signale an und werden von
einem Wandler in digitale Daten umgesetzt und an
den Integrator weitergeleitet.
Videomonitor Auch die Anzeige von Nachrichtensendungen,
Reportagen und Fachsendungen, wie sie vom Fern-
sehen her bekannt sind, können wichtige digital
weiterzuverarbeitende Informationen enthalten.
Bilder können mit Mustersuche auf Bildinhalte
durchsucht werden, in Bildern kann nach Texten
recherchiert werden, in akustisch angezeigten
Reden kann nach Worten gesucht werden. Nach-
richten sind mit Text, Ton, Bild und Bewegungsda-
ten multimedial. Für die Darstellung dieser Audio/
Videodaten ist ein besonderer Monitor, ein Video-
monitor erforderlich.
Web-Suchmaschine Nicht alle Informationen sind bereits auf bekannten
Servern vorhanden. Eine große, eigentlich nicht
mehr auszunutzende Menge von Informationen
sind auf den unzähligen Servern des Internet, im
World Wide Web, kurz WWW, verteilt. Damit steht
nicht mehr die Suche nach der Information im Vor-
dergrund, sondern die Suche nach Informationen
darüber, wo die eigentliche Information gefunden
werden könnte, die Metainformation. Für die Verar-
beitung von Metainformationen stehen Suchma-
schinen im Internet zur Verfügung. Die Suchma-
schinen erstellen automatisch in periodischen
Zeitabständen Kataloge über die Orte von Informa-
tionen. Benötigt man eine spezielle Information,
liest man aus dem Katalog die möglicherweise inte-
ressanten Quellen ab und beauftragt die Suchma-
schine, die Datenquelle anzusprechen und die frag-
lichen Informationen zu liefern. Die Anzeige der
gefundenen Informationen geschieht im Browser.
Metasuchmaschine Die Web-Suchmaschinen liefern allerdings, so zeigt
die Praxis, jeweils nur ca. 30% der möglichen Quel-
len, aber keine identischen Ergebnisse. Um diesen
Zustand zu verbessern, sind Programme entwickelt
178 Kapitel 4 • Welche Softwarekomponenten sind für ein DWH einzusetzen?

worden, die parallel die Suchdienste der einzelnen


Web-Suchmaschinen ausführen lassen und deren
Ergebnisse zusammenführen, die sogenannten
Metasuchmaschinen.
Extraktor Ein Extraktor ist ein Programm, das aus dem
Zugriff auf eine Datenbank die Übermittlung der
Daten in ein anderes Datenhaltungssystem veran-
lasst. Ein spezieller Extraktor ist eine ODBC-
Schnittstelle oder ein SQL-Programm. Die Daten
werden in dem Format und mit den Bezeichnungen
geliefert, wie es die Datenquelle bereitstellt.
Für einen tieferen Einblick in die Thematik der Middleware ist zu empfehlen:
 Österle u.a., Middleware

DWH-Komponenten der Datenquellenschicht


Datenbanken Die Daten, die den zentralen Komponenten des
DWH über den Integrator zugeliefert werden, sind
in erforderliche Formate und Strukturen transfor-
mierte Kopien anderer Datenhaltungssysteme.
Dies können relationale Datenbanken, hierarchi-
sche Datenbanken, objektorientierte Datenbanken
oder Multi-Media-Datenbanken sein. Die redun-
danzärmste Variante der Datenhaltung ist die relati-
onale Datenbank. Ein Beispiel für den Aufbau einer
relationalen Datenbank ist am Anfang des Kapitels
am Beispiel der Architektur des Datenbankmanage-
mentsystems Ingres grafisch dargestellt.
Dateiverwaltungssysteme Abzugrenzen von den Datenbanken sind die Datei-
verwaltungssysteme. In Dateiverwaltungssyste-
men kann in den einzelnen Files, aber nicht File-
übergreifend nach Informationen gesucht werden.
Es können auch multidimensionale Datenbanken
anderer Data Warehouses sein. Die Daten können
auch aus einfachen Files und aus Dokumenten wie
Kalkulationssheets, Textdokumente und Grafiken
von Dateiverwaltungssystemen bezogen werden.

4.1.3 Verwandte Systeme


Im Folgenden sollen zwei in sich geschlossene, aus mehreren Komponenten
zusammengesetzte komplette Informations-Systeme, die gleichzeitig Kompo-
nenten des DWH sein können, vorgestellt werden: das OLAP-System und das
Knowledge Discovery System.
Kapitel 4 • Welche Softwarekomponenten sind für ein DWH einzusetzen? 179

Das OLAP-System
Das Konzept des Online Analytical Processing, kurz OLAP, ist von den Kon-
zeptionisten des Relationalen Modells aus der Erkenntnis mit entwickelt wor-
den, dass die hervorragenden Konsistenzmechanismen der relationalen Daten-
banken große Nachteile bei der multidimensionalen und der konsolidierenden
Bearbeitung von Daten verursachen. So darf z.B. in relationalen Datenbanken
keine Hierarchie mit akkumulierten Werten definiert werden, weil dies zu
schlecht kontrollierbaren Redundanzen führt. Besonders die Konsolidierung
entlang eines eine Hierarchie durchlaufenden Pfades ist eine für das Control-
ling von Unternehmen wichtige Funktion. Die Konsolidierung ist darüber hin-
aus entlang verschiedener Dimensionen erforderlich. Die Entscheidung, wel-
cher Konsolidierungspfad gerade gebraucht wird, also entlang welcher
Dimension die Konsolidierung durchgeführt wird, und ob an einer bestimmten
Aggregationsstufe die Dimension gewechselt werden muss, ist von dem augen-
blicklich zu bearbeitenden Problem abhängig. Sie muss daher flexibel vom
Desktop aus, im Augenblick des Gebrauchs, abzurufen sein. Die Richtung des
Durchlaufens der Aggregationspfade muss sowohl in Richtung Verdichtung wie
auch in Richtung Auflösung möglich sein, d.h. von den unverdichteten zu agg-
regierten Größen und von den aggregierten zu den detaillierte Größen.
Das OLAP-Konzept wurde von E.F.Codd, dem Erfinder der relationalen Daten-
banken, zusammen mit S.B.Codd in die folgenden zwölf Anforderungen, die
zwölf Codd'schen Regeln des Online Analytical Processing, gekleidet.

Nummer Forderung

1 Mehrdimensionale konzeptionelle Perspektiven

2 Transparenz

3 Zugriffsmöglichkeit

4 Konsistente Berichterstellung

5 Client/Server-Architektur

6 Generische Dimensionalität

7 Dynamische Handhabung dünn besetzter Matrizen

8 Mehrbenutzerunterstützung

9 Uneingeschränkte kreuzdimensionale Operationen

10 Intuitive Datenverarbeitung

11 Flexible Berichterstellung

12 Unbegrenzte Dimensionen- und Aggregationsebenen

Tabelle 4.1: Die zwölf Codd'schen Regeln des Online Analytical Processing
180 Kapitel 4 • Welche Softwarekomponenten sind für ein DWH einzusetzen?

Multidimensionalität
Die Multidimensionalität ist eine Eigenschaft, die besonders häufig in Frage-
stellungen des Unternehmens anzutreffen ist. So ist zum Beispiel der Umsatz
eine Größe, die produktbezogen, regionsbezogen und zeitbezogen zugeordnet
werden muss, wie die Frage »In welchem Zeitraum wurden mit welchem Pro-
dukt in welcher Region Umsätze in welcher Höhe gemacht?«, zeigt. Die Forde-
rung der Multidimensionalität bedeutet, dass mehrere unterschiedlich dimen-
sionierte Datenwürfel angelegt werden können. Die Berechnungen können
innerhalb einer Dimension (intradimensional) oder auch über mehrere Dimen-
sionen hinweg (interdimensional) definiert und durchgeführt werden. Die
Sicht auf die Dimensionen der Würfel ist wahlweise interaktiv auswählbar.
Die Darstellungsart sollte der Multidimensionalität gerecht werden, das heißt
wenigstens die dritte Dimension einbeziehen.

 


   


 

 

    

   



   


 


   

    
 

   

   




   






 
 
 
   
 
    
 
 

 
    

 
 
   





   
 




   




   


 


   

   
 

   

   



   


 


   



 


   


 



Abbildung 4.6: Beispiel eines Multiwürfels


Kapitel 4 • Welche Softwarekomponenten sind für ein DWH einzusetzen? 181

Transparenz
Mit Transparenz ist von Codd&Codd eine Eigenschaft definiert worden, die dem
Benutzer die Herkunft der Daten, die Lokation des eingesetzten Tools und die
Koppelung des Tools an die gesamte Anwendung »transparent« werden lässt.
Anders ausgedrückt ist Transparenz die Eigenschaft des Systems, dem Benutzer
die Eingabe der exakten Systemdefinition der Datenquellen zu ersparen, also
die Möglichkeit, die Quelle per »Klick« auszuwählen.
Die Transparenzforderung betrifft die Offenheit der Systemkomponenten für
die Anbindung weiterer Softwarekomponenten. Dies bedeutet z.B., dass bei
einem Wechsel des Server-Produkts die Client-Seite, so wie sie konfigurierte
wurde, weiter betrieben werden kann, eben nur auf einem anderen Server. Dies
wiederum bedingt eine Middleware, das heißt eine Softwareschicht, welche die
Verbindung zwischen den Client-Tools und den Server-Tools herstellt.
Zugriffsmöglichkeit
Unter Zugriffsmöglichkeit formuliert Codd&Codd die Forderung, in einem
analytischen Modell agieren zu können, ohne dabei die Originaldaten direkt
ansprechen zu müssen.
Da die Originaldaten in verschiedenen Quellen gespeichert sind, müssten vom
OLAP-Benutzer verschiedene Zugriffssprachen, Datenbankschemata, Formatie-
rungen und Systemeinstiege beherrscht werden. Er müsste die lokale Position
jeder Datenquelle kennen und ansprechen und zu jedem System eine eigene
Zugriffserlaubnis erhalten. Die einzelnen Datenmengen müssten manuell
zusammengeführt werden. Der Benutzer soll statt dessen mit nur einer
Zugriffsart auf eine Struktur und mit nur einer Sprache auskommen. Dafür ist
ein eigenes Datenbankschema, ein Data Dictionary, erforderlich. Da die Daten
nicht unbedingt relational, sondern vielmehr in einer multidimensionalen und
hierarchischen Struktur benötigt werden, ist zudem noch eine Modellkompo-
nente erforderlich.
Der Transport der Daten aus den ursprünglichen Quellen in die Datenbank des
OLAP-Servers wird mit sogenannten Middlewarekomponenten abgewickelt.
Konsistente Berichterstellung
Mit konsistenter Berichterstellung ist das performante Verhalten bei der
Erstellung von Berichten aus großen Datenmengen, langen Hierarchien, brei-
ten Hierarchien und vielen Dimensionen gemeint. Die Forderung nach Konsis-
tenz ist begrifflich etwas missglückt, da hierunter bereits in der Datenbank-
technologie die Stimmigkeit der zueinander in Beziehung stehenden
Datensätze von Datenbanken verstanden wird und die Bedeutung des Wortes
wenig mit dem Zusammenhang zu tun hat, der von Codd&Codd angesprochen
wird. Die Navigation in einem Multiwürfel muss auch bei hoher Komplexität
komfortabel bleiben. Hier wäre der Begriff »performante Berichterstellung«
passender, zumal die Konsistenzproblematik nicht auf der Berichtsebene, son-
dern auf der Datenhaltungsebene sichergestellt wird.
182 Kapitel 4 • Welche Softwarekomponenten sind für ein DWH einzusetzen?

Client/Server-Architektur
Die technischen Eigenschaften Client/Server-Architektur sind in der Welt der
relationalen Datenbanken üblich, wie z.B. die Aufteilung der Prozesse auf einen
Server und einen Client.
Der Aufbau der Softwaresysteme mittels Client/Server-Architekturen hat sich
durchgesetzt. Dass OLAP-Systeme in Client/Server-Architekturen aufgebaut
werden, ist dennoch nicht selbstverständlich, da die Daten meistens in Termi-
nal-Host-Systemen vorliegen. Das Prinzip der C/S-Architektur erlaubt es, koo-
perierende Programme auf verschiedenen Rechnern, z.B. einem Server-Rech-
ner und einem Client-Rechner, ablaufen zu lassen. Das Client-Programm holt
sich bei Bedarf vom Server Daten und Rechenleistung. Der Server kann dann
als starker Datenbankserver für die Haltung großer Datenmengen ausgelegt
und an einem festen Ort platziert werden. Die Programme zur Analyse der
Daten können lokal entfernt vom Server auf Client-Rechnern installiert werden
und je nach Bedarf mit dem relevanten Datenausschnitt versorgt werden.
Das Thema der Client/Server-Architekturen wird in Kapitel 5 »Die Hardware
Architektur von Data Warehouse Systemen« noch vertieft.
Generische Dimensionalität
Auf den Dimensionen des Multiwürfels sind bestimmte nützliche Funktionen
definiert. Die generische Dimensionalität fordert, allgemeingültige, also über
alle Dimensionen gültige Funktionen zu definieren, ohne dabei jede einzelne
Dimension zu nennen. Anders ausgedrückt soll die für eine Dimension defi-
nierte Funktion auf alle anderen Dimensionen generisch ausgeweitet werden.
Dünn besiedelte Matrizen
Ein Multiwürfel setzt sich aus Elementarwürfeln zusammen. Jeder Elementar-
würfel hat Platz für eine gewisse Datenmenge. Die Multiwürfel werden naturge-
mäß nicht in an allen Bereichen in der gleichen Dichte mit Daten bestückt sein,
sondern es wird Leerplätze geben. Je nach der Lage dieser dünnbesiedelten Stel-
len werden jeweils andere Zugriffe performanter sein, als dies bei homogen und
stark besetzten Matrizen der Fall ist. Es muss möglich sein, die Performance-
unterstützenden Zugriffstechniken besonders bei dünnbesetzten Matrizen
dynamisch und flexibel dieser Datenbesiedelungssituation anzupassen.
Multi-User-Betrieb
Die technischen Eigenschaften des Multi-User-Betriebs sind in der Welt der
relationalen Datenbanken üblich. Dateien der OLAP-Server werden von mehre-
ren Benutzern angefragt. Der konkurrente Zugriff vieler Benutzer muss mit
Sperr- und Freigabe- und Roll-Back-Mechanismen die Konsistenz der Daten
erhalten, bzw. bei einem Absturz des Rechnersystems auf einen konsistenten
früheren Zustand zurückführen.
Kapitel 4 • Welche Softwarekomponenten sind für ein DWH einzusetzen? 183

Kreuzdimensionale Operationen
Die Arbeit mit multidimensionalen Würfeln bringt die Notwendigkeit einer
wesentlichen Erweiterung mit sich, nämlich Berechnungen, die innerhalb der
Werte einer Dimension stattfinden. Daten unterschiedlicher Herkunft, regio-
nal, serverlogisch, datenbanktypisch, sollen trotz verschiedener Formate in die
Berechnung einbezogen werden können. So können z.B. die Daten einer
Dimension aus verschiedenen Regionen von verschiedenen Datenhaltungssys-
temen kommen. Bei diesen kreuzdimensionalen Operationen sollen die Zahlen
in allen Aggregationsebenen ohne direkte Angabe von Additionsvorschriften
automatisch aggregiert werden.
Intuitive Datenbearbeitung
Bei der intuitiven Datenbearbeitung sollen die Daten mit den der Fachsprache
des Anwenders entnommenen Bezeichnungen gefunden werden können, ohne
den Anwender mit einer Programmiersprache und den internen Bezeichnun-
gen zu konfrontieren. Von einem Standort aus sollen, ohne lange Menühierar-
chien des Systems durchlaufen zu müssen, die Daten, die in einem Zusammen-
hang stehen, direkt angesprochen werden können. Die Dimensionen sollen frei
wechselbar sein. Die Verdichtungsebenen sollen durch einfache Bedienungsele-
mente aufgelöst oder zusammengefasst werden können.
Für diese intuitive Datenbearbeitung sind besondere Navigationsfunktionen
(Drill Down, Drill Across, Roll Up, Drill In) erforderlich und eine übersichtliche
synoptische Darstellung mehrerer Dimensionen. Eine solche für eine effiziente
Navigation die Mehrdimensionalität verdeutlichende Orientierungshilfe zeigt
die folgende Abbildung »Raumvisualisierung«.
Flexible Berichterstellung
Die flexible Berichterstellung erfordert es, dass zusammengehörige Daten in
Berichten nebeneinander platziert werden können. Spalten und Zeilen müssen
ihrer Aggregation entsprechend in mehrere Aggregationskomponenten aufge-
spalten werden können. Die Spalten müssen je nach Bedarf frei verschiebbar,
hervorhebbar und auch unsichtbar gemacht werden können.
Für die flexible Berichterstellung sind Zugriffswerkzeuge, Montage- und Anpas-
sungstools für Berichtsteile erforderlich (Spaltenkonfigurator, Formelfelder,
Hyperlinks, wertdynamische Feldpräsentationen).
Unbegrenzte Aggregationsebenen
Es ist zwar keine grenzenlose Anzahl von Dimensionen und auch keine gren-
zenlose Anzahl von Aggregationsebenen für die Erfassung unternehmensspezi-
fischer Fragestellungen erforderlich, aber die Dimensionalität sollte praktisch
nicht beschränkt werden. Die Forderung unbegrenzte Aggregationsebenen
bedeutet nicht die Möglichkeit, unendlich viele Ebenen zu verarbeiten, was gar
nicht möglich ist, sondern nicht an die praktisch sinnvollen Grenzen zu stoßen.
184 Kapitel 4 • Welche Softwarekomponenten sind für ein DWH einzusetzen?

Abbildung 4.7: Raumvisualisierung

Die Leistung der Systeme ist heute auf ca. 20 Dimensionen und weit mehr tiefe
Aggregationen ausgelegt. Hier wäre auch der Begriff »ausreichende Aggregati-
onsebenen« besser angebracht als derjenige der unbegrenzten Aggregationse-
benen.
Integrität
Was bei allen bisher genannten Codd'schen Forderungen stillschweigend vor-
ausgesetzt, also nicht explizit gefordert wird, ist die Integrität der Daten. Dies
ist umso verwunderlicher, als doch gerade die Integrität der Daten die heraus-
ragende Leistung des Entity Relationship Modells von E.F.Codd ist, und zwar so
erfolgreich, dass sie sich zu einer Königsdisziplin des Software Engineering
entwickelt hat.
Die Integrität der Daten ist auf der Ebene der Quellen so gut wie es das entspre-
chende Datenverwaltungssystem zulässt, und hier sind die relationalen Daten-
banken führend. Es werden auch andere Quellen gebraucht, deren Verwal-
tungsmechanismen nicht soviel zur Integrität beitragen können. Die meisten
Hersteller haben dies erkannt und legen deshalb dem Datenwürfel zunächst
eine relationale Datenbank zugrunde, die dazu zwingt, zunächst einmal alle
Daten, egal welcher Herkunft, in einen integren Zustand zu überführen. Die
Integrität hängt allerdings auch von der sorgfältigen Modellierung ab.
Kapitel 4 • Welche Softwarekomponenten sind für ein DWH einzusetzen? 185

Selbstverständlich ist zu fordern, dass auch die Weiterverarbeitung der Daten,


wie z.B. Aggregation entlang der Hierarchien, die Integrität nicht zerstört.
Integrität ist damit auf drei Ebenen zu verlangen: in den Datenquellen, in der
Datenbasis des OLAP-Servers und in der Schicht der Modelle und Multiwürfel.
Die Codd'schen Forderungen schlagen sich in neuen Funktionen und in neuen
Architekturkomponenten nieder, die in den relationalen und konventionellen
Datenhaltungssystemen nicht vorhanden sind. Da ein OLAP-System auf vor-
handenen Datenbanken aufsetzt, deren Daten abzieht und in einer eigenen
Struktur ablegt, ist ein OLAP-Server erforderlich. Die anderen Funktionen sind
entweder auf dem Server, als Middlewarekomponenten für den Datentransfer
oder als Datenorganisationskomponenten (Data Dictionary, Modellbank) von
den Datenhaltungssystemen oder auf dem Desktop (Navigation, Berichtsmon-
tage) platziert. Das OLAP-System hat folgenden Aufbau.




    


 

 

 
  


 







   
  
     

Abbildung 4.8: OLAP-Systemaufbau


186 Kapitel 4 • Welche Softwarekomponenten sind für ein DWH einzusetzen?

Da die OLAP-Systeme andere Stärken als die transaktionsorientierten OLTP-


Systeme besitzen, sind sie für andere Aufgaben geeignet. Eine Gegenüberstel-
lung des den relationalen Datenbanken zugrunde liegenden Transaktionskon-
zepts, des Online Transaction Processing, OLTP und des Online Analytical
Processing, OLAP, verdeutlicht diese unterschiedlichen Stärken.

Kriterium OLTP OLAP

Zugriff Update, Eingabe, Löschen Lesezugriff

Datenansicht fest programmiert benutzerdefiniert

Datenmenge wenig sehr viel

Datenniveau detailliert aggregiert

Aktualität neuester Stand historisch

Verarbeitungseinheit Dateneinzelsatz und Listen multidimensionale Matrizen

Bezug applikationsintener Sachverhalt applikationsübergreifender


Sachverhalt

Tabelle 4.2: Synopse der OLAP- und OLTP-Anforderungen

Im folgenden Abschnitt soll noch ein weiteres Beispiel eines kompletten, eigen-
ständigen Subsystems des Data Warehouse, das Knowledge Discovery System,
vorgestellt werden.

Knowledge Discovery System


Ein wesentlicher Aspekt der Datenverarbeitung ist die Wissensgewinnung. Man
möchte mit neuen Technologien und Funktionen mehr Erkenntnisse aus den
vorhandenen Daten ziehen als dies bei den »gewöhnlichen« Datenhaltungssys-
temen möglich ist. Vor der Bestimmung der einzelnen Funktionen lohnt sich
deshalb ein Blick auf den Prozess der Wissensfindung in Datenbanken. Hier hat
sich bereits ein Terminus Technicus etabliert: Knowledge Discovery on Data-
bases, kurz KDD. Es gibt sehr starke Tendenzen, die historisch unabhängig von
der Idee der DWH entstandenen KDD-Systeme für DWH-Aufgaben einzusetzen
und sogar deren Komponenten vollständig in ein DWH zu integrieren.
Die Wissensfindung wird in mehreren Schritten abgewickelt, die im Folgenden
skizziert werden:
✔ Datenauswahl und -sammlung
✔ Datenklärung und -vorbereitung
✔ Transformation und Reduktion
✔ Data Mining
✔ Strukturierung und Modellierung
Kapitel 4 • Welche Softwarekomponenten sind für ein DWH einzusetzen? 187

✔ Evaluation
✔ Visualisierung
Datenauswahl und Sammlung
Aus der großen Menge der erreichbaren Daten sind zunächst diejenigen her-
auszufinden, die für das zu lösende Problem relevant sind. Diese Daten werden
aus dem Data Warehouse heraus in eine problemrelevante Sammlung kopiert,
um nicht in der erheblich größeren Menge des DWH arbeiten zu müssen.
Klärung und Vorbereitung
Nach der Auswahl steht ein immer noch großer Umfang an Daten zur Verfü-
gung, der noch auf Qualität oder Güte geprüft werden muss. Die Gütebeurtei-
lung umfasst unter anderem die Darstellungsform, Lückenhaftigkeit, Aktualität
und Widerspruchsfreiheit. Dies ist wichtig, um nicht durch eine mangelnde
Datenqualität bereits Beurteilungsfehler zu induzieren.
Transformation und Reduktion
Die Daten entstammen in der Regel verschiedenen Quellen und sind daher in
unterschiedlichen Formaten vorhanden. Die Formate werden in ein einheitli-
ches Format transformiert. Dazu gehört zum Beispiel auch die Aufspaltung von
nicht-atomaren Attributen in kleinste ansprechbare, über alle Daten homogene
Einheiten, in sogenannte Datenelemente. Daten, die nicht der Qualität entspre-
chen, die sogenannten »schlechten« Daten, werden ersetzt oder eliminiert. Die
Datenmenge wird auf die relevante und zuverlässige Datenmenge reduziert. Die
nicht schließbaren Lücken werden identifiziert und zu Vorgaben für die Aus-
wertungsalgorithmen kondensiert.
 

 
  
 


  


   
   
  

 

   
! " 



Abbildung 4.9: Knowledge Discovery Prozess


188 Kapitel 4 • Welche Softwarekomponenten sind für ein DWH einzusetzen?

Data Mining Strukturierung und Modellfindung


Das Ergebnis des Data Mining soll eine Hypothese, also ein für Entscheidungen
verwertbarer Handlungshinweis sein. Das Data Mining kennt hierfür zwei
Wege. Der eine Weg ist die Prüfung von vermuteten Hypothesen, die soge-
nannte Hypothesen-Validierung. Der schwierigere zweite Weg ist die automati-
sche Gewinnung von Hypothesen aus den Daten, die Hypothesen-Generierung.

Beispiel: Data Mining Hypothese


Ein sehr grobes Beispiel für eine Hypothese aus dem Bereich der Kraftwerks-
technik ist die Vermutung, dass »in den Jahreszeiten höheren Stromver-
brauchs die Ausfälle von Bauteilen durch höheren Verschleiß ansteigen«.
Grob ist die Hypothese deshalb, weil man Genaueres wissen möchte, z.B.
welche von mehreren 10.000 Bauteilen dies sind.

Für die Hypothesengenerierung sind verschiedene Techniken aus der Logik,


Statistik und der Mengenlehre in mehr oder weniger bewährtem Einsatz. Unter
anderem sind dies Warenkorbanalysen, Schließen mit Neuronalen Netzen,
Schließen mit genetischen Algorithmen, Clusteranalyse, fallbasiertes Schlie-
ßen, Regelinduktion mit Entscheidungsbäumen, assoziative Netze, Fuzzy Set
Analyse. Alle diese Techniken werden im vorliegenden Buch vorgestellt. Für
nähere Informationen wird auf ergänzende Literatur verwiesen. Die Data
Mining Techniken sind sehr übersichtlich in den drei Aufsätzen
 Kurz, v.d.Lühe, Weber, »... Data Mining ...« S.249-321 in Martin, Data
Warehousing
dargestellt.
Evaluation
Die aus dem Data Mining gewonnenen Erkenntnisse werden interpretiert, d.h.
ihr Sinn wird auf die untersuchte reale Situation bezogen. Es wird die Frage
gestellt, ob das Ergebnis eine reale Möglichkeit ist. Die Möglichkeit wird im
Evaluationsschritt erprobt.
Visualisierung
Die Ergebnisse sind naturgemäß komplex und können vom Anwender wesent-
lich schneller kognitiv erfasst werden, wenn sie von reinen Zahlenschemata in
eine grafische Präsentation überführt werden. Grafische Präsentationen sind
der Realität näher als Tabellen und Texte, dreidimensionale Darstellungen sind
realer als Flächen und bewegte Darstellungen sind realer als statische Darstel-
lungen. Es sind deshalb verstärkte Tendenzen in Richtung dreidimensionaler
bewegter Darstellungen, sogenannter virtueller Räume, zu erkennen.
Kapitel 4 • Welche Softwarekomponenten sind für ein DWH einzusetzen? 189

Visualisierung ist auch in den Zwischenschritten der Strukturierung und des


Data Mining sehr nützlich.
 Fayyad, Knowledge Discovery

4.1.4 Die Komponentenkonfiguration des DWH


Problemstellung und Motivation
Der Verschiedenheit der Nutzerkreise entsprechend, ist jeweils eine andere
Funktionalität und Ergonomie angemessen, sind andere Werkzeuge im Ange-
bot, ist eine unterschiedliche Datenverdichtung der Informationen unter-
schiedlicher Zugriffe vonnöten. Aus der Sicht der Unternehmenshierarchien
kann man drei Nutzerkreise ausmachen: Top Management, Mittleres Manage-
ment und Operatives Management. Die folgende Tabelle stellt die unterschiedli-
chen Anforderungen dieser drei Nutzerkreise dar.

Eigenschaft Top-Management Mittleres Management Operat. Management

Planungsfocus stark wenig fast nicht

Kontrollfocus wenig stark stark

Zeitrahmen ein bis fünf Jahre bis zu einem Jahr täglich

Ziel der Aktivität alle BW-Funktionen eine BW-Funktion Subfunktionen

Art der Aktivität ziemlich unstrukturiert leicht strukturiert hochstrukturiert

Komplexität hochkomplex gut definiert zielgerichtet

Job Measurement schwierig weniger schwierig leicht

Ergebnis Pläne, Politiken, Strategien Implementierungspläne Endprodukt

Informationsart extern intern, relativ genau historisch, exakt

Mentalfähigkeiten kreativ, innovativ verantwortlich, überzeugend effizient, effektiv

Involvierte Personen wenige mittelmäßig viele viele

Interaktivität zwischen Bereichen zwischen Abteilungen innerhalb der Abteilung

Tabelle 4.3: Charakterisierung der Aufgaben der Managementebenen nach Kanter

Literatur, die sich vertieft mit den Managementaufgaben auseinandersetzt und


deren Unterstützungsmöglichkeiten in Anforderungen von Systemarchitektu-
ren formuliert ist:
 Dreger, Management Informations Systeme
 Davis, Management Informations Systeme
190 Kapitel 4 • Welche Softwarekomponenten sind für ein DWH einzusetzen?

Datenquellen
Die Suche nach den Komponenten startet mit der Frage nach den Datenquellen,
da alle weiteren Komponenten sich auf die Behandlung der Daten aus diesen
Quellen ausrichten. Für die Auswahl weiterer Komponenten ist daher wichtig,
✔ welche Datentypen (Text, Zahlen, Bitmaps, Strukturgrafike ...) zu verarbei-
ten sind
(Bilddaten müssen z.B. anders verarbeitet werden als Zahlenkolonnen)
✔ welche Datenträger die Daten konservieren
(Papierdokumente müssen eventuell für eine Textrecherche eingescannt
werden)
✔ welche Inhalte die Daten verkörpern
(exakte Zahlen, logische Regeln, verbale Beschreibungen erfordern ver-
schiedene Interpretations- und Auswertungsformen)
✔ welche Güte die Daten im Sinne von Vollständigkeit, Aktualität, Genauig-
keit, Widerspruchsfreiheit bieten

Gestaltungs- und Lösungsmöglichkeiten


Die Gestaltungsaufgabe des DWH-Spezialisten besteht nun darin, aus der Kom-
plexität der Data Warehouse Softwarekomponenten diejenigen zu bestimmen,
welche die von den Anwendern geforderte Unterstützung ihrer Aufgabenerfül-
lung am besten gewährleisten.
Zunächst wird man die internen Datenquellen aufspüren und bezüglich ihrer
Tauglichkeit beurteilen. Sind die internen Daten ungepflegt und daher zum
Beispiel unvollständig, wird man nach externen Quellen recherchieren müssen.
➢ Feststellen der internen Datenquellen
➢ Feststellen der externen Datenquellen
Die Daten können dauerhaft benötigt werden und müssen dann kontinuierlich
verfügbar gehalten werden. Sie werden auch ad hoc, d.h. plötzlich und unvor-
hersehbar, also temporär, gebraucht werden. Im ersten Falle muss dem Suchen
und Zugreifen auf die eventuell externe Datenquelle ein Transformieren und
Anlegen einer Kopie vorausgehen und im eigenen Data Warehouse durch Kom-
ponenten abgedeckt werden. Im zweiten Fall müssen außerdem Werkzeuge, die
ohne Programmieraufwand Daten extrahieren und integrieren können, zur
Verfügung stehen.
➢ Integrations- und Transformationskomponenten
➢ Feststellen der Such- , Extraktions- und Transformationskomponenten
Die Daten aus verschiedenen Quellen haben Inhalte, die zueinander in Bezie-
hung stehen können. Diese Beziehungen können z.B. Referenzen, Hinweise,
Verhaltenskopplungen mit und ohne Regeln oder sogar Beziehungen in Form
Kapitel 4 • Welche Softwarekomponenten sind für ein DWH einzusetzen? 191

komplexer Modelle sein. Für diese Beziehungen müssen Verwaltungskompo-


nenten gefunden werden.
➢ Auswahl der Datenhaltungs- und deren Verwaltungskomponenten
➢ Feststellen der Verwaltungs- und Referenzierungskomponenten
Der Benutzer muss durch die Komplexität des Systems geführt werden, um
sich nicht hoffnungslos im Daten- und Funktionenlabyrinth zu verirren.
➢ Feststellen der Komponenten für die Benutzerunterstützung
Der Sinn der Daten ist aufgrund komplexer Sachverhalte nicht immer auf
Anhieb zu erkennen. Besonders bei großen Datenmengen ist man lange auf der
Suche, was sie denn nun für eine Aussage ableiten lassen. Hierfür sind vom
DWH-Spezialisten Komponenten zu finden, die dem Benutzer eine Interpreta-
tion erleichtern.
➢ Feststellen des Bedarfes an Komponenten zur Interpretation komplexer
Datenmengen
Bleibt noch eine Gestaltungsfrage zu entscheiden, und zwar die Reihenfolge der
Beschaffung. Soll das DWH schnell und zügig durch Zukauf aller benötigten
Komponenten aufgebaut werden oder ist schrittweise, immer wenn eine Kom-
ponente beherrscht wird, erst die nächste Komponente zu beschaffen? Einer-
seits bindet die Investition in die Komponenten Mittel, andererseits werden
Hersteller bei der Rabattierung auf die Einkaufsmenge achten.
➢ Entscheidung der Beschaffungsfolge der Komponenten
Wie diese Gestaltungsfrage der softwaretechnischen Komponenten und Tools
zu lösen ist, zeigt der folgende Abschnitt.

Problemlösung: Regeln und Hilfsmittel


Das Verfahren
Die nun anliegende Entscheidung ist also die Auswahl der Softwarekomponen-
ten der soeben aufgezählten Gruppierungen des DWH. Hierzu dienen Kompo-
nentenlisten oder besser Referenzmodelle für Data Warehouse Komponenten.
Das folgende Verfahren ist zur Ermittlung der Komponentenstruktur empfeh-
lenswert.

Verfahren: Bestimmung der softwaretechnischen Komponenten der


DWH-Architektur
❖ Bestimmung der Anforderungen (Informationen, Funktionen) an Daten-
quellen
Prüfung der internen Quellen auf Güte und Vollständigkeit
❖ Auffinden der externen Datenquellen
192 Kapitel 4 • Welche Softwarekomponenten sind für ein DWH einzusetzen?

❖ Auswahl der für das DWH relevanten Komponenten aus dem DWH-
Referenzmodell oder mit Hilfe der DWH-Komponentenliste
Feststellen der Monitore für die ausgewählten Datenquellen
Feststellen der Extraktoren für die ausgewählten Datenquellen
Definition der Integratoren der Datenauszüge
Definition der Modell-Definitions- und Verwaltungskomponenten
❖ Festlegen des Datenhaltungs- und Datenbankmanagementsystems
Festlegung des Archivierungssystems
❖ Festlegung der Komponenten zur Interpretation der Daten
❖ Festlegung der Ergonomiekomponenten
Ableitung der Ergonomie-Anforderungen
Feststellung der Präsentationskomponenten

DWH-Komponentenliste
Für die Evaluation und Beschaffung ist die Auflistung der DWH-Komponenten
erforderlich. Das folgende Muster einer DWK-Komponentenliste dient als
Checkliste für die Zusammenstellung des Bedarfs.

Datenquellen Ort Data Warehouse Benutzerschicht

Relational Formelgenerator Navigator


1.
2. Customizer
Hierarchisch Statistik

Flache Files Makroprozessor Browser

Dokumente KDD-Komponenten Profiler


Neuronales Netz
Netzwerk-Datenbanken Fuzzy Set Kommunikationsassistenten
1
Webserver OLAP-Client 2
3
Industrieprozess Filter Groupworkassistenten
1
Video Expertensystem 2

Tabelle 4.4: Muster Komponentenliste Data Warehouse

Empfehlenswert ist neben der Bestimmung der Komponenten noch die Einord-
nung nach deren Bedeutungsgraden bezüglich der Lösung der gestellten Aufgabe
nicht erforderlich > nützlich > unbedingt nötig,
nach den Möglichkeiten für die Kostengestaltung
nicht beschaffen > eventuell beschaffen > unbedingt beschaffen
Kapitel 4 • Welche Softwarekomponenten sind für ein DWH einzusetzen? 193

und für die Termingestaltung


schnell starten > später ausbauen > langsam aber vollständig starten
festzustellen.
DWH-Referenzmodell
Das DWH-Referenzmodell ist nützlicher als eine Komponentenliste, da die
Komponententypen zusammen mit ihren Beziehungen zu den Nachbarkompo-
nenten sind. Die Vernetzung der Komponenten gibt z.B. einen Hinweis darauf,
ob für den Zugriff einer Komponente A auf eine Komponenten B eine vermit-
telnde Komponente erforderlich ist.
Einige Hersteller bieten ebenfalls übersichtliche Komponentendiagramme für
DWH an. Diese sind allerdings unvollständig, da sie verständlicherweise nur auf
die Darstellung und Positionierung der eigenen Produkte abzielen. Sie halten
sich auch meistens nur an den firmeninternen Sprachgebrauch, der leider oft
von der Terminologie der Lehre abweicht. Beispiele von firmenbezogenen
Komponentendiagrammen werden in Kapitel 9, Unterkapitel »DWH-Pro-
dukte«, gezeigt.
Bei der Komponentenkonfiguration sucht man zuerst die nötigen Komponen-
ten und optimiert danach die Funktionenzahl. Um die optimale Ausstattung des
DWH-Systems zu erreichen, kann man anstelle einer Komponentenkonfigura-
tion auch den Weg einer Funktionenkonfiguration wählen. Bei der Funktio-
nenkonfiguration sucht man zuerst die erforderliche Funktionalität und opti-
miert danach die Komponentenzahl.
Ist die Komponentenstruktur des DWH klar, können die Komponenten, zu
denen zur Zeit am Markt Produkte erhältlich sind, ausgesucht oder auch selbst
entwickelt werden. Im Folgenden wird zunächst die für die Produktevaluation
erforderliche Funktionalität der Data Warehouse Komponenten vorgestellt.

4.2 Die Funktionalität des DWH

4.2.1 Übersicht
Bei verschiedenen Herstellern sind die gleichen Komponenten mit unter-
schiedlicher Funktionalität ausgestattet. Andererseits können verschiedene
Komponenten teilweise gleiche Funktionen umfassen. Deshalb ist unabhängig
von der Komponentenbetrachtung eine Funktionsbetrachtung erforderlich.
Die Menge aller DWH-Funktionen ist selbst wieder so umfangreich, dass sich
eine gruppierende Übersicht bewährt. Die folgenden, sich nicht unbedingt
gegenseitig ausschließenden Funktionsgruppen können unterschieden werden:
✔ Editieren
✔ Benutzerführung
194 Kapitel 4 • Welche Softwarekomponenten sind für ein DWH einzusetzen?

✔ Fachfunktionen
✔ Funktionenerstellung
✔ Data Mining
✔ Schnittstellen
✔ Reporting
✔ Navigation
Die Funktionen werden im Folgenden überblicksartig aufgelistet. Die speziel-
len DWH-Funktionen sind in den folgenden Abschnitten detaillierter darge-
stellt.
Editierfunktionen
Editierfunktionen sind Funktionen, mit denen Dateninhalte und ihre Darstel-
lung bearbeitet werden. Die Inhaltsbearbeitung besteht aus den Grundfunktio-
nen »Eingeben neuer Daten«, »Löschen vorhandener Daten«, »Kopieren von
Daten«, »unveränderndes Lesen«, »teilweise Verändern«. Editierfunktionen
werden in einem Programm namens Editor zusammengefasst.
✔ Elementarfunktionen
Eingabe, Löschen, Kopieren, Ansehen, Korrigieren (Update)
✔ Bearbeitungsfunktionen
Umordnen, Einordnen,
Mustersuche, Austauschen
✔ Bearbeitungshinweisfunktionen
Verbergen, Sichern vor Veränderung
Einbetten von Verweisen (Hypertext-Links)
Funktionen zur Benutzerführung
Funktionen werden auf der Benutzeroberfläche durch Symbole (Menüpunkt,
Feld, Button, Icon, Liste) präsentiert und durch eine Benutzerinteraktion oder
eine Eingabe (Drücken der Enter-Taste, Dateneintrag, Mausklick) ausgelöst. Mit
einigen Funktionen soll der Benutzer seine Programme auf eine ihm angemes-
sene Arbeitsweise anpassen können. Das betrifft z.B. die Anordnung der Bedie-
nelemenete auf dem Bildschirm oder die Präsentation der Dokumente auf dem
Bildschirm. Diese Funktionen nennt man Benutzerführungsfunktionen.
✔ Hilfeführung
Suchindex
Online-Handbuch mit ausführlicher Anleitung zur Bedienung der Pro-
gramme
Lernprogramm mit interaktiven Hinweisen bei vermutlichen Eingabefehlern
✔ Customizer
Bestückung der Menüs mit Befehlen
Kapitel 4 • Welche Softwarekomponenten sind für ein DWH einzusetzen? 195

Zuordnen von Funktionstasten zu Befehlen


Symbolisieren von Befehlen mit Icons und Verändern der vorgegebenen
Anordnung
Verändern des Bildschirm-Layouts nach Farbe, Buchstabentypen und Größe
Metafunktionen
Eine wichtige allgemeine Funktionalität ist die Erweiterbarkeit der vorhande-
nen Funktionen. Da hinter jeder Funktion ein ausführbares Programm liegt,
entspricht dies dem Vergrößern des Programmumfanges und einer Steigerung
der Kapazität. Die Erweiterung kann über Zuladen neuer Funktionen oder
Komponenten und auch in der eigenen Erstellung von neuen Funktionen
erreicht werden. Die Funktionen zur Erstellung weiterer Funktionen sind
Metafunktionen.
✔ Generatoren
Formelgenerator mit Syntax zur Beschreibung von mathematischen Funk-
tionen
Makrorecorder zur Sammlung von Funktionen zu einem Ablauf. Beispiel:
Makrorecorder von MS Office, zur Aufzeichnung einer Folge von Bedie-
nungsschritten und aufrufbare Abspeicherung unter einem Funktionsna-
men.
Schemagenerator für Datenbanken
Programmgenerator aus grafischen Programmpräsentationen
✔ Entwicklungstools
3GL Programmeditor mit einem Compiler für eine Programmiersprache
der 3. Generation, wie C, C++, COBOL, FORTRAN
4GL Programmeditor mit einem Pre-Compiler in eine Programmiersprache
der 3. Generation, z.B. SQL
Makroeditor mit Makrosprache und Übersetzer zu einem ausführbaren Pro-
gramm, z.B. Makros eines Kalkulationsblatts
Fachfunktionen
Die Fachfunktionen umfassen betriebswirtschaftliche Logik, Wissen zu techni-
schen Prozessen und Erfahrungswissen. Dieses Wissen kann z.B. in ablauffähi-
gen Formeln wie ROI-Quotient in Bibliotheken fixiert sein. Umfassende For-
melsammlungen oder sogar Formelschemata sind zu betriebswirtschaftlichen
Modellen vereint, wie z.B. das ROI-Schema von Dupont.
✔ Formelschemata
✔ Betriebswirtschaftliche Modelle
✔ Referenzmodelle
für Prozesse
für Datenbankstrukturen
✔ Regelmodelle
196 Kapitel 4 • Welche Softwarekomponenten sind für ein DWH einzusetzen?

Schnittstellenfunktionen
Schnittstellenfunktionen sind erforderlich, um zwischen verschiedenen Pro-
grammen auf einem Gerät oder zwischen verschiedenen Geräten Daten auszu-
tauschen. Der Ausdruck eines Dokuments auf einem Drucker benötigt ein
Schnittstellenprogramm (Druckertreiber). Der Zugriff auf eine Datenbank
benötigt einen Datenbanktreiber. Ist die Datenbank auf einem anderen Rechner
installiert als das anfragende Programm, ist ein Transport der Daten durch ein
Netz abzuwickeln. Der Transport von Daten durch ein Netzwerk benötigt Pro-
gramme, welche die Daten für den Transport transformieren, das Ziel adressie-
ren, mit Sichereitsinformationen bestücken und Verbindungsunterbrechungen
egalisieren.
✔ Gerätetreiber
Drucker, Scanner, Lesestift, Barcode-Leser, Plotter, Fax
Telefonmodem, ISDN-Modem, LAN-Modem, GSM-Modem
✔ Importfunktionen
z.B. von Spreadsheet-Tabellen, Texten, Adressen, Grafiken in ein Textverar-
beitungsprogramm
✔ Exportfunktionen
in andere eventuell lokal entfernte Dokumentensysteme
✔ Softwaretreiber
für Datenbankzugriff mit ODBC, SQL, CICS u.a.
für den Aufruf entfernter Funktionen wie RPC, RFC
Crosscompiler
Navigationsfunktionen
Die Navigationsfunktionen helfen, die Orte zu finden, an denen die gewünschte
Information liegt, sich dort hin zu bewegen und die gesuchten Files aufzuru-
fen, d.h. ihre Präsentation auf einem Monitor zu starten.
✔ Navigator
zur Orientierung in der Ablagestruktur von Dokumenten und Files
✔ Drill Down Funktion
die Betrachtung detaillierterer Stufen einer hierarchisch verdichteten
Datensammlung
✔ Drill Across
die Betrachtung der Daten auf den Stufen gleichen Detaillierungsgrades
einer hierarchisch verdichteten Datensammlung
Reportingfunktionen
Die Reportingfunktionen dienen zur Darstellung von Informationen und deren
Zusammenstellung zu einem Bericht. Einige dieser Funktionen der Darstel-
lung von komplexen Sachzusammenhängen sind speziell für das DWH interes-
sant.
Kapitel 4 • Welche Softwarekomponenten sind für ein DWH einzusetzen? 197

✔ Allgemeine Reportfunktionen
Seitenlayout: Schriftkopf, Fußzeile, Ränder, Spalteneinteilung,
Rahmen, Schattierungen, Zeichenarten, Schriftgrößen,
Montage von Texten, Grafiken, Tabellen aus unterschiedlichen Quellen
✔ Grafikfunktionen
Businessgrafiken: Balkendiagramm, Punktediagramm, Portfoliomatrix,
Trendkurve, Kreissegmentdarstellung, Mengenflusszweige, Punktewolke,
Datenspinne
alternative Grafiken und automatische Grafiken zur Darstellung von Zah-
lenmengen
Sondersymbole und Beispielgrafiken
✔ Data Warehouse Reporting
Exception Reporting: Auslösen von Signalen, Nachrichten und Berichten
bei besonderen, sich in Daten repräsentierenden Veränderungen
Schwellenwertanzeige zur automatischen Hervorhebung der von einem
vordefinierten Zustand abweichenden Werte
Die Reportingfunktionen stellen die Grenzen der Darstellbarkeit komplexer
Zusammenhänge dar. Einfache Zusammenhänge sind schon aus Listen und
Businessgrafiken zu erkennen. Schwieriger ist es, aus verschiedenen Einzeldar-
stellungen Beziehungen zwischen den dargestellten Größen entdecken zu kön-
nen. Ein Beispiel, das einen Maßstab für die Leistungsfähigkeit des Reportings
setzt, zeigt die folgende Abbildung.

Abbildung 4.10: Beispiel: synoptischer Report


198 Kapitel 4 • Welche Softwarekomponenten sind für ein DWH einzusetzen?

Allgemeine statistische Funktionen


Die statistischen Funktionen werden auf eine große Datenmenge angewendet,
um Strukturen und Gesetzmäßigkeiten zu erkennen und durch eine mathema-
tische Formel auszudrücken. Solche Zusammenhänge sind z.B. die Zusam-
mengehörigkeit unstrukturierter Datenmengen nach einem Kriterium oder die
abhängige Veränderung von Daten durch die Veränderung anderer Daten oder
auch die Erkenntnis einer Entwicklungsrichtung aus der zeitlichen Verände-
rung von Daten.
✔ Sensitivitätsanalyse
die Feststellung der Veränderung von Werten bei der Abweichung von
Grundannahmen
✔ Clustering
die Beurteilung der Zusammengehörigkeit von Wertepaaren zu einer Menge
durch die Messung ihrer Abstände zueinander im Vergleich zum Abstand
von anderen Wertepaaren
✔ Trendrechnung
Berechnung der weiteren Entwicklung von Werten einer Größe aus den
Veränderungen in der Vergangenheit
✔ Korrelation
Feststellung der Abhängigkeit der Werte einer Größe von einer anderen
Größe und Ermittlung der mathematischen Funktion dieser Abhängigkeit
✔ Multidimensionale Analyse
Darstellung von Zusammenhängen vieler unterschiedlicher Faktoren und
deren Beurteilung auf Abhängigkeit oder Wahlfreiheit, d.h. Bestimmung
ihrer Dimensionen
✔ ABC-Analyse
Gruppierung von Objekten wie z.B. Produkte nach den Werten einer inter-
essanten Größe wie z.B. Kosten
In Abbildung 4.11 ist das Beispiel einer Visualisierung eines Entscheidungs-
baumes auf einer Maske dargestellt.
Administrationsfunktionen
Die Administrationsfunktionen dienen dem Betrieb der Applikationen von der
Installation, der Einrichtung der Erlaubnisse und Bewegungsfreiheiten der
User, der Aktualisierung und Sicherung der Daten, bis zum Transport der Daten
zu anderen Lokationen.
✔ Replikator
Verteilung von Kopien von Daten auf entfernte Datenhaltungssysteme
✔ Metamodellierer
Definition eines Schemas aus Datenbanktabellen, ihren Spalten und ihrer
Formatierung
Kapitel 4 • Welche Softwarekomponenten sind für ein DWH einzusetzen? 199

Abbildung 4.11: Maske Entscheidungsbaum

✔ Berechtigungsmanager
Zuteilung von Berechtigungsprofilen für den Zugriff auf einzelne Daten,
Tabellen, Datensätze, Spalten, Funktionen, Masken und Rechner
Data Mining Funktionen
Die speziellen Funktionen von Data Warehouse Komponenten dienen der
Suche von Daten, dem Aufspüren von Datenorten und Dateninhalten, dem
Interpretieren von Daten, dem Auswählen, Nachbearbeiten, Zusammenstellen
und Präsentieren von Daten. Diese Funktionen kann man typische DWH-
Funktionen nennen.
✔ Hypothesengenerator
Erzeugung einer formulierten Aussage auf Basis der Überprüfung der Vari-
ablen einer Datenmenge und aller Datenpaare
✔ Hypothesenvalidierer
Überprüfung einer auf Variablen der Datenmenge formulierten Aussage
durch Prüfen aller Datenpaare der Datenmenge
✔ Entscheidungsbaum-Generator
Darstellung einer Entscheidungssituation mit ihren mehrstufigen Möglich-
keiten und den Wahrscheinlichkeiten der Entscheidungsmöglichkeiten auf
allen Stufen
200 Kapitel 4 • Welche Softwarekomponenten sind für ein DWH einzusetzen?

✔ Clusterfinder
Analyse von Wertepaaren auf ihre Zugehörigkeit zu einer Gruppe über ihre
Nähe
✔ Regel-Editor
Formulierung von logischen Aussagen über Variablen einer Datenmenge
mittels logischer Operatoren (wenn – dann, nicht, und, oder, für alle,
wenigstens einer) und Umsetzung in Datenbankabfragen
✔ Neuronales Netz – Konfigurator
Konfiguration eines Systems von Recheneinheiten (Unterprogrammen), die
aus Ergebnisvergleichen und Vergleich von Grundgrößen auf Gesetzmäßig-
keiten zur Erzielung bester Ergebnisse schließen
✔ Simulator
Berechnung des Verlaufes definierter Größen aus der Veränderung der
Werte anderer Größen und deren Darstellung als Grafik
✔ Animator
Präsentation der Veränderung von Werten diverser Grundgrößen als beweg-
tes symbolisiertes Bild
✔ Optimierer
Variation einer Grundsituation in Richtung eines optimalen Ergebnisses
Lineare Optimierung
Genetische Optimierung mit Hilfe genetischer Algorithmen
Für ein intensiveres Studium der statistisch orientierten Methoden des Data


Mining ist zu empfehlen:
Bewry u.a., Data Mining

4.2.2 Ausgewählte Data Warehouse Funktionen


Aus der Menge der aufgezählten Funktionen einer DWH-SW sollen jetzt einige
speziell für die Datenanalyse verwendete Funktionen detaillierter dargestellt
werden. Dies sind die Funktionen Portfoliomatrix, ABC-Analyse, Multiwürfel,
Entscheidungsbaum, Cluster und Trendkurve.
Portfoliomatrix
Die Portfoliomatrix wurde in der Marketingtheorie aus der Erkenntnis des
Umsatz-Lebenslaufes von Produkten zur Einschätzung der augenblicklichen
Lebensphase und zur Prognose des weiteren Umsatzverlaufes entwickelt.
Basisschema ist eine Vier-Felder-Matrix mit einer x-Achse als Wachstumsskala
und einer y-Achse als Skala des relativen Marktanteils. Ein Produkt wird, durch
einen Kreis symbolisiert, in der Vier-Felder-Matrix positioniert. Der Durchmes-
ser des Kreises entspricht maßstabsgerecht seinem Umsatz. Die Position ent-
spricht auf der x-Achse der von den Fachleuten eingeschätzten Wachstum-
schance und in der y-Achse dem aktuellen relativen Marktanteil. In der Matrix
werden auch andere Produkte eines Unternehmens zum Vergleich positioniert.
Kapitel 4 • Welche Softwarekomponenten sind für ein DWH einzusetzen? 201

Es ist auch möglich, in einer Portfoliomatrix ein Produkt mit seinen Positionen
aus der Vergangenheit darzustellen. Auf der Synopse der historischen Positio-
nen des Produkts kann eine Prognose für die nächste Position abgeleitet wer-
den.
Für jedes der vier Felder gibt es eine Handlungsempfehlung bezüglich der wei-
teren Ausrichtung des Produkts:
✔ Feld 1: wenig relativer Marktanteil, hohe Wachstumschance > investie-
ren oder nicht investieren, wenn klar ist, dass keine Marktposi-
tion erzielt werden kann
✔ Feld 2: hoher relativer Marktanteil, hohe Wachstumschance > investie-
ren für den Ausbau der Position
✔ Feld 3: hoher relativer Marktanteil, niedrige Wachstumschance > kein
weiterer Ausbau, sondern Umsätze kassieren und Ausstieg vorbe-
reiten
✔ Feld 4: wenig relativer Marktanteil, niedrige Wachstumschance > Abzug
aller Investitionen
Es ist ebenfalls möglich, statt einer Einteilung in zwei mal zwei Felder eine
Neun-Felder Matrix einzuteilen. Bei mehr als neun Feldern wird die Matrix und
alle daraus abgeleiteten Handlungsempfehlungen unübersichtlich.
Zusammenfassend lässt sich sagen:
➡ Die Funktion Portfoliomatrix positioniert ein oder mehrere Produkte mit
einem oder mehreren historischen Positionen entsprechend der Wachstum-
schancen und des relativen Marktanteils in einer Vier-Felder-Matrix, symbo-
lisiert durch eine Kreisfläche, deren Durchmesser im Verhältnis der
Umsätze stehen.

 



 


  

  

   
 

 

   


   

  

   


  

  

Abbildung 4.12: Beispiel einer Portfoliomatrix


202 Kapitel 4 • Welche Softwarekomponenten sind für ein DWH einzusetzen?

ABC-Analyse
Die ABC-Analyse ist zum Zwecke der schnellen Klassifizierung der für den
Betriebserfolg wichtigen Kunden erfunden worden. Ziel ist dabei, die Kunden
nach ihrem Umsatz in drei Gruppen einzuteilen: die »Großkunden«, mit denen
nahezu der gesamte Umsatz gemacht wird, die Mittelgroßkunden, mit denen
noch ein guter Zusatzumsatz erreicht wird, und die Kleinkunden mit kleinen
Umsätzen.
Beispielsweise könnte die ABC-Gruppierung wie folgt eingeteilt werden:
✔ A-Kunden: Gruppe der umsatzstärksten Unternehmen, die bis 80% des
Gesamtumsatzes tragen
✔ B-Kunden: Gruppe, die zwischen 80% und 95% bewirken
✔ C-Kunden: Restgruppe, welche die letzten 5% des Umsatzes bewegen
Die ABC-Analyse kann generell auch für Kumulationsbetrachtungen mit ande-
ren Größen als Umsätzen eingesetzt werden, wie z.B. Mengen von Bestellun-
gen, Servicenachfragen im Call Center oder Umfang von Garantiefällen aus Auf-
trägen.
In der Abbildung ist die ABC-Kurve dargestellt, die auf der x-Achse (% der Kun-
den) die Kunden der Höhe ihres Umsatzes nach von links nach rechts aufreiht.
Auf der y-Achse sind die summierten Umsätze in % bis zu der x-Prozentsumme
angetragen. Man kann ablesen, dass mit ca. 36% aller Kunden schon 80% des
Umsatzes erreicht wird. Um 95% des Umsatzes zu erwirtschaften (ca.72% der
Kunden), müssen weitere 36% Kunden betreut werden. Für die letzten 5% des
Umsatzes sind noch einmal 28% der Kunden zu verwalten.
Diese Gruppeneinteilung ist für gezielte Marketingmaßnahmen interessant.
Um Kunden der A-Gruppe zu halten, darf und sollte man in mehr Marketing-
maßnahmen investieren als für die C-Kunden.
Zusammenfassend lässt sich sagen:
➡ Die Funktion ABC-Analyse reiht Objekte entlang der x-Achse nach der
Größe eines Messwertes, kumuliert diese Messwerte entsprechend der Grö-
ßenreihung und trägt die kumulierten Werte an der y-Achse zu der zugehö-
rigen Position des Objekts auf der x-Achse an.
Das Beispiel der folgenden Abbildung ist aus der Zeitschrift Office, Heft 6, 1997
entnommen.
Kapitel 4 • Welche Softwarekomponenten sind für ein DWH einzusetzen? 203

Abbildung 4.13: Beispiel Kumulationsdiagramm einer ABC-Analyse

Entscheidungsbaum
Der Entscheidungsbaum ist aus dem Bedarf entstanden, komplexe Gesamtent-
scheidungen über Teilentscheidungen zu lösen.
In der Abbildung ist ein Entscheidungsbaum mit drei Stufen dargestellt. Das
Entscheidungsproblem »A« lässt sich in zwei Einzelentscheidungen »B« und
»C« zerlegen. Beiden Möglichkeiten lässt sich eine Erfolgswahrscheinlichkeit
von 0,3 bzw. 0,7 oder 30% bzw. 70% zuordnen. Die Zwischen- oder Teilentschei-
dungen »B« und »C« sind im Beispiel in weitere Teilentscheidungen zerlegbar.
Für »B« ist diese Zerlegung in die Teilentscheidungen »D« und »E« zweiter
Stufe möglich. Die Teilentscheidung »D« ist noch in zwei weitere Teilentschei-
dungen der dritten und letzten Stufe möglich. Im Beispiel führt die Zerlegung
zu elf möglichen Entscheidungen des Problems »A«. Jede der Entscheidungen
E1 bis E11 hat eine Bewertung, wie z.B. eine Erfolgswahrscheinlichkeit.
Die Erfolgswahrscheinlichkeit w(E) der Entscheidung E ist das Produkt aller
Erfolgswahrscheinlichkeiten des Weges von der Wurzel des Entscheidungsbau-
mes bis zum betreffenden Entscheidungsblatt. Für die Entscheidungen E1 und
E2 ist dies
w1(E1) = w(AB) · w(BD) · w(DE1) = 0,3 · 0,2 · 0,1 = 0,006
w(E2) = w(AB) · w(BD) · w(DE1) = 0,3 · 0,2 · 0,9 = 0,036
Zu jeder neuen Entscheidungsstufe führt ein Entscheidungskriterium bzw.
eine Entscheidung. Die Kriterien können unter Umständen in der Reihenfolge
der Entscheidungszerlegung vertauscht werden.
204 Kapitel 4 • Welche Softwarekomponenten sind für ein DWH einzusetzen?

Es ist möglich, dass die gleiche Entscheidung auf mehreren Zerlegungswegen


erreicht werden kann. Dann werden die beiden Erfolgswahrscheinlichkeiten
der beiden Wegeprodukte addiert.
w2(E1) = w(AC) · w(CH) · w(HE1) = 0,7 · 0,7 · 0,7 = 0,343
w(E1) = w1(E1) + w2(E1) = 0,006 + 0,343 = 0,349
Zusammenfassend lässt sich sagen:
➡ Die Funktion Entscheidungsbaum zerlegt ein Entscheidungsproblem hier-
archisch in Entscheidungsstufen mit ein oder mehreren Entscheidungs-
möglichkeiten je Stufe. Jeder Einzelentscheidung kann eine Erfolgswahr-
scheinlichkeit zugeordnet werden, über die eine Erfolgswahrscheinlichkeit
aller möglichen Entscheidungen und aller Zwischenstufen-Folgen berech-
net wird.


 

 
   


    
        


  
     

Abbildung 4.14: Beispiel eines Entscheidungsbaumes

Cluster
Die Clusteranalyse wurde entwickelt, um aus einer Punktemenge Gruppen von
nahe beieinander liegenden Punkten zu entdecken.
In der Ebene kann man diese Gruppen von Punkten in der Regel mit bloßem
Auge erkennen. In einer Datenbank sind diese Gruppen nicht sichtbar und bei
besonders großen Mengen von Datenpaaren sind der Leistungsfähigkeit des
Auges Grenzen gesetzt. Hinzu kommt, dass das Auge nur zwischen eng beisam-
men und weiter entfernt unterscheiden kann, aber keine Messwerte ausgibt
und damit subjektiv wahrnimmt. Für eine objektive Messung ist ein Maßstab
zur Abstandsmessung, ein Abstandsmaß, erforderlich.
Alle bekannten Punkte werden in einer x-y-Ebene mit maßstäblichen Skalen
eingetragen. Ein Programm berechnet die Abstände aller Punkte zueinander
und gruppiert einem Maximalwert eines Abstandes entsprechend alle Punkte-
paare, deren Abstand kleiner als der Maximalwert ist. Die Punktegruppen hei-
ßen Cluster. Ein Punkt gehört immer zu genau einem oder gar keinem Cluster.
Kapitel 4 • Welche Softwarekomponenten sind für ein DWH einzusetzen? 205

Die Punkte können auch im mehrdimensionalen Raum definiert sein.


Zusammenfassend lässt sich sagen:
➡ Die Funktion Clusteranalyse stellt Punkte in einem n-dimensionalen Raum
einem Abstandsmaß folgend ihrem Abstand entsprechend zu Gruppen,
Cluster genannt, zusammen.



  
   
 
 



Abbildung 4.15: Beispiel einer Clusterdarstellung

Trendkurve
Die Trendkurve macht die Annahme, dass die Punkte einer zu analysierenden
Datei Messwerte einer mathematischen Funktion sind, die ungenau gemessen
wurde. Dies ist z.B. in der Physik durch Umgebungsbedingungen, abgenutzte
Messwerkzeuge und Ablesefehler der Fall. Mit der Trendanalyse versucht man
nun, diese eigentliche Kurve zu rekonstruieren. Die Punkte streuen um die
gesuchte Trendkurve.

 


Abbildung 4.16: Beispiel einer Trendkurve


206 Kapitel 4 • Welche Softwarekomponenten sind für ein DWH einzusetzen?

Ziel der Trendanalyse ist, diese Kurve nicht nur für die vorliegenden Punkte
herauszufinden, sondern auch für nicht gemessene Werte außerhalb der
Punktmenge. Die Trendkurve wird außerhalb der Punktemenge fortgesetzt.
Zusammenfassend lässt sich sagen:
➡ Die Funktion Trendermittlung berechnet aus Punkten in einem n-dimensi-
onalen Raum eine geschätzte Kurve mit der geringsten Abstandssumme zu
den Punkten und berechnet Werte, die außerhalb der Punktemenge liegen,
entsprechend der Fortsetzung der Kurve Trendkurve genannt.

Multiwürfel
Die Datendarstellung als Multiwürfel ist aus dem Bedürfnis entstanden, die
Datenfelder zu multidimensionalen Parametern übersichtlicher darzustellen.
Mit der Multidimensionalität ist gemeint, dass der Wert oder Inhalt eines
Datenfeldes von den Werten einer festen Anzahl anderer verschiedener Daten-
felder, den Dimensionen, abhängt.
Ein vielzitiertes Beispiel ist der Umsatz, das abhängige Datenfeld eines dreidi-
mensionalen Multiwürfels; der Inhalt des Datenfeldes ist die Umsatzzahl, z.B.
in DM. Die drei Würfel-Dimensionen sind die Datenfelder »Produkt«,
»Region«, »Zeit«. Die im Würfel dargestellte Aussage ist dann von dem Muster:
✔ eine spezielle Umsatzzahl ist der Umsatz in DM
zu einem bestimmten Produkt
in einer bestimmten Region
in einem bestimmten Zeitabschnitt
Die Werte der Dimensionen sind entlang der Würfelkanten zu lesen, also zum
Beispiel sind die Werte der Dimension »Zeit« die Monate und die Werte der
Dimension »Produkte« die Namen der einzelnen Produkte.
Die Einheit einer Dimension kann zu Akkumulationseinheiten zusammenge-
fasst werden. Zum Beispiel kann zur Dimension »Zeit« die Einheit »Monate«
und die Einheit »Jahre« angeführt werden.
Je feiner die Einheit gewählt wurde, umso mehr Verdichtungsebenen oder
Akkumulationsstufen sind möglich. Eine feinere Zeiteinheit könnte z.B. »Tage«
sein, und die Akkumulationsstufen in der Reihenfolge ihrer Verdichtung könnte
dann sein: »Wochen«, »Monate«, »Quartale«, »Jahre«, »Gesamtzeitraum«.
Multiwürfel können im relationalen Datenmodell aus einer zentralen Tabelle
und sternförmig damit in Relation stehenden Tabellen (eine pro Dimension)
dargestellt werden. Deshalb wird oft von Star-Schema gesprochen.
Bei mehr als zwei Dimensionen kann man den Blick auf den Würfel verändern.
Im Beispiel kann man z.B. aus der Sicht eines ausgewählten Produkts die
Matrix (zweidimensionaler Würfel) der Umsätze der Regionen entsprechend
den Zeiteinheiten sehen. Die Sicht kann auf verschiedene Akkumulationsebe-
nen eingestellt werden. So kann die Matrix die Umsätze der Monate oder der
Wochen oder der Jahre ausweisen.
Kapitel 4 • Welche Softwarekomponenten sind für ein DWH einzusetzen? 207

Zusammenfassend lässt sich sagen:


➡ Die Funktion Multiwürfel erlaubt die Zusammenstellung von Daten zu
einem multidimensionalen Würfel in Abhängigkeit von einer festen Anzahl
von Dimensionen, mit allen Navigations- und Akkumulationsmöglichkeiten
entlang der Dimensionen des Würfels. Für die Akkumulationsmöglichkeiten
können je Dimension hierarchische Verdichtungsebenen definiert werden.
Ein Beispiel eines Multiwürfels mit drei Dimensionen und seinen Aggregatio-
nen ist weiter oben im Abschnitt »OLAP-System« dieses Kapitels angegeben.

4.2.3 Funktionale Gestaltung der DWH-Software


Problemstellung und Motivation
Komponentenbezug
Die weiter oben in diesem Kapitel ausgewählten Komponenten sind in Funktio-
nalität, Ergonomie und Erweiterbarkeit weitgehend unterschiedlich ausgestat-
tet. Die Funktionalität findet bei jedem Hersteller je nach Produktphilosophie
eine andere Ausprägung. Die Funktionalität ist unterschiedlich, da sie für
unterschiedliche Anwender und unterschiedliche Aufgaben hergestellt wurde.
Da ein DWH mit der Recherche, Präsentation, Interpretation und Zusammen-
stellung von Daten andere Aufgaben verfolgt als andere vergleichbare Informa-
tionssysteme, muss es auch besondere Funktionen bieten, mit denen diese Auf-
gaben unterstützt werden. Diese Funktionen sind weniger auf die Datenhaltung
bezogen. Dies können die Datenbankmanagementsysteme schon sehr gut, sie
konzentrieren sich auf Finden, Auswerten und Visualisieren. Es sind daher
weniger die Eingaben und die Bearbeitung der operativen Daten betroffen.
Anwenderbezug
Ein DWH verfolgt aber nicht nur andere Aufgaben, sondern spricht auch eine
besondere Klientel des Unternehmens an, die diese Aufgaben wahrnimmt. Die
Anwender sind in erster Linie Entscheidungsträger aller Ebenen, also auch der
obersten Managementebene. Führungskräften steht in der Regel nicht so viel
Zeit zur Verfügung, dass sie sich lange mit Anwenderhandbüchern auseinan-
dersetzen könnten, um eine Software zu bedienen. Führungskräfte haben auch
ein sehr vielfältiges Arbeitsspektrum, was eine kontinuierliche Verwendung
eines Softwaresystems verhindert. Aber durch die Tendenz zu flachen Hierar-
chien in Organisationen werden zunehmend mehr Managementfunktionen an
die operativen Bereiche delegiert und andererseits werden einige operative
Tätigkeiten schneller mittels EDV durchgeführt als delegiert. Das bedeutet,
dass ein DWH auch eine besondere Ergonomie oder, funktional gesprochen,
besondere ergonomische Funktionen für das Data Warehousing bieten muss.
Nach dem Überblick über die funktionalen Möglichkeiten ist nun die Frage
nach der funktionalen Gestaltung des DWH durch den DWH-Spezialisten zu
lösen.
208 Kapitel 4 • Welche Softwarekomponenten sind für ein DWH einzusetzen?

Gestaltungs- und Lösungsmöglichkeiten


Der Gestaltungsspielraum besteht zunächst einmal aus der Definition der tech-
nischen Funktionalität, der ergonomischen Funktionalität und dann aus der
Auswahl dessen, was der Beschaffungsmarkt zur Verfügung hat. Die Methodik
für die Auswahl (»Wie findet man das richtige Produkt?«) ist die Evaluations-
studie. Die Evaluationsstudie setzt, wenn sie nicht in einer Schublade ver-
schwindet, sondern präsentiert und kommuniziert wird, die Diskussion um
wirklichen Bedarf, um die organisatorischen Konsequenzen und die Kosten in
Gang, und führt zu Vereinbarungen über weitere Maßnahmen.
Die Softwarebranche ist noch nicht so weit entwickelt wie z.B. der Maschinen-
bau, wo man Funktionsbausteine kaufen und zu einem System montieren
kann. Deshalb werden heute in der Regel nicht einzelne Funktionen erworben,
sondern komplexere Komponenten. Zukünftig wird sich allerdings die Kompo-
nentenmontage gegenüber der Komplettlösung durchsetzen. Die Definition der
funktionalen Anforderungen ist Grundlage der Evaluation der Komponenten,
d.h. des funktionalen Vergleichs des Marktangebotes der verschiedenen Pro-
dukte. Wie eine Evaluationsstudie hierzu aussieht, was sie aussagen soll und
wie man einen optimalen Weg durch die vielen Kriterien findet, wird in Kapitel
7, »Das Vorgehensmodell für Data Warehouse Systeme« vorgestellt. Vor der
Evaluation steht jedoch die Definition der Funktionalität.
➢ Erstellen der Funktionenliste des DWH mit allgemeinen Funktionen
Editoren, Generatoren, Treiber
➢ Erstellen der Funktionenliste der speziellen DWH-technischen Funktionen
Data Mining, Reporting, Ergebnispräsentation
➢ Spezifikation der Anpassungsfähigkeit der Funktionalität
➢ Spezifikation der Funktionen, die in Eigenentwicklung hergestellt werden
müssen
Bei einer Entscheidung für eine Beschaffung geeigneter Produkte ist ein weite-
rer Gestaltungsschritt erforderlich, er betrifft die Anpassungsfähigkeit der Pro-
dukte. Bei mangelnder Anpassungsfähigkeit kann sich die Gestaltungsaufgabe
bis zur Spezifizierung einer unternehmensadäquaten, selbst zu entwickelnden
Lösung ausweiten. Dieser Gestaltungsschritt, der zwischen »selbst machen«
oder »machen lassen« (make or buy) unterscheiden muss, setzt eine komplexe
Vorgehensweise, den Entwurf, voraus und wird deshalb in Kapitel 7 »Vorge-
hensmodell« behandelt.

Problemlösung: Regeln und Hilfsmittel


Das Verfahren
Nach der Bestimmung der Komponenten und der Softwarearchitektur ist jetzt
die funktionale Ausstattung der Komponenten festzulegen. Hierbei hilft folgen-
des Verfahren:
Kapitel 4 • Welche Softwarekomponenten sind für ein DWH einzusetzen? 209

Verfahren: DWH-Funktionen
❖ Festlegung der allgemeinen funktionalen Anforderungen mit Hilfe der
DWH-Funktionenliste
❖ Festlegung der ergonomischen Funktionen
Feststellung der zu versorgenden Managementebenen
(wenn nicht bereits im Schritt betriebswirtschaftliche Anwendung
geschehen)
Ableitung der Ergonomie-Funktionen
Festlegung der Ergonomiekomponenten
❖ Festlegung der spezifischen Funktionen
entsprechend der ausgewählten Komponenten
❖ Spezifikation der Anpassungsfähigkeit der Funktionalität
Festlegung der Entwicklungsfunktionen
❖ Spezifikation der Funktionen, die in Eigenentwicklung hergestellt
werden müssen

Die zu lösende Gestaltungsfrage lautet also: Mit welcher Funktionalität soll ein
DWH ausgestattet sein und wie kann man die Konsequenzen des Fehlens der
einzelnen Funktionen einschätzen.

DWH-Funktionenliste
Das Mittel zur Definition der Funktionalität ist eine DWH-Funktionenliste, die
aus Literaturstudium, Evaluationsstudien und Produktvergleichen selbst ange-
fertigt werden kann. Oftmals sind in einer Fachzeitschrift taugliche Listen ver-
öffentlicht. Meistens sind dort allerdings die Konsequenzen fehlender Funktio-
nen nicht dargestellt.
Die veröffentlichten Listen bergen die Gefahr in sich, dass die für das eigene
Unternehmen relevanten Teile dort eine untergeordnete Rolle spielen, da sie
meistens aus verwandten, aber leider nicht identischen Projekten stammen und
nur begrenzt verwendbar sind. Hier kann die Beauftragung eines Beratungsun-
ternehmens, das eine auf die spezielle Situation des Unternehmens bezogene
aktuelle Funktionenliste zusammenstellt, weiterhelfen. Die Konsequenzen
mangelnder Funktionskenntnis sind erheblich. Sie sind entweder mit Leis-
tungseinschränkung oder mit Mehraufwand, weiterem Zukauf und Terminbe-
lastung verbunden. Die Feststellung der interessanten Funktionen sollte in
einer sinnvollen Reihenfolge abgewickelt werden.
Neben den Betrachtungen zu speziellen für das DWH nützlichen Funktionen
gibt es übergreifende Kriterien, allgemeine Anforderungen, die von der speziel-
len Funktionalität des DWH unabhängig sind.
210 Kapitel 4 • Welche Softwarekomponenten sind für ein DWH einzusetzen?

Je mehr Programme einem User zur Verfügung stehen, umso mehr Benutzer-
führungen muss der Benutzer beherrschen. Die Gefahr, Programm A mit der
gerade intensiv betriebenen Benutzerführung von Programm B versehentlich
zu bedienen, kann unbeabsichtigte Reaktionen von Programm B auslösen. Die
Bedienungselemente der Programme unterschiedlicher Hersteller haben eine
unterschiedliche Präsentation oder Symbolik auf dem Bildschirm. Der Anwen-
der wird dadurch, je heterogener die Produktelandschaft ist, mit einem erhöh-
ten Lernpensum und mit ständigem Umorientieren bei wechselnder Nutzung
der Programme konfrontiert. Das macht seine Arbeit ineffizient.
➡ Die allgemeinen Funktionen und ihre Präsentation sollten über eine
Anwendung oder noch besser über alle im Unternehmen eingesetzten
Anwendungen einheitlich sein.
Jede Überfunktionalisierung steigert die Fehlerhäufigkeit und die Nachfragen
der User zur Klärung der Frage, ob man die Funktion vielleicht doch irgendwie
gebrauchen könnte. Damit steigen die Aufwendungen für die Administration
und Betreuung.
➡ Reduktion der Gesamtfunktionalität auf das in der Bedarfsanalyse für jeden
Benutzertyp erhobene Minimum an Funktionalität
Als Einstieg in die systematische Zusammenstellung der DWH-Funktionalität
sei hier eine Liste vorgestellt (siehe Tabelle 4.5).
Die Funktionen haben nicht alle die gleiche Wichtigkeit und müssen deshalb
auf ihre Notwendigkeit beurteilt werden. Es sind drei Kategorien ausreichend:
✔ Muss-Funktionen, ausschließende Kriterien; Produkte die diese Kriterien
nicht erfüllen oder diese Funktionen nicht besitzen werden ausgeschlossen
✔ Soll-Funktionen; ein Fehlen dieser Funktionen hat Konsequenzen für Ter-
mine, Aufwände und Qualität
✔ Kann-Funktionen; wünschenswerte Funktionen, die nur leichte Einbußen
für den Nutzer bedeuten
Die Liste der funktionalen Anforderungen wird in der Evaluation verwendet. In
mittelfristiger Zukunft wird die Liste als Bestellliste für Funktionsbausteine
dienen können. Durch die Vielzahl der eingesetzten Werkzeuge ist zu beachten,
dass sich die Funktionalität der einzelnen Komponenten überschneidet. Die
Mehrfachabdeckung gleicher Funktionen soll unbedingt minimiert werden.
Kapitel 4 • Welche Softwarekomponenten sind für ein DWH einzusetzen? 211

Technische Funktion Entwicklungsfunktion Ergonomie-Funktion

Metafunktionen Entwicklungssoftware-Tools Benutzerführung


Programmgenerator 3GL-Compiler Hilfeführung

Formelgenerator Makroeditor Customizer

Metamodeller Makrorecorder Online-Handbuch

SQL-Generator Lernprogramm
Schnittstellenfunktionen 4GL-Compiler

Gerätetreiber Datenbankschemagenerator
Importfunktion Datenbankschemadesigner
Exportfunktion Editierfunktionen

Softwaretreiber Reportgenerator Elementarfunktionen

Fachfunktionen Zahlen-Grafik-Wandler Bearbeitungsfunktion


Formelschema Grafik-Grafik-Wandler Bearbeitungshinweisfunktion
Betriebswirtschaftliches Textverarbeitung
Modell
Referenzmodell Kalkulationssheet
Regelmodell Exceptionanzeige Navigationsfunktionen

Formular-Formatierer Navigator

Statistische Funktionen Dokumentmontage Driller (down, across, ...)

Sensitivitätsanalysen

Clusteranalyse Administrationsfunktionen Visualisierungsfunktionen


Trendrechnung Replikator Simulator

Korrelation Performancetuning Animator

Multidimensionale Analyse Berechtigungsverwaltung Visualisierer

ABC-Analyse Modellverwaltung

DWH-Funktionen
Neuronales Netz

Fuzzy-set-Analyse
Optimierungsrechnung

Hypothesengenerator

Entscheidungsbaum-
analyse

Tabelle 4.5: Muster Funktionenliste Data Warehouse

4.3 Die softwaretechnischen Technologietypen


Problemstellung und Motivation
Technologietypus
Die Entscheidung für den Softwaresystemtyp fällt schon in der Orientierungs-
phase. Dort werden die Ansätze Executive Information System, Decision
Support System, OLAP-System, KDD-System und umfassender DWH-Ansatz
212 Kapitel 4 • Welche Softwarekomponenten sind für ein DWH einzusetzen?

gegeneinander abgewogen. Bezüglich der Frage der Technologien und der


softwaretechnischen Tools und Komponenten müssen weitere Entscheidungen
getroffen werden:
✔ Entscheidung, Zukauf oder Neuentwicklung, besser bekannt als
»Make-or-Buy-Decision«
✔ Entscheidung des Verteilungstypes zentral-dezentral
✔ Entscheidung für Anwendungsschwerpunkte
Im Folgenden wird der Reihe nach auf die drei Technologiekriterien »Ferti-
gungstypen«, »Fachtypen« und »Verteilungstypen« des Data Warehouse einge-
gangen. Alle drei Kriterien zusammen definieren den Technologietypus der
Softwarekomponente.
Softwarefertigungstypus
Der Fertigungstypus einer Softwarekomponente ist, wie bei der Entscheidung
zur betriebswirtschaftlichen Funktionalität, von der Ebene der Anwender
abhängig. Bezüglich der betriebswirtschaftlichen Funktionalität war die
Anwenderebene für den Verdichtungsgrad der Daten wichtig. Bezüglich des
Softwaretyps ist die Anwenderebene für die Ergonomie ausschlaggebend. Je
höher die Ebene des Nutzers in der Hierarchie des Unternehmens, desto selte-
ner ist der Umgang mit der EDV möglich.
Über die Anwenderebenen wurde im vorigen Kapitel »Die betriebswirtschaftli-
che Architektur von Data Warehouse Systemen« gesprochen. Als Visualisierung
wurde die Managementpyramide gezeigt. Diese Pyramide dient auch hier als
Orientierungs-grundlage zur Zuordnung der Softwaretypen. Da unterschiedli-
ches Nutzerverhalten auf den Hierarchieebenen des Unternehmens unter-
schiedliche Anforderungen an die Software stellen, haben sich unterschiedliche
Ergonomietypen entwickelt, die zu unterschiedlichen Komponenten von Syste-
men wurden. Die Unterschiede zeigen sich im Abstraktionsgrad der verfügba-
ren Programmiersprachen, in der Automatisierung von Programmprozessen,
in der Verborgenheit oder Transparenz der internen Architektur.
Schlechte Erfahrungen mit Individualprojekten durch zu lange Laufzeiten,
mangelnde Funktionalität, Budgetüberschreitungen und sogar die Erkenntnis,
dass einige Vorhaben gar nicht umsetzbar sind, ließ das Interesse an komplet-
ter Standardsoftware in den letzten Jahren wieder erheblich wachsen. Hinzu
kommt der Zeitdruck durch den Millenniumswechsel, die Euroumstellung und
die Unsicherheit, alle Datumsstellen in den vorhandenen Programmen recht-
zeitig zu finden und schnell ausbessern zu können. Da war es aus der Sicht der
Unternehmensführung schon wesentlich einfacher, die gesamte Software durch
»millenniumsichere« Standardpakete zu ersetzen.
Daneben hat sich auch bezüglich Quantität und Effizienz auf dem Sektor der
Tools zur Eigenentwicklung oder Individualentwicklung viel getan. Es sind
Entwurfswerkzeuge von der Qualität von CAD-Programmen entwickelt worden.
Kapitel 4 • Welche Softwarekomponenten sind für ein DWH einzusetzen? 213

Sie dienen zum Zeichnen von Programm- und Datenbankstrukturen bis zur
Erzeugung von Programm-„Stücklisten«. Einige können sogar Programmkom-
ponenten und Datenbanken generieren. Die eigentliche Programmierarbeit
wird immer häufiger durch immer leistungsfähigere Generatoren ersetzt.
Eine Zwischenvariante zwischen absoluter Eigenentwicklung und Standard-
software ist Zukauf und Eigenentwicklung von Bausteinen und deren Montage
in ein neu zugekauftes Framework, bzw. in eine zugekaufte Mutterapplikation,
die Komponentenmontage. Diese setzt voraus, dass man ein standardisiertes
Framework hat. Man weiß heute noch nicht, welche Produkte von Frameworks
sich langfristig durchsetzen werden. Auf alle Fälle kann man in den Medien ein
verstärktes Interesse am Zusammenbau von Software aus Komponenten durch
die anwendenden Unternehmen ausmachen.
Die Entscheidungsmöglichkeiten der Softwarefertigungstypen sind:
✔ Beschaffung von fertigprogrammierter Standardsoftware (technische Soft-
ware, kaufmännische Software), wenn alle gewünschten Eigenschaften zur
Zufriedenheit der Anwender abgedeckt sind
✔ Officetools, wenn die Aufgaben nicht vorherbestimmbar sind und nur für
einige ausgewählte Anwender anfallen, so dass umfassende Individual-Pro-
grammierung zu teuer ist
✔ Vorgefertigte Softwarebausteine, Komponenten, Programmmuster, Frame-
works
✔ Entwicklungswerkzeuge für die Individualentwicklung, wenn wesentliche
der geforderten Eigenschaften nicht enthalten sind
✔ Reine Individualprogrammierung mit Programmiersprachen früher Gene-
rationen
Mit der Entscheidung für den Fertigungstyp ist die Entscheidung über die
Anpassungsfähigkeiten des Softwarepakets getroffen:
✔ Ausprogrammierte, starre Standardsoftware, wenn kein eigenes Personal
für Anpassungsarbeiten aufgebaut und unterhalten werden soll und wenn
die Arbeit einem weithin bewährten Industriestandard zugeführt werden
soll
✔ Parametrisierte und konfigurierbare Standardsoftware
✔ Komponentenzukauf, wenn ein gutes Framework vorhanden ist und die
Komponenten die erforderlichen Eigenschaften abdecken
✔ Dynamische Selbstkonfiguration
Jeder Fertigungstyp hat eine andere Benutzerführung und andere Freiheits-
grade in der weiteren Ausgestaltung und der Starrheit der Anwendung. So
erlauben zum Beispiel Workflowsysteme, die Veränderung der Reihenfolge der
Benutzerschritte ohne Programmierung zu verändern. Kalkulationstabellen-
214 Kapitel 4 • Welche Softwarekomponenten sind für ein DWH einzusetzen?

programme (Spreadsheet) erlauben dem Benutzer die Erstellung von Reports


und ermöglichen mit Hochsprachen, eigene Programme zu programmieren
(Makros). Standardsoftware lässt sich mit einigen Parametereingaben an die
Benutzerwünsche anpassen. Executive Information Systems erlauben einen frei
definierbaren Zugriff auf vorhandene Datenquellen, was bei Standardsoftware
fest programmiert ist. Desktoptools wie Office-Programme erlauben die Verän-
derung der Menüzeile entsprechend der eigenen Arbeitsergonomie. Eine
Zuordnung der Standardtypen zum Hierarchielevel der Organisation zeigt die
Abbildung »Softwarefertigungstypen«.
Fachtypus
Die Softwaretechnologie wird auch von der fachlichen Aufgabe beeinflusst,
wenn nicht sogar geprägt. Die fachlich bedingte Ausprägung ist der Fachtypus
der Softwarekomponente. In Prozesssteuerungsprogrammen kommt es z.B.
auf die Echtzeit der Programmausführung an, was zu prozessornah arbeiten-
den Komponenten mit dem Schwerpunkt auf minimalen Ausführungszeiten
führt. Geographische Systeme müssen topologische Strukturtreue und metri-
sche Abbildungen sicherstellen und effizient wiedergeben. Das führt zu speziel-
len Anforderungen an grafische Präsentation und Netzdatenbanken. Ähnlich
wie geographische Strukturen sind auch die Strukturen technischer Systeme
topologisch, das heißt in der Form ihres Zusammenbaus abzubilden. Wobei
anders als in geographischen Systemen es nicht auf Punktedichte, sondern nur
auf Nennung der Beziehungen und Zusammengehörigkeit der Bauteile unter-
einander ankommt. Für alle diese Anforderungen sind besondere Datenbankar-
chitekturen, spezielle Programmarchitekturen und auch Präsentationsarchi-
tekturen, also Softwaretechnolgien, entwickelt worden.
Der Fachtypus ist komponentenbezogen zu sehen, da in einem Softwaresystem
mehrere fachlich verschiedene Aufgaben abgedeckt werden können und damit
das Softwaresystem auch mit mehreren Technologien realisiert werden muss.
Beispiele für Office Standard Systeme sind:
✔ Textverarbeitung
✔ Grafikprogramm
✔ Kalkulationsprogramm, Tabellenrechnung, Statistiken, Businessgrafiken
✔ Präsentationsprogramm
Beispiele für technische Standardsysteme sind:
✔ CAD
✔ CIM
✔ Produktionssteuerung
✔ Engineering Database Management, Produkt-Daten-Managementsysteme
✔ Technische Berechnung und Auslegungsprogamme
Kapitel 4 • Welche Softwarekomponenten sind für ein DWH einzusetzen? 215

✔ Festigkeitsberechnung, Finit-Elemente-Berechnung
Beispiele für kaufmännische Standardsysteme sind:
✔ Kostenrechnung und Finanzbuchhaltung
✔ Personalverwaltung
✔ Materialverwaltung
Beispiele für geographische Systeme sind:
✔ Wetterkarten
✔ Geographische Orientierungssysteme
✔ Routenplaner
Beispiele für Prozesssteuerungssysteme zur Steuerung von Industrieprozes-
sen sind:
✔ Verkehrsleitsysteme
✔ Hausleitsysteme
✔ Leitstände von Energieversorgungsanlagen
✔ Produktionsstraßensteuerung
Beispiele für übergreifende Systeme sind:
✔ Archivierung
✔ Kommunikation, Fax, Mailing
Bleibt noch anzumerken, dass diese Liste der fachlichen Technologietypen
nicht vollständig ist und durch Neuentwicklungen des Marktes ständig erwei-
tert wird.
Verteilungstypus
Die Verteilungstypen einer Software unterscheiden sich durch ihre Auftren-
nung in Komponenten, die auf verschiedenen Rechnern betrieben werden kön-
nen. Für diese Auftrennung wurden die drei Ebenen Präsentationsschicht,
Applikationsschicht, Datenhaltungsschicht definiert. Auf den jeweiligen Archi-
tekturschichten sind wieder verschiedene Softwaretechnologien einsetzbar und
kombinierbar.
Diese Schichten können selbst wieder zerteilt und die Bestandteile weiter ver-
teilt werden. Dies ist im »Exkurs Client/Server-Architekturen« am Ende von
Kapitel 5 »Hardware« ausführlich dargestellt. Die Möglichkeiten des Zusam-
menspiels dieser Teilung führt zu den folgenden Verteilungsarchitekturen:
✔ Host-Terminal
✔ Entfernte Präsentation
216 Kapitel 4 • Welche Softwarekomponenten sind für ein DWH einzusetzen?

Präsentationsschicht Applikationsschicht Datenhaltungsschicht

Zeichenorientierung, Maschinensprache Flache Filesysteme


erweiterte Zeichensätze

Grafisch Assembler Hierarchische DB

Verteilte Grafik Third Generation Language Relationale DB

Multimedial Fourth Generation Language Netz-DB

Fifth Generation Language Objektorientierte DB

Objektorientiert Regelbasierte DB

Regelbasiert Deduktive DB

Fuzzy Fuzzy DB

Tabelle 4.6: Schichtentechnologien

✔ Client-Server
✔ Remote Zugriff
✔ Mobiles System
✔ Peer to peer
✔ Multi Tier System
Diese Aufzählung ist nur als Orientierung und zur Verdeutlichung der Vielfäl-
tigkeit der Möglichkeiten gedacht. Vollständige Klassifikationen mit Begrün-
dungen sind vereinzelt in verschiedenen Büchern zu der jeweiligen Thematik
zu finden, z.B. für das Thema Verteilung in
 Mühlhäuser, Software Engineering
Programmiersprachen und deren Klassifikation in
 Sammet, Programming Languages
 Ghezzi, Jazayeri, Programmiersprachen
Datenbanken, deren Klassifikation und Technologie in
 Vossen, Datenmodelle
Aus der Sicht der Verteilungstechnologien von Software sind folgende Schich-
tenkombinationen wesentlich:
✔ Hostbasierte Applikation mit hierarchischer Datenbank und zeichenorien-
tierter Oberfläche und Terminal
✔ Client/Server-Architektur mit relationaler Datenbank und grafischen Ober-
flächenobjekten
Kapitel 4 • Welche Softwarekomponenten sind für ein DWH einzusetzen? 217

✔ Durchgängig objektorientierte Applikation über alle Schichten der Software


einschließlich der Datenbank mit verteilten Objekten
✔ Web-Architektur mit Datenbankserver, Web-Applikationsserver, Browser
Aus den Darstellungen erwächst die folgende komplexe Gestaltungsaufgabe zur
Bestimmung der Softwaretechnologie für den DWH-Spezialisten.

Gestaltungs- und Lösungsmöglichkeiten


Da man sich nicht ein komplettes DWH-System selbst entwickeln kann (100 PJ
Entwicklungszeit), setzt man Standardkomponenten ein, die dann für den eige-
nen Zweck konfiguriert, ergänzt, teilsubstituiert und weiterentwickelt werden.
Die Gestaltung besteht in diesem ersten Schritt aus der Sichtung des Marktes
nach angebotenen Softwarekomponenten der einzelnen Hersteller.
Die Gestaltungsaufgabe in diesem Schritt besteht aus der Zusammenstellung
der Komponenten, die das beabsichtigte DWH enthalten soll, und der Entschei-
dung, wie diese hergestellt werden sollen:
➢ Zusammenstellung der Komponenten des DWH
Bezüglich des Freiheitsgrades der Anpassungsmöglichkeiten, die natürlich
auch vom Fertigungstyp abhängen, sind fertig ausprogrammierte und starr ein-
zusetzende Standardsoftware, parametrisierbare und tabellengesteuerte Stan-
dardsoftware und montierbare Softwarekomponenten zu unterscheiden. Eine
besondere Stellung im Rahmen der Individualentwicklung stellen die Office-
tools dar, mit denen sich Anwender bei Bedarf und ad hoc selbst Programme
entwickeln können. Beispiele sind EXCEL-Makros, Word-Templates, ACCESS-
Datenbankanwendungen. Das führt zu einer weiteren Gestaltungsentschei-
dung.
➢ Entscheidung der Anpassungsfähigkeiten: starr, parametrisiert, montierbar
➢ Entscheidung des Fertigungstyps der Software: Standardsoftware, Enduser-
Tools, Individualsoftware
Eine Sonderstellung in Standardsoftware stellen grafik-intensive und auf spezi-
ellen Datenbanken arbeitende technische Programme wie CAD, CAE, technische
Systeme und Geographie-Systeme dar, da sie eigens entwickelte Architekturen
und Technologien, wie spezielle Datenbanken, besitzen. Die Gestaltungsaufgabe
im zweiten Schritt besteht aus der Entscheidung, von welchem Fachtypus die
einzelnen Komponenten des gewünschten DWH sein sollen.
➢ Entscheidung des Fachtypus einzelner Komponenten des DWH
Jede einzelne Komponente kann unter Umständen in unterschiedlich ausge-
stattete und lokal verteilte Rechner installiert werden. Es ist deshalb die Gestal-
tungsfrage des Verteilungstypus zu lösen.
➢ Entscheidung über Verteilungstypus einzelner Komponenten des DWH
218 Kapitel 4 • Welche Softwarekomponenten sind für ein DWH einzusetzen?

Problemlösung: Regeln und hilfsmittel


Das Verfahren
Bezüglich des Fertigungstypus der Software gibt es nach der grundsätzlichen
Einordnung der Softwarekategorie, wie bereits gezeigt, die Unterscheidungen
Standardisierungsgrad und den von der Rechnerorganisation abhängigen Tech-
nologietyp. Zur Problemlösung der Technologiefrage sind also mehrere
Schritte erforderlich:
✔ Fachliche Technologietypen von einzelnen Komponenten
✔ Feststellung des Fertigungstypus oder auch des Standardisierungstypus
✔ Verteilungstechnologien von Software
Zu empfehlen ist folgende Vorgehensweise:

Verfahren: Bestimmung des Software-Technologietypen der DWH-Komponenten


❖ Festlegung des Standardsoftwaretyps bzw. des Fertigungstypus und der
Anpassungsfähigkeit der Software
Ausprogrammierte starre Standardsoftware
Parametrisierte Standardsoftware
Fähigkeit zur Komponentenmontage
❖ Festlegung von Fachtypen von einzelnen Komponenten
technisch, kaufmännisch, geographisch, prozesstechnisch, integrativ
❖ Festlegung der Verteilungsarchitektur und des Verteilungstypus

Technologietypus
Wesentliche Bedingung für die Entscheidungsfreiheit ist der Markt. Was nüt-
zen die besten Vorsätze, wenn der Markt nicht die nötigen Produkte hierfür
anbietet? Die Entscheidung des Software-Technologietypus hängt in erster
Linie ab
✔ von der Bereitschaft des Unternehmens, neue Wege in der Hardwaretechno-
logie einzuschlagen, bzw. von der Beharrlichkeit, sich auf die altbewährten
Technologien zu verlassen:
⇒ Beibehalten alter Host/Terminal-Systeme oder
⇒ Ablösen durch moderne Client/Server-Architekturen
✔ von der Berücksichtigung vorhandener Softwaresysteme: Teile eines DWH
sind bereits auf vorhandenen Technologien realisiert
⇒ Beibehalten der Host/Terminal-Systeme oder
⇒ Integration des Host als Server-Komponente
✔ von der Bereitschaft, in die modernste Technologie zu wechseln
⇒ Vollständige objektorientierte Anwendungen eventuell mit verteilten
Objekten
Kapitel 4 • Welche Softwarekomponenten sind für ein DWH einzusetzen? 219

✔ von der Bereitschaft, Risiken und Verantwortung für die Eigenentwicklung


zu übernehmen
⇒ Zukauf von Standardsystemen und Schnittstellenentwicklung oder
Eigenentwicklung
✔ von der Flexibilität der Anpassungen
Matrix der Technologietypen
Die Entscheidungsmöglichkeiten der Matrix der fachlichen Klasse sind in die-
sem Kapitel in den Übersichten dargestellt. Jetzt sind noch die Einzelentschei-
dungen der drei Technologietypen im Zusammenhang zu betrachten. Hierfür
ist die Matrix der Software-Technologietypen eine gute Hilfe. Sie hat als Spal-
ten die fachlichen Technologietypen aufgelistet und in den Zeilen ist der Ferti-
gungstyp in abnehmender Standardisierung aufgereiht. Jede der Typenkombi-
nationen kann in verschiedenen Verteilungsarchitekturen aufgebaut werden.

Präsentation
Applktn DB
Applikation
Datenbank

DWH i.e.S., EIS OLAP DSS


Technische
Technische Office Kaufmännische Geografische
Prozess
Systeme Systeme Systeme Systeme
Systeme

Präsentation Präsentation Präsentation Präsentation Präsentation


Standard-
software Applktn DB Applktn DB Applktn DB Applktn DB Applktn DB
Hersteller- Applikation Applikation Applikation Applikation Applikation
anpassung
Datenbank Datenbank Datenbank Datenbank Datenbank

Präsentation Präsentation Präsentation Präsentation Präsentation


Customizing Applktn DB Applktn DB Applktn DB Applktn DB Applktn DB
parametrisiert
tabellen-gesteuert Applikation Applikation Applikation Applikation Applikation
Datenbank Datenbank Datenbank Datenbank Datenbank

Präsentation Präsentation Präsentation Präsentation Präsentation


Komponenten-
montage Applktn DB Applktn DB Applktn DB Applktn DB Applktn DB
Frameworks Applikation Applikation Applikation Applikation Applikation
Business Objects
Datenbank Datenbank Datenbank Datenbank Datenbank

Präsentation Präsentation Präsentation Präsentation Präsentation


individual Applktn DB Applktn DB Applktn DB Applktn DB Applktn DB
Programmierg
2GL,3GL,4GL Applikation Applikation Applikation Applikation Applikation
Datenbank Datenbank Datenbank Datenbank Datenbank

Integrierende Systeme: Workflowsystem, Industrieprozess

Abbildung 4.17: Matrix der Software-Technologietypen


220 Kapitel 4 • Welche Softwarekomponenten sind für ein DWH einzusetzen?

Für die Entscheidung des Fertigungstyps ist die Ebene und Position des Benut-
zers von Bedeutung. Je höher die Ebene des Benutzers in der Hierarchie des
Unternehmens, desto mehr Selbsterklärung der Software ist erforderlich und
umso einfacher muss die Nutzerführung sein. Dies leistet Standardsoftware mit
festprogrammierten Dialogen besser als parametrisierbare Software und Indivi-
dualsoftware, welche der Benutzer erst im Laufe langer, intensiver Nutzung zu
beherrschen lernt.
Für die Entscheidung über die Fertigungstypen ist auch die Wettbewerbsrele-
vanz maßgebend. Systeme, die einen Wettbewerbsvorsprung erzielen sollen,
können nicht von der Stange gekauft werden.
Wenn die Komponenten und das Architekturprinzip bzw. der Technologietyp
feststehen, kann man den Markt auf die Angebote zu den benötigten Kompo-
nenten betrachten und mittels ausführlicher Funktionenlisten die Angebote
beurteilen. Für die konkrete Produktauswahl muss eine Evaluationsstudie
erstellt werden, die auf die funktionalen Unterschiede der Produkte eingeht.
Die Gestaltungsfrage der Evaluationsstudie kann zwar erst nach Beantwortung
der Frage der Funktionalität und nach Beantwortung der Frage nach der
Methodik behandelt werden, man kann aber jetzt schon feststellen, dass keines
der Angebote einzelner Hersteller die Bedarfe vollständig abdeckt. Man wird
deshalb die Frage nach einer Kombination der Produkte mehrerer Hersteller
stellen.
Komponentenliste mit Technologietypisierung
Das Ergebnis der Technologietypenbestimmung ist in einer Liste festzuhalten.
Da zu jeder Komponente die Technologietypen-Entscheidung getroffen werden
muss, ist der Ausgangspunkt dieser Liste die Komponentenliste. Die folgende
Liste »Komponentenliste mit Technologietypisierung« ist ein Beispiel für die
Einordnung der Komponenten als Softwaretyp. Für die Nachvollziehbarkeit
durch Dritte sollte die Entscheidungsbegründung festgehalten werden. Viele
Unternehmen akzeptieren die Entscheidung »Standardsoftware« sehr schnell,
wollen aber auf Grund der hohen Kosten und des hohen Erfolgsrisikos eine
Eigenentwicklung gut begründet haben.
Der nächste Problemlösungsschritt des DWH-Gestalters besteht in der Aufzäh-
lung der Funktionen der einzelnen Komponenten des zukünftigen DWH. Die
Funktionen sind zum Teil allgemeiner Natur, also auch für Programme, die
keine DWH-Komponenten sind, von Bedeutung, wie zum Beispiel grafische
Oberflächen und zum Teil spezielle Funktionen des DWH. Beide Funktions-
gruppen müssen definiert werden. Im folgenden Kapitel werden die software-
technischen Funktionen des Data Warehouse betrachtet.
Kapitel 4 • Welche Softwarekomponenten sind für ein DWH einzusetzen? 221

DWH- Fertigungstyp Fachtyp Verteilungstyp Begründung


Komponente
S P E K I I T K O G P T R A P C M

Legende:
S – Standard, P – Parametrisiert, E – Enduser -Tools, K – Komponenten, I – Individualentwicklung
T – Technisches System, K – Kaufmännisches System, P – Prozesssteuerungssystem, G – Geographisches System, I – Integratiossystem,
T – Terminal, R – Remote Präsentation, A – Remote Access, P – Peer to Peer, C – Client/Server, M – Mobil

Tabelle 4.7: Muster DWH Komponentenliste mit Technologietypisierung

4.4 Fortsetzungsbeispiel InDaWa


Einleitung
Die Managementebenen wurden schon ausgemacht. Die Frage ist jetzt, welche
Technologietypen (Fertigungstyp, Fachtyp, Verteilungstyp) für die aufgeworfe-
nen Fragestellungen der Instandhaltung am Besten geeignet sind und welche
Komponenten das InDaWa umfassen soll.

Beispiel
Der Fachtyp ist nicht schwer zu bestimmen, ein Instandhaltungssystem hat
sowohl
✔ einen kaufmännischen Teil im Verwaltungssystem der Arbeitsaufträge und
Kostenabrechnung der Instandhaltungsarbeiten
✔ einen technischen Teil mit der Stücklistenzerlegung aller Bauteile, der
topologischen Anlagenteilstruktur, den Konstruktionszeichnungen (CAD)
der Anlagenteile
✔ einen Prozessteil mit dem zeitlichen Produktionsverlauf des Kraftwerks
Da es sich um die Zusammenführung von Daten aus verschiedenen Kraftwer-
ken handelt, muss auf verschiedene Datenbanken und verschieden Systeme
zugegriffen werden können.
222 Kapitel 4 • Welche Softwarekomponenten sind für ein DWH einzusetzen?

Beispiel: Bestimmung der Technologietypen


Die gegenüber den ursprünglichen Verwaltungsaufgaben der Instandhaltung
neue Fragestellung an die Ereignisse, die zur Instandsetzung führen, fordern
eine Erweiterung der Instandhaltungsdatenbasis. Damit ist Individualent-
wicklung in den bestehenden Instandhaltungssystemen vonnöten.
Für die Schadenserfassung sieht man die Belastungen der Anlagen von der
Produktionsleistung verursacht. Man sieht keine aus der geographischen
Verteilung der Abnehmer resultierende Belastung und benötigt deshalb kein
Geographiesystem.
Die Kostenerfassung wurde in allen Kraftwerken über ein zurückliegendes
Großprojekt mit einer betriebswirtschaftlichen Standardsoftware vereinheit-
licht.
Die Ergebnisse der Auswertungen werden zu weiteren Betrachtungen,
Umordnungen von Spalten und Ergänzung um weitere schriftliche Informa-
tionen anregen. Freiheitsgrade dieser Art liefern Enduser-Tools wie z.B. ein
Kalkulationsprogramm oder EIS-Tools. Es ist nicht mit weitergehenden Fra-
gestellungen zu rechnen. Der Einsatz soll Mobilität gewährleisten.
Eine streng geführte Nutzerführung durch ein Workflow-Management
System ist nicht sinnvoll, da es sich nicht um häufig wiederkehrende Tätig-
keiten mit einem festen Ablauf handelt.
Damit ist das Technologietypen-Profil für das Instandhaltungsprojekt
InDaWa festgestellt. Das Ergebnis ist in der folgenden Liste zusammenge-
fasst.
✔ Individual-Erweiterung der technischen Basisdatenbanken der Kraft-
werke mit direktem Zugriff, keine Verarbeitung von CAD-Daten
✔ Zugriff auf Daten der Produktionsprozesse
✔ keine geographischen Systeme
✔ kein Standardsoftware-Einsatz für DWH
✔ kein Customizing der kaufmännischen Standardsoftware Kostenrech-
nung
✔ eventuell Makroprogramme und Addins für das Reporting mit Officetools
wie Kalkulationsprogramme, Businessgrafiken, Textbausteine
✔ keine Integrationskomponenten wie Workflow-Tool
Die Erkenntnisse sind entsprechend dem Diagramm »Softwaretechnologie-
typen« in der folgenden Grafik als Technologieprofil schraffiert hervorgeho-
ben.
Kapitel 4 • Welche Softwarekomponenten sind für ein DWH einzusetzen? 223

GIU
OLAP RDB
OLAP,Miner
MRDB

DWH i.e.S., EIS OLAP DSS


Technische
Technische Office Kaufmännische Geografische
Prozess
Systeme Systeme Systeme Systeme
Systeme

Präsentation Präsentation Präsentation GUI Präsentation


Standard-
software Applktn DB Applktn DB Applktn DB Applktn DB Applktn DB
Hersteller- Applikation Applikation Applikation Applikation Applikation
anpassung
Datenbank Datenbank Datenbank Datenbank Datenbank

Präsentation Präsentation GUI Präsentation Präsentation


Customizing Applktn DB Applktn DB Makro RDB Applktn DB Applktn DB
parametrisiert
tabellen-gesteuert Applikation Applikation Applikation Applikation Applikation
Datenbank Datenbank Datenbank Datenbank Datenbank

Präsentation Präsentation Präsentation Präsentation Präsentation


Komponenten-
montage Applktn DB Applktn DB Applktn DB Applktn DB Applktn DB
Frameworks Applikation Applikation Applikation Applikation Applikation
Business Objects
Datenbank Datenbank Datenbank Datenbank Datenbank

GUI CUA Präsentation Präsentation Präsentation


individual 4GL DB Applktn DB Applktn DB Applktn DB Applktn DB
Programmierg
2GL,3GL,4GL 4GL Echtzeit Applikation Applikation Applikation
RDB, Filesystem Datenbank Datenbank Datenbank

Integrierende Systeme: Workflowsystem, Industrieprozess

Abbildung 4.18: Beispiel Softwaretechnologietypen - Profil für InDaWa

Nach der Abgrenzung der Technologien wird nun die Komponentensicht mit
funktionaler Sicht kombiniert, um zu einem Komponentenbild zu kommen.
Das mit Hilfe des DWH-Referenzmodells abgeleitete InDaWa-Architekturdia-
gramm ist als Lösung im Anhang dargestellt.

Beispiel: Bestimmung der DWH-Komponenten


Um eine Vergleichbarkeit aller Analysen zu garantieren, müssen Schadens-
meldungen für alle Zugriffe dieselbe Struktur haben. Damit ist eine fest zu
definierende Abfrage mit vordefinierten Reports einzurichten. Da die Basis-
systeme verschieden sind, gibt es auch kein Standard-Auswertungssystem.
Statt die Auswertungen über Zugriffe auf die einzelnen Systeme zu errei-
chen, wird ein DWH-Server mit replizierter Haltung der für die Auswertung
wesentlichen Instandhaltungs- und Prozessdaten und den Kostendaten aus
den kaufmännischen Standardsystemen eingerichtet.
Für die Einflüsse auf die Schadensereignisse werden mindestens folgende
Faktoren eingeschätzt:
224 Kapitel 4 • Welche Softwarekomponenten sind für ein DWH einzusetzen?

✔ Lokation, Belastung, Inspektionsarten, Anlagenteil, Instandhaltungskos-


ten
Damit ist eine Darstellung und Verwaltung im multidimensionalen Würfel
eines OLAP-Tools sinnvoll.
Es sollen Automatismen zur Interpretation von Daten eingesetzt werden, um
Regeln zu Ausfallerscheinungen abzuleiten. Hier ist speziell die Gruppenbil-
dung von Daten (Clustering), die Ableitung von Beziehungen der Daten-
gruppen (Assoziationen) gewünscht.
Der Einsatz neuronaler Netze wird als wenig zielführend abgelehnt, statt des-
sen soll ein konventioneller Data Miner für die Hypothesengenerierung ein-
gesetzt werden.
Archivierung ist nicht sinnvoll, die Daten müssen immer in ihrer Gesamtheit
über die vollständigen Kraftwerke-Historien ausgewertet werden.
Damit ist die Komponentenarchitektur für das Data Warehouse InDaWa fest-
gestellt. Das Ergebnis ist in der folgenden Liste zusammengefasst.
✔ Replizierte Ausschnitte der Basisdatenbanken (Oracle, Informix, Adabas,
IDMS) der Kraftwerke auf einem DWH-Server
✔ Prozessdatentransformator
✔ Replizierte Ausschnitte der Standardsoftware-Module der Kostenrech-
nung der Kraftwerke
✔ Derzeit sind keine Internetinformationen erforderlich
✔ Enduser-Tools mit Kalkulationsprogramm, Statistikprogramm
✔ EIS-Tools
✔ Destktop-OLAP-Würfel mit Desktop-Datenbank
Die Erkenntnisse sind mittels des bereits vorgestellten Referenzmodells in
der folgenden Abbildung in eine Komponentenarchitektur für das Instand-
haltungs Data Warehouse InDaWa umgesetzt worden.

Gestaltungsentscheidungen
Zusammengefasst ergeben sich damit die folgenden Gestaltungsentscheidun-
gen für das Beispiel Data Warehouse eines Kraftwerkparkes.
Kapitel 4 • Welche Softwarekomponenten sind für ein DWH einzusetzen? 225

Gestaltungsaspekt Entscheidung Begründung

ORIENTIERUNG

ARCHITEKTUR
Betriebswirtschaftskomponenten
...
Softwarekomponenten

Managementebene operative Managementebene Organisation der Erfassung von Schäden


taktische Managementebene Optimierung Lagerhaltung, Kostenreduktion
Softwaretyp Individualkomponente Erweiterung der Basisdaten
Office System zur freien Kalkulation
für ad-hoc-Abfragen
für Standardanalysen
DWH-Komponenten OLAP-Würfel mit Client-Tools multidimensionale Problematik
EIS-Tools für spontane Dialoggestaltung
Prozessdatenwandler analog/digital-Wandlung
Middleware für ADABAS, Zugriffe auf vorhandene Datenbestände
Informix, Oracle, IDMS
Office-Tools Ergebnisberichte, Dokumentenmontage
Statistik-Tools individuelle kleine Auswertungen

Hardwarekomponenten
...
Organisationskomponenten
...

VORGEHENSMODELL

Tabelle 4.8: Entscheidungschart InDaWa, Softwarekomponenten

4.5 Übungen
Übung (mit Lösung) 4.1: Beurteilungskriterien OLAP-Produkte
Entwerfen Sie eine systematische Liste von Funktionen mit Beurteilungskrite-
rien zur Produkt-Präsentation eines Herstellers für OLAP-Produkte.

Modul Fragestellung Auswertungskriterien

Übung 4.2: Funktionsbedeutung


Geben Sie zu jeder Funktion der vorangestellten Übung die Konsequenzen
Ihres Fehlens an, nach den Kriterien:
✔ Verzichtbar: nur ergonomisch von Bedeutung
✔ Ersetzbar: mit anderen Funktionen kann man sich mit vertretbarem Auf-
wand behelfen
226 Kapitel 4 • Welche Softwarekomponenten sind für ein DWH einzusetzen?

✔ Unverzichtbar: wichtige Fragen können nicht erledigt werden


Übung 4.3: DWH-Referenzmodelle
Entwerfen Sie anhand des DWH-Referenzmodelles ein in sich abgeschlossenes,
funktionsfähiges Teilsystem mit zwei Datenquellen.
Übung 4.4: Technologietyp
Was bedeuten die Begriffe Fertigungstyp, Anwendungstyp, Verteilungstyp,
Fachtyp? Geben Sie zu jedem Begriff Beispiele.
Übung 4.5: Spezielle Funktionen
Schildern Sie die Bedeutung und die wesentlichen Charakteristika der folgen-
den Funktionen:
✔ ABC-Analyse
✔ Portfoliomatrix
✔ Multiwürfel
✔ Entscheidungsbaum
Übung (mit Lösung) 4.6: DWH-Architektur InDaWa
Entwerfen Sie zu den Ausführungen im Beispiel InDaWa im vorangegangenen
Unterkapitel mit Hilfe des DWH-Referenzmodells die InDaWa DWH-Architektur.
Übung (mit Lösung) 4.7: Entscheidungsgang Gestaltung Datenbankmanage-
mentsystem
Spielen Sie mit Hilfe der Grafik »Entscheidungsgang der DWH-Gestaltung« die
Gestaltungsentscheidungen für die Komponenten eines Datenbankmanage-
mentsystems bis zur Ebene Ihnen bekannter Produkte durch.
Übung 4.8: Entscheidungsdurchlauf IT-Kategorie Software
Versuchen Sie mit Hilfe des Entscheidungsfeldes Softwarearchitektur einen
Entscheidungsdurchlauf mit folgenden Einschränkungen zu entwerfen:
✔ Als Softwarekomponente kommt nur ein Standardsoftware-Hersteller in
Frage.
✔ Die Standardsoftware enthält eine Basisdatenbank, deren Hersteller auch
für das DWH ausgewählt werden soll.

4.6 Zusammenfassung der Entscheidungsgänge


In der folgenden Grafik ist der Entscheidungslauf der softwaretechnischen
Gestaltungskomponenten zusammengefasst. Der Entscheidungslauf zur Soft-
warearchitektur hat vier Entscheidungsgänge: die Festlegung des Anwen-
dungstyps, die Bestimmung des Technologietyps, die Festlegung des Ferti-
gungstyps und die Festlegung des Fachtyps.
Kapitel 4 • Welche Softwarekomponenten sind für ein DWH einzusetzen? 227

Erster Entscheidungsgang
Zunächst wird im ersten Schritt des ersten Entscheidungsganges auf der
Ebene des Systemtyps der Anwendungstyp abgegrenzt. Das ist mit der Wahl,
ein DWH zu konstruieren, bereits geschehen. Ist der Anwendungstyp definiert,
kann auf der Ebene der Komponenten weiter detailliert werden. Zum Beispiel
könnte die zum Systemtyp DWH gehörige Komponente »Data Mining Tools«
interessant sein.
Im zweiten Schritt des ersten Entscheidungsganges sind die Systemkompo-
nenten zu definieren, die durch die unterschiedlichen Aufgaben der Anwende-
rebene bedingt sind. So ist z.B. für die Aufgabe »Finden von Zusammenhän-
gen« die Komponente Data Mining nötig.
Je nach gewählter Komponente unterscheiden sich die zu Modulen oder Funk-
tionen gruppierten Funktionen. Diese werden im dritten Schritt des ersten
Entscheidungsganges gefunden. Zuerst sind die allgemeinen über das gesamte
DWH homogenen Funktionen zu definieren. Danach sind die für die Kompo-
nente typischen Funktionen festzulegen. Für die Komponente Data Mining ist
das z.B. die Funktionalität der Funktionengruppe zur Hypothesenbildung.
Der vierte Schritt des ersten Entscheidungsganges ist erforderlich, um nach
der Bestimmung der Module die Funktionen festzustellen.
Der Durchlauf durch die Gestaltungsentscheidungen des ersten Entschei-
dungsganges wird am Beispiel des Entscheidungswegs Technologietyp in der
folgenden Darstellung deutlich:

IT-Kategorie Erster Entscheidungsgang


Softwaretechnologie
1. Schritt

Systemtyp
Anwendungstyp:
DWH
Fertigungstyp:
Standardsoftware 2. Schritt
Systemkompo-
nente
DWH-Komponenten
Data Mining 3. Schritt

Systemmodul
Funktionengruppen
der DWH-Kompo-
nenten 4. Schritt

Funktionen
Funktionen

Abbildung 4.19: Erster Entscheidungsgang


228 Kapitel 4 • Welche Softwarekomponenten sind für ein DWH einzusetzen?

Zweiter Entscheidungsgang
Nach der Festlegung der Komponentenstruktur und der Ermittlung ihrer
Funktionen im Einzelnen wird im zweiten Entscheidungsgang eine Entschei-
dung über den Fertigungstyp getroffen. Das heißt, es wird festgestellt, ob das
System mit den gewünschten Komponenten als Produkt beschafft werden
kann, ob eine Eigenentwicklung erforderlich ist oder ob die gewünschte Funk-
tionalität dem Nutzer als Office-Makro zur Selbsterstellung zugemutet werden
kann.
Dritter Entscheidungsgang
Im dritten Entscheidungsgang wird der Fachtyp festgelegt. Die verschiedenen
Fachtypen sind mit unterschiedlichen Architekturen und Technologien reali-
siert und unterschiedlich in Komponenten zerlegt. Für die verschiedenen
Komponenten wurden unterschiedliche Technologien entwickelt. Eine geogra-
hische Datenbank eines geographischen Systems ist z.B. anders organisiert als
die relationale Datenbank eines kaufmännischen Systems oder eine technische
Datenbank einer technischen Applikation. Mit diesen verschiedenen Technolo-
gien muss ein DWH kooperieren können.
Vierter Entscheidungsgang
Im vierten Entscheidungsgang wird der Verteilungstyp festgelegt. Der Vertei-
lungstyp gibt die Verteilung der einzelnen Komponenten über die Hardwarear-
chitektur an. Dabei können alle Komponenten auf einem Rechner installiert
sein. Es können auch einzelne Komponenten in mehreren Schichten zerlegt
und auf verschiedenen Rechnern platziert sein. Dies ist zum Beispiel für mobile
Lösungen erforderlich.
Die Entscheidungsgänge zwei bis vier wurden im Text als »Technologietypen«-
Entscheidung parallel abgehandelt.
Die verschiedenen Systemtypen-Elemente sind unterschiedlich tief zu detaillie-
ren. Dies liegt im Ermessen des DWH-Spezialisten. Diese unterschiedlichen
Detaillierungsgrade bringt die Grafik »Entscheidungsgang Data Warehouse
Gestaltung« durch die unterschiedliche Aufteilung der Boxen zum Ausdruck.
Die Grafik gibt nicht in allen Detaillierungsstufen eine vollständige Klassifika-
tion, sondern sie beschränkt sich der Übersichtlichkeit und der Erkenntnis des
Zerlegungsprinzips zuliebe auf die wichtigsten Unterteilungen (siehe Abbil-
dung 4.20).
Kapitel 4 • Welche Softwarekomponenten sind für ein DWH einzusetzen? 229


    

  



     
  %" " 

  

     



   

# 
 
 
$
+ #  $

!     %


%"
 " &!
'//0+  ' 
* 1 # 
')


 &
#

 .*  

 

, )   
)    
&- "
  "$
1  $$ 
  

  
%


 
!
(
 
 



 !
 
  
 

  
 




 (  2&1
 (  3&1 #  &-4 6 

   %  

4  #




 
 

 
!    


4+  ! "
%-4
&
-  
  
--   )

  *
  
$  
"+
 
    , 
- 
  
 


$
.! (

!  )
 6 4
 5( 
)
    
     
   


!
 5

!  
(


"  
 ,$ % 

( $" 
  

Abbildung 4.20: Entscheidungsgang Data Warehouse Architektur: Softwarekomponenten


231

KAPITEL 5
5 Welche Hardwarekomponenten und
Netzinfrastrukturen sind für den Betrieb eines
DWH erforderlich?
Einleitung
Das DWH bezieht Daten von vorhandenen Systemen und gibt diese weiter an
andere Systeme. Ein DWH ist aus Softwaresicht ein Softwaresystem, das mit
bereits vorhandenen, auf verschiedenen Rechnern liegenden Softwaresystemen
kooperiert und auf ihren Leistungen aufbaut. Ein DWH umfasst selbst eine
Reihe von kooperierenden Programmen, d.h. ein Softwaresystem. Programme
benötigen mindestens einen oder mehrere Computer, um ablaufen oder betrie-
ben werden zu können. Die Softwaresysteme, mit denen das DWH kooperiert,
laufen überwiegend auf anderen Computern als das DWH selbst. Zwischen die-
sen Systemen findet Kommunikation statt. Um kommunizieren zu können,
müssen diese Systeme verbunden sein. DWH-Systeme operieren auf Hardware-
systemen.
Das bedeutet, dass zur Gestaltung eines DWH verschiedene Hardwareaspekte in
die Entscheidungen einzubeziehen sind. Diese Hardwareaspekte betreffen den
oder die Computer, auf denen das DWH-System ablaufen bzw. ausgeführt wer-
den soll und auf denen Basisdaten verwaltet werden. Diese Computer sind die
Arbeitsplatzrechner der Benutzer und die Systeme mit den Basisdaten, die Ser-
ver. Mit Typ und Bauart des Rechners ist auch das Betriebssystem festzulegen.
Da verschiedene Rechner miteinander kooperieren müssen, muss auch das
Medium zwischen den Rechnern, die Verbindung zwischen diesen Rechnern, in
die Betrachtung mit einbezogen werden. Dieses Medium ist das Lokale Netz-
werk oder in englischer Sprache das Local Area Network, kurz LAN. Wenn man
bedenkt, dass in großen Unternehmen die Basisdaten über Kontinente verteilt
sind, muss sogar die Kommunikationsverbindung zwischen diesen Ländern,
das Wide Area Network, kurz WAN, einbezogen werden.
Durch die enorme Leistungsfähigkeit der LAN/WAN-Technologien entstehen
viele Möglichkeiten, die Rechner weltweit zu verteilen und die Komponen-
tentechnologie der Software bietet weitere Möglichkeiten, die Softwareteile auf
diesen Rechnern zu verteilen. Das Allokationsproblem ist zu lösen. Im Zusam-
menhang mit dem Allokationsproblem ist die Client/Server-Architektur mit
Technologien zur Kooperation verteilter Softwarekomponenten von Bedeu-
tung.
Hardwarekomponenten und Netzinfrastrukturen
232 Kapitel 5 • Hardwarekomponenten und Netzinfrastrukturen

Der entsprechende Kapitelaufbau ist deshalb wie in folgender Grafik dargestellt.

 


 

 

 
 


 
   
 !"

Abbildung 5.1: Übersicht Kapitel Hardwarearchitekturen

Lernziel
Der DWH-Spezialist gestaltet die Hardwareausstattung des DWH nicht selbst,
das machen der Netzwerkspezialist und der Rechnerspezialist. Die Lernziele des
Kapitels umspannen deshalb das Wissen, das erforderlich ist, um die Hardware-
anforderungen für den Hardwarespezialisten zu formulieren. Der DWH-Spezia-
list muss dazu die Grundbegriffe von Rechnernetzen beherrschen.

Lernziele:
 Definition der Anforderungen an das für ein DWH erforderliche WAN
 Komponenten
Vorgabe der Anforderungen an die für ein DWH erforderlichen LAN-

 Festlegung der DWH-Serveranforderungen


 Definition
tion
der für ein DWH erforderlichen Arbeitsplatzrechnerkonfigura-

 Aufzählung der Peripheriekomponenten und ihrer Schnittstellen


 Erkennen der Bedeutung der Auswahl des Betriebssystems und des
Zusammenhanges der Auswahl mit dem Rechnertyp
 Beurteilung der Verteilung von Software auf Rechnern
Kapitel 5 • Hardwarekomponenten und Netzinfrastrukturen 233

5.1 Netzkomponenten für den Betrieb des DWH


Prinzip des Informationsweges im DWH-Netz
Die folgende Prinzipskizze zeigt die Besonderheit des Rechnernetzes des DWH
im Vergleich zu einem Datenbankapplikations-Netz.

 
    
   
   

 
 
 


 
 


Abbildung 5.2: Prinzipskizze Informationsweg im DWH-Netz

Der Vorgang der DWH-Recherche startet beim Anwender, der Informationen


von einem DWH-Server geliefert bekommen möchte. Der DWH-Anwender
schickt von seinem PC, dem DWH-Client, aus eine Anfrage über sein Lokales
Netz, kurz LAN, des Gebäudes, dem DWH-Client-LAN, zum Server, der dieses
lokale Netz verwaltet, bedient und steuert, dem LAN-Server. Dieser Server lei-
tet die Anfrage über weitere Lokale Netze des Unternehmens, die zum Beispiel
in anderen Stockwerken oder anderen Gebäuden des Betriebsgeländes liegen
können, in das öffentliche oder private globale Netz, das Wide Area Network,
kurz WAN. Über das WAN wird die Anfrage entsprechend der vom Client-LAN-
Server mitgegebenen Standort-Adresse in das LAN geleitet, das den DWH-Ser-
ver umfasst, zum DWH-Server-LAN. Der DWH-Server wird mittels seines
Lokalen Netzes (LAN DWH-Server) über das Lokale Netz des Datenbankservers
vom Datenbankserver mit Basisinformationen versorgt. In umgekehrter Rei-
henfolge werden die Daten der gewünschten Anfrage über die genannten LANs
und das WAN an den Client-PC geliefert. In Datenbankapplikationsnetzen ist
kein DWH-Server als konsolidierende Komponente vorhanden, und die Daten-
mengen fließen in zwei Richtungen. In einer Richtung findet die Eingabe,
Löschung, Änderung und das Kopieren vorhandener Daten vom Datenbank-
Client-Rechner statt. In der Gegenrichtung wird der Datentransfer gemäß den
Anwenderanfragen analog geliefert.
Notwendigerweise müssen Unternehmen als offene Systeme mit anderen
Institutionen, Unternehmen und technischen Anlagen kommunizieren. Wenn
die Kommunikation DV-gestützt stattfinden soll, sind hierfür technische Ver-
bindungen, sogenannte Kommunikationsnetze in die Unternehmensumwelt
erforderlich. In der Regel sind bereits externe Netze vorhanden, so dass der
Schwerpunkt des Entscheidungsspielraumes in Anbindungsfragen liegt. Anders
ist die Entscheidungslage für interne Netze. Hier ist ein komplexes Gestal-
234 Kapitel 5 • Hardwarekomponenten und Netzinfrastrukturen

tungsproblem von Konzeption und Beschaffung zu lösen. Dies ist aber nicht die
Aufgabe der DWH-Spezialisten, sondern der Netzwerkspezialisten.

5.1.1 Wide Area Network


Problemstellung und Motivation
Das Wide Area Network, kurz WAN genannt, verbindet voneinander entfernte
Standorte über Leitungen. Über WAN-Strecken können Firmenstandorte unter-
schiedlicher Städte, unterschiedlicher Länder oder sogar verschiedener Konti-
nente miteinander verbunden werden. Der Begriff »Strecke« ist dabei schon zu
eng gewählt, das WAN ist ein Netz mit vielen alternativen Strecken. Dem
Anwender erscheint das WAN im Augenblick einer Verbindung immer als Stre-
cke. Das liegt daran, dass für seine Anfrage vom Anfangspunkt, dem Eintritts-
punkt in das Netz, eine der augenblicklichen Lastsituation im WAN-Netz ent-
sprechende optimale Strecke bis zum Endpunkt ausgewählt wird. Die Auswahl
dieser Strecke kann auch kostendynamisch erfolgen. Das bedeutet, dass immer
dann, wenn ein Anwender anfragt, eine Software den im Augenblick preiswer-
testen Weg durch das Netz sucht. Die Verbindung kann aber auch statisch, also
durch eine feste Verbindung, vorbestimmt sein. Eine feste Verbindung kann
z.B. eine vorher festgelegte Funkstrecke oder ein bestimmtes Kabel sein.

Definition: Wide Area Network


Ein Wide Area Network, kurz WAN, ist das System der überregionalen Kom-
munikationsverbindungen von EDV-Systemen, einschließlich ihrer Verbin-
dungskomponenten, einschließlich der Softwarefunktionen der Verbindung.
Das Wide Area Network wird von einem Provider betrieben und vermietet.
Die Leitungsnutzung wird um Provider-Dienstleistungen, Mehrwertdienste,
ergänzt.

Aus der Sicht der Betriebsart gibt es demnach zwei wesentliche Leitungstypen:
✔ Direktverbindung oder Standleitung mit dauerhaft zur Verfügung stehen-
der Verbindung (Festverbindung) in einer verabredeten Kapazität und Qua-
lität
✔ Frame Relay, ursprünglich virtuelle Festverbindungen von Lokalen Netzen,
neuerdings auch mit Wählverbindung in einer verabredeten Kapazität
Für die Übertragung der Informationen stehen unterschiedliche Medien zur
Verfügung. Das können z.B. folgende von einem die erforderliche Infrastruktur
und die Wegerechte besitzenden Vermieter zur Verfügung gestellten WAN-
Leitungen sein
✔ Glasfaserkabel
✔ Kupferkabel
Kapitel 5 • Hardwarekomponenten und Netzinfrastrukturen 235

✔ Funkwellen, z.B. Richtfunkwellen, Kurzwellenfunk


✔ Lichtstrahlen, z.B. Laserstrahl
Eine Verbindung wird mittels Software und Steuergeräten unterhalten. Das
oben genannte Suchen des preiswertesten Weges, das sogenannte Least-Cost-
Routing oder das Verpacken von Informationen zu Datenpaketen mit bestimm-
ten Übertragungseigenschaften wird von einer speziellen Software durchge-
führt. Die Software leistet auch die Steuerung der Umsetzung der Signale bei
einem Medienwechsel, z.B. von einem Lichtimpuls in eine Spannungsände-
rung eines elektrischen Stromes. Die Software wird in sogenannten aktiven
Netzkomponenten, Medienkonvertern und in Rechnern ausgeführt. Aus logi-
scher Sicht können diese Verbindungen sein
✔ ISDN
✔ Satellitenfunknetz
✔ GSM
✔ Telefonfestnetz
✔ Fernsehkabel-Netz
✔ ATM
Vernetzungsstrukturen von EDV-Komponenten sind in unterschiedlicher Aus-
prägung, mit unterschiedlichem Abdeckungsgrad und mit unterschiedlichsten
Technologien weltweit realisiert. WANs können im Eigentum von privaten Fir-
men, von staatseigenen und auch von privatisierten Telekommunikationsge-
sellschaften sein. Großunternehmen wie die großen Hardwarehersteller und
die staatlichen und privatisierten Telekommunikationsunternehmen sind in
der Lage, bezüglich ihrer DWH-Anforderungen länderübergreifende Leitungen
für Datenverkehr zu verlegen. Von Privatpersonen und kleinen Unternehmen
können diese vorhandenen Infrastrukturen gar nicht oder nur unwesentlich
beeinflusst werden. Für den DWH-Spezialisten ist daher die vorhandene WAN-
Situation zu erfassen, und seine weiteren Gestaltungsentscheidungen sind von
diesen Erkenntnissen ausgehend fortzusetzen.
Provider
Da ein DWH über Leitungen mit den verschiedenen Lokationen des Unterneh-
mens kommunizieren muss, sind solche Leitungen für die Nutzung bei den
Leitungseigentümern, sogenannten Providern, zu bestellen. Große Unterneh-
men besitzen mitunter eigene Leitungen, so dass zunächst eine interne Leitung
bestellt werden muss und zur internen Leitungsbestellung nur eine externe
Leitungs-Lückenschließung hinzubestellt werden muss.
Für die Arbeiten mit und im WAN bieten die Leitungs- und Netzbesitzer, also die
Provider, verschiedene Dienste und spezielle Funktionen neben der Leitungs-
nutzung an. Solche Dienste sind zum Beispiel zentrale Mailboxen, Rufumlei-
tungen, Konferenzschaltungen, Auskunftsdienste und Internetanbindung. Da
236 Kapitel 5 • Hardwarekomponenten und Netzinfrastrukturen

solche Dienste auf der Basis einer bestehende Infrastruktur angeboten werden,
wird von einer sogenannten Mehrwertleistung gesprochen. Provider bieten also
Mehrwertdienstleistungen und Leitungsnutzung an.
WAN-Komponenten
Ein WAN beginnt bei der Ankoppelung der LANs und der Haustelefonanlage
oder auch einer Hausvideoanlage an ein überregionales Leitungssystem wie
z.B. das Postnetz. Diese Ankoppelung des LAN an ein WAN wird über Geräte,
sogenannte Router hergestellt. Router gehören zu den sogenannten aktiven
Komponenten. Vom Router fließen die Informationen in die eigentliche Verbin-
dungsstrecke; diese besteht aus terrestrischen Kabeln, die zu Sendern und von
da über Funkstrecken zu Funkempfängern führen; von dort werden die Infor-
mationen wieder in terrestrische Kabel eingespeist. Die Router können selbst
beschafft und installiert werden, oder sie können vom Provider installiert und
mit der Leistungsnutzung mit vermietet werden.
Lasten und Kapazität
Die Leitungsmiete ist umso teurer, je größer die bestellte Leitungskapazität,
also der pro Zeit erforderliche Datendurchfluss der Leitung ist. Ziel ist deshalb,
die Leitungen zwischen den Standorten gerade so groß zu wählen, dass die Ant-
wortzeiten durch die Benutzerzugriffe für die Anwendungen der erforderlichen
Arbeitsergonomie entsprechen.
Die durch die Leitungen transportierten Datenmengen hängen von den Daten-
typen und den Dokumentenarten ab. Reine Zahlensammlungen benötigen
weniger Kapazität als Textdokumente, Textdokumente benötigen weniger als
Spreadsheets, diese wiederum weniger als Grafiken, Grafiken weniger als CAD-
Zeichnungen und diese weniger als Videosequenzen.
Zahlenliste < Textseite < Kalkulationssheet < Businessgrafik
< CAD-Zeichnung < Videosequenz
Die Leitungskapazität und die Datenübertragungsrate werden als Datendurch-
satz pro Zeiteinheit gemessen. Wobei der Datendurchsatz in der kleinsten
Dateneinheit »Bit« und die Zeiteinheit in Sekunden gemessen wird:
Leitungskapazität = Datendurchsatz/Zeit [Bit/Sekunden]
Die vermutete anfallende Last wird berechnet aus der durchschnittlichen paral-
lelen Zugriffsanzahl der Benutzer, der Benutzerzahl, der Größe der Dokumente
und der Anzahl der pro Zugriff zu transportierenden Dokumente. Als Annähe-
rungswert ist folgende Formel nützlich:
Leitungslast = durchschnittliche Zugriffsanzahl pro Benutzer in der Sekunde ·
Benutzerzahl · Gleichzeitigkeitsfaktor des Zugriffs · Dokumen-
tenanzahl pro Zugriff · durchschnittliche Dokumentengröße
[Bit/Sekunden]
Alternativ zur Einheit »Bit« wird oft auch die Einheit Byte = 8 Bit zur Angabe
von Zeichenmengen verwendet.
Kapitel 5 • Hardwarekomponenten und Netzinfrastrukturen 237

Die Maßeinheit [Bit/Sekunde] für die Datenübertragungsrate wird oft mit


Baud, dem Maß für die Schrittgeschwindigkeit, verwechselt, die eine Schritt-
einheit pro Sekunde darstellt. Baud = Bit/Sekunde gilt nur bei binärer Übertra-
gung, also wenn ein Übertragungsschritt ein Bit ist.
Die Leitungskapazitäten werden nicht in beliebigen Größen zur Miete zur Ver-
fügung gestellt, sondern in Abstufungen. Die zu bestellende Leitung ist also die
zur berechneten Leitungslast nächstgrößere angebotene Leitungskapazität. Die
angebotenen Stufen von Leitungskapazitäten sind z.B.:
2,4 kBit < 4,8 kBit < 9,6 kBit < 16 kBit < 64 kBit < 128 kBit < 256 kBit < 2 MBit
< 34 MBit < ...
Visualisierung
WANs können sehr komplex sein, so dass sich eine symbolisierte Darstellung
zur Übersicht empfiehlt. Zur Visualisierung des WAN bedient man sich eines
WAN-Diagrammes. Die Informationen, die ein solches WAN-Diagramm enthal-
ten muss, sind
✔ die Standorte
entweder symbolisch entsprechend ihrer topographischen Lage auf dem
Diagramm verteilt oder in einer geographischen Karte hervorgehoben
✔ die zwischen den Standorten bestehenden Verbindungen
✔ die Kapazität der Verbindungen
Das Diagramm kann noch ergänzt werden durch die Betriebsart der Leitung,
z.B. Standleitung, Frame Relay, und durch Kennzeichnung eigener Anlagen.
Eventuell ist auch eine Klassifizierung der Standorte z.B. in Produktionsstätte,
Hauptverwaltung, Büros sinnvoll. Mitunter kann auch ein Hinweis auf die phy-
sische Ausführung wie Funkstrecke, Richtfunkstrecke, Satellitenfunkstrecke,
Glasfaserkabel nützlich sein.

Beispiel
In der folgenden Abbildung ist ein Beispiel für ein WAN, das WAN der deut-
schen Fluggesellschaft Lufthansa, mit Kapazitätsangaben dargestellt. Man
sieht, dass die Lufthansa mehrere Standorte unterhält und diese in den deut-
schen Großstädten angesiedelt sind. Die Standorte beherbergen mehrere
Typen wie Büro, Hauptverwaltung, Flugstation, Buchungszentrum, die
innerhalb eines Standorts teilweise ebenfalls durch WAN-Strecken verbun-
den sind.
Bezüglich der Kapazitätsangaben im Diagramm bedeutet z.B. 2M eine Kapa-
zität von 2Megabit (2·10 6) Bit Informationen und 64 k eine Kapazität von
64· 1.000 Bit.
238 Kapitel 5 • Hardwarekomponenten und Netzinfrastrukturen

Die Standorte der Lufthansa AG sind durch weiße Kreise gekennzeichnet.


Einige Standorte sind über ein Frame Relay verbunden, wie z.B. die Verbin-
dung zwischen Leipzig und Nürnberg.



   




 
!"

 &
  #'
#' $#
#

)  #


 
 

$'  
"#
)
&


 



  

 
 


+ ,

   
#
 
! $ $ %
)  #
  #
 
$
!! 
!
  


#
   
+ 


-#

+


 

(&





 

  



#

*


#
&
 $ 

$ 

 
"
# 




 







 

  
 


Abbildung 5.3: Das WAN der deutschen Lufthansa AG

Gestaltungs- und Lösungsmöglichkeiten


Der Umfang des zu gestaltenden Gesamt-Netzes des DWH ist mit LAN, WAN
und Netzkomponenten nach Gerätetypen, Produkten, Dienstleistern, Topolo-
Kapitel 5 • Hardwarekomponenten und Netzinfrastrukturen 239

gien und Technologien umrissen. Es ist nicht die Aufgabe des DWH-Spezialis-
ten, ein Kommunikationsnetz zu entwerfen. Er muss wissen, dass die Kompo-
nenten des DWH über ein Kommunikationsnetz in Verbindung stehen und
Daten austauschen. Diese Kommunikationswege sind für die Performance, für
die Verfügbarkeit und überhaupt für die Erreichbarkeit von Datenquellen maß-
gebend. Eine Datenquelle, zu der keine Netzverbindung besteht, kann nicht
angefragt werden. Der DWH-Spezialist muss so viel von einem Kommunikati-
onsnetz verstehen, dass er mit dem Netzspezialisten besprechen kann, was
gebraucht wird.
Die Anforderungen, die der DWH-Spezialist dem Netzspezialisten übergeben
muss, sind Lastanforderungen, Lokationen der Benutzer und Lokationen der
Datenquellen. Hinzu kommt noch eine gewisse Bedeutung der Verfügbarkeit
aus der Sicht der Benutzer. Die lokale Verteilung der Benutzer ist meistens vor-
gegeben, da ein Unternehmen, das ein DWH betreiben will, sicherlich schon
andere Datenbankanwendungen betreibt, sonst hätte das DWH keine Rohdaten.
➢ Feststellung der Datenquellen nach Lokation, Rechnertyp, Betreiber der
Datenquellen
Es muss nicht an jedem Ort der Welt, an dem das Unternehmen tätig ist, der
gesamte Umfang der DWH-Daten zur Verfügung stehen. Für die einge-
schränkte Sicht auf das DWH hat man die Möglichkeit, Ausschnitte aus dem
Gesamtvolumen herauszugreifen und lokal zu verteilen. So genügt es zum Bei-
spiel einer amerikanischen Niederlassung, einen DWH-Ausschnitt der amerika-
nischen Daten lokal vorzuhalten. Damit ist die Verteilbarkeit eines DWH auf
verschiedene lokationsnahe Server angesprochen. Die Gestaltungsentschei-
dung des DWH-Spezialisten besteht damit in der Platzierung der DWH-Server
im komplexen Netz des Unternehmens und in den Verbindungen zur Daten
liefernden Außenwelt.
➢ Bestimmung der Anwender mit Hilfe der Systemverzeichnisse mit
Lokation, vorhandene Netze
➢ Berechnen der Datenflüsse
➢ Festlegen der Serverlokationen
➢ Information einholen zur Feststellung der Netzprovider durch Netzplaner
➢ Erstellung eines Netz-Schaubildes
Der Wandel der Anforderungen bringt eine weitere Gestaltungsaufgabe mit
sich: die Einschätzung der Zukunft bezüglich steigender Belastungen der
Netze. Dies kann durch umfangreichere Applikationen oder durch vergrößerte
Benutzerzahlen kommen. Der DWH-Spezialist muss also seine DWH-Anforde-
rungen so formulieren, dass die Netzplaner bei der Auswahl und Konfiguration
ihrer Komponenten Skalierungsmöglichkeiten berücksichtigen können.
240 Kapitel 5 • Hardwarekomponenten und Netzinfrastrukturen

➢ Skalierungsprognose erstellen nach User, Applikationen, Datenmengen,


Erschließung neuer Niederlassungen, Wachstum der vorhandenen Nieder-
lassungen, Entwicklung bzw. Beschaffung neuer zu integrierender Basis-
applikationen, Erschließung neuer externer Datenquellen

Problemlösung: Regeln und Hilfsmittel


Das Verfahren
Ob die LAN's der Niederlassungen über Satellitenfunk oder Erdkabel zu einem
WAN verknüpft sind, ist für den DWH-Spezialisten ohne Bedeutung. Diese Fra-
gen gehören nicht zu seinen Gestaltungsaufgaben. Der DWH-Spezialist sollte
nur die Netzkomponenten von Namen und Funktion her kennen, um sich mit
Anwendern und Netzplanern verständigen zu können. Diese werden die Vorga-
ben mittels ausgewählter Technologien und konkreter Produkte umsetzen.
Hierzu gehört:
✔ Feststellung der lokalen Verteilung der Nutzer und der dort zu installieren-
den Software
✔ Feststellung der Lokationen der erforderlichen externen Datenquellen und
der Betreiber
Die folgende Reihenfolge des Vorgehens (kursiv dargestellte Schritte sind vom
Netzspezialisten durchzuführen) hat sich bewährt.

Verfahren: Bestimmung der Anforderungen an die DWH-Netzarchitektur


❖ Feststellung der Datenquellen, später eintragen in das Referenzschema
DWH-Netz
Lokation
Rechnertyp
Betreiber der Datenquellen
❖ Bestimmung der Anwender
Lokation
vorhandene Netze
aus Systemverzeichnissen
❖ Erstellung Netzschema
Entwurf anschauliche Netzgrafik mit vereinbarter Symbolebibliothek
❖ Skalierungsprognose mittels Skalierungsschema erstellen nach User,
Applikationen, Datenmengen
Erschließung neuer Niederlassungen
Wachstum der vorhandenen Niederlassungen
Entwicklung bzw. Beschaffung neuer zu integrierender Basisapplikationen
Erschließung neuer externer Datenquellen
❖ Bemessung der Komponenten und Leitungen mit Hilfe der Datenfluss-
matrix
Kapitel 5 • Hardwarekomponenten und Netzinfrastrukturen 241

❖ Information einholen zur Feststellung der Netzprovider durch Netzplaner


❖ Bestimmung der Provider mittels Providercheckliste
Bestimmung der zu bestellenden Leitungskapazitäten
Bestimmung der WAN-Leitungsart (ISDN, ATM, Standleitung, Frame
Relay...)
Festlegung der Bezugsform der Router und Medienkonverter
Bestimmung der Mehrwertdienste

Die kursiven Schritte sind nicht vom DWH-Spezialisten, sondern vom Netz-
werkspezialisten auszuführen.
Netzschema
Das Ergebnis der Gestaltungstätigkeit sollte ein mit der Unterstützung der
Hardware- und Netzspezialisten gefertigtes Netzschema der vom DWH betrof-
fenen Komponenten sein. Die Unterstützung ist hierbei bezüglich Symbolik
und Nomenklatur und Werkzeuge zur Darstellung zu erwarten. Das Netzschau-
bild ist für die Schulung der DWH-Anwender äußerst nützlich. Das Verständnis
des Gesamtsystems erleichtert dem Anwender die Orientierung und die Kom-
munikation mit dem Servicepersonal.
Skalierungsschema
Kein DWH-Spezialist kann exakt voraussagen, wie groß der DWH-Server sein
muss, um den augenblicklichen Anforderungen an Kapazität und Performance
zu genügen. Erfahrungsgemäß steigt die Nachfrage kurz nach der Einfüh-
rungsphase mit der Akzeptanz der Pilotanwender und der Intensität des inter-
nen Marketing. Ist das DWH eine Weile in Betrieb, werden erst die Nützlichkeit
und die vielen Verwendungsmöglichkeiten erkannt, und die wachsende Anwen-
dergemeinde macht den Ausbau des Systems nötig. Zur Bemessung sind dem-
nach nur grobe Schätzungen möglich über
✔ augenblickliche Anwenderzahl
✔ Wachstumserkenntnisse zur Anwenderzahl aus der Vergangenheit bei
Einführung neuer Anwendungen
✔ augenblickliche Datennachfrage durch das Netz
✔ Wachstumserkenntnisse zur Datennachfrage aus der Vergangenheit bei
Einführung neuer Anwendungen
✔ Zuwachsraten des Datenverkehrs über das Netz aus den Geschäftsabsichten
des Unternehmens, z.B. neue Niederlassungen zu gründen, alte Niederlas-
sungen auszubauen
Diese sind jedoch sehr nützlich. Auf alle Fälle muss eine Skalierungsplanung
Netz mit Hilfe eines Skalierungsschemas erstellt werden.
242 Kapitel 5 • Hardwarekomponenten und Netzinfrastrukturen

Lokation Lokation
Applikation Benutzer Datenquelle Anwenderzahl Datenvolumen Zugriffsfrequenz

Applikation x 1
2
3
4
Applikation y 1
2
3
4
Applikation z 1
2
3
Applikation 1
2
3
Applikation 1
2
3
Applikation 1
2
3

Tabelle 5.1: Skalierungsprognose

Datenflussmatrix
Für die Erfassung der Leitungslasten ist die sogenannte Datenflussmatrix
nützlich. In der Datenflussmatrix werden die Quellen und Ziele des Datenflus-
ses, die Lokationen, mit den wesentlichen Datenarten, Mengen und speziellen
Qualitäten zu Sicherheit, Verfügbarkeit und Performance dargestellt.
Es muss darauf geachtet werden, dass die Anforderungen nicht notwendiger-
weise symmetrisch sind. D.h. der Datenfluss zwischen zwei Lokationen kann in
beiden Richtungen unterschiedliche Mengen und unterschiedliche Qualitäten
haben.

Quelle Lokation 1 Lokation 2 Lokation 3 Lokation 4

Senke
Lokation 1 nach 2
Datenmenge
Lokation 1 Sicherheit
Antwortzeit
Verfügbarkeit

Lokation 2 nach 1
Datenmenge
Lokation 2 Sicherheit
Antwortzeit
Verfügbarkeit

Lokation 3 nach 1
Datenmenge
Lokation 3
Sicherheit
Antwortzeit
Verfügbarkeit

Lokation 4 nach 1
Datenmenge
Lokation 4
Sicherheit
Antwortzeit
Verfügbarkeit

Tabelle 5.2: Muster: Datenflussmatrix


Kapitel 5 • Hardwarekomponenten und Netzinfrastrukturen 243

Providercheckliste
Der Netzspezialist wird entscheiden, ob die aktiven Komponenten zusammen
mit den Leitungen gemietet oder getrennt beschafft werden. Der Netzspezialist
wird auch die Provider-Auswahl auf einem Preis-Leistungsvergleich basierend
auswählen und die Leitungen bestellen. Der DWH-Spezialist hingegen ist für
die Terminanforderung, also die Angabe des Zeitpunkts der Leitungsverfügbar-
keit, verantwortlich.
Die Providerauswahl kann mit dem in Kapitel 9 »Produktevaluation« darge-
stellten Evaluationsverfahren durchgeführt werden. Das dort für Softwarekom-
ponenten dreistufig empfohlene Auswahlverfahren kann hier auf zwei Stufen
reduziert werden.
Für die Vertiefung des Themas »WAN« sei empfohlen:
 Tanenbaum, Computernetzwerke
 Badach, Unternehmensnetze
 Siegmund, Netze

5.1.2 Local Area Network


Problemstellung und Motivation
Das Local Area Network, kurz LAN genannt, verbindet innerhalb eines Stand-
orts verschiedene Teilnehmer über Leitungen miteinander. Bei sehr großen
Teilnehmerzahlen können diese gruppiert werden und innerhalb der Gruppen
einzelne LANs installiert werden. Die einzelnen Gruppen-LAN werden dann
wiederum über ein LAN miteinander verbunden.
Aus physischer Sicht können diese Leitungen z.B. Kabel, Funkstrecken und
Infrarotstrecken sein.

Definition
Ein Local Area Network, kurz LAN, ist die hauseigene oder lokal Gebäude
verbindende Kommunikationsverbindung samt ihrer Hardwaretechnologie,
Verbindungskomponenten einschließlich Softwarefunktionen.

Ein LAN ist aufgebaut aus einer Verkabelung bzw. einer Sendestrecke für elek-
tromagnetische Wellen oder auch Infrarot-Strahlung und Komponenten, die
einzelne LANs und das WAN miteinander verbinden. Auf die Komponenten wird
weiter unten eingegangen. Die Schnittstellen der Endgeräte wie z.B. Modems
für den Anschluss an die Telefonleitung, werden üblicherweise nicht mehr zum
LAN sondern zum Endgerät gezählt.
244 Kapitel 5 • Hardwarekomponenten und Netzinfrastrukturen

Ebenso wie bei WANs gibt es auch bei LANs unterschiedliche logische Verarbei-
tungen und daraus resultierende Verarbeitungstechnolgien bezüglich Software
und Hardware. Verschiedenen LAN-Arten aus logischer Sicht sind
✔ Ethernet
✔ Token Ring
✔ ISDN-Hausnetz
✔ GSM
✔ Telefonhausnetz
✔ Fernsehkabelnetz
✔ ATM
Die verschiedenen Übertragungsmedien oder Leitungsarten der LANs aus
physischer Sicht sind
✔ Funk wie Richtfunk, Satellitenfunk
✔ Infrarotstrahlen
✔ Glasfaserkabel
✔ Telefonkabel
✔ Fernsehkabel
✔ Ultraschall
✔ Lichtwellenleiter
Komponenten des LAN und Protokolle
Die Verbindung einzelner LANs und die Verbindung von LANs mit WANs wird
über spezielle Komponenten hergestellt. Mittels sogenannter LAN-Komponen-
ten werden verschiedene LANs miteinander verbunden oder große LANs in
kleinere LANs segmentiert. Um diese unterschiedlich beschaffenen LANs ver-
binden zu können, müssen diese Komponenten »Intelligenz« in Form von Pro-
zessoren und die darauf ausführbaren Programme besitzen.
Die Arbeitsweise der LAN-Komponenten kann man besser verstehen, wenn man
das Protokoll-Prinzip kennt. Im Laufe der letzten Jahrzehnte haben sich die
Hersteller bemüht, unter der Überschrift »Offene Systeme« ihre unterschiedli-
chen Produkte so auszustatten, dass sie zu komplexen Systemen verschiedener
Hersteller kombiniert werden können. Hierzu muss das eine System von sei-
nem Nachbarsystem so viel verstehen, dass es seine Daten aufnehmen, weiter-
verarbeiten und zurückzugeben kann. Das heißt, die Hersteller mussten Details
ihrer Datenverarbeitung und Konstruktionsprinzipien offenlegen, und es muss-
ten Vereinbarungen getroffen werden, die beim Bau der herstellereigenen Sys-
teme zukünftig einzuhalten sind. Diese Vereinbarungen sind in sogenannten
Standardisierungsspezifikationen festgelegt worden. Das Zusammenpassen der
Kapitel 5 • Hardwarekomponenten und Netzinfrastrukturen 245

unterschiedlichen Realisierungen der Protokollschichten der Hersteller zeigt


die Abbildung »Protokollschichten nach ISO-OSI«.

   '  )
  ( ' -#- ,
)* +
  
  
%  -

 
 


'
  

    !"#!$ 


,-
.    -
&  (

%, "!   '
28
6 : 
     $!#$ 
  


7

.
 ( & !0 1   

8
88

, !

!0 1
- % & 8
 9 -
  ! % 8 87 % &
 9 87 %
- 8
 !0
- -%
!0 % * )  )

./   ! %
./ 
-, 23 4 )5 3 )4 )6

Abbildung 5.4: Protokollschichten nach ISO-OSI

Das Durchlaufen der Information durch die verschiedenen Geräte und Kabel
erfordert mehrere Transformationen und Konvertierungen, entsprechend der
Datendarstellung und der physikalischen Zustände in diesen verschiedenen
Medien. Im Glasfaserkabel sind z.B. die Daten als Lichtimpulse dargestellt, im
Hauptspeicher eines Rechners als Transistorzustände, auf einer Richtfunkstre-
cke sind es elektromagnetische Wellen und im Kupferkabel Stromimpulse.
Aber auch in den Programmen und im Betriebssystem sind intern und vom
Benutzer nicht bemerkbar unterschiedliche Datendarstellungen vorhanden.
Auf einer 3,5-Zoll-Diskette sind die Daten in einer anderen Struktur als auf
einer CD abgelegt. Die unterschiedlichen Datenbanken organisieren ihre Daten
in verschiedenen Strukturen. Wenn man nun eine Information auf den Weg
durch diese Systeme schickt, muss man den Informationen diese Strukturin-
246 Kapitel 5 • Hardwarekomponenten und Netzinfrastrukturen

formationen der physikalischen Zustände mitgeben, damit das nachfolgende


System erkennt, wie diese Informationen zu lesen sind. Diese Begleitinformati-
onen heißen Protokolle. Da die verschiedenen Systeme
Verkabelung – Rechnerhardware – Betriebssystem – Anwendungsprogramm
aufeinander aufbauen, hat man in den ISO-Normungsgremien ein Schichten-
modell der Protokoll-Standardisierung erarbeitet: das ISO-OSI-Modell der Pro-
tokollschichten. Ein Informationspaket wird nun auf dem Weg in das Netz in
der Reihenfolge der Schichten mit Protokollstücken verpackt und beim Emp-
fänger des Informationspaketes in der umgekehrten Reihenfolge wieder ent-
packt. Trotz hoher Standardisierung gibt es noch verschiedene Realisierungen
von Protokollen zu den verschiedenen Schichten. Diese Schichtung der Proto-
kolle zeigt die folgende Abbildung.

 
    
  #
#
$ 
  
  $
   
%  
  
 %
& 
 

 
&
' 
  
  
  '
" 
 
 
 "
!  

  

  

 !
     !      "

Abbildung 5.5: Schichtenaufbau nach dem ISO-OSI-Modell

Das Verpacken und Entpacken der Daten entsprechend vorgegebener Proto-


kolle wird von den verschiedenen Netzkomponenten automatisch erledigt.
Solche Komponenten lassen sich je nach Aufgabe voneinander unterscheiden.
✔ Repeater sind für die Verbindung gleicher LANs. Sie übertragen auf der
untersten Ebene der OSI-Schichten, auf der Bitübertragungsschicht.
✔ Bridges übertragen auf den zwei untersten Ebenen der OSI-Schichten, auf
der Sicherungsschicht und auf der Bitübertragungsschicht. Sie verbinden
jeweils zwei LAN-Segmente.
✔ Hubs übertragen wie Bridges auch auf den zwei untersten Ebenen der OSI-
Schichten, auf der Sicherungs- und auf der Bitübertragungsschicht, erlauben
aber die Verbindung verschiedener und vieler LANs auf einheitlichem Kabel.
✔ Switches übertragen auf den zwei untersten Ebenen der OSI-Schichten, auf
der Sicherungs- und auf der Bitübertragungsschicht, zwischen mehr als
zwei LAN-Segmenten.
Kapitel 5 • Hardwarekomponenten und Netzinfrastrukturen 247

✔ Router übertragen auf den drei untersten Ebenen der OSI-Schichten, auf
der Vermittlungsschicht, der Sicherungsschicht und der Bitübertragungs-
schicht.
✔ Gateways übertragen auf den obersten Ebenen der OSI-Schichten, auf der
Applikationsebene, der Vermittlungs-, der Sicherungs- und auf der Bitüber-
tragungsschicht.
Die folgende Abbildung gibt einen Eindruck von verschiedenen Bauformen und
Größen von Routern.

Abbildung 5.6: Router

Neben den aktiven und passiven Netzkomponenten für das Packen und Entpa-
cken der Protokolle gibt es Komponenten für andere Aufgaben, wie physikali-
sches Verbinden verschiedener Medien, das Aufteilen einer Verbindung zwi-
schen verschiedenen Geräten oder das direkte Anbinden eines Gerätes an ein
Netz:
✔ Multiplexer sind für die Mehrfachnutzung von Leitungen durch verschie-
dene Geräte unterschiedlichen Typs, z.B. Video – PC, oder gleiche Geräte.
✔ Medienkonverter sind z.B. für die Anbindung von Lichtwellenleitern an
Kupferkabel.
✔ Modems sind für den Anschluss eines PCs oder Notebooks an ein Telefon-
netz.
Die folgende Grafik gibt ein Beispiel dafür, wie die Netzkomponenten in ein
Netz integriert sind. Dabei symbolisieren die Zylinder mit den vier Pfeilen Rou-
248 Kapitel 5 • Hardwarekomponenten und Netzinfrastrukturen

ter und die Kästen mit kreuzenden Linien symbolisieren Switches. Die folgende
Abbildung 5.7 stellt einen Switchpanel dar. Der Switchpanel ist ein zentrales
Element eines strukturierten Lan. Er besteht aus mehreren Switches und Ste-
ckerleisten uber die die LAN-Teilnehmer miteinander verbunden werden.

Abbildung 5.7: Switchpanel

LAN-Server
Je nach Auffassung betrachtet man manchmal auch die sogenannten LAN-Ser-
ver noch als Netzkomponenten. Die LAN-Server haben die Aufgabe, den Betrieb
des LANs zu steuern, ähnlich wie das Betriebssystem eines Arbeitsplatz-PCs das
Betreiben dieses PCs ermöglicht. Hierzu gehört zum Beispiel die Verwaltung
von gemeinsamen Dateien, die Verwaltung der Drucker, die für alle zugänglich
sein sollen, kurz alle Ressourcen, die eben allen LAN-Mitgliedern zur Verfü-
gung stehen sollen.
Ebenso darf man auch spezielle, vielen Benutzern zur Verfügung stehende End-
geräte wie LAN-Drucker und Plotter noch zum LAN zählen.
Der LAN-Begriff im erweiterten Sinne umfasst noch alle Endgeräte, also auch
die Arbeitsplatz-PCs. Eine deutliche Grenze wird hier erst zu den mobilen Gerä-
ten gezogen, die als nicht mehr zum LAN zugehörig zählen. Den Endgeräten
Kapitel 5 • Hardwarekomponenten und Netzinfrastrukturen 249

wird im Folgenden ein eigener Abschnitt unter dem Gesichtspunkt Rechnersys-


tem und Peripheriegeräte gewidmet.
Für den DWH-Manager wie auch für den Benutzer ist es oft transparenter, das
gesamte Netz in einem Diagramm zu erkennen, also nicht ein WAN-Schaubild
mit einzelnen LAN-Diagrammen geistig zusammenspielen zu müssen. Für die-
sen Zweck dient die Grafik der folgenden Abbildung »Beispiel DWH-Netzgra-
fik«. Da es dem DWH-Spezialisten wie auch dem Benutzer des DWH nicht auf
die LAN- und WAN-Komponenten ankommt, werden diese nicht in die Grafik
aufgenommen.


 


!$%
      
 " 

!
 

()* &



! !
 !  )%
$ 


#

 



$
$

    "##  "## 
 
 
 


 &'

  
 
!  !


  
%&

  


 

! !

Abbildung 5.8: Beispiel einer vereinfachten DWH-Netzgrafik ohne WAN-Komponenten


250 Kapitel 5 • Hardwarekomponenten und Netzinfrastrukturen

Gestaltungs- und Lösungsmöglichkeiten


Die LAN-Gestaltung gehört ebenfalls nicht mehr zu den Aufgaben des DWH-
Spezialisten. Auch hier kommt genau wie bei der Gestaltung des WAN das Wis-
sen des Netzspezialisten zum Zuge. Der DWH-Spezialist muss allerdings dem
Netzspezialist mitteilen, welche Datenbankserver für das DWH erreichbar sein
müssen, welche Benutzer auf diese Server zugreifen müssen und welche DWH-
Server beabsichtigt sind.
➢ Feststellung der Datenquellen der Lokation, nach Lokation, Rechnertyp,
LAN-Segment und Typ, Applikationen und Datenbanken der Datenquellen
➢ Bestimmung der Anwender im LAN nach Lokation, vorhandene Netze
Wenn der DWH-Spezialist eine schematische Zeichnung des Netzes anfertigen
kann, erleichtert dies die Kommunikation mit dem Netzspezialisten, der das
Schema überprüfen und korrigieren wird.
➢ Erstellung LAN-Schema
➢ Bestimmung der von den Nutzern des DWH gewünschten LAN-Dienste
Der Netzspezialist wird mit Hilfe der Anforderungen der Benutzer wie sie schon
zum WAN ermittelt wurden, d.h. besonders den Datenmengen und der Verbin-
dungsqualität, die Auslegung des LANs bestimmen. Er wird auch bestimmen,
ob ein eigenes DWH-LAN gegen die anderen LANs abzugrenzen ist.

Problemlösung: Regeln und Hilfsmittel


Das Verfahren
Ob LANs mit Switches, Repeater, Hubs oder Router gekoppelt werden sollen,
über welche Art von Verkabelung die Systemkomponenten verbunden werden,
ist Sache des Netzspezialisten. Ebenso ist die Realisierung der LAN-Strukturen
Sache des Netzspezialisten. Der DWH-Spezialist muss alle Informationen, die
der Netzspezialist für die Struktur- und Produktentscheidungen braucht,
bereitstellen. Die folgende Reihenfolge des Vorgehens (kursiv dargestellte
Schritte sind vom Netzspezialisten durchzuführen) hat sich bewährt.

Verfahren: Bestimmung der Anforderungen an die DWH-Netzarchitektur


❖ Feststellung der Datenquellen der Lokation, eintragen in das Referenz-
schema DWH-Netz
Lokation
Rechnertyp, LAN-Segment und Typ
Applikationen und Datenbanken der Datenquellen
❖ Bestimmung der Anwender im LAN
Lokation und vorhandene Netze
aus Systemverzeichnissen
Kapitel 5 • Hardwarekomponenten und Netzinfrastrukturen 251

❖ Bestimmung der Aufstellorte der Server mittels Checkliste Server-Allo-


kation
❖ Erstellung LAN-Schema mit Anwender- und Serverlokationen
Entwurf anschauliche Netzgrafik mit vereinbarter Symbolebibliothek
❖ Bemessung der LAN-Komponenten und LAN-Leitungen, Hausverkabe-
lungen
❖ Bestimmung der LAN- Leitungskapazitäten
Bestimmung der LAN-Leitungsart (Token Ring, Ethernet...)
Bestimmung der LAN-Betriebssysteme
Bestimmung der LAN-Server und der LAN-Dienste (z.B. Drucken)

Die kursiven Schritte sind nicht vom DWH-Spezialisten, sondern vom Netz-
werkspezialisten auszuführen.
DWH-Referenznetzschema
Neben der Lokation soll der DWH-Spezialist in der Netzgrafik die Rechnervor-
aussetzungen wie Rechnertyp und Betriebssystem, angeben, da diese für die
Fähigkeiten des LAN wichtig sind. Für die externen Informationsquellen die ja
über das WAN erreicht werden, ist das Betriebssystem und der Zielrechner
unerheblich. Die Zugängigkeit wird vom Provider sichergestellt. Die Bestim-
mung der Rechner wird im folgenden Kapitel behandelt.
Das Hausnetz großer Unternehmen ist in mehrere LANs unterteilt. Oftmals
sind diese LANs dem zentralen Rechner des jeweiligen LANs entsprechend ver-
schieden, so dass mehrere LAN-Arten miteinander gekoppelt werden müssen.
Die Bearbeitung der Netzproblematik durch den DWH-Manager beginnt mit dem
Formulieren der Informationswege vom DWH-Benutzer zu den Servern der Roh-
daten bzw. den ursprünglichen Informationsquellen. Die Platzierung der DWH-
Server ist zu diesem Zeitpunkt noch völlig offen. Hierfür ist ein Schema mit Fel-
dern, in die Angaben zu LANs, Server und Arbeitsplatzrechner mit Lokation, Typ,
Anzahl eingetragen werden können, dienlich. Dies ist ein DWH-Referenznetz-
schema mit allen möglichen, für die DWH-Gestaltungsentscheidung zu beach-
tenden LANs ohne die passiven und aktiven Netzkomponenten wie z.B. Router,
Switches, Hubs. Mitunter ist es nützlich, Angaben zu WANs einzubeziehen.
Die Manager des Corporate Network oder die Netzwerkplaner machen aus die-
sem Referenzschema mittels Grafikprogrammen mit speziellen Symbolebiblio-
theken ein professionelles Netzschema mit vorgefertigten und fest definierten
Symbolen für alle Komponenten, identifizierenden Kennzeichnungen und
Kapazitätsangaben.
Aus der genannten Profizeichnung kann der DWH-Spezialist ein anschauliche-
res, von den für den DWH-Benutzer unwesentlichen Details befreites Bild,
zeichnen. Unwesentlich für den DWH-Benutzer sind z.B. Angaben zur Koppe-
lung oder technischen Ausführung der WAN und LAN.
252 Kapitel 5 • Hardwarekomponenten und Netzinfrastrukturen




 


    


 !  
  

  
      



)
 


 " & " /0 #  )


# '(# 11  
 #   % #
#  $

  $


 






*+#, 2  # 

 -  -  



(
( .
 /0.
#
  
 
   !"  " 11

(








 
3/34
#
  $



  

 


  

  
)##(  .,)
70# '& ') ')
+634 50# 20#
11 
 11
*+ +6  $ ! -



 
 %
 &

Abbildung 5.9: Referenzschema DWH- Netz

Checkliste Server-Allokation
Die Platzierung oder Allokation der DWH-Server hängt von den Verfügbar-
keitsanforderungen und von den Wartungsaufgaben ab. Je näher der DWH-Ser-
ver beim Anwender ist, umso höher ist die Verfügbarkeit und umso besser ist
die Performance. Die Verfügbarkeit ist höher, da weniger Zwischenkomponen-
ten und Leitungen ausfallen können. Die Performance ist besser, weil weniger
Verarbeitungsschritte zwischen dem Anwender und dem Server liegen.
Kapitel 5 • Hardwarekomponenten und Netzinfrastrukturen 253

Die Verfügbarkeit hängt auch von der Pflege der Geräte ab. Das bedeutet, je
näher der Service angesiedelt ist, umso schneller ist die Reaktion auf Betriebs-
probleme möglich. Zentraler Service ist kostengünstiger, da die Ressourcen
besser verteilt werden können. Wenn allerdings ein zentraler Service lokal ein-
gesetzt werden muss, dann sind Reisezeit und Reisekosten zu teuer.
Die Data Warehouse Anwender sind in der Regel international verteilt, so dass
es aus Sicht der Servernähe immer entfernte und damit benachteiligte Teilneh-
mer gibt. Für diese muss dann eine Ausfalllösung geschaffen werden. Die Allo-
kation des oder der DWH-Server ist ein Optimierungsproblem. Das heißt, es
gibt keine eindeutige Lösung. Das wichtigere Kriterium ist allerdings das Per-
sonalproblem. Wichtige Fragen hierzu sind:
✔ Bietet der lokale Arbeitsmarkt ausreichend qualifiziertes Personal?
✔ Ist dessen Verfügbarkeit und Zuverlässigkeit gewährleistet?
✔ Ist das Gehaltsniveau vertretbar?
✔ Sind eventuell Versetzungen und Versendungen von Zentralpersonal mög-
lich?
✔ Sind lokale Servicepartner zu engagieren?
Die Kriterien für die lokale Zuordnung, die Allokation, sind in der folgenden
Checkliste Server-Allokation zusammengefasst.

Kriterium Objekt der Kritik

Betriebsfähigkeit Hardware, Software

Servicebereitschaft Software

Qualifikation Partner

Zuverlässigkeit Personal

Organisationsstruktur Aktualität, Rechtsform

Verfügbarkeit

Sicherheit

Mobilität

Tabelle 5.3: Checkliste Server-Allokation

Bezüglich der Einbindung zweier nicht weit voneinander entfernter Standorte


kann noch die Wahl zwischen der Konfiguration der Verbindung als LAN oder
als WAN getroffen werden. Dies ist ebenfalls Aufgabe des Netzspezialisten.
Für die Vertiefung des Themas LAN sei empfohlen:
 Tanenbaum, Netzarchitektur
 Kauffels, Lokale Netze
254 Kapitel 5 • Hardwarekomponenten und Netzinfrastrukturen

5.2 Rechnerkonfiguration für den Betrieb des DWH

5.2.1 Rechnertypen
Es gibt keine Lösung, die für alle Applikationen gleich gut und besser als
andere Lösungen ist. Für jede Applikation ist eine andere Rechnerkonfiguration
optimal. Die Optimalität ist die preiswerteste Alternative bei vorgegebenen
Leistungsmindestgrenzen. Die Rechnerentscheidung erfordert bereits so viel
Fachwissen, dass die Kompetenz des DWH-Spezialisten überfordert ist. Die Lei-
tung des Rechenzentrums wird die Entscheidungen anhand einer Charakteris-
tik der Rechnertypen und der Standards des Unternehmens treffen:
✔ nach Betriebssystem, um die Lauffähigkeit der clientseitigen Softwaremo-
dule und die Programmierbarkeit zu beurteilen
✔ nach wesentlichen Leistungsdaten, wie Massenspeicherplatz, Hauptspei-
cherplatz, Taktrate und parallel einsetzbaren Prozessoren, um die Erfüllung
der Anforderungen der Software nach Performance und Kapazität zu beur-
teilen
✔ nach Display-Auflösung zur Beurteilung der Lesbarkeit von großen Reports
und Farbigkeit für die Interpretation von Grafiken
✔ nach Mobilität zur Beurteilung von Gewicht, Größe, Transportierbarkeit im
Flugzeug
✔ nach Netzanbindungsfähigkeit bzw Replikationsfähigkeit zum Datenaus-
tausch mit dem DWH-Server.
Im Folgenden wird bezüglich dieser Kriterien kurz auf die einzelnen Rechner-
typen und ihre unterschiedliche Funktionalität eingegangen.
Taschenrechner, Kalkulatoren, Organizer
Taschenrechner, Kalkulatoren und Organizer sind für einen einzelnen, priva-
ten Anwender für die Einzelkalkulation, einfache Programmroutinen, Verwal-
tung kleiner Dateien und die Adressverwaltung konzipiert. So lassen sich zum
Beispiel auch DWH-Programme realisieren, wie das in Kapitel 7 »Vorgehens-
modell« dargestellte ROI-Schema von Dupont. Diese kleinen Programme kön-
nen auch Matrizenberechnungen ausführen, Businessgrafiken wie Balkendia-
gramme und Verlaufskurven anzeigen und sogar kleine Dateien verarbeiten.
Die Darstellung ist aufgrund zu kleiner Displays unübersichtlich, wird aber in
Zukunft in Bezug auf Lichtstärke, Kontrast und Auflösung erheblich besser
werden. Organizer sind für den Datenaustausch mit PCs vorbereitet, können
über ein Netz mit Hilfe eines Modems Daten versenden und sogar Terminals
emulieren. Für DWH ist allerdings die Anzeige zu klein und die Funktionalität
zu gering. Diese Rechnerkategorie wird deshalb nicht einbezogen. Trotzdem
sollte man die kontinuierlich wachsende Funktionalität im Auge behalten.
Kapitel 5 • Hardwarekomponenten und Netzinfrastrukturen 255

Bedeutung für DWH-Anwendungen:


➡ Taschenrechner, Kalkulatoren und Organizer sind für DWH-Anwendungen
nicht tauglich
Palmtops, Handhelds
Bei der Leistungsfähigkeit der heutigen Palmtops oder Handhelds (Terminale-
mulation, Spreadsheets, Relationale Datenbank, 8MB Hauptspeicher, 128MB
PCMCIA Massenspeicher, Netzanbindung) sind diese unbedingt in die Liste der
Möglichkeiten aufzunehmen. Bislang waren für Palmtops nur proprietäre
Betriebssysteme und entsprechend wenig Software erhältlich (PSION, SHARP).
Seit dem Erscheinen von Windows-CE für Palmtops und die entsprechenden
Toolkits zur Erstellung von Programmen ändert sich dieses Bild. Die Netzan-
bindung erlaubt mit Modems und PC-Karten das Lesen von Webseiten und den
Datenaustausch mit zentralen Rechnern. Hier beginnt die Anwendbarkeit für
DWH.
Bedeutung für DWH-Anwendungen:
➡ Palmtops sind als Frontend für hochverdichtete Daten, sehr kleine Daten-
mengen und maximal dreidimensionale Würfel als DWH-Anwendungen
tauglich
Notebook, Subnotebook, Laptop
Die mobile Variante des PCs ist das Notebook, das samt seiner Peripheriekom-
ponenten im Reisegepäck untergebracht werden kann. Die kleinere Variante
des Notebooks ist das ca. A5 große, zwei Zentimeter hohe Subnotebook. Die
Verkleinerung geht auf Kosten der Auslagerung der Massendatenspeicher CD
und Floppy-Disk, des verkleinerten Bildschirms und der (gegenüber dem PC
ohnehin schon verkleinerten) nochmals kleineren Tastatur. Notebook und Sub-
notebook lassen den Einbau weiterer Karten nicht zu, weshalb sich die Technik
einer von außen einsteckbaren, scheckkartengroßen PCMCIA-Karte etabliert
hat. Als die Notebooks noch Aktentaschengröße hatten, hießen sie Laptops, um
anzuzeigen, dass sie das Arbeiten ohne Schreibtisch auf dem Schoß oder auf
den Knien ermöglichen. Subnotebooks gibt es sowohl für das Betriebssystem
Windows-CE wie auch für NT und Windows 95/98.
Der Einsatz eines Notebooks ist für mobile Arbeitsplätze sinnvoll. Das ist beson-
ders für das Erfassen von Daten am Ort der Entstehung der Fall. Anwendungen
sind Einscannen von Barcodes, Erfassen von Interviews und direktes Protokol-
lieren des Verhaltens einer technischen Anlage bei einer Kontrolle.
Zur Orientierung bezüglich der Größe der Geräte in der Abbildung: die Breite
eines großen Gerätes beträgt ca. 25cm und die Breite des kleinen Gerätes ca.
20cm.
256 Kapitel 5 • Hardwarekomponenten und Netzinfrastrukturen

Abbildung 5.10: Subnotebook und Handheld

Bedeutung für DWH-Anwendungen:


➡ Notebook, Subnotebook und Laptop sind als Frontend für OLAP-Zugriffe
und Reportgestaltung tauglich. Für im Verhältnis zum DWH kleinen Daten-
mengen ist auch ein kleines Data Mart möglich.
Arbeitsplatzrechner, Personal Computer, Workstation
Der am häufigsten verbreitete Rechner ist der Arbeitsplatzrechner, Personal
Computer oder kurz PC, der gestiegenen Leistungsfähigkeit wegen neuerdings
auch Workstation genannt. Der PC ist kein tragbares Arbeitsgerät, sondern sta-
tionär eingesetzt. Er ist aber doch so mobil, dass er bei Umzug schnell abgebaut
und in einem anderen Büro wieder aufgebaut werden kann, ohne besondere
Beförderungsmittel und ohne besonderes Spezialwissen einsetzen zu müssen.
Als Server eingesetzte PCs haben eine Belastungstragfähigkeit von etwa 50
Usern.
Personal Computer können in mehreren zu einem sogenannten Cluster gekop-
pelten Einheiten mit nur einem Bildschirm als Einschübe in einem schrankar-
tigen Gestell zusammengestellt werden. Diese sogenannten Racks werden
sowohl für RISC- als auch für CISC-Prozessoren gebaut und sind damit für die
Betriebssysteme UNIX, NT und auch DEC-VMS geeignet. Der große Vorteil die-
ser Bauweise ist die große Platzersparnis bei einer leichten Skalierbarkeit.
Kapitel 5 • Hardwarekomponenten und Netzinfrastrukturen 257

Abbildung 5.11: Beispiel für PC-Racks mit einem Gehäuse

Beispiel: PC-Racks
Im folgenden Beispiel sind im linken Rack 13 Einschübe mit je vier Pentium
CPUs und einem Server-Einschub mit acht Pentium CPUs möglich. Das
mittlere Rack umfasst neben einem Monitor und einem RAID-System neun
Einschübe für vier CPU-PCs. Das rechte Rack enthält acht Steckplätze für
Einschübe mit vier CPUs und Plätze für ein RAID-System und für eine
Stromausfallversorgungseinheit USV und einen Monitor.
Zur Orientierung bezüglich der Größe der Geräte in der Abbildung: Die
Breite eines Gerätes ist ca. 60 cm, die Höhe ca. 2 m. Die lauffähigen Betriebs-
systeme sind NT, UNIX, DEC-VMS.

Bedeutung für DWH-Anwendungen:


➡ Arbeitsplatzrechner, Personal Computer und Workstation sind als Frontend
für OLAP-Zugriffe und anschließende Reportgestaltung mit kleineren
Datenmengen als bei DWH-Anwendungen tauglich. Für im Verhältnis zum
DWH kleinen Datenmengen ist auch ein kleines Data Mart möglich, aber für
Data-Marts-Server nicht geeignet. Wegen der ausgezeichneten Skalierbar-
keit und des Einsatzes von Parallel-Prozessoren eignet sich das PC-Rack
hervorragend als DWH-Server.
258 Kapitel 5 • Hardwarekomponenten und Netzinfrastrukturen

Abbildung 5.12: Beispiel für PC-Racks mit zwei Gehäusen

Mikrorechner, Minirechner
Die nächstgrößere Kategorie bilden die Mikrorechner mit einer Belastungs-
tragfähigkeit von etwa 100 Anwendern. Minirechner sind leistungsfähiger als
Mikrorechner und haben eine Belastungstragfähigkeit von etwa 1.000 Usern.
Die ehemals deutliche Grenze zwischen Minirechner und Mikrorechner ist de
facto verschwunden. Minirechner werden teilweise mit proprietären Betriebs-
systemen geführt und teilweise mit firmenspezifischen UNIX-Derivaten. Mit
»firmenspezifisch« ist hierbei gemeint, nicht ganz so proprietär aber doch mit
firmenspezifischen Eigenheiten, was die Firmen auch in der Bezeichnung aus-
drücken:
✔ DEC ULTRIX
✔ HP HP-UX
✔ IBM AIX
Bei besonderen Anforderungen an Rechenleistung, Schnelligkeit des Speicher-
zugriffes und simultane Verarbeitung großer Datenmengen wird der parallele
Einsatz mehrerer Prozessoren interessant. Dies ist besonders im Bereich der
Kapitel 5 • Hardwarekomponenten und Netzinfrastrukturen 259

Bildverarbeitung, der Verarbeitung multimedialer Daten und großer Datenban-


ken von geometrischen und geographischen Modellen. Hierfür wurde das Kon-
zept der Parallelrechner geschaffen. Die parallel arbeitenden Prozessoren kön-
nen dabei in getrennten Rechnergehäusen sitzen, die über ein LAN
(Rechnerverbund) verbunden sind.
Ein Beispiel für einen solchen, schon als Superverbund zu bezeichnenden,
Rechnerverbund ist der zur Berechnung der Filmsequenzen des Trickfilms
»Toy-Story« aufgestellte Workstationverbund aus über 100 Rechnern. Ein wei-
teres Beispiel ist der 1999 in Zürich vorgestellte LINUX-Cluster mit 50 PCs, die
über ein 100-Mbit-Ethernet verbunden wurden. Der Hauptspeicher umfasste
insgesamt 50x512Mbyte. Interessant ist an diesem Versuch, dass man damit
eine Lösung schaffen konnte, die in den »Top 500« der leistungsfähigsten Paral-
lelrechner Platz 202 erreichte, bei Investkosten von ca. 1 Mio. DM.

Abbildung 5.13: Beispiel eines PC-LINUX-Cluster mit Alpha-Rechnern

Die parallelarbeitenden Prozessoren können auch in einem Gehäuse auf ver-


schiedenen Platinen untergebracht sein (Multiprozessorrechner) oder sogar
auf einer Platine (Transputer) montiert sein. Ebenso wie bei den PCs schon
angeführt, kann die Bauweise auch ein Rack mit verschiedenen Einschüben mit
RISC-Rechnern sein. Den Einsatz dieser geballten Technologie fordern die ser-
verseitig auftretenden Datenmengen und Programmkomplexe. Die Vorausset-
zung für den Einsatz von Parallelrechnern ist die Betriebsfähigkeit der DWH-
Software, also das dort laufende Betriebssystem.
260 Kapitel 5 • Hardwarekomponenten und Netzinfrastrukturen

Beispiel Minirechner (1996)


Am Beispiel der VAX 6000 seien typische Leistungen eines Minirechners ver-
deutlicht. Die Ausstattung pro Platine beträgt ein bis fünf Vektorprozesso-
ren. Bis zu acht Speicherplatinen mit bis zu 518 MB sind für den Hauptspei-
cher einsetzbar. Es sind zwei Plattenlaufwerke mit bis zu 3GB
Massenspeicher im Cabinet integriert und ein Anschluss von bis zu 40 exter-
nen Laufwerken 1GB möglich.

Abbildung 5.14: Beispiel Minirechner: VAX 6000 von DEC

Zur Orientierung bezüglich der Größe der Geräte in der Abbildung sei die
Höhe eines Gerätes mit ca. 150 cm genannt.

Bedeutung für DWH-Anwendungen:


➡ Einige Minirechner sind mit Multiprozessorausbau als Server für DWH zu
empfehlen.
Großrechner
Großrechner sind mit der Belastungstragfähigkeit von mehreren Tausend
Anwendern leistungsfähiger als Minirechner. Großrechner können nur von
Spezialunternehmen abgebaut, befördert und wieder aufgebaut werden. Es sind
spezielle Beförderungsmittel, besondere Werkzeuge und Spezialwissen erfor-
derlich. Auch Großrechner werden als Multiprozessorrechner gebaut.
Bedeutung für DWH-Anwendungen:
➡ Großrechner sind als Server für DWH zu empfehlen.
Kapitel 5 • Hardwarekomponenten und Netzinfrastrukturen 261

Supercomputer
Supercomputer sind die leistungsfähigsten Rechner. Supercomputer sind fest
installiert und in der Mobilitätsskala das unbeweglichste aller Computersys-
teme. Sie sind mehr als alle anderen Systeme an klimatisierte, staubfreie Räume
gebunden. Supercomputer werden mit einem proprietären Betriebssystem
geführt. Für Supercomputer sind keine DWH-Komponenten entwickelt worden.

Beispiel Supercomputer
Als Beispiel für einen sehr jungen Supercomputer soll die T3E-1200E von
Cray Research dienen. Die 1200E ist ein massiv paralleler Rechner mit bis zu
2048 Prozessoren, die je eine Taktrate von 600 MHz haben. Ein Engpass ist
der Datentransfer zwischen den Prozessoren. Bei der 1200E erledigt das ein
Router-Chip mit 42 Gbit/s. Der Preis für ein 1200E Rechnersystem liegt in
der Größenordnung von 20 Mio. DM.

Abbildung 5.15: T3E-1200E von Cray Research

Die T3E-1200E wird für Wetterberechnungen eingesetzt.

Bedeutung für DWH-Anwendungen:


➡ Supercomputer werden aus Kostengründen nicht für DWH eingesetzt.
Bezüglich des Marktes der Supercomputer sind noch ein paar Zahlen interes-
sant. Die weltweit vertriebenen Supercomputer werden in einer Leistungsrang-
liste, den »Top 500«, geführt. Auf den ersten 25 Plätzen der »Top 500« der leis-
tungsfähigsten Rechner der Welt sind 18 Plätze von Cray Research besetzt.
262 Kapitel 5 • Hardwarekomponenten und Netzinfrastrukturen

Seit einigen Jahren werden zu den Supercomputern nicht mehr nur die in
einem zusammenhängenden Gehäuse eingebauten Rechnergebilde gezählt. Es
werden auch die Rechnerverbunde als Supercomputer angesehen, wie das wei-
ter vorne erwähnte Rechnercluster.
Chip-Card-Rechner
Der Vollständigkeit zuliebe sei noch ein Blick auf einen neueren Rechnertyp
geworfen, dessen Bedeutung mangels geeigneter Software für DWH derzeit
noch nicht groß ist, in Zukunft aber steigen wird.
Mittlerweile sind Chip-Card-Rechner, Rechner von der Größe einer Scheck-
karte, erhältlich. Diese benötigen allerdings ein zusätzliches Eingabegerät und
haben dann doch wieder die Größe eines Palmtops. Einen kompletten Rechner
in Größe einer PCMCIA-Karte gibt es derzeit noch nicht: Zur Bedienung sind
ebenfalls wie bei der Chip-Card noch externe Einheiten erforderlich, wie Tasta-
tur, Mikrofon, PC. So ist es auch nur möglich, einzelne und kurze Datensätze
anzuzeigen, wie Adressen und Kurznotizen, was für DWH-Funktionen nicht
ausreicht.
Bedeutung für DWH-Anwendungen:
➡ Chip-Card-Rechner werden aus Kostengründen nicht für DWH eingesetzt.
Fuzzy-Logic-System, Künstliche Neuronale Netze
Immer häufiger ist von Fuzzy-Logic-Systemen und Künstlichen Neuronalen
Netzen, kurz KNN, die Rede. Ob hierzu Rechnertypen auf dem großen Markt
der Datenbankanwendungen platziert werden, bleibt noch abzusehen. Es gibt
Prototypen, die eher für Erfahrungszwecke eingesetzt werden. Die Konzepte
des Rechnens mit Fuzzy-Sets wie auch mit Prinzipien der Neuronalen Netze
werden derzeit in Rechnern mittels Programmen simuliert. Über die Nützlich-
keit gibt es noch zu wenige überzeugende Erfahrungsberichte von Anwendern,
um sie in die Rechnerauswahl miteinzubeziehen. In der Softwareauswahl sind
sie als funktionale Module interessant.
Bedeutung für DWH-Anwendungen:
➡ Fuzzy-Logic-System und Künstliche Neuronale Netze (KNN) sind für DWH-
Analysen nicht tauglich, sie sind noch viel zu teuer und serverseitig und
clientseitig noch ohne komfortable DWH-Softwareausstattung.
Prozessrechner
Prozessrechner sind nicht für die Langzeitspeicherung von Daten konzipiert
und damit auch nicht für Datenbankanwendungen. Ihre Aufgabe ist die zeitver-
lustfreie Steuerung oder auch Echtzeit-Steuerung von Produktionsprozessen.
Bedeutung für DWH-Anwendungen:
➡ Prozessrechner sind für DWH-Anwendungen ungeeignet, zu teuer und
ohne entsprechende Standardsoftware.
Kapitel 5 • Hardwarekomponenten und Netzinfrastrukturen 263

Datenbankmaschine
Nicht unerwähnt bleiben soll ein Rechnertyp, der speziell für die Verarbeitung
von Datenbankfunktionen konzipiert und auch in Einzelexemplaren gebaut
wurde, die Datenbankmaschine. Das Problem hierbei ist die Verfügbarkeit von
Anwendungen und das sehr tiefgehende und daher sporadisch verfügbare Spe-
zialwissen über Administration und Programmierung. Für Datenbankmaschi-
nen sind keine DWH-Komponenten entwickelt worden. Es sind außerdem welt-
weit Datenbankmaschinen eher in Forschungslabors als in Herstellerkatalogen
zu finden. Trotzdem wäre ein extra für die strukturierte Datenhaltung speziali-
sierter Rechnertyp mit entsprechend ergonomischer Datenbanksoftware sehr
nützlich und äußerst performant.
Bedeutung für DWH-Anwendungen:
➡ Datenbankmaschinen können derzeit aus Kostengründen nicht für DWH
eingesetzt werden.
Net-Computer
Auf der Client-Seite hat sich vor einiger Zeit mit großem Wirbel ein neues Kon-
zept mit einer geringen Auswahl von Produkten (soft wie hard) namens Net-
Computer (auch Network-Computer) bemerkbar gemacht. Der Net-Computer,
der oft der Produktgruppe intelligentes Terminal zugeordnet wird, ist ein End-
gerät ohne eigene Mengen-Datenhaltung, aber mit Prozessor und Hauptspei-
cher. Alle Programme laufen auf dem Netserver bis auf die Präsentation der
Programmelemente, die mittels dem auf dem Net-Computer installierten
Browser betrieben werden. Da die Net-Computer keinen deutlichen Preisvorteil
brachten, haben sie sich nicht durchsetzen können. Die über NC betreibbare
Programmvielfalt ist gering, und das Betreiben eines EXCEL-Sheet auf einem
entfernten Server bereitete z.B. der Anwenderschar Unbehagen. Für das Betrei-
ben von DWH-Frontends ist der Net-Computer ungeeignet, wenn die Daten
lokal weiterverwendet werden sollen.
Bedeutung für DWH-Anwendungen:
➡ Net-Computer werden nicht für DWH eingesetzt, da bisher zu wenig Soft-
ware am Markt vorhanden ist und die flexiblen Client-Berechnungen auf-
grund mangelnder Prozessor-Intelligenz auf den NC-Server ausgelagert
werden müssten. Mobiles Rechnen ist damit gar nicht möglich.
Virtuelles Computer-Netz
Aus der Gruppe der Rechnerverbunde kommt ebenfalls ein neues Konzept, das
weltweit verteilte Computer bei Bedarf für eine bestimmte Aufgabe zu einem
großen temporären virtuellen Computer-Netz koordiniert. Die Rechnerleistung
steht nach der Einbindung in den Verbund wie in einem Multiprozessorsystem
oder einem Parallelrechner zur Verfügung. Die Koordination der verschiedenen
Rechner, das ist zuerst die Aufgabenverteilung, wird bis zur Lösung dieser Auf-
gabe aufrechterhalten und danach aufgelöst und abgemeldet. Die einzelnen
264 Kapitel 5 • Hardwarekomponenten und Netzinfrastrukturen

Rechner stehen dann einem anderen virtuellen Netz zur Verfügung. Für die
Koordination ist ein neues Betriebssystem erforderlich. Ein Betriebssystem, das
diese Koordination leisten soll, ist bei der Firma Sun derzeit im Entwurfssta-
dium. Es ist offensichtlich, dass die Kommunikationszeit zwischen diesen
Rechnern der eigentliche Leistungsengpass ist.
Bedeutung für DWH-Anwendungen:
➡ Virtuelle Computer-Netze sind noch im Anfangsstadium ihrer Entwicklung
und können daher nur mit Risiko und unter großem Aufwand für DWH ein-
gesetzt werden.

5.2.2 Aufrüstung
Neben der einmal getroffenen Gestaltungsentscheidung ist im Laufe der
Betriebszeit die Anpassung an aktuelle Bedarfe erforderlich. Den größten Ein-
fluss auf die Veränderung haben technologische Neuerungen und veränderte
Leistungsanforderungen. Für die Hardwareausstattung bedeutet dies zweierlei:
Erstens muss die Gestaltungsentscheidung die spätere Anpassbarkeit berück-
sichtigen und zweitens ist die Anpassung bei Bedarf zu gestalten. Ein Beispiel
für die Aufrüstungsmöglichkeiten eines PCs sei hier stellvertretend für die Pro-
blematik angeführt:
✔ Prozessor-Overdrive zur Steigerung der Taktrate und Ergänzung mit
zusätzlichen Leistungen
✔ Einbau von stärkeren Grafikkarten oder Erweiterung des Grafikspeichers
✔ Einbau von Video-Tunerkarten
✔ Austausch von alten CD-ROM-Laufwerken gegen schnellere CD-ROM-Lauf-
werke oder DVD-Laufwerke
✔ Aufrüstung des Hauptspeichers mit zusätzlichen Speicher-Chips.
Die folgende Tabelle zeigt in Grundzügen die Entscheidungssituation und die
daraus resultierende Aufrüstungsstrategie nach einem Katalog der Firma Digi-
tal Equipment Corporation (DEC).

Problem Bedingung Aufrüstung

Begrenzter Raum Schnelle Aufrüstung von Hauptspeicher Board-Level-Upgrade


und Prozessorleistung, niedrige Kosten

Erweiterung innerhalb Senkung der Betriebskosten Cabinet-Austausch


des Cabinet nicht möglich

Eingeschränkte Verfüg- Hohe Input-Output-Rate erforderlich Cluster-Aufbau und Cluster-


barkeit Erweiterung

Applikationsüberlastung Lokale Systemkontrolle erforderlich Vernetzung, neue Rechner

Tabelle 5.4: Möglichkeiten der Aufrüstungsentscheidung


Kapitel 5 • Hardwarekomponenten und Netzinfrastrukturen 265

Die Aufrüstung von Großrechnern und Minirechnern kann z.B. durch soge-
nannte Board-Upgrades
✔ Bestückung der Hauptplatine mit weiteren Prozessoren
✔ Zusätzliche Platinen
✔ Austausch der alten Platinen gegen Platinen mit Vektorprozessoren
oder durch
✔ Cabinet Austausch
✔ Clusterbildung mehrerer Rechner
✔ Applikationsauslagerung an weitere Rechner
erfolgen.
Die folgende Grafik der Aufrüstungspfade eines etwas älteren Modelles von
DEC, die VAX 6000/200 soll die Vielfältigkeit der Skalierung belegen.

Abbildung 5.16: Aufrüstungsmöglichkeiten der VAX 6000/200


266 Kapitel 5 • Hardwarekomponenten und Netzinfrastrukturen

5.2.3 Rechnerauswahl
Problemstellung und Motivation
Bezüglich der Hardware liegt der Sachverhalt der Entscheidungskompetenz
gänzlich anders als bei Gestaltungsentscheidungen zur Software. Das Ziel der
Softwarebestimmung bestand aus der Make-or-Buy-Entscheidung, auf der Basis
der Spezifizierung der Anforderungen und aus einer Eigenentwicklung von
nicht erwerblichen Softwarekomponenten. Das Ziel der Rechnerbestimmung
besteht nicht darin, einen Rechner zu entwerfen und zu bauen und all seine
aufwändigen Entwicklungsschritte zu durchlaufen, sondern darin, den optima-
len Rechner zu beschaffen. Die Aufmerksamkeit liegt auf der Evaluation des
Marktangebots im Unterschied zu den bereits besprochenen, zu konfigurieren-
den Softwareteilen. Software, die dem gewünschten Leistungsumfang nicht
entspricht, muss selbst entwickelt werden. Im Gegensatz dazu kann eine Rech-
nerkonfiguration nur aus dem Marktangebot zusammengestellt werden.
Es stellt sich die Frage, welche Rechnerkonfiguration optimal für das
gewünschte DWH ist. Das erste Problem einer Rechnerkonfiguration ist, dass
eigentlich der Hersteller der Software wissen müsste, welche Rechnerleistung
für den Betrieb seiner Software erforderlich ist, diese aber nicht öffentlich
bekannt gibt. Schließlich hat er ja bereits bei der Programmierung und
anschließenden Tests entsprechende Erfahrungen gesammelt. Aber da er Haf-
tungsansprüche bei falschen Ratschlägen fürchtet, gibt er keine verbindlichen
Auskünfte oder macht nur sehr vage Andeutungen. Einige Hardwarehersteller
helfen dem Anwender durch eine umfangreiche, strukturierte Befragung, die
sie in einer eigenen Erfahrungsdatenbank auswerten lassen. Bei IBM ist ein sol-
cher Fragenkatalog für die Konfiguration eines SAP-Servers z.B. ca 30 DIN-A-
4-Seiten lang. Viele Fragen dieses Kataloges sind nicht aus dem Stegreif zu
beantworten und erfordern viel Aufwand für die Bearbeitung. Deswegen und
wegen der kontinuierlich wachsenden Anforderung ist der sicherste Weg der
Weg der Skalierung des Systems. Man fängt klein, aber ausbaubar an und ska-
liert den Erfahrungen entsprechend.

Gestaltungs- und Lösungsmöglichkeiten


Die Gestaltungsproblematik des DWH-Spezialisten liegt nicht in der Konstruk-
tion und dem Zusammenbau von Computern, auch Assemblieren genannt, son-
dern in der Auswahl aus dem Marktangebot. Die Gestaltungsaufgabe ist also auf
die Auswahl und Beschaffung des richtigen auf dem Markt verfügbaren Model-
les beschränkt.
In frühen Tagen der EDV, dem Zeitalter der »proprietären Systeme«, wurde die
Hardwareentscheidung durch die Softwareentscheidung mit getroffen. Software
war an ein Betriebssystem gebunden und damit nur im »Bundle« mit der Hard-
wareplattform zu beziehen. Seit sich die Technologie der Client/Server-Systeme
durchgesetzt hat, ist eine Austauschbarkeit der Hardware und eine Auflocke-
rung der Herstellerabhängigkeit eingetreten. Gleichzeitig ist damit ein Ent-
scheidungsgang mehr, die Entscheidung der Rechnerplattform, erforderlich.
Kapitel 5 • Hardwarekomponenten und Netzinfrastrukturen 267

Nicht immer ist die Hardwareentscheidung frei zu treffen, da sich Unterneh-


men meistens zur Erzielung besonderer Rabattstaffeln langfristig für einen
Rechnerhersteller entscheiden. Der DWH-Spezialist muss sich zunächst über
die Freiheitsgrade in der Rechnerbeschaffung erkundigen und im vorgegebe-
nen Rahmen seine Anforderungen definieren.
➢ Herstellerbindung der Rechnerbeschaffung feststellen
Da auf einem Rechner – Server wie auch Client – in der Regel mehrere Pro-
gramme verschiedener Hersteller betrieben werden müssen, kann die Rechner-
entscheidung erst dann gefällt werden, wenn alle unbedingt erforderlichen Pro-
gramme feststehen. Meistens müssen verschiedene Rechner mit verschiedenen
Konfigurationen beschafft werden. Dann besteht die Gestaltungsaufgabe darin,
die Zahl der Rechnertypen minimal zu halten, um die Administrationskosten
gering und die Flexibilität zu Produktwechseln hoch zu halten. Es ist allerdings
unabdingbar, eine grundsätzliche Entscheidung zur Rechnertechnologie zu
treffen.
➢ Rechnertechnologie festlegen
Die Gestaltungsfreiheit liegt in der Festlegung der Technologie, die sich im
Rechnertyp und im Prozessortyp ausdrückt, und in der Auswahl des Herstel-
lers, wenn nicht, wie in vielen Firmen vorgegeben, eine bindende Hersteller-
Partnerschaft besteht. Und die Gestaltungsfreiheit liegt, last but not least, in
der Definition der Baureihe und der genauen Konfiguration von Prozessortyp,
Speichergröße und Massenspeicher und bei Racks auch Stromausfallschutz
und Backup-System.
➢ Server-Rechner festlegen nach Rechner-Technologie, Prozessortyp, Herstel-
ler, Baureihe, Konfiguration Backup, Stromausfallschutz
➢ Arbeitsplatzrechner festlegen nach Rechner-Technologie, Prozessortyp,
Hersteller, Baureihe, Konfiguration
Neben der Auswahl des Rechners ist die Arbeitsplatzausstattung noch mit Peri-
pheriekomponenten zu komplettieren. Darüber wird noch im Abschnitt
»Bestimmung der Peripheriekomponenten« weiter unten gesprochen.
Die Rechneraufrüstung, bzw. die Entscheidung der Aufrüstungsstrategie
gehört nicht mehr zum Aufgabenfeld des DWH-Spezialisten, sondern ist bereits
Aufgabe der Anwenderservices bzw. des Rechenzentrums. Der DWH-Spezialist
muss diese allerdings mit Prognosen der Bedarfsentwicklung versorgen.
➢ Anpassungsprognosen und Bestimmung der Produkteigenschaften für die
Anpassung
Mit der Hardwareentscheidung muss noch eine Lokationsentscheidung getrof-
fen werden:
➢ Verteilung der Arbeitsplatzsysteme auf Orte und Räume
➢ Aufspaltung und Allokation der DWH-Ausschnitte (Data-Marts)
268 Kapitel 5 • Hardwarekomponenten und Netzinfrastrukturen

Problemlösung: Regeln und Hilfsmittel


Das Verfahren
Der DWH-Spezialist darf nie die Perspektive der Anwender verlieren. Das zu
gestaltende DWH ist ja ein System für Anwender und muss daher die Bedürf-
nisse des Anwenders befriedigen. Das bedeutet, die Aufgaben der Anwender zu
unterstützen, ihre Arbeit zu erleichtern, den Arbeitsplatz effizienter zu
machen. Den Anwender interessiert im Prinzip nicht, ob die Daten aus Übersee
oder aus dem Nachbarort kommen. Für den Anwender ist es auch unwichtig,
welche Komponenten zu einer Architektur zusammengesetzt wurden und mit
welchen Methoden die Erkenntnisse erzielt wurden. Aber die Ergonomie seines
Arbeitsplatzes, die Verfügbarkeit und die Funktionalität seines Systems, sind
ihm äußerst wichtig. Das folgende Verfahren ist zu empfehlen:

Verfahren: Bestimmung der Anforderungen an die DWH-Rechner


❖ Feststellung der strategischen Abkommen mit Hardwareherstellern
❖ Bestimmung der Rechnertechnologie mit Hilfe der Rechnertypenübersicht
❖ Verschaffung eines Marktüberblickes mit Hilfe der Rechnertypenübersicht
❖ Alternative Auswahl und Evaluation mittels Produktevaluationsverfahren
❖ Feststellung der erforderlichen Endgeräte
Lokation
Rechnertyp, Kapazität, Prozessor
eingebaute Kommunikationskomponenten
❖ Bestimmung der Server
Lokation
Bautyp, Kapazität, Prozessor
eingebaute Kommunikationskomponenten
❖ Aufstellung von Wachstumsprognosen

Rechnertypenübersicht
Das zu lösende Problem heißt: Für welchen Arbeitsplatz und für welche Server-
Dienste ist welche Rechnerkonfiguration optimal? Der DWH-Spezialist wird die
Rechnerauswahl nicht alleine treffen. Er benötigt lediglich für die Wahrung sei-
nes Überblicks eine grobe Charakteristik der Rechnertypen mit
✔ Betriebssystem, um die Lauffähigkeit der clientseitigen Softwaremodule
und die Programmierbarkeit zu beurteilen
✔ wesentlichen Leistungsdaten wie Massenspeicherplatz, Hauptspeicherplatz,
Taktrate, um die Erfüllung der Anforderungen der Software nach Perfor-
mance und Kapazität zu beurteilen
✔ Display-Auflösung zur Beurteilung der Lesbarkeit von großen Reports und
Farbigkeit für die Interpretation von Grafiken
Kapitel 5 • Hardwarekomponenten und Netzinfrastrukturen 269

✔ Mobilität zur Beurteilung von Gewicht, Größe, Transportierbarkeit im Flug-


zeug
✔ Netzanbindungsfähigkeit bzw Replikationsfähigkeit zum Datenaustausch
mit dem DWH-Server
Zunächst sei ein Überblick über die Rechnertypen und deren Kurzcharakteris-
tik gegeben. Die Daten der folgenden Rechnertypenübersicht sind typisch. In
der Praxis zeigt sich, dass die einstmals scharfen Abgrenzungen verschwinden
und die Leistung eines Rechnertyps der unteren Klasse nahezu bis an die direkt
darüberliegende Klasse ausgebaut werden kann.

Mobilität, Ener- Replikation/


Typ Leistung Display, Eingabe
gieversorgung Applikation
Organizer 1–2 MB Einfarbig, LCD TragbareTasche Infrarotschnittstelle
Proprietär Mhz Touchscreen Batterien Link-Kabel zum PC
1–4 MB Single-User Akkus Modem/Termine,
Adressen, Notizen

Palmtop 2–16 MB Ein- u. mehrfarbig, LCD Tragbare Tasche PCMCIA


MS Windows CE 75 Mhz Touchscreen, Mini-Tastatur Batterien Infrarotschnittstelle
Psion-OS Single-User Akkus, Netztrafo Link-Kabel zum PC
Modem, GSM, ISDN/
Termine, Adressen,
kleine Dokumente

Notebook 16–128 MB LCD-mehrfarbig Tragbarer Koffer Diskette, PCMCIA,


MS Windows 95, 100–300 Mhz Normtastatur Batterien CD,
98, NT Gigabyte Maus, Touchpad, Kamera Akkus, Netztrafo Infrarotschnittstelle
Apple MacIntosh CISC Singleuser LAN
Link-Kabel zum PC
Modem, GSM, ISDN/
Termine, Adressen,
Dokumente,
Datenbanken

PC, Work Station 32–256 MB Röhrenbildschirm Stationär Diskette, CD, DVD,


Apple-MacIntosh 100–300 Mhz LCD-mehrfarbig Stromnetz CD-ROM
NEXT 1–64 Gigabyte HS Multibildschirm Privattransport Infrarotschnittstelle
LINUX CISC Normtastatur Nummernbl. LAN
2–4 MB Maus,Touchpad,Kamera Modem, GSM, ISDN/
Grafikmem Single-User, 50 Multiuser Termine, Adressen,
Dokumente,
Datenbanken

Mikrorechner RISC PC-Terminal Montiert LAN/mittlere


UNIX Normtastatur Numnernbl. Stromnetz Datenbanken,
VMS ca 100 Multiuser Spezialtransport Serverdienste

Minirechner CMOS PC-Terminal Montiert LAN


UNIX Normtastatur Nummernbl. Stromnetz Bandstation/mittlere
TANDEM, Bull; SNI, ca 200 Multiuser Klimaraum Datenbanken,
IBM, DEC Spezialtransport Serverdienste

Großrechner 500–1.000 MIPS Terminal Montiert Proprietäres LAN


Proprietäre BS 1–16 Proz, CMOS Konsole Stromnetz Bandstation/große
TANDEM, Bull; SNI, 2–24 GB HS Normtastatur Numernbl. Klimaraum Datenbanken,
IBM, UNISYS ca 1.000 Multiuser Spezialtransport Serverdienste, zeit-
Spezialwerkzeug kritische Transaktionen

Superrechner 600Mhz Terminal Montiert auf Proprietäres LAN


Proprietäre BS bis 2.000 Proz Konsole Fundament Bandstation/große
TANDEM, Bull; SNI, Normtastatur Numernbl. Stromnetz Datenbanken, Forsch-
IBM, HITACHI, (Multiuser) Klimaraum ungsberechnungen,
CRAY, UNISYS Spezialtransport Wetterprognosen,
WS-Verbund Spezialwerkzeug Astronomie

Tabelle 5.5: Rechnertypen-Übersicht


270 Kapitel 5 • Hardwarekomponenten und Netzinfrastrukturen

Prozessorfestlegung
Statt die Auswahl bei einem Rechnersystem oder einer Bauart zu starten, kann
man auch zunächst den Prozessortyp festlegen. Die Leistungsfähigkeit von Pro-
zessoren wird regelmäßig gemessen, ihre Entwicklungsfähigkeit in der Zukunft
ausgeleuchtet und Empfehlungen veröffentlicht. Für den DWH-Spezialisten ist
interessant, dass das UNIX für RISC-Prozessoren entwickelt wurde und die
Microsoft-Betriebssysteme Windows NT, Windows 95 und Windows 98 für
CISC-Prozessoren. Eine Prozessorentscheidung ist damit großenteils auch eine
Betriebssystementscheidung.
Rechnerevaluation
Stehen mehrere Alternativen zur Wahl, kann das in Kapitel 9 »Produktevalua-
tion« vorgestellte Evaluationsverfahren angewendet werden. Kriterien für die
Beschreibung der Anwendersituation sind damit die Kriterien für die Rechnere-
valuation.
✔ Einzusetzendes Client-Softwareprodukt
✔ Größe der zu bewegenden Datenmengen, Größe der anzuzeigenden Reports
✔ Offlinefähigkeit, also Fähigkeit, unabhängig vom Netz betrieben werden zu
können und Daten nach Bedarf nachzutanken
Skalierung und Wachstum
Die Auslegung der Rechner deckt im ersten Planungsschritt nur die Anforde-
rungen des augenblicklichen Bedarfs ab. Als spezielle DWH-Kriterien für die
Auswahl der DWH-Server-Rechner dienen neben den üblichen, für alle Soft-
waresysteme gültigen Kriterien, zusätzliche Kriterien für die Belastung des
Systems:
✔ Bedarf der Datenmengen
✔ Anzahl der online zugreifenden User
✔ Gewünschte Antwortzeiten
✔ Kompatibilität der Betriebssysteme.
Der Bedarf wandelt sich im Laufe der Zeit, z.B. durch neue Aufgaben des Unter-
nehmens, Veränderungen der Märkte, organisatorische Umstrukturierungen.
Jede dieser Veränderungen hat Auswirkungen auf den Bedarf der Nutzer des
DWH und muss sich in Anpassungen der Konfiguration des DWH niederschla-
gen. Für den DWH-Spezialisten erwächst hieraus die Aufgabe, bereits in der
Konfiguration der Systeme die Flexibilität zu berücksichtigen. Er muss sich als
Prognostiker betätigen und die Zukunft der Bedarfe vorhersagen. Diese
Zukunft umfasst Wachstumsschätzungen der bestehenden Applikationen aus
✔ funktionaler Sicht: Welche Funktionen könnten zukünftig noch benötigt
werden?
Kapitel 5 • Hardwarekomponenten und Netzinfrastrukturen 271

✔ der Sicht der Datenmengen: Wie wird der Umfang der Datenmengen
zukünftig wachsen?
✔ der Sicht der Informationen: Ist zukünftig mit dem Bedarf an neuen Infor-
mationen, Informationsstrukturen, Informationsquellen, Informationsar-
ten zu rechnen?
Über das beste Zusammenspiel von DWH-Software und Rechnerarchitektur
werden die Softwarehersteller bestimmte Empfehlungen abgeben, die nur im
Test bestätigt werden können. Da hierzu nie eine verlässliche Vorausberech-
nung stattfinden kann, ist unbedingt auf die Skalierbarkeit des Rechnersystems
zu achten. Optimieren lässt sich noch der Administrations- und Qualifikations-
aufwand, indem man neben den bestehenden Betriebssystemen keine neuen
einführt.
Eine allgemeine Faustregel zur Bemessung der Server gibt es nicht. Anstelle
einer Faustregel sollen die Praxisbeispiele Anhaltspunkte für die eigene Konfi-
guration liefern. Es folgen einige Beispiele von Rechnerentscheidungen und zu
bewältigenden Datenmengen, die von der Gartner Group bekannt gemacht
wurden.

Beispiel: Rechnerlösungen zu Kapazitätsanforderungen


Finanzdienstleister,
Informix, 300GByte Rohdaten mit 67 Tabellen, 6 gleichzeitige Abfragen
32Knoten IBM-SP2
Telekommunikationsunternehmen
Informix 2,1Tbyte Rohdaten
90Knoten IBM SP2
Fastfood Firma
Informix 90Gbyte Rohdaten mit Starschema, 5 gleichzeitige Benutzer
HP9000, 4CPU
Finanzdienstleister,
Oracle, 900GByte detailliert und summiert, ca 10 gleichzeitige Benutzer
2*Cluster NCR3600
Telekommunikationsunternehmen,
Oracle, 225GByte, 35 Tabellen, 30 gleichzeitige Benutzer
16Way Sequent
Versicherung,
Oracle, 220GByte, denormalisierte Tabellen, 4 gleichzeitige Benutzer
24Knoten IBM-SP2
Telekommunikationsunternehmen,
Teradata, 600GByte, 35 Tabellen, 40 gleichzeitige Benutzer
NCR 5100M, 64Prozessoren
272 Kapitel 5 • Hardwarekomponenten und Netzinfrastrukturen

Die Wahl des richtigen Rechners kann auch aus der Sicht der Betriebssysteme
getroffen werden. Das heißt, zuerst wird das Betriebssystem bestimmt und
dann die Wahl des Rechners getroffen.
Für tiefere Einblicke in Rechnertypen und Rechnerarchitekturen sind interes-
sant:
 Hansen, Wirtschaftsinformatik
 Tanenbaum, Computerarchitektur

5.3 Bestimmung der Betriebssysteme


Problemstellung und Motivation
Ein Betriebssystem steuert alle Hardwarekomponenten und das Zusammen-
spiel zwischen Hardware und Software. Das Betriebssystem kann als Hardware
realisiert sein, in Form von Schaltkreisen, oder als Software auf einer Hardware
installiert sein. Die Betriebssystemsoftware ist die unmittelbare Schnittstelle
zur Hardware. D.h. jede Software kann nur über Betriebssystemfunktionen
Hardwarekomponenten ansprechen.
Mit der Rechnerauswahl ist prinzipiell auch eine Entscheidung für das einzu-
setzende Betriebssystem gefallen. Jeder Rechnertyp hat ein bevorzugtes
Betriebssystem bzw. eine eingeschränkte Auswahl von einsetzbaren Betriebs-
systemen. Besonders bei Großrechnern kann in der Regel genau je ein
Betriebssystem installiert werden. Auf einer DEC-VAX ist das VMS, auf einer
IBM-AS400 ist das AIX, auf einer HP-3000 ist das MPE. Bei einigen Arbeitsplatz-
rechnern ist das ebenso. Auf einem Next-Rechner ist dies das Betriebssystem
Next, auf einem RISC-Rechner ist das meistens ein UNIX-Derivat, auf einem
Apple ist das MacIntosh. Anders sind die Auswahlmöglichkeiten bei PCs. Auf
einem PC sind das OS/2, MS-Windows NT, MS-Windows 98, LINUX und andere.
Auf einigen Rechnertypen können alternativ verschiedene, aber nicht beliebige
Betriebssysteme installiert werden. Es können z.B. MS-Windows NT und MS-
Windows 98 unter LINUX, IBM-VM unter IBM-MVS, HP-UX unter HP-MPE
betrieben werden. Dies bedeutet, dass Software, die für das eine Betriebssystem,
das Gastsystem, entwickelt wurde, auch unter dem Wirtssystem eingesetzt wer-
den kann. Diese verschiedenen, gleichzeitig installierten Betriebssysteme kön-
nen allerdings nicht gleichberechtigt parallel betrieben werden und bringen
Performanceeinbußen mit sich. Das bedeutet, ein Betriebssystemwechsel ist
nur bei Neuinstallation aller Programme inklusive Betriebssystem möglich.
Für einige Betriebssysteme gibt es auch die Möglichkeit, ein zweites Betriebs-
system, ein Gastbetriebssystem, als sogenannte »Emulation« unter dem Wirts-
betriebssystem zu betreiben.
Kapitel 5 • Hardwarekomponenten und Netzinfrastrukturen 273

Bei einigen Großrechnern ist auch die Umschaltung des Betriebes von einem
Betriebssystem auf ein zweites Betriebssystem möglich. Damit sind dann
andere Programme betriebsfähig gestellt. Ob dies bei laufendem Betrieb mög-
lich ist, hängt auch von der Anzahl der Prozessoren ab.
Welche der Möglichkeiten auch immer gewählt wird, mit der Auswahl der
Rechner sind die Möglichkeiten der Betriebssystemauswahl eingeschränkt wor-
den. Dies motiviert die Frage, ob nicht zuerst die Entscheidung für ein oder
mehrere Betriebssysteme getroffen werden sollte, um daraus erst die Entschei-
dung für den passenden Rechner abzuleiten. Die hier zu lösende Gestaltungs-
aufgabe hätte demnach die Frage nach dem richtigen Betriebssystem, vor der
Frage nach dem richtigen Rechner stellen können. Für die Fragestellung »Auf-
bau eines DWH« ist allerdings weniger die Funktionalität eines Betriebssystems
maßgebend als vielmehr die Leistungsfähigkeit von Rechnern. Ein leistungs-
schwacher Rechnertyp mit einem guten Betriebsystem ist für den Anwender
aus Performancegründen ineffizient.
Ausgewählte Eigenschaften des Betriebssystems
Alle Betriebssysteme haben eine Mindestausstattung an Funktionen. Diese die-
nen zur Erkennung der Hardware, zur Installation von Software, zur Einstel-
lung von Rechnerverhaltensweisen, zu Speichermanagement und Datensiche-
rung, Ein- und Ausgabesteuerung, Abwicklung der Verarbeitungsprozesse,
Verwaltung der Dateien zu Programmen und Daten, Erteilung von Zugriffsbe-
rechtigungen und Anbindung an externe Rechner- und Rechnernetze. Wesent-
liche Kriterien zur Auswahl sind:
Robustheit Wesentlich für die Verfügbarkeit der Applikationen
und das schnelle Aufspüren von Fehlern ist die
Betriebsstabilität des Betriebssystems, die Robust-
heit. Hierzu gehört die weitestgehende Absturzfrei-
heit, die Einschränkung von Abstürzen auf ein
verursachendes Programm unter Erhaltung des
Betriebes aller anderen Programme (z.B. bei
Windows 95 nicht gegeben) und die Selbstreini-
gung bei Abstürzen von Datei-Fragmenten und
Zuordnungen.
Multitaskingfähigkeit Wenn mehrere Benutzer auf einem Rechner arbei-
ten, dann sollte es auch möglich sein, dies mit ver-
schiedenen Programmen zu erlauben. Der Betrieb
mehrerer Programme zur gleichen Zeit kann auch
für mindestens einen Anwender erlaubt werden. In
beiden Fällen spricht man von Multitaskingfähig-
keit. Wenn die Tasks des Betriebssystems von ver-
schiedenen Benutzern, von verschiedenen Rech-
nern bestellt werden können, spricht man von der
Multiuserfähigkeit eines Betriebssystem. Dies
274 Kapitel 5 • Hardwarekomponenten und Netzinfrastrukturen

erlaubt den Betrieb von Anwendungssoftware bei


konkurrierenden Benutzerzugriffen. Für die PCs
war früher nur Single-User-Betrieb (MS-DOS, MS-
Windows) interessant, weil man sagte, ein PC steht
auf einem Arbeitsplatz einem User zur Verfügung.
Mittlerweile sind PCs wesentlich leistungsfähiger
geworden und werden jetzt auch als Applikations-
server für den Zugriff mehrerer User eingesetzt
(MS-Windows NT). Die Anzahl der gleichzeitig
arbeitenden Benutzer kann derzeit je nach
Betriebssystem und Rechner von einem bis zu
10.000 reichen.
Betriebsart Vor der Fähigkeit, mehrere Benutzer zu versorgen,
steht die Eigenschaft, im Dialog mit einem Benut-
zer zu arbeiten. Diese Betriebsart wird Dialogbe-
trieb genannt. Damit ist das Befehl-Reaktion-Wech-
selspiel zwischen Computer und Anwender
gemeint, also das Erteilen direkt ausführbarer
Befehle an den Rechner, das prompte Ausführen
von Programmabschnitten auf die Aktionen eines
Benutzers durch den Rechner, das prompte Anzei-
gen des Ergebnisses und das Warten auf weitere
Anweisungen. Der Gegensatz hierzu ist der Batch-
betrieb. Ein Programm wird mit allen Daten dem
Rechner zur Abarbeitung zur Verfügung gestellt,
der Rechner rechnet zu einem günstigen Zeitpunkt
und speichert die Ergebnisse in einer Datei ab.
Diese Art der Verarbeitung ist nützlich für aufwän-
dige Rechnungen mit langer Wartezeit, wie z.B.
Wetterprognosen, Filmsequenzen, Festigkeitsbe-
rechnungen.
Performance Jedes Betriebssystem ist für einen bestimmten Pro-
zessortyp ausgelegt. Der Einsatz auf einem anderen
Prozessor bringt Einbußen in der Verarbeitungsge-
schwindigkeit oder Performance. Das Zusammen-
spiel von Zielprozessor und Betriebssystem kann
anhand von genormten Leistungstests, sogenann-
ten Benchmarktests, gemessen werden. Tests die-
ser Art werden unregelmäßig in der Presse und im
Internet veröffentlicht. Dies ist zwar ein Hinweis,
lässt aber noch keinen 100 Prozent sicheren
Schluss auf die Performance eines Anwendungspro-
grammes zu. Bei der Beschaffungsentscheidung
sollte, wenn die Anwendungssoftware feststeht, eine
vergleichende Testinstallation auf den in Frage
Kapitel 5 • Hardwarekomponenten und Netzinfrastrukturen 275

kommenden Maschinen die Performance-Beurtei-


lung untermauern.
Parallelität Der Betrieb mehrerer Prozessoren und die Vertei-
lung von Programmen, Unterprogrammen und
Teilberechnungen auf jeweils unausgelastete Pro-
zessoren, dynamisch während des Betriebes durch
ein Betriebssystem, ist die Parallelverarbeitung. Die
derzeitigen Betriebssysteme können diese Parallel-
verarbeitung auf den Prozessoren innerhalb eines
Rechners oder sogar zwischen einer in einem
Schrank mit einem Mininetz gekoppelten Rechner-
gruppe (z.B. IBM-SP2-Rack) organisieren. Neu sind
Bestrebungen, ein Betriebssystem zu etablieren,
das über eine Auswahl beliebiger freiwilliger Rech-
ner im Internet eine Applikation verteilt und aus-
führen lässt.
Skalierbarkeit Mit der Skalierbarkeit ist die Fähigkeit des
Betriebssystems definiert, weitere Hardwarekompo-
nenten in das System zu integrieren. Dies sind z.B.
weitere Speichersysteme, zusätzliche Prozessoren,
größere interne Speicher, zusätzliche Ausgabege-
räte. Diese Eigenschaft ist besonders für DWH inte-
ressant, da das Wachstum der Daten überproportio-
nal sein kann und das Interesse der Benutzer
sprunghaft ansteigen kann.
Internationalität Sehr oft wird ein DWH über viele Länder mit unter-
schiedlichen Sprachen, Währungen und Zeichen-
sätzen eingesetzt. Die Fähigkeit des Betriebssys-
tems, sich mit Tastaturbelegung, Präsentation
nationaler Zeichensätze, Sprachumschaltung an die
Gepflogenheiten verschiedener Nationen anzupas-
sen, heißt Internationalität.
Verbreitung Ein wesentliches Kriterium ist die Verbreitung oder
der Marktanteil des Produkts. Große Marktanteile
sind ein Indiz für langes Leben. Das Betriebssystem,
das sich über alle RISC-Rechnerhersteller am brei-
testen durchgesetzt hat, ist UNIX, bzw. weitestge-
hend kompatible UNIX-Derivate. Die Betriebssys-
teme mit den höchsten Installationszahlen sind die
PC-Betriebssysteme MS-Windows NT, MS-Windows
3.1, MS-Windows 95, MS-Windows 98. Dies nur, um
ausgewählte Aspekte der Homogenität (minimale
Herstellerzahl, minimale Produkte, meisteinge-
setzte Produkte) anzudeuten. Betriebssysteme
276 Kapitel 5 • Hardwarekomponenten und Netzinfrastrukturen

haben ein Erscheinungsbild auf dem Monitor des


Rechners. Ein Homogenitätsaspekt ist die weitge-
hende Übereinstimmung der Befehlseingabe, Sym-
bolisierung von Befehlen und Führung des Benut-
zers über verschiedene Betriebssysteme.
Softwareumfang Große Verbreitung zieht auch meistens eine große
Auswahl von Software, die dieses Betriebssystem
zur Plattform gewählt hat, nach sich. Ein weitver-
breitetes Betriebssystem einzusetzen heißt dann
unter anderem, eine große Auswahlmöglichkeit,
den Softwareumfang, von Anwendungssoftware
vorzufinden.
Homogenität Die Homogenität ist eine Eigenschaft, die einer
Gruppe von Betriebssystemen zukommt. Kein
Unternehmen kann in der Regel mit nur einem
Betriebssystem auskommen, da es verschiedene
Rechnertypen einsetzen muss. Eine möglichst
geringe Anzahl von Herstellern und Betriebssyste-
men ist hier die Zielsetzung. DEC hat z.B. mit VMS
ein Betriebssystem geschaffen, das über alle Rech-
nerkategorien von DEC eingesetzt werden kann,
außer auf dem PC.
Funktionsumfang Wie jede Software erfüllt auch ein Betriebssystem
bestimmte Aufgaben in Form von Funktionen,
Unterprogrammen, Komponenten, Modulen, mit-
tels seines Funktionsumfangs. Solche Funktionen
sind z.B. Erkennung der Hardware zur Installation
von Software, zur Einstellung von Rechnerverhal-
tensweisen, Speichermanagement und Datensiche-
rung, Ein- und Ausgabesteuerung, Abwicklung der
Verarbeitungsprozesse, Verwaltung der Dateien zu
Programmen und Daten, Erteilung von Zugriffsbe-
rechtigungen, Anbindung an externe Rechner- und
Rechnernetze, Kommunikation mit anderen Benut-
zern, Anzeige der Stromversorgung. Alle genannten
Funktionen sind zu Komponenten und Modulen
gruppiert und stellen eine Betriebssystem-Architek-
tur dar.
Utilities
Kein Betriebssystem ist vollständig. Das heißt, nicht alle Funktionen, die für
die Analyse des Rechnerzustandes und für die Rückführung des Systems auf
einen erwünschten Zustand erforderlich sind, sind in einem Betriebssystem
Kapitel 5 • Hardwarekomponenten und Netzinfrastrukturen 277

enthalten. Aber man kann die Funktionalität erweitern, indem man sogenannte
Utilities installiert. Solche Utilities umfassen z.B.
✔ das Dateimanagement mit Suchen verlorengegangener Dateien, Wiederher-
stellen versehentlich gelöschter Dateien, Löschen nichtgebrauchter Dateif-
ragmente
✔ die Hardwarediagnose mit Aufdecken von physikalischen Fehlern, funktio-
nalen Einschränkungen;
die Leistungsfähigkeit wird am Umfang der unterstützten Hardwarepalette
gemessen
✔ das Systemmanagement mit Monitoring angeschlossener Hardwarekompo-
nenten, Meldung von angesprochenen, aber nicht erreichbaren Komponen-
ten;
die Leistungsfähigkeit wird am Umfang der unterstützten Hard- und Soft-
warekomponenten gemessen
✔ die Datensicherung mit planmäßiger automatischer Auslagerung und
Archivierung oder Replikation
✔ Systemoptimierung, Tuning und Parametereinstellung, Komprimierung
und Dekomprimierung
Die meisten Utilities-Funktionen sind, unabhängig von der eingesetzten Soft-
ware und Hardware, für alle Systeme nützlich. Es gibt allerdings auch Utilities,
die nur auf bestimmte Hardwareprodukte und auf bestimmte Softwareprodukte
wirken. Mit dem Aufbau eines Data Warehouse und der Beschaffung damit ver-
bundener neuer Software- und Hardwareprodukte werden auch weitere Utili-
ties benötigt.

Gestaltungs- und Lösungsmöglichkeiten


Einige Anwendungsprogramme sind nur auf einem Betriebssystem lauffähig.
Aber die meisten der auf dem Markt angebotenen Softwareprodukte lassen eine
Installation auf mehreren oder mittels mehrerer Betriebssysteme zu. Um nicht
mit einem Sammelsurium von diversen verschiedenen Betriebssystemen den
Aufwand für Qualifikation und Betrieb unnötig zu vergrößern, ist eine Verein-
heitlichung der Betriebssystemvielfalt durch Definition eines Betriebssystem-
standards zu empfehlen.
➢ Definition eines Betriebssystemstandards
Die Suche nach Softwareprodukten des Marktes kann nun bei ähnlichen Soft-
wareprodukten bevorzugt auf die Standard-Betriebssysteme des Unternehmens
fokussiert werden.
➢ Einschätzung des Softwaremarktes der DWH-Komponenten bezüglich der
Betriebssystemauswahl
➢ Bestimmung der für die jeweiligen feststehenden DWH-Softwarekomponen-
ten möglichen Betriebssysteme
278 Kapitel 5 • Hardwarekomponenten und Netzinfrastrukturen

Erfahrungsgemäß können Unternehmen bei Releasewechseln nicht alle einge-


setzten Betriebssysteme gleichzeitig und niemals vollständig durch neue
Releases ablösen. Dies liegt an der Willenskraft der Systemadministratoren und
an der Verfügbarkeit der Anwender (Auslandseinsatz, Termindichte, Krankheit).
Viele Anwender haben sich eigene Programme geschrieben, die auf Eigenschaf-
ten der vorhandenen Betriebssysteme angewiesen sind und keinen Release-
wechsel vertragen würden.
➢ Festlegung des Releasestandes
Viele der Utilities-Funktionen sind für alle Systeme gleichermaßen nützlich
und bereits im Unternehmen vorhanden. Einige der Utilities-Funktionen wer-
den erst mit der Einführung von Data Warehouse Komponenten interessant.
➢ Bestimmung der zusätzlich zum Betriebssystem erforderlichen Utilities-
Funktionen

Problemlösung: Regeln und Hilfsmittel


Das Verfahren
Für die Entscheidung der bevorzugten Betriebssysteme ist die augenblickliche
Situation des Unternehmens zu berücksichtigen. Ein etabliertes Betriebssys-
tem sollte nicht ohne weiteres in Frage gestellt werden, sondern Anhaltspunkt
für die Softwarewahl sein. Die Einführung eines weiteren Betriebssystems
bringt neuen Schulungsaufwand, erneute Zeit des Sammelns von Erfahrungen
mit den noch unbekannten Verhaltensweisen und auch Personalneueinstellun-
gen mit sich. Der Verwaltungsaufwand wird mit jedem zusätzlichen Betriebs-
system erhöht durch eine umfangreichere und kompliziertere Release- und
Update-Organisation.
Oftmals sind die Betriebssysteme der Arbeitsplätze bereits durch einen Unter-
nehmensstandard festgelegt, dann ist keine Betriebssystementscheidung zu
treffen.
Serverseitig können die Rechner für den Einsatz der DWH schon vorhanden
und mit einem bestimmten Betriebssystem ausgestattet sein, auch dann ist
keine Betriebssystementscheidung mehr zu treffen.
Ist bereits das DWH-Tool ausgesucht, dann ist auch die Plattformwahl auf die
Optionen des ausgewählten Produkts eingeschränkt. Es ist ebenfalls keine
Betriebssystementscheidung zu treffen, wenn die einzusetzende Anwendungs-
Software nur auf einem Betriebssystem lauffähig ist und keine Alternative zu
dieser Anwendungs-Software möglich ist.
Zur Auswahl des Betriebssystems ist folgendes Verfahren nützlich.
Kapitel 5 • Hardwarekomponenten und Netzinfrastrukturen 279

Verfahren: Bestimmung der Anforderungen an DWH- Betriebssysteme


❖ Feststellung der eingesetzten Betriebssysteme
Definition einer Einsatzstrategie für Betriebssysteme (Homogenität, Her-
stellerunabhängigkeit, relativer Release-Stand)
❖ Betriebsbedingungen durch ausgewählte Softwarekomponenten
❖ Setzung von Rahmenbedingungen für die Betriebssystemwahl
❖ Definition und Gewichtung der Kriterien zur Auswahl mittels der
Kriterienliste Betriebssystem
Robustheit, Multitaskingfähigkeit, Parallelität, Multiuser-Fähigkeit
Verbreitungsgrad, Softwareumfang
Funktionalität
Homogenität
❖ Verschaffung eines Marktüberblickes über Produkte, Funktionalität,
Releasestände und Tendenzen von Betriebssystemen mittels der Kriteri-
ensynopse Betriebssysteme
❖ Feststellen der zusätzlich zum Betriebssystem erforderlichen Utilities-
Funktionen, Verschaffung eines Marktüberblickes über Produkte

Rahmenentscheidungen für Betriebssysteme


Gegenüber dem linearen Durcharbeiten aller Leistungskriterien des Betriebs-
systems kann man auch selektiv vorgehen und zunächst eine Rahmenentschei-
dung treffen. Diese wird für die Leistungskriterien eine unterschiedliche
Gewichtung bewirken. Die erste Rahmenentscheidung könnte hier lauten,
✔ dasjenige Betriebssystem auszuwählen, das die größte Palette an Applikatio-
nen unterstützt.
Dazu gehört z.B. NT, Windows 95 aber auch UNIX, je nach Rechnergröße. Im
DWH-Markt haben sich die Hersteller Client-seitig, also z.B. bezüglich der
Auswertungstools, auf die Microsoft Betriebssysteme focussiert. Der DWH-
Spezialist kann, wenn er die Entscheidung Betriebssystem vor der Entschei-
dung »DWH-Software« treffen will, die Evaluation auf die unter NT laufenden
DWH-Komponenten einschränken.
Eine andere Rahmenentscheidung kann sein,
✔ das neue Betriebssystem homogen in die bestehende IT-Landschaft zu inte-
grieren,
das heißt z.B., die Ergonomie für die Anwender gleich oder ähnlich zu halten.
Bei bestehendem Windows 95 ist die Homogenität mit NT höher als mit
Macintosh oder Next.
280 Kapitel 5 • Hardwarekomponenten und Netzinfrastrukturen

Kriterienliste Betriebssystem
In der folgenden Tabelle sind die Kriterien der Betriebssysteme mit einigen aus-
gewählten charakterisierenden Eigenschaften in der Reihenfolge steigender
Leistungsfähigkeit dargestellt.

Kriterium Charakteristik

Robustheit Ereignisprotokollierung, Früherkennung von Konflikten,


kontrolliertes Herunterfahren, automatisches Reboot

Multitasking Singletasking, Multithreading, Multitasking, Multiusing, Multiusing


hoher Benutzerzahlen

Betriebsart Dialogbetrieb, Batchbetrieb

Performance Rechentakt des Prozessors, Cachinggröße

Parallelität Prozessorentyp, Prozessorenanzahl, verschiedene Rechner,


entfernte Rechner, Aufgabendifferenzierung

Skalierbarkeit Plug-and-Play-Peripherie, erweiterbare Hauptspeicher, Kapazität


der Massenspeichererweiterung

Internationalität Monolingual, Englisch/Deutsch-Umschaltung, Lexika, Multilingual,


Unicode

Verbreitung National, weltweit

Funktionaler Umfang Editoren, integrierte grafische Oberfläche, Emulation, Utilities

Softwareauswahl Standard, Betriebswirtschaft, Tools

Homogenität Zu den vorhandenen Betriebssystemen

Tabelle 5.6: Kriterienliste Betriebssystem

Kriteriensynopse Betriebssysteme
Besteht Entscheidungsfreiheit in der Wahl des Betriebssystems,
✔ ist kein Rechner- oder Betriebssystemstandard festgestellt,
✔ sind die bereits getroffenen Entscheidung für bestimmte DWH-Komponen-
ten nicht bindend
✔ und auch das Standardbetriebssystem des Unternehmens nicht zwingend.
Besteht Entscheidungsfreiheit für ein Betriebssystem, werden die oben darge-
stellten Kriterien der Reihe nach analysiert. Ein Unternehmen, das alle Frei-
heitsgrade in der Auswahl offen lässt, benötigt eine Gegenüberstellung der zum
Teil im Konflikt zueinander stehenden Leistungsmerkmale der verschiedenen
Betriebssysteme, eine Kriteriensynopse Betriebssysteme. Eine solche Synopse
ist als Hilfsmittel im Folgenden dargestellt.
Kapitel 5 • Hardwarekomponenten und Netzinfrastrukturen 281

g
tät fan
rm ce eit nali um
it g o t rk g ng
e i n s f a n i t ä a i o n s f n
a tu
u sth tius rieb o rm l lel l i er
b
r n at
k tio -Um brei
b l t r f r a a e n r
Typ Ro Mu Be Pe Pa Sk Int Fu SW Ve
Personals
Organizer
W-CE
Pilot
Casio
PDA
W-CE
Psion
Sharp
Arbeitsplatz
PC, Notebook
W95/98
W2000
NT
MacOS
OS/2
NEXT
LINUX
WS
NT
LINUX
UNIX
Server
WS
NT
UNIX
Minirechner
VMS
MPE
UNIX
Großrechner
MVS
MPE

Tabelle 5.7: Kriteriensynopse Betriebssysteme

Rechnerentscheidung und Betriebssystemkonsequenzen


In der Regel fordert die einzusetzende Software zwar keinen Rechner, aber
bestimmte Betriebssystemalternativen. Das Betriebssystem schränkt die Aus-
wahl unter bestimmten Rechnertypen ein. Hierbei ist zu empfehlen, »reinras-
sig« zu bleiben, das heißt, keine verschiedene Betriebssysteme fordernden Pro-
gramme auf einer Plattform zu betreiben, da dies immer Stabilitätsprobleme
und Performanceverluste verursacht.
Wird die Rechnerentscheidung vorgezogen, ist auch das Betriebssystem weitge-
hend festgelegt, obwohl
✔ auf einem Rechner wahlweise verschiedene Betriebssysteme (z.B. OS/2 und
NT und DOS) installiert werden können,
282 Kapitel 5 • Hardwarekomponenten und Netzinfrastrukturen

✔ unter einem Betriebssystem andere Betriebssysteme simuliert werden kön-


nen (MS-Windows unter UNIX),
✔ bei einem Großrechner von IBM die Simulation des Gastbetriebssystem
sogar gleichzeitig mit dem Wirtsbetriebssystem im Timesharing betrieben
werden kann.
Bezüglich der Großrechnersysteme soll noch darauf hingewiesen werden, dass
diese teilweise in einem eigenen (proprietären) Netzbetriebssystem betrieben
werden. Die Rechnerauswahl hat damit Konsequenzen für die Netzgestaltung.
Sie hat außerdem Konsequenzen für die Softwareauswahl, die sich auf die für
das Betriebssystem lauffähige Software beschränken muss. Für die sogenann-
ten Superrechner und Großrechner oder Hosts ist die Softwareauswahl wesent-
lich kleiner als für UNIX-Systeme.

5.4 Bestimmung der Peripheriekomponenten


Problemstellung und Motivation
Ein Rechner für sich alleine genommen bietet nur ein Potential, Informationen
zu verarbeiten. Es bedarf einer Aktivierung dieser Fähigkeiten und der Bereit-
stellung von »Rohinformationen« zur Verarbeitung durch eine Eingabe mittels
Eingabegeräten. Das Ergebnis der Verarbeitung wird nicht unbedingt in Real-
zeit wieder verwendet, sondern es wird sehr oft viel später, manchmal erst nach
Jahren, gebraucht. Das Verarbeitungsergebnis muss dauerhaft oder vorüberge-
hend aufbewahrt, d.h. gespeichert werden. Ein Rechner benötigt hierfür Spei-
chergeräte. Die Informationen müssen in einer verständlichen und gut wahr-
nehmbaren Form zur Verfügung gestellt werden können. Die Aufbereitung der
Informationen für die Sinnesfähigkeiten des Menschen erfordert Ausgabegeräte.
Eingabe
Eingabegeräte sind so vielfältig wie die Handlungsformen und Nutzungsge-
wohnheiten der Menschen. Die Rechner werden über Eingabegeräte bedient. Je
nach der Art des Mediums, das die Daten gespeichert hat, sind andere Eingabe-
geräte erforderlich. Je nach Art der Daten sind andere Medien geeignet. Texte
können mit Scannern eingelesen und als Text erkannt werden, oder aber über
eine Tastatur eingetippt werden, oder mittels Stift auf einem Touchscreen auf-
gezeichnet werden. Sprache kann mittels Mikrofon akustisch aufgezeichnet
und mit Spracherkennungsprogrammen in Texte konvertiert werden. Statische
Bilder werden eingescannt, bewegte Bilder werden mit Filmkameras aufge-
zeichnet.
Beispiele für Eingabegeräte sind in der folgenden Checkliste Eingabegeräte
aufgeführt.
Kapitel 5 • Hardwarekomponenten und Netzinfrastrukturen 283

Speichermedium Kriterien der Auswahl

Tastatur Anbindung, Tastendruck, Tastenanzahl, Belegung


Nummernblock Anbindung, Tastendruck
Maus Übertragungsgenauigkeit, Empfindlichkeit
Touchpad Übertragungsgenauigkeit, Empfindlichkeit
Grafiktablett Übertragungsgenauigkeit, Empfindlichkeit, Blattgröße
Zeichenbrett Übertragungsgenauigkeit, Empfindlichkeit, Blattgröße
Elektronischer Stift Übertragungsgenauigkeit, Empfindlichkeit
Barcode-Leser Empfindlichkeit, Erkennung
Datenhandschuh Übertragungsgenauigkeit, Empfindlichkeit
Scanner, Faxmodem Auflösung, Geschwindigkeit, Größe, Anschluss

Sensoren physikalische Eigenschaften, chemische Eigenschaften,


Empfindlichkeit, Genauigkeit
Mikrofon Empfindlichkeit, Frequenzgang
Klaviertastatur Anbindung, Tastendruck,
Digitale Fotokamera Auflösung, Empfindlichkeit, Funktionalität
Digitale Filmkamera Auflösung, Empfindlichkeit, Funktionalität
Fernsehempfangstuner Funktionalität, Sendertypen

Tabelle 5.8: Checkliste Eingabegeräte

Speicherung, Aufbewahrung
Zur Speicherung von Daten ist so ziemlich alles, was die Natur bietet, von Inte-
resse für die Technologen – vom künstlichen chemischen Molekül zum Biomo-
lekül, von Atomen bis zu Hologrammen und zu Halbleitern. Die Aufzeichnung
einer Videokamera kann z.B. magnetisch auf Videoband, elektrisch in einem
Speicherchip oder optisch auf CD festgehalten werden.
Beispiele für Speichermedien sind in der folgenden Checkliste Speichermedien
aufgeführt.

Speichermedium Kriterien der Auswahl

Floppy-Disk Dichte, Speichermenge, Seitenzahl


Festplatte Speichermenge, Zugriffszeit, Austauschbarkeit
PCMCIA-Flashcard Speichermenge, Zugriffszeit, Einbauhöhe
CD-ROM, CD-RW Zugriffszeit, Speichergröße, Überschreibbarkeit, Format
DVD Zugriffszeit, Speichergröße, Format
Digitalband Zugriffszeit, Speichergröße
Halbleiterspeicher Zugriffszeit, Speichergröße
Hologramm Haltbarkeit, Dreidimensionalität

Tabelle 5.9: Checkliste Speichermedien


284 Kapitel 5 • Hardwarekomponenten und Netzinfrastrukturen

Ausgabe
Ausgabegeräte sind so vielfältig wie die Sinnesausstattung der Menschen. Kom-
plizierte Strichzeichnungen, wie Konstruktionspläne von Architekten und
Ingenieuren, werden auf Papierrollen von Plottern gezeichnet. Videosequenzen
können mit dem Licht der Beamer oder LCD-Overhead-Aufsatz auf Leinwand
projiziert werden.
Die Möglichkeiten der peripheren Komponenten sind vielfältig und bedürfen
einer sorgfältigen Wahl, die nicht zuletzt auch das Kriterium Kosten berück-
sichtigen muss. Die Auswahl dieser Komponenten ist nicht die Aufgabe des
DWH-Spezialisten, aber eine Gestaltungsaufgabe für einen kompletten DWH-
Arbeitsplatz. Deshalb wird das Thema nur der Vollständigkeit halber, und als
Gelegenheit zur Anregung der Zusammenarbeit der IT-Beschaffer und Nutzer-
services mit dem DWH-Spezialisten, gestreift. Beispiele für Ausgabegeräte sind
in der folgenden Checkliste Ausgabegeräte aufgeführt.

Objekt Kriterien der Auswahl

Drucker Druckgeschwindigkeit, Farbe, Blattanzahl


Faxgerät Druckgeschwindigkeit, Farbe, Blattanzahl
Plotter Druckgeschwindigkeit, Farbe, Blattanzahl
Kopierer Kopiergeschwindigkeit, Farbe, Blattanzahl, Kopierfunktionen
Kopfhörer, Lautsprecher Frequenzspektrum, Leistung
Monitor, Fernsehgerät Schärfe, Helligkeit, Farbtreue
Overhead-LCD-Display Schärfe, Helligkeit, Farbtreue
Videobeamer Schärfe, Leistung, Farbtreue
Videobrille Schärfe, Helligkeit, Farbtreue

Tabelle 5.10: Checkliste Ausgabegeräte

Schnittstellen
Im Rechner selbst findet der Transport der Daten über Adress- und Datenbusse
statt. Der Transport an Außeneinheiten geht über Schnittstellen des Rechners,
Schnittstellen der Außengeräte und ein verbindendes Transportmedium. Bei-
spiele für Schnittstellen sind in der folgenden Checkliste Schnittstellen aufge-
führt.

Objekt Kriterien der Auswahl

Centronics Durchsatz, Gerät: Drucker


RS 232 Durchsatz, Gerät: Drucker, Scanner
IrDA Durchsatz, Gerät: Infrarot-Übertragung
IEEE-1394 Durchsatz, Gerät: Videokamera
PCMCIA Durchsatz, Gerät: GSM-Handy, CD-ROM-Laufwerk
USB Durchsatz, Gerät: Geräte wie Drucker, Scanner, Fax
V.90 Modem Durchsatz, Gerät: Kommunikationsgeräte

Tabelle 5.11: Checkliste Schnittstellen


Kapitel 5 • Hardwarekomponenten und Netzinfrastrukturen 285

Zu den physischen Schnittstellen sind immer auch Programme, sogenannte


Treiber, erforderlich. Diese dienen zur Konfiguration der jeweiligen Schnitt-
stelle und zur Wandlung der physischen Form der Daten, um über ein Medium
wie Kabel oder Luft bewegt werden zu können, wie z.B. bei Infrarot- oder
Funkübertragung.
Transportmedium
Das Transportmedium für Informationen ist z.B. eine Leitung mit allen Fähig-
keiten und auch eine Person, die z.B. ein Speichermedium von einem Rechner
zu einem anderen trägt.
Beispiele für Transportmedien sind in der folgenden Checkliste Transportme-
dien aufgeführt.

Objekt Kriterien der Auswahl

Kupferkabel elektrische Impulse, Telefonleitung, Stromleitung, Cat5


Koaxialkabel z.B. Fernsehkabel, Ethernet-Kabel
Infrarotwellen Leistung, Frequenz, Formerkennung
Glasfaser und Lichtimpulse Anzahl, Bandbreite, Formerkennung
Elektromagnetische Wellen Funk, GSM, Richtfunk, Satellitenverbindung
Akustische Wellen Signale

Tabelle 5.12: Checkliste Transportmedien

Gestaltungs- und Lösungsmöglichkeiten


Zu einer vollständigen Konfiguration eines DWH-Arbeitsplatzes gehört eine
Aufzählung und teilweise eine Spezifizierung aller Ausgabekomponenten, Ein-
gabekomponenten, Speichermedien und Transportarten. Spezifizierung ist z.B.
nötig für ein Fax-Modem, das in unterschiedlichen Übertragungsraten von
9.600 bis 56.000 und mehr Bit/Sekunde gefertigt wird. Diese unterschiedlichen
Leistungen sind unterschiedlich teuer, deshalb ist eine Überlegung zum
Kosten/Nutzen-Verhältnis angebracht.
Die einsetzbaren Peripheriekomponenten sind von der Ausstattung des Arbeits-
platzrechners, seiner Lokation und seiner Einbindung in ein Netz, abhängig.
➢ Bestimmung der Lokation, Netzeinbindung und Ausstattung des Arbeits-
platzrechners der Anwender
Auch Peripheriekomponenten werden durch Leistungsdaten charakterisiert. Je
leistungsfähiger sie sind, desto teuerer sind sie zu erwerben. Hier gilt es, ein
optimales Preis-Leistungsverhältnis zu ermitteln.
➢ Bestimmung des Bedarfes und der Leistungsspezifikation der Peripherie-
komponenten
286 Kapitel 5 • Hardwarekomponenten und Netzinfrastrukturen

Einige Peripheriekomponenten sind so teuer, dass sie sich erst bei Benutzung
durch einen größeren Anwenderkreis amortisieren. Es ist also die Entschei-
dung zu treffen, ob mobil oder stationär am Arbeitsplatz, stationär an der Loka-
tion oder entfernt zugegriffen werden muss. Daneben ist zu beachten, daß die
Einsatzorte erhöhte Flexibilität der Ausrüstung der Mitarbeiter eines Unterneh-
mens fordern. Der Arbeitsplatz ist nicht mehr uneingeschränkt als stationär
einzuordnen. Die Frage, ob mobiler oder stationärer Einsatz erforderlich ist, ist
zu beantworten.
➢ Kriterien zur Beurteilung der Lokation und Mobilität der Peripherie

Problemlösung: Regeln und Hilfsmittel


Das Verfahren
Die Entscheidung der Peripherieausstattung lässt sich über den Bedarf, der aus
der Arbeitsplatzbeschreibung oder der Stellenbeschreibung hervorgeht, und
aus der angestrebten Applikationsverteilung ableiten. Als Entscheidungshilfe
kann eine Checkliste Peripheriekomponenten, wie sie am Anfang dieses Kapi-
tels kurz und auszugsweise aufgelistet wurde, ergänzt mit Typen und Varianten,
dienen. Die genaue Spezifikation der Peripheriekomponenten ist nicht die Auf-
gabe des DWH-Managers, sondern dem Serviceteam und den Infrastrukturge-
staltern des Unternehmens angetragen.

Verfahren: Festlegung der Lokation der Peripheriekomponenten


❖ Bestimmung der Lokation, Netzeinbindung und Ausstattung des Arbeits-
platzrechners der Anwender
❖ Bestimmung des Bedarfes und der Leistungsspezifikation der Peripherie-
komponenten
❖ Kriterien zur Beurteilung der Lokation und Mobilität der Peripherie
(Netzbindung, mobil, stationär ungebunden)

Checkliste Allokation der Applikationen und Peripheriedienste


Eine gute Kontrolle für die ermittelte Ausstattung der Arbeitsplätze ist die Ana-
lyse der einem Arbeitsplatz zugeordneten Applikationen. Aus der Bedienung der
Applikationen kann auf den Bedarf an peripheren Geräten geschlossen werden.
So ist z.B. für ein CAD-Programm ein Grafiktablett als Eingabegerät und ein
Plotter als Ausgabegerät nützlich. Da ein Plotter in der Regel sehr teuer ist und
nicht nur durch eine Person ausgelastet ist, wird man den Plotter über einen
Netzanschluss zur Verfügung stellen. Für die Erfassung der Zuordnung der
Applikationen und die Ableitung der dafür erforderlichen Allokation der Peri-
pherie dient die Checkliste Allokation der Applikationen und Peripherie-
dienste.
Kapitel 5 • Hardwarekomponenten und Netzinfrastrukturen 287

Arbeitsplatz Applikation 1 Applikation 2 Applikation 3 Applikation 4 Applikation 5


Nr. XXX Office SSW DWH CAD CAE
Rechner
Rechner 1 Typ Typ Typ
mobil stationär mobil ---

Rechner 2 Typ
stationär stationär stationär stationär

Output
Drucker Typ
mobil mobil/stationär

Kopierer Typ stationär –


stationär

Plotter – stationär stationär

Fax mobil

Projektor

Lautsprecher

Input

Tableau

Video

Mikrofon

Scanner

Barcodeleser

Speicher

CD-R

PCMCIA

Tabelle 5.13: Muster: Allokations-Check Applikationen und Peripheriedienste

Schema der Arbeitsplatzintegration mit Peripheriekomponenten


In der Regel sind die Arbeitsplätze der DWH-Benutzer bereits vollständig ausge-
stattet. Heute übliche DWH-Applikationen erfordern keine besondere Periphe-
rie, die nicht schon durch normale Office-Applikationen vorhanden sein muss.
Für neue Arbeitsplätze bedeutet dies, dass auch die DWH-Ausstattung nach der
üblichen Arbeitsplatztypisierung vorgenommen werden kann. Die Anforderun-
gen können sich dann ändern, wenn unter DWH nicht nur die finanzwirtschaft-
lichen Informationen im Vordergrund des Interesses stehen, sondern das DWH
auch als Mittel für qualitative Daten, Industrieprozesse, Muster und Multimedia
genutzt wird. In beiden Fällen ist ein Schema der Arbeitsplatzintegration mit
Peripheriekomponenten von Nutzen.
288 Kapitel 5 • Hardwarekomponenten und Netzinfrastrukturen


  



 

  

  
  

  

   
 
 
 $

( 
 



   0 
 
 


 

$
     #
% '

  (  0
 &$  
 
  & 


 0
  %$

 (!!()
"
 (!!()   0333 456 "

 %$ 
  "  %$ 

" * 




( *  ( 


 " +


 &  0 1 +

# 
( 2(* # 

 + 
  /!+


   
    ! " #
! " # $!% &
$!% & $!% (
&  ' 
  $!%  $
$!% 75,  
&  ' 

 !    

 .,,'.,,
 

 !   

  ,



    



 ,(-%
 

 


  


"+$$

Abbildung 5.17: Schema der Arbeitsplatzintegration

5.5 Allokation der Softwarekomponenten


Problemstellung und Motivation
Nutzung
Software kann nur auf Rechnern zur Ausführung kommen. Der Zugang zur
Software ist an die Aufstellung von Rechnern gebunden. Mit der Platzierung
der Rechner ist zwar noch offen, wo die Softwarekomponenten zu installieren
sind, aber die Möglichkeiten, die Softwarekomponenten zu verteilen, sind auf
die Lokationen der Rechner eingeschränkt. Die Standorte der Rechner sind im
Kapitel 5 • Hardwarekomponenten und Netzinfrastrukturen 289

Hinblick auf die Standorte der Benutzer, den Personalmarkt und die Nähe der
Implemetierung der Funktionen ausgewählt worden.
Es ist zu unterscheiden, ob eine Softwarekomponente vielen Benutzern oder
nur einem einzigen Benutzer Dienste zur Verfügung stellen muss.
Die Nutzung kann dauerhaft zur Verfügung stehen oder bei Bedarf angefordert
werden. Es gibt Anmeldungszähler zur Lizenzüberwachung, welche die Lizen-
zenüberprüfung nicht auf die Zahl der gemeldeten Benutzer bezieht, sondern
auf die Zahl der gleichzeitig arbeitenden Benutzer. Nutzung von Lizenzen kos-
tet Geld, ebenso kostet ein auf Grund starker Nutzungsannahmen leistungsfä-
hig ausgebauter Rechner mehr Geld als ein leistungsschwach bestückter Rech-
ner. Die bereitgestellte Verfügbarkeit muss daher in vernünftigem Verhältnis
zur Nutzung stehen.
Folgende Nutzungsvarianten sind zu unterscheiden
✔ nach der Nutzungsdauer: kontinuierlich, periodisch, fallweise, spontan
✔ nach dem Nutzungsort: entfernt, am Ort
✔ nach der Zeiteinteilung: alleinberechtigt, gruppenberechtigt,
Zeitfenster-berechtigt
✔ nach dem Besitzverhältnis: gemietete Lizenz, gekaufte Lizenz,
Eigentum
Verteilung
Um die einzelnen Komponenten einer Software gemäß der Anwendernachfrage
besser positionieren zu können, wurde die Client/Server-Architektur entwi-
ckelt. Die Client/Server-Architektur teilt die Programme in einen Teil, der auf
dem Endgerät des Benutzers abläuft und einen Teil, der auf einem allen Usern
zugänglichen Server abläuft. Dies bedeutet eine Entlastung des Servers, da ja
einige Berechnungen oder Programmausführungen vom Server auf das Endge-
rät abgegeben werden können. Es wäre zum Beispiel nicht möglich bzw. nicht
sinnvoll, die grafischen Benutzeroberflächen aller Benutzer auf einem zentra-
len Rechner verarbeiten zu lassen, um das Ergebnis auf einem Terminal anzu-
zeigen. Jede neue Bewegung eines grafischen Elementes, wie z.B. Mausklick auf
einen Button, würde eine erneute entfernte Berechnung erfordern. Neben der
Rechenlast der Server ist deshalb noch die Kommunikationslast der Leitungen
ein Grund, den Datenverkehr zu minimieren, und dies geschieht eben auch
durch die Möglichkeit, die Masken direkt auf dem Endgerät zu erzeugen, anstatt
sie als grafische Präsentation zu versenden. Mit dem Prinzip der Client/Server-
Architektur, Programme in verteilbare Komponenten aufzusplitten, ist dann als
Fortsetzung der Idee der zweistufigen Verteilung noch die Idee zur mehrstufi-
gen Verteilung verwirklicht worden. Die Verteilbarkeit ermöglicht eine auf die
Programmkomponente gezielt ausgerichtete Rechnerkonfiguration.
Ein weiterer Aspekt der Verteilung ist die effiziente Kooperation der DWH-
Komponenten mit Standardprogrammen des Arbeitsplatzrechners. Mit anderen
290 Kapitel 5 • Hardwarekomponenten und Netzinfrastrukturen

Worten, zu einer vollständigen Ausstattung des Arbeitsplatzes gehören eben-


falls die Nicht-DWH-Programme. Dies bedeutet, dass nicht nur die speziellen
DWH-Komponenten zu verteilen sind, sondern auch die üblichen Programme
für Kommunikation, Gruppenarbeit, Büroaufgaben und Terminverwaltung.
Die Ausstattung ist von der Aufgabenstellung des Arbeitsplatzes abhängig. Die
meisten Arbeitsplätze sind dabei völlig identisch auszustatten, andere bedürfen
besonderer Beachtung. Managementpositionen benötigen z.B. eine besonders
ergonomische, erklärungsfreie Konfiguration und setzen viel weniger ausge-
feilte Analysewerkzeuge auf großen, unüberschaubaren Datenmengen ein. Zu
solchen Arbeitsplätzen können Ausstattungsstandards vorbereitet werden. Bei-
spiele für solche Arbeitsplatzarten sind in der folgenden Checkliste Arbeits-
platzkategorien zusammengestellt.

Massendateneingabe und Hilfspersonal


Sekretariat
Fachkraft und Standardsoftware-Anwender
Konstrukteur, Produktentwickler und CAD-Arbeitsplatz
Marketingspezialist, Analytiker
Buchhaltung
Anlageanalytiker
Management
Aufsichtsrat

Tabelle 5.14: Checkliste Arbeitsplatzkategorien

Die Softwarekonfiguration des Arbeitsplatzes des DWH ist also die Definition
der Bestückung der Rechner der Benutzer mit einem voll funktionsfähigen
System von zusammenarbeitenden Softwarekomponenten.

Gestaltungs- und Lösungsmöglichkeiten


Neben der Individualität der einzelnen Arbeitsplätze, bedingt durch die Ver-
schiedenheit der Aufgaben, gibt es sehr ähnliche Arbeitsplätze, die eine ähnli-
che Ausstattung an Software erfordern. Zunächst ist es daher hilfreich, diese
Ähnlichkeitsgruppen festzustellen. Eine Arbeitsplatzausstattung wird demnach
nach der Zuordnung zur Kategorie und dem entsprechenden Standard und der
Nennung der individuellen Unterschiede bestimmt.
➢ Feststellung der Lokation der Datenquellen und der Server-Verteilung
➢ Bestimmung der Lokation der Anwender
➢ Kategorisierung der Arbeitsplätze
Die Unternehmen können zwar nicht entscheiden, ob Hersteller ihre Produkte
als Client/Server-Lösungen oder als Terminal-Host-Lösungen produzieren, aber
sie können entscheiden, ob sie grundsätzlich ein verteilbares Produkt erwerben
wollen. Der Kauf eines verteilbaren Produkts bietet dann zwar die Gestaltungs-
Kapitel 5 • Hardwarekomponenten und Netzinfrastrukturen 291

freiheit der Verteilung, aber er bringt auch den Zwang mit sich, die Verteilung
bestimmen zu müssen.
➢ Bestimmung der Softwarekomponenten auf Server und Clients
Problemlösung: Regeln und Hilfsmittel
Das Verfahren
Die Methodik zur Ausstattung der Arbeitsplätze ist prinzipiell von der DWH-
Problematik unabhängig, sie ist für alle Software-Allokationen gleichermaßen
einsetzbar. Die Server-Softwarekomponenten des DWH sind selbstverständlich
auf den DWH-Servern zu installieren und damit bereits durch die Aufstellung
der Server alloziert. Dies war durch die Feststellung der Länderaktivitäten des
Unternehmens bereits begründet worden. Damit ist nur die Ausstattung der
Arbeitsplätze zu bestimmen. Die folgende Vorgehensweise ist für die Ermitt-
lung der Software-Allokation zu empfehlen.

Verfahren: Software-Allokation
❖ Feststellung der Lokation der Datenquellen und der Server-Verteilung
mit Hilfe des Netzdiagramms
❖ Bestimmung der Lokation der Anwender
❖ Kriterien zur Beurteilung der Lokationen der Software, (Client oder Ser-
ver, Serverzuordnung)
❖ Kategorisierung der Arbeitsplätze
❖ Bestimmung der Softwareausstattung der Clients

Dokumentation der Serververteilung


Die Ausstattung der Arbeitsplätze ist wegen des Zugriffs aus der Ferne von der
Allokation der Server abhängig, da der Durchlauf durch die verschiedenen
LANs und WANs die unterschiedliche Verpackung der Daten in Protokolle
durch Hilfsprogramme erfordert. So benötigt z.B. ein Datenaustausch über
Modem und Telefonnetz eine andere Hilfssoftware als der Datentransfer über
das Handy-Netz GSM. Auf dem Server muss eine Datenbank erreicht werden,
und diese muss mit einer ihr verständlichen Abfragesprache, z.B. SQL, ange-
sprochen werden. Auch hierfür ist die Installation eines speziellen Programmes
nötig. Als erste Problemlösungshilfe dient also die Dokumentation der Server-
verteilung mit den darauf installierten Softwarekomponenten.
Netzdiagramm
Als zweite Problemlösungshilfe ist eine Grafik der Netze, das bereits bespro-
chene Netzdiagramm, erforderlich. Dies braucht allerdings den DWH-Spezialis-
ten nicht weiter zu kümmern, da für die Definition der erforderlichen Netz-
komponenten auf den Arbeitsplatzrechnern der PC-Service und das
Netzwerkmanagement zuständig sind.
292 Kapitel 5 • Hardwarekomponenten und Netzinfrastrukturen

Liste Softwareausstattung der Clients


Als Entscheidungsgrundlage für die Allokation der Softwarekomponenten
sollte die Liste der Arbeitsplätze und der Serverorte aus der Hardwarebestim-
mung verwendet werden. Die Server-Programme werden dann in der Nähe der
Benutzer oder in der Nähe des besten Service, analog der Entscheidung der
Hardware-Allokation, installiert.
Zur Definition der Kategorien kann z.B. die bereits dargestellte Klassifikation
der Managementebenen oder eine eigens erstellte Kategorienliste, wie am
Kapitelanfang dargestellt, dienen:

Benutzer, Office Kommuni- Betriebsw. DWH-


Rechner kation SSW Komponente
Arb. Typ

Name Typ Typ Typ


PC, W95 Ort Ort Ort
CAD

Name Typ
PC, W95 Ort
Sekretariat

Tabelle 5.15: Liste Softwareausstattung der Clients

Blockdiagramm der Softwarekomponenten


Es ist ganz nützlich, zur Prüfung der Vollständigkeit der Komponentenliste
eine Softwareschichtengrafik oder ein Blockdiagramm der Softwarekompo-
nenten zu erstellen und die Kommunikation des Anwenders anhand des
gedanklichen Durchlaufens der Verarbeitungsschichten des Client-Rechners
bis zum Server durchzuspielen. In der folgenden Abbildung »Arbeitsplatzkonfi-
guration als Schichtenbild« kann der Anwender z.B. über eine COBOL-
Applikation durch ein TCP/IP-Netz auf eine SQL-Datenbank zugreifen.
 
 
 





 

 
  !!  # 
" 
'(' #$%&'


      

Abbildung 5.18: Softwarekonfiguration des Arbeitsplatzes als Schichtenbild


Kapitel 5 • Hardwarekomponenten und Netzinfrastrukturen 293

Die Ausstattung der jeweiligen Kategorie wird in einer unternehmensweit gül-


tigen Richtlinie als Standard fixiert und den Anwendern zugänglich gemacht.
Die Anwender können rechtzeitig ihre über die Standardausstattung hinausge-
henden Anforderungen anmelden.

5.6 Exkurs Client/Server-Architektur


Der Wunsch, grafische Oberflächen für mehrere Benutzer zu betreiben, führt
zwangsläufig zu einer Architektur, die einen zentralen Rechner entlasten muss.
Die Entlastung kann durch Aufspalten eines komplexen Programmes in meh-
rere Komponenten und das Auslagern der Ausführung dieser Komponenten auf
weitere Rechner bewältigt werden. Die vielen Benutzern dienenden Funktio-
nen, Module, Programme und Komponenten werden dabei von einem allen
Usern zur Verfügung stehenden, zentralen Rechner, dem Server durchgeführt.
Dieser Rechner (Server) dient den Programmen der Benutzer (Clients).
Im Extremfall steht hierbei jeder verteilten Komponente ein eigener Rechner
zur Verfügung, der nur für die jeweiligen Benutzer dieser Komponente arbeitet.
Eine andere Verteilungsvariante ist die Ausführung mehrerer Komponenten
auf einem Rechner, bis zu einer erlaubten Obergrenze für die Anzahl von
Benutzern. Bei Überschreiten dieser Grenze wird ein weiterer Rechner wieder
mit allen Komponenten zur Verfügung gestellt.
Um bessere Verteilungsmöglichkeiten als bei den konventionellen Hostsyste-
men nutzen zu können, wurde die Client/Server-Architektur entwickelt.

Exkurs Client/Server-Architektur
Der Grundgedanke der Client/Server-Architektur ist die Aufspaltung eines
Programmes in zwei oder mehrere Teile, die auf verschiedenen Rechnern,
einem Client-Rechner und einem oder mehreren Server-Rechnern laufen
können. Wie groß diese Teile sind, welchen funktionalen Umfang sie haben,
bleibt dabei den Vorstellungen der Programmierer überlassen. Die Gestal-
tungsfreiheit ist durch die Fähigkeiten der verwendeten Rechner begrenzt.
Durch die Aufteilbarkeit können auch die Fähigkeiten mehrerer Rechner
genutzt werden. In Summe sind bei den C/S-Architekturen die Rechnerfä-
higkeiten variantenreicher konfigurierbar. So kann z.B. die rechenintensive
Verarbeitung grafischer Benutzungsoberflächen auf einen eigens für einen
Benutzer zuständigen Rechner gelegt werden. Ein einzelner Rechner wäre
mit der Grafikverarbeitung aller Benutzer eines Multiuserbetriebes aus-
sichtslos überfordert. Die grafische Oberfläche kann auf einem PC oder
einem X-Terminal ausgeführt werden. Andererseits wäre ein PC damit über-
fordert, eine große Datenbank im Multiuserbetrieb mit angemessenem
Antwortzeitverhalten zu betreiben.
294 Kapitel 5 • Hardwarekomponenten und Netzinfrastrukturen

Es haben sich für die Programmklasse der »Datenbankanwendungen«, um


die es im DWH ja hauptsächlich geht, bestimmte Aufteilungsstellen der Pro-
gramme als optimal herausgestellt. Die folgende Darstellung, aus einer
Informationsreihe der Firma Digital Equipment Corporation, DEC, gibt
einen Überblick über diese möglichen Trennstellen von monolithischen
Programmen zu Client/Server-Scheiben.
$ ()  
 

  

(.//

(  

$  

    
     

$  $ #


   

  


  
#$ &'
   

  

* , - +

#$ &' #$ &'

        
  
 

)   
*
 

           


    
!!    
     
  



     

Abbildung 5.19: Sinnvolle Aufteilungsstellen von Client/Server-Programmen


Kapitel 5 • Hardwarekomponenten und Netzinfrastrukturen 295

Die Aufspaltung eines Programmes in einen Client-Teil und einen Server-


Teil zwingt die Softwarehersteller zu einer Öffnung der Schnittstellen für
andere Programme. Hierdurch wird eine von den Kunden nicht mehr
gewünschte Bindung vermieden. In der Frühzeit der Business-Applikationen
war noch eine starke Herstellerabhängigkeit der Kundschaft üblich. Es gab
z.B. sogenannte »Bundles«, die bei einem Applikationskauf sogar zum Kauf
der zugehörigen Hardware zwangen. Ein lukratives Nebengeschäft, das ver-
ständlich macht, weshalb es nicht die Hardwarehersteller waren, welche die
Offenheit von Applikationen anstrebten. So kann durchaus der Client-Teil
von einem Hersteller A besser sein als der Client-Teil des Herstellers B, der
den Server-Teil programmiert hat. Die Client/Server-Architektur gestattet
also auch eine größere Flexibilität im Wechsel oder in der Kombination der
Produkte verschiedener Hersteller.
Mittels der Client/Server-Architektur sind also Gestaltungsfreiheiten
geschaffen, Programme so aufzuspalten, dass verschiedene Rechner mit
unterschiedlichen Leistungsmerkmalen an der Abarbeitung einer Anwen-
dung beteiligt werden können. Ein Leistungsmerkmal ist dabei die Kapazität
und Schnelligkeit. Die Verarbeitung einer Datenbank kann z.B. durch die
Verteilung der Daten auf verschiedene gleichartige Rechner erheblich
beschleunigt werden. Die Rechner können noch dazu in der Nähe der Benut-
zer platziert werden, was noch einmal eine Schnelligkeitssteigerung durch
verkürzte Netzstrecken bringt.
Vorteile einer Verteilbarkeit bzw. einer Verteilung von Anwendungen sind
damit:
✔ Lastverteilung auf viele Rechner vom gleichen Typus
✔ Leistungsverteilung auf verschiedene Rechnertypen
✔ Skalierbarkeit durch Hinzunahme weiterer Rechner
✔ Präzisere Allozierbarkeit in die Nähe der Benutzer bzw der Datenquellen
Die folgende Grafik gibt einige Beispiele der Programmverteilung auf ver-
schiedene Rechner:

        # 

   $ 
     !
" 
        
 
 
 
 
 




  
 
 
 


 




         

 
 
 
 


    

 


Abbildung 5.20: Client/Server-Architekturen


296 Kapitel 5 • Hardwarekomponenten und Netzinfrastrukturen

Für die Platzierung von Programmen haben sich seit der Entwicklung von
Client/Server-Produkten einige Empfehlungen bewährt:
✔ große Datenbanken mit Multiuserzugriff auf einen speziellen, skalierbaren
Server legen
✔ Grafikverarbeitung der Oberfläche auf das Endgerät PC oder X-Terminal
✔ hochspezialisierte Programme mit komplizierten Berechnungen auf einen
weiteren Server
✔ Kommunikationsdienste wie Mails auf einen speziellen Mailserver
✔ Internetseiten auf einen speziellen Web-Server
✔ Archivierung auf einen speziellen Archivierungs-Server
Die Verständigung der Rechner und ihre Kooperation muss über Hilfspro-
gramme gesteuert werden. Das Zusammenspiel zwischen Client- und Server-
programmen basiert auf einem Unterprogramm zum Aufruf entfernter, also
auf anderen Rechnern liegender Programme, dem Remote-Procedure Call,
kurz RPC, wie in der folgenden Grafik dargestellt ist.
Client-Rechner Server-Rechner
Anwend.- Komm.- Komm.- Server- Server-
Client-Stub
Programm Kompon. Kompon. Stub Programm
Prozedur-
aufruf Aufruf-
kodierung Aufruf- Aufruf-
übertragung empfang Aufruf-
dekodierng Prozedur-
aufruf

Warten
Abarbeitg

Ergebnis-
Ergebnis- rückgabe
Ergebnis- Ergebnis- kodierng
Ergebnis- empfang übertragung
Ergebnis- dekodierng
rückgabe

Abbildung 5.21: Ablauf eines Remote Procedure Calls (RPC)


Das Anwendungsprogramm auf dem Client-Rechner enthält einen Aufruf für
ein anderes Programm, das auf einem Server-Rechner installiert ist. Kommt
die Abarbeitung des Client-Programmes an diesen Aufruf, wird es in einen
Wartezustand versetzt. Der Aufruf wird samt allen Parametern und Überga-
bewerten so zu einem Miniprogramm, dem Klientenstub, kodiert, dass er
über ein Kommunikationsnetz übertragen werden kann. Anschließend wird
von der Kommunikationssoftware die Übertragung zum Server durchge-
führt. Auf der Serverseite wird der Aufruf empfangen und vom Serverstub
dekodiert. Das Ergebnis der Dekodierung ist ein für das Serverprogramm
verständlicher Aufruf. Der Aufruf wird vom Serverprogramm abgearbeitet
und die Ergebnisse werden an den Serverstub übergeben. Der Serverstub
kodiert die Ergebnisse zur Übertragung der auf dem Server resistenten Kom-
munikationssoftware.
Kapitel 5 • Hardwarekomponenten und Netzinfrastrukturen 297

Die Kommunikationssoftware überträgt das Ergebnis durch das Netz. Der


Client-Rechner empfängt die Übertragung und gibt dem Klientenstub die
Daten zur Dekodierung für das rufende Client-Programm. Der Klientenstub
übergibt das Ergebnis an die Client-Prozedur und der Wartezustand wird
aufgehoben.

Die Grafiken entsprechen den Darstellungen in


 Mühlhäuser, Client-Server
 Digital, Technologie

5.7 Fortsetzungsbeispiel InDaWa


Einleitung
Das fortgesetzte Projektbeispiel des Data Warehouse InDaWa aus der Branche
»Energieversorgung« ist am Ende des vorigen Kapitels an der Stelle angelangt,
wo der Bedarf an Softwarekomponenten feststeht. Der nächste Schritt ist die
Bestimmung des Hardwaresystems, auf dem diese Software zur Ausführung
kommen soll. Hierzu gehören die Rechner für die Verarbeitung von Daten und
Programmen, die Netze zur Verbindung der Rechner und die Peripherie der
Rechner für Eingaben, Ausgaben und Aufbewahrung. Für die Bestimmung der
Hardware sind neben Anwendungen noch die Kapazitäten zu ermitteln. Danach
können die Folgerungen für die Typen, Komponenten und Kapazitäten der
Hardware gezogen werden.

Beispiel
Welche Anforderungen sind nun an eine Hardware für ein Instandhaltungs-
DWH eines Energieversorgers zu stellen, der den im vorangehenden Kapitel
»Softwarekomponenten« festgestellten Software-Komponentenbedarf einset-
zen möchte? Mit einer kurzen Betrachtung kann eine Kapazitätsschätzung
angestellt werden.

Beispiel: Mengenermittlung
Mengen
Die Schadensanalysen eines Kraftwerkes umfassen die gesamten Komponen-
ten, Bauteile, Materialien und Betriebsmittel der Produktionsanlage. Eine
Schadensanalyse umfasst daher die Daten aller Bauteile des Kraftwerks. Schä-
den sind abhängig vom Zusammenspiel der Komponenten im Produktions-
prozess. Eine Schadensanalyse umfasst daher auch die Daten der Einbauorte,
die sogenannte Anlagentopologie. Schäden haben eine Vorgeschichte, Schä-
den machen sich durch Störgeräusche, Verformung, Temperaturwechsel,
Stoffaustritt, Output-Schwankungen und Signale bemerkbar.
298 Kapitel 5 • Hardwarekomponenten und Netzinfrastrukturen

Eine Schadensanalyse umfasst deshalb auch historische Daten von Vorfällen


und Ereignissen. Ursache von Schäden können Belastungen durch Klima,
Wetter und Geologie sein. Eine Schadensanalyse umfasst daher die Daten der
Umwelt. Ein großer Vorteil dabei ist, dass der Betreiber über zehn Kraft-
werke mit gleichen Bauteilen unterschiedlicher Bauweise und unterschiedli-
cher Typen (Steinkohle, Braunkohle, Kernkraft) verfügt, so, dass Querver-
gleiche angestellt werden können.
Es werden zunächst nicht mehr als fünf Experten für Schadensanalysen in der
Zentrale und je ein Experte pro Kraftwerk eingesetzt. Man kann nicht abschät-
zen, wieviel Know-how zu Schäden gewonnen werden kann und welches
Kosteneinsparungspotential die Instandhaltung bietet. Man will kein Risiko
eingehen, mehr Kosten durch die Analysen zu verursachen, als an Instandhal-
tungskosten durch deren Erkenntnisse eingespart werden kann. Es wird als
gute Kosten/Nutzen-Relation die Besetzung von fünf Experten vermutet.
Damit sind folgende Eckwerte ausgemacht:
✔ Lokationen: Zehn Kraftwerke und eine Zentrale
✔ Benutzer im gleichzeitigen Zugriff (nur in der Zentrale): Fünf Personen
Benutzer insgesamt: 15 Personen
Benutzer pro Kraftwerk: Eine Person
Bezüglich der Datenmengen ist folgendes festzuhalten:
✔ Bauteildatenbank
pro KW 200.000, mal 10 Kraftwerke, mal 10KByte 20GB
✔ Instandhaltungsaufträge für die Schadenshistorie:
100.000 pro Jahr pro KW, bei 20 Jahren Betriebszeit
und 5KByte pro Auftrag 10GB
✔ Anlagentopologie:
pro KW 200.000, 10 Kraftwerke, 10KByte Beschreibung 20GB
✔ Summe 50GB

Auf der Basis der Mengenschätzungen werden unter Berücksichtigung der Rah-
menbedingungen, wie z.B. vorhandene Rechnertypen und Einkaufseinschrän-
kungen, die Hardwarekomponenten bestimmt.

Beispiel: Hardwarebestimmung
Rechner
In den technischen Bereichen haben sich Rechner der VAX-Familie von DEC
mit dem Betriebssystem VMS und UNIX-Rechner diverser Hersteller durch-
gesetzt. Es gilt die Devise, nur wenn ausdrücklich zu erkennen ist, dass die
vorhanden Rechner nicht einsetzbar sind, ist nach einem neuen Hersteller
zu suchen. Dann soll aber immer noch UNIX das bevorzugte Betriebssystem
sein. Auf alle Fälle ist klein zu beginnen, bei Offenhaltung der Möglichkeit
eines sukzessiven Ausbaus.
Kapitel 5 • Hardwarekomponenten und Netzinfrastrukturen 299

Die Performance-Anforderungen sind durch hohe Datenmengen und durch


komplexe Programme gestellt. Man gibt hier den RISC-Maschinen den Vor-
zug. Über die Komplexität der Auswertungsalgorithmen besteht noch Unge-
wissheit, deshalb möchte man die Skalierbarkeit sicherstellen. Dabei wird
der Ausbau im bestehenden Gehäuse durch weitere Prozessoren auf maximal
16, ergänzt um optionale Hauptspeichererweiterungen auf maximal 2GB, als
ausreichend betrachtet. Starten will man mit vier Parallel-Prozessoren.
Die Schadensaufnahme ist bisher auf Papier durch Dritte vorgenommen
worden. Zukünftig soll die Schadensaufnahme von zwei der fünf Schadens-
analytiker selbst vor Ort erstellt werden. Hierfür ist eine mobile Ausrüstung
erforderlich.
WAN
Da die Schadensanalytiker zusammen in einem Bürogebäude sitzen und kein
Zugriff auf landesweite Informationen erforderlich ist, sind keine besonderen
WAN-Anforderungen gegeben. Es ist mit folgendem Verkehr zu rechnen:
✔ Ein Mal pro Monat Überspielung aller Schadensfälle jedes Kraftwerkes an
die Zentrale
✔ Ein Mal pro Monat Rücksendung der Auswertungen
LAN
Die Schadensanalytiker arbeiten als Gruppe zusammen und erarbeiten wett-
bewerbsrelevante Daten. Sie müssen daher durch ein die Kooperation
ermöglichendes LAN verbunden sein. Dies hat allerdings keine weiteren
Anforderungen gegenüber der bereits für Mailing und Groupwork installier-
ten unternehmensweiten Office-Lösung ergeben.
Ein über die üblichen Sicherheitsmechanismen wie Werkszutritt, Passwort-
schutz für LAN, Server und Applikation hinausgehendes, eigens gesichertes
LAN, ist nicht nötig. Mit einem datenintensiven CAD-Austausch ist nicht zu
rechnen, da die CAD-Zeichnungen von der Schadensgruppe nicht elektro-
nisch bearbeitet werden.
Das LAN besteht damit aus drei stationären und zwei mobilen Clients und
einem DWH-Instandhaltungsserver, die über das hauseigene Ethernet ver-
bunden sind.
Peripherie
Einige Schäden können mittels Fotografien besser analysiert und eingeord-
net werden. Die Schadensexperten brauchen deshalb einen Zugriff auf ein
Fotoarchiv und sollen eigene Foto-Aufnahmen vor Ort machen können. Die
Kontrolle der Aufnahme soll ebenfalls noch vor Ort möglich sein. Bewegtbil-
der sind derzeit nicht vorhanden, es wird noch überlegt, ob eine Videoauf-
nahme und der dreidimensionale Eindruck der Situation von Vorteil für die
Analyse ist. Eventuell wird eine elektronische Filmkamera probeweise einge-
setzt. Auf alle Fälle ist hierfür Vorsorge zur tragen.
300 Kapitel 5 • Hardwarekomponenten und Netzinfrastrukturen

Einige Situationsanalysen erfordern tieferen Einblick in die Konstruktion


mittels CAD-Zeichnungen. Diese werden in der Konstruktion erstellt, ver-
waltet und archiviert. Ausdrucke sind auf dem dort installierten Drucker
möglich und abholbar, da die Konstruktion im gleichen Gebäude angesiedelt
ist. Massendrucke sind nicht erforderlich.
Um auch Details genau genug erkennen zu können und um große CAD-
Zeichnungen übersichtlich darstellen zu können, werden große Monitore
mit einer hohen Auflösung eingesetzt.
Das Bild des Arbeitsplatzes der einzelnen Mitarbeiter der Schadensgruppe ist
im Anhang als Lösung aufgeführt.

Gestaltungsentscheidungen
Wie in den vorhergehenden Kapiteln werden auch hier die Entscheidungen, die
im Musterprojekt »DWH für Energieversorger, InDaWa« getroffen wurden, im
Überblick zusammengestellt.

Entscheidung/
Gestaltungsaspekt Erkenntnis Begründung

ORIENTIERUNG

ARCHITEKTUR
Betriebswirtschaftskomponenten
...
Softwarekomponenten

Hardwarekomponenten
...
WAN Keine Erweiterung erforderlich Keine Daten von außen

LAN Keine Erweiterung erforderlich Keine wesentliche Netzlaststeigerung, da nur


5 Analytiker, Anschlüsse bereits vorhanden

Client-Rechner 5 PC, Pentium 300 Mhz, Stärker als Office-Standard


stationär 5 Analytiker erforderlich
1 Notebook, Pentium Mobile Schadensaufnahme

Betriebssystem W98 bevorzugt Integration in bestehende Administration

Peripherie

Server-Rechner RISC, Multiprozessor Skalierbarkeit, wesentlicher Datenumfang


unklar

Betriebssystem UNIX bevorzugt etabliert im Unternehmen

Organisationskomponenten
...

VORGEHENSMODELL

Tabelle 5.16: Entscheidungschart InDaWa, Hardware


Kapitel 5 • Hardwarekomponenten und Netzinfrastrukturen 301

5.8 Übungen
Übung 5.1: Hardware-Architekturkomponenten
Zählen Sie auf, welche Hardware-Architekturkomponenten aus Ihrer Sicht und
mit Ihrer Erfahrung für die Arbeitsplätze
✔ Bereichsleiter Marketing
✔ Aufsichtsratsmitglied
✔ Weltweiter Produktmanager für eine Produktgruppe
✔ Weltweiter Einkäufer für die Bauteile von Robotern
✔ Zentrale Buchhalterin für Debitoren
zum Betrieb von DWH-Komponenten erforderlich sein könnten.
Übung 5.2: WAN- und LAN-Komponenten
Zählen Sie die Komponenten eines WAN und LAN umfassenden Unternehmens-
netzes auf und schildern Sie die Aufgabe der Komponenten anhand eines
gedachten Durchlaufs der Informationen einer Datenbankanfrage.
Übung 5.3: Rechnertypen
Geben Sie die für ein DWH interessanten Rechnertypen mit ihren wesentlichen
Eigenschaften an.
Übung 5.4: Skalierungsfälle
Welche Skalierungsfälle können für ein DWH auftreten und mit welchen Ska-
lierungsmöglichkeiten kann man das DWH-System anpassen?
Übung 5.5: Arbeitsplatzausstattungsschema
Stellen Sie schematisch die Hardwarekomponenten und die Netzintegration
einer DWH-Arbeitsplatzausstattung dar.
Übung 5.6: Transaktion
Beschreiben Sie den Ablauf einer Transaktion in einer zweistufigen Client/Ser-
ver-Architektur. Wie heißt die grundlegende Prozedur, die hierfür verwendet
wird?
Übung 5.7: Client/Server-Technologie
Welche Gestaltungsfreiheiten sind mit der Client/Server-Technologie gegeben?
Übung 5.8: Client/Server-Applikation
Zeigen Sie die Trennstellen einer Client/Server-Applikation auf. Nehmen Sie ein
Ihnen bekanntes Beispiel für eine Applikation und schildern Sie, auf welche
Rechnertypen Sie welchen Programmteil implementieren würden.
302 Kapitel 5 • Hardwarekomponenten und Netzinfrastrukturen

Übung mit Lösung 5.9: Arbeitsplatzausstattungsschema


Entwerfen Sie das Schema Arbeitsplatzintegration zum Arbeitsplatz des Scha-
densanalytikers des Data Warehouse InDaWa.
Übung 5.10: Entscheidungsdurchlauf IT-Kategorie Hardware
Versuchen Sie mit Hilfe des Entscheidungsfeldes Hardware-Architektur einen
Entscheidungsdurchlauf mit folgenden Einschränkungen zu entwerfen:
✔ Für Hardwarekomponenten kommt nur eine Client/Server-Architektur in
Frage.

5.9 Zusammenfassung der Entscheidungsgänge zur


Hardwaregestaltung
Das Data Warehousesystem wurde als komplexes Informationssystem, das wei-
ter nach IT-Kategorien zerlegt werden kann, erkannt. Die IT-Kategorien
betriebswirtschaftliche Komponente und Softwarekomponenten wurden
bereits in vorangegangenen Entscheidungsläufen analysiert. Als dritte Kompo-
nente ist nun die Hardwarekonfiguration zu gestalten. In der Abbildung »Ent-
scheidungslauf der Hardwaregestaltung« sind für den Entscheidungslauf der
hardwaretechnischen Gestaltungskomponenten vier Entscheidungsgänge zu
durchlaufen:
✔ Wide Area Network, WAN
✔ Local Area Network, LAN
✔ Rechnertypen und Betriebssysteme
✔ Peripheriegeräte
Erster Entscheidungsgang
Im ersten Entscheidungsgang sei zunächst das WAN betrachtet. Am WAN kann
nicht wirklich Gestaltung erfolgen. WAN-Nutzung wird in der Regel bei einem
WAN-Eigentümer oder einem Partnerunternehmen, dem Betreiber, in Form
von Technologie und Kapazität bestellt. Nur wenige Unternehmen können sich
ein eigenes WAN mit Verlegung von Kabeln durch Länder und Ozeane leisten.
Die eigenen Beschaffungen zum WAN liegen in den Koppelungskomponenten,
die allerdings auch gemietet werden können.
Die eigentliche Gestaltungsfreiheit liegt im ersten Schritt des ersten Entschei-
dungsganges in der bestellten Technologie, der Leistung und dem Lieferanten,
dem Provider. Im zweiten Schritt des ersten Entscheidungsganges werden der
WAN-Technologie entsprechend die Komponenten für den Zugang zum WAN
und die Beschaffungsart – Miete oder Kauf – bestimmt.
Kapitel 5 • Hardwarekomponenten und Netzinfrastrukturen 303

Das WAN bestimmt nicht die Rechnerentscheidung und auch nicht die LAN-
Entscheidung. Deshalb kann die WAN-Entscheidung auch zuletzt getroffen
werden.
Zweiter Entscheidungsgang
Das Rechnersystem ist, je komplizierter sein Aufbau, also je umfangreicher die
Anzahl der kooperierenden Komponenten ist, mit einer Infrastruktur zu ver-
binden, mit einem Lokalen Netzwerk. Die Bestimmung der Netzwerke ist hier
als zweiter Entscheidungsgang dargestellt. Im ersten Schritt des zweiten Ent-
scheidungsganges wird die Verkabelungsart bestimmt.
Im zweiten Schritt des zweiten Entscheidungsganges werden der LAN-Tech-
nologie und LAN-Topologie entsprechend die Komponenten im LAN bestimmt.
Der zweite Entscheidungsgang kann auch nach der Bestimmung des Rechner-
systems durchgeführt werden. Wenn das Lokale Netz schon existiert, sind
lediglich Erweiterungen oder Umstrukturierungen zu überlegen. Es wird aller-
dings beim Neuaufbau nicht das LAN den Rechnertyp bestimmen, sondern die
LAN-Entscheidung entsprechend der Rechnerentscheidung getroffen werden.
Dritter Entscheidungsgang
Im dritten Entscheidungsgang wird zunächst auf der Ebene des Systemtyps im
ersten Schritt des dritten Entscheidungsgangs das Rechnersystem bestimmt.
Da das DWH-System aus mehreren Rechnern besteht, sind dies mehrere Rech-
ner, je nach Bedarf und Funktion im Gesamtsystem und je nach Benutzerrolle.
Weiter kann auf der Ebene der Systemkomponenten im zweiten Schritt des
dritten Entscheidungsgang der Rechneraufbau detailliert werden. Zum Bei-
spiel könnte die zum Systemtyp »Rechnersystem« gehörige Systemkompo-
nente »Workstation« relevant sein.
Die Leistungsfähigkeit von Workstations unterscheidet sich in der Leistungsfä-
higkeit ihrer einzelnen Bauteile oder Systemmodule, die im dritten Schritt des
dritten Entscheidungsgangs bestimmt wird. Deshalb ist es interessant, die
Alternativen, z.B. der möglichen »Motherboards«, zu betrachten. Das Herz-
stück eines Motherboard ist der Prozessor. In der Regel ist es ausreichend, sich
dann auf der Ebene der Funktionen unter einem bestimmten Prozessortyp, z.B.
einem RISC-Prozessor, für eine Leistungsklasse, z.B. mit der Taktrate 300 MHz,
zu entscheiden.
Der beispielhafte Durchlauf durch die Gestaltungsentscheidungen des dritten Ent-
scheidungslaufes ist wie folgt:
304 Kapitel 5 • Hardwarekomponenten und Netzinfrastrukturen

IT-Kategorie Dritter Entscheidungsgang


Hardware
1. Schritt

Systemtyp
Rechnersystem
2. Schritt
Systemkompo-
nente
Workstation
3. Schritt

Systemmodul
Motherboard
4. Schritt

Funktionen
Prozessortyp RISC

Abbildung 5.22: Dritter Entscheidungsgang

Vierter Entscheidungsgang
Im vierten Entscheidungsgang ist die Peripherie des Rechnersystems zu defi-
nieren. Diese hängt von der Umgebung ab, in der das Rechnersystem arbeiten
soll. Das Ergebnis ist die Definition der Eingabegeräte, Ausgabegeräte, der Spei-
chersysteme und einiger Hilfssysteme wie z.B. Stromversorgung, Sicherheits-
systeme, Feuerschutz. Neben der Spezifikation der Peripheriegeräte muss auch
der Aufstellungsort bestimmt werden. Der Aufstellungsort ist von der Qualifika-
tion der Anwender, klimatischen Bedingungen und Medien, auf denen die
Informationen geliefert werden, abhängig.
Die verschiedenen Gestaltungsobjekte der Systemtypen sind unterschiedlich
tief zu detaillieren. Dies liegt im Ermessen des DWH-Spezialisten. Diese unter-
schiedlichen Detaillierungsgrade bringt die Grafik »Entscheidungsgang Data
Warehouse Gestaltung« durch die unterschiedliche Aufteilung der Boxen zum
Ausdruck. Die Grafik gibt nicht in allen Detaillierungsstufen eine vollständige
Klassifikation, sondern sie beschränkt sich der Übersichtlichkeit und der
Erkenntnis des Zerlegungsprinzips zuliebe auf die wichtigsten Unterteilungen.
Mit diesen Gestaltungsentscheidungen sind noch keine Produktentscheidun-
gen getroffen, sondern nur Kriterien für die Produktsuche geschaffen. Damit
ist also der beispielhafte Durchlauf durch die Gestaltungsentscheidungen wie
folgt (siehe Abbildung 5.22).
Kapitel 5 • Hardwarekomponenten und Netzinfrastrukturen 305


    

  


 

  


 



  



 

  !  '  



 
    1 
 1 # ""6
 & $ ! 
 '   1 6


  
 

  # $  
& 
  $&
& 
 /$& 

5&( $"&

 
& ' "  "   

 
  
  "&, "%
   ("  1+1
*&
&"%
  * &  "%
 % -" 
) 8
-7 %



  .1
%
+ "%
  ' & """%
(   -"%

 -  &"%
 -&&
  %
-# 
& & -&&  
 $ $ &
  "! "&
$ !   %
 
 &
 &  

 
      
    

 
  $  
))
) !"  )
*&& '  ) )
&$ (" 
  "&& 
) " 
+"
    
   ! ,
"   !     

"#"$ + -"


 $%"  
     ! "   
  " "#"$ *"&


" )

1- .
 & 3#
 & #"
1-

#
) ))
&6 /0
  ( &- 1/0
 "4(&&4 &" &

    & " &


& &
)
'
(
' 

*$ &"
)
+ (
 
 & 

 "

 "0 

 
" 
  &-
    
 



&
$$ 
'  &&
2
($
 

Abbildung 5.23: Entscheidungslauf der Hardwaregestaltung


307

KAPITEL 6
6 Welche Organisationsstruktur muss für ein Data
Warehouse System implementiert werden?
Übersicht
Ein DWH besteht aus betriebswirtschaftlichen Funktionen, aus der Software,
die diese betriebswirtschaftlichen Funktionen automatisiert ausführt, und aus
der Hardware, auf der die Software von Betriebssystemen gesteuert zur Ausfüh-
rung kommt. Die Automatisierung kann nicht umfassend sein. Sie muss durch
manuelle Handlungen, durch Entscheidungen und Veranlassungen und durch
Umsetzungen in Gang gebracht und in Gang gehalten werden. Das Zusammen-
spiel der betriebswirtschaftlichen Abläufe ist eine Kombination aus manuellen
und automatisierten Aktivitäten. Dieses Zusammenspiel ist zu organisieren.
Eine DWH-Organisation agiert in einem internen Umfeld des Unternehmens.
Nicht das gesamte Unternehmen und auch nicht das gesamte Umfeld wirken
auf das DWH ein, sondern nur ein Ausschnitt. Das Unternehmensumfeld des
DWH besteht aus den mit dem DWH zusammenarbeitenden Systemen. Die
Organisationsgestaltung des DWH ist vom jeweiligen Umfeld – der unterneh-
mensinternen Organisation – abhängig.
Auch das Unternehmen ist von einer Umwelt umgeben; das ist ein bestimmter
Ausschnitt aus der Welt, der mit dem Unternehmen in Kontakt steht und
gewisse Einflüsse auf es ausübt. Um diese Einflüsse mit in die Gestaltung einbe-
ziehen zu können, ist der relevante Umweltausschnitt festzustellen.
In der folgenden Abbildung ist die Einbettungsbeziehung von Welt, relevanter
Umwelt, Umfeld und DWH dargestellt.

   
   
 
   
 
 

       
     

     
    



Abbildung 6.1: Einbettungsbeziehung des DWH in die Umwelt


308 Kapitel 6 • Organisationsstruktur für ein Data Warehouse System

Der Aufbau des Kapitels Organisation ist dementsprechend in die drei Teile
Umwelt, Umfeld und Organisation aufgeteilt. Die drei Teile werden in den fol-
genden Kapiteln von außen nach innen bearbeitet. Diese Vorgehensweise
erklärt sich durch die »Enthalten-sein-Beziehung«:
➡ Die Umwelt enthält das Umfeld des Unternehmens,
➡ das Umfeld des Unternehmens enthält das Umfeld des DWH,
➡ das Umfeld des DWH enthält die Organisation des DWH komplett.
Zuerst wird betrachtet, was unter der Umwelt des DWH zu verstehen ist, und es
werden Mittel zur Analyse vorgestellt. Im zweiten Schritt wird die Betrachtung
in Richtung Innenwelt oder Umfeld fortgesetzt, um dann die Organisation des
DWH zu entwerfen.

 


 
 


 

  
 
 

Abbildung 6.2: Aufbau des Kapitels Organisation

Wer sich tiefer als hier dargestellt in die Organisationstheorie einarbeiten will,


dem sei empfohlen:


Bleicher, Organisation


Wittlage, Unternehmensorganisation


Wittlage, Fallstudien
Wittlage, Methoden

Lernziel
Die Lernziele bestehen darin, eine verbesserte Sicht auf die »Außenwelt« des
Unternehmens zu schaffen, Erkenntnisse aus dieser Außensicht zu gewinnen
und ihre Bedeutung für das DWH zu beurteilen.
Ebenso gilt es, eine verbesserte Sicht auf die »Innenwelt« des Unternehmens zu
schaffen, Erkenntnisse aus dieser Innensicht zu gewinnen und ihre Bedeutung
für das DWH zu beurteilen.
Als Lernziel ergibt sich auch, dass der DWH-Spezialist so viel Know-how erwer-
ben muss, dass er alle Komponenten der Organisation eines DWH erkennt, fest-
Kapitel 6 • Organisationsstruktur für ein Data Warehouse System 309

stellen kann, wo die organisatorischen Gestaltungsfreiheiten liegen, wer gestal-


ten darf, und wer zu gestalten erlaubt.

Lernziele
 Verstehen der Bedeutung der Umwelteinflüsse
 Erkennen des relevanten Umweltausschnitts
 Aufnehmen der Umwelteinflüsse in die Gestaltung des DWH
 Verstehen der Bedeutung der Umfeldsysteme und der Umfeldorganisation
 Erkennen des relevanten Umfeldausschnitts
 Aufnehmen der Berührungspunkte des Umfeldes in die Gestaltung des DWH
 Kennen der Komponenten einer Organisationsstruktur
 Anwenden der Methodik zur Lösung von Organisationsgestaltungsfragen
 Feststellen der nötigen Befugnisse und Kompetenzen
 Definition der Berichtswege und Berichtsformen für den Betrieb des DWH
 Definition der Aufgaben des DWH-Betriebspersonals
 Bestimmung der für den DWH-Betrieb erforderlichen Rollen und Stellen
 Beschreibung der Organisationsstruktur eines DWH-Betriebs
 Beschreibung der Prozesse für den Betrieb des DWH
6.1 Welcher Umweltausschnitt ist für den Entwurf eines DWH
relevant?
Problemstellung und Motivation
Das Unternehmen, das ein DWH betreibt, ist in eine Umgebung, eine Unterneh-
mensumwelt integriert. Diese Unternehmensumwelt ist immer vorhanden, ob
das DWH aufgebaut wird oder nicht. Die Umwelt kann durch das Unternehmen
beeinflusst werden. Es können z.B. Partnerschaften geschlossen werden für die
Zusammenarbeit bei der Produktion oder dem Absatz von Produkten. Unter-
nehmen arbeiten in Arbeitsgemeinschaften, um Standards zu schaffen, die sie
bei der Konstruktion ihrer Produkte berücksichtigen. Unternehmen arbeiten
über Verbände mit politischen Einrichtungen zusammen, um Gesetzesbildun-
gen möglichst unternehmerfreundlich zu beeinflussen.
Ein Unternehmen steht im kontinuierlichen Austausch mit seiner Umwelt. Es
wird von seiner Umwelt beeinflusst. Alle Veränderungen der Umwelt verändern
auch die Einwirkungen auf das Unternehmen. Ein Unternehmen muss sich die-
sen Veränderungen aussetzen, es muss diese Veränderungen und deren mögli-
che Auswirkungen erkennen und analysieren. Das Ergebnis der Analyse müssen
310 Kapitel 6 • Organisationsstruktur für ein Data Warehouse System

Maßnahmen sein, die verhindern, dass die Auswirkungen geschäftsschädigend


werden. In einem DWH sind deshalb die Umwelteinflüsse mit abzubilden. Die
Analyse der Umwelteinflüsse ist vom DWH zu unterstützen.
Jedes Unternehmen steht in einem informationellen und materiellen Austausch
mit seiner Umgebung. Das heißt, es empfängt Informationen, verarbeitet diese
und gibt wieder Informationen an die Umwelt zurück. Ein Unternehmen unter-
liegt z.B. Auflagen von Behörden und Gesetzen und muss diese in seinem
Betrieb berücksichtigen. Werden die Auflagen von Behörden nicht beachtet,
kann das zur Stilllegung eines Betriebes führen. Die Betrachtung der Unterneh-
mensumwelt ist eine Außenbetrachtung aus der Sicht des Unternehmens.

Definition: Unternehmensumwelt
Die Unternehmensumwelt sind alle Systeme, Institutionen, Konstellationen
und Organisationsstrukturen, die durch ihren Informationsaustausch, ihre
Prozesse und ihre Funktionen auf das Unternehmen einwirken.

Auflagen und politische Zielsetzungen ändern sich im Lauf der Zeit, was immer
wieder zu neuen Gesetzen und Auflagen führt. Den Unternehmen wird in sol-
chen Fällen in der Regel ein Umstellungszeitraum eingeräumt, der zur
Umstrukturierung ausreichen muss. Beispiele hierzu sind der Beschluss der EG
zur europaweiten Einführung des EURO als Zahlungsmittel, der geplante
Abbau von Kernkraftwerken, die Öffnung der Strommärkte und die Privatisie-
rung der Telekommunikation.
Ein Unternehmen bezieht Güter, Vorprodukte und Dienstleitungen von ande-
ren Unternehmen. Prozesse, die andere Unternehmen besser, preiswerter, qua-
litativ hochwertiger und schneller abwickeln können, werden ausgelagert und
die Ergebnisse bzw. Produkte dieser Prozesse eingekauft. Das Unternehmen,
das ein DWH aufbauen möchte, steht in prozessualem Austausch mit der
Umgebung.
Funktionen des Unternehmens können an Verbände delegiert werden und in
politische Aufträge gekleidet werden. Das Unternehmen, das ein DWH aufbauen
möchte, steht in funktionalem Austausch mit der Umgebung.
Diese Umgebung besteht z.B. aus konkreten organisierten Gesellschaften wie
anderen Unternehmen, Institutionen, Parteien, Verbänden, Staaten und unor-
ganisierten Gesellschaften wie Interessengruppen. In der Umgebung manifes-
tieren sich technologische Tendenzen, politische Ereignisse und Strömungen,
gesellschaftliche Veränderungen und Naturkatastrophen.
Einige wichtige ausgewählte Umweltbeziehungen sind deshalb:
✔ Informationsaustausch, Auflagen, Gesetze
✔ Güteraustausch, Warenlieferungen, Versorgung, Personalbewegung
Kapitel 6 • Organisationsstruktur für ein Data Warehouse System 311

✔ Prozessteilung, Arbeitsteilung
✔ Zahlungsfluss
✔ Funktionsdelegation
Auch wenn Umgebungseinflüsse gar nicht oder nur geringfügig beeinflusst
werden können, sind sie doch in ihrer Auswirkung von erheblicher Bedeutung.
Nahezu alle Umweltbeziehungen mit Austauschprozessen sind von Informati-
onsfluss begleitet.
Um frühzeitig über Umweltursachen und deren Wirkungen informiert zu sein,
sind sogenannte »Frühwarnsysteme« entwickelt worden. Ein Frühwarnsystem
soll schon so lange vor Eintreten des schwerwiegenden Ereignisses dieses
Ereignis ankündigen, dass eine Vorbereitung auf die Auswirkungen möglich ist.

Gestaltungs- und Lösungsmöglichkeiten


Für die Gestaltungsaufgaben des DWH-Spezialisten ergibt sich hieraus also
zunächst die Orientierung in der Umwelt der Unternehmung und die Beurtei-
lung und Auswahl derjenigen Systeme, Institutionen, Bewegungen, Veränderun-
gen und Trends, die mit dem aufzubauenden DWH in Wechselwirkung stehen.
➢ Feststellung aller Umweltsysteme
➢ Auswahl der Umweltsysteme, deren Tendenzen und Verhalten auf das
zukünftige DWH Einfluss haben können
➢ Ermittlung der funktionalen, informationellen, prozessualen, materiellen
Wechselwirkungen der Umwelt auf das angestrebte DWH

Problemlösung: Regeln und Hilfsmittel


Das Verfahren
Das erste Problem, das es zu lösen gilt, ist die Abgrenzung des irrelevanten
Weltausschnitts gegen die relevante Umwelt des DWH. Folgendes Verfahren ist
zu empfehlen:

Verfahren: Bestimmung des DWH-relevanten Umweltauschnitts


❖ Definition der Sicht auf die Welt in Institutionen und Systemen
❖ Feststellung aller Umweltsysteme und deren Wirkungsbeziehung mittels
einer Checkliste
❖ Auswahl der Umweltsysteme mit Einflusspotential auf das zukünftige
DWH
❖ Feststellung der Tendenzen der Umweltsysteme
❖ Ermittlung der funktionalen, informationellen, prozessualen, materiellen
Wechselwirkungen auf das angestrebte DWH
312 Kapitel 6 • Organisationsstruktur für ein Data Warehouse System

Umweltsysteme
Für die Auswahl relevanter Umweltsysteme können Typologien dienen. Einmal
ist eine Typologie der Unternehmen und Institutionen interessant, da andere
Unternehmen Bestandteil der Umwelt sind. Nützlich ist auch eine Klassifika-
tion der Fachgebiete, da jedes Fachgebiet in Wissenschaft und Forschung
Ergebnisse hervorbringt, die wieder zu neuen Tendenzen in Gesellschaft und
Technik führen. Hierzu dient die folgende Checkliste Umweltsysteme.

Bereich Systeme

Natur Geographie, Geologie, Klima und Wetter, Botanik

Politik Staat, Länderregierungen, Bezirksbehörden, Stadtbehörden,


Polizei, Militär, Rechtssysteme

Gesellschaft Bewegungen, Trends, Verhaltenskodexe, Kulturgut, Historik

Wissenschaft Tendenzen, Trends

Technische Anlagen Wasserwege, Straßensystem, Luftfahrtsraum, Flughäfen,


Schienenanlagen, Stromüberlandleitungen, Verteiler, Kraftwerke,
Industrieanlagen, Forschungsanstalten, Fernsehsender, Natur-
schutzanlagen

Institutionen Vereine, Parteien, Firmen, Privatpersonen, Technische Über-


wachungsvereine, Verbände, Kirchengesellschaften, Gewerk-
schaften, Universitäten, Stiftungen

Tabelle 6.1: Checkliste Umweltsysteme

Austauschobjekte der Umweltsysteme


Mit dem Umweltsystem steht das DWH oder die vom DWH abzubildenden
Ereignisse im funktionalen, informationellen, prozessualen und materiellen
Austausch. Ein weiterer Ansatz, die Umweltbeziehungen zu ermitteln, ist des-
halb die Ermittlung dieser Austauschbeziehungen. Als Hilfsmittel soll folgende
Checkliste Austauschobjekte der Umweltsysteme dienen.

Austauschtyp Austauschobjekte

Informationen Gesetzestexte, Verlautbarungen, Vorträge, Fachschriften,


Meinungen

Sachmittel Rohstoff, Energie, Halbzeuge, Vorprodukte, Werkzeuge

Dienstleistung Services, Vermietung, Beratung, Schulung

Personen Kapazität, Leistung, Know-how

Geld Finanzierung, Bezahlung

Tabelle 6.2: Checkliste Austauschobjekte der Umweltsysteme


Kapitel 6 • Organisationsstruktur für ein Data Warehouse System 313

Wirkungsbeziehungen
Zur Darstellung der Wirkungsbeziehungen der Umweltsysteme kann das Kon-
textdiagramm Umweltsysteme angewendet werden. Das Kontextdiagramm
wird in Kapitel 7 »Das Vorgehensmodell für Data Warehouse Systeme« vorge-
stellt. Liegt der Schwerpunkt der Darstellung auf den Wirkungsbeziehungen,
kann das Wirkungsdiagramm nach Vester
 Vester, Ballungsgebiete
oder ein Petrinetz verwendet werden:
 Reisig, Systementwurf

6.2 Welcher Umfeldausschnitt ist für den Entwurf eines DWS


relevant?
Problemstellung und Motivation
Das EDV-System eines Unternehmens ist kein Selbstzweck. Es steht nicht für
sich alleine, sondern ist in eine Organisationsstruktur, in laufende Betriebspro-
zesse und bestehende Anlagen integriert. EDV-Systeme sind über LANs verbun-
den und LANs beanspruchen wie das Kommunikationssystem einen Teil der
Hausverkabelung. Die Rechnerräume sind klimatisiert und von einem
Zugangskontrollsystem überwacht. Einige Rechner greifen unmittelbar bei
bestimmten Zuständen von Produktionsstraßen in die Produktionsprozesse
ein. Die Haustechnik wird von einem Leitsystem-Rechner gesteuert.
Ein DWH ist wie jedes andere EDV-System in ein funktionierendes Unterneh-
men aus technischen Anlagen, Gebäuden und Organisationsstrukturen inte-
griert. Um ein DWH-System aufbauen zu können, müssen diese integrativen
Bedingungen konzipiert werden. Es ist erforderlich, das Unternehmensumfeld
des DWH zu bestimmen.
Informationen für das DWH entstehen im Unternehmensbetrieb aus physikali-
schen Prozessen, Geldtransfers, Sachmittelströmen und menschlichen Hand-
lungen. In Softwareprogrammen werden Teile des Unternehmens mittels Infor-
mationen abgebildet. Die Informationen repräsentieren das Unternehmen als
Modell. Sie repräsentieren auch das Unternehmensgeschehen und erlauben
zusammenfassende Auswertungen und Prognosen.
Einige Beispiele für solche Systeme als Informationslieferanten zum Unterneh-
mensgeschehen:
✔ haustechnische Anlagen
Zugangskontrollsysteme
Arbeitszeiterfassungssysteme
firmeneigene Verkehrsanlagen und deren Überwachungssysteme
314 Kapitel 6 • Organisationsstruktur für ein Data Warehouse System

Facility Management Systeme


Gebäudeleitsystem
Alarmmanagement
Brauch- und Trinkwasserversorgung
Klimaanlage und Sonnenschutzanlagen
Energieversorgung und Beleuchtungssteuerung
✔ Produktionsanlagen
Steuerungs- und Signalsysteme
Produktionsleittechnik
Lagetechnik
✔ Kommunikationssysteme
Telekommunikationsanlagen und Videokonferenzräume
Haussprechanlage
Telefonnetz
✔ Verkehrssysteme
Verkehrssignal- und Verkehrsleitsysteme
Personenbeförderungssysteme und Transportsysteme
Schranken- und Garagentorsteuerung
Die Systeme können nicht unabhängig voneinander betrieben werden. Sie ste-
hen untereinander im Informationsaustausch und können wichtige Informati-
onen für ein DWH liefern. Nicht alle Systeme sind für ein DWH interessant,
und nicht für jedes Unternehmen ist die gleiche Kombination von Systemen für
den DWH-Einsatz von gleicher Bedeutung. Für das DWH ist deshalb die rele-
vante Auswahl der Systeme herauszufinden. Es ist das Unternehmensumfeld
des DWH zu bestimmen. Die Betrachtung des Unternehmensumfeldes ist eine
Innenbetrachtung aus der Sicht des Unternehmens.

Definition: Unternehmensumfeld
Das Unternehmensumfeld sind alle Systeme und Organisationsstrukturen
des Unternehmens mit ihrer Innenwirkung, ihrem gegenseitigen Informati-
onsaustausch, den zwischen ihnen ablaufenden Prozessen und ihren Funk-
tionen.

Nicht alle Informationen aller technischen oder organisatorischen Prozesse


sind für DWH-Auswertungen interessant. Es ist deshalb ein Beurteilungsschritt
erforderlich, der feststellt, welche Informationen dieses Unternehmensumfel-
des zur Integration beitragen.

Gestaltungs- und Lösungsmöglichkeiten


Das zukünftige DWH muss in der internen Organisation mit den bestehenden
Organisationseinheiten und den internen technischen Anlagen und EDV-Syste-
men kooperieren können. Das DWH benötigt dafür entsprechende Komponen-
Kapitel 6 • Organisationsstruktur für ein Data Warehouse System 315

ten zur Kommunikation. Das können Programme sein, das können Hardware-
schnittstellen sein, und es sind immer auch organisatorische Strukturen.
➢ Feststellung der Umfeldsysteme
➢ Auswahl der für die Konzeption des DWH relevanten Umfeldsysteme
➢ Ermittlung der funktionalen, informationellen, prozessualen, materiellen
Wechselwirkungen des Umfeldes auf das angestrebte DWH

Problemlösung: Regeln und Hilfsmittel


Das Verfahren
Das Verfahren zielt auf die Bestimmung der Beziehungen und Einflüsse, die das
DWH vom Inneren des Unternehmens her, von seinen Bestandteilen und Teil-
systemen zu erwarten hat. Das folgende Verfahren ist nützlich:

Verfahren: Bestimmung der DWH-relevanten Umfeldsysteme


❖ Feststellung aller Umfeldsysteme mittels einer Checkliste
❖ Auswahl der Umfeldsysteme und deren Beziehungen zum zukünftigen
DWH
❖ Prüfung der Vollständigkeit aus der Sicht der Institutionen und Systeme
der Außenwelt
❖ Ermittlung der funktionalen, informationellen, prozessualen Wechsel-
wirkungen auf das angestrebte DWH

Umfeldsysteme, technischen Anlagen


Die technischen Anlagen sind je nach Branche und Betriebsaufgaben des Unter-
nehmens völlig verschieden. Eine Bank muss z.B. Raumüberwachung und
Zugangssicherung in der Schalterhalle haben, ein Kernkraftwerk hat einen
Zugangsschutz ähnlich einer militärischen Anlage und ein Verkehrssystem mit
eigener Schienenanlage. Die folgende Checkliste Technische Anlagen des
Unternehmens kann nur eine Anregung zur weiteren Vertiefung darstellen
(siehe Tabelle 6.3).
Checkliste Austauschobjekte der Umfeldsysteme
Auch mit dem Umfeldsystem steht das DWH oder die vom DWH abzubildenden
Ereignisse im funktionalen, informationellen, prozessualen und materiellen
Austausch. Ein weiterer Ansatz, die Umfeldbeziehungen zu ermitteln, ist des-
halb, analog zur Ermittlung der Umweltsysteme, die Ermittlung dieser Aus-
tauschbeziehungen des DWH mit dem Umfeldsystem. Als Hilfsmittel soll die
folgende Checkliste dienen (siehe Tabelle 6.4).
316 Kapitel 6 • Organisationsstruktur für ein Data Warehouse System

Bereich Anlagen

Haustechnik Hausleittechnik, Sicherheitstechnik, Zutrittssystem, Raum-


überwachungsanlagen, Feuerlöschanlagen, Beleuchtungs-
system

Gebäude Gebäude, Klimatechnik, Kühlanlagen, Heizungsanlagen,


Jalousiesteuerung

Versorgungsanlagen Energieerzeugung, Energieverteilung, Wasser, Abwasser,


Luft, Wärme

Verkehrstechnik Verkehrsleittechnik, Verkehrsanlagen, Verkehrsüberwachung

Kommunikationstechnik Telekommunikationsanlage, Videokonferenzraum, Rohrpost-


anlage

IT-Systeme Prozesssteuerung, betriebswirtschaftliche Anwendungen,


LAN-Systeme, Rechenzentren

Produktionstechnik Transportanlagen

Tabelle 6.3: Checkliste Technische Anlagen des Unternehmens

Austauschtyp Austauschobjekte

Informationen Gesetzestexte, Verlautbarungen, Vorträge, Fachschriften,


Meinungen

Sachmittel Rohstoff, Energie, Halbzeuge, Vorprodukte, Werkzeuge

Dienstleistung Services, Vermietung, Beratung, Schulung

Personen Kapazität, Leistung, Know-how

Geld Finanzierung, Bezahlung

Tabelle 6.4: Checkliste Austauschobjekte der Umfeldsysteme

Kontextdiagramm Umfeldsysteme
Die Umfeldsysteme werden in einem Kontextdiagramm, dem Kontextdiagramm
Umfeldsysteme, grafisch dargestellt. Das Kontextdiagramm Umfeldsysteme
muss nahtlos in das zuvor ermittelte Kontextdiagramm Umweltsysteme einge-
passt werden können. Das bedeutet, dass die Austauschbeziehungen zwischen
Umwelt und Unternehmen, die als relevant für das DWH ausgemacht wurden,
sich zu Austauschbeziehungen zwischen Umfeld und DWH fortsetzen müssen.
Das Kontextdiagramm wird in Kapitel 7 »Vorgehensmodell« vorgestellt.
Kapitel 6 • Organisationsstruktur für ein Data Warehouse System 317

6.3 Grundbegriffe zur Organisation


Problemstellung und Motivation
Der Aufbau eines DWH ist zu 30% Organisationsarbeit. Deshalb lohnt sich der
genaue Blick auf das Thema Organisation. Eine Organisation ist ein komplexes
Gebilde, das der Konzeption und Planung bedarf. Organisation kann erst dann
geplant, konzipiert und entworfen werden, wenn das Objekt der Organisation,
also das zu organisierende Etwas, bekannt ist. Diese zu organisierenden
Objekte sind in den vorhergehenden Kapiteln als betriebswirtschaftliche Funk-
tionen, Softwarekomponenten und Hardwarekomponenten bereits bestimmt
worden. Es ist ermittelt worden, welche Anwender mit welchen betriebswirt-
schaftlichen Aufgaben konfrontiert sind, mit welcher Software diese Aufgaben
unterstützt werden können und welche Hardware für den Betrieb der Software
am besten geeignet erscheint. Es ist also herausgefunden worden, welche
Anwender in welcher Lokation welcher Aufgabe mit welchen Hilfsmitteln nach-
gehen. Dies sind grob gesehen organisatorische Bedingungen.
Im jetzt folgenden Schritt können daraus die dafür nötigen Aufgabenträger,
ihre Rollen, die Stellenbezeichnungen und die erforderlichen Befugnisse abge-
leitet werden. Die Aufgabenträger und ihre Stellen müssen in Kommunikati-
onswege, in eine bestehende Organisationshierarchie integriert werden. Das
ergibt die neue Organisationsstruktur.
Lebensabschnitte des DWH und Rollen
Das Organisationsproblem ist dabei noch durch die Tatsache, dass das Data
Warehouse wie jedes Soft- und Hardwareprojekt drei wesentliche Lebensab-
schnitte hat, erschwert. Der erste Abschnitt ist der Aufbauabschnitt, das Pro-
jekt, in dem das DWH aufgebaut wird. Der zweite Lebensabschnitt ist der
Betrieb mit all seinen Anpassungen und Veränderungen. Der dritte Lebensab-
schnitt ist der Abbau bzw. die Aufhebung aller Einrichtungen. Das bedeutet,
dass die Aufgabe »Organisation« alle DWH-Lebensabschnitte und damit alle
Phasen des DWH-Lebenszyklus umfassen muss, denn alle Phasen benötigen zu
ihrer Abwicklung Aufgabenträger, Kompetenzen, Berichts- und Meldewege.
Die Beziehung zwischen dem Aufbauabschnitt und dem Betriebsabschnitt des
DWH ergibt sich zwangsläufig aus der Tatsache, dass bei der Projektdurchfüh-
rung wertvolles und unverzichtbares Know-how zum Betrieb des DWH gesam-
melt und aufgebaut wird. Da sich das Know-how in Personen konstituiert und
von Personen transportiert und aktiviert wird, ist es ein Anliegen des Projekts,
die Projektrollen der Personen so nah wie möglich an den zukünftigen
Betriebsrollen zu orientieren. Oder umgekehrt, die Projektrollen so zu gestal-
ten, dass alle Fragen des zukünftigen Betreibens bereits im Projekt geübt wer-
den. Das für den Abbau erforderliche Know-how erwirbt man im Betrieb des
DWH, man denke z.B. an Löschung von Daten mit Datenschutz, den umweltge-
rechten Abbau von Hardware, die lizenzkonforme Destallation von Software.
318 Kapitel 6 • Organisationsstruktur für ein Data Warehouse System

Im Folgenden wird nun die speziell für die drei Lebensabschnitte des DWH –
Aufbau, Betrieb und Abbau – erforderliche Organisation ermittelt, bzw. werden
die in der Praxis zu lösenden Aufgaben dargestellt.
Sinnzusammenhang der Organisation
Organisation steht in einem bestimmten Sinnzusammenhang mit den Aufga-
ben eines Unternehmens. Ein Betrieb wird durch eine Zweckaufgabe begrün-
det, d.h. er verfolgt nach seiner Gründung einen Betriebszweck. Dieser Zweck
ist in Zielen formuliert. Alles, was ein Betrieb macht, ist zielgerichtet, d.h. es
dient der Erreichung seiner Ziele, unabhängig davon, ob diese Ziele tatsächlich
erreicht werden, oder ob sie sich im Laufe der Betriebstätigkeit verändern.

 

  
   
  ! 

  


 
   
 

     
    


 


   

       

Abbildung 6.3: Sinnzusammenhang von Organisation und Betrieb

Der Betrieb verfolgt die Erreichung der Ziele unter Einsatz der ihm zur Verfü-
gung stehenden Mittel. Diese Mittel können als zu kombinierende Faktoren
eines Produktionsprozesses im allgemeinsten Sinne (also auch Ideenproduk-
tion) in Sachmittel, Finanzmittel und Personen gruppiert werden.
Sachmittel sind z.B. Rohstoffe, Informationen, Räume, Energiepotential, Ver-
sorgungssysteme, Menschen, Maschinen, Werkzeuge. Ohne Sachmitteleinsatz
Kapitel 6 • Organisationsstruktur für ein Data Warehouse System 319

bleibt die Tätigkeit rein geistiger Natur. Schon die Dokumentation von Ideen
erfordert Sachmittel. Sachmittel können bzw. müssen erworben werden, und
für die Bezahlung sind Finanzmittel erforderlich. Ohne Finanzmittel können
Sachmittel nicht beschafft werden. Beschaffung und Einsatz von Sachmitteln,
auch die Transaktion von Finanzmitteln zur Beschaffung, werden von Perso-
nen durchgeführt.
Für alle Aktivitäten sind also Handlungsträger erforderlich. In den meisten Fäl-
len sind das Personen, es können aber auch Automaten und Maschinen sein.
Automaten können ursprünglich manuelle Tätigkeiten automatisch ausführen.
Automaten und Maschinen müssen allerdings wiederum von Personen entwor-
fen, konstruiert, gebaut und bedient werden. Ein Unternehmen erfordert eine
Organisation, um das Zusammenwirken seiner Sachmittel, Finanzmittel und
Personen zu koordinieren. Dieses Zusammenführen der Ressourcen und ihr
Zusammenwirken wird mit dem Begriff Faktorkombination bezeichnet.

 

 
 

     





 




Abbildung 6.4: Faktorkombination

Organisationsstruktur
Eine Organisation besteht aus Struktur und Prozessen. Organisationsstruktu-
ren sind ein Potential für Prozesse. Organisationsstrukturen sind ganz allge-
mein eine verfügbare Infrastruktur der Elemente der Unternehmung, die
zusammen auf eine Menge von Grundsubstanzen und Objekte wie Rohstoffe,
Information, Räume, Energiepotential, Versorgungssysteme, Menschen,
Maschinen und Werkzeuge wirken sollen mit dem Ziel, über den kombinierten
Einsatz ein Erzeugnis hervorzubringen. Eine Organisationsstruktur ist damit
eine sinnvolle Ordnung dieser wirkenden und bewirkten Elemente.
Beispiele für Elemente einer Organisationsstruktur sind der Aufbau einer tech-
nischen Anlage, wie im Kapitel »Die Architektur von Data Warehouse Syste-
men« dargestellt, eine Lagerordnung von Ersatzteilen, die hierarchische Glie-
derung der Organisation, die Anordnung der Zufahrtswege zum Unternehmen.
Eine Organisationsstruktur wirkt allerdings noch nicht von selbst. Die Struk-
turelemente müssen bewegt, in Gang gesetzt, in eine Wirkungsfolge gebracht
werden. Diese Wirkungsfolge ist ein Prozess. Ein Prozess ist die zeitliche
320 Kapitel 6 • Organisationsstruktur für ein Data Warehouse System

Abfolge dieses Wirkens, dieser aufeinander einwirkenden Kombination der Ele-


mente der Organisationsstruktur. Ein Prozess besteht daher aus aufeinander-
folgenden oder parallelen Vorgängen, aus Aktivitäten, die Substanzen, Gegen-
stände und Informationen aus Eingangselementen, dem Input, und
Ausgangselementen, dem Output, erzeugen. Die Aktivitäten bedienen sich
dabei des Einsatzes bestimmter Elemente der Organisationsstruktur, der
Arbeitsmittel. Die Arbeitsmittel werden von Personal und von Maschinen einge-
setzt. Das Personal muss für den Einsatz der Arbeitsmittel qualifiziert werden.
Aber alleine mit Strukturieren und Folgendefinition ist noch kein Prozess,
noch keine Aktivität gestartet. Der Prozess, bzw. eine Aktivität muss definiert,
implementiert und auch noch in Bewegung gesetzt werden; es muss festgelegt
werden, wann die Strukturbestandteile in welcher Weise zusammenwirken
müssen. Maschinen, Programme und auch Menschen tragen in sich das Poten-
tial, aktiv zu werden. Manche Menschen nutzen jedoch dieses Potential nicht,
manche Maschinen werden nicht eingesetzt und manche Programmfunktionen
werden nie aufgerufen. Es bedarf auslösender Signale für das Aktivieren von
Funktionen und das Veranlassen von Aktivitäten.
Organisationsproblem
Aus dem Zweck des Betriebes sind mannigfache Organisationsformen abzulei-
ten, die alle in unterschiedlich günstiger Weise den Betrieb zu seiner Zwecker-
füllung führen. Die richtige oder dem Zweck angemessene Organisation zu fin-
den ist ein Gestaltungsproblem, das Organisationsproblem. Ein bewährter
Startpunkt der Lösung eines Organisationsproblems ist die Feststellung des
Objekts, das zu organisieren ist. Das ist bereits geschehen mit der Beantwor-
tung der betriebswirtschaftlichen Aufgaben, der Software zur Unterstützung
der Ausführung der Aufgaben und der Hardware für den Betrieb der Software.
➡ Die Lösung des Organisationsproblems ist die Feststellung, wie Aufbau,
Betrieb und Abbau des DWH organisiert sind. Im Detail:
➥Welche Prozesse sind abzuwickeln, durch die Verkettung von
➥welchen Aufgaben und Handlungen, die von
➥welchen Rollen wahrgenommen werden, die zu
➥welchen Stellen zugeordnet werden müssen, die in
➥welche Organisationsstruktur wie eingebunden werden und dort mit
➥welchen Sachmitteln umgesetzt werden sollen, was
➥welche Qualifikation erfordert?
Dabei kann man auch, statt mit der mesoskopischen Sicht der Unternehmens-
prozesse zu beginnen, mikroskopisch, d.h. mit der Feststellung der personen-
gebundenen Aufgaben starten und diese zu Prozessen zusammenführen oder,
anders ausgedrückt, zu Prozessen organisieren. Eine dritte Möglichkeit ist der
Start mit makroskopischer Sichtweise, das ist die Betrachtung der Unterneh-
mensumwelt.
Kapitel 6 • Organisationsstruktur für ein Data Warehouse System 321

Die Strukturfrage: die organisatorischen W`s


Der Lösung der dargestellten Problematik kann man sich systematisch nähern.
Jeder organisatorische Aufgabenkomplex lässt sich mit den sogenannten orga-
nisatorischen W`s (Fragewörtern) vollständig spezifizieren. Die organisatori-
schen W's können in Gruppen, Strukturfragen und Prozessfragen eingeteilt
werden.

Frage Nachgefragtes organisatorisches Gestaltungsobjekt

Woran Verrichtungsobjekt, Organisationsobjekt, zu bearbeitendes Ding

Was Aktivität, Verrichtung, Aufgabe

Wie Methode, Verfahren der Verrichtung, Technologie

Wer Ressource: Personal, Aufgabenträger

Womit Ressource: Arbeitsmittel, Energie, Information

Wozu Ziel, Zweck, Ergebnis der Aktivität

Weswegen Kompetenz: Erlaubnisse, Befugnisse, Weisungsrechte

Wodurch Fachkompetenz, Qualifikation

Wann Zeitpunkt der Ausführung

Wo Ressource: Lokalität, Raum, Position zur Verrichtung

Tabelle 6.5: Strukturfragen der Organisation

Eine organisatorische Situation ist aber bestenfalls dann vollständig beschrie-


ben, wenn alle Aufgaben, die nach den organisatorischen W`s definiert sind, in
eine Reihenfolge, eine Verknüpfung und Verkettung von Geben und Nehmen
von Informationen und Sachmittel, in eine Kooperation gebracht worden sind.
Zum anderen sind, um wirklich kooperieren zu können, noch Kompetenzen
erforderlich. Beispiel für Kompetenzen sind, Erlaubnisse zu erteilen, Zugangs-
berechtigung zu Räumen zu vergeben, Erteilung von Bestellungen zuzulassen,
Unterschriftenregelungen zu ergänzen, Weisungsbefugnisse zu erteilen und
Qualifikation aufzubauen. Erst diese Weisungskompetenz ermöglicht die Ausü-
bung der Erlaubnisse und Beauftragungen.
Die Prozessfragen
Neben den Strukturfragen müssen die Prozessfragen beantwortet werden. Für
jede Aktivität gibt es einen zu bearbeitenden Eingang an Informationen, Werk-
zeugen, Sachmitteln, nämlich die Zulieferung oder Vorgängeraktivität, die aus
einer vorausgegangenen Aktivität stammt. Die Beschreibung der Aktivität
selbst ist bereits mit der Beantwortung der Strukturfragen gelöst.
322 Kapitel 6 • Organisationsstruktur für ein Data Warehouse System

Was nach der Aktivität passieren soll, ist noch zu klären mit der Nennung der
Nachfolgeaktivität. Der Anstoß zur Ausübung der Aktivität kann die Zuliefe-
rung aus der Vorgängeraktivität oder ein anderes Signal sein. Mit der Verknüp-
fung von Aktivität, Vorgänger, Nachfolger und auslösender Bedingung ist der
Prozess definiert.

Frage Nachgefragtes organisatorisches Gestaltungsobjekt

Wonach Zulieferung, Verkettung der Aktivitäten

Wovor Ablieferung, Verkettung der Aufgaben

Worauf Auslöser: Weisung, Ereignis, Vorfall, Regelung

Tabelle 6.6: Prozessfragen der Organisation

➡ Der Gestaltungsvorgang »Organisation« des DWH ist demnach beendet,


✔ wenn die Aufgaben katalogisiert und beschrieben sind und mit ihrer
Beschreibung die restlichen organisatorischen Strukturfragen geklärt
sind.
✔ die Aufgaben zu Prozessen mit gegenseitigen Informations-, Energie-
und Sachmittellieferbeziehungen verkettet sind und in einer Struktur
von Kompetenzen, Befugnissen und Erlaubnissen eingebettet sind.
Organisationsobjekt
Das Organisationsobjekt oder das Verrichtungsobjekt ist ein Gegenstand oder
eine Idee, die für eine organisatorische Handlung verfügbar ist und an der eine
organisatorische Handlung ausgeübt wird. Ist die Handlung nur eine Planung,
also keine Ausführung am Objekt, ist das Objekt ein Planungsobjekt. So ist zum
Beispiel in einem Produktionsprozess der Rohstoff ein Organisationsobjekt, das
durch Bearbeitung zu einem Produkt wird. Aber auch die Bandstraße, auf der
Rohstoffe befördert werden, ist ein Organisationsobjekt. Genauso sind die zur
Energieversorgung der Bandstraße erforderliche Stromleitung und die entlang
der Bandstraße eingesetzten Werkzeuge Objekte organisatorischen Handelns,
also Organisationsobjekte. Die Bandstraße, die Stromleitung, wie auch die
Werkzeuge sind außerdem Sachmittel zur Verrichtung organisatorischer
Handlungen an einem Organisationsobjekt. Der Unterschied liegt in der primä-
ren Absicht, den Rohstoff zu verändern, und der sekundären Absicht, diese
Veränderung über eine Bandstraße abzuwickeln.

Definition: Organisationsobjekt
Ein Organisationsobjekt oder Verrichtungsobjekt ist das Objekt, an dem pri-
märe organisatorische Handlungen ausgeübt werden.
Kapitel 6 • Organisationsstruktur für ein Data Warehouse System 323

Organisatorische Aufgaben
Die Aufgabenstellung definiert, was mit dem Organisationsobjekt getan werden
muss oder was das Ergebnis der Aktivität sein soll und unter welchen Bedin-
gungen die Aktivität ausgeführt werden soll. Die Tätigkeit an dem Objekt ist
durch eine Handlung, einen Vorgang, eine Reihenfolge von Schritten beschrie-
ben. Eine organisatorische Aufgabe lässt sich also folgendermaßen formulie-
ren: »Am Objekt X ist Y vorzunehmen.« Eine organisatorische Aufgabe kann
auch teleologisch formuliert sein und die Handlung unerwähnt lassen: »Objekt
Y ist zu Objekt Z umzuformen.« Die Bedingungen sind sehr verschiedenartig.
Sie können sein:
✔ Fallregelungen wie: »Wenn Ereignis E passiert ist Aktivität X vorzuneh-
men.«
✔ Anweisungen wie: »Person P sagt, Aktivität X muss vorgenommen werden.«
✔ Terminvorgaben wie: »Bis zum Datum D muss Aktivität X ausgeführt sein.«
✔ Mengenregelung wie: »Aktivität ausführen, bis Menge Z hergestellt ist.«

Definition: Organisatorische Aufgabe


Eine organisatorische Aufgabe ist eine definierte organisatorische Hand-
lung, die an einem Organisationsobjekt oder Verrichtungsobjekt ausgeübt
werden soll.

Je genauer eine organisatorische Aufgabe formuliert ist, umso exakter kann sie
ausgeführt werden. Aber je exakter die organisatorische Aufgaben formuliert
ist, umso weniger Spielraum hat der Handelnde. Eine Abweichung von der Vor-
gabe ist aber bei unvorhergesehenen Vorkommnissen, die die Bedingungen ver-
ändern, unbedingt erforderlich.
Methoden, Technologie, Verfahren
Mit der Methode wird beschrieben, wie die Aufgabe erfüllt werden soll, wenn
alternative Handlungsfolgen möglich sind. Eine Methode beschreibt eine emp-
fohlene Herangehensweise, eine Zergliederung einer komplexen Handlung in
kleinere Handlungseinheiten. Eine Methode ist selbst eine Sammlung »kleiner«
organisatorischer Aufgaben, die, zu einer Abfolge geordnet, über Zwischen-
schritte zur Erfüllung der Aufgabe an einem Objekt führt. Diese »kleinen Aufga-
ben« können aus der »großen Aufgabe«, der organisatorischen Aufgabe an dem
Objekt, durch Zerlegen des Objekts in kleine, handhabungsfreundliche Teile,
entstehen. Für eine Methode ist die Reihenfolge der Handlungen wesentlich.

Definition: Methode
Eine Methode ist eine abgestimmte Reihenfolge von Detailhandlungen, um
eine organisatorische Aufgabe auszuüben.
324 Kapitel 6 • Organisationsstruktur für ein Data Warehouse System

Oft wird neben dem Begriff der Methode der Begriff der Technologie synonym
verwendet. Hier soll unter Methode die abstrakte Schilderung der einzelnen
detaillierten Handlungen verstanden werden und unter Technologie der techni-
sche Produkttyp, von dem die technischen Mittel des Einsatzes sind. Eine
Methode zur Trennung des Verrichtungsobjekts Stahlstange ist zum Beispiel
Schneiden. Die Technologie kann ein Schneidbrenner oder ein Laserstrahl sein.

Definition: Technologie
Eine Technologie ist der technische Produkttyp, zu dem die technischen Mit-
tel des Einsatzes gehören.

Oft wird neben dem Begriff der Methode der Begriff des Verfahrens synonym ver-
wendet. Hier soll unter Verfahren die Folge der organisatorischen Handlungen
nach den Regeln einer Methode zusammen mit ihren Technologien und mit Hilfe
von Werkzeugen an einem oder mehreren Verrichtungsobjekten verstanden wer-
den. Ein Verfahren ist z.B. die Beförderung der Stahlstange bis zur Trennma-
schine, die Trennung des Verrichtungsobjekts Stahlstange mittels der Technolo-
gie Laserstrahl und die anschließende Kühlung der Schnittflächen mit Öl.

Definition: Verfahren
Ein Verfahren ist die abgestimmte Folge des Einsatzes von Methoden nach
Regeln und mit Hilfe von technischen Mittel, den Werkzeugen, an einem
oder mehreren Verrichtungsobjekten.

Aufgabenträger, Rollen, Stellen


Zur Ausübung der Handlung der organisatorischen Aufgabe ist ein handlungs-
fähiges Individuum, ein Aufgabenträger, erforderlich. Ein solches Individuum
kann ein Mensch, ein Tier oder eine Maschine oder eine Maschine mit einer
Software sein.

Definition: Aufgabenträger
Ein Aufgabenträger ist eine Person oder eine Maschine, die eine organisato-
rische Aufgabe ausüben soll.

Kein Mensch der Welt kann alle Aufgaben alleine durchführen, und auch im
Gefüge eines Unternehmens und sogar bei dem, gemessen am Gesamtunter-
nehmen kleinen, Aufgabenbereich DWH fallen so viele Aufgaben an, dass Aufga-
benteilung erforderlich ist. Aufgabenteilung und Aufgabenbündelung auf Auf-
gabenträger führt zu Rollen. Jeder Aufgabenträger, ob Person oder Maschine,
kann mit einer Rolle völlig ausgelastet und zufrieden sein, oder aber mehrere
Rollen ausüben.
Kapitel 6 • Organisationsstruktur für ein Data Warehouse System 325

Rollen können von internen wie auch von externen Aufgabenträgern einge-
nommen werden. Besonders für den Einsatz vorübergehender Kapazitätslasten
lohnt es nicht, dauerhafte Stellen oder Rollen einzurichten. Jobs auf Zeit sind
in Deutschland eher die Ausnahme, was die Alternative des zeitlich und kosten-
technisch begrenzten Einsatzes externen Personals attraktiv macht.

Definition: Rolle
Eine Rolle ist die Zuordnung einer organisatorischen Aufgabe zu einer Per-
son oder einer Maschine, die diese Aufgabe ausüben soll.

Eine Stelle ist einem Aufgabenträger zugeordnet. Eine Stelle ist in ein Gefüge
von Weisungsrechten integriert. Eine Stelle mit Weisungsrecht ist ein Vorge-
setzter von Weisungsempfängern. Zu einer Stelle gehört eine Aufgabenstellung.
Nicht jeder Aufgabenträger muss ein Mensch sein. Aufgaben können in Pro-
grammen realisiert werden und von Maschinen ausgeführt werden. Eine Stelle
kann mehrere Rollen ausüben. So kann z.B. ein Buchhalter auch Betriebsrats-
vorsitzender, Projektleiter für die Einführung der neuen Währung »EURO« und
Mentor für die Integration neuer Mitarbeiter in den Bereich Rechnungswesen
sein.

Definition: Stelle
Eine Stelle ist die Zusammenfassung aller organisatorischen Aufgaben zu
einem Aufgabengebiet genau einer Person.

Organisationsstruktur
Der Begriff »Organisationsstruktur« wird oft synonym mit dem Begriff Organi-
sationshierarchie gebraucht, weil dies die am weitesten verbreitete Struktur der
Weisungsbefugnisse in Unternehmen ist. Die Hierarchie ist nicht die einzige
Struktur einer Organisation und deshalb ist der Begriff »Organisationshierar-
chie« im Sinne der Bedeutung der »Hierarchie« nicht allgemein genug. Besser
ist daher der Begriff Organisationsstruktur.
Die Struktur kann sich im Laufe der Lebenszeit des organisierten Unterneh-
mens wandeln. Die moderne Zeit erfordert schnelle Anpassung der Organisati-
onsstruktur an äußere Bedingungen. Die Organisationsstruktur unterliegt
daher einer laufenden Veränderung. Die Anforderungen aus der Umwelt der
Unternehmen ändern sich so schnell, dass die erfolgreichsten Unternehmen
diejenigen sind, die ihre Organisationsstruktur am schnellsten anpassen kön-
nen. Der Höhepunkt der Anpassungsfähigkeit hat sich in den sogenannten »vir-
tuellen Unternehmen« gefunden, die sich, immer auf eine neue Aufgabenstel-
lung ausgerichtet, neu bilden und nach der Abwicklung der Aufgabe wieder
auflösen.
326 Kapitel 6 • Organisationsstruktur für ein Data Warehouse System

Eine Organisationsstruktur besteht aus Stellen. Die Stellen stehen in einem


Informationslieferungsverhältnis (Berichtsweg). Sie müssen an andere Stellen
Informationen liefern. Viele dieser Informationswege sind vordefiniert. Einige
Informationen müssen in Form von standardisierten Berichten geliefert wer-
den. Die Informationswege, Informationsinhalte und Stellen sind zu einer per-
manenten Struktur organisiert.

Definition: Organisationsstruktur
Eine Organisationsstruktur ist die Zusammenfassung aller Stellen mit ihren
Verbindungen entsprechend ihrer Berichtswege und Beauftragung.

Organisationsstrukturen können selbst das Ergebnis organisatorischer Hand-


lungen sein. Die organisatorische Aufgabe ist dann die »Organisation der Orga-
nisation«. Das Verrichtungsobjekt ist in diesem Falle eine bestehende Struktur
für das Organisieren. Organisation kann von einer bestehenden Organisations-
einheit angeordnet werden oder aus einer bislang unorganisierten Personen-
menge ohne Anordnung von »oben« entstehen, die sogenannte Selbstorganisa-
tion. Organisationsstrukturen können dauerhaft eingerichtet werden oder für
die Dauer der Abwicklung einer Aufgabe oder eines Projekts als Projektorgani-
sation erhalten bleiben. Organisationsstrukturen können auch als spontane
Organisationsstruktur mit dem plötzlichen Aufkommen von Aufgabenstellun-
gen entstehen und sich kurz nach der Erfüllung organisatorischer Aufgaben
wieder auflösen oder über längere Zeiträume erhalten bleiben.
Eine erweiterte Auffassung sieht auch in der Konstellation der nicht-persona-
len Ressourcen (z.B. Räume, Anordnung von Werkbänken und Maschinen in
der Werkstatt, Anordnung und Möglichkeiten von Verkehrswegen, Ausstattung
mit Versorgungsleitungen für Wasser und Strom) eine Organisationsstruktur,
die sogenannte Sachmittelorganisation. Dies macht besonders in sogenannten
Mensch-Maschine-Systemen Sinn, wo Handlungen von Personen auf Automa-
ten übertragen wurden.
Die Organisationsstruktur mittelgroßer Unternehmen ist bereits so komplex,
dass man sich mittels grafischer Darstellung eine bessere Übersicht verschafft.
Zur Darstellung einer Organisationsstruktur dient das Organigramm. Die Dar-
stellung der Organisationsstruktur ist eine Methode und daher Bestandteil
eines Vorgehensmodells, das im folgenden Kapitel »Das Vorgehensmodell für
Data Warehouse Systeme« besprochen wird.
Kompetenzen
In modernen Unternehmen gibt es sehr viel Selbständigkeit und Handlungs-
freiheit, was zwangsläufig die Tendenz zur Verflachung der Hierarchien mit
sich bringt. Handlungsfreiheit setzt Kompetenz und Verantwortung voraus.
Nur wer die Befugnis zur Beschaffung hat, z.B. hinterlegt durch eine Unter-
schriftenprobe, kann auch beschaffen. Der Begriff der Kompetenz wird neben
dem Verständnis als Befugnis oft auch als Kenntnisreichtum, Erfahrung und
Kapitel 6 • Organisationsstruktur für ein Data Warehouse System 327

Fähigkeit, eine bestimmte Aufgabe bewältigen zu können, gebraucht. Zur


Erfüllung von Aufgaben ist also die Erteilung einer Kompetenz durch den Vor-
gesetzten und auch die Bekanntgabe der Kompetenzzuteilung durch den Vor-
gesetzten erforderlich.

Definition: Kompetenz
Kompetenz ist die Erlaubnis zur Ausübung einer organisatorischen Aufgabe.

Ein Projektleiter DWH muss zum Beispiel mit der Kompetenz der Projektüber-
wachung ausgestattet werden. Hierzu gehören die Befugnisse
✔ Einladung zu Besprechungen
✔ Bestellung von Besprechungsräumen
✔ Bedarfsanforderung von Equipment
✔ Abzeichnung der Aufwandsberichte der Mitarbeiter
✔ Berichten an Vorgesetzte in Lenkungsausschüssen
✔ Erteilung von Terminvorgaben
✔ Zuweisung von Aufgaben an Projektmitarbeiter
Qualifikation
Zur Ausübung der Aufgaben einer Stelle oder Rolle ist Befähigung in Form von
Wissen, Erfahrungen zu Vorkommnissen und Risiken, Kenntnisse von Metho-
den, Sachkenntnis über die zu bearbeitenden Objekte und Fertigkeit in der
Anwendung von Sachmitteln erforderlich. Eine Stelle benötigt zur Erfüllung
ihrer Aufgaben eine angemessene Qualifikation. Angemessen bedeutet, dass
weder eine schlechtere Qualifikation (Unterqualifikation) noch eine bessere
Qualifikation (Überqualifikation) geeignet sind.

Definition: Qualifikation
Qualifikation ist die Befähigung zur Ausübung einer organisatorischen Auf-
gabe.

Qualifikation ist erforderlich, um zugeteilte Kompetenzen in die Aufgabener-


füllung einfließen lassen zu können. Es ist zum Beispiel völlig nutzlos, einer
Person die Kompetenz der Leistungsabnahme zuzuteilen, wenn diese Person es
mit ihrer inneren Haltung nicht vereinbaren will, andere Personen zu kontrol-
lieren. Für die Ausübung dieser Kontrollfunktion ist z.B. Führungsqualifika-
tion, Verhandlungsfähigkeit und soziale Kompetenz erforderlich.
328 Kapitel 6 • Organisationsstruktur für ein Data Warehouse System

Sachmittel
Das Wissen des Aufgabenträgers über den Zustand des Verrichtungsobjekts ist
nicht immer aktuell. Die an einem Verrichtungsobjekt auszuübende Tätigkeit
erfordert Informationen. Die Fähigkeiten des Menschen als Handlungsträger
sind physisch und physikalisch begrenzt. Solche Grenzen sind z.B. Muskelkraft,
Fingergröße, Temperaturresistenz, Schnelligkeit, Sehvermögen, Ausdauer. Die
an einem Verrichtungsobjekt auszuübende Tätigkeit erfordert Hilfsmittel. Die
Ausübung einer Aufgabe macht also den Einsatz von Sachmitteln erforderlich.
Sachmittel sind
✔ Werkzeuge
✔ Rohstoffe
✔ Arbeitsmaterial
✔ Energieversorgung
✔ Transportmittel
✔ Halbprodukte
✔ Maschinen
✔ Informationen
✔ Anleitungen
✔ Signalflüsse
Die zu bearbeitenden Objekte sind selbst wieder als Sachmittel für andere orga-
nisatorische Aufgaben einsetzbar. So kann die organisatorische Aufgabe z.B. die
Herstellung von Werkzeugen sein. Mit den Sachmitteln und an den Sachmit-
teln werden die Aktivitäten ausgeübt.

Definition: Sachmittel
Sachmittel sind alle Hilfsmittel, die zur Ausübung einer organisatorischen
Aufgabe eingesetzt werden sollen.

Die Bereitstellung der Sachmittel zur Verwendung bei der Aufgabenerfüllung


ist ein Organisationsproblem. Die Anordnung der Sachmittel, die Lagerung, der
Zugriff, die Erlaubnis der Entnahme ist die Sachmittelorganisation.
Abzugrenzen von den Sachmitteln sind die Finanzmittel. Finanzmittel sind zur
Beschaffung nicht vorhandener Sachmittel erforderlich.

Zusammenfassung der Strukturelemente der Organisationssituation


Im folgenden Diagramm sind die besprochenen Strukturelemente der Organi-
sationssituation mit ihren Wechselbeziehungen zusammengestellt.
Kapitel 6 • Organisationsstruktur für ein Data Warehouse System 329

Ein Aufgabenträger ist in eine Organisationsstruktur integriert. Er hat dort


Kompetenzen und eine entsprechende Qualifikation für den Einsatz von Sach-
mitteln, um die gestellte Aufgabe am Verrichtungsobjekt erfüllen zu können.
Die Sachmittel sind in eine Sachmittel-Organisationsstruktur integriert.

"

 

   

 

 !   
 
 


  
    
  


 
    

  





 

  

 #
 $


 







  






 
  

 

 
 

!!

     



   
   
   
  

Abbildung 6.5: Strukturelemente der Organisationssituation

Prozess, Ablauf, Workflow


Prozesse, Abläufe oder auf »EDV-deutsch« Workflows sind Folgen von Hand-
lungen, Aktivitäten oder Vorgängen. Zum Organisieren der Prozesse gehört die
Einhaltung von Rahmenbedingungen und die Sicherstellung der Ressourcen.
Ohne ausreichende Ressourcen kann ein Prozess nicht abgewickelt werden.
Prozesse sind deshalb nach Dauer, Aufwand und Terminierung zu kalkulieren.

Definition: Prozess, Ablauf, Workflow


Ein Prozess, Ablauf oder Workflow ist eine Folge von Aufgaben, Handlun-
gen, Aktivitäten, Funktionen oder Vorgängen mit der Nennung der Aufga-
benträger und der Hilfsmittel, die zur Ausübung der Aufgabe eingesetzt wer-
den sollen.

Rahmenbedingungen sind auch durch die Verknüpfung mit anderen Prozessen


gegeben. Jeder Prozess erzeugt Ressourcen, Zwischenprodukte, Ergebnisse, die
in anderen Prozessen verwendet werden müssen. Termine, Zeitdauer und Auf-
wände der Prozesse stehen daher in einem Abhängigkeitsverhältnis. Koordina-
tion ist vonnöten. Eine Prozessdefinition muss diesen koordinativen Teil hin-
reichend gut bestimmen.
330 Kapitel 6 • Organisationsstruktur für ein Data Warehouse System

Ein gutes Beispiel für einen Prozess ist das Berichtswesen. Berichte werden
erstellt, indem der Inhalt der Berichte recherchiert und in einer freien Form
oder mittels Standardformularen und Musterberichten festgehalten wird. Der
Inhalt der Berichte wird abgestimmt. Berichte werden verteilt an eine vorher
verabredete Interessenten- oder Betroffenenliste. Der Inhalt der Berichte dient
der Überprüfung getroffener Entscheidung und der Unterstützung neuer zu
treffender Entscheidungen.
Die Ablauforganisation selbst eines kleinen Unternehmens ist bereits so kom-
plex, dass man sich mittels grafischer Darstellungen eine Übersicht verschafft.
Für diese Darstellungen bedient man sich standardisierter Symbole, die zu Dia-
grammen zusammengesetzt werden. Die Darstellung der Ablauforganisation ist
eine Methode und daher Bestandteil eines Vorgehensmodells. Die Methode Dar-
stellung der Ablauforganisation wird daher in Kapitel 7 »Das Vorgehensmodell
für Data Warehouse Systeme« besprochen.
Veränderungen an einem Prozess haben unmittelbare Auswirkungen auf
andere Prozesse. Auf die Schnittstellen von Prozessen ist deshalb besonderes
Augenmerk zu legen. Die Schnittstellenproblematik bleibt oft unbehandelt,
weil die Zuständigkeitsfrage ungeklärt ist. Die entscheidende Frage ist: »Ist der
Empfänger verpflichtet, sich Information zu holen (Holschuld) oder ist der
Sender verpflichtet Information zu bringen (Bringschuld)«.
➡ Da das Einrichten eines DWH Veränderungen von organisierten Prozessen
bewirkt, muss der DWH-Spezialist eine koordinierende Rolle zwischen den
Prozessen und deren Interessenten einnehmen.
Auslöser
Ein Auslöser eines Prozesses ist ein Startsignal für einen Automatismus oder
das Aktivieren eines Willens zu einer Handlung. Ein Auslöser kann eine ein-
zelne Handlung auslösen oder eine ganze Kette aufeinanderfolgender Handlun-
gen. Im zweiten Fall ist der Auslöser der Start für einen Prozess. Beispiel für
einen Auslöser kann die Anordnung einer Behörde, der Anruf eines Kunden, ein
Temperaturgrenzwert, eine Naturkatastrophe oder eine Zeitungsnachricht sein.

Definition: Prozessauslöser
Ein Prozessauslöser startet einen Prozess mit einer Aufgabe aus der Folge
von Aufgaben, Handlungen, Aktivitäten, Funktionen.

Input
Ein Prozess verarbeitet oder bearbeitet die Verrichtungsobjekte. Das zu verar-
beitende Gut ist entweder bereits im Prozess vorhanden oder wird dem Prozess
zugeliefert. In einen Prozess eingehende Objekte sind ein Prozess-Input. Auch
die Sachmittel müssen dem Prozess als Input beigestellt werden. Sachmittel
können bei der Einwirkung auf das Verrichtungsobjekt ebenfalls verändert wer-
Kapitel 6 • Organisationsstruktur für ein Data Warehouse System 331

den. So wird z.B. ein Schweißdraht beim Schweißen verbraucht, Kühlwasser


verdunstet, Werkzeuge nutzen sich ab.

Definition: Input
Ein Input in einen Prozess ist das Verrichtungsobjekt, an dem die Aufgabe,
Handlung, Aktivität, Funktion ausgeübt werden soll, oder ein Sachmittel,
mit dessen Hilfe die Aufgabe, Handlung, Aktivität, Funktion ausgeübt wer-
den soll.

Ein Prozess steht in der Regel in einem Zulieferungs- oder Abnahmeverhältnis.


Ein Input kann Auslöser für einen Prozess sein, z.B. durch das Anstehen eines
neuen Inputs.
Output
Das Ergebnis eines Prozesses liefert der Prozess meistens an einen anderen
Prozess, der weitere Aufgaben an dem Objekt erledigt. Ein Prozess steht in der
Regel in einem Lieferungs- oder Abgabeverhältnis. Die Abgabe ist der Prozess-
Output. Auch die Sachmittel, die dem Prozess als Input beigestellt wurden,
gehören zu diesem Output; sie gehen aber durch die Einwirkung auf das Ver-
richtungsobjekt verändert aus dem Verarbeitungsprozess hervor. So ist die
Menge Schweißdraht durch Schweißen reduziert, Kühlwassermenge ist redu-
ziert, Werkzeuge sind nach der Einwirkung abgenutzt.

Definition: Output
Ein Output aus einem Prozess ist das Verrichtungsobjekt, an dem die Auf-
gabe, Handlung, Aktivität, Funktion ausgeübt wurde, oder ein Sachmittel,
mit dessen Hilfe die Aufgabe, Handlung, Aktivität, Funktion ausgeübt wurde.

Was aus der Sicht des liefernden Prozesses ein Output ist, ist aus der Sicht des
empfangenden Prozesses ein Input. Prozesse sind über Input-Output-Bezie-
hungen vernetzt.
Zu einem Output kann auch einen Auslöser gehören, also neben dem Bereitste-
hen des Outputs zur Abgabe auch ein Signal, dass der Produktionsprozess neue
Rohstoffe aufnehmen kann.

Zusammenfassung der Prozesselemente der Organisationssituation


Ein Prozess besteht aus Aktivitäten. Eine Aktivität erhält einen Input und agiert
nach einem Auslöser. Das Ergebnis der ausgeübten Aktivität ist ein Output. Im
folgenden Diagramm sind die besprochenen Prozesselemente der Organisati-
onssituation mit ihren Wechselbeziehungen zusammengestellt.
332 Kapitel 6 • Organisationsstruktur für ein Data Warehouse System


 


 



     
      


 

  
  
 


 



 
  
  

  
  
 

Abbildung 6.6: Prozesselemente der Organisationssituation

Gestaltungs- und Lösungsmöglichkeiten


Die allgemeine Gestaltungsaufgabe »Organisation« ergibt sich also aus der
Bestimmung der dargestellten Strukturelemente wie Aufgaben, Objekt der Ver-
richtung, Rollen des Personals, Stellen, Eingliederung, Sachmittel, und deren
Zusammenführung zu einem Ablauf.
➢ Bestimmung der Organisationsstruktur mit Definition der Aufgaben,
Zuweisung der Aufgaben zu Rollen, Feststellung des Kapazitätsbedarfs der
Aufgaben, Bündelung der Rollen mit zugehörigen Aufgaben zu Stellen, Ein-
ordnung der Stellen in die Hierarchie des Unternehmens, Definition der
Befugnisse
➢ Bestimmung der Prozesse mit Feststellung der erforderlichen prozeduralen
Regelungen, Definition der Teilnehmer und Träger der Prozesse, Definition
der Zulieferer, Status und Ergebnisse der Prozesse, Festlegung des Berichts-
wesens
➢ Bestimmung der Arbeitsmittel
Sind die Strukturteile der Organisation bestimmt, ist die Struktur noch mit
Leben zu füllen. Die Hauptakteure organisatorischen Geschehens sind, trotz
hohen Automatisierungsgrades der Industrien, Personen. Personen müssen zur
Ausübung ihrer Aufgaben benannt, befugt und qualifiziert werden.
➢ Staffing mit Benennung der Personen, Ermittlung der erforderlichen Quali-
fikation, Allokation der Personalressourcen, Zukauf von temporären exter-
nen Ressourcen, Planung der Schulung

Problemlösung: Regeln und Hilfsmittel


Das Verfahren
Organisation ist teuer und kann deshalb nicht immer wie in einem Selbstbedie-
nungsladen zur freien Verwendung ausgestellt sein. Sie muss immer dann zur
Verfügung stehen, wenn die Zweckaufgabe ansteht. Das heißt, die Organisati-
Kapitel 6 • Organisationsstruktur für ein Data Warehouse System 333

onsbildung für das DWH muss im Zusammenhang mit den Aufbauschritten des
DWH durchgeführt werden.
Eine Ausnahme hiervon ist die Organisation der Bewältigung von Risikositua-
tionen. Das Eintreten des riskanten Ereignisses ist nicht vorhersehbar. Riskante
Situationen erfordern promptes Reagieren. Deshalb muss die Organisation der
Risikoaktivitäten vorbereitet sein. Sie kann nicht erst dann mit dem Aufbau der
Organisation zur Risikobewältigung anfangen, wenn die Risikosituation ein-
tritt. Folglich ist eine optimale Risikoorganisation bereitzuhalten.
Als Problemlösungsmittel für den Entwurf der Organisation dient ein allgemei-
nes, nicht nur für DWH gültiges Verfahren der Organisationsgestaltung, also
eine Richtlinie, in welcher Reihenfolge welche gestalterische Maßnahme
durchgeführt wird. Das folgende Verfahren ist zum Gestalten der Organisation
für ein DWH zu empfehlen:

Verfahren: Organisationsgestaltung
❖ Bestimmung der Prozesse mit Checkliste der prozessualen organisatori-
schen W's
Feststellung der erforderlichen prozessualen Regelungen
Definition der Teilnehmer und Träger der Prozesse
Definition der Zulieferer, Status und Ergebnisse der Prozesse
Festlegung des Berichtswesens, Qualitätssicherung
❖ Organisationsstruktur mit Checkliste der strukturalen organisatorischen
W's
Definition der Aufgaben
Zuweisung der Aufgaben zu Rollen
Kapazitätsbedarf der Aufgaben feststellen
Bündelung der Rollen mit zugehörigen Aufgaben zu Stellen
Einordnung der Stellen in die Hierarchie des Unternehmens
Definition der Befugnisse
Bestimmung der Sach- und Arbeitsmittel
❖ Staffing mit Rollen/Stellen-Schema
Ermittlung der erforderlichen Qualifikation
Allokation der Personalressourcen
Zukauf von temporären externen Ressourcen
Planung der Schulung

Checkliste Organisationsgestaltung
Zur Bestimmung der Organisationssituation dienen die im Kapitel vorgestell-
ten organisatorischen W's. Dabei sollte mit der Sammlung der interessieren-
den Prozesse gestartet werden. Die Prozesse sind aufzulisten und zu identifizie-
ren durch eine Bezeichnung und eine eindeutige Kennzeichnung aus
Nummern und/oder Buchstaben. Jeder Prozess sollte dann durch die Beantwor-
334 Kapitel 6 • Organisationsstruktur für ein Data Warehouse System

tung der drei Prozessfragen beschrieben werden. Zudem müssen die einzelnen
Aktivitäten jedes Prozesses durch Beantwortung der Strukturfragen beschrie-
ben werden. Auch die Aktivitäten innerhalb des Prozesses sind zu identifizieren.
Ein Prozess wird demnach nach dem Schema der Checkliste Organisationssi-
tuation beschrieben.

Identifizierungsnummer Zu Prozess:
Prozess Bezeichnung Aktivität Aktivitätsbezeichnung

Wonach Woran

Wovor Was

Worauf Wie

Wer

Womit

Wozu

Weswegen

Wodurch

Wann

Wo

Tabelle 6.7: Checkliste Organisationssituation

Rollen/Stellen-Schema
Als Hilfsmittel zur Definition von Rollen und deren Zusammenfassung zu Stel-
len dient das Rollen/Stellen-Schema. Im ersten Schritt sind die Rollen zu sam-
meln und anhand der Aufgaben oder der Qualifikation zu beschreiben. Ist die
Rollenliste vollständig, sind die von einer Rolle auszuübenden Aufgaben auf
ihren Zeitbedarf zu beurteilen. Füllt die Aufgabenstellung einer Rolle die für
eine Stelle vereinbarte Arbeitszeit nicht aus, kann die Stelle weitere Rollen aus-
üben. Für diese weiteren Rollen kommen solche in Frage, die in der Nähe der
Qualifikation der bereits der Stelle zugeordneten Rollen liegen. Die Qualifikati-
onen und Kenntnisse sollten sich in einer homogenen Weise ergänzen.

Rolle Kapazität Qualifikation Befugnisse Stelle, Eingliederung

Tabelle 6.8: Rollen/Stellen-Schema


Kapitel 6 • Organisationsstruktur für ein Data Warehouse System 335

Für die Darstellung von Organisationsstrukturen und Prozessen gibt es neben


den hier und im Kapitel 7 verwendeten Diagrammformen viele weitere. Es sei
empfohlen nachzuschlagen in:
 Blum, Betriebsorganisation
 Schmidt, Methoden
 Schmidt, Aufbauorganisation
 Liebelt, Ablauforganisation
Es soll noch angemerkt werden, dass Organisationsgestaltung selbst auch ein
Organisationsobjekt ist und daher auch zu organisieren ist. Organisationsge-
staltung geschieht nicht von selbst, sie ist zu implementieren in Form von Rol-
len, die Organisationsgestaltung ausüben. Dies sind die Manager und in Stabs-
funktion die Organisatoren der Organisationsabteilung.
Die organisatorischen Fragestellungen werden für die Lebensabschnitte Aufbau
und Abbau des DWH in den Kapiteln 8 und 10 erörtert.

6.4 Organisation des Betriebes des DWH


Einleitung
Die Entwicklung des DWH ist zum Zeitpunkt der Einführung oder Implemen-
tierung, oder noch genauer zum Zeitpunkt der Freigabe für den Betrieb, abge-
schlossen. Das heißt, alle Rechner sind beschafft und aufgebaut, die Betriebs-
systeme sind samt allen Utilities installiert, die DWH-Applikationen sind
beschafft, die fehlenden Funktionen sind selbst entwickelt worden, alle Pro-
gramme installiert und konfiguriert. Die Middleware für den Zugriff auf die
Ursprungsdateien sind getestet, der Zugriff ist mit allen Formattransformato-
ren und Struktur-Referenzen eingerichtet. Die Benutzer sind trainiert worden,
und dem Management wurde die Freigabe berichtet.
Ein Data Warehouse Server hat einen Raum, in dem er aufgestellt ist, und
einen Arbeitsplatz, von dem aus er betrieben wird. Die Orte dieser Rechner
müssen nicht notwendigerweise zusammen liegen. Die Anforderungen an die-
sen Raum sind die gleichen wie die Anforderungen, die bereits für die vorhan-
denen Rechner gelten. Die Organisationsarbeit des DWH-Spezialisten endet mit
der Bestellung von Räumlichkeiten bei der Rechenzentrumsorganisation, in die
auch der DWH-Server integriert werden sollte. Die Rechenzentrumsorganisa-
tion bestellt notwendige Erweiterungen bei der Hausverwaltung bzw. der Faci-
lity Management Gruppe, da die Geräte unter anderem in die Überwachung von
Temperatur, Rauchentwicklung, Feuer und Stromversorgung integriert werden
muss.
Zum Betreiben dieser aus Hardware- und Softwarekomponenten bestehenden
Hardware- und Software-Architektur sind Organisationskomponenten zu einer
336 Kapitel 6 • Organisationsstruktur für ein Data Warehouse System

Organisationsarchitektur zusammenzustellen. Diese Organisationskomponen-


ten des DWH-Betriebs sind Betriebssachmittel, Betriebspersonal und eine
Struktur und Regelungen für ihr Zusammenspiel. Zu den Sachmitteln sind die
Räume der Hardware und des Personals zu rechnen.

6.4.1 Aufgaben, Rollen, Stellen für den Betrieb des DWH


Die folgenden Rollen oder auch Stellen der Abbildung »Organigramm des
DWH-Betriebes« sind für den Betrieb eines DWH erforderlich.

      


 
   

$%&  


 


  

 

'!
   

    

 
 
 
$%& 



  !

 ) "
# 
* 
 


    
   

  

  


(

 


 
"(

Abbildung 6.7: Organigramm des DWH-Betriebes

Management DWH-System
Die Leitung eines DWH-Projekts wird nach Beendigung des Projekts nicht
mehr benötigt. Die bei der Durchführung des Projekts entstandene Kenntnis
vom System, seinen Eigenheiten und seinem Verhalten in der Testsituation ist
für das Management des Gesamt-DWH, das DWH-Management, ungeheuer
nützlich, wenn nicht sogar unverzichtbar, und sollte daher in Form der Stelle
DWH-Manager fixiert werden.
Kapitel 6 • Organisationsstruktur für ein Data Warehouse System 337

Die Aufgaben des DWH-Managements sind


✔ Betreuung der Führungsebene der Niederlassungen, Definition und Budge-
tierung von Änderungsprojekten und Änderungsaufträgen
✔ Staffing: Prüfung, ob Kapazitäten und Qualifikationen angemessen sind,
Neubesetzung bei Personalfluktuation, Bestellung externer Kapazität
In einem Großunternehmen, wie zum Beispiel einem Konzern, ist der DWH-
Manager dem für die Gesamt-EDV zuständigen Bereichsleiter unterstellt.
DWH-Systemanalyse
Die Aufgabe der DWH-Systemanalyse ist in der Betriebsphase – mit der bereits
dargestellten Übertragung des Fachwissens der Anwender in die Sprachen der
Programmspezifikationen – fachlich identisch mit der Aufgabenstellung in der
Projektphase zum Aufbau des DWH. Die einzige Einschränkung ist, dass sich
nach der Inbetriebnahme die Spezifikation auf Änderungen und Erweiterungen
bezieht und daher kapazitativ kleiner als im Aufbauprojekt zu bestücken ist.
Die Aufgaben der DWH-Systemanalyse sind während des Betriebes:
✔ Aufnahme von Änderungswünschen
✔ Fachliche Konzeption und Spezifikation von DWH-Applikationsänderungen
✔ Schulung und fachliche Betreuung der Anwender
Der Systemanalytiker ist für die Dauer des Betriebes dem DWH-Manager unter-
stellt.
DWH-Programmierung
Das Know-how der DWH-Programmierung wird auch in der Betriebsphase
beansprucht. Keine Dokumentation ist so gut und verlässlich wie die Auskunft
des Programmierers selbst. Da in einem DWH auf Programmebene ständig
Anpassungen vorzunehmen sind, ist die Einrichtung einer Stelle DWH-Pro-
grammierung angemessen.
Die Aufgaben der DWH-Programmierung sind:
✔ Umsetzung der Änderungsspezifikationen in bestehenden Programmen
Der DWH-Programmierer berichtet an den DWH-Manager.
DWH Systemadministration
Die Aufgabenstellung der DWH-Systemadministration umfasst nach der Ein-
führung die DWH-Entwicklungssysteme, da ja noch Erweiterungen und Ände-
rungen zu erwarten sind, und die Betriebssysteme. Hierzu gehört in erster
Linie die Sicherstellung des Betriebes der freigegebenen Applikationen. Je nach
Umfang des Systems, das ja über alle Länder der Welt verteilte Server umfassen
kann, ist die Rolle DWH-Administrator durch mehrere Stellen über die Länder
verteilt zu besetzen.
338 Kapitel 6 • Organisationsstruktur für ein Data Warehouse System

Eine andere wesentliche Aufgabe ist die permanente Beobachtung des Leis-
tungsverhaltens des Systems, der Performance. Das Performance-Auditing ist
eine Querschnittstätigkeit und dient der Ermittlung von Schwachpunkten des
Gesamtsystems, die sich auf die Antwortzeit und Verfügbarkeit auswirken. Bei
erkannter Ursache wird ein Maßnahmenplan erarbeitet und dessen Umsetzung
eingeleitet.
Die Unterschiedlichkeit der Komponenten erfordert im Wesentlichen verschie-
dene, sich nicht überschneidende Qualifikationen, je nach eingesetzter Soft-
ware und Hardware wie Applikations-Server-Auditing, Applikations-Auditing
und Customizing betriebswirtschaftlicher Standardsoftware, Datenbank-Audi-
ting, Datenbank-Server-Auditing. Jede Qualifikation umfasst sowohl alle spezi-
fischen Tools, das zugehörige Betriebssystem einschließlich der Utilities sowie
die Systemadministration der Applikationskomponente. Darüber hinaus ist
diese Qualifikation mit der speziellen Konfiguration der Kunden detailliert ver-
traut und bezüglich des Zusammenwirkens aller Systemkomponenten über-
blicksartig informiert. Ein Bündel von Kenntnissen, das keine Stelle alleine in
sich vereinen kann.
Die Aufgaben der DWH-Systemadministration sind:
✔ Konfiguration und Skalierung der Rechner-Hardware und der Betriebssys-
teme, Installation der Server-Komponenten
✔ Aufrechthalten der Betriebsverfügbarkeit von Rechnern und Netzen für die
Entwickler und Benutzer
✔ Datensicherung aller Ergebnisse
✔ Applikations-Server-Auditing
✔ Applikations-Auditing und Customizing betriebswirtschaftlicher Standard-
software
✔ Datenbank-Auditing
✔ Datenbank-Server-Auditing
Der Systemadministrator berichtet sowohl an den EDV-Leiter, dem der Betrieb
der Rechner unterstellt ist, als auch an den DWH-Manager.
PC- Betreuung
Die PC-Betreuung ist bereits vor der Installation eines DWH vorhanden, die
DWH-User werden bereits betreut, die Betreuung umfasst jedoch noch nicht
die DWH-Komponenten der Clients. Die PC-Betreuung ist daher für die neuen
Komponenten zu qualifizieren, der Leistungsumfang in den Serviceverträgen
entsprechend um die DWH-Komponenten der Clients zu erweitern.
Die neuen Aufgaben der bereits bestehenden PC-Unterstützung sind:
✔ Überwachung von Lieferung und Installation, Abnahme der DWH-Client-
Komponenten und ihrer Updates
Kapitel 6 • Organisationsstruktur für ein Data Warehouse System 339

✔ Beurteilung der Aufstockung der PC-Hardware entsprechend den Anforde-


rungen der DWH-Komponenten der Clients
Die PC-Betreuung bleibt weiterhin im bestehenden Unterstellungsverhältnis.
DWH-Benutzer
Die DWH-Benutzer müssen sicherstellen, dass das Fachwissen, das in den
Applikationen abgebildet werden soll, auf aktuellstem Stand bereitgestellt wird.
Sie sind für die Richtigkeit der Daten verantwortlich und haben einen großen
Einfluss auf die Ergonomie der Anwendungen. Die Benutzer prüfen die Anwen-
dungen auf Stimmigkeit der Ergebnisse.
Die Aufgaben der DWH-Benutzer sind:
✔ Bereitstellung des Fachwissens in Form von Unterlagen, Interviewaussagen
✔ Testen der Ergonomie und der fachlichen Stimmigkeit der Anwendungen,
Pflege der Daten
Die DWH-Benutzer sind zeitweise in Teams zur