Diplomarbeit - Hochschule Wismar

Hochschule Wismar
Fachbereich Wirtschaft
Diplomarbeit
Erstellung eines dynamischen Reportingmoduls auf
Grundlage einer operativen Unternehmensdatenbank
Diplomarbeit zur Erlangung des Grades
Diplom-Wirtschaftsinformatiker (FH)
der Hochschule Wismar
eingereicht von:
Martin Behrndt
geboren am 29. Oktober 1980 in Stralsund
Studiengang Wirtschaftsinformatik
Matrikel Nr. : 101045
Betreuer:
Prof. Dr. J. Cleve
Prof. Dr. Ing. U. Lämmel
Wismar, den 28. Mai 2006
Inhaltsverzeichnis
I
Einleitung
1
1
Einleitung und Problemstellung
2
1.1
Motivation der Ausarbeitung . . . . . . . . . . . . . . . . . . . . . .
2
1.2
Einordnung der Problemstellung . . . . . . . . . . . . . . . . . . . .
3
II
2
Theorie
4
Allgemeine Begriffserklärung
5
2.1
Reporting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5
2.2
Datenbanksysteme . . . . . . . . . . . . . . . . . . . . . . . . . . .
6
2.2.1
Relationale Datenbanken . . . . . . . . . . . . . . . . . . . .
7
2.2.2
Multidimensionale Datenbanken . . . . . . . . . . . . . . . .
9
Relational versus Multidimensional . . . . . . . . . . . . . . . . . .
10
2.3.1
Anwendungsorientierte Ebene . . . . . . . . . . . . . . . . .
10
2.3.2
Datenmodellierungsebene . . . . . . . . . . . . . . . . . . .
12
2.3.3
Darstellungsorientierte Ebene . . . . . . . . . . . . . . . . .
12
Informationssysteme . . . . . . . . . . . . . . . . . . . . . . . . . .
13
2.4.1
Definition . . . . . . . . . . . . . . . . . . . . . . . . . . . .
13
2.4.2
Anforderungen . . . . . . . . . . . . . . . . . . . . . . . . .
13
2.4.3
Informationsbedarf . . . . . . . . . . . . . . . . . . . . . . .
14
MIS-Konzepte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
15
2.5.1
Begriff . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
15
2.5.2
Management Information Systems . . . . . . . . . . . . . . .
16
2.5.3
Management Reporting Systems . . . . . . . . . . . . . . . .
17
2.5.4
Decision Support Systems . . . . . . . . . . . . . . . . . . .
17
2.5.5
Executive Information Systems . . . . . . . . . . . . . . . .
18
2.5.6
Data Warehouse . . . . . . . . . . . . . . . . . . . . . . . .
19
2.5.7
Online Analytical Processing . . . . . . . . . . . . . . . . . .
24
Client-Server Architektur . . . . . . . . . . . . . . . . . . . . . . . .
25
2.3
2.4
2.5
2.6
I
INHALTSVERZEICHNIS
III
3
Praxis
Ausgangssituation
28
3.1
Das MedienHaus Rostock . . . . . . . . . . . . . . . . . . . . . . . .
28
3.2
Grundgedanken . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
30
3.3
Die manuelle Auswertung . . . . . . . . . . . . . . . . . . . . . . .
31
3.4
Auswertungsanalyse . . . . . . . . . . . . . . . . . . . . . . . . . .
32
3.4.1
Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . .
32
3.4.2
Definition und Vorgehen . . . . . . . . . . . . . . . . . . . .
33
3.4.3
Ergebnisse . . . . . . . . . . . . . . . . . . . . . . . . . . .
34
Grundsätzliche Schwierigkeiten . . . . . . . . . . . . . . . . . . . .
35
3.5.1
Sprachprobleme . . . . . . . . . . . . . . . . . . . . . . . .
36
3.5.2
Abfrageerstellung . . . . . . . . . . . . . . . . . . . . . . . .
37
3.6
Erweiterung der Problemstellung . . . . . . . . . . . . . . . . . . . .
38
3.7
Lösungsmöglichkeiten . . . . . . . . . . . . . . . . . . . . . . . . .
39
3.7.1
OLAP und Data Warehouse . . . . . . . . . . . . . . . . . .
39
3.7.2
Externe Berichtswerkzeuge . . . . . . . . . . . . . . . . . .
41
3.7.3
Eigene Entwicklung . . . . . . . . . . . . . . . . . . . . . .
42
3.5
4
Software Engineering
43
4.1
Anforderungsdefinition . . . . . . . . . . . . . . . . . . . . . . . . .
43
4.1.1
Zielbestimmung . . . . . . . . . . . . . . . . . . . . . . . .
44
4.1.2
Produkteinsatz . . . . . . . . . . . . . . . . . . . . . . . . .
44
4.1.3
Produktübersicht . . . . . . . . . . . . . . . . . . . . . . . .
45
4.1.4
Produktfunktionen, -daten und -leistungen . . . . . . . . . . .
46
Konzeption . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
46
4.2.1
Grobkonzept . . . . . . . . . . . . . . . . . . . . . . . . . .
47
4.2.2
Feinkonzept . . . . . . . . . . . . . . . . . . . . . . . . . . .
48
Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
50
4.3.1
Verbale Beschreibung . . . . . . . . . . . . . . . . . . . . .
50
4.3.2
Komponentenüberblick . . . . . . . . . . . . . . . . . . . . .
52
4.3.3
Datenbankkomponente . . . . . . . . . . . . . . . . . . . . .
53
4.3.4
Query-Engine . . . . . . . . . . . . . . . . . . . . . . . . . .
56
4.2
4.3
5
27
Umsetzung
61
5.1
Aufbau der Tabellenstruktur . . . . . . . . . . . . . . . . . . . . . .
61
5.1.1
Konventionen . . . . . . . . . . . . . . . . . . . . . . . . . .
61
5.1.2
Besonderheiten der Laufzeitumgebung . . . . . . . . . . . .
62
5.1.3
Das RPE-Datenmodell . . . . . . . . . . . . . . . . . . . . .
63
II
INHALTSVERZEICHNIS
5.2
6
Implementierung des Projektions-Moduls . . . . . . . . . . . . . . .
Schlussfolgerungen und Fazit
63
66
IV Anhang
VI
Ehrenwörtliche Erklärung
VII
Abkürzungsverzeichnis
VIII
Literaturverzeichnis
X
Stichwortverzeichnis
XII
A SQL_Analyser.pl
XIII
B Datenblätter Berichtswerkzeuge
XVII
B.1 Business Objects Crystal Reports . . . . . . . . . . . . . . . . . . . . XVII
B.2 Cognos ReportNet . . . . . . . . . . . . . . . . . . . . . . . . . . . XVII
B.3 Microsoft Reporting Services . . . . . . . . . . . . . . . . . . . . . . XVII
C Detailbeschreibung des Datenmodells
XXVII
D Inhalt der Begleit-CD
XXXII
III
Abbildungsverzeichnis
2.1
Aufbau eines Datenbanksystems . . . . . . . . . . . . . . . . . . . .
6
2.2
relationale Beispieltabellen . . . . . . . . . . . . . . . . . . . . . . .
8
2.3
Würfelmetapher . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
9
2.4
Einordnung der MIS-Konzepte . . . . . . . . . . . . . . . . . . . . .
15
2.5
Aufbau eines MIS . . . . . . . . . . . . . . . . . . . . . . . . . . . .
16
2.6
Aufbau eines DSS . . . . . . . . . . . . . . . . . . . . . . . . . . . .
18
2.7
Daten- und Informationsfluss im DWH-Modell . . . . . . . . . . . .
20
2.8
Sprachkonflikte im Datawarehouse . . . . . . . . . . . . . . . . . . .
21
2.9
Data Warehouse-Architekturen . . . . . . . . . . . . . . . . . . . . .
23
2.10 3-Schichten Architektur . . . . . . . . . . . . . . . . . . . . . . . . .
26
3.1
Verbindung KDB-MHR . . . . . . . . . . . . . . . . . . . . . . . . .
31
3.2
Ablauf einer manuellen Auswertung . . . . . . . . . . . . . . . . . .
31
3.3
graphischen Darstellung der Auswertungsanalyse . . . . . . . . . . .
34
4.1
Die ReportingEngine im Anwendungskontext . . . . . . . . . . . . .
45
4.2
Use Case Diagramm des Grobkonzeptes . . . . . . . . . . . . . . . .
47
4.3
Use Case: Abfragefragmente definieren . . . . . . . . . . . . . . . .
48
4.4
Use Case: Auswertung zusammenstellen . . . . . . . . . . . . . . . .
49
4.5
Aktivitätsdiagramm: Abfrage zusammenstellen . . . . . . . . . . . .
49
4.6
Komponentenüberblick . . . . . . . . . . . . . . . . . . . . . . . . .
52
4.7
ERD der administrativen Daten . . . . . . . . . . . . . . . . . . . . .
53
4.8
ERD der Nutzerdaten . . . . . . . . . . . . . . . . . . . . . . . . . .
54
4.9
ERD der Ergebnisdaten . . . . . . . . . . . . . . . . . . . . . . . . .
55
4.10 ERD des gesamten Datenmodells . . . . . . . . . . . . . . . . . . . .
56
4.11 beispielhafte Projektion und Speicherung aus Datensicht . . . . . . .
58
4.12 Programmablaufplan von Projektion und Datenspeicherung . . . . . .
59
5.1
64
Datenmodell des Reporting-Moduls . . . . . . . . . . . . . . . . . .
IV
Tabellenverzeichnis
2.1
Nutzengetriebene Unterschiede zwischen OLTP und OLAP . . . . . .
11
2.2
DBS-getriebene Unterschiede zwischen OLTP und OLAP . . . . . .
11
2.3
Darstellung Relation und Cube . . . . . . . . . . . . . . . . . . . . .
12
5.1
Suffixe in der KDB . . . . . . . . . . . . . . . . . . . . . . . . . . .
62
V
Teil I
Einleitung
1
Kapitel 1
Einleitung und Problemstellung
1.1
Motivation der Ausarbeitung
In Anbetracht zunehmender Globalisierung, steigender Markttransparenz sowie der
verstärkten Austauschbarkeit von Produkten und Dienstleistungen vergrößert sich der
Bedarf an entscheidungsstützenden Werkzeugen immer weiter. Gleichzeitig wächst die
Anzahl der zur Verfügung stehenden Informationen und damit auch ihre Bedeutung
für den wirtschaftlichen Erfolg eines Unternehmens [FROS03]. Jedoch wäre es weit
gefehlt zu behaupten, mehr Informationen sei gleichbedeutend mit mehr Erfolg. Vielmehr gilt es die Devise „die richtige Information zur richtigen Zeit am richtigen Ort“
umzusetzen.
Als Konsequenz wurde in den letzten Jahrzehnten eine Reihe von Ansätzen entwickelt, um vorhandene Daten und Informationen zur Entscheidungsstützung zu nutzen.
Die Grundlage moderner Systeme bilden dabei zumeist analytische Datenbanken, welche neben den operativen Datenbanken und Informationssystemen betrieben werden.
Kleine, mittelständische und zum Teil auch größere Unternehmen scheuen nicht selten
Aufwand und Kosten für die Erstellung und den Betrieb solcher Datenbanksysteme.
Bei anderen Unternehmen ist die Integration solcher Systeme in bestehende Strukturen
nicht ohne Weiteres möglich. Analytische Datenbanken sind jedoch, zumindest theoretisch, die Grundlage für effiziente, schnelle und umfassende Datenanalysen, auch
wenn die Wirtschaftlichkeit dieser Systeme nur schwer messbar ist.
Ein weiteres Problem, das wachsende Datenbestände mit sich bringen, ist die zunehmende Trennung von Datenspeicherung und Datenverwendung. Dieses Vorgehen verbessert zwar auf der einen Seite die Sicherheit, die Widerverwendbarkeit und die Effizienz der Verwaltung der Daten, verhindert jedoch auf der anderen Seite die Daten2
1.2. EINORDNUNG DER PROBLEMSTELLUNG
verwendung ohne Programm- oder Administratorunterstützung. Eine nutzergesteuerte
Datenanalyse wird allein dadurch unmöglich das dem Nutzer das Wissen fehlt wie er
an die zu analysierenden Daten gelangt.
In dieser Ausarbeitung soll versucht werden, einen geeigneten Kompromiss für den
Zielkonflikt zwischen Kosten und Notwendigkeit von entscheidungsstützenden Maßnahmen zu finden. Als Lösungsmöglichkeit wird ein Reportingmodul, das Daten nutzergesteuert aus der Datenbank eines operativen Informationssystems auslesen, aufbereiten und darstellen kann, vorgeschlagen.
Mit diesem System als Grundlage wird es in späteren Projekten möglich sein, einen
Großteil an entscheidungsrelevanten Datenanalysen durchzuführen, ohne neben dem
Informationssystem eine analytische Datenbank betreiben zu müssen.
1.2
Einordnung der Problemstellung
Die Einordnung des Problems in ein bestimmtes Themengebiet ist äußerst schwierig. Viele Konzepte aus der Literatur tangieren ähnliche Probleme, jedoch sind ihre
Betrachtungsweisen oft zu speziell oder eingeschränkt. Der angebotene Lösungsvorschlag wird sich aus diesem Grund an einigen Konzepten orientieren und gegebenenfalls Vorgehensweisen miteinander kombinieren. Um dem Leser die Möglichkeit zu
geben, diesen Prozess nachzuvollziehen, wird im Kapitel 2 kurz und prägnant auf die
folgenden Konzepte eingegangen:
• Informationssysteme (IS)
• Management Information System (MIS)
• Decision Support Systems (DSS)
• Executive Information System (EIS)
• Data Warehouse (DWH)
• Online Analytical Processing (OLAP)
Das durch diese Ausarbeitung betroffene Themengebiet wird als „Reporting“ bezeichnet werden.
3
Teil II
Theorie
4
Kapitel 2
Allgemeine Begriffserklärung
Dieses Kapitel wird die begrifflichen Grundlagen für den praktischen Teil der vorliegenden Ausarbeitung schaffen. Neben Begriffsdefinitionen werden zusätzlich historische Entwicklungen beschrieben, um daraus entstandene Zusammenhänge zu verdeutlichen.
2.1
Reporting
Unter dem Begriff des Reportings bzw. Berichtswesens werden alle Mittel und Maßnahmen zur Beschaffung, Verarbeitung, Speicherung und Weiterleitung von Informationen in Form eines Berichtes verstanden. Dabei ist ein Bericht im Kontext dieser
Ausarbeitung als zweckgebundene, meist tabellarische Zusammenstellung von Informationen anzusehen. Der Zweck eines Berichtes liegt in der Informationsversorgung
der operativen und strategischen Einheiten eines Unternehmens.
In der Literatur findet sich das Berichtswesen zumeist als integriertes Werkzeug des
Controllings oder Rechnungswesens wieder, dessen Aufgabe darin besteht, dem gehobenen Management unternehmensbezogene Informationen, Kennzahlen sowie ergebnisverbessernde Maßnahmen zu präsentieren. [SCHU01, S.22 ff.] Diesem Bild soll
das Reporting in dieser Ausarbeitung nicht entsprechen. Stattdessen ist es zwar als
Werkzeug zur Informationsbeschaffung zu verstehen, jedoch beschränkt sich die Zielgruppe nicht auf das gehobene Management und die Bewertung der Information liegt
allein beim Empfänger.
5
2.2. DATENBANKSYSTEME
Weiterhin soll das Reporting folgenden Anforderungen1 genügen:
• Wahrheit: Berichte müssen inhaltlich und strukturell korrekt sein.
• Klarheit: Berichte müssen dem Empfänger begrifflich verständlich sein. Dazu
gehören u. a. Aufbau und Nutzung eines einheitlichen Vokabulars, um Missverständnisse und Verwechslungen zu vermeiden.
• Sicherheit: Berichte müssen unter Beachtung bestehender Berechtigungskonzepte erstellt werden. Darüber hinaus müssen sie den jeweiligen gesetzlichen
Bestimmungen genügen.
2.2
Datenbanksysteme
Ist umgangssprachlich von einer Datenbank die Rede, ist meistens ein Datenbanksystem (DBS) gemeint.
Ein DBS ist ein System zur elektronischen Datenverwaltung, dessen wesentliche Aufgabe darin besteht, große Datenmengen zu speichern und für Abfragen durch mehrere
Benutzer bzw. Anwendungen bereitzustellen. Ein DBS besteht aus zwei Komponenten: der Verwaltungssoftware2 , die als Datenbank-Management-System (DBMS) bezeichnet wird, und dem eigentlichen Datenspeicher, der Datenbank.
Abbildung 2.1: Aufbau eines Datenbanksystems
Das DBMS stellt das Herzstück eines DBS dar. Hierbei handelt es sich um hoch komplexe Software zur Datenverwaltung, die u. a. das Speichern, Ändern, Löschen und
Lesen von Daten, unter Berücksichtigung von Aspekten wie Mehrbenutzerbetrieb, Datenintegrität und -sicherheit, übernimmt. Wie Abbildung 2.1 zeigt, ist ein DBMS nicht
1
2
In Anlehnung an [WEREP].
Abbildung 2.1 verdeutlicht diesen Zusammenhang.
6
2.2. DATENBANKSYSTEME
auf eine Datenbasis beschränkt, sondern verwaltet i. d. R. mehrere gleichzeitig. Die eigentliche Datenbank ist lediglich der logische und physische3 Speicherort von Daten,
die i. d. R. inhaltlich zusammengehörig sind.
2.2.1
Relationale Datenbanken
Speichert ein DBS Daten in relationaler Form, wird von einem relationalen Datenbanksystem (RDBS) gesprochen. Weit verbreitete RDBS sind z. B. mySQL, ORACLE,
MsSQL, DB2 und dBase. Analog zum DBS wird bei einem DBMS, das relational gespeicherte Daten verwaltet, von einem relationalen Datenbank-Management-System
(RDBMS) gesprochen.
RDBS stellen zur Zeit eines der wichtigsten Systeme zur Datenspeicherung dar. Neben
der Kommunikationsinfrastruktur zählen sie zu den Schlüsseltechnologien des Informationszeitalters. Sie bieten die Möglichkeit, Daten sicher, konsistent und effizient im
Hinblick auf den benötigten Speicherplatz mehrbenutzerfähig zu speichern, abzufragen, zu bearbeiten und zu löschen. Dieser Abschnitt soll dazu dienen, die Grundgedanken und -begriffe der relationalen Datenbanktechnologie zu vermitteln. Dabei soll
vor allem auf das Relationenmodell und die Normalisierung eingegangen werden.
Relationenmodell
Das Relationenmodell, welches die Grundlage eines jeden RDBS darstellt, wurde Anfang der siebziger Jahre von E. F. Codd entwickelt. Im Wesentlichen beschreibt es die
Verwaltung von Daten in zweidimensionalen Tabellen, die über Schlüsselattribute miteinander verknüpft werden können. Eine Tabelle gemäß dem Relationenmodell ist wie
folgt aufgebaut [MEIE04, S. 3 f.]:
• Eine Tabelle besitzt einen eindeutigen Namen.
• Die Spalten einer Tabelle werden als Attribute bezeichnet.
• Innerhalb einer Tabelle sind Attributnamen eindeutig.
• Attributwerte sind atomar.
• Die Zeilen einer Tabelle werden als Tupel bezeichnet.
• Innerhalb einer Tabelle sind Tupel eindeutig.
• Das Attribut bzw. die minimale Attributkombination, die ein Tupel innerhalb
einer Tabelle eindeutig identifiziert, wird als Primärschlüssel bezeichnet.
• Die Reihenfolge und Anordnung von Attributen und Tupel ist bedeutungslos.
3
Kleine Datenmengen werden meist in einer, größere verteilt auf mehrere Dateien gespeichert.
7
2.2. DATENBANKSYSTEME
Normalisierung
Die Normalisierung ist ein wichtiges Mittel zur Konsistenzsicherung, die diese durch
Redundanzminimierung realisiert. Insgesamt gibt es sechs Normalformen. An dieser
Stelle wird sich jedoch auf die Darstellung der ersten drei beschränkt, da diese in der
Praxis zumeist ausreichend sind. [MEIE04, S. 34ff.]
• 1NF: Eine Tabelle ist in erster Normalform, wenn ihre Attributwerte atomar
sind.
• 2NF: Eine Tabelle befindet sich in zweiter Normalform, wenn sie der ersten
Normalform genügt und jedes Nichtschlüsselattribut von jedem Schlüssel voll
funktional abhängig ist.
• 3NF: Eine Tabelle ist in dritter Normalform, wenn sie sich in zweiter Normalform befindet und kein Nichtschlüsselattribut von einem Schlüssel transitiv abhängt.
Abbildung 2.2: Aufbau eines Datenbanksystems
Abbildung 2.2 zeigt vier Tabellen, an denen die Grundzüge der relationalen Datenmodellierung beispielhaft skizziert werden sollen. Tabelle a) enthält Beispieldaten und
befindet sich bereits in erster Normalform. Die Tabellen b) bis d) sind das Ergebnis der
Normalisierung und befinden sich in dritter Normalform. Es ist zu erkennen, dass Normalisierung zur Verteilung der Daten auf mehrere Tabellen führt. Um die Beziehungen
der Werte untereinander zu erhalten, werden Referenzen benutzt, die als Fremdschlüssel bezeichnet werden. Fremdschlüssel verweisen immer auf den Primärschlüssel der
referenzierten Tabelle.
8
2.2. DATENBANKSYSTEME
2.2.2
Multidimensionale Datenbanken
Obwohl multidimensionale Datenbankensysteme in der Literatur4 oft als OLAPDatenbanken bezeichnet werden, sollen ihre Charakteristika in dieser Ausarbeitung
allgemein im Themenbereich der Datenbanken beleuchtet werden. Dennoch ist die Bezeichnung OLAP-Datenbanken im Grunde nicht unberechtigt, denn die Blütezeit5 der
multidimensionalen Datenbankensysteme begann mit dem Aufkommen von OLAPSystemen und diese sind auch heute noch die Hauptnutzer dieser Technologie.
Unter einem multidimensionalen Datenbanksystem (MDBS), wird ein Datenbanksystem verstanden, das die auf konzeptioneller Ebene mehrdimensional dargestellten Datenstrukturen auch physisch in mehrdimensionalen Datenbank- und Speicherstrukturen
umsetzt. [LEHN99, S. 37ff.]
Abbildung 2.3: Der Würfel als Metapher für mehrdimensionale Daten
Der Grundgedanke besteht darin, den Datenbestand als mehrdimensionalen Würfel
darzustellen, wobei die quantitativen Daten den Zellen und die qualitativen den Kanten
entsprechen. Abbildung 2.3 zeigt beispielhaft einen dreidimensionalen Würfel6 . Das
multidimensionale Datenmodell gestaltet sich wesentlich einfacher als das relationale.
Es ist wie folgt aufgebaut [CLAU98, S. 20]:
• Jede Zelle wird durch die Angabe der Ausprägungen der Dimensionen eindeutig
identifiziert.
• Jede Zelle besitzt einen Inhalt, der auch leer sein kann.
Der Würfel in Abbildung 2.3 zeigt einen Teil der in Abbildung 2.2 relational modellierten Beispieldaten. Um den Begriff der Würfelmetapher zu wahren, wurde jedoch
der Maßstab missachtet.
4
5
6
Z. B. [CLAU98], [LEHN99], [HOLT99], [OEHL00].
Die Anfänge lassen sich bis in die frühen sechziger Jahre zurück verfolgen.
Ein multidimensionales DBS kann auch mehr als drei Dimensionen darstellen.
9
2.3. RELATIONAL VERSUS MULTIDIMENSIONAL
Das klassische MDBS zeichnet sich dadurch aus, dass es seine Daten direkt auf einen
physischen Speicherbereich aufteilt. Der Zugriff erfolgt ähnlich wie im mehrdimensionalen Array direkt, da die Adresse jedes Datums einfach berechenbar ist. Der Datenzugriff ist damit sehr schnell. Allerdings hat diese Speicherform den gravierenden
Nachteil, dass für die Speicherung der Daten nicht soviel Platz benötigt wird wie es
Daten gibt, sondern soviel wie es Daten geben könnte.
Als Konsequenz werden in der Praxis oft multidimensionale Daten mit Hilfe von relationalen Datenbanken gespeichert. Das prominenteste Beispiel sind die in Abschnitt
2.5.6 beschriebenen DWH.
2.3
Relational versus Multidimensional
Grundsätzlich ist zu sagen, dass RDBS und MDBS auf Grund der Verschiedenheit ihrer Konzeption zwar schlecht vergleichbar sind, Unterschiede und damit auch Stärken
und Schwächen aber so am besten sichtbar sind. Es sollen Unterschiede auf drei Ebenen aufgezeigt werden: die anwendungsorientierte, die Datenmodellierungs- und die
darstellungsorientierte Ebene.
2.3.1
Anwendungsorientierte Ebene
Zur Ermittlung der Unterschiede wird für jedes Konzept jeweils die in der Praxis meist
auftretende Verwendungsform gewählt. Für RDBS ist es das Online Transaction Processing (OLTP). MDBS werden meist in OLAP-Systemen eingesetzt, so auch hier.
Tabelle 2.1 charakterisiert die verschiedenen Einsatzbereiche der beiden Konzepte. Dabei wird deutlich, dass im Mittelpunkt von OLAP die Analyse von historischen Daten
steht. Im Gegensatz dazu werden OLTP-Systeme zur Haltung von aktuellen Daten eingesetzt.
Tabelle 2.2 zeigt die datenbanktechnischen Unterschiede zwischen OLTP und OLAP.
Dabei sei darauf hingewiesen, dass unter OLAP-Datenbanken in der Praxis oft die
in Abschnitt 2.2.2 angesprochenen RDBS zur Speicherung von mehrdimensionalen
Daten verstanden werden. Nur diese Systeme sind in der Lage, Terrabytes an Daten
aufzunehmen und zu verwalten.
10
2.3. RELATIONAL VERSUS MULTIDIMENSIONAL
Online Transaction Processing
Online Analytycal Processing
- Administration / Kontrolle
- Entscheidungsstützung
bereich
⇒ operative Datenverarbeitung
⇒ dispositive Datenverarbeitung
Art und Einheit
- sich wiederholende, struktur-
- Ad-hoc-Zugriffe für interaktive
Anwendungs-
der Interaktion
ierte, überwiegend vordefinierte
Zugriffe
Datenexploration
- vordefinierte Zugriffe für
⇒ Transaktion
Standardberichte
⇒ Statistische Analyse
Verarbeitungs-
- Einfüge-, Änderungs- und
- überwiegend lesender und
einheiten und
Löschoperationen von über-
aggregierender Zugriff auf
charakteristik
wiegend einzelnen, in einer
große Teile des Gesamtdaten-
Transaktion geklammerten,
bestandes
Datensätzen
⇒ ’append-only’ Semantik
⇒ ’update in place’-Semantik
Zentraler Fokus
⇒ ’Data In’
⇒ ’Information Out’
Tabelle 2.1: Nutzengetriebene Unterschiede zwischen OLTP und OLAP
Art der zu
verwaltenden
Online Transaction Processing
Online Analytycal Processing
- aktuelle und sich dynamisch
- bereinigte, historische und
ändernde Werte
statistische Einzeldaten
Information
Design des
konzeptionellen
Schemas
- verdichtete Stammdaten
⇒ Datenisolierung
⇒ Datenkonsolodierung
- anwendungsorientiert (auf
- themenbezogen teilweise
Basis des ER-Modells)
- hochgradig Normalisiert mit
dem Ziel der Redundanzfreiheit
Nebenläufigkeit
denormalisierte Schemata
(Star-/Snowflake)
- gezielte Verletzung der
Redundanzfreiheit
- hoch bis extrem hoch
- von geringem Interesse
- Einhaltung der ACIDEigenschaften
Physische
- einzelsatzorientierer Zugriff
- verlaufsorientiert, verdichtend
Zugriffs-
- Index-/Hashzugriff über
- sequenzieller Lesezugriff
charakteristika
Datenbankgröße
Primärschlüssel
(Scan-Operationen)
- 10 Megabyte bis mehrere
Gigabyte
Geforderte
Antwortzeiten
- 5 Gigabyte bis mehrere
Terrabyte
- Bruchteile von Sekunden
(maximal 2-3 Sekunden)
- Sekunden bis zu wenigen
Minuten
Tabelle 2.2: DBS-getriebene Unterschiede zwischen OLTP und OLAP
11
2.3. RELATIONAL VERSUS MULTIDIMENSIONAL
2.3.2
Datenmodellierungsebene
Ein für diese Ausarbeitung wichtiger Unterschied zwischen MDBS und RDBS ist
die Art der Daten, die durch die Systeme sinnvoll gespeichert werden können. Dieser Aspekt wird in der Literatur nicht diskutiert, da er bei der in der Theorie üblichen
strikten Trennung von Produktiv- und Analysedaten irrelevant ist. Wird diese Trennung, wie in der Praxis üblich, nicht eingehalten, zeigt sich, dass zwar das relationale
Datenmodell in der Lage ist, beliebige mehrdimensionale Daten abzubilden, jedoch
nicht anders herum.
Das multidimensionale Datenmodell ist beispielsweise nicht dazu fähig, einfache Listen sinnvoll aufzunehmen. Es benötigt einen Fakt, um den sich Dimensionen anordnen.
Eine Liste, z. B. von Mitarbeitern, besitzt jedoch keine Elemente, die sich in Dimensionen und Fakten unterteilen lassen. Zwar wäre es möglich, eine der Spalten als Fakt und
die anderen als Dimension zu deklarieren oder alle Spalten als Dimensionen um einen
leeren Fakt anzusehen, ein sinnvoller Zusammenhang zwischen den Daten entsteht so
jedoch nicht.
2.3.3
Darstellungsorientierte Ebene
Neben der logischen und physischen Speicherung von Daten spielt deren Präsentation
eine zentrale Rolle. Hierbei soll im Folgenden lediglich auf die textuellen, nicht aber
auf die Aspekte der graphischen Datendarstellung eingegangen werden.
Region
Monat
Produkt
Umsatz
Nord
Januar
Teller
100
Nord
Januar
Tasse
150
Süd
Februar
Teller
250
Süd
Februar
Tasse
200
Januar
Februar
Teller
Tasse
Teller
Tasse
Nord
100
−
250
−
Süd
−
150
−
200
Tabelle 2.3: Darstellung identischer Daten als Relation und statistische Tabelle
Tabelle 2.3 greift das Beispiel vorheriger Abschnitte wieder auf und zeigt die typischen
Darstellungsformen von relationalen und multidimensionalen Daten. Da der zweidimensionale Raum eines Bildschirms oder eines Blatt Papiers i. d. R. zur Darstellung
12
2.4. INFORMATIONSSYSTEME
von mehrdimensionalen Konstrukten nicht ausreichend ist, wird in der Praxis auf das
Konzept der statistischen Tabelle zurückgegriffen. Dieses ermöglicht durch eine verschachtelte Darstellung die Anzeige aller Inhalte. Zudem bietet sie eine wesentlich
intuitivere Nutzung. [LEHN99, S. 61 ff.]
2.4
2.4.1
Informationssysteme
Definition
Als IS wird ein System bezeichnet, dessen Zweck in der Beschaffung, Verarbeitung,
Speicherung, Übertragung und Bereitstellung von Informationen liegt. Die benannten
Zwecke sind im Konkreten zumeist unterschiedlich ausgeprägt. [SCHW95, S. 18]
Die Komponenten eines betrieblichen IS sind [SCHW95, S. 19]:
• Hard- und Systemsoftware,
• Anwendungssoftware,
• organisatorische Konzepte und Regelungen,
• Menschen, die an bzw. mit dem System arbeiten,
• Management für die Steuerung und Kontrolle des Systembetriebes und
• Daten.
2.4.2
Anforderungen
Die Anforderungen an IS sind größtenteils einsatzbezogen, deshalb stellt der folgende
Ausschnitt nur die wichtigsten allgemeinen Anforderungen dar. [OEHL00, S. 5 ff.]
• Relevanz: Der Relevanzbegriff verbindet in diesem Kontext Informationen mit
zutreffenden Entscheidungen. Je besser sich die zur Verfügung gestellte Information für die richtige Auswahl einer Alternative im Entscheidungsprozess eignet,
desto relevanter ist sie für die Entscheidungsfindung.
• Genauigkeit: Die Genauigkeit bezeichnet im Umfeld der Informationsverarbeitung den Grad der Realitätstreue des Informationsmodells. Dabei geht es jedoch
nicht um jede Einzelheit, sondern lediglich darum, das Wesentliche der realen
Welt einzufangen.
13
2.4. INFORMATIONSSYSTEME
• Flexibilität: Das ideale IS stellt für jede zu treffende Entscheidung die relevanten Informationen bereit. Da die Informationssuche jedoch i. d. R. fest im IS
codiert ist, müssten im Vorhinein alle relevanten Informationsarten bekannt sein,
um ausgewertet werden zu können. Weil dies in der Praxis meist nicht der Fall
ist, wird sich damit beholfen, möglichst zweckpluralistische Informationen bereit zu stellen, d. h. Auswertungen liefern Informationen, die für möglichst viele
Sachverhalte relevant sind.
• Sprachliche Adäquanz: Die sprachliche Adäquanz soll gewährleisten, dass der
Nutzer die bereitgestellten Informationen auch versteht. Aus diesem Grund sollte die Sprachebene der Informationsausgabe immer die des Benutzers sein. Diese
Maßgabe ist oft nur schwer umsetzbar, da sich zum Einen die Sprachebenen der
einzelnen Benutzer unterscheiden und sich zum Anderen die IS-Entwickler der
Sprachebene der Benutzer nicht bewusst sind.
• Zeitliche Adäquanz: Der Begriff der zeitlichen Adäquanz bezeichnet die Aktualität einer Information. Im Allgemeinen sollten Informationen über ein Ereignis unmittelbar nach dessen Eintritt zur Verfügung stehen. Dabei ist es jedoch
sinnvoll, den Zeitbezug einer Information im Auge zu behalten. Es bringt z. B.
keinen Vorteil, Ressourcen darauf zu verwenden, schnellstmöglich eine Information zur Verfügung zu stellen, die wohlweislich die nächsten Wochen niemand
benötigt.
2.4.3
Informationsbedarf
Ein wichtiger Arbeitsschritt bei der Erstellung von entscheidungsstützenden Werkzeugen ist die Ermittlung des Informationsbedarfs mit Hilfe der Informationsbedarfsanalyse. Mit dieser soll sowohl Fehlentwicklungen als auch der Informationsüberflutung
vorgebeugt werden. Laut HOLTEN wird die Analyse des tatsächlichen Informationsbedarfs von Systementwicklern immer noch sehr „stiefmütterlich“ behandelt. Unnötige oder Informationen in der falschen Form sind meist die Folge. Allzu oft wird
die Analyse jedoch durch den Umstand erschwert bzw. verhindert, dass es nicht möglich ist, die benötigten Informationen für zukünftige Prozesse zu quantifizieren. Auch
unerwartete oder sehr selten auftretende Aufgaben benötigen in vielen Fällen Informationen, die bei der Entwicklung des IS noch nicht absehbar waren.
14
2.5. MIS-KONZEPTE
2.5
2.5.1
MIS-Konzepte
Begriff
Es ist ein schwieriges Unterfangen, Datenverarbeitungssysteme, die Informationen für
die Entscheidungsunterstützung bereitstellen, unter einen gemeinsamen Oberbegriff zu
vereinen. Zwar liegt es nahe, derartige Systeme als entscheidungsunterstützende Systeme zu bezeichnen, doch ist dieser Begriff bereits für die deutsche Übersetzung des
Decision Support Systems reserviert. Auch die Bezeichnung als Führungsinformationssystem oder Management Information System, wie sie in der Literatur verwendet
wird, ist grundsätzlich nicht möglich, da beide Begriffe eigenständige Konzepte repräsentieren.
Dennoch muss im Rahmen der vorliegenden Arbeit ein Oberbegriff für die beschriebenen Datenverarbeitungssysteme gefunden werden. Der Verfasser entscheidet sich
dabei für den Begriff des Management Informationssystems. Dieser repräsentiert zwar
ein eigenes Konzept, doch wird dieses im Gegensatz zu den anderen Begriffsalternativen nicht mehr weiterentwickelt und stellt trotzdem den Ursprung der meisten Datenverarbeitungssysteme zur Entscheidungsunterstützung dar. Um Verwechslungen zu
vermeiden, wird die Abkürzung MIS für eben jenen Oberbegriff verwandt, während
der Begriff Management Information System (Man.Inf.Sys.) das System der sechziger
und siebziger Jahre bezeichnet.
Abbildung 2.4: zeitliche und inhaltliche Einordnung der MIS-Konzepte7
MIS sind somit spezielle Informationssysteme für die obere Führungsebene, d. h. sie
sollen dem Management die richtigen Informationen zum richtigen Zeitpunkt in der
richtigen Form zur Verfügung stellen, damit dieses möglichst fundierte Entscheidun7
In Anlehnung an [OEHL00, S. 8].
15
2.5. MIS-KONZEPTE
gen treffen kann. Im Folgenden wird ein kurzer inhaltlicher und geschichtlicher Abriss
bisheriger MIS-Konzepte gegeben.
2.5.2
Management Information Systems
Der Begriff des Man.Inf.Sys. entstand zu Beginn der sechziger Jahre. Er basiert auf
dem Ansatz der Analyse von Variablen, die den Schlüssel zum Unternehmenserfolg
darstellen. Diese so genannten Schlüsselvariablen werden sowohl von globalen Umgebungsvariablen, Ressourcen und Organisationsstruktur der Unternehmung, als auch
von der Unternehmensstrategie beeinflusst. Um dem Management alle entscheidungsrelevanten Kennzahlen zur Verfügung stellen zu können, verfolgen Man.Inf.Sys. das
Ziel, den gesamten Unternehmensdatenbestand in Echtzeit zu analysieren. Darüber
hinaus sollten sie die Möglichkeit der Erstellung von Ausnahmeberichten, interaktiven
Abfragen und der Simulation von Entscheidungsalternativen bieten.
Es handelt sich somit um einen zentralistischen Ansatz für unternehmensweite Managementunterstützung. Durch den Einsatz von DV-Technik sollen alle Unternehmensbereiche mit Informationen und Funktionen versorgt werden. Das Man.Inf.Sys.-Konzept
verbindet die Basisdatenverarbeitungen8 der einzelnen Unterbereiche miteinander. Die
so entstandene ganzheitliche Unternehmenssicht soll damit globale Informationen für
die Führung zur Verfügung stellen. Zu den Hauptzielen des Man.Inf.Sys.-Konzepts
gehört zudem die Automatisierung von Massenarbeiten und die Unterstützung bei
Dispositions- und Planungsarbeiten durch die Bereitstellung entscheidungsrelevanter
Informationen.
Abbildung 2.5: schichtweiser Aufbau eines MIS [SCHI99, S. 7]
Abbildung 2.5 veranschaulicht die neu gewonnene Unternehmenssicht. Durch die Ver8
Engl.: elementary data processing (EDP).
16
2.5. MIS-KONZEPTE
dichtung der Gesamtdaten sind Man.Inf.Sys. in der Lage, den Kenntnisstand des Unternehmens entscheidend zu vergrößern. Der Erfolg der Man.Inf.Sys. ist jedoch durch
die hohen Ansprüche und mangelnde DV-Möglichkeiten9 stark eingeschränkt.
Folgende Probleme führten letztlich zum Scheitern des Konzeptes:
• Der Informationsbedarf des Top Managements war kaum bestimmbar.
• Zur Informationsversorgung sollten alle Daten des Unternehmens genutzt werden.
• Die Masse der Informationen führte zur Informationsüberflutung.
• Der angestrebte Funktionsumfang war allgemein zu hoch.10
• Die technischen Voraussetzungen waren für derart komplexe Systeme ungenügend.
Als Konsequenz der unzureichenden Umsetzung dieser (zu) hohen Anforderungen entwickelten sich im Laufe der siebziger und achtziger Jahre Management Reporting Systems (MRS). Diese engten den Begriff des Man.Inf.Sys. auf ein umsetzbares Maß ein.
[HOLT99, S. 29 ff.]
2.5.3
Management Reporting Systems
MRS stellen einen direkten Ableger des Man.Inf.Sys.-Gedankengutes dar. Allerdings
konzentrieren sie sich auf einzelne Unternehmensbereiche und versorgen dort das operative und mittlere Management mit gezielten Berichts- und Kontrollsystemen. Vorrangiges Ziel ist die Darstellung von zeitbezogenen, unternehmensinternen Informationen für gut strukturierte und vorhersehbare Problembereiche. Als MRS-Erweiterungen
gelten Ausnahme- und Bedarfsberichte sowie spezielle Abfragemöglichkeiten. Bis
heute finden sich in der Unternehmenspraxis oft MRS unter funktionsbezogenen Bezeichnungen wie Finanz-, Produktions- oder Personalinformationssystem. [HOLT99,
S. 29 ff.]
2.5.4
Decision Support Systems
Zu Beginn der siebziger Jahre entwickelten GORRY und SCOTT MORTON den Ansatz der DSS. Sie nutzen interaktive, computergestützte Systeme für die Lösung von
9
10
Es standen nur Großrechner zur periodischen Kennzahlenversorgung auf Papier zur Verfügung.
Es wurde versucht, die sprichwörtliche „eierlegende Wollmilchsau“ zu erschaffen.
17
2.5. MIS-KONZEPTE
nicht im Voraus planbarer Vorgänge, d. h. DSS konzentrierten sich auf die Lösung von
teilweise oder unstrukturierten Problemen. Sie sollen die Entscheidungsqualität nicht
durch zusätzliche, sondern durch die Ausnutzung bereits existierender Informationen verbessern. Die Kombination von mathematischen Methoden, Unternehmensdaten, Rechenleistung und kreativen Nutzern sollen im interaktiven Mensch-MaschineDialog komplexe unstrukturierte Aufgaben besser lösen und zur Entwicklung neuer
Entscheidungsmodelle führen.[SCHI99, S. 8 f.]
Abbildung 2.6: schichtweiser Aufbau eines DSS [SCHI99, S. 9]
Abbildung 2.6 verdeutlicht, dass DSS das Man.Inf.Sys.-Konzept um eine entscheidungsorientierte Sicht ergänzen. Da in der Praxis der Man.Inf.Sys.-Gedanke lediglich
partiell durch den Einsatz von meist abteilungsbezogenen MRS realisiert wird, fügt
erst das DSS die Teildaten zu einem Gesamtüberblick zusammen.
2.5.5
Executive Information Systems
Anfang der achtziger Jahre begann die Ausbreitung der EIS. Ihr Einsatz stand im engen Zusammenhang mit der Einführung von PCs am Arbeitsplatz des Top Managements. Die Verbreitung wurde zudem durch betriebswirtschaftliche Belange wie dem
Wunsch nach mehr Transparenz der Unternehmensstruktur und der zunehmende Bedeutung von Informationsvorsprüngen voran getrieben. Letztendlich verdankten EIS
ihre wachsende Popularität auch der Unzufriedenheit über die Informationsüberflutung
durch MRS. [HOLT99, S. 32 f.]
EIS wurden mit dem Ziel geschaffen, den obersten Führungskräften effektivere Werkzeuge zur Informationsnutzung im Planungs- und Kontrollprozess zu bieten. Dies soll
durch Nutzung mehrdimensionale Datenbanken ermöglicht werden. EIS spannen zu18
2.5. MIS-KONZEPTE
meist einen Datenkubus mit den Dimensionen Zeit, Unternehmens- und Produktstrukturen sowie betriebswirtschaftliche Größen auf. Neben schneller Navigation in den
Daten bieten EIS zusätzlich die Möglichkeit schneller, bedarfsorientierter Überblicke
über Kernvariablen des Geschäftes und interaktive Datenmanipulationen zu Analysezwecken. Die organisatorische Unterstützung, d. h. Zusammenstellung, Aufbau und
Aktualisierung der Datenbasis, werden von EIS-Spezialisten übernommen. [HOLT99,
S. 33 ff.]
2.5.6
Data Warehouse
Da das DWH-Konzept einerseits durch seine neue Datensicht eine Schlüsselposition
unter den MIS-Konzepten einnimmt und andererseits eine mögliche Alternative zum
zu entwickelnden Reporting-Modul darstellt, soll dieses Konzept im Gegensatz zu den
bisher beschriebenen ausführlicher vorgestellt werden.
Mit steigenden Datenmengen wurde Anfang der neunziger Jahre deutlich, dass Präsentation und Modellierung, auf die sich die bisherigen MIS-Konzepte konzentriert
hatten, nur noch zu unbefriedigenden Lösungen führen falls weiterhin die Datenbasis
vernachlässigt würde. Die operativen Datenbanken als Informationsbasis zu nutzen,
hatte zur Folge, dass die Antwortzeiten sowohl der Produktivsysteme als auch für MIS
immer größer wurden.
An diesem Punkt setzt der Grundgedanke des DWH an. Das DWH stellt eine von operativen DV-Systemen unabhängige, speziell für die Informationsgewinnung optimierte
Datenbasis dar. Im Folgenden sollen die wichtigsten Merkmale eines DWH charakterisiert werden [LEHN03, S. 9 f.],[OEHL00, S. 17 f.].
• Auswertungsorientierte Datenorganisation: Im Gegensatz zu operativen Systemen orientiert sich die logische und physische Datenmodellierung im DWH
nicht an der Datenbeschaffung, sondern an der Datenauswertung. Demzufolge
werden die Daten abfrageoptimal modelliert.
• Datenintegration aus verschiedenen Quellen: Ein DWH verbindet verschiedenste Datenquellen zu einer zentralen, einheitlichen Datenbasis. Dafür müssen
die Daten aus den betroffenen Quellsystemen extrahiert, bereinigt und vereinheitlicht werden.
• Keine Aktualisierung durch den Nutzer: DWH-Nutzer können lediglich lesend auf die Daten zugreifen. Schreibend wird auf ein DWH nur zum Zweck
des periodischen Datenimports zugegriffen. Datenänderungen finden in einem
DWH im Idealfall nicht statt.
19
2.5. MIS-KONZEPTE
• Zeitraumbezug: Durch das kontinuierliche Hinzufügen von Daten bildet ein
DWH Zeiträume ab. Die Daten werden dabei oft bis zu zehn Jahre in Abhängigkeit ihres Alters in zunehmenden Aggregationsstufen gespeichert.
• (Optionale) Historisierung: Unter Historisierung wird das vollständige Aufzeichnen von Datenänderungen verstanden. Diese Technik muss im Quellsystem implementiert sein. Historisierung erstellt ein detailierteres Datenabbild, ist
jedoch in ihrer Anwendung meist durch den enormen Speicherbedarf begrenzt.
Abbildung 2.7 skizziert den Fluss von Daten und Informationen im DWH-Modell.
Darüber hinaus verdeutlicht sie die Grundgedanken des Konzeptes, die zum Einen in
der Trennung der Datenbasis für die operativen und entscheidungsstützenden Systeme
und zum Anderen in der periodischen Aktualisierung der DWH-Datenbasis sowohl aus
internen als auch aus externen Quellen liegen.
Abbildung 2.7: Daten- und Informationsfluss im DWH-Modell [LEHN03, S. 4]
Während ein DWH-System die einzelnen Bestandteile und Strukturen beschreibt, bezeichnet der Begriff Data Warehousing den Prozess, der zur Planung, zum Aufbau
und insbesondere zum Betrieb eines DWH-Systems notwendig ist. [LEHN03, S. 10]
Da dieser Abschnitt lediglich den Zweck verfolgt, die Funktionsweise eines DWH in
groben Zügen zu verdeutlichen, wird auf die Erläuterungen zu den Themen Planung
und Aufbau eines DWH verzichtet. Stattdessen soll der DWH-Betrieb mit seinen drei
wesentlichen Bestandteilen Load Management, Warehouse Management und Query
Management im Folgenden näher betrachtet werden. [OEHL00, S. 20 ff.]
20
2.5. MIS-KONZEPTE
Load Management
Ziel des Load Managements ist die Bereitstellung einer homogenen Datenbasis. Es
beinhaltet das Extrahieren, Konvertieren und Vorverdichten von Daten aus unterschiedlichsten Quellen. Bevor die gewonnenen Daten ins DWH einfließen können, müssen
sie zumeist bereinigt werden. Dieser Vorgang wird i. A. als Cleansing bezeichnet. Der
Transformationsprozess ist aus zwei Blickwinkeln zu betrachten: aus technischer und
aus semantischer Sicht. Technisch gesehen sind Probleme wie der Umgang mit unterschiedlichsten Datenformaten11 , Gruppierungen oder Schlüsselsystemen zu lösen. Die
Interpretation von Nullwerten und nicht gefüllte Pflichtfelder stellen weitere Herausforderungen dar.
Wesentlich größere Schwierigkeiten bestehen jedoch in semantischer Hinsicht. Bei der
Zusammenführung der verschiedensten Datenbestände zu einer inhaltlich und begrifflich homogene Datenbasis werden oft Defekte deutlich, deren Ursprung in den unterschiedlichen Datendefinitionen der Ursprungssysteme liegt. In Abbildung 2.8 sind die
wichtigsten Defekte graphisch dargestellt.
Abbildung 2.8: Sprachkonflikte im Datawarehouse [OEHL00, S. 22]
• Abgrenzung: Abgrenzungsunterschiede ergeben sich bei der Verwendung des
gleichen Begriffs und Sachverhalts, bei unterschiedlichen zeitlichen und sachlichen Zuordnungen.
• Synonym: Synonyme sind verschiedene Begriffe, die den gleichen Sachverhalt
bezeichnen.
• Homonym: Homonyme sind gleiche Begriffe die verschiedene Sachverhalte bezeichnen.
• Äquipollenz: Zwei Begriffe gelten als äquipollent, wenn sie denselben Sachverhalt in verschiedener Form widerspiegeln.
11
Die größten Schwierigkeiten gehen hierbei von nicht öffentlichen Daten und Dateiformaten aus.
21
2.5. MIS-KONZEPTE
Besondere Herausforderungen entstehen bei Unternehmenszusammenschlüssen. Einerseits sollen die Daten der zusammengeführten Unternehmen möglichst schnell
vereinigt werden, um einen besseren Überblick über das neue Gesamtunternehmen
zu erhalten, andererseits zieht die Fusion meist gravierende Umstrukturierungen der
Organisations- und damit auch der Datenstruktur nach sich. [OEHL00, S. 20 ff.]
Warehouse Management
Das Warehouse Management beinhaltet neben der Daten- und Nutzerverwaltung auch
Sicherungskonzepte und andere administrative Vorgänge wie z. B. die Optimierung der
Datenbasis für Abfrage.
Als eines der wichtigsten Werkzeuge zu diesem Zweck ist eine geeignete Datenmodellierung zu sehen. Das charakteristische Beschreibungsmittel eines DWH ist das StarSchema12 . Dieser Modellierungsansatz wurde mit der Absicht entwickelt, die Stärken
von relationalen und multidimensionalen Datenbanksystemen miteinander zu verbinden. RDBS speichern Daten sehr effizient im Hinblick auf den benötigten Speicherplatz, während multidimensionale DBS sehr schnelle Abfragen ermöglichen.
Im Mittelpunkt des Star-Schemas steht die Faktentabelle. Sie enthält die zu analysierenden quantitativen Daten13 . Sternförmig um die Faktentabelle gruppieren sich Dimensionstabellen, die die Kriterien, nach denen die Fakten später analysiert werden
können, definieren. Der Primärschlüssel der Faktentabelle setzt sich aus den Primärschlüsseln der Dimensionstabellen zusammen. Dies impliziert, dass es jeden Eintrag
zu einer Kombination von Dimensionen nur einmal geben kann. Die Dimensionstabellen enthalten flache Hierarchiestrukturen, die durch die Verletzung der dritten Normalform14 schnelle Abfragen ermöglichen.
Query Management
Das Query Management beinhaltet den gesamten Bereich der Datenabfrage und
-analyse. Dazu kommen neben den im DWH integrierten Werkzeugen insbesondere
OLAP-Systeme, welche in Abschnitt 2.5.7 beschrieben werden, zum Einsatz.
Den größten Einfluss auf die Datenabfrage hat die Art der Datenspeicherung. Hierbei wird zwischen den drei Architekturen Data Marts, zentrales und virtuelles Data Warehouses unterscheiden. Abbildung 2.9 gibt einen Gesamtüberblick der DWHArchitekturen.
12
13
14
Siehe [OEHL00, S. 23].
Dies sind beispielsweise Daten wie Umsätze, Kosten, Verkaufszahlen oder Erträge.
Genauere Erklärungen zu Normalformen finden sich in Abschnitt 2.2.1.
22
2.5. MIS-KONZEPTE
Abbildung 2.9: Data Warehouse-Architekturen und ihre Bestandteile [SCHI99, S. 19]
Im virtuellen DWH existiert keine für das Konzept typische autonome Datenbasis, d. h.
die Abfrageergebnisse stammen aus den jeweiligen Quellsystemen. Das Harmonisieren der unterschiedlichen Datenbasen erfolgt hier zur Laufzeit der Auswertung und
ausschließlich mit Hilfe von Metadaten. Der Vorteil eines virtuellen DWH liegt in der
Aktualität der Abfrageergebnisse und einer höheren Flexibilität. Zudem ist ein virtuelles DWH wesentlich kostengünstiger als eine zentrale- oder Data Mart-Lösung, da
auf bereits vorhandene Daten und Hardware zurückgegriffen werden kann. Allerdings
ergeben sich gravierende Geschwindigkeitsverluste, da sowohl auf nicht für Abfragen
optimierte operative Systeme oder Dateien zugegriffen wird als auch die Übersetzung
und Harmonisierung der Daten Zeit benötigt. Darüber hinaus besteht die Gefahr, dass
der Betrieb der operativen Systeme empfindlich gestört wird. Letztlich ist die Möglichkeit der Einbindung externer Datenquellen beschränkt und historische Daten sind
nur soweit, wie in den Produktivsystemen15 vorhanden, verfügbar.
Das zentrale DWH repräsentiert den DWH-Gedanken im klassischen Sinne. Es verfügt über eine zentrale, homogene von Produktivsystemen getrennte Datenbasis, die
periodisch durch Hinzufügen von Daten aus internen und externen Datenquellen aktualisiert wird. Ist in der Literatur von einem DWH die Rede, so wird damit meist
automatisch das zentrale DWH assoziiert.
Aus der Kritik, dass der DWH-Gedanke einen zu umfassenden Anspruch erhebt, indem
es versucht alle entscheidungsrelevanten Unternehmensdaten zentral16 zu modellieren,
resultiert die Data Mart-Architektur. Um Projektlaufzeiten von teilweise mehreren Jah15
16
Historische Daten in Produktivsystemen überschreiten selten einen Horizont von 2-3 Jahren.
Zur Erinnerung: An diesem Anspruch sind die Man.Inf.Sys. der frühen sechziger Jahre gescheitert.
23
2.5. MIS-KONZEPTE
ren aus dem Weg zu gehen, wird sich oft auf abteilungsspezifische Ausschnitte konzentriert. Diese als Data Mart bezeichneten Ausschnitte stellen für sich genommen jeweils
kleine DWH dar. Durch die eingeschränkte Sichtweise vermindert sich die Komplexität des zu entwickelnden Systems radikal, jedoch geht dadurch auch die allumfassende
Unternehmenssicht verloren. Dazu kommen Redundanzen und Inkonsistenzen in den
verschiedenen Data Marts.
Wie aus den Abbildungen 2.7 und 2.9 deutlich wird, sind Metadaten ein unverzichtbarer Bestandteil im DWH. Metadaten beschreiben sowohl Art, Struktur und Herkunft als
auch Zugriffsart und Speicherung der Daten im DWH. Darüber hinaus dokumentieren
sie Art und Zeitpunkt von Datenextraktionen aus Quellsystemen. Diese Daten werden
im laufenden DWH-Betrieb zum Nachvollziehen abgelaufener Prozesse, zur Bewertung von Kennzahlen und für den Zugriff auf die eigentlichen Analysedaten benötigt.
Metadaten werden neben den Nutzdaten in einer separaten Datenbank, dem so genannten Metadaten Repository, gespeichert und verwaltet. [LEHN03, S.45 ff.],[SCHI99,
S. 25 ff.]
2.5.7
Online Analytical Processing
Wie in Abbildung 2.4 zu erkennen ist, begann die Entwicklung von OLAP-Systemen
in den frühen neunziger Jahren, etwa zeitgleich mit dem Aufkommen von DWH. Meist
werden beide Konzepte in einem Atemzug genannt bzw. die Funktionalität des Einen
dem Anderen zugesprochen. Beide Standpunkte sind weder als falsch noch als richtig einzuordnen, denn auf der einen Seite ergänzen sich die beiden Konzepte, indem
das DWH Daten zur Verfügung stellt und OLAP diese analysiert, auf der anderen
Seite können die Konzepte auch ohne einander existieren. Darüber hinaus besitzen
praktische DWH-Systeme, wenn auch begrenzte, Analysemöglichkeiten und OLAPSysteme sind in der Lage, Daten zu modellieren.
Fest steht, dass OLAP ein eigenständiges Konzept mit dem vorrangigen Ziel, mehrdimensionale Daten möglichst schnell zu analysieren, ist. Prägend für den Begriff war
die Veröffentlichung der 12 Grundregeln von E.F. Codd im Jahr 1993. Da diese jedoch zum Teil umstritten17 , sehr detailliert und deshalb nur schwer umsetzbar waren,
folgte 1995, im Rahmen des OLAP Report18 , mit dem Begriff Fast Analysis of Shared
Multidimensional Information (FASMI) eine praktikable OLAP-Definition [CLAU98,
S. 11 ff.]:
17
18
Denn die Regeln entstanden in Zusammenarbeit mit einen namhaften OLAP-Anbieter.
Der OLAP Report ist eine unabhängige Informationsquelle zum Thema OLAP, siehe [OLAP].
24
2.6. CLIENT-SERVER ARCHITEKTUR
• Fast: Die Antwortzeiten des Systems müssen gering sein. Einfache Abfragen
sollten maximal fünf, komplexe nicht mehr als 20 Sekunden benötigen.
• Analysis: Das System muss in der Lage sein, die benötigte Analyselogik abzubilden. Zudem soll es dem Nutzer intuitive Werkzeuge zur Logikeingabe zur
Verfügung stellen.
• Shared: Das System muss für den Mehrbenutzerbetrieb ausgelegt sein, was
dementsprechende Maßnahmen zur Integritätssicherung voraussetzt.
• Multidimensional: Als Schlüsselkriterium wird vom System der Umgang mit
und die Analyse von mehrdimensionalen Datenstrukturen inklusive der Unterstützung von Mehrfachhierarchien verlangt.
• Information: Das System soll die Fähigkeit besitzen, Informationen aus den zur
Verfügung stehenden Daten abzuleiten.
Laut Abbildung 2.4 ist OLAP konzeptionell in die Kategorie der Präsentation einzuordnen, doch wie lässt sich das mit der Aussage, OLAP-Systeme sind in der Lage, Daten zu modellieren, oder dem Begriff der OLAP-Datenbank vereinbaren? Der
Grund liegt darin, dass OLAP vorwiegend für die Analyse und Präsentation von mehrdimensional gespeicherten Daten konzipiert wurde. Ähnlich wie ein DWH sind OLAPSysteme in der Lage, Daten z. B. aus relationalen DB zu extrahieren und in mehrdimensionaler Form zu speichern, um dann die Vorteile der mehrdimensionalen Datenhaltung bei der Analyse nutzen zu können.
OLAP ist nicht das erste Konzept, das auf die Analyse mehrdimensional modellierter
Daten setzt, auch EIS waren diesen Schritt schon gegangen. Jedoch versucht OLAP
analog zum DWH, die Analysedatenbasis weitgehend von den Produktivsystemen zu
trennen.
2.6
Client-Server Architektur
Unter Client-Server Architektur wird eine Netzwerkstruktur verstanden, bei der eine
hierarchische Aufgabenverteilung vorliegt. Der Server ist dabei der Anbieter von Ressourcen und Diensten, auf die die Arbeitsstationen (Clients) zugreifen können. Der
Client ist in diesem Modell für die Interaktion mit dem Nutzer optimiert, während
der Server für die Bereitstellung von Daten für viele gleichzeitig zugreifende Clients
optimiert ist.
25
2.6. CLIENT-SERVER ARCHITEKTUR
Abbildung 2.10: 3-Schichten Architektur
Eine spezielle Form der Client-Server Architektur findet sich in der 3-Schichten Architektur. Wie Abbildung 2.10 zeigt, wird in diesem Modell die Ebene des Servers
weiter in Präsentations- bzw. Anwendungsschicht und Datenschicht unterteilt. Dieses
Konzept findet seine Anwendung zumeist bei dynamischen Webseiten oder browserbasierten Informationssystemen. Es zeichnet sich durch folgende Merkmale aus:
• Plattformunabhängigkeit: Durch den Einsatz von serverseitigen Skriptsprachen wie z. B. PHP, Active Server Pages (ASP) , VB- und Javascript, deren Output HTML ist, wird auf dem Clientrechner zum Anzeigen der Daten lediglich ein
Browser benötigt. Da HTML standardisiert ist und Browser für nahezu alle Betriebssysteme verfügbar sind, ist höchste Plattformunabhängigkeit gewährleistet.
• Sicherheit: Datenabfragen und -manipulationen sind ausschließlich mit Hilfe
der auf dem Web- bzw. Applikationsserver gespeicherte Skripte möglich. Da
dem Nutzer die direkte Kommunikation mit der Datenbasis durch physikalische
Trennung von Präsentation und Daten verwehrt ist, wird die Sicherheit der Daten
wesentlich erhöht.
• Lastverteilung: Die physische Trennung von Präsentations- und Datenschicht
bringt einen weiteren Vorteil mit sich. Starke Belastung des einen Systems führt
nicht zwangsläufig zu Beeinträchtigungen des anderen.
26
Teil III
Praxis
27
Kapitel 3
Ausgangssituation
3.1
Das MedienHaus Rostock
Das MedienHaus Rostock (MHR) ist ein kleiner IT-Dienstleister, der in den Bereichen Consulting, System-Design, Programmierung, Grafik-Design und Bildverarbeitung, Server- und Application-Hosting sowie eBusiness-Lösungen, B2B und B2C tätig
ist.
Es bietet bzw. erarbeitet IT-Lösungen auf den Gebieten:
• Datenbanken, insbesondere SQL- und ACCESS-Lösungen,
• öffentliche und nicht-öffentliche IT-Systemlösungen,
• integrierte Internet- und Telekommunikations-Lösungen,
• Content Management Lösungen,
• neuronale Technologien sowie
• Netzwerk und Netzwerksicherheit.
Der Schwerpunkt der Leistungen des MedienHauses liegt dabei auf der Integration der verschiedenen IT-Komponenten und -Technologien. Darüber hinaus bietet es
Komplettlösungen von Konzeption über Produktion, Installation, Schulung bis hin
zum Pre-Sales-Service. Das MedienHaus Rostock entwickelt, integriert und betreibt
Informations- und Kommunikationssysteme sowie eCommerce Applikationen.
Zu aktuellen Projekten des MHR gehören u. a. Maklersysteme, Webshops und ein Kundeninformationssystem für die Vereins- und Westbank (VuW).
28
3.1. DAS MEDIENHAUS ROSTOCK
Das Maklersystem ist ein datenbankgestütztes Wohnungsverwaltungssystem für
freie Wohnungen, Häuser und Gewerberäume. Der Mittelpunkt der Anwendung ist eine moderne und leistungsfähige Datenbank. In ihr werden die Stammdaten gespeichert
und gepflegt. Aus den Daten werden mit Hilfe von serverseitigen Skriptsprachen sowohl die Homepage als auch die Administrationsschnittstellen als Internetpräsentation
generiert.
GlobalWebShop 3.0 ist ein vollwertiges Warenkorb-System mit Bestellmöglichkeit.
Beim Kundeninformationssystem handelt es sich um ein spezielles Informationsund Managementsystem, welches für Abteilungen der VuW entwickelt wurde. Das
System wurde als Intranetlösung konzipiert und dient der Erfassung, Bereitstellung
und Auswertung aller Informationen zu Geschäftskunden, die Onlinebanking nutzen.
Das Informationssystem ist als zentralisierte Datenbanklösung auf Basis des MS SQL
Servers aufgebaut. Alle Funktionen des Systems sind mittels Webbrowser einfach und
intuitiv bedienbar. Zur Erfassung von Daten verfügt das System über Module zum automatisierten Datenimport, so dass die Daten ständig auf dem aktuellen Stand gehalten
werden können. Zusätzlich ist eine manuelle Datenerfassung möglich.
Das Informationssystem stellt den Mitarbeitern alle vorhandenen Informationen über
ihre Onlinebanking-Kunden schnell und übersichtlich zur Verfügung. So beinhaltet das
System u. a. folgende Kundendaten:
• Adressen, Konten und Zahlungsverkehr,
• betriebswirtschaftliche Daten,
• Informationen zur EDV-Ausstattung,
• Informationen zur Nutzung von Onlinebankingprodukten und -diensten,
• Informationen zum Nutzungsverhalten beim Onlinebanking und
• erbrachte Serviceleistungen inkl. Abrechnungen.
Mit Hilfe von Assistenten kann der Mitarbeiter Auswertungen über Kunden bzw. Kundengruppen, z. B. zum Zahlungsverkehr, zur effektiven Nutzung von OnlinebankingProdukten oder anderen Kriterien erstellen lassen. Diese sind u. a. Grundlage für fundierte Beratungsansätze der Kundenbetreuer.
Weiterhin werden über das System z. B. die Einführung von Hard- und Softwareprodukten für das Onlinebanking beim Kunden abgewickelt. Dabei werden Aufträge der
29
3.2. GRUNDGEDANKEN
Kunden manuell erfasst bzw. auf Grundlage von zuvor getätigten Auswertungen vorqualifiziert. Die Auslösung der anfallenden Versandaufträge erledigt das System dabei
ebenso automatisch wie die Aktualisierung der Kundendaten und die eventuelle Ableitung von Aufgaben für beteiligte Mitarbeiter.
Zusätzlich beinhaltet das Informationssystem spezifische Taskplanungs- und Messagingmodule. Aufgrund seines modularen Aufbaus kann das System bei Bedarf um
weitere Module, z. B. zur Prozess-, Bestellabwicklung, Abrechnung, Auswertung usw.
erweitert werden. [MHHRO]
Das soeben beschriebene Kundeninformationssystem soll zukünftig mit dem Namen
Roteiro und die zugehörige Datenbank als Kundendatenbank (KDB) bezeichnet werden.
3.2
Grundgedanken
Im Tagesgeschäft von Roteiro besteht oft die Notwendigkeit zur Durchführung von
teilweise einmaligen Datenabfragen- und auswertungen. Zwar handelt es sich bei den
verschiedenen Abfragen, wie eine spätere Analyse in Abschnitt 3.4 zeigen wird, in
vielen Fällen um ähnliche Daten, jedoch unterscheiden sich zumeist die Auswahlkriterien oder die Nutzdatenzusammenstellung der gewünschten Ausgabe. Die Realisierung
dieser Auswertungen ist bislang nur mit Hilfe manueller SQL-Abfragen möglich.
Der beschriebene Sachverhalt bringt großen Arbeitsaufwand mit sich. Zum Einen lassen sich die SQL-Abfragen auch bei ähnlichen Problemstellungen meist nicht wieder verwenden, weil sie für die eine bestimmte Problemlösung optimiert wurden, zum
Anderen muss für jede Auswertung eine Ausgabedatei mit eigenem Layout erzeugt
werden. Für beide Probleme sucht das MHR schon seit Längeren nach geeigneten Lösungen.
Mit dem Hardwareumzug Roteiros nach München im Januar 2006 entstand ein weiteres Problem. Wie Abbildung 3.1 zeigt, hat das MHR nun nur noch eingeschränkten
Zugriff auf Roteiro. Manuelle SQL-Abfragen sind nahezu unmöglich.
Der Grundgedanke besteht darin, ein System zu schaffen, welches im Idealfall beliebige Datenabfragen erlaubt und dabei möglichst wenig Eingreifen eines Entwicklers
verlangt. Zudem soll sowohl die Datenauswahl als auch die Erstellung des Präsentationslayout durch den Nutzer vorgenommen werden.
30
3.3. DIE MANUELLE AUSWERTUNG
Abbildung 3.1: Zugriffsweg MHR auf KDB
3.3
Die manuelle Auswertung
In diesem Abschnitt wird der Vorgang der Erstellung einer manuellen Auswertung
skizziert. Ziel ist es, einen Eindruck vom Vorgehen zu vermitteln und bereits bekannte
Schwachstellen aufzuzeigen.
Abbildung 3.2: Ablauf einer manuellen Auswertung als Aktivitätsdiagramm
Abbildung 3.2 zeigt den typischen Ablauf bei der Erstellung manueller Auswertungen.
Erfahrungsgemäß dauert die Anfertigung einer Auswertung, ohne Nachbesserung, in
Abhängigkeit von der Komplexität zwischen zwei und acht Arbeitsstunden. Allerdings
entspricht das Auswertungsergebnis des ersten Durchlaufes i. d. R. nicht den Vorstellungen der Nutzer und es kommt zur Nachbearbeitung. In Extremfällen kann es so
31
3.4. AUSWERTUNGSANALYSE
vereinzelt zu Bearbeitungszeiten von bis zu 40 Stunden kommen.
Die häufigsten Fehlerquellen sind Missverständnisse bei der Begriffsdefinition, vergessene Datenfelder oder falsche bzw. unvollständige Auswahlkriterien. In der Regel wird
pro Woche maximal eine Auswertung angefordert, wobei die Arbeit meist von keinem
bestimmten Entwickler übernommen wird. Damit liegen für den Einzelnen teilweise vier bis fünf Wochen zwischen zwei Auswertungen. Durch diese relativ großen
Zeiträume geraten gemachte Fehler oft in Vergessenheit und werden später erneut begangen.
3.4
Auswertungsanalyse
In diesem Abschnitt werden die Motivation, das Vorgehen und die Ergebnisse der Analyse der in den Abschnitten 3.2 und 3.3 angesprochenen manuellen Auswertungen vorgestellt.
3.4.1
Motivation
Die Analyse wird aus drei Gründen durchgeführt. Erstens soll sie die These des Entwicklerteams, dass es sich bei den Auswertungen um zumeist ähnliche Sachverhalte
und damit auch ähnlich Sprachkonstrukte handelt, untermauern. Wäre dies nicht der
Fall, wäre die gesamte Entwicklung zu überdenken.
Zweitens bilden die Analyseergebnisse die Grundlage für die Zielstellung und die
Entwicklung. Zwar existiert von vornherein das allgemeine Ziel, dass das ReportingModul mindestens 80% der bisherigen manuellen Abfragen bewältigen können muss,
aber eine konkrete Vorstellung, in welcher Größenordnung die Komplexität für die
Erfüllung dieser Anforderung liegen würde, ist bis dato nicht vorhanden.
Drittens soll die Analyse als Mittel der in Abschnitt 2.4.3 beschriebenen Informationsbedarfsermittlung eingesetzt werden. Dabei ist zwar klar, dass vergangene Auswertungen kein Maß für zukünftige darstellen, jedoch bleibt anzunehmen, dass die häufigsten
Sprachkonstrukte auch in neuen Auswertung Wiederverwendung finden.
Darüber hinaus sollte letztlich auch die Tatsache, dass ein strukturierter Gesamtüberblick oft neue Sichtweisen eröffnet, nicht vergessen werden. Es besteht demnach die
Möglichkeit, dass die angestrebte Analyse völlig unerwartete Ergebnisse liefert.
32
3.4. AUSWERTUNGSANALYSE
3.4.2
Definition und Vorgehen
Um die einzelnen Auswertungen einheitlich bewerten zu können, wird im Folgenden
das Vorgehen bei der Analyse definiert.
Gegenstand der Analyse sind alle im Jahr 2005 im Rahmen des Projekts Roteiro durchgeführten manuellen Auswertungen. Der Begriff der manuellen Auswertung bezeichnet dabei eine in Textform gespeicherte Abfolge von SQL-Befehlen.
Um den Inhalt zu bestimmen, werden sowohl Ausprägung als auch Anzahl von Tabellen, Spalten, Funktionen, Sortierungen und Gruppierungen ermittelt. Darüber hinaus
werden Zweck und Besonderheiten der Auswertung bestimmt. Temporärtabellen und
deren Spalten werden nicht in die Analyse mit einbezogen, da sie lediglich Daten aus
realen Spalten enthalten und über die einzelnen Auswertungen hinaus nicht verglichen
werden können. Da der Aufwand für die Auswertungserstellung im Nachhinein nicht
mehr bestimmt werden kann, soll die Anzahl der Zeilen und Zeichen der groben Schätzung1 dienen.
Um eine möglichst gleich bleibende Qualität bei der Durchführung zu sichern, werden einfache, häufig auftretende Arbeitsschritte automatisiert. Das Zählen und Dokumentieren der einzelnen Inhalte wird z. B. durch ein dafür entwickeltes Perlskript2
übernommen. Das Identifizieren der Inhalte sowie die Bestimmung von Zweck und
Besonderheiten bleiben jedoch dem Menschen vorbehalten.
Trotz vieler quantitativer Daten wird die Bewertung der Kompliziertheit einer Auswertung zum Großteil von der subjektiven Einschätzung des Durchführenden beeinflusst.
Die SQL-Syntax, obwohl oft als starr und einfach empfunden, ist zu komplex, um die
Schwere einer Abfrage anhand eines einfachen Modells zu berechnen. Da die Analyse
der Auswertungen jedoch lediglich einen Teil dieser Ausarbeitung darstellt, wird die
Komplexität der Abfragen der Einfachheit halber subjektiv bestimmt.
Als Zusammenfassung der Einzelanalysen wird eine Aufstellung der relativen Häufigkeiten der untersuchten Inhalte das Gesamtbild abrunden. Die Inhalte mehrmals ausgeführter Auswertungen gehen dabei nur einmal in die Wertung mit ein, da bei der
geringen Anzahl von Auswertungen mehrfach ausgeführte das Bild stark dominieren
würden.
1
2
Diese Schätzung ist keinesfalls repräsentativ.
Der Quellcode dieser Analysehilfe befindet sich in Anhang A.
33
3.4. AUSWERTUNGSANALYSE
3.4.3
Ergebnisse
Nach der Analyse der 25 manuellen Auswertungen aus dem Jahr 2005 stellt sich die
durchschnittliche Auswertung wie folgt dar3 :
Die Auswertung fragt mit Hilfe von 10,96 Select-Anweisungen 10,72 verschiedene
Spalten aus 7,44 unterschiedlichen Tabellen ab. Sie nutzt 1,6 Insert-, 1,84 Update-,
0,72 Order by- und 0,36 Group by-Anweisungen. Sie enthält 2053,72 Zeichen auf
59,12 Zeilen verteilt, besitzt einen Schweregrad von 3,68 und wird durchschnittlich
1,48 mal ausgeführt. Weiterhin handelt es sich beim Ergebnis der Auswertung mit
einer Wahrscheinlichkeit von 88% um eine Liste aus zweidimensionalen und zu 12%
um mehrdimensionale Daten.
Durchschnittlich wird alle zwei Wochen eine Auswertung erstellt. Bei der graphischen
Darstellung4 der einzelnen Zeitpunkte fällt jedoch auf, dass sich die Auswertungen
nicht gleichmäßig verteilen, sondern meist in Gruppen auftreten. Bei gleichzeitiger
Betrachtung der Inhalte wird klar, dass meist zwei Auswertungen zu ähnlichen Sachverhalten in kurzen Abständen hinter einander angefertigt wurden.
Abbildung 3.3: graphischen Darstellung der Auswertungsanalyse
3
4
Alle Materialien und Ergebnisse der Analyse befinden sich auf der Begleit-CD im Verzeichnis
Analyse, siehe Anhang D.
Siehe Abbildung 3.3 oben.
34
3.5. GRUNDSÄTZLICHE SCHWIERIGKEITEN
Annähernd jede zweite Auswertung enthält Daten aus den Tabellen Mitarbeiter, Partnernummer, Kunden, Adressen, BcsPartner oder Kundenbetreuer. Dies war zu erwarten, da es sich bei diesen Objekten um die zentralen Elemente Roteiros handelt. Allerdings sollte das nicht darüber hinweg täuschen, dass in den 25 Auswertungen 98
Spalten aus 40 verschiedene Tabellen abgefragt wurden. Auch wenn diese Zahlen auf
den ersten Blick nichtssagend klingen, lassen sich doch einige Erkenntnisse aus ihnen
ableiten.
1. Der hohe Anteil der Tabellen (32,5%) und Spalten (51%), die in einer Auswertungen auftauchten, zeigt, dass sich die Abfragen nicht so stark ähneln wie erhofft.
2. Sich ähnelnde Auswertungen wurden meist in geringen Abständen erstellt, was
den Eindruck der Entwickler erklärt, dass verschiedene Auswertungen oft die
gleichen gleichen Sachverhalte wiederspiegeln.
3. Bei den Ergebnissen der manuellen Auswertungen handelte es sich vorrangig um
Listen zur Synchronisierung von Datenbeständen oder als Grundlage für Marketingaktionen, echte Datenanalysen waren die Seltenheit.
4. Sortierungen spielten oft eine wichtige Rolle, Gruppierungen der Daten wurden
dagegen wesentlich sparsamer eingesetzt.
5. Die Anzahl der Insert- und Update-Befehle zeigt, dass zur Ergebniserstellung
oder -speicherung meist Temporärtabellen eingesetzt wurden.
6. Der Einsatz von Update-Anweisungen kann die Komplexität einiger Abfrage auf
Kosten der Quelltextmenge herabsetzen.
7. Die Komplexität der Auswertungen schwankte sehr stark, jedoch war ein Trend
zwischen Länge und Schwere der Auswertung erkennbar.5
Auffällig waren die teilweise sehr komplizierten Zusammenhänge zwischen Speicherung und Bedeutung der Daten. Für einen Teil dieser Zusammenhänge wurden zur
Vereinfachung Funktionen genutzt, deren Verwendung im Laufe des Jahres zunahm.
3.5
Grundsätzliche Schwierigkeiten
In diesem Kapitel werden die bei bisherigen manuellen Anfragen beobachteten und
von Vornherein absehbaren Schwierigkeiten für das zukünftige System erläutert und
diskutiert.
5
Siehe Abbildung 3.3 unten.
35
3.5. GRUNDSÄTZLICHE SCHWIERIGKEITEN
3.5.1
Sprachprobleme
Eine der schwierigsten Aufgaben bei der Anfertigung von manuellen Auswertungen
ist die korrekte Umsetzung der verbalen Anfrage des Nutzers. Das Hauptproblem liegt
hierbei in den verschiedenen Sprachebenen, auf denen sich Nutzer und Entwickler
bewegen. Als Folge dieses Verständigungsproblems entstehen falsche6 Auswertungsergebnisse und mit deren Korrektur ein nicht unerhebliches Maß an Mehrarbeit. Die
Verständigungsschwierigkeiten sind vergleichbar mit den in Abschnitt 2.5.6 beschriebenen und in Abbildung 2.8 gezeigten Sprachkonflikten beim Load Management im
DWH.
Eine weitere Fehlerquelle liegt in der Datensicht. Während der Nutzer nur die Daten kennt, die er zum täglichen Arbeiten benötigt, stehen dem Entwickler meist alle
existierenden Daten zur Verfügung. Darüber hinaus arbeitet der Nutzer mit bereits angepassten, der Entwickler jedoch mit Rohdaten.
Letztlich enthalten die verbalen Anfragen meist nur erwünschte Parameter. Ausschlusskriterien werden oft als selbstverständlich oder implizit angesehen, obwohl gerade sie die Grundlage effizienter Datenabfragen darstellen.
Da das Problem der Verständigung sowohl auf Nutzer- als auch auf Entwicklerseite
besteht, ist es schwierig, eine geeignete Lösung zu finden. Die beste Möglichkeit besteht in der Definition eines unmissverständlichen Begriffskatalogs. Jedoch ist dessen
Realisierung im Rahmen dieses Projektes nicht möglich.
Es scheint nicht Erfolg versprechend, dem Nutzer die Sprachebene des Entwicklers
abzuverlangen. Daher bleibt nur die Möglichkeit, dem Entwickler Mittel zur Verfügung zu stellen, die das Verständnis des Nutzers erleichtern. Der sukzessive Aufbau
einer Übersetzungstabelle wäre mit geringem Aufwand realisierbar und würde sich als
hilfreich erweisen. So könnten auch als selbstverständlich geltenden Kriterien als Standardparameter in geeigneter Form festgelegt und gespeichert werden. Darüber hinaus
wäre es sinnvoll, Begriffsdefinitionen aus Roteiro heranzuziehen, da der Nutzer einen
Großteil der Begrifflichkeiten von dort entlehnt. Allerdings ist zu bedenken, dass durch
den sukzessiven Aufbau einige Zeit vergehen wird, bevor zufrieden stellende Ergebnisse erzielt werden.
6
I. S. v. das Ergebnis entspricht nicht dem, was der Nutzer erwartet hat.
36
3.5. GRUNDSÄTZLICHE SCHWIERIGKEITEN
3.5.2
Abfrageerstellung
Eine weitere schwierige Aufgabe besteht in der Erstellung des SQL-Quelltextes der
Auswertung. In komplexen Produktivsystemen wie Roteiro7 fällt es selbst dann, wenn
der Benutzer bereits weiß, was er benötigt, nicht leicht, die entsprechenden Daten
zu extrahieren. Dies liegt zum Großteil daran, dass die Datenbank im Hinblick auf
Integritäts- und Konsistenzsicherung optimiert ist. Auch der andauernde Wandel von
Strukturelementen und die Integration neuer Merkmale verschlechtern die Übersichtlichkeit und erschweren die Datenentnahme. In der Praxis wird in diesem Zusammenhang oft von gewachsenen Systemen gesprochen, d. h. in das System werden nachträglich Sachverhalte aufgenommen, die bei der Planung nicht vorgesehen waren. Einfachste Sachverhalte bedürfen daher nicht selten komplexer SQL-Abfragen.
Wie bereits in Abschnitt 3.4.3 angesprochen, erleichtern inzwischen so genannte benutzerdefinierte Funktionen den Datenbankzugriff. Mit ihrer Hilfe lassen sich komplizierte Abfragen speichern und parametrisiert wieder verwenden. Dennoch haben auch
diese Funktionen Grenzen und Nachteile. Das größte Manko besteht darin, dass der bereits kompilierte Code der Funktion bei der SQL-internen Abfrageoptimierung nicht
mehr berücksichtigt wird. Die Folgen sind schwer kalkulierbare Geschwindigkeitsverluste, die sich besonders bei großen Abfragen und Datenmengen bemerkbar machen.
Bei kleinen Abfragen bzw. wenigen Daten bringen die Funktionen dagegen teilweise
erhebliche Geschwindigkeitsvorteile, was darauf zurückzuführen ist, dass der Code der
Funktion bereits in kompilierter Form vorliegt. Bei Auswertungen liegt der Hauptvorteil der benutzerdefinierte Funktion jedoch eindeutig in der zentralen Definition und
Speicherung von komplizierten Abfragen und Zusammenhängen.
Im Hinblick auf den in Abschnitt 3.2 formulierten Grundgedanken stellt sich die Frage, wie eine nutzergesteuerte Datenextraktion erfolgen soll. Sicher ist, dass der Nutzer
kein SQL für seine Abfrage benötigen darf. Dies hat zwei Gründe: Erstens ist davon
auszugehen, dass der überwiegende Teil der Roteironutzer keine SQL-Kenntnisse besitzt und zweiten ist das Erstellen von sinnvollen Abfragen nur mit Wissen über den
Aufbau des Datenmodells und den Zusammenhängen zwischen den Daten möglich.
Zweiteres stellt allgemein das Problem bei Abfragen dar. Metadaten- und Dokumentationssysteme versuchen die Schwierigkeiten zu minimieren, indem sie mehr Transparenz im Bereich Datenstruktur und -zusammenhang schaffen.
7
Die KDB enthält zur Zeit ca. 230 Tabellen mit mehr als 3000 Spalten.
37
3.6. ERWEITERUNG DER PROBLEMSTELLUNG
3.6
Erweiterung der Problemstellung
In diesem Abschnitt wird der in Abschnitt 3.2 formulierte Grundgedanke mit den gefundenen Problemen und daraus resultierenden Erkenntnissen kombiniert. Das Ziel
dabei ist, eine erste detaillierte Spezifikation der Aufgabenstellung unter Berücksichtigung bekannter Probleme zu erstellen, auf deren Basis eine zielgerichtete Suche nach
Lösungen möglich ist.
Der Grundgedanke der Ausarbeitung ist die Tatsache, dass sowohl die HypoVereinsbank (HVB) als auch das MHR die Entwicklung eines Systems anstreben, mit dem
sich nutzergesteuert Daten aus einer Datenbank extrahieren und analysieren lassen.
Dabei ergeben sich zusammengefasst folgende Probleme:
Sprach- und Verständigungsprobleme:
• allgemeine Sprachkonflikte zwischen Nutzer und Entwickler
• der einzelne Nutzer kennt i. d. R. nur die Daten, die er selbst verwendet
• Nutzer bezeichnen mit gleichen Begriffen verschiedene Sachverhalte
Probleme bei der Datenidentifikation:
• der Nutzer ist sich der Abfragedefinition oft nicht bewusst welche Parameter
bzw. Filter zu verwenden sind
• selbst den Administratoren der HVB sind die Strukturen und Abhängigkeiten
ihres Datenmodells nicht immer bewusst
• die Datenspeicherung in Roteiro ist teilweise sehr kompliziert
Zugriffsbeschränkungen:
• der Datenzugriff darf nur unter Berücksichtigung der in Roteiro implementierten
Nutzerrechte möglich sein
• Roteiro ist ein browserbasiertes IS, einzige Schnittstelle ist der Internet Information Services (IIS)
Sonstige Probleme:
• der Betrieb eines weiteren Datenbanksystems ist wegen zusätzlicher Hardwarekosten tendenziell unerwünscht
• Analyse und Extraktion sollen auf möglichst aktuellen Daten realisiert werden
38
3.7. LÖSUNGSMÖGLICHKEITEN
Spezifikation:
Unter Berücksichtigung der aufgelisteten Probleme muss das System folgenden Anforderungen genügen.
7→ Das System muss Daten extrahieren und analysieren können,
7→ Ergebnisse in geeigneter Form z. B. als CSV-, PDF- oder XLS-Datei speichern,
7→ den Nutzer bei der Datenauswahl unterstützen,
7→ aus Benutzersicht Abfragen ohne SQL ermöglichen,
7→ das in Roteiro implementierte Rechtekonzept umsetzen,
7→ in die Benutzeroberfläche von Roteiro integrierbar sein,
7→ auf dem operativen Produktionssystem aufsetzten und
7→ darf den Ablauf des Produktionssystems nicht behindern.
3.7
Lösungsmöglichkeiten
In diesem Abschnitt werden die verschiedene Möglichkeiten zur Realisierung des
Reporting-Moduls eingehend betrachtet und diskutiert. Potenziell bieten sich drei
Varianten zur Realisierung eines Reporting-Moduls. Hierbei handelt es sich um
OLAP/DWH, kommerzielle Reportingtools und eine Eigenentwicklung.
3.7.1
OLAP und Data Warehouse
Zunächst ist festzuhalten, dass OLAP und DWH bei der Bewertung der Lösungsmöglichkeiten zusammengefasst werden. Sie sind zwar jeweils eigenständige Konzepte8 ,
allerdings ist die einzelne Betrachtung im Kontext dieser Lösungssuche nicht sinnvoll.
Im Rahmen der gestellten Anforderungen ist auf Seiten des DWH nur der Einsatz einer virtuellen DWH-Lösung möglich, weil die Analysedaten aktuell sein sollen und
die Anschaffung neuer Hardware nicht finanzierbar ist. Da zum Einen virtuelle DWHLösungen oft Bestandteil von OALP-Systemen sind und zum Anderen ähnliche Vorund Nachteile wie OLAP aufweisen, sind unter dem Begriff OLAP-System im Folgenden auch virtuelle DWH zu verstehen.
8
Vgl. Abschnitt 2.5.7.
39
3.7. LÖSUNGSMÖGLICHKEITEN
OLAP-Systeme sind zur Datenanalyse konzipiert und darüber hinaus in der Lage, benutzerdefinierte Abfragen zu realisieren. Die Abfragen lassen sich mit dem Frontend
erstellen. Analysen von multidimensional gespeicherten Daten sind sehr schnell, zudem stellen OLAP-Systeme eine Reihe verschiedener Auswertungsmöglichkeiten aus
den Bereichen Statistik und Data Mining zur Verfügung. Die Distribution des Microsoft SQL Server 2000 (MsSQL2000), die vom MHR für die Datenspeicherung Roteiros eingesetzt wird, enthält bereits das OLAP-System Analysis Services, es würden
demnach keine zusätzlichen Softwarekosten entstehen.
Das Speichern der Analyseergebnisse in den gewünschten Formaten stellt kein Problem dar.
Bei der Datenauswahl unterstützen OLAP-Systeme wie Analysis Services den Benutzer insofern, dass Spalten aus Tabellen ausgewählt werden können. Die sinnvolle
Verknüpfung der Daten aus mehreren Tabellen erfolgt automatisch unter Verwendung
der Fremdschlüsselbeziehungen. Die Datenauswahl ist somit ohne SQL möglich, allerdings navigiert der Benutzer direkt auf der Produktivdatenbank. Demzufolge sind
Kenntnisse zur Datenstruktur der Inhalte unbedingt erforderlich.
Die Nutzerrechte werden direkt in der OLAP-Datenbank definiert. Die Nutzung des
Rechtekonzepts aus Roreiro ist damit nicht möglich.
Da es sich bei OLAP-Systemen i. A. um Client-Server-Anwendungen handelt, ist der
volle Funktionsumfang lediglich bei der Verwendung des Frontends möglich, dessen
Einsatz sich jedoch aus zwei Gründen verbietet. Erstens müsste die Clientsoftware
beim Nutzer lokal installiert sein, was aber aus Sicherheitsgründen bei der HVB nicht
erlaubt ist. Zweitens müssten Client- und Serversoftware direkt miteinander kommunizieren können. Das hätte jedoch zur Folge, dass der OLAP-Server auf dem mit der
Außenwelt verbundenen Webserver installiert sein müsste. Auch dies ist aus Sicherheitsgründen nicht zulässig. Die angestrebte Integration in Roteiro mittels der standardisierten Schnittstelle OLE DB for OLAP ist nur mit erheblichem Aufwand möglich,
denn einerseits fehlt es dem MHR an Kenntnissen zum Umgang mit dieser Schnittstelle und andererseits bringt die Integration großen Programmieraufwand mit sich.
OLAP-Systeme können zwar direkt auf relationale Datenbanken aufsetzen und deren
Daten analysieren, allerdings geht dabei der wesentliche Geschwindigkeitsvorteil verloren. Um diesen im vollen Umfang auszunutzen, müssten die auszuwertenden Daten
zuvor in multidimensionaler Form gespeichert werden. Diese Überführung der Daten birgt jedoch erhebliche Schwierigkeiten, denn die multidimensional gespeicherten
Daten stellen lediglich das Abbild zum Zeitpunkt der Überführung dar. Demzufolge
müssten die Daten entweder vor jeder Auswertung erneut überführt werden, was allein
40
3.7. LÖSUNGSMÖGLICHKEITEN
aus zeitlicher Sicht nicht vertretbar ist, oder es müsste eine periodische Aktualisierung, die beispielsweise täglich oder wöchentlich durchgeführt werden würde, in Kauf
genommen werden.
Zusammenfassend ist festzustellen, dass OLAP- und DWH-Systeme für die Lösung
der bestehenden Problem nicht in Frage kommen.
3.7.2
Externe Berichtswerkzeuge
Reportingtools wie z. B. Business Objects Crystal Reports, Cognos ReportNet oder
Microsoft Reporting Services sind spezielle Softwarelösungen zur Berichtserstellung.
Auch wenn sich die Zielsetzungen dieser Produkte stark ähneln, gibt es z. T. erhebliche
Unterschiede in der Art und den Umfang der Umsetzung. Da es sich bei den genannten
Berichtswerkzeugen um auf dem Markt weit verbreitete Produkte handelt, sollen sie
an dieser Stelle als Stellvertreter für die Bewertung dienen.
Die Extraktion und Analyse von Daten aus verschiedensten Quellen sowie die Speicherung der Ergebnisse in unterschiedlichsten Dateiformen sind elementare Bestandteile
dieser Systeme. Darüber hinaus bieten sie Hilfsmittel zur Berichtsgestaltung und zur
Erstellung von Graphiken.
Bei der Abfrageunterstützung zeigen sich gravierende Unterschiede. Während Crystal
Reports und ReportNet auf graphische Unterstützung setzen, sind die Datenabfragen
in Reporting Services mit SQL zu definieren. Allerdings wird in der Welt der Berichtswerkzeuge unter einem Nutzer immer ein Individuum verstanden, welches sich mit
den Datenstrukturen der Datenbank auskennt. Dies ist i. d. R. ein Administrator oder
Entwickler. Der eigentliche Nutzer des Systems wird meist als Empfänger, Kunde oder
Partner bezeichnet und hat nur wenige Möglichkeiten, die Berichtsdarstellung oder deren Inhalte zu beeinflussen.
Alle Werkzeuge bringen ihre eigenen Komponenten zur Rechteverwaltung mit. Inwiefern externe Rechtekonzepte übernommen werden können, ist nicht bekannt.
Die Anzeige der erstellten Berichte als Webseite ist generell bei allen Tools möglich.
Das liegt nicht zuletzt daran, dass Berichte verteilt werden müssen und Netzwerke
dazu ein ideales Medium sind. Allgemein zeigen sich bei den Nutzerschnittstellen
die größten Unterschiede zwischen den Reportinglösungen. Während ReportNet den
kompletten Funktionsumfang als browserbasiertes System zur Verfügung stellt, bietet Reporting Services lediglich die Darstellung und Verwaltung der Berichte über die
Webschnittstelle. Zur Reporterstellung wird zusätzlich Microsoft Visual Studio benö41
3.7. LÖSUNGSMÖGLICHKEITEN
tigt. Um bei Crystal Reports den vollen Funktionsumfang nutzen zu können, ist der
Benutzer auf das Frontend angewiesen. Dieses unterstützt ihn nicht nur bei der Berichtserstellung und -verwaltung, sondern bietet darüber hinaus viele Analysehilfen,
die sich sonst in OLAP- und Data Mining-Werkzeugen finden.
Um die Integration in verschiedenste Anwendungen zu ermöglichen, verfügen die
untersuchten Berichtswerkzeuge über Programmierschnittstellen, mit deren Hilfe ein
Großteil der Funktionalitäten auch von externen Anwendungen genutzt werden kann.
Abschließend ist zu den Reportingtools festzuhalten, dass sie zahlreiche nützliche
Hilfsmittel und Funktionen bieten, um das Standardreporting einfacher und effektiver
zu gestallten. Graphische Darstellungen sowie Analysewerkzeuge aus den Bereichen
OLAP und Data Mining helfen zudem dabei, den zur Verfügung stehenden Daten noch
mehr Information zu entnehmen.9
Zur Lösung des Hauptproblems der Ausarbeitung sind sie dennoch ungeeignet, da sie
in jedem Fall Administrator- bzw. Entwicklerwissen zur Datenextraktion voraussetzen.
Es fehlen Konzepte, die es Nutzern ermöglichen, Daten ohne Kenntnis der Datenstruktur abzufragen.
3.7.3
Eigene Entwicklung
Es ist anzunehmen, dass eine maßgeschneiderte Lösung die gestellten Anforderungen
am ehesten erfüllen wird, da sich die Realisierung an den Problemen orientiert, jedoch
sind dabei Kosten im Auge zubehalten.
Für häufig auftretende Probleme und Aufgabenstellung bietet externe Software zumindest im Hinblick auf Kosten und Nutzen meist die günstigere Alternative. Denn
sie garantiert den Erhalt eines großen Umfangs an Funktionen und Unterstützung und
die Kosten dafür liegen unter denen, die bei der Entwicklung einer eigenen Software
entstehen würden. Ausgehend davon kann festgestellt werden, dass eine Eigenentwicklung meist nur dann sinnvoll ist, wenn es keine externe Lösung gibt, die die gestellten
Anforderungen erfüllt.
Das zu entwickelnde Reporting-Modul ist ein solcher Fall. Aus der fehlenden Möglichkeit, ein Modell zu definieren, das es auch einem Nutzer gestattet, Daten zu extrahieren, resultiert die Notwendigkeit, ein solches Modell selbst zu entwickeln. Die
Realisierung des Reporting-Moduls wird in den Kapiteln 4 und 5 eingehend beschrieben.
9
Weiter Informationen zu den beschriebenen Berichtswerkzeugen befinden sich in Anhang B.
42
Kapitel 4
Software Engineering
In diesem Kapitel wird die Entwicklung des Reporting-Moduls, das im folgenden auch
als Reporting-Engine (RPE) bezeichnet wird, aus der Sicht der System- und Softwareentwicklung betrachtet, dessen strukturiertes Vorgehen möglichen Entwicklungsfehlern entgegen wirken soll.
Die Anwendungsentwicklung erfolgt idealtypisch in den sechs Phasen Analyse, Konzeption, Design, Implementierung, Einführung und Betrieb. [STEI05, S. 4 ff.] Da der
Ist-Zustand bereits in Kapitel 3 sowohl ausführlich erläutert als auch analysiert wurde
und die Einführung sowie der Betrieb des Reporting-Moduls nicht Gegenstand dieser Ausarbeitung sind, verbleiben lediglich die Phasen Konzeption, Design und Implementierung. Letztere wird separat in Kapitel 5 behandelt. Als Ergebnis der ISTAnalyse wird zunächst die Anforderungsdefinition mittels Lastenheft präsentiert, bevor die Konzeption und das Design der RPE vorgestellt werden.
4.1
Anforderungsdefinition
Zur strukturierten Abbildung der Anforderungsdefinition eines Softwaresystems wird
in der Praxis häufig ein Lastenheft verwendet. Bei umfangreichen Softwareprojekten
wird aus diesem in einem zweiten Schritt ein Pflichtenheft erstellt, das die einzelnen Abschnitte des Lastenheftes weiter verfeinert. Das Pflichtenheft dient später sowohl als Grundlage für die Entwicklung als auch als Basis für Vertragsverhandlungen.
[SCHW95, S.106 ff.] Da es sich bei der Entwicklung im Rahmen dieser Ausarbeitung
lediglich um ein Teilsystem handelt, wird sich auf die weniger detaillierte Anforderungsdefinition mittels Lastenheft beschränkt.
43
4.1. ANFORDERUNGSDEFINITION
4.1.1
Zielbestimmung
Die Zielbestimmung präzisiert die Zielstellung der Entwicklung mittels dreier Kriterien: Musskriterien sind zwingend zu erfüllen und bilden den zentralen Kern der Entwicklung. Kannkriterien bezeichnen Aufgaben und Eigenschaften der Software, die
erwünscht, aber nicht unbedingt erforderlich sind. Die Abgrenzungskriterien dienen
letztlich dazu, die Zielstellung mit Hilfe einer Negativliste so weit wie möglich einzugrenzen.
Musskriterien:
• Extraktion von Daten aus der KDB
• Datenauswahl durch Roteironutzer
• Verwaltung der Datenauswahl und zugehöriger Ergebnisse
• Darstellung relationaler und multidimensionaler Daten
• Datenausgabe in den Formaten HTML, PDF und XLS
• keine Störung des Betriebs Roteiros
Kannkriterien:
• Analyse der KDB-Daten
• graphische Darstellung und Analyse
Abgrenzungskriterien:
• kein vollständiger Abfragegenerator
4.1.2
Produkteinsatz
Der Produkteinsatz betrachtet das Einsatzgebiet der Software-Lösung von drei verschiedenen Standpunkten. Dabei stellt jeder Blickwinkel eine weitere Spezifikation
der Anforderungen dar.
Das Reporting-Modul dient der nutzergesteuerten Entnahme von Daten aus der KDB.
Da es sich bei der RPE um ein in Roteiro zu integrierendes Teilsystem handelt, ist der
Einsatzbereich in jedem Fall stark an das Gesamtsystem gebunden.
44
4.1. ANFORDERUNGSDEFINITION
Anwendungsbereiche
Roteiro und damit auch RPE finden ihre Anwendung im Bereich Electronic Services
der HVB.
Zielgruppen
• Mitarbeiter des Bereiches Electronic Services (Anfangs mind. Level 2)
• Administratoren des MHR
Betriebsbedingungen
• Nutzung im Einschichtbetrieb, für etwa 8 bis 10 Stunden täglich
• MultiUserAnwendung
• Administratorunterstützung
4.1.3
Produktübersicht
Die Produktübersicht in Abbildung 4.1 visualisiert die Einordnung des Moduls ins
Gesamtsystem. Die Darstellung zeigt das die RPE zur Ausführung den Web- und Applikationsserver Roteiros und zur Datenspeicherung einen Teil der KDB nutzen soll.
Durch dieses Vorgehen ist eine vollständige Integration der RPE in Roteiro gewährleistet.
Abbildung 4.1: Die ReportingEngine im Anwendungskontext
45
4.2. KONZEPTION
4.1.4
Produktfunktionen, -daten und -leistungen
In diesem Abschnitt werden stichpunktartig sowohl die Funktionen und Leistungen als
auch die Daten, die die Software zur Verfügung stellen bzw. mit denen sie umgehen
muss, definiert.
Produktfunktionen
F10 Erstellung und Verwaltung von Auswertungsdefinitionen
F20 Umsetzung der Auswertungsdefinitionen zu Auswertungsergebnisse
F30 Verwaltung der Auswertungsergebnisse
F40 Erstellung der Ergebnisausgabe als HTML, PDF und XLS
Produktdaten
D10 alle relevanten Nutzdaten der KDB
D20 Metadaten zur Beschreibung der Nutzdaten
D30 Formatierungsdaten des Reports
D40 Ergebnisdaten des Reports
Produktleistungen
L10 nutzerdefinierte Datenabfragen
L20 Speicherung der Abfrageergebnisse
L30 dynamische Darstellung der Ergebnisse
4.2
Konzeption
Dieser Abschnitt dient der Erstellung eines Modells, welches die gestellten Aufgaben
und Anforderungen erfüllen soll. Das Konzept wird mittels Top-Down-Entwurfes erstellt und mit Hilfe von Use-Case-Diagrammen visualisiert.
Im ersten Schritt des Top-Down-Entwurfs wird das Grobkonzept erstellt, das den prinzipiellen Ablauf der nötigen Prozesse skizziert. Anschließend werden diese Prozesse
im Feinkonzept weiter konkretisiert.
46
4.2. KONZEPTION
4.2.1
Grobkonzept
Die Grundidee der RPE besteht darin, SQL-Abfragen so zu definieren, dass sich der
Roteironutzer später beliebige Auswertungen zusammenstellen kann. Um dies zu erreichen wird, der SQL-Quellcode modular gespeichert. Im Folgenden wird der so gespeicherte Quellcode als Abfragefragment oder -teil bezeichnet. Abbildung 4.2 illustriert die Beziehungen zwischen den vier zentralen Prozessen und den zwei beteiligten
Akteuren.
Abbildung 4.2: Use Case Diagramm des Grobkonzeptes
Der Prozess ist aus zwei Blickwinkeln zu betrachten: aus Administrator- und aus Nutzersicht. Aufgabe der Administratoren wird es sein, im Vorfeld alle Abfrageteile, die
die Nutzer in ihren Auswertung verwenden möchten, zu definieren. Dieser Vorgang
erfolgt für jedes Fragment einmalig. Nach der Definition kann es durch beliebig viele
Nutzer beliebig oft wiederverwendet werden.
Die Beziehung zwischen Nutzer und Administrator, welche die Definition benötigter
Abfragefragmente initiiert, wird im Modell absichtlich nicht abgebildet. Dafür gibt es
folgende Gründe:
1. Der Kommunikationsprozess zwischen Nutzer und Administrator ist für den
Kerngedanken des Konzepts irrelevant.
2. Es handelt sich um einen für jeden einzelnen Abfrageteil einmaligen Prozess.
3. Die ersten Definitionen von Abfragefragmenten erfolgen auf Grundlage der Auswerungsanalyse bzw. ausgewählter Beispiele.
Aus Nutzersicht ist für eine Auswertung sowohl der Inhalt als auch das Layout zu
definieren. Nach der Erstellung werden dem Nutzer die Ergebnisse in Dateiform zur
Verfügung gestellt.
Die Generierung und Ausführung der SQL-Abfrage erfolgt vollautomatisch.
47
4.2. KONZEPTION
4.2.2
Feinkonzept
In diesem Abschnitt werden die im Grobkonzept vorgestellten Prozesse weiter verfeinert, d. h. jeder Prozess wird in weitere Teilprozesse zerlegt.
Abfragefragmente definieren
In diesem Prozess werden SQL-Abfragen so zerteilt, dass die Fragmente später zu
beliebigen, jedoch trotzdem korrekten SQL-Abfragen kombiniert werden können. Abbildung 4.3 verdeutlicht die Zusammenhänge zwischen den zu definierenden Teilen.
Abbildung 4.3: Use Case: Abfragefragmente definieren
Die SQL-Abfrage wird in die vier Bestandteile Tabellendaten, Filter, Verknüpfungen
und Nutzdatenabfrage zerlegt. Die Tabellendaten bestehen aus dem Tabellennamen
und dem Primärschlüssel. Filter dienen der Einschränkung der Datenmenge. Verknüpfungen repräsentieren für Auswertungen sinnvolle Fremdschlüsselbeziehungen zwischen zwei Tabellen. Als Nutzdaten werden im Rahmen dieser Ausarbeitung die Daten
bezeichnet, die dem Nutzer letztendlich zur Verfügung gestellt werden.
Um den Nutzer eine Auswertungsdefinition ohne SQL-Kenntnisse zu ermöglichen,
werden zusätzlich zu den Abfragefragmenten Metadaten mit Informationen zur Bedeutung der Teile abgelegt. Diese fungieren dann als Übersetzungsschicht.
Auswertung zusammenstellen
Das Zusammenstellen der Auswertung wird im weiteren Verlauf dieser Ausarbeitung
als Erstellung eines Auswertungsprofils bzw. als Erstellung eines Profils bezeichnet.
Diese Begrifflichkeit wurde gewählt, um zu verdeutlichen, dass es sich bei der Zusammenstellung nicht um reale Daten sondern lediglich um deren Beschreibung handelt.
48
4.2. KONZEPTION
Abbildung 4.4: Use Case: Auswertung zusammenstellen
Ein Auswertungsprofil wird von einem Nutzer definiert. Dieser ist der Eigentümer des
Profils. Das Verändern oder Löschen eines Profils ist ausschließlich1 dem Eigentümer
vorbehalten.
Abbildung 4.4 verdeutlicht die grundlegenden Prozesse beim Anlegen eines Profils. Gleichzeitig sind die drei enthaltenen Informationsarten erkennbar. Dies sind
Auswertungs-, Anzeige- und Profilinformationen.
Abfrage generieren und ausführen
Das Generieren und Ausführen der SQL-Abfrage wird als vollautomatischer Prozess
konzipiert. Eine direkte Interaktion mit einem Akteur ist demnach nicht notwendig.
Die Darstellung als Use Case Diagramm ist aus diesem Grund nicht sinnvoll. Stattdessen soll das Aktivitätsdiagramm in Abbildung 4.5 den grundsätzlichen Ablauf dieses
Prozesses verdeutlichen.
Abbildung 4.5: Aktivitätsdiagramm: Abfrage zusammenstellen
Ergebnisse abholen
Der Prozess des Abholens der Ergebnisse wird nicht weiter verfeinert, da er keine
Unterprozesse besitzt. Er ist jedoch für das Verständnis des Konzeptes von zentraler
1
Hiervon ausgenommen sind administrative Eingriffe.
49
4.3. DESIGN
Bedeutung. Durch ihn wird signalisiert, dass sowohl die Datenabfrage als auch die Datenaufbereitung nicht online realisiert werden. Mit diesem Vorgehen soll der gestellten
Anforderung nachgekommen werden, den reibungslosen Betrieb des Produktivsystems
so wenig wie möglich zu stören.
Da es bei den bisherigen manuellen Auswertungen in jedem Fall zu Wartezeiten kam,
stand schon bei Projektbeginn fest, dass eine warteschlangenbasierte Lösung einer
RPE in Frage kommen würde. Dadurch lassen sich Probleme, die insbesondere durch
den Mehrbenutzerbetrieb und durch umfangreiche Auswertungen entstehen, erheblich
entschärfen. Beispielsweise gab es in der Vergangenheit Auswertungen, die Laufzeiten von mehr als 30 Minuten aufwiesen. Diese Auswertung über eine Webschnittstelle
auszuführen, hätte unweigerlich ein Timeout des Webservers zur Folge. Zudem würde
die gleichzeitige Ausführung vieler Auswertungen mit großer Wahrscheinlichkeit den
Betrieb des Produktivsystems erheblich behindern.
Durch den Einsatz eines warteschlangenbasierten Systems können diese Probleme umgangen werden. Der Nutzer stellt seinen Auftrag ein und wird bei Fertigstellung informiert. Die Abarbeitung der Aufträge kann damit so gesteuert werden, dass die zur
Verfügung stehende Rechenzeit optimal genutzt wird. Das könnte z. B. auch bedeuten,
dass die Ausführung der Auswertungen auf die Tageszeiten verlegt werden, in denen
niemand am Produktivsystem arbeitet.
4.3
Design
Ziel der Designphase ist es, auf Grundlage der Konzeption eine Softwarearchitektur zu erstellen und damit die anschließende Realisierung des Systems vorzubereiten.
[STEI05, S. 7]
Zunächst wird das zu entwickelnde System verbal beschrieben. In weiteren Schritten
folgt die technische Darstellung.
4.3.1
Verbale Beschreibung
Zur Realisierung des Funktionsumfangs wird die RPE in vier Komponenten unterteilt. Diese Unterteilung orientiert sich an den zu erfüllenden Aufgaben und an den
Programmiersprachen, mit denen diese umgesetzt werden. Als Ergebnis entstehen die
folgenden Komponenten.
50
4.3. DESIGN
Das UserInterface (UI) wird als Webanwendung mittels ASP umgesetzt. Seine Aufgabe besteht darin, dem Nutzer eine einfache und intuitive Benutzung des Reportingmoduls zu ermöglichen. Gleichzeitig soll es mit Hilfe von Eingabemasken und Plausibilitätstests Fehler, die durch falsche Eingaben entstehen, verhindern. Weiterhin ist ein
Teil des UI für die Administration des Reportingmoduls vorgesehen. Das UI stellt die
zentrale Schnittstelle der RPE dar. Es verknüpft sowohl die Module untereinander, als
auch das Reportingmodul mit dem Informationssystem. Da das MHR auf die Entwicklung webbasierter UI spezialisiert ist und sich die RPE nahtlos in Roteiro einfügen soll,
wird das Design und die Realisierung des UI von einem Entwickler des MHR erfolgen.
Im Rahmen dieser Ausarbeitung werden lediglich die formalen Schnittstellen zu den
einzelnen Komponenten definiert.
Die Datenbankkomponente (DBK)
beinhaltet hauptsächlich das Datenmodell, wel-
ches zur Verwaltung und Speicherung der Abfragefragmente, den Auswertungsdefinitionen und deren Ergebnissen benötigt wird. Darüber hinaus werden SQL-Funktionen
und -Prozeduren, so genannte „userdefined Functions“ und „stored Procedures“, zur
funktionalen Unterstützung des System genutzt. Durch die Nutzung von Filtern und
Nutzdatenabfragen, die als SQL-Funktionen oder -Prozeduren implementiert wurden,
können vorhandene Funktionalitäten aus Roteiro direkt in der RPE verwendet. Im Umkehrschluss sind dadurch auch Funktionen, die im Rahmen der Realisierung und des
Betriebes der RPE entstehen, unmittelbar in Roteiro einsetzbar.
Die Query-Engine (QE) wird zur Generierung des SQL-Quellcode eingesetzt. Die
gesamte Logik, die benötigt wird, um aus den Abfragefragmenten und dem Auswertungsprofil eine korrekte SQL-Abfrage zu erstellen, wird als Perlskript abgelegt. Für
diese Aufgabe könnte auch jede andere Programmiersprache genutzt werden, da Perl
jedoch schon in anderen Modulen Roteiros benutzt wird und es sich um eine sowohl
einfache als auch vielseitige Sprache handelt, bietet sich ihre Verwendung in diesem
Projekt an.
Um die in Abschnitt 4.2.2 angesprochene warteschlangenorientierte Lösung zu realisieren, wird ein vom MHR entwickeltes Inter Process Communication Modul (IPC)
eingesetzt. Dieses übernimmt bereits seit Längerem die kapazitätsabhängige Ablaufsteuerung von Prozessen in Roteiro.
Die Output-Engine (OE)
wird letztendlich die Darstellung der Ergebnisse überneh-
men. Da die Abfrageergebnisse in homogener Form in der Datenstruktur der RPE gespeichert werden, wird die OE in der Lage sein, Ergebnisse jeglicher Art darzustellen.
Zunächst ist eine Ausgabe in HTML geplant. Darüber hinaus wird jedoch in späteren
Versionen auch das Erzeugen von PDF- und MS Exceldateien angestrebt.
51
4.3. DESIGN
Die Planung und Implementierung der OE wird nicht im Rahmen dieser Ausarbeitung
erfolgen, da sie bereits als Gegenstand eines anderen Projektes vorgesehen ist.
4.3.2
Komponentenüberblick
In diesem Abschnitt wird zunächst das Zusammenspiel der Komponenten erläutert,
bevor in den nächsten Abschnitten auf das Design der einzelnen Teile eingegangen
wird.
Abbildung 4.6 verdeutlicht sowohl den allgemeinen Programmablauf als auch die nötigen Datenflüsse zur Erstellung einer Auswertung. Dieser idealtypische Ablaufplan
geht davon aus, dass alle benötigten Abfrageteile bereits im Vorfeld definiert wurden.
Abbildung 4.6: Zusammenspiel der RPE-Komponenten
Die Erstellung der Auswertung beginnt mit der Definition eines Auswertungsprofils.
Die benötigten Profildaten werden mittels UI entgegen genommen und im Datenmodell der DBK gespeichert. Anschließend wird der Auftrag zur Umsetzung des Profils
in die Warteschlange des IPC-Moduls eingestellt. Sobald freie Kapazitäten vorhanden sind, veranlasst das IPC-Modul den Start der QE. Diese liest die Profildaten und
Abfragefragmente aus der DBK, erstellt den SQL-Quellcode der Abfrage und führt
ihn aus. Die Ergebnisse der Abfrage werden in der DBK gespeichert. Danach signalisiert die QE dem UI die Beendigung seiner Aktivitäten, woraufhin der Nutzer über
die Bereitstellung der Auswertungsergebnisse informiert wird. Im letzten Schritt nutzt
das UI die OE um dem Nutzer die Ergebnisse seiner Auswertung in Form von HTML
darzustellen bzw. als PDF- oder XLS-Datei zur Verfügung zu stellen.
52
4.3. DESIGN
4.3.3
Datenbankkomponente
Wie in Abschnitt 4.3.2 deutlich wurde, stellt das Datenmodell den zentralen Datenspeicher und damit das Herzstück des Reporting-Moduls dar. Durch die Verwendung eines zentralen Speichermediums ist es möglich, die Schnittstellen zwischen
den Komponenten weitestgehend zu minimieren und damit einer wichtigen Forderung
der Softwareentwicklung, dem Prinzip der schmalen Datenkopplung, nachzukommen.
[SCHW95, S. 150]
In diesem Abschnitt wird das benötigte Datenmodell unter Verwendung des EntityRelationship-Modells (ERM) entwickelt. Bereits in Abschnitt 4.2.1 wurde der grobe
Rahmen für die zu speichernden Daten gesteckt, wobei sich die drei Bereiche administrative, Nutzer- und Ergebnisdaten heraus kristallisierten.
Im Folgenden wird zu jedem der Datenbereiche ein separates Entity-RelationshipDiagramm (ERD) angefertigt. Diese werden im letzten Schritt zu einem Gesamtmodell
zusammengefügt.
Administrative Daten
Als administrative Daten werden die Abfragefragmente bezeichnet, da diese ausschließlich von Administratoren anzulegen sind. Neben Informationen zu Spalten, Tabellen und Auswahlkriterien, so genannten Filtern, werden hier auch Metadaten abgelegt, die die Bedeutung der Abfrageteile beschreiben. Aggregationen werden zunächst
nicht in das Modell aufgenommen, denn zum Einen erschweren sie die Modellierung
und zum Anderen sind Gruppierungen und Aggregationen in den bisherigen manuellen
Auswertung eher die Ausnahme. Zudem ist eine Aggregation erst auf Nutzdaten sinnvoll. Demnach kann diese Arbeit auch von einer späteren Erweiterung übernommen
werden.
Abbildung 4.7: ERD der administrativen Daten
Abbildung 4.7 stellt das ERM der administrativen Daten dar. Die Entität Line reprä53
4.3. DESIGN
sentiert die Spalteninformationen einer Abfrage. Der Begriff Line soll signalisieren,
dass die Nutzdaten mehrdimensional darstellbar sind. Eine Line gehört zu genau einem Show_Block. Zu einem Show_Block gehört mindestens eine Line. Ein Element
der Entität Show_Block stellt dabei zusammengehörige Daten aus Nutzersicht dar. Ein
Element der Entität Query_Block verkörpern dagegen eine Tabelle oder ein abstraktes Filtermodul und repräsentiert den logischen Speicherort der Daten. Auch zu einem
Query_Block gehört mindestens eine Line und eine Line gehört zu genau einem Query_Block.
Die Implementierung von Filtermodulen ist als stored Procedure oder userdefined
Function geplant. Zur Ausführung wird eine Parameterliste benötigt. Die Entität
Filter_Para repräsentiert die einzelnen Filterparameter eines Filtermoduls. Ist das
Query_Block-Element eine Tabelle, so stellt ein Filterparameter eine mögliche Selektionsbedingung dar. Dabei hat ein Query_Block beliebig viele Filter_Para. Ein Filterparameter wiederum gehört zu genau einem Query_Block. Zur Speicherung von festen
Parameterwerten wird jedem Filter_Para eine beliebige Anzahl an Para_Values zugeordnet, wobei ein Para_Value immer zu genau einem Filterparameter gehört.
Das Zusammenfügen von beliebigen Daten wird dadurch erreicht, dass jeweils zwei
Abfrageblöcke mittels Verbundoperation zusammengefügt werden. Um diese Beziehung abzubilden, stellt die Entität Connection jeweils die linke und rechte Verbindung
zwischen zwei Query_Blocks dar.
Nutzerdaten
Nutzerdaten enthalten die Nutzereingaben, die ein Auswertungsprofil beschreiben.
Dies sind z. B. der Name des Profils, die ausgewählten Inhalte und Parameter für verwendete Filter. Darüber hinaus soll in späteren Versionen der RPE auch ein Großteil
des Berichtslayouts durch den Nutzer definiert werden. In dieser Phase der Entwicklung wird jedoch zunächst auf diese Funktionalität verzichtet und lediglich ein Standardlayout verwendet.
Abbildung 4.8: ERD der Nutzerdaten
Abbildung 4.8 zeigt die zur Speicherung der Nutzerdaten nötigen Strukturen. Die Entität Profil enthält allgemeine Profilinformationen. Zu jedem Profil werden Inhalte in
Form von Lines definiert. Diese stellen im Kontext der Abfrage die Projektion dar.
54
4.3. DESIGN
Zu jedem Profil gehört mindestens eine Profil_Projection, eine Profil_Projection gehört dabei genau zu einem Profil. Die Entität Profil_Selection repräsentiert alle vom
Nutzer ausgewählten Filterbedingungen. Da auch Verbundoperationen eine Filtercharakter aufweisen, fließen sie an dieser Stelle in die Selektion mit ein. Die Filterung
beeinflusst die Gesamtmenge der Ausgabe, deshalb gilt: Ein Profil hat beliebig viele
Profil_Selection, wobei jede zu genau einem Profile gehört.
Ergebnisdaten
Unter Ergebnisdaten werden in erster Linie die Ergebnisse einer Auswertung verstanden. Hier spielt die Art und Weise, wie die Daten gespeichert werden, eine wichtige
Rolle. Damit die OE später auf alle Ergebnisse in der gleichen Art und Weise zugreifen kann, muss eine dynamische Datenstruktur geschaffen werden. Darüber hinaus
schließt der Begriff Ergebnisdaten in diesem Kontext alle nötigen Daten zur Ergebnisverwaltung und -beschreibung mit ein.
Abbildung 4.9: ERD der Ergebnisdaten
Das Modell zur Speicherung der Ergebnisdaten wird durch Abbildung 4.9 veranschaulicht. Die Verwaltungsdaten eines Auswertungsauftrags werden durch die Entität Job
dargestellt. Sie verwaltet die Ergebnisse, die durch die Ausführung einer Auswertung
entstehen. Ein Job hat beliebig viele Job_Lines, wobei eine Job_Line zu genau einem Job gehört. Die gesamten Ergebnisse eines Jobs werden mit Hilfe der Entität
Job_Data abgebildet, um mit Hilfe eines einheitlichen Speicherortes die Datenausgabe
mittels OE zu ermöglichen. Da jede Job_Line mindestens ein Job_Data hat und umgekehrt, wird zur Abbildung dieser Beziehung eine Kreuztabelle benötigt. Die Entität
Job_LineData illustriert diese Beziehung. Mit ihrer Hilfe lassen sich die Zusammenhänge zwischen Line und Data wie in einem Koordinatensystem abbilden.
Gesamtdatenmodell
Im letzten Schritt werden die drei Datenbereiche zu einem Datenmodell zusammengefügt. Die abstrakte Line, welche die Menge der erwünschten Daten repräsentiert, stellt
dabei das Bindeglied zwischen den einzelnen Datenbereichen dar. Zudem spiegelt das
Datenmodell den angestrebten Wiederverwendungsgedanken wieder. Eine Line wird
Bestandteil beliebig vieler Auswertungen, indem sie als Projektion in das jeweilige
Auswertungsprofil einfließt. Wird eine Auswertung mehrmals ausgeführt, so wird die
Projektion, die auch als Line eines Profils bezeichnet werden kann, in mehreren Jobs
verwendet. Da es durchaus möglich ist, dass aus einer Auswertung ein leeres Ergebnis
55
4.3. DESIGN
resultiert, jedoch keine leeren Datenfelder gespeichert werden sollen und die Dokumentation des Jobs erwünscht ist, wird ein Job direkt einem Profil zugeordnet.
Abbildung 4.10: ERD des gesamten Datenmodells
Abbildung 4.10 zeigt das gesamte Datenmodell. Die Umsetzung in konkrete Datenbanktabellen erfolgt in Abschnitt 5.1.
4.3.4
Query-Engine
Der folgende Abschnitt wird sich mit dem konzeptionellen Design der QE auseinander
setzen. Dabei wird zunächst auf Gegebenheiten in der KDB eingegangen, bevor das in
Abschnitt 4.2.2 vorgestellte Konzept weiter verfeinert wird.
Die Kundendatenbank
Die KDB stellt die Datenbasis der Auswertungen dar. Um den Entwicklungsaufwand
so klein wie möglich zu halten, wird die RPE und damit auch die QE weitestgehend
an die Gegebenheiten der KDB angepasst.
Bei der Entwicklung wird sich der Sachverhalt zunutze gemacht, dass alle Tabellen
der KDB einen numerischen künstlichen Primärschlüssel besitzen. Dieses Schlüsselattribut wird im Folgenden als Index oder Primärschlüssel einer Tabelle bezeichnet. Es
sei darauf hingewiesen, dass dieser als Index bezeichnete künstliche Primärschlüssel
nichts mit dem für die Abfragebeschleunigung verwendeten Spaltenindex zu tun hat.
56
4.3. DESIGN
Als Konsequenz daraus ist jeder Datensatz der KDB über den Tabellennamen und
einen numerischen Wert adressierbar. Dies wiederum ermöglicht es den Ablauf der
QE in zwei separate Teilbereiche aufzuteilen: das Zusammenstellen der Abfragedaten
als Indizes sowie das Umwandeln der Indizes in Nutzdaten und Eintragen der Daten in
die Tabellenstruktur. Aus Sicht des Relationenmodells werden durch diese Aufteilung
Selektion und Projektion voneinander getrennt.
Selektion und Verbundoperationen
Das Projekt hatte bis dato mehr Zeit in Anspruch genommen als geplant. Zudem wurde seitens der HVB eine schnelle Möglichkeit benötigt, die zur Zeit fehlenden manuellen Auswertungen zu ersetzen. Die Implementierung des UI und der QE hatten noch
nicht begonnen, die OE und das Datenmodell waren jedoch nahezu fertiggestellt. Aus
diesem Grund fiel die Entscheidung, zunächst den zweiten Schritt der QE, also die
Projektion, zu realisieren. Durch den modularen Aufbau der RPE war dies prinzipiell
möglich.
Da der Autor vor Beendigung des Designs der Selektion aus dem Projekt ausschied,
wird dieser Teilbereich lediglich in stark verkürzter Form dargestellt. Die Implementierung des Selektionsmoduls wird aus diesem Grund ebenfalls nicht im Rahmen dieser
Ausarbeitung stattfinden.
Der Begriff der Selektion bezeichnet die Datenoperation zur Auswahl von Tupeln aus
einer Tabelle. [KREM01, S. 112] Eine Verbundoperation verbindet zwei Tabellen über
ein gemeinsames Merkmal. [MEIE04, S. 219]
Aufgabe des Selektionsmoduls ist die Erstellung einer Temporärtabelle, die für jede
an der Auswertung beteiligte Tabelle genau eine Spalte mit dessen Primärschlüssel
enthält.
Ist lediglich eine Tabelle an der Auswertung beteiligt, wird die Abfrage aus den einzelnen Fragmenten zusammengestellt und das Ergebnis in ein temporäre Tabelle umgeleitet, die dann an den zweiten Schritt der QE, die Projektion, übergeben wird. Im
Falle der Beteiligung mehrerer Tabellen wird neben der Selektion auch eine paarweise
Verbundoperation angewendet. Das Ergebnis dieser Operation wird ebenfalls in eine
temporäre Tabelle umgeleitet, welche im folgenden Schritt mit der nächsten Tabelle
vereinigt wird. Das Ergebnis ist wiederum eine temporäre Tabelle. Dieses Prozedere
wird solange fortgeführt bis alle an der Auswertung beteiligten Tabellen abgearbeitet
worden sind.
Projektion und Datenspeicherung
Der Begriff der Projektion bezeichnet die Datenoperation zur Auswahl von Spalten aus
57
4.3. DESIGN
einer Tabelle. [KREM01, S. 112]
Das Projektionsmodul hat zwei grundlegende Aufgaben. Im ersten Schritt wandelt sie
die Indizes der Temporärtabelle in Nutzdaten um. Im Anschluss werden diese Daten
in der Ergebnisstruktur gespeichert.
Die Speicherstruktur ist so angelegt, dass die Daten sowohl relational als auch multidimensional abgebildet werden können. Dadurch ist es später möglich, die Daten
variabel anzuzeigen.
Der Schritt der Projektion beginnt mit der Übernahme des Job-Index, aus dem sich alle
erforderlichen Informationen für die weiter Arbeit entnehmen lassen. Über die Beziehung „Job führt zu Profil“ werden die Profildaten ermittelt. Die Namenskonvention
„tmp_RPE_result_“Job-Index beschreibt den eindeutigen Namen der mittels Selektion erstellten Temporärtabelle.
Abbildung 4.11: beispielhafte Projektion und Speicherung aus Datensicht
Abbildung 4.11 zeigt beispielhaft die Umwandlung der temporären Indexdaten in das
gewünschte Ergebnisformat aus Datensicht. Um das Beispiel anschaulicher zu gestalten, enthält die Ausgangstabelle bereits Daten an Stelle von Indizes. Zur Herstellung
der benötigten Struktur sind drei Arbeitsschritte nötig. Im Ersten wird für jede Zeile der
Temporärtabelle und jede Profil_Projection eine Job_Line angelegt. Als zweites werden die Indizes der Temporärtabelle Profile_Projection-weise in Nutzdaten übersetzt,
für jedes Datum ein Job_Data angelegt und die Verbindung zur Job_Line mittels eines
Job_LineData-Eintrags hergestellt. Im letzten Schritt werden die Zeilenzugehörigkei58
4.3. DESIGN
ten der Daten in die Tabelle Job_LineData eingetragen. Um diese Beziehung herstellen
zu können, wird der Primärschlüssel der Temporärtabelle verwendet.
Der in Abbildung 4.12 dargestellte Programmablaufplan verdeutlicht den Weg von
der Temporärtabelle zu den Ergebnisdaten. Gleich zu Beginn wird deutlich, dass eine
erfolgreiche Abarbeitung des Programms nur möglich ist, sofern ein Job und die zugehörige Temporärtabelle existieren. Ist dies der Fall und die Selektion führte trotzdem
zur leeren Ergebnismenge, wird das Programm ohne Ergebnis beendet.
Abbildung 4.12: Programmablaufplan von Projektion und Datenspeicherung
Sofern die temporäre Ergebnistabelle Werte enthält, wird für jede Zeile eine Job_Line
angelegt. Diese werden später genutzt, um die Zusammengehörigkeit der einzelnen Datenfelder abzubilden. Danach werden die Linedaten aus den Tabellen Profil_Projection und Line ausgelesen. Anschließend wird für jede beteiligte Line zunächst eine Job_Line angelegt, die Daten der Temporärtabelle mittels vordefinierter
SQL-Abfrage in Nutzdaten gewandelt und als Job_Data gespeichert. Nach dem Speichern wird für jedes Job_Data ein Job_LineData angelegt, welches zum Einen auf die
59
4.3. DESIGN
aktuelle Job_Jine und zum Anderen auf die neu eingetragenen Job_Datas verweist.
Sind alle Profil_Projections abgearbeitet, wird die bereits angesprochene Zeilenzugehörigkeit hinzugefügt. Hierfür wird sowohl bei den Job_Lines, die die Zeilen der Temporärtabelle repräsentieren, als auch bei den Job_Datas der Primärschlüssel der Temporärtabelle hinterlegt. Die innere Verknüpfung der Tabelle Job_Line und Job_Data
über diesen Schlüssel liefert die noch fehlenden Job_LineData.
Im letzten Schritt werden die temporären Daten und Zeilenzuordnungen gelöscht und
Verwaltungsinformationen wie die Anzahl der Resultate und der Zeitpunkt der Beendigung der Auswertung in die Tabelle Job eingetragen.
Es zeigt sich, dass die Hauptaufgabe in der Herstellung der richtigen Zuordnung der
Datenfelder zueinander liegt. Da der SQL-Quelltext zur Umwandlung des Indexes in
ein Datum bereits fertig in der Definition der zugehörigen Line gespeichert ist, beschränkt sich der Umwandlungsaufwand auf einfache Textoperationen und das Ausführen der SQL-Abfrage.
60
Kapitel 5
Umsetzung
Zwar nahm die Implementierung des ausgearbeiteten Konzeptes viel Zeit in Anspruch,
jedoch würde die Beschreibung der durchgeführten Tätigkeiten nur wenig zur Erweiterung des Kenntnisstandes beitragen. Aus diesem Grund wird die eigentliche Umsetzung lediglich in groben Zügen skizziert. Stattdessen soll das Kapitel weitestgehend
für die Beschreibung der Anpassungen des in den Phasen Konzeption und Design erarbeiteten Modells an die reale Einsatzumgebung genutzt werden.
Das Hauptaugenmerk des Kapitels liegt auf der Implementierung des in Abschnitt
4.3.3 entwickelten Datenmodells, da hier mehrere Veränderungen des Modells nötig
waren. Im Anschluss wird kurz die Umsetzung des Projektions-Moduls erläutert, obwohl dafür kaum Änderungen des Konzeptes nötig waren.
5.1
Aufbau der Tabellenstruktur
Im Folgenden wird zunächst auf nötige Modellanpassungen eingegangen. Diese Anpassungen waren nötig, da das Modell einerseits an bestimmte Konventionen angepasst
werden musste und andererseits spezielle Eigenschaften der Laufzeitumgebung zu beachten waren. Anschließend wird das fertige Datenmodell präsentiert.
5.1.1
Konventionen
Bei der Entwicklung von größeren Systemen ist die Nutzung von Namenskonventionen
ein weit verbreitetes Hilfsmittel, um bereits am Namen eines Objektes seine Funktion oder Zugehörigkeit erkennen zu können. Beim MHR werden Namenskonventio-
61
5.1. AUFBAU DER TABELLENSTRUKTUR
nen insbesondere mit Hilfe von Prä- und Suffixen realisiert. Diese werden für Datei-,
Tabellen- und Spaltennamen verwendet.
Zusammengehörige Objekte besitzen das gleichen Präfix. So beginnen z. B. alle Tabellennamen, die zur RPE gehören, mit der Vorsilbe “RPE_“. Tabellen, die lediglich
der Abbildung von m-zu-n-Beziehungen dienen, werden zusätzlich mit dem Buchstaben “x“ vor dem Präfix gekennzeichnet. Spalten einer Tabelle tragen zusätzlich zum
Modul- ein Tabellenpräfix.
Objekte mit gleichen Funktionen besitzen gleiche Suffixe. Der in Abschnitt 4.3.4 angesprochene Primärschlüssel einer Tabelle wird beim MHR beispielsweise immer mit
der Nachsilbe “_idx“ versehen. Auch ein Fremdschlüssel trägt das Suffix _idx, jedoch
steht diesem das Tabellenpräfix der Referenztabelle voran.
Um der Vorgabe der HVB, dass zu jedem Datensatz Zeit, Ort und Person der Anlage
oder Löschung ermittelbar sein muss, nachzukommen, enthält jede Tabelle der KDB
vier Pflichtspalten, die diese Informationen aufnehmen. Tabelle 5.1 zeigt Suffixe und
ihre Bedeutung in der KDB.
_idx
Primärschlüssel einer Tabelle
_made
Datum der Erstellung des Datensatzes
_mody
Datum der letzten Änderung des Datensatzes
_op
Mitarbeiter, der die letzte Änderung vorgenommen hat
_ip
IP-Adresse von der aus die letzte Änderung vorgenommen wurde
_del
Löschkennzeichen
_stat
Statusfeld für die temporäre Nutzung
Tabelle 5.1: Suffixe in der KDB
Die gezeigten Namenskonventionen dienen hauptsächlich der Übersichtlichkeit und
erleichtern das Lesen von Programmcodes erheblich. Als Nebeneffekt kann bei Verbundoperationen in vielen Fällen auf Aliasnamen der Tabellen verzichtet werden.
5.1.2
Besonderheiten der Laufzeitumgebung
Gerade bei Datenmodellen spielen Datentypen und ihre Eigenschaften eine wichtige
Rolle. Diese wiederum sind abhängig von der jeweiligen Laufzeitumgebung, welche
im Falle des Datenmodells der RPE der MSSQL2000 ist.
Im Regelfall besitzt eine Spalte einer Tabelle genau einen Datentyp. Alle Werte der
Spalte müssen diesem Datentypen entsprechen. Die Speicherung von Werten mit ver62
5.2. IMPLEMENTIERUNG DES PROJEKTIONS-MODULS
schiedenen Datentypen ist demnach grundsätzlich nicht möglich, obwohl der MSSQL2000 mit dem Datentyp Sql_Variant diesbezüglich eine Ausnahme bietet.
Der Datentyp Sql_Variant erlaubt die Speicherung verschiedenartiger Daten in einer
Spalte, ohne dabei typspezifische Informationen zu verlieren. Aus diesem Grund schien dieser Datentyp bis zur Implementierung als am besten geeignet, um die unterschiedlichen Daten der Auswertung aufzunehmen. Erst bei der Implementierung wurde deutlich, dass dies ein Trugschluss war, da der Datenbankzugriff über ODBC und
OLE diesen Datentyp nicht unterstützt.
Um die Daten trotzdem in einer Spalte speichern zu können, werden alle Daten explizit
in Text umgewandelt und der Ausgangsdatentyp mittels Datenschlüssel gespeichert.
5.1.3
Das RPE-Datenmodell
Abbildung 5.1 zeigt das implementierte Datenmodell der RPE, in dem die zuvor erläuterten Sachverhalte ihre Anwendung finden.
Zusätzlich zum konzeptionellen Datenmodell wurde eine direkte Beziehung zwischen
den Tabellen RPE_queryBlock und RPE_Profile_Selection geschaffen. Diese Beziehung existierte zwar bereits implizit, jedoch werden zur Realisierung drei Verbundoperationen benötigt. Die zusätzliche redundante Beziehung ermöglicht die Einsparung von zwei Verbundoperationen und spart somit Zeit.
Eine detaillierte Beschreibung der Spalten findet sich in Anhang C. Darüber hinaus
enthält die Begleit-CD1 den Quelltext für die Erstellung der Datenstruktur.
5.2
Implementierung des Projektions-Moduls
Im Folgenden wird die Umsetzung des Projektions-Moduls erläutert.
Das resultierende Programm2 unterscheidet sich lediglich in zwei Punkten von dem
in Abschnitt 4.3.4 entwickelten Ablaufplan. Einerseits wurden im Ablaufplan aus
Gründen der Abstraktion sowohl auf die Darstellung der nötigen Schritte für die IPCVerwaltung als auch für die Datenbankkommunation verzichtet. Da es sich bei beiden
um starre Strukturen handelt, waren sie für den Ablauf an sich uninteressant.
Der zweite Punkt, der im konzeptionellen Ablauf vernachlässigt wurde, war die Par1
2
Siehe Anhang D.
Der Quellcode befindet sich auf der Begleit-CD siehe Anhang D.
63
5.2. IMPLEMENTIERUNG DES PROJEKTIONS-MODULS
Reporting-Engine
------------------------------------------------------------- administrative Daten
--------------------------------------------------------------
RPE_ParaValue
RPE_Connection
RPE_showBlock
rpe_pv_idx
rpe_pv_made
rpe_pv_mody
rpe_pv_ip
rpe_pv_op
rpe_pv_del
rpe_pv_stat
rpe_pv_fp_idx
rpe_pv_pos
rpe_pv_name
rpe_pv_value
rpe_pv_type
rpe_ct_idx
rpe_ct_made
rpe_ct_mody
rpe_ct_ip
rpe_ct_op
rpe_ct_del
rpe_ct_stat
rpe_ct_Name
rpe_ct_des
rpe_ct_left_qb_idx
rpe_ct_right_qb_idx
rpe_ct_JoinType
rpe_ct_Condition
rpe_sb_idx
rpe_sb_made
rpe_sb_mody
rpe_sb_ip
rpe_sb_op
rpe_sb_del
rpe_sb_stat
rpe_sb_name
rpe_sb_des
RPE_Line
RPE_FilterPara
RPE_queryBlock
rpe_li_idx
rpe_li_made
rpe_li_mody
rpe_li_ip
rpe_li_op
rpe_li_del
rpe_li_stat
rpe_li_qb_idx
rpe_li_sb_idx
rpe_li_name
rpe_li_des
rpe_li_query
rpe_fp_idx
rpe_fp_made
rpe_fp_mody
rpe_fp_ip
rpe_fp_op
rpe_fp_del
rpe_fp_stat
rpe_fp_qb_idx
rpe_fp_pos
rpe_fp_name
rpe_fp_default
rpe_qb_idx
rpe_qb_made
rpe_qb_mody
rpe_qb_ip
rpe_qb_op
rpe_qb_del
rpe_qb_stat
rpe_qb_TabName
rpe_qb_pk
rpe_qb_FName
rpe_qb_FFunction
rpe_qb_FSelect
------------------------------------------------------------------- Nutzerdaten
RPE_Profile_Projection
-------------------------------------------------------------------
RPE_Profile_Selection
RPE_Profile
rpe_ps_idx
rpe_ps_made
rpe_ps_mody
rpe_ps_ip
rpe_ps_op
rpe_ps_del
rpe_ps_stat
rpe_ps_pf_idx
rpe_ps_qb_idx
rpe_ps_pars_idx
rpe_pf_idx
rpe_pf_made
rpe_pf_mody
rpe_pf_ip
rpe_pf_op
rpe_pf_del
rpe_pf_stat
rpe_pf_ma_idx
rpe_pf_name
rpe_pf_archiv
rpe_pp_idx
rpe_pp_made
rpe_pp_mody
rpe_pp_ip
rpe_pp_op
rpe_pp_del
rpe_pp_stat
rpe_pp_li_idx
rpe_pp_pf_idx
rpe_pp_dim
rpe_pp_namesource
rpe_pp_optName
rpe_pp_sort
----------------------------------------------------------------- Ergebnisdaten -------------------------------------------------------------------
RPE_Job_Data
rpe_jd_idx
rpe_jd_made
rpe_jd_mody
rpe_jd_ip
rpe_jd_op
rpe_jd_del
rpe_jd_stat
rpe_jd_data
rpe_jd_type
rpe_jd_sort
rpe_jd_help_pk
xRPE_Job_LineData
RPE_Job_Lines
xrpe_jld_idx
xrpe_jld_made
xrpe_jld_mody
xrpe_jld_ip
xrpe_jld_op
xrpe_jld_del
xrpe_jld_stat
xrpe_jld_jl_idx
xrpe_jld_jd_idx
xrpe_jld_dim
RPE_Job
rpe_jl_idx
rpe_jl_made
rpe_jl_mody
rpe_jl_ip
rpe_jl_op
rpe_jl_del
rpe_jl_stat
rpe_jl_jb_idx
rpe_jl_pp_idx
Abbildung 5.1: ER-Modell der Reportingengine
64
rpe_jb_idx
rpe_jb_made
rpe_jb_mody
rpe_jb_ip
rpe_jb_op
rpe_jb_del
rpe_jb_stat
rpe_jb_pf_idx
rpe_jb_done
rpe_jb_results
rpe_jb_rc
rpe_jb_archiv
5.2. IMPLEMENTIERUNG DES PROJEKTIONS-MODULS
allelität. Durch den Einsatz des IPC-Moduls ist es möglich, das gleiche Programm
mehrfach auszuführen. Im Falle der RPE wäre es wünschenswert, wenn mehrere Auswertungen gleichzeitig berechnet werden könnten. Um dies zu gewährleisten muss
jedoch sichergestellt werden, dass jeder Prozess lediglich die ihm zugehörigen Daten
manipuliert.
Als Konsequenz wurde der Ablauf dahingehend verändert, dass auch die “Job_LineJob_Data“-Verknüpfung, die über den Primärschlüssel der Temporärtabelle erzeugt
wird, während der Behandlung der einzelnen Profil_Projection erfolgt. Als Bearbeitungsstatus wird jeweils der “rpe_jb_idx“ verwendet. Damit wird gewährleistet, das
jeweils nur die Daten einer Auswertung bearbeitet werden.
65
Kapitel 6
Schlussfolgerungen und Fazit
Wie sich im Laufe der Ausarbeitung gezeigt hat, war die Entwicklung der ReportingEngine aus zweierlei Gesichtspunkten unausweichlich. Erstens sollte ein System entstehen, das Daten jeglicher Art nutzergesteuert abfragen und darstellen kann und auf
dessen Grundlage Datenanalysen möglich sind. Ferner musste ein Ersatz für die durch
die Hardwareumstellung verloren gegangene Möglichkeit der Erstellung von manuellen Auswertungen gefunden werden.
Der Gang der Untersuchung hat deutlich gemacht, welche komplexen Vorgänge und
vielfältige Fehlerquellen im Zusammenhang mit der Datenextraktion stehen. Als
Hauptprobleme haben sich dabei die Eigenheiten der relationalen Datenspeicherung
sowie die unterschiedlich Verwendung und Interpretation von Begrifflichkeiten heraus
kristallisiert.
Diese Probleme ließen sich großteils durch den Einsatz von Metadaten lösen. Dadurch
ist entwickelte die Reporting-Engine einerseits in der Lage, die Zusammenhänge zwischen Daten transparenter darzustellen und ermöglicht es dem Nutzer darüber hinaus,
ohne SQL- und Datenbankkenntnisse Daten aus einer relationalen Datenbank zu extrahieren.
Allerdings wurde gleichzeitig deutlich, dass es angebracht wäre, einen unmissverständlichen Begriffskatalog zu entwickeln, um in Zukunft eine effektivere Kommunikation zwischen Anwendern und Administratoren zu ermöglichen und damit einhergehend das Verständnis beider Seiten für einander zu verbessern.
Das angestrebte Projekt konnte im Rahmen dieser Ausarbeitung nur teilweise fertig
gestellt werden. Neben dem Abschluss der Arbeiten am UI und der OE ist die Implementierung des Selektionsmoduls von ausschlaggebender Bedeutung für den Projekterfolg. In weiteren Schritten werden Analysemodule und erweiterte Möglichkeiten
66
zur Ausgabeformatierung zu ergänzen sein, um denen in Abschnitt 4.1.1 definierten
Anforderungen endgültig gerecht werden zu können.
Mit der Erarbeitung des konzeptionellen Modells und der Implementierung der Datenstruktur der Reporting-Engine wurde der Grundstein für den Projekterfolg gelegt.
Mit Hilfe des Projektionsmoduls wird es bereits vor Fertigstellung des UI einen Ersatz
für die manuellen Auswertungen geben. Damit ist das Ziel der Ausarbeitung, durch
die Schaffung eines nutzergesteuerten Abfragesystems den Grundstein für umfassende
Datenanalysen zu legen, durchaus als erreicht zu betrachten.
67
Teil IV
Anhang
VI
Ehrenwörtliche Erklärung
Ich erkläre hiermit ehrenwörtlich, dass ich die vorliegende Arbeit selbständig angefertigt habe, die aus fremden Quellen direkt oder indirekt übernommenen Gedanken sind
als solche kenntlich gemacht. Es wurden keine anderen als die angegebenen Quellen und Hinweise verwandt. Die vorliegende Arbeit wurde bisher noch keiner anderen
Prüfungsbehörde vorgelegt und auch noch nicht veröffentlicht.
Wismar, 28. Mai 2006
.........................................
VII
Abkürzungsverzeichnis
ASP
Active Server Pages
DBMS
Datenbank-Management-System
DBS
Datenbanksystem
DSS
Decision Support Systems
DWH
Data Warehouse
EDP
Elementary Data Processing
EIS
Executive Information System
ER
Entity-Relationship
ERD
Entity-Relationship-Diagramm
ERM
Entity-Relationship-Modell
ESS
Executive Support Systems
EUS
Entscheidungssünterstützende Systeme
FASMI
Fast Analysis of Shared Multidimensional Information
HTML
HyperText Markup Language
HTTP
HyperText Transfer Protocol
HVB
HypoVereinsbank
IIS
Internet Information Services
IPC
Inter Process Communication
IS
Informationssystem
KDB
Kundendatenbank
Man.Inf.Sys
Management Information Systems
MDBS
multidimensionales Datenbank-System
MHR
MedienHaus Rostock GmbH
MIS
Managementinformationssystem
MS
Microsoft
MSSQL2000
Microsoft SQL Server 2000
OLAP
Online Analytical Processing
OLTP
Online Transaction Processing
PDF
Portable Document Format
PHP
Hypertext Preprocessor
VIII
ABKÜRZUNGSVERZEICHNIS
RDBMS
relationales Datenbank-Management-System
RDBS
relationales Datenbank-System
SQL
Structured Query Language
VB-Script
Visual Basic Script
VuW
Vereins- und Westbank
IX
Literaturverzeichnis
[CLAU98] Clausen, N.: OLAP
Multidimensionale Datenbanken
Bonn: Addison Wesley Longman, 1998
[FROS03] Frosch-Wilke, D.: Data Warehouse, OLAP und Data Mining
Datenschutz und Datensicherheit Nr.27 2003 - S.597ff
[HOLT99] Holten ,R.: Entwicklung von Führungsinformationssystemen
Ein methodenorientierter Ansatz
Wiesbaden: Deutscher Universitäts-Verlag, 1999
[KREM01] Kremer, H. W.: Select * From SQL Server 2000
Bonn: Galileo Press, 2001
[LEHN99] Lehner, W.: Multidimensionale Datenbanksysteme
Stuttgart, Leipzig: B.G.Teuber, 1999
[LEHN03] Lehner, W.: Datenbanktechnologie für Data-Warehouse-Systeme
Konzepte und Methoden
Heidelberg: dpunkt-Verlag, 2003
[MEIE04] Meier, A.: Relationale Datenbanken
Leitfaden für die Praxis
Berlin, Heidelberg: Springer, 2004
[OEHL00] Oehler, K.: OLAP
Grundlagen, Modellierung und betriebswirtschaftliche Lösungen
München: Carl Hanser Verlag, 2000
[SCHI99]
Schinzer, H.; Bange, C.;Mertens, H.: Data Warehouse und Data Mining
Marktführende Produkte im Vergleich
München: Vahlen Verlag, 1999
X
LITERATURVERZEICHNIS
[SCHU01] Schuler, A. H.; Pfeifer, A.: Effizientes eReporting
Zukunft des Corporate Reporting
München: Addison Wesley Verlag, 2001
[SCHW95] Schwarze, J.: Systementwicklung
Planung, Entwicklung und Einfuehrung von Informationssystemen
Herne: Verl. Neue Wirtschafts-Briefe, 1995
[STEI05]
Steinweg, C.: Management der Software-Entwickling
Projektkompass für die Erstellung von leistungsfähigen IT-Systemen
Wiesbaden: Vieweg Verlag, 2005
[MHHRO] Homepage: MedienHaus Rostock
http://www.mhr.de/home.htm
[OLAP]
Website: The OLAP Report
http://www.olapreport.com
[WEREP] Wikipedia Enzyklopädie: Berichtswesen
http://de.wikipedia.org/wiki/Berichtswesen
XI
Stichwortverzeichnis
Data Mart, 23
Data Warehouse, 19
Architektur, 22
virtuell, 23
Datenbank, 6
Datenbanksystem, 6
Decision Support Systems, 17
Endscheidungsunterstützende Systeme, siehe
Decision Support System
Executive Information Systems, 18
Führungsinformationssysteme, siehe
Executive Information Systems
Informationsbedarfsanalyse, 14
Informationssystem, 13
Kundendatenbank, 30
Management Information Systeme, 16
Management Reporting Systems, 17
Metddaten, 24
Normalisierung, 8
Nutzdaten, 48
Online Analytical Processing, 24
Relationenmodell, 7
Roteiro, 30
XII
Anhang A
SQL_Analyser.pl
#!perl
# Author: Martin Behrndt
# Skript zum:
#
-Entfernen
#
+ Kommentare
#
+ überflüssigen Whitespaces
#
-Zählen
#
+ der Zeichen
#
+ der Zeilen
#
+ der Tabellen
#
+ der Spalten
#
+ von Befehlen
#
* SELECT
#
* INSERT
#
* UPDATE
#
* ORDER BY
#
* GROUP BY
#
...in einer manuellen Auswertung(SQL-Datei)
#
# Vorausetzung ist das Markieren von Tabellen,Spalten, mit { bzw. [
###############################################################################
use strict;
use warnings;
## Dateinamen holen ##
my @file = ();
if (scalar(@ARGV) != 0){
@file = split(/\./,join(’’,@ARGV));
}else{
print "\nDateiname:\t"; chomp(@file = split(/\./,<STDIN>));
XIII
ANHANG A. SQL_ANALYSER.PL
}
## Dateinamen in Namen und Endung zerlegen ##
my ($filename,$suffix) = @file;
## Datei öffnen ##
open(INFILE, "<".$filename.".".$suffix)
or die "ERROR: Cannot read $filename.$suffix!\n";
seek(INFILE, 0, 0);
# an den Dateianfang springen #
my @infile = <INFILE>; # Datei einlesen #
close INFILE;
# Datei schließen #
## Textbereinigung und Zählen ##
my $bk_tag = 0;
my (@output, @columns, @tables, @orders, @groups);
## count(Zeilen, Zeichen, SELECTs, INSERTs, UPDATEs, ORDER BYs, GROUP BYs) ##
my @count = (0,0,0,0,0,0,0);
foreach my $line (@infile){
## entfernen ##
$line =~ s/\/\*.*\*\///g; # einzeiliger Blockommentar
if($line =~ /\/\*/){
$line =~ s/\/\*.*//g; # Anfang Blockommentar
$bk_tag = 1;
}elsif($line =~ /\*\//){
$line =~ s/.*\*\///g; # Ende Blockommentar
$bk_tag = 0;
}elsif($bk_tag == 1){
$line =~ s/.*//g;
# Innerer Blockommentar
}
$line =~ s/--.*\n?//g;
# ZeilenKommentare
$line =~ s/\s+/\ /g;
# Mehrfachleerzeichen
$line =~ s/^\s*\n//g;
# Leerzeilen mit Leerzeichen
$line =~ s/\n//g;
# Leerzeilen ohne Leerzeichen
## Zeilen für Output auswählen
if($line ne ’’ && $line ne ’ ’){
while($line =~ /\bSELECT\b/gi){$count[2]++;}
while($line =~ /\bINSERT\b/gi){$count[3]++;}
while($line =~ /\bUPDATE\b/gi){$count[4]++;}
while($line =~ /\bORDER\b\s+\bBY\b/gi){$count[5]++;}
while($line =~ /\bGROUP\b\s+\bBY\b/gi){$count[6]++;}
while($line =~ /\[(.*?)\[/g){push(@tables,$1);}
while($line =~ /\{(.*?)\{/g){push(@columns,$1);}
while($line =~ /\^(.*?)\^/g){push(@orders,$1);}
while($line =~ /\§(.*?)\§/g){push(@groups,$1);}
$line =~ s/\[|\{|\^|§//g; # Markierungen entfernen
$count[0] += length($line);
XIV
ANHANG A. SQL_ANALYSER.PL
push(@output,$line);
}
}
## Bereinigten Auswertungstext in Ausgabedatei schreiben ##
my $Outfile = $filename."_AsW.txt";
# Namen für Ausgabedatei erstellen #
&write_ascii(join("\n",@output),$Outfile); # eigentliches Schreiben
## Anzahlen bestimmen und ausgeben ##
$count[1] = scalar(@output);
my %tables = &make_hash(@tables);
my %columns = &make_hash(@columns);
my %orders = &make_hash(@orders);
my %groups = &make_hash(@groups);
my $output = "";
$output .= "\nDie Datei ’$Outfile’ enthaelt :\n";
$output .= "#Tabellen\t#Spalten\t#SELECTs\t#INSERTs";
$output .= "\t#UPDATEs\t#ORDER\t#GROUP\t#Zeile\t#Zeichen\n";
$output .= "".scalar(keys %tables)."\t".scalar(keys %columns)."\t$count[2]";
$output .= "\t$count[3]\t$count[4]\t$count[5]\t"
$output .= "$count[6]\t$count[1]\t$count[0]\n";
$output .= "\nTabelle :\n";
$output .= &print_hash(\%tables);
$output .= "\nSpalten :\n";
$output .= &print_hash(\%columns);
if($count[5] > 0 || scalar(keys %orders) > 0){
$output .= "\nSortierungen :\n";
$output .= &print_hash(\%orders);
}
if($count[6] > 0 || scalar(keys %groups) > 0){
$output .= "\nGruppierungen :\n";
$output .= &print_hash(\%groups);
}
&write_ascii($output,$filename."_Result.txt");
print $output;
## Fenster offen halten ##
system(’Pause’);
#####################################################################
############################# SUBS ##################################
#####################################################################
sub print_hash{
my $text = "";
my %hash = %{$_[0]};
foreach my $key (sort keys %hash){
XV
ANHANG A. SQL_ANALYSER.PL
$text .= "$key\t$hash{$key}\n";
}
return $text;
}
sub make_hash{
my %hash = ();
foreach my $item (@_){
if($item ne ’’ && $item ne ’ ’){
if(defined $hash{$item}){
$hash{$item}++;
}else{
$hash{$item} = 1,
}
}
}
return %hash;
}
sub write_ascii{
my $content = shift(@_);
my $file = shift(@_);
open(OUTFILE, ">".$file) or die "ERROR: Fehler beim oeffnen von $file!\n$!\n";
print OUTFILE $content;
close(OUTFILE) or die "ERROR: Fehler beim schliessen von $file!\n$!\n";
}
Die Nutzung diese Quellcodes erfolgt auf eigene Gefahr. Es wird keine Haftung für möglicherc
weise auftretenden Schäden oder Datenverluste übernommen. 2006
by Martin Behrndt.
XVI
Anhang B
Datenblätter Berichtswerkzeuge
B.1
Business Objects Crystal Reports
B.2
Cognos ReportNet
B.3
Microsoft Reporting Services
XVII
ANHANG B. DATENBLÄTTER BERICHTSWERKZEUGE
Crystal Reports XI
Die bewährte, weltweite Standardlösung für Reporting
Crystal Reports® XI, der bewährte De-facto-Standard für Reporting, hilft Ihnen bei der Erstellung, Organisation und Verteilung von Berichten über das Web oder integriert in Unternehmensanwendungen. Ein zuverlässiges Berichtswesen ist die unabdingbare Basis jeder
Business Intelligence (BI)-Strategie. In Form von aussagekräftigen Berichten sorgt Crystal
Reports für die sichere Verbreitung erfolgskritischer Informationen an Anwender innerhalb
und außerhalb Ihres Unternehmens.
Als leistungsfähiger Reporting-Standard unterstützt Crystal Reports jede Stufe des Berichtsprozesses:
den Zugriff auf alle relevanten Daten und die Präsentation in jedem gewünschten Format
die zeitnahe Versorgung aller Anwender mit den richtigen Berichten
die Integration der Reporting-Funktionalitäten in Anwendungen und Portale
XVIII
ANHANG B. DATENBLÄTTER BERICHTSWERKZEUGE
Crystal Reports XI
Der bewährte, weltweite Reporting-Standard
Gute Gründe für ein Upgrade auf Crystal Reports XI
ken in Berichten. Dadurch können Sie
Bilder außerhalb Ihrer Datenbank ablegen und wertvollen Speicherplatz sparen.
Crystal Reports Server
Crystal Reports Server XI ist das neueste
Mitglied der Crystal Reports-Produktfamilie. Die umfassende ReportingLösung hilft kleineren und mittelständischen Unternehmen, Berichte über
das Web oder integriert in Anwendungen zu erstellen, zu organisieren und zu
verteilen.
Editierbares RTF-Format
Stellen Sie Ihren Anwendern Berichte in
einem neuen RTF-Format zur Verfügung, damit sie selbst Änderungen am
Dokument vornehmen können
Kostenneutrale Laufzeitlizenzen
Die Crystal Reports Developer Edition
beinhaltet eine kostenneutrale Laufzeitlizenz für den unbegrenzten, unternehmensinternen Einsatz der Crystal
Reports .NET-, Java™- und COM(RDC) Report Engine-Komponenten.
Zusätzliche Lizenzgebühren fallen nicht
an.
„Intelligente“ Grafikerstellung
Erstellen Sie eine Grafik oder lassen Sie
sich den besten Grafikstil automatisch
anzeigen. Diese Funktion aktualisiert Ihr
Diagramm sofort, wenn neue Variablen
hinzugefügt werden.
Dynamische, kaskadierende Prompts
Erfüllen Sie die Anforderungen unterschiedlichster Anwender mit nur einem
Report, indem Sie dynamische Werte für
die Eingabeaufforderungen in Berichten
festlegen. Eine Pflege der Listen mit
statischen Prompt-Werten für die einzelnen Berichte entfällt, denn Sie können die bereits vorhandenen und im
Repository abgelegten Prompts wieder
verwenden.
HTML-Vorschau
Sorgen Sie für perfekte Berichte. Prüfen
Sie das Design Ihrer Reports mit Hilfe
der HTML-Vorschau vor der Veröffentlichung im Web.
Dynamische Bildpositionierung
Nutzen Sie eine Datenbankverbindung
zur Platzierung von Bildern und Grafi-
Hierarchisches Gruppieren
Verbessern Sie das Layout Ihres Berichts
und stellen Sie Daten in hierarchischer
anstatt in relationaler Form dar. Diese
Funktion eignet sich ideal für Organigramme und aggregierte Berichte.
Workbench
Mit der Workbench organisieren Sie Ihre
Projekte und gruppieren die Berichte
nach Ihren persönlichen Vorgaben.
Dependency Checker
Stellen Sie sicher, dass Ihr Bericht perfekt funktioniert - bevor Sie ihn verteilen. Der Dependency Checker findet
schnell unterbrochene Links, Formelfehler und ähnliche Probleme.
Aktualisierte Datentreiber
Die neuen Treiber für XML, JDBC, IBM
DB2 und Exchange erleichtern Ihnen
den Zugriff auf die benötigten Daten.
XIX
ANHANG B. DATENBLÄTTER BERICHTSWERKZEUGE
Der neue Field Explorer erleichtert
die Navigation innerhalb des
BusinessObjects EnterpriseSystems. Im Crystal Reports
Designer können Sie ReportingKomponenten gemeinsam mit
anderen Anwendern nutzen.
Besuchen Sie die Crystal
Reports-Seite für Einsteiger.
Hier finden Sie alle Informationen für einen schnellen Start
mit Crystal Reports.
Exportieren Sie Berichte in
bekannte Formate wie XML,
PDF, Excel und HTML.
Es war noch nie so einfach, den
idealen Grafiktyp für Ihre Daten zu
finden.
Wählen Sie zwischen nativer,
ODBC-, OLE DB- und JDBCVerbindung zu Datenbanken,
Dateien, Protokollen, Unternehmensanwendungen oder Programmelementen.
Mit dem Dependency Checker
identifizieren Sie automatisch
unterbrochene Links, Formelfehler
und andere Abhängigkeitsprobleme.
Automatisch aktualisierte Auswahllisten und kaskadierende
Prompts sorgen für weniger
Wartungsaufwand.
Datenzugriff und -präsentation
nach Wunsch
Der Zugriff auf und die Kombination von Daten aus
unterschiedlichen Quellen ist oft komplex und erfordert
verschiedene Werkzeuge. Die Umwandlung dieser
Daten in verwertbare Informationen stellt eine weitere
Herausforderung dar. Crystal Reports bietet Ihnen
einen durchgängigen Standard für einfache Datenintegration, flexible Berichtserstellung und zeitsparende
Report-Pflege. So wird die IT-Abteilung entlastet und
die Anwender können fundiert Entscheidungen treffen.
Einfacher Zugriff auf alle Daten
Crystal Reports gibt Ihnen die vollständige Kontrolle
über die Datenanbindung und unterstützt Sie so bei der
problemlosen Erfüllung der sich ständig ändernden Anwenderanforderungen. Leistungsstarke Datentreiber
und flexible Zugriffsmöglichkeiten stellen die Verbindung zu allen benötigten Daten her. Alternativ können
Sie Business Views als Datenabstraktionsschicht einrichten und so den Verbindungsprozess zu verschiedenen Datenquellen vereinfachen und den Aufwand
bei der Migration von Berichten von der Entwicklungsumgebung in den produktiven Betrieb verringern.
Berichte, die ankommen
Die offene Design-Umgebung von Crystal Reports
ermöglicht Ihnen das Erstellen von anspruchsvollen,
aussagekräftigen Berichten. Sie können praktisch jeden
Report erzeugen, von Steuerformularen und Top NVertriebsberichten bis zu Adressaufklebern. Dank der
umfangreichen Layout- und Formatierungsoptionen
wie Grafiken, Landkarten, Gruppierungen und Sortierungen erstellen Sie mühelos professionelle, pixelgenaue Berichte ohne aufwändige Programmierung.
Berichte schnell erstellen und einfach
pflegen
Mit Crystal Reports beschleunigen Sie die Erstellung
und Pflege Ihrer Berichte und haben Zeit, sich auf
wichtigere Aufgaben zu konzentrieren. Anpassbare
Vorlagen weisen Berichten automatisch Formate und
Layouts zu. Custom Functions extrahieren die betriebswirtschaftliche Logik aus Formeln und stellen sie ohne
weiteren Programmieraufwand zur Nutzung in anderen
Berichten zur Verfügung. Außerdem können Sie häufig
gebrauchte Berichtselemente (Textobjekte, Custom
Functions, SQL-Befehle und Bilder) zur Weiterverwendung und zentralen Aktualisierung in einer Bibliothek,
dem Repository, ablegen.
XX
ANHANG B. DATENBLÄTTER BERICHTSWERKZEUGE
Planen Sie die Berichtsverarbeitung zu
bestimmten Zeiten, Terminen und in
vordefinierten Formaten.
Mit dem neuem Crystal Reports
Server verteilen Sie Crystal ReportsBerichte über das Web.
Steuern Sie den Informationszugriff der
Anwender über die detaillierten
Sicherheitseinstellungen auf Objekt-,
Nutzer- und Datenebene.
Der richtige Bericht zur richtigen
Zeit an den richtigen Empfänger
Interaktive und individuelle Auswertungsumgebung
Die zeitgerechte Berichtsverteilung an Anwender innerhalb und außerhalb des Unternehmens kann teuer,
zeitaufwändig und auch riskant sein, denn Ihre vertraulichen Berichte könnten in falsche Hände geraten. Mit
Crystal Reports verfügen Sie über eine sichere, steuerbare Umgebung zur flexiblen Berichtsauswertung und
-bearbeitung, die Ihnen hilft, die Kosten für die Informationsverteilung zu reduzieren.
Mit Crystal Reports machen Sie die Anwender unabhängig von IT-Unterstützung und sorgen für einen
besseren Entscheidungsprozess. Ihre Anwender können
die Daten in gewohnten Formaten und Umgebungen
betrachten und auswerten. Dazu können Sie einen der
vordefinierten Thin- oder Zero-Client-Viewer von
Crystal Reports einsetzen. Selbstverständlich können
Sie diese Viewer auch Ihren Anforderungen anpassen
und Ihren Anwendern maßgeschneiderte Möglichkeiten zum Ausdrucken, Aktualisieren und Durchsuchen
der Berichten bieten. Auch für Funktionalitäten wie der
Drill-down auf Grafiken und zwischen Gruppen von
Berichtsdaten ist keine zusätzliche Programmierung
nötig.
Berichtsveröffentlichung im Web - für
sichere Auswertungen mit SchedulingFunktionalität
Crystal Reports Server bietet Ihnen eine skalierbare
Web-Reportinglösung, mit der sich Berichte einfach
und effizient an Anwender verteilen lassen. Sie sind in
der Lage, jeden bestehenden Crystal Reports-Bericht im
Web zu veröffentlichen und dabei gleichzeitig die Berichtsausführung zu planen sowie die Sicherheitseinstellungen festzulegen. Ihre Anwender können dann die
Berichte sofort in der sicheren Umgebung eines anpassbaren Portals aufrufen und auswerten - alles was sie
dazu benötigen ist eine einzige URL. Zusätzlich stehen
Ihnen vordefinierte Integrationspakete zur Verfügung,
die die Anpassung an Ihre vorhandene Portaloberfläche
beschleunigen.
XXI
ANHANG B. DATENBLÄTTER BERICHTSWERKZEUGE
In den führenden IDEs ist die Crystal
Reports-Technologie bereits enthalten.
Integrieren Sie pixel-genaue Berichte in Ihre
Java-, .NET- oder COM-Anwendungen zum
Einsatz im Web oder unter Windows.
Umfassende SDKs sorgen für maximale Flexibilität bei der Anwendungsentwicklung.
Integrieren Sie ReportingFunktionalitäten in Anwendungen
und Portale
Implementierungsoptionen
Eine wichtige Voraussetzung für jede Reporting-Lösung
ist die einfache Integration in bestehende Systeme,
Applikationen und Infrastrukturen. Crystal Reports lässt
sich in praktisch jede Umgebung integrieren und bietet
Ihnen einen durchgängigen Reporting-Standard für die
unterschiedlichsten Implementierungsanforderungen,
mit dem Sie die langfristige Attraktivität Ihrer Anwendungen sicherstellen können.
Erstellen Sie interaktive Berichte in Ihren
Anwendungen
Crystal Reports hält für Anwendungsentwickler
umfangreiche Software Development Kits (SDKs)
bereit, mit denen sich das Sichten, Drucken und
Exportieren von Berichten einfach in Java-, .NET- und
COM-Anwendungen integrieren lässt. Crystal Reports
Server verfügt über zusätzliche interaktive APIs für die
Berichtsänderung und -erstellung durch die Anwender
zur Ausführungszeit. Vordefinierte Integrationspakete
beschleunigen den Einsatz von Portalen.
Integrieren Sie individuelle Java-, .NET- und COMBerichtskomponenten direkt in Ihre Anwendungen und
genießen Sie unternehmensweit die Vorteile einer
internen, unbegrenzten Nutzungslizenz ohne CPUBegrenzung. Alternativ können Sie die Berichtsverarbeitung auch auf den Crystal Reports Server übertragen.
Auf diese Weise zentralisieren Sie das Reporting unterschiedlicher Anwendungen und bieten Ihren Anwendern mehr interaktive Berichtsfunktionalitäten. Für was
Sie sich auch entscheiden, Crystal Reports nutzt ein
konsistentes Objektmodell, das sicherstellt, dass die
Migration von einer Lösung zur anderen nahtlos und
direkt erfolgt.
Integration in alle marktgängigen Web
Application Server und Plattformen
Mit Crystal Reports schreiben Sie Ihre Anwendung in
Java, .NET oder COM und setzen sie unter Windows,
LINUX und UNIX ein. Mit Crystal Reports Server entwickeln Sie außerdem unterschiedliche Applikationen,
die mit einem zentralen Report Repository verbunden
sind. Die Pflege von separaten Repositories für individuelle Anwendungen wird damit überflüssig.
XXII
ANHANG B. DATENBLÄTTER BERICHTSWERKZEUGE
Crystal Reports XI
Der weltweit bewährte Standard für Reporting
Die passende Crystal Reports-Edition für Ihre Anforderungen
Ob IT-Profi, Anwendungsentwickler oder Fachanwender, für jede Anforderung gibt es die
passende Crystal Reports-Version:
Crystal Reports Server: vollständige Reporting-Lösung für kleinere und mittelständische Unternehmen zur Erstellung, Organisation und Verteilung von Berichten über das Web (oder integriert in Anwendungen).
Crystal Reports Developer Edition: für die Entwicklung und Integration von Berichten in
Web- und serverbasierten Anwendungen.
Crystal Reports Professional Edition: zum Erstellen von Berichten auf Basis einer Vielzahl
von PC- und Unternehmensdatenquellen.
Die folgende Tabelle vergleicht die wichtigsten Funktionen von Crystal Reports XI nach Edition:
Crystal Reports Server
Crystal Reports Developer
Crystal Reports Professional
Crystal Reports XI - Funktionsvergleich nach Edition
Native, ODBC-, OLE DB- und JDBC-Verbindung zu relationalen, OLAP-, XML-,
Altsystem- und Unternehmensdatenquellen
✔
✔
✔
✔
✔
✔
✔
✔
✔
✔
✔
✔
✔
✔
✔
Zugriff auf eigene, benutzerdefinierte Daten über JavaBeans, ADO, .NET und COM
Grafischer Report Designer für schnellen Datenzugriff und aussagekräftige Formatierung
Berichtsintegration
SDKs zum Sichten, Drucken und Exportieren von Berichten in Anwendungen
Die Berichtsverarbeitung findet in einer selbst entwickelten Anwendung statt
Die Berichtsverarbeitung wird auf einen separaten Berichtsserver ausgelagert
✔1
✔
APIs für das Erstellen und Anpassen von Berichten durch den Anwender
Anpassbare Report Viewer
Verteilung und Steuerung2
Schnelle Berichtsveröffentlichung im Web für Workgroups und Abteilungen
Planung (Scheduling) der Berichtsausführung zu bestimmten Zeiten, Terminen
Sicherheit auf Benutzer-, Gruppen-, Objekt- und Ordner-Ebene
Leistungsfähige semantische Schicht (Business Views) zur Datenbankbetrachtung durch
den Anwender
✔
Bibliothek (Repository) zur berichtsübergreifenden Wiederverwendung von Objekten
✔
1. Für Nutzer der Report Designer-Komponente (RDC): diese APIs sind in der Developer Edition verfügbar.
2. Die Professional and Developer Editions enthalten als Einführungsangebot fünf Nutzungslizenzen (5 Named Users) von Crystal Reports Server.
✔
✔
✔
www.businessobjects.com
www.businessobjects.de
www.businessobjects.ch
Europa
Tel: +33 1 41 25 21 21
Deutschland
Tel: +49 (0)700 26 25 32 87
Schweiz
Tel: +41 (0)56 483 40 50
Business Objects hält folgende US-Patente, die Produkte betreffen können, die Business Objects anbietet und verkauft: 5,555,403; 6,247,008 B1; 6,578,027 B2;
490,593 und 6,289,352. Business Objects, das Business Objects-Logo, BusinessObjects, Crystal Reports, Crystal Enterprise, Crystal Analysis, WebIntelligence,
RapidMarts und BusinessQuery sind Warenzeichen oder eingetragene Warenzeichen von Business Objects SA in den USA und/oder anderen Ländern. Alle
anderen hier erwähnten Namen können Warenzeichen der jeweiligen Besitzer sein. Copyright © 2004 Business Objects. Alle Rechte vorbehalten.
PT#DS731-A
XXIII
Printed in Germany - März 2005 (Autor: C. Factor; unter mitwirkung von: D. Dicochea, S. Jaganathan, M. Meckler, J. Meegan, Pam Seale)
Datenzugriff und Berichtsdesign
ANHANG B. DATENBLÄTTER BERICHTSWERKZEUGE
Business intelligence software for reporting and OLAP analysis of Cor...
http://www.cognos.com/products/business_intelligence/reporting/featur...
Manage My Profile | Contact Us | Careers | Investor Relations
Worldwide Sites
Evaluate
Overview
Features and Benefits
MS Office Integration
White Papers
Fact Sheet
Online Demo
System Requirements
Validate
Certified for SAP® BW
Red Hat Ready
Analyst / Press Views
Customer Successes
Choose
Cognos Leadership
Support & Services
Contact Us Now
Extend
With Cognos
PowerPlay®
Corporate
Performance
Management
BI Standardization
Scorecarding &
Dashboard Software
Search:
Cognos Home > Products > Cognos ReportNet > Features and Benefits
Cognos ReportNet
Focus on Performance
Features and Benefits
Online Demo
See the new standard for
enterprise reporting in action.
Advanced authoring capabilities
One authoring environment for creating all report types, including
dashboards.
Federated queries—one query drawing on multivendor data
sources—even within a single reporting object.
Adaptive authoring automatically adjusts report layout when
objects are added, moved or removed.
Embed live applications, Web sites and non-BI content within a
report.
Drag-and-drop authoring incorporates data, text, charts, graphs,
and images.
Edit reports with prompts and toolbar commands.
Advanced visualisations and charting abilities through Cognos
Visualizer.
Work with data using familiar business terms.
Use a variety of charts: crosstabs, bar/3D bar, pie/doughnut,
line, gauge, funnel, scatter, dot density, waterfall, and more.
Create complex, multi-page layouts using different data sources
without programming or workarounds.
Conditional suppression and automatic calculations.
Data access
High performance federated data access across all sources.
Complete connectivity regardless of environment - relational
databases, SAP® BW, Excel, XML, JDBC, LDAP and Web Services.
Support for Windows, UNIX, and Linux operating systems,
including mixed platform deployments.
SAP-certified BAPI® and iViews, Certified Powered by SAP
NetWeaver™.
Load balancing across Windows and Unix platforms.
Single portal, metadata layer, and point of administration.
Open architecture
On-demand Web seminar
Learn how First Citizens Bank
uses Cognos ReportNet to
increase customer
profitability.
Key features up close
Cognos TechTalk
Cognos TechTalk
Get answers to your technical
questions with on-demand
Web seminars, white papers,
analyst reports, demos and
more.
Questions?
Cognos worldwide
locations
Have Cognos contact
you
Open architecture leverages XML, SOAP and WSDL.
Fully published SDK.
Foundation for the entire Cognos Enterprise BI suite
Leverages existing security models and supports multiple security
authentication providers.
Powerful distribution
Proven scalability to 190,000 named users. Reporting times of
2.5 seconds.
Out-of-the-box integration with SAP and IBM Websphere portals.
Burst personalized reports to multiple locations and in multiple
formats.
User interface supports 10+ languages; reports delivered in 25+
languages.
Multiple export formats: Excel, PDF, XML, HTML, and CSV.
Multilingual capabilities automatically deliver reports in users'
working language.
Stateless connections use pooled connections to service report
requests.
Import and manipulate BI content in MS Office.
Home | Legal Notices | Privacy Statement | Site Map
Copyright © 2006 Cognos Incorporated
corporate performance management — business intelligence, enterprise planning
and balanced scorecard
1 von 1
30.03.2006 14:53
XXIV
ANHANG B. DATENBLÄTTER BERICHTSWERKZEUGE
Reporting Services
Für viele Unternehmen besteht die
Herausforderung darin, den richtigen
Mitarbeitern nützliche Informationen
zur rechten Zeit zur Verfügung zu
stellen. Solche Mitarbeiter benötigen
den Zugriff auf geschäftliche Daten,
die möglicherweise über die gesamte
Organisation verteilt sind.
SQL Server 2005 Reporting Services erweitert die Microsoft® Business IntelligencePlattform, um solche Anforderungen zu
unterstützen. Reporting Services ist eine
serverbasierte Reporting-Umgebung, die
über Webdienste verwaltet wird. Berichte
können in einer Vielzahl von Formaten,
mit umfangreichen Interaktivitätsmöglichkeiten und vielen Druckoptionen erstellt
werden. Als integrierte Komponente von
SQL Server 2005 stellen die Reporting
Services Folgendes zur Verfügung:
• eine leistungsstarke Engine zur Verarbeitung und Darstellung von Berichten
• einen vollständigen Satz an Tools zum
Erstellen, Verwalten und Anzeigen von
Berichten
• eine erweiterbare Architektur und eine
offene Schnittstelle für die Integration
von Reporting-Lösungen in unterschiedliche IT-Umgebungen
Reporting-Szenarien
Die Reporting Services bieten die Kombination aus einer umfassenden Plattform
mit einer skalierbaren und erweiterbaren
Architektur. Sie decken so eine große
Menge der Anforderungen im Bereich
Reporting ab:
• Enterprise Reporting
Unternehmen können die Reporting
Services für ihre operativen Berichte
oder für Business Intelligence-Anwendungen nutzen. Mit den Reporting
Services können die IT-Mitarbeiter eine
Vielzahl an Berichten erstellen und diese
verschiedenen Personen im Unternehmen
zur Verfügung stellen – zum Beispiel
über E-Mails, über ein Portal oder über
beide Wege.
• Ad-hoc-Reporting
SQL Server 2005 Reporting Services
stellen den Report Builder zur Verfügung. Report Builder ist ein neues Adhoc Reporting-Tool, das Mitarbeitern
das Erstellen eigener Berichte und die
Abfrage von Unternehmensdaten
ermöglicht. Report Builder bietet ein
benutzerfreundliches Abfragemodell,
über das die Benutzer ohne tief
greifendes technisches Verständnis
der darunter liegenden Datenquellen
Berichte erstellen können.
• Embedded Reporting
Independent Software Vendoren (ISVs)
können die Reporting Services nutzen,
um vordefinierte Berichte oder Ad-hoc
Berichte als Teil einer Anwendung zur
Verfügung zu stellen. Die IT-Organisationen des Kunden können auf diese
Berichte zugreifen, sie anpassen oder
neue erstellen, die ihren geschäftlichen
Anforderungen entsprechen.
• Webbasiertes Reporting für
Partner/Kunden
Unternehmen können interaktive,
webbasierte Berichte erstellen und
Kunden oder Partnern Informationen
über Extranets oder über das Internet
zur Verfügung stellen. Reporting
Services isolieren die Leser der Berichte
von der Komplexität der zugrunde
liegenden Datenquellen – gleichzeitig ist
die Personalisierung und Interaktivität
gewährleistet.
Offene und erweiterbare ReportingPlattform
Reporting Services stellen eine vollständige
und serverbasierte Plattform zur Erstellung,
Verwaltung und Bereitstellung von traditionellen und interaktiven Berichten zur
XXV
Verfügung. Gleichzeitig stellen umfassende
APIs und das modulare Design eine Möglichkeit für Softwareentwickler, Datenanbieter und Unternehmen dar, das Reporting
in ältere Systeme oder Drittanbieteranwendungen zu integrieren. Die Reporting
Services bieten eine einzigartige Kombination von Eigenschaften:
• Eine komplette, serverbasierte
Reporting-Plattform
Die Reporting Services unterstützen
den gesamten Lebenszyklus – von der
Erstellung über die Bereitstellung bis
zur Verwaltung von Berichten.
• Flexibles und erweiterbares
Reporting
Die Reporting Services unterstützen
sowohl traditionelle als auch interaktive
Berichte in unzähligen Formaten und
mit umfassenden Bereitstellungsoptionen.
Sie können mit offenen APIs und
Schnittstellen sehr einfach in jede Umgebung oder Lösung integriert werden.
• Skalierbarkeit
Das modulare, webbasierte Design des
Produktes unterstützt auch Umgebungen mit hohen Volumina. Es kann eine
Reporting-Serverfarm mit mehreren
Reporting-Servern eingerichtet werden,
die Tausende von webbasierten Clients
gleichzeitig bedienen kann.
• Integration mit Microsoft-Produkten
und -Tools
Die Reporting Services integrieren sich
sehr leicht in bekannte Microsoft-Tools
wie Visual Studio® und Anwendungen
wie Office® und SharePoint® Portal
Server – und zwar, ohne dass Programmieraufwand oder Anpassungen
notwendig wären.
Erstellung, Verwaltung und Bereitstellung von Berichten
Die Reporting Services kombinieren die
Vorteile von zentral verwalteten Reporting-Systemen mit der Flexibilität und den
On-Demand-Möglichkeiten von Desktopanwendungen und webbasierten Anwendungen. Als vollständige Reporting-Plattform unterstützen die Reporting Services
den gesamten Reporting-Lebenszyklus –
von der Erstellung bis zur Bereitstellung.
ANHANG B. DATENBLÄTTER BERICHTSWERKZEUGE
• Erstellen von Berichten
Die Reporting Services enthalten alles,
was Sie zur Erstellung von traditionellen
oder interaktiven Berichten benötigen –
inklusive eines grafischen Design-Tools
mit den entsprechenden Assistenten.
• Verwalten von Berichten
Die Reporting Services enthalten ein
webbasiertes Tool zur Verwaltung von
Berichten und zur Integration mit dem
neuen SQL Server Management Studio.
Administratoren können diese Schnittstelle zur Organisation von Berichten
und Datenquellen, zur Planung der
Berichtsausführung und -bereitstellung
und zur Verfolgung von Berichtshistorien nutzen. Alternativ können die
Reporting Services Web Services APIs
von Unternehmen oder ISVs zum
Erstellen von angepassten Verwaltungstools verwendet werden.
• Absichern von Berichten
Die Reporting Services implementieren
ein flexibles, rollenbasiertes Sicherheitsmodell zum Schutz der Berichte und
Reporting-Ressourcen. Das Produkt
stellt umfangreiche Schnittstellen zur
Integration anderer Sicherheitsmodelle
zur Verfügung.
• Bereitstellen von Berichten
Sie können Berichte über Portale,
E-Mails oder webbasierte ReportingServer zur Verfügung stellen. Die
Navigations-, Such- und AbonnementFeatures helfen den Benutzern dabei,
die benötigten Berichte zu finden.
Personalisierte Abos sorgen dafür, dass
den Benutzern die von ihnen bevorzugten Berichte angezeigt werden.
Integration mit Microsoft Business
Intelligence-Produkten
Die Reporting Services arbeiten sehr
einfach mit anderen Microsoft Business
Intelligence-Produkten zusammen. Sie
nutzen SQL Server Integration Services
als Datenquelle für Berichte. Dies ist
einzigartig, denn so wird es ermöglicht,
nicht persistente Datenquellen für
Berichte zu verwenden. Mit den SQL
Server Analysis Services stehen umfangreiche, multidimensionale Analysemöglichkeiten zur Verfügung. Die Reporting
Services können nicht nur OLAP-Daten,
sondern auch relationale Daten darstellen.
Die Reporting Services stellen eine vielseitige Benutzerschnittstelle zur Erstellung
von Analyseberichten zur Verfügung. Egal,
ob es um hohe Anforderungen, Ad-hocBerichte für Endbenutzer oder Embedded
Reporting-Funktionen geht – die Reporting Services sind die geeignete Plattform.
SQL Server ist Teil des Windows Server Systems – einer umfassenden und integrierten Serverinfrastruktur, die die Entwicklung, Bereitstellung und den Betrieb einer flexiblen Unternehmenslösung vereinfacht. Weitere Informationen zu SQL Server 2005 und der Analysis
Services Data Mining-Funktionen finden Sie unter http://www.microsoft.com/sql/2005 (englischsprachig).
Die Informationen in diesem Dokument beziehen sich auf eine vorläufige Version eines Softwareprodukts, das bis zur endgültigen Version wesentlichen Änderungen unterliegen kann. Dieses Dokument
wurde vor der Veröffentlichung der Verkaufsversion des besprochenen Produktes erstellt. Daher können wir nicht garantieren, dass alle im Dokument enthaltenen Details in der Verkaufsversion des Produktes
enthalten sind. Die in diesem Dokument enthaltenen Informationen spiegeln die aktuelle Sicht auf das Programm zum Zeitpunkt der Veröffentlichung durch das Unternehmen Microsoft wider. Da Microsoft
auf sich ändernde Marktanforderungen reagieren muss, stellt dies keine Verpflichtung seitens Microsoft dar, und Microsoft kann die Richtigkeit der hier dargelegten Informationen nach dem Zeitpunkt der
Veröffentlichung und die zukünftige Verfügbarkeit des besprochenen Programms nicht garantieren. Dieses Dokument dient nur zu Planungs- und Informationszwecken. Die enthaltenen Informationen
können sich jederzeit und ohne vorherige Ankündigung ändern. MICROSOFT SCHLIESST FÜR DIE INFORMATIONEN IN DIESEM DOKUMENT JEDE GEWÄHRLEISTUNG AUS, SEI SIE AUSDRÜCKLICH ODER
KONKLUDENT.
102347 FD 06/05
XXVI
Anhang C
Detailbeschreibung des Datenmodells
XXVII
ANHANG C. DETAILBESCHREIBUNG DES DATENMODELLS
RPE_Connection
Spaltenname
rpe_ct_idx
Datentyp
int
Prec Scale Nullable default
10
0 No
PK Beschreibung
1 PK
rpe_ct_made
datetime
23
3 No
(getdate())
0 Zeitstempel Erzeugung des Records
rpe_ct_mody
datetime
23
3 No
(getdate())
rpe_ct_ip
varchar
35
YES
0 Zeitstempel letzte Änderung des Records
IP-Adresse des Mitarbeiters bei Erzeugung / letzter
0
Änderung
rpe_ct_op
int
10
0 YES
rpe_ct_del
int
10
0 No
(0)
0 Statusfeld für Löschkennzeichen
(0)
0 FK: Tabelle "Mitarbeiter", Erzeugung / letzte Änderung
rpe_ct_stat
int
10
0 No
rpe_ct_Name
varchar
255
No
0 Name der Verknüpfung für UI
rpe_ct_des
varchar
1000
YES
0 Beschreibung der Verknüpfung für UI
rpe_ct_left_qb_idx
int
10
0 YES
0 FK auf linken QueryBlock
rpe_ct_right_qb_idx int
10
0 YES
0 FK auf rechten QueryBlock
rpe_ct_JoinType
tinyint
rpe_ct_Condition
varchar
3
0 No
6000
No
0 Statusfeld für temp. Benutzung
Art der Verknüpfung 0=Inner Join, 1=Letf Join, 2=Right
Join, 3=Full Join
0 Auswahlbedingung
(0)
0
RPE_FilterPara
Spaltenname
rpe_fp_idx
Datentyp
int
Prec Scale Nullable default
10
0 No
PK Beschreibung
1 PK
rpe_fp_made
datetime
23
3 No
(getdate())
0 Zeitstempel Erzeugung des Records
rpe_fp_mody
datetime
23
3 No
(getdate())
rpe_fp_ip
varchar
35
YES
0 Zeitstempel letzte Änderung des Records
IP-Adresse des Mitarbeiters bei Erzeugung / letzter
0
Änderung
rpe_fp_op
int
10
0 YES
rpe_fp_del
int
10
0 No
(0)
0 Statusfeld für Löschkennzeichen
(0)
0 Statusfeld für temp. Benutzung
0 FK: Tabelle "Mitarbeiter", Erzeugung / letzte Änderung
rpe_fp_stat
int
10
0 No
rpe_fp_qb_idx
int
10
0 YES
0 FK: Tabelle "queryBlock"
rpe_fp_pos
int
10
0 No
0 Position im Parameterstring
rpe_fp_name
varchar
255
No
rpe_fp_default
varchar
255
No
0 Name des Parameters
('NULL')
0 Standartwert des Parameters
RPE_Job
Spaltenname
rpe_jb_idx
Datentyp
int
Prec Scale Nullable default
10
0 No
PK Beschreibung
1 PK
rpe_jb_made
datetime
23
3 No
(getdate())
0 Zeitstempel Erzeugung des Records
rpe_jb_mody
datetime
23
3 No
(getdate())
rpe_jb_ip
varchar
35
YES
0 Zeitstempel letzte Änderung des Records
IP-Adresse des Mitarbeiters bei Erzeugung / letzter
0
Änderung
rpe_jb_op
int
10
0 YES
rpe_jb_del
int
10
0 No
(0)
0 Statusfeld für Löschkennzeichen
(0)
0 Statusfeld für temp. Benutzung
0 FK: Tabelle "Mitarbeiter", Erzeugung / letzte Änderung
rpe_jb_stat
int
10
0 No
rpe_jb_pf_idx
int
10
0 YES
0 FK: Tabelle "Profile"
rpe_jb_done
datetime
23
3 YES
0 Zeitstempel der Fertigstellung des Jobs
rpe_jb_results
int
10
0 YES
0 Anzahl der Ergebnisse
rpe_jb_rc
int
10
0 YES
rpe_jb_archiv
int
10
0 No
KDB- Doku Anhang 2: Datentabellen/Spalten
0 ReturnCode des IPC-Jobs
(90)
0 Anzahl der Tage, die der Job archiviert werden soll
Stand '22.05.2006'
XXVIII
Seite: 1 von 4
ANHANG C. DETAILBESCHREIBUNG DES DATENMODELLS
RPE_Job_Data
Spaltenname
rpe_jd_idx
Datentyp
int
rpe_jd_made
datetime
23
3 No
(getdate())
0 Zeitstempel Erzeugung des Records
rpe_jd_mody
datetime
23
3 No
(getdate())
rpe_jd_ip
varchar
35
YES
0 Zeitstempel letzte Änderung des Records
IP-Adresse des Mitarbeiters bei Erzeugung / letzter
0
Änderung
rpe_jd_op
int
10
0 YES
rpe_jd_del
int
10
0 No
(0)
0 Statusfeld für Löschkennzeichen
10
0 No
(0)
rpe_jd_stat
int
rpe_jd_data
varchar
Prec Scale Nullable default
10
0 No
7958
PK Beschreibung
1 PK
0 FK: Tabelle "Mitarbeiter", Erzeugung / letzte Änderung
0 Statusfeld für temp. Benutzung
YES
0 Daten eines Datenfeldes
rpe_jd_type
tinyint
3
0 YES
rpe_jd_sort
int
10
0 YES
(0)
0
0
rpe_jd_help_pk
int
10
0 YES
0
Postion des Datenfeldes, gemäß Sortiervorgabe, in der
Liste der LineDaten
RPE_Job_Lines
Spaltenname
rpe_jl_idx
Datentyp
int
Prec Scale Nullable default
10
0 No
rpe_jl_made
datetime
23
3 No
(getdate())
0 Zeitstempel Erzeugung des Records
rpe_jl_mody
datetime
23
3 No
(getdate())
rpe_jl_ip
varchar
35
0 Zeitstempel letzte Änderung des Records
IP-Adresse des Mitarbeiters bei Erzeugung / letzter
0
Änderung
YES
PK Beschreibung
1 PK
rpe_jl_op
int
10
0 YES
rpe_jl_del
int
10
0 No
(0)
0 Statusfeld für Löschkennzeichen
0 FK: Tabelle "Mitarbeiter", Erzeugung / letzte Änderung
(0)
0 Statusfeld für temp. Benutzung
rpe_jl_stat
int
10
0 No
rpe_jl_jb_idx
int
10
0 YES
0 FK: Tabelle "Job"
rpe_jl_pp_idx
int
10
0 YES
0 FK: Tabelle "ProfileLines"
RPE_Line
Spaltenname
rpe_li_idx
Datentyp
int
Prec Scale Nullable default
10
0 No
PK Beschreibung
1 PK
rpe_li_made
datetime
23
3 No
(getdate())
0 Zeitstempel Erzeugung des Records
rpe_li_mody
datetime
23
3 No
(getdate())
rpe_li_ip
varchar
35
YES
0 Zeitstempel letzte Änderung des Records
IP-Adresse des Mitarbeiters bei Erzeugung / letzter
0
Änderung
rpe_li_op
int
10
0 YES
rpe_li_del
int
10
0 No
(0)
0 Statusfeld für Löschkennzeichen
rpe_li_stat
int
10
0 No
(0)
0 Statusfeld für temp. Benutzung
rpe_li_qb_idx
int
10
0 YES
0 FK: Tabelle "queryBlock"
rpe_li_sb_idx
int
10
0 YES
0 FK: Tabelle "showBlock"
rpe_li_name
varchar
255
No
rpe_li_des
varchar
1000
YES
0 Beschreibung des Lineinhaltes
rpe_li_query
varchar
6000
No
0 SQLtext der Spaltenabfrage
0 FK: Tabelle "Mitarbeiter", Erzeugung / letzte Änderung
0 Name der Line
RPE_ParaValue
Spaltenname
rpe_pv_idx
Datentyp
int
Prec Scale Nullable default
10
0 No
rpe_pv_made
datetime
23
3 No
(getdate())
0 Zeitstempel Erzeugung des Records
rpe_pv_mody
datetime
23
3 No
(getdate())
0 Zeitstempel letzte Änderung des Records
KDB- Doku Anhang 2: Datentabellen/Spalten
PK Beschreibung
1 PK
Stand '22.05.2006'
XXIX
Seite: 2 von 4
ANHANG C. DETAILBESCHREIBUNG DES DATENMODELLS
rpe_pv_ip
varchar
35
YES
rpe_pv_op
int
10
0 YES
0
IP-Adresse des Mitarbeiters bei Erzeugung / letzter
Änderung
0 FK: Tabelle "Mitarbeiter", Erzeugung / letzte Änderung
rpe_pv_del
int
10
0 No
(0)
0 Statusfeld für Löschkennzeichen
rpe_pv_stat
int
10
0 No
(0)
0 Statusfeld für temp. Benutzung
rpe_pv_fp_idx
int
10
0 YES
0 FK: Tabelle "FilterPara"
rpe_pv_pos
int
10
0 No
0 Position für Liste in UI
rpe_pv_name
varchar
255
No
0 Textliche Bedeutung des Values für UI
rpe_pv_value
varchar
7000
No
0 Wert des Parameters
rpe_pv_type
int
10
0 No
0 Datentyp des Parameters
RPE_Profile
Spaltenname
rpe_pf_idx
Datentyp
int
Prec Scale Nullable default
10
0 No
PK Beschreibung
1 PK
rpe_pf_made
datetime
23
3 No
(getdate())
0 Zeitstempel Erzeugung des Records
rpe_pf_mody
datetime
23
3 No
(getdate())
rpe_pf_ip
varchar
35
YES
0 Zeitstempel letzte Änderung des Records
IP-Adresse des Mitarbeiters bei Erzeugung / letzter
0
Änderung
rpe_pf_op
int
10
0 YES
rpe_pf_del
int
10
0 No
(0)
0 Statusfeld für Löschkennzeichen
rpe_pf_stat
int
10
0 No
(0)
0 Statusfeld für temp. Benutzung
rpe_pf_ma_idx
int
10
0 YES
0 FK: Tabelle "Mitarbeiter", Besitzer des Profils
rpe_pf_name
int
10
0 No
0 Name des Profils
rpe_pf_archiv
int
10
0 No
0 FK: Tabelle "Mitarbeiter", Erzeugung / letzte Änderung
(90)
0 Zeit der Archivierung in Tagen
RPE_Profile_Projection
Spaltenname
rpe_pp_idx
Datentyp
int
Prec Scale Nullable default
10
0 No
rpe_pp_made
datetime
23
3 No
(getdate())
0 Zeitstempel Erzeugung des Records
rpe_pp_mody
datetime
23
3 No
(getdate())
rpe_pp_ip
varchar
35
0 Zeitstempel letzte Änderung des Records
IP-Adresse des Mitarbeiters bei Erzeugung / letzter
0
Änderung
YES
PK Beschreibung
1 PK
rpe_pp_op
int
10
0 YES
rpe_pp_del
int
10
0 No
(0)
0 Statusfeld für Löschkennzeichen
rpe_pp_stat
int
10
0 No
(0)
0 Statusfeld für temp. Benutzung
rpe_pp_li_idx
int
10
0 YES
0 FK: Tabelle "Line"
rpe_pp_pf_idx
int
10
0 YES
0 FK: Tabelle "Profile"
10
0 No
(0)
0 Dimension der Line
10
0 No
(0)
0 Datenschlüssel zur Art des LineNamen
(0)
0 Datenschlüssel: Sortierreihenfolge für die Daten der Line
rpe_pp_dim
int
rpe_pp_namesourc
int
e
rpe_pp_optName
varchar
rpe_pp_sort
int
255
10
0 FK: Tabelle "Mitarbeiter", Erzeugung / letzte Änderung
YES
0 No
0 (optionaler) benutzerdefinierter Name der Line
RPE_Profile_Selection
Spaltenname
rpe_ps_idx
Datentyp
int
Prec Scale Nullable default
10
0 No
rpe_ps_made
datetime
23
3 No
(getdate())
0 Zeitstempel Erzeugung des Records
rpe_ps_mody
datetime
23
3 No
(getdate())
rpe_ps_ip
varchar
35
0 Zeitstempel letzte Änderung des Records
IP-Adresse des Mitarbeiters bei Erzeugung / letzter
0
Änderung
YES
KDB- Doku Anhang 2: Datentabellen/Spalten
PK Beschreibung
1 PK
Stand '22.05.2006'
XXX
Seite: 3 von 4
ANHANG C. DETAILBESCHREIBUNG DES DATENMODELLS
rpe_ps_op
int
10
0 YES
rpe_ps_del
int
10
0 No
(0)
0 Statusfeld für Löschkennzeichen
0 FK: Tabelle "Mitarbeiter", Erzeugung / letzte Änderung
rpe_ps_stat
int
10
0 No
(0)
0 Statusfeld für temp. Benutzung
rpe_ps_pf_idx
int
10
0 YES
0 FK: Tabelle "Profile"
rpe_ps_qb_idx
int
10
0 YES
0 FK: Tabelle "queryBlock"
rpe_ps_pars_idx
int
10
0 YES
0 FK: Tabelle "ParameterSet"
RPE_queryBlock
Spaltenname
rpe_qb_idx
Datentyp
int
Prec Scale Nullable default
10
0 No
rpe_qb_made
datetime
23
3 No
(getdate())
0 Zeitstempel Erzeugung des Records
rpe_qb_mody
datetime
23
3 No
(getdate())
rpe_qb_ip
varchar
35
0 Zeitstempel letzte Änderung des Records
IP-Adresse des Mitarbeiters bei Erzeugung / letzter
0
Änderung
0 Statusfeld für Löschkennzeichen
YES
rpe_qb_op
int
10
0 YES
rpe_qb_del
int
10
0 No
(0)
10
0 No
(0)
255
No
rpe_qb_stat
int
rpe_qb_TabName
varchar
PK Beschreibung
1 PK
0 FK: Tabelle "Mitarbeiter", Erzeugung / letzte Änderung
0 Statusfeld für temp. Benutzung
0 Name der BlockTabelle
rpe_qb_pk
varchar
255
No
0 PK der BlockTabelle
rpe_qb_FName
varchar
255
No
0 Name des Filter
rpe_qb_FFunction
varchar
255
No
rpe_qb_FSelect
varchar
6000
No
0 Filterfuntionsname für den Aufruf
('SELECT *
FROM')
0 Aufruftext der Filterfunktion
RPE_showBlock
Spaltenname
rpe_sb_idx
Datentyp
int
Prec Scale Nullable default
10
0 No
PK Beschreibung
1 PK
rpe_sb_made
datetime
23
3 No
(getdate())
0 Zeitstempel Erzeugung des Records
rpe_sb_mody
datetime
23
3 No
(getdate())
rpe_sb_ip
varchar
35
YES
0 Zeitstempel letzte Änderung des Records
IP-Adresse des Mitarbeiters bei Erzeugung / letzter
0
Änderung
rpe_sb_op
int
10
0 YES
0 FK: Tabelle "Mitarbeiter", Erzeugung / letzte Änderung
rpe_sb_del
int
10
0 No
(0)
0 Statusfeld für Löschkennzeichen
rpe_sb_stat
int
10
0 No
(0)
0 Statusfeld für temp. Benutzung
rpe_sb_name
varchar
255
No
0 Name des log. Anzeigeblockes
rpe_sb_des
varchar
1000
YES
0 Beschreibung
Prec Scale Nullable default
10
0 No
PK Beschreibung
1 PK
xRPE_Job_LineData
Spaltenname
xrpe_jld_idx
Datentyp
int
xrpe_jld_made
datetime
23
3 No
(getdate())
0 Zeitstempel Erzeugung des Records
xrpe_jld_mody
datetime
23
3 No
(getdate())
xrpe_jld_ip
varchar
35
YES
0 Zeitstempel letzte Änderung des Records
IP-Adresse des Mitarbeiters bei Erzeugung / letzter
0
Änderung
xrpe_jld_op
int
10
0 YES
xrpe_jld_del
int
10
0 No
(0)
0 Statusfeld für Löschkennzeichen
(0)
0 Statusfeld für temp. Benutzung
0 FK: Tabelle "Mitarbeiter", Erzeugung / letzte Änderung
xrpe_jld_stat
int
10
0 No
xrpe_jld_jl_idx
int
10
0 YES
0 FK: Tabelle "JobLines"
xrpe_jld_jd_idx
int
10
0 YES
0 FK: Tabelle "JobData"
xrpe_jld_dim
int
10
0 No
KDB- Doku Anhang 2: Datentabellen/Spalten
(0)
0 Dimension
Stand '22.05.2006'
XXXI
Seite: 4 von 4
Anhang D
Inhalt der Begleit-CD
LaTeX
d
LaTeX-Quellcode
Abschnitt
d
Kapitel
Pics
d
Abbildungen
Auswertungen
d
Auswerungsanalyse
HVB
d
manuelle Auswertungen der HVB
VUW
d
manuelle Auswertungen der VUW
Analyse.xls
f
Analyseergebnisse
Analyser.pl
f
Analyseskript
Umsetzung
d
RPE.pdf
f
Datenbankdiagramm der RPE
RPE_Projection.pl
f
Projektions-Modul
RPE_Tablestructure.sql
f
SQL-Quellcode zum Anlegen
der Tabellenstruktur
RPE_TD.pdf
f
Detailbeschreibung des Datenmodells
XXXII