Workflowmanager. Provisionsermittlung. Text- Entkopplungs- und Schnittstellenschicht Systemplattform

Transkript

1 Ein generisches Data Warehouse im Kontext einer Anwendungsarchitektur Prof. Dr. Wolfgang Gerken Fachhochschule Hamburg FB Elektrotechnik/Informatik Berliner Tor Hamburg gerken@informatik.fh-hamburg.de Zusammenfassung Der Gesamtverband der Deutschen Versicherungswirtschaft e. V. hat eine Musterarchitektur für DV- Anwendungssysteme im Versicherungswesen entwickelt, auf deren Basis Softwarehäuser und Versicherungsunternehmen im Rahmen eines Komponentenmarktes modulare und adaptierbare 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 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-Anwendungs- Architektur VAA [GDV96]. Sie stellt als übergreifendes Konstruktionsprinzip und Referenzarchitektur einen begrüßenswerten softwaretechnischen Rahmen für Versicherungsanwendungen der Zukunft dar.

2 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 ARBEITSEBENE Parametersystem Datenmanager Tarifierung Workflowmanager DV-Vorgangsmanager Dialogmanager Deckungsprüfung Provisionsermittlung... ANWENDUNGSBAUSTEINE DIENSTEBENE Präsentationsdienste Berechtigungssysteverarbeitunbehandlung Text- Fehler-... Entkopplungs- und Schnittstellenschicht Systemplattform Abb. 1: Schichtenmodell eines VAA-konformen Anwendungssystems (vgl. [GDV96])

3 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 Anwendung B Komponente A Komponente B Partner Versicherungs- Vertrag Partner Versicherungs- Vertrag nehmer nehmer 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].

4 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) Workflow- Managers 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.

5 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. 4 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

6 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 = 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 Data- Warehouse-Bereich finden sich in [Ohle96]; Architekturkonzepte multidimensionaler Data- Warehouse-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].

7 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 Zeit Produkte Vertrieb KID Name... ZID Monat... PID Name... VID Bdir Otto 81 04/98 5 HUK 11 Hmb 14 Eva 6 LV...

8 Produktion KID ZID PID VID Policen BWE Provision 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. Kunden KID Region PLZ 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.

9 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. Produktion KID ZID PID VID Kennzahl Wert Policen BWE Provision 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. Produktion KEY Dimension ID Wert 1 Kunden 13-1 Zeit 81-1 Produkte 5-1 Vertrieb 11-1 Kennzahl Policen 2 1 Kennzahl BWE Kennzahl Provision 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.

10 Aggregations- Dimensions- Dimensionen ebenen werte 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 Aggregationsebene Dim-Id Name Ebene-Id Name Dim-Id Ober-Id 1 Zeit 1 Jahr 1-2 Produkt 2 Monat Vertrieb 3 Sparte 2-4 Kennzahl 4 Produkt Kunden 5 Bdir 3-6 Agentur Kennzahl 4-8 Region 5-9 PLZ 5 8 Dimensionswerte Werte-Id Ebene-Id OberWert-Id Dim-Wert / HUK Hmb / LV Policen BWE Provision Hmb-Mitte

11 Faktenwerte Gruppe DimWerte-Id Wert Abb. 10: Generisches, logisches Datenmodell eines mehrdimensionalen Datenwürfels Bedeutung und Inhalt der einzelnen Attribute können der folgenden Tabelle entnommen werden. Relation Attribut Beschreibung Dimension Dim-Id Identifikationsschlüssel (Primary Key PK) Name Bezeichnung einer Dimension Aggregationsebene Ebene-Id Identifikationsschlüssel (PK) Name Bezeichnung der Ebene Dim-Id Verweis auf die zugehörende Dimension (Foreign Key FK) Ober-Id Verweis auf die nächsthöhere Aggregationsebene (FK) Dimensionswerte Werte-Id Identifikationsschlüssel (PK) Ebene-Id Verweis auf die zugehörende Aggregationsebene (FK) OberWert-Id Verweis auf den nächsthöheren Dimensionswert, zu dem dieser Wert zu aggregieren ist Dim-Wert Dimensionswert Faktenwerte Gruppe Künstlicher Schlüssel zum Zusammenfassen zusammengehörender Werte (PK) DimWerte-Id Verweis auf den zugehörenden Dimensionswert (PK) Wert 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

12 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 Tupeln benötigt bei 2 Byte je Dimensions-Id und 4 Byte je Kennzahlenwert insges *(4*2+3*4)= Byte. Eine entsprechende Tabelle nach Abb. 10 enthält Tupel; für die ursprünglichen Fremdschlüssel und für die Faktenwerte. Unter der Annahme, daß eine Null-Eintrag 1 Byte benötigt, ergibt sich ein Speicherbedarf von * *8= 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 Smalltalk- Prototyp 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 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.

13 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] Anahory, Sam; Murray, Dennis: Data Warehouse, Bonn - Reading 1997 [Baye96] Bayer, Rudolf: The Universal B-Tree for multidimensional Indexing, TU München I9637, München 1996 [BeLi97] Berry, Michael; Linoff, Gordon: Data Mining Techniques, New York 1997 [BeSc93] Behme, Wolfgang; Schimmelpfeng, Katja (Hrsg.): Führungsinformationssysteme, Wiesbaden 1993 [Boll96] Bollinger, Toni: Assoziationsregeln, Analyse eines Data Mining Verfahrens, in: Informatik Spektrum 19 (1996) 5, S. 257 ff. [ChGl98] Chamoni, Peter; Gluchowski, Peter (Hrsg.): Analytische Informationssysteme, Berlin - Heidelberg - New York 1998 [Farn95] Farny, Dieter: Versicherungsbetriebslehre, Karlsruhe 1995 [GDV96] Gesamtverband der Deutschen Versicherungswirtschaft (Hrsg.): VAA Die Anwendungsarchitektur der Versicherungswirtschaft, 2. Auflage, Bonn 1996 [GeRa96] Gerken, Wolfgang; Raasch, Jörg: Anwendungsarchitektur der Versicherungswirtschaft (VAA) im Lichte der Objektorientierung, in: Versicherungswirtschaft 51 (1996) 8, S. 492 ff. [Gerk97] Gerken, Wolfgang: Data Warehouse Datengrab oder Informationspool? in: Versicherungswirtschaft 52 (1997) 8, S. 506 ff. [Gluc96] Gluchowski, Peter: Architekturkonzepte multidimensionaler Data-Warehouse- Lösungen, in: [MuBe96], S. 229 ff. [HaBM97] Hagedorn, Jürgen; Bissantz, Nicolas; Mertens, Peter: Data Mining: Stand der Forschung und Entwicklung, in: Wirtschaftsinformatik 39 (1997) 6, S. 601 ff. [Hahn98] Hahne, Michael: Logische Datenmodellierung für das Data Warehouse, in: [ChGl98], S. 103 ff. [Inmo96] Inmon, William: Building the Data Warehouse, New York 1996 [JaGK96] Jahnke, Bernd; Groffmann, Hans-Dieter; Kruppa, Stephan: On-Line Analytical Processing (OLAP), in: Wirtschaftsinformatik 38 (1996) 3, S. 321 ff. [KeFi98] Kemper, Hans-Georg; Finger, Ralf: Datentransformation im Data Warehouse, in: [ChGl98], S. 61 ff. [KnHe95] Knolmeyer, Gerhard; Herbst, Holger: Ansätze zur Klassifikation von Geschäftsregeln, in: Wirtschaftsinformatik 37 (1995) 2, S. 149 ff. [Loos96] 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.

14 [MuBe96] Muksch, Harry; Behme, Wolfgang: Das Data-Warehouse-Konzept, Architektur Datenmodelle Anwendungen, Wiesbaden 1996 [Nakh98] Nakhaeizadeh, Gholamreza (Hrsg.): Data Mining, Heidelberg 1998 [Ohle96] Ohlendorf, Thomas: Objektorientierte Datenbanksysteme für den Einsatz im Data- Warehouse-Konzept, in: [MuBe96], S. 205 ff. [Raas98] Raasch, Jörg: Eine Komponentenarchitektur für Versicherungsanwendungen, in: Versicherungswirtschaft 53 (1998) 8, S. 514 ff. [Reut96] Reuter, Andreas: Das müssen Datenbanken im Data Warehouse leisten, in: Datenbank Fokus (1996) 2, S. 28 ff. [Vets95] Vetschera, Ralf: Informationssysteme in der Unternehmensführung, Berlin - Heidelberg - New York 1995