Ein generisches Data Warehouse im Kontext einer

Ein generisches Data Warehouse im Kontext einer Anwendungsarchitektur
Prof. Dr. Wolfgang Gerken
Fachhochschule Hamburg
FB Elektrotechnik/Informatik
Berliner Tor 3
20099 Hamburg
E-Mail: [email protected]
Zusammenfassung
Der Gesamtverband der Deutschen Versicherungswirtschaft e. V. hat eine Musterarchitektur für DVAnwendungssysteme
im
Versicherungswesen
entwickelt,
auf
deren
Basis
Softwarehäuser
Versicherungsunternehmen im Rahmen eines Komponentenmarktes modulare und adaptierbare
und
Anwendungen
entwickeln bzw. einsetzen sollen. Diese begrüßenswerte Initiative basiert aber auf einem Modell, welches das
Geheimnisprinzip objektorientierter Anwendungen verletzt [GeRa96].
In diesem Beitrag wird eine alternative Komponentenarchitektur vorgestellt. Weiterhin wird anhand der Komponente
Data Warehouse exemplarisch gezeigt, wie sich generische Strukturen bei der Entwicklung anpaßbarer Komponenten
einsetzen lassen.
Die Untersuchungen werden im Rahmen des Projektes „Software-Engineering in der Versicherungswirtschaft“
(SEVERS) durchgeführt, das seit einigen Semestern im FB Elektrotechnik/Informatik der FH Hamburg läuft.
1
Das Projekt SEVERS
Das Projekt „Software-Engineering in der Versicherungswirtschaft“ (SEVERS) dient dazu, die im
Informatik-Studium vermittelten Methoden und Ansätze mit praktischen Anwendungen zu
konfrontieren und ihre Bewährung nachzuweisen. Dies erfolgt in enger Zusammenarbeit mit
Beratungs- und Versicherungsunternehmen im Hamburger Raum. Die Teilnahme an Projekten ist
fester Bestandteil des Curriculums der letzten Studiensemester.
Das SEVERS-Projekt (vgl. URL http://users.informatik.fh-hamburg.de/~raasch/severs.htm) geht
davon aus, daß Versicherungsunternehmen, wie auch Unternehmen anderer Branchen, in den
nächsten Jahren einen schwerwiegenden Technologiewandel in der informationstechnologischen
Infrastruktur zu bewältigen haben. Dazu möchten wir Qualifikationsmöglichkeiten im Rahmen
wechselnder Arbeitsvorhaben für unsere Studierenden anbieten: insbesondere gehören dazu die
Bereiche Objektorientierung, Anwendungsarchitekturen und Data Warehouse, von denen hier die
Rede sein soll.
2
Die Versicherungs-Anwendungs-Architektur
Hoher Kostendruck, größere Kundenorientierung, kürzere geforderte Entwicklungszeiten bei der
Produktentwicklung, eine effiziente Unterstützung des Außendienstes sowie die Forderung nach
besseren Führungsinformationen führten zur Entwicklung der Versicherungs-AnwendungsArchitektur VAA [GDV96]. Sie stellt als übergreifendes Konstruktionsprinzip und Referenzarchitektur einen begrüßenswerten softwaretechnischen Rahmen für Versicherungsanwendungen
der Zukunft dar.
VAA unterscheidet zwischen einer fachlichen und einer technischen Architektur. Im fachlichen Teil
werden die Versicherungsanwendungen durch ein Prozeßmodell beschrieben, das sich aus einem
Funktionen- und einem Datenmodell zusammensetzt. Das Prozeßmodell beinhaltet die für
Versicherungsunternehmen relevanten Geschäftsprozesse. Es operiert auf Geschäftsobjekten wie
Versicherungsvertrag, Partner, Schaden/Leistung, Geschäftsprozeßdokumentation, Produkt, Konto,
Versicherungsobjekt sowie Dokument, Schriftstück, Datenträger. Das Funktionenmodell basiert auf
dem aus sechs Kernfunktionen bestehenden Modell von Farny [Farn95]. Das Grundkonzept der
technischen Architektur ist dreischichtig. Die Versicherungsanwendungskomponenten der
Bausteinschicht, die durch eine Entkopplungs- und Schnittstellenschicht unabhängig von den
eingesetzten Systemplattformen sind, stellen dabei die technischen Realisierungen der fachlichen
Prozesse dar.
Die in Teil- und Elementarprozesse hierarchisch gegliederten Prozeßketten der fachlichen Sicht
werden aus technischer Sicht von einem Workflowmanager gesteuert, der die globale Konsistenz
der arbeitsplatzübergreifenden Geschäftsprozesse sicherstellt. Der Workflowmanager ruft
seinerseits die Vorgangssteuerung auf, die die Arbeitsschritte am Arbeitsplatz eines Bearbeiters
steuert. Daraus ergibt sich für ein nach VAA entwickeltes DV-Anwendungssystem folgendes
Schichtenmodell. Für nähere Erläuterungen siehe [GDV96].
STEUERUNGSEBENE
Dialogmanager
Workflowmanager
Parametersystem
DV-Vorgangsmanager
Datenmanager
ARBEITSEBENE
Deckungsprüfung
Tarifierung
Provisionsermittlung
....
ANWENDUNGSBAUSTEINE
DIENSTEBENE
Präsentationsdienste
Berechtigungssystem
Textverarbeitung
Fehlerbehandlung
Entkopplungs- und Schnittstellenschicht
Systemplattform
Abb. 1: Schichtenmodell eines VAA-konformen Anwendungssystems (vgl. [GDV96])
....
Die Arbeitsebene realisiert die fachlichen Elementarprozesse. Die Steuerungsebene enthält die
Komponenten zur arbeitsplatzübergreifenden Workflowsteuerung, zur arbeitsplatzbezogenen
Vorgangssteuerung sowie den Dialogmanager. Anwendungsbausteine dürfen sich nicht gegenseitig
aufrufen. Dies ist nur über die Workflow- bzw. Vorgangssteuerung möglich. Der Zugriff auf
Datenbestände – insbesondere die anderer Anwendungsbausteine - wird von einem zentralen
Datenmanager durchgeführt. Dadurch werden Datenbanken global, das Geheimnisprinzip wird
unterlaufen. Es können Systeme entstehen, die genauso wartungs- und pflegeintensiv sind wie jene
Altsysteme, die es mittelfristig abzulösen gilt. Die dringend erforderliche Flexibilisierung der
Anwendungen wird nicht erreicht [Raas98]. Änderungen im Ablauf eines Teilprozesses haben
immer Auswirkungen auf den steuernden Workflow- bzw. Vorgangsmanager und sind damit nicht
mehr nur lokal durchführbar. Außerdem ist der gewünschte Komponentenmarkt unserer Meinung
nach nur realisierbar, wenn die Datenbestände einer Komponente lokal verwaltet werden. Dies setzt
allerdings voraus, daß eine Komponente Schnittstellen besitzt, über die andere Komponenten auf
die Datenbestände zugreifen können, wie es in der folgenden Abbildung rechts gezeigt ist.
Anwendung A
Partner
Anwendung B
Versicherungsnehmer
Vertrag
Komponente A
Partner Versicherungsnehmer
Komponente B
Vertrag
Abb. 2: Integrierte Datenbestände vs. Komponentenarchitektur
Allerdings gilt es in diesem Fall darauf zu achten, daß die Einhaltung von Geschäftsregeln
[KnHe95] und die globale Konsistenz der Daten durch vertragliche Regelungen zwischen den
einzelnen Komponenten sichergestellt ist. Dies erfolgt über Aufrufe der Komponentenschnittstelle
(siehe dazu die Ausführungen im nächsten Abschnitt bzw. [Raas98]). Die Mechanismen werden
denen bei einer verteilten Datenbank gleichen müssen.
3
Die Komponentenarchitektur
Im Rahmen des SEVERS-Projekts wurde eine Komponentenarchitektur entwickelt, die im
Gegensatz zur VAA von einem strengen Modul-Begriff ausgeht und das Geheimnisprinzip
unterstützt. Die Komponenten orientieren sich an den Geschäftsobjekten eines
Versicherungsunternehmens. So gibt es z. B. die Komponenten Partner,
Produkt oder
Schaden/Leistung. Die Architektur einer Komponente ist der folgenden Abbildung zu entnehmen;
genauere Ausführungen finden sich in [Raas98].
Datenhaltung
(KS)
Datenhaltung
(VgSt)
Komponentenschnittstelle
Vorgangssteuerung
Interaktionssteuerung
Fachmodell
(Domain)
Datenhaltung
(Domain)
Andere
Anwendungskomponenten
Dialogsteuerung
Abb. 3: Architektur von Anwendungskomponenten
Anwendungskomponenten besitzen eine innere Aufteilung in Subkomponenten, denen jeweils
bestimmte Aufgaben zugewiesen sind:
• Komponentenschnittstelle
Die von anderen Anwendungskomponenten nutzbaren Dienste bzw. Leistungen einer
Komponente werden über die Komponentenschnittstelle bereitgestellt; und nur über diese
Schnittstelle kann die Komponente ihrerseits die Dienste anderer Komponenten aufrufen.
• Datenhaltung (Komponentenschnittstelle)
Die Komponentenschnittstelle besitzt eine eigene Datenhaltung für interne, persistente Daten.
• Vorgangssteuerung
Die Vorgangssteuerung überwacht und steuert die Abarbeitung eines Geschäftsvorfalls in einer
Komponente aus fachlicher Sicht. Sie kann damit als Untereinheit des (globalen) WorkflowManagers betrachtet werden, der die komponentenübergreifende Steuerung eines
Geschäftsvorfalls übernimmt.
• Datenhaltung (Vorgangssteuerung)
Hier werden die für die Vorgangssteuerung notwendigen Daten über legale Geschäftsvorfälle
gespeichert.
• Interaktionssteuerung
Diese Subkomponente regelt und gewährleistet die korrekte Kommunikation zwischen der
(nicht zur Komponente gehörenden) Benutzungsschnittstelle und dem Fachmodell. Sie sorgt
dafür, daß Dialoge angezeigt und wieder entfernt werden, daß Fehler- und Statusmeldungen
vom Fachmodell und der Vorgangssteuerung an die Benutzungsschnittstelle weitergegeben
werden.
•
•
•
4
Dialogsteuerung
Die Dialogsteuerung übernimmt die externe Darstellung interner Formate und kommuniziert mit
dem Benutzer. Da viele Unternehmen
sich eine firmenspezifische Fassung der
Bildschirmformate vorbehalten werden, ist dieser Anwendungsteil offen, d. h. anpaßbar.
Fachmodell
Das Fach- oder auch Domainmodell repräsentiert den eigentlichen Anwendungsbereich, die
abstrakte fachliche Sicht der Anwendungswelt. Sie kapselt die Geschäftsobjekte einer
Anwendungswelt (in diesem Fall einer Versicherung). Alle fachlichen Zusammenhänge
spiegeln sich im Domainmodell wider, das für die eigene Konsistenz und für korrekte
Beziehungen zu anderen Geschäftsobjekten sorgt.
Datenhaltung (Fachmodell)
Diese Subkomponente sorgt für eine eigene, lokale Speicherung der zu einem Geschäftsobjekt
gehörenden Daten. Dadurch sind Anwendungskomponenten austauschbar, was einen
Komponentenmarkt erst ermöglicht.
Die Anwendungskomponente Data Warehouse
Neben den operationalen Anwendungskomponenten wie Partner, Produkt usw. benötigt ein
Versicherungsunternehmen noch ein Führungsinformationssystem (siehe dazu etwa [Vets95],
BeSc93]). In diesem Zusammenhang wird oft der Begriff Data Warehouse genannt. Unter einem
Data Warehouse wollen wir eine Datenbank verstehen, die in einem Unternehmen entscheidungsrelevante Daten, die aus unterschiedlichsten Quellen stammen können, für Management-Aufgaben
bereitstellt. Damit gehört zum Begriff des Data Warehouse nicht nur die Definition und
Speicherung der Daten, sondern die gesamte Thematik der Führungsinformationssysteme, also
Datenübernahme, Aufbereitung und Auswertung (vgl. zu diesem Thema etwa [AnMu97],
[ChGl98], [Gerk97], [MuBe96]. Wichtig dabei ist, daß die notwendigen Daten vorhanden und
zugreifbar sind und Analyseprozesse zur Verfügung stehen, die die Daten in entscheidungsrelevante
Informationen umwandeln und diese geeignet bereitstellen.
Ein Data Warehouse läßt sich durch folgende Eigenschaften kennzeichnen [Inmo96]:
• Subjektorientierung:
Die (logische) Organisation und die Darstellung der Daten erfolgt aus der Sicht des Anwenders,
d. h. seine Anforderungen bezüglich der Informationsinhalte bestimmen die Strukturen.
• Verwaltung großer Datenmengen:
Historische Daten werden zur Optimierung der Performance und zur Reduzierung des
Speicherbedarfs bei operationalen Systemen entweder nicht vorgehalten oder ausgelagert. Ein
erfolgreiches Data Warehouse muß solche Daten aber online verfügbar machen. Dabei stellt sich
das Problem, daß eine Vorstrukturierung der Daten erforderlich ist, um bei Abfragen eine
akzeptable Antwortzeit, die nicht im Stunden-Bereich liegt, gewährleisten zu können. Aus
diesem Grund ist z. B. festzulegen, welche Daten redundant gespeichert werden sollen und
welche jeweils bei Bedarf aus anderen berechnet werden können.
• Summation und Aggregation:
Um die operationalen Daten entscheidungsrelevant vorzuhalten, müssen diese bei ihrer
Übernahme in ein Data Warehouse durch Summation und Aggregation verdichtet werden. So
interessieren einen Manager sicherlich nicht die einzelnen Positionen jeder Bestellung eines
Kunden; wohl aber die Quartals- und Jahressummen. Dadurch werden auch die Zugriffszeiten
auf die gespeicherten Daten reduziert.
• unterschiedliche Informationsquellen:
Die Datenbasis für ein Data Warehouse kann aus verschiedenen Bereichen erstellt werden; so
gehen in der Regel neben operationalen Produktionsdaten auch historische Daten und evtl.
externe Daten (wie z. B. der DAX oder Daten aus Wirtschaftsdatenbanken) in die Datenbasis
ein. In diesem Zusammenhang ist ein Abgleich der verschiedenen konzeptuellen Schemata
erforderlich, um die Daten der Quellen-Systeme in die Strukturen des Data Warehouse
überführen zu können.
Die in einem Data Warehouse gespeicherten Daten kann man sich als mehrdimensionalen Würfel
strukturiert denken. Die als Dimensionen bezeichneten Kanten des Würfels sind z. B. Zeit, Artikel,
Kunden, Region. Eine Dimension kann in mehrere Dimensions- oder Aggregationsebenen aufgeteilt
sein; bei Artikel sind das z. B. Artikel→Artikelgruppe→Sparte und bei der Dimension Zeit
Tag→Woche→Monat→Jahr (die Aggregationsrichtung wird duch den Pfeil symbolisiert). Im
allgemeinen ist davon auszugehen, daß Aggregation disjunkte Summation bedeutet. Der Wechsel
von einer höheren zu einer niedrigeren Aggregationsebene einer Dimension (z. B. von Artikelgruppe zu Artikel) wird Drill-Down genannt; der umgekehrte Weg heißt Roll-up. Für jede
Dimension und jede Aggregationsebene gibt es mehrere Ausprägungen. Das sind die einzelnen
Zeitpunkte bzw. Zeiträume, die einzelnen Artikel, Artikelgruppen usw. Das Innere des
mehrdimensionalen, von den Dimensionen aufgespannten Datenwürfels sind die zu den
Dimensionsausprägungen gehörenden Fakten wie Umsatz, Absatz oder auch Return of Investment
(= Gewinn / eingesetztes Kapital). Die Fakten sind also Funktionen der Dimensionen, wie z. B.
1.000.000 = Umsatz(XYZ GmbH, 1997). Jeder gespeicherte Wert ist von mehreren der
Dimensionen abhängig; aber nicht notwendigerweise von allen.
Im Rahmen der SEVERS-Komponentenarchitektur ist das Data Warehouse eine Anwendungskomponente unter anderen. Damit ist es optimal in das gesamte betriebliche Informationssystem
eingebettet. Über die Komponentenschnittstelle erfolgt dann die Versorgung des Data Warehouse
mit Daten der anderen (operationalen) Komponenten. Hierbei sind allerdings
Transformationsprozesse in Form von Filterungen, Harmonisierungen, Verdichtungen und
Anreicherungen notwendig [KeFi98]. Das Fachmodell realisiert den logischen Datenwürfel. Es
abstrahiert dabei von der internen Speicherung der Daten, die in einer relationalen,
objektrelationalen, objektorientierten oder in einer speziellen multidimensionalen Datenbank
erfolgen kann. Anforderungen an ein RDBMS aus Sicht eines Data Warehouse beschreibt [Reut96];
Anmerkungen zur Eignung objektorientierter Datenbanksysteme für den Einsatz im DataWarehouse-Bereich finden sich in [Ohle96]; Architekturkonzepte multidimensionaler DataWarehouse-Lösungen sind bei [Gluc96] beschrieben.
Fachmodell und Vorgangssteuerung zusammen stellen die Funktionalitäten für Auswertungen des
Data Warehouse bereit, wie sie für Führungsinformationssysteme notwendig sind. Sie entsprechen
damit der ROLAP-Engine von [Gluc96]. Für nähere Ausführungen zum Thema Online Analytical
Processing bzw. Data Mining siehe z. B. [BeLi97], [Boll96], [HaBM97], [JaGK96], [Nakh98].
5
Datenmodellierung bei einem Data Warehouse
Wie jede Datenbank muß auch ein Data Warehouse semantisch und logisch modelliert werden. Zur
semantischen Modellierung herkömmlicher OLTP-Anwendungen (Online-Transaction-Processing)
und zum Einsatz von relationalen Datenbanksystemen, wodurch als logisches Datenmodell das
Relationenmodell bestimmt ist, hat sich das Entity-Relationship-Modell durchgesetzt ([Hahn98], S.
105). Die Anforderungen an ein OLAP-System nach Codd et al. (vgl. dazu [JaGK96]) wie z. B. die
multidimensionale konzeptionelle Sicht auf die Daten, Einheitlichkeit der einzelnen Dimensionen
hinsichtlich Struktur und Funktionalität und intuitive Datenanalyse legen aber besondere
Modellierungsmethoden wie das Star-Schema und das Snowflake-Schema nahe (vgl. dazu
[Hahn98], S. 109 ff). Die grundlegende Idee des Star-Schemas ist es, die Daten eines Data
Warehouse in die bereits erwähnten Kategorien Fakten und Dimensionen aufzuteilen und diese
unterschiedlich zu modellieren und darzustellen.
Die folgende Abbildung zeigt, wie ein Datenmodell nach dem Star-Schema aussehen könnte. Die
Fakten-Tabelle wird als Kreis/Ellipse dargestellt, die Dimensionstabellen als Rechteck. Die
Beziehungen zwischen Dimensionen und Fakten sind implizit immer vom Typ 1:N.
Zeit
Vertrieb
Produktion
Produkte
Kunden
Abb. 4: Beispiel für ein Star-Schema
Bei der Umsetzung in eine relationale Datenbank beinhaltet die Fakten-Tabelle Produktion
Fremdschlüssel für jede Dimension und die Zahlenwerte für z. B. Policenanzahl, Bewertungseinheit
BWE, Provision. Zur Selektion von Daten aus der Faktentabelle muß ein Join über sämtliche
beteiligten Dimensionstabellen gebildet und anschließend eine Restriktion auf die auszugebenden
Attribute durchgeführt werden.
Kunden
KID Name ...
13 Otto
14
Eva
...
Zeit
ZID Monat ...
81 04/98
Produkte
PID Name ...
5 HUK
6
LV
Vertrieb
VID Bdir ...
11 Hmb
KID
13
14
14
...
ZID
81
81
81
PID
5
5
6
Produktion
VID
Policen
11
2
11
1
11
1
BWE
2.000
900
5.000
Provision
400
150
900
Abb. 5: Logisches Datenmodell eines Star-Schemas
Mögliche verschiedene Aggregationsebenen einer Dimension, der sogenannte Drill-down-Baum,
können durch eine 1:n-Beziehung einer Dimension auf sich selbst abgebildet werden, wie es z. B.
von Stücklisten-Strukturen bekannt ist. Eine weitere, allerdings nicht-normalisierte Variante zur
Realisierung von Dimensionshierarchien zeigt die folgende Abbildung.
KID
13
14
15
16
17
18
...
Kunden
Region
PLZ
20
20099
20
20099
20
20098
20
20098
20
20099
20
-
Name
Otto
Adam
Eva
-
Abb. 6: Dimensionshierarchien
6
Generische Datenstrukturen bei einem Data Warehouse
Die oben vorgestellte Umsetzung eines Star-Schemas in eine relationale Datenbank ist zwar
intuitiv und kann auch durch geeignete Zugriffsverfahren wie z. B. Bitlisten oder die mehrdimensionale Indizes verwaltenden UB-Bäume [Baye96] unterstützt werden, ist aber schwerfällig
bei Strukturänderungen beim zugrundeliegenden
Datenwürfel. Das Hinzufügen neuer
Dimensionen, neuer Aggregationsebenen innerhalb einer Dimension oder neuer Fakten ist immer
mit Schemaänderungen verbunden. Der nachfolgend vorgeschlagene, generische Ansatz hat diese
Nachteile nicht.
Die Konzeption von generischen Strukturen, die mit den Anwendungsmodellen zu instantiieren
sind, basiert auf dem Prinzip der Abstraktion [Loos96]. Das Domain-Modell „Produkt“ des
SEVERS-Projekts erlaubt z. B. die Definition von Versicherungsprodukten durch Instanziierung
von Objekten eines Metamodells statt Erzeugung von Datenbank-Tabellen. Hierauf wird im
folgenden aber nicht weiter eingegangen. Statt dessen wird gezeigt, wie ein Data Warehouse in
eine generische Struktur eingebettet werden kann.
Eine erste Änderung besteht darin, die bei [Hahn98] als Kennzahlen bezeichneten Fakten anders zu
betrachten. Es wird zwischen dem Kennzahlbegriff (Attribut) und dem Wert (Attributwert)
unterschieden; z. B. Kennzahl: Umsatz, Wert: 1,2 Mio. DM). Die Kennzahlen stellen dann, auf
einer höheren Abstraktionsebene, eine eigene Dimension dar. Die ursprünglichen Fakten sind nur
noch die Kennzahlenwerte. Dadurch ergibt sich ein neues logisches Datenmodell für die Tabelle
Produktion aus Abb. 5.
KID
13
13
13
...
ZID
81
81
81
Produktion
PID
VID
5
11
5
11
5
11
Kennzahl
Policen
BWE
Provision
Wert
2
2.000
400
Abb. 7: Modifizierte Faktentabelle
Bei dieser Lösung können ohne Datenstrukturänderungen neue Kennzahl(begriffe) hinzugefügt
werden. Dimensionsänderungen haben aber immer noch Strukturänderungen zur Folge. Wenn auch
dieses vermieden werden soll, kommt man zu noch einer anderen Lösung. Wenn man die
ursprüngliche Faktentabelle „kippt“, erhält man je Dimensionswert ein eigenes Tupel. Die zu einem
Fakt gehörenden Fremdschlüssel werden mit einem gemeinsamen künstlichen Schlüssel versehen.
KEY
1
1
1
1
1
1
1
2
...
Produktion
Dimension
ID
Kunden
13
Zeit
81
Produkte
5
Vertrieb
11
Kennzahl
Policen
Kennzahl
BWE
Kennzahl Provision
...
...
...
Wert
2
2.000
400
Abb. 8: Gekippte Faktentabelle
Eine weitere Änderung bei der generischen Umsetzung eines mehrdimensionalen Datenwürfels
betrifft die Dimensionstabellen. Es gibt keine unabhängigen Dimensionstabellen mehr. Statt dessen
existieren zwei Meta-Tabellen mit den Dimensionsbezeichnungen und mit den einzelnen
Aggregationsebenen und eine Tabelle mit den Ausprägungen der einzelnen Dimensionen. Das
Hinzufügen einer neuen Dimension oder einer neuen Ebene im Drill-down-Baum ist dann nicht
mehr mit Schemaänderungen der Datenbank verbunden, sondern bewirkt nur das Einfügen neuer
Tupel in die genannten Tabellen.
Aggregationsebenen
Dimensionen
Dimensionswerte
Faktenwerte
Abb. 9: Generisches, semantisches Datenmodell eines mehrdimensionalen Datenwürfels
Die Pfeile stellen jeweils 1:n-Beziehungen dar. Die 1:n-Beziehung von Dimensionsebenen auf sich
selbst ermöglicht die Definition mehrerer Aggregationsebenen innerhalb einer Dimension, wie sie
für das Roll-up bzw. Drill-down notwendig ist. Entsprechendes gilt für die Aggregation der
Dimensionswerte. Die folgende Abbildung stellt die beispielhafte Umsetzung dieses Konzepts in
eine relationale Datenbank dar.
Dimension
Dim-Id
Name
1
Zeit
2
Produkt
3
Vertrieb
4
Kennzahl
5
Kunden
Werte-Id
1
2
3
4
5
6
7
8
9
10
11
12
13
Ebene-Id
1
2
3
4
5
6
7
8
9
Aggregationsebene
Name
Dim-Id
Jahr
1
Monat
1
Sparte
2
Produkt
2
Bdir
3
Agentur
3
Kennzahl
4
Region
5
PLZ
5
Dimensionswerte
Ebene-Id
OberWert-Id
2
5
3
5
2
5
1
3
7
7
7
6
3
8
9
11
...
...
Dim-Wert
04/98
HUK
Hmb
05/98
1998
LV
Policen
BWE
Provision
Hmb-Mitte
20
20099
...
Ober-Id
1
3
5
8
Gruppe
1
1
1
1
1
1
1
2
2
2
3
...
Faktenwerte
DimWerte-Id
1
2
3
12
7
8
9
5
6
9
...
Wert
3
2.900
550
200.000
-
Abb. 10: Generisches, logisches Datenmodell eines mehrdimensionalen Datenwürfels
Bedeutung und Inhalt der einzelnen Attribute können der folgenden Tabelle entnommen werden.
Relation
Dimension
Aggregationsebene
Attribut
Dim-Id
Name
Ebene-Id
Name
Dim-Id
Ober-Id
Dimensionswerte Werte-Id
Ebene-Id
OberWert-Id
Faktenwerte
Dim-Wert
Gruppe
DimWerte-Id
Wert
Beschreibung
Identifikationsschlüssel (Primary Key PK)
Bezeichnung einer Dimension
Identifikationsschlüssel (PK)
Bezeichnung der Ebene
Verweis auf die zugehörende Dimension (Foreign Key
FK)
Verweis auf die nächsthöhere Aggregationsebene (FK)
Identifikationsschlüssel (PK)
Verweis auf die zugehörende Aggregationsebene (FK)
Verweis auf den nächsthöheren Dimensionswert, zu
dem dieser Wert zu aggregieren ist
Dimensionswert
Künstlicher Schlüssel zum Zusammenfassen zusammengehörender Werte (PK)
Verweis auf den zugehörenden Dimensionswert (PK)
Faktenwert oder NULL
Abb. 11: Erläuterung der Attribute des generischen Modells
Vorteil dieses vorgeschlagenen Ansatzes ist, daß Strukturänderungen am mehrdimensionalen
Datenwürfel – was nach [AnMu97] häufig vorkommen kann - nicht mit Strukturänderungen beim
logischen Datenmodell des Data Warehouse verbunden sind. Allerdings bedingt dieser Ansatz eine
größere Anzahl von Tupeln in der Faktentabelle und einen höheren Speicherplatzbedarf, was sich
aber durch die hardware-technologische Entwicklung relativieren dürfte.
Beispiel: Eine Faktentabelle nach Abb. 5 mit 10.000 Tupeln benötigt bei 2 Byte je Dimensions-Id
und 4 Byte je Kennzahlenwert insges. 10.000*(4*2+3*4)=200.000 Byte. Eine entsprechende
Tabelle nach Abb. 10 enthält 70.000 Tupel; 40.000 für die ursprünglichen Fremdschlüssel und
30.000 für die Faktenwerte. Unter der Annahme, daß eine Null-Eintrag 1 Byte benötigt, ergibt sich
ein Speicherbedarf von 40.000*5+30.000*8=440.000 Byte. Systembedingte Verwaltungsinformationen wie z. B. Indizes wurden dabei nicht betrachtet.
Die Offenheit des Ansatzes bedingt sicherlich eine höhere Komplexität. Genauere Aussagen
darüber können allerdings zum jetzigen Projektstand noch nicht gemacht werden. Dazu sind
umfangreiche Messungen mit größeren Datenbeständen im direkten Vergleich zur traditionellen
Starschema-Implementierung notwendig.
Die Tabelle „Aggregationsebene“ kann bei der Dimension Kennzahl benutzt werden, um eine
Unterscheidung in Ist- bzw. Soll-Werte vorzunehmen.
Problematisch ist die Behandlung verschiedener Datentypen bei den einzelnen Dimensionen bzw.
Aggregationsebenen. Im ersten Ansatz kann bei der Umsetzung in ein RDBMS für das Attribut
Dim-Wert als Typ CHAR() bzw. VARCHAR() gewählt werden. Bei einem rein numerischen
Wertebereich der Dimensionswerte kann ein entsprechender Datentyp gewählt werden.
7
Aktueller Projektstand und Ausblick
Im Wintersemester 1997/98 wurde für die Komponentenarchitektur ein experimenteller SmalltalkPrototyp realisiert, der die Anwendungskomponenten Partner, Vertrag, Wagnis und Produkt
enthielt. Gleichzeitig wurde von einer anderen Studentengruppe ein Prototyp eines Data Warehouse entwickelt und mit ca. 25.000 Fakten gefüllt; allerdings ohne Berücksichtigung des
generischen Ansatzes.
Im Sommersemester wurde damit begonnen, ein generisches Data Warehouse zu implementieren,
das sich an der vorgestellten Komponentenarchitektur orientiert. Die Entwicklung erfolgt mit Visual
Age for Java, einer JDBC-Schnittstelle und dem RDBMS Sybase.
Der vorliegende Artikel stellt einen Vorschlag und eine Diskussionsgrundlage für eine
Komponentenarchitektur
und
ein
generisches
Data
Warehouse
als
eine
der
Anwendungskomponenten dar. Die vorgestellten Konzepte für eine Data Warehouse gelten aber
auch für andere Systemarchitekturen. Allerdings sind noch viele offene Fragen zu klären. So stehen
z. B. Performance-Untersuchungen noch aus; auch die Frage eines automatischen Übergangs vom
Star-Schema zum generischen Datenmodell ist noch zu untersuchen. Wünschenswert wäre
letztendlich natürlich auch, die vorgeschlagenen Konzepte in einer praktischen, nicht-akademischen
Systemumgebung und mit größeren Datenbeständen testen zu können.
Danksagung
An der Entwicklung der Anwendungsarchitektur und des generischen Data Warehouse haben im
SEVERS-Projekt viele Studierende des Studiengangs Softwaretechnik an der FH Hamburg sehr
engagiert mitgearbeitet. An dieser Stelle herzlichen Dank. Mein besonderer Dank gilt meinem
Kollegen Herrn Prof. Dr. Jörg Raasch für seine Arbeiten zum Thema Komponentenarchitektur.
Dank auch an die Gutachter für ihre hilfreichen Anmerkungen.
Literaturverzeichnis
[AnMu97]
[Baye96]
[BeLi97]
[BeSc93]
[Boll96]
[ChGl98]
[Farn95]
[GDV96]
[GeRa96]
[Gerk97]
[Gluc96]
[HaBM97]
[Hahn98]
[Inmo96]
[JaGK96]
[KeFi98]
[KnHe95]
[Loos96]
Anahory, Sam; Murray, Dennis: Data Warehouse, Bonn - Reading 1997
Bayer, Rudolf: The Universal B-Tree for multidimensional Indexing, TU München
I9637, München 1996
Berry, Michael; Linoff, Gordon: Data Mining Techniques, New York 1997
Behme, Wolfgang; Schimmelpfeng, Katja (Hrsg.): Führungsinformationssysteme,
Wiesbaden 1993
Bollinger, Toni: Assoziationsregeln, Analyse eines Data Mining Verfahrens, in:
Informatik Spektrum 19 (1996) 5, S. 257 ff.
Chamoni, Peter; Gluchowski, Peter (Hrsg.): Analytische Informationssysteme, Berlin
- Heidelberg - New York 1998
Farny, Dieter: Versicherungsbetriebslehre, Karlsruhe 1995
Gesamtverband der Deutschen Versicherungswirtschaft (Hrsg.): VAA – Die
Anwendungsarchitektur der Versicherungswirtschaft, 2. Auflage, Bonn 1996
Gerken, Wolfgang; Raasch, Jörg: Anwendungsarchitektur der Versicherungswirtschaft (VAA) im Lichte der Objektorientierung, in: Versicherungswirtschaft 51
(1996) 8, S. 492 ff.
Gerken, Wolfgang: Data Warehouse – Datengrab oder Informationspool? in:
Versicherungswirtschaft 52 (1997) 8, S. 506 ff.
Gluchowski, Peter: Architekturkonzepte multidimensionaler Data-WarehouseLösungen, in: [MuBe96], S. 229 ff.
Hagedorn, Jürgen; Bissantz, Nicolas; Mertens, Peter: Data Mining: Stand der
Forschung und Entwicklung, in: Wirtschaftsinformatik 39 (1997) 6, S. 601 ff.
Hahne, Michael: Logische Datenmodellierung für das Data Warehouse, in:
[ChGl98], S. 103 ff.
Inmon, William: Building the Data Warehouse, New York 1996
Jahnke, Bernd; Groffmann, Hans-Dieter; Kruppa, Stephan: On-Line Analytical
Processing (OLAP), in: Wirtschaftsinformatik 38 (1996) 3, S. 321 ff.
Kemper, Hans-Georg; Finger, Ralf: Datentransformation im Data Warehouse, in:
[ChGl98], S. 61 ff.
Knolmeyer, Gerhard; Herbst, Holger: Ansätze zur Klassifikation von
Geschäftsregeln, in: Wirtschaftsinformatik 37 (1995) 2, S. 149 ff.
Loos, Peter: Geschäftsprozeßadäquate Informationssystemadaption durch generische
Strukturen, in: G. Vossen, J. Becker (Hrsg.), Geschäftsprozeßmodellierung und
Workflow-Management, Bonn 1996, S. 162 ff.
[MuBe96]
[Nakh98]
[Ohle96]
[Raas98]
[Reut96]
[Vets95]
Muksch, Harry; Behme, Wolfgang: Das Data-Warehouse-Konzept, Architektur –
Datenmodelle – Anwendungen, Wiesbaden 1996
Nakhaeizadeh, Gholamreza (Hrsg.): Data Mining, Heidelberg 1998
Ohlendorf, Thomas: Objektorientierte Datenbanksysteme für den Einsatz im DataWarehouse-Konzept, in: [MuBe96], S. 205 ff.
Raasch, Jörg: Eine Komponentenarchitektur für Versicherungsanwendungen, in:
Versicherungswirtschaft 53 (1998) 8, S. 514 ff.
Reuter, Andreas: Das müssen Datenbanken im Data Warehouse leisten, in:
Datenbank Fokus (1996) 2, S. 28 ff.
Vetschera, Ralf: Informationssysteme in der Unternehmensführung, Berlin Heidelberg - New York 1995