III.5. vollständige (zweidimensionale - GDV

Gesamtverband der Deutschen
Versicherungswirtschaft e.V.
Prozesse
Objekte
Funktionen
Daten
Komponenten
Request Broker
VA A
Edition
1999
Die Anwendungsarchitektur der Versicherungswirtschaft
DATENMANAGER / ANHANG
VERSION 2.1
PROZEDURAL
© GDV 1999
http://www.gdv.de/vaa
Autoren:
Projektteam "Datenmanager"
Administration, Koordination: Gesamtverband der Deutschen Versicherungswirtschaft e.V., Berlin
http://www.gdv.de/vaa
© GDV 1999
Datenmanager / Anhang
Willkommen bei VAA Edition 1999!
Liebe Leserin, lieber Leser,
haben Sie bereits eine der Broschüre der VAA Edition 1999 gelesen? Wenn ja, können Sie gleich
weiter blättern, denn dieses Kapitel steht gleichlautend am Anfang jedes VAA-Dokuments dieser
Ausgabe.
Ansonsten freuen wir uns über Ihr Interesse an der VAA und gratulieren Ihnen zu Ihrer Entscheidung,
sich mit diesem Thema zu beschäftigen, an dem wir seit Jahren mit großem Engagement und immer
noch mit viel Spaß arbeiten.
Mit WIR sind alle gemeint, die sich in den letzten Jahren direkt an der Arbeit in den VAA-Gremien
beteiligten. Um wen es sich dabei im einzelnen handelt, können Sie in einem Anhang der Broschüre
ANFORDERUNGEN UND PRINZIPIEN nachlesen, darüber hinaus werden die VAA-Gremien auf der neuen
VAA-CD und im Internet (http://www.gdv.de/vaa) vorgestellt.
Nun zur Sache:
Die VAA wurde in den vergangenen zwei Jahren in zwei Richtungen weiterentwickelt.

Der erste Schritt in Richtung Objektorientierung ist getan. Sie finden in der VAA Edition 1999 das
OBJEKTORIENTIERTE FACHLICHE
REFERENZMODELL und das OBJEKTORIENTIERTE TECHNISCHE
REFERENZMODELL der VAA. Das Geschäftsobjekt PRODUKT wurde bereits detailliert ausgearbeitet.

Die prozedurale Variante lebt weiter. Sie wurde ergänzt um eine weitere fachliche Komponente,
INKASSO/KONTOKORRENT.
Darüber hinaus wurden die aufgrund der Aufnahme der Objektorientierung notwendig gewordenen
Überarbeitungen und Ergänzungen der Dokumente der 2. Auflage von VAA vorgenommen. Es
entstand eine Vielzahl von zum Teil sehr umfangreichen Dokumenten, die auf drei Wegen
veröffentlicht werden: CD-ROM, Internet und als gebundene Broschüren in Papierform.
Um Ihnen die Orientierung zu erleichtern, haben wir als Übersicht über die verfügbaren
Dokumentationen der VAA Edition 1999 einen grafischen Wegweiser erstellt, den Sie auf der
nächsten Seite finden können. Vielleicht hilft er Ihnen, sich zurechtzufinden und Ihre
Schwerpunktthemen "herauszufischen".
Viel Spaß beim Studium des hier und in den übrigen Dokumenten zusammengestellten VAA-Wissens.
© GDV 1999
http://www.gdv.de/vaa
Datenmanager / Anhang
Dokumentenstruktur der VAA Edition 1999
Anforderungen und Prinzipien
neu
Glossar
überarbeitet
VAA prozedural (pVAA) Version 2.1
Prozeduraler Rahmen
neu
Fachliche Beschreibung
Inkasso/Kontokorrent
neu
Partner
Partner/Anhang
Provision
überarbeitet
Schaden/Leistung
Vertrag
Technische Beschreibung
Datenmanager
Datenmanager/Anhang
Dialogmanager
Parametersystem
Workflow-/Vorgangsmanager
VAA objektorientiert (oVAA) Version 1.0
Objektorientiertes fachliches Referenzmodell
Hauptdokument
neu
Anhang A – Use-Case-Modell –
neu
Anhang B – Klassenmodell –
neu
Modell in Rational-Rose-Format
neu
Objektorientiertes technisches Referenzmodell
neu
Produkt
neu
http://www.gdv.de/vaa
© GDV 1999
Datenmanager / Anhang
I.
Inhalt
Das Verhältnis Database Middleware zum VAA-Datenmanager ....................... 3
I.1.
Database Middleware: Definition und Zielsetzung ........................................................................ 3
I.1.1.
Der Translation Layer............................................................................................................ 4
I.1.2.
Der Communication Layer .................................................................................................... 5
I.1.3.
Der Management Layer ........................................................................................................ 5
I.1.4.
Database Middleware ........................................................................................................... 5
I.2.
Standards und de-facto-Standards ............................................................................................... 7
I.2.1.
Microsoft’s Open Database Connectivity ODBC ................................................................... 7
I.2.1.1.
Architektur ......................................................................................................................... 8
I.2.1.2.
Anwendungsgebiete .......................................................................................................... 9
I.2.1.3.
Einschränkungen ............................................................................................................ 10
I.2.1.4.
Entscheidungskriterien für eine Verwendung von ODBC ................................................ 11
I.2.2.
IBM’s Distributed Relational Database Architecture DRDA ................................................. 12
I.2.3.
ISO/ANSI’s Remote Data Access Standard RDA ............................................................... 12
I.2.4.
SQL Access Group’s RDA .................................................................................................. 12
I.2.5.
Borland’s Integrated Database API Archtecture IDAPI ....................................................... 13
I.2.6.
Apple’s Data Access Language Standard DAL ................................................................... 13
I.3.
Abgrenzung zum Datenmanager VAA ........................................................................................ 14
I.4.
Produkte...................................................................................................................................... 15
I.4.1.
DataJoiner von IBM............................................................................................................. 15
I.4.2.
Natural Active View von Software AG ................................................................................. 17
I.4.3.
OpenDM von Siemens Nixdorf ............................................................................................ 19
I.4.4.
DBA von Siemens Nixdorf ................................................................................................... 22
I.4.5.
ComUnity OT-Framework von Siemens Nidorf ................................................................... 24
I.4.6.
SYBASE Client/Server Produkts ......................................................................................... 27
I.4.7.
Der Datensichtprozessor der Württembergischen Versicherung......................................... 29
I.4.8.
Weitere ................................................................................................................................ 30
II. Technologische Aspekte - insbesondere Objektorientierung ......................... 30
II.1.
Komponentenorientierung und Objektorientierung ...................................................................... 30
II.1.1.
Was ist eine Komponente, ein Objekt? ............................................................................... 32
II.1.2.
Common Object Requets Broker der OMG ......................................................................... 33
II.1.2.1.
Object Management Architecture ................................................................................ 33
II.1.2.2.
Common Object Request Broker Architecture ............................................................ 35
II.1.2.3.
ORB-Implementierungen im Vergleich ........................................................................ 36
II.1.3.
Object Linking and Embedding ........................................................................................... 38
II.1.4.
Bewertung ........................................................................................................................... 40
II.2.
Objektorientierte Modellierung und objektorientierte Datenhaltungstechnologien ....................... 41
II.2.1.
E/R-Modellierung und objektorientierte Modellierung.......................................................... 41
II.2.2.
Der VAA-Datenmanager im Vergleich zu objektorientierten und relationalen
Datenbankmanagementsystemen ...................................................................................................... 45
II.2.3.
Objektorientierte Zugriffsschichten zu relationalen Datenbankystemen .............................. 47
II.2.3.1.
© GDV 1999
Probleme des Paradigmen-Wechsels ......................................................................... 47
i
Inhalt
Datenmanager / Anhang
II.2.3.2.
Komplexe Datentypen ................................................................................................. 47
II.2.3.3.
Objekt-Identität ............................................................................................................ 48
II.2.3.4.
Beziehungen zwischen Objekten ................................................................................ 49
II.2.3.5.
Vererbung und Polymorphismus ................................................................................. 49
II.2.3.6.
Allgemeine Probleme .................................................................................................. 50
II.2.3.7.
Transaktionskonzept ................................................................................................... 50
II.2.3.8.
Transparenz bei der Programmierung ......................................................................... 51
II.2.3.9.
ODMG-Verträglichkeit ................................................................................................. 51
II.2.4.
Beispielhafte Modellierung bei einer Versicherung .............................................................. 52
II.2.5.
VAA-Datenmanager: Warum nicht alles in objektorientierter Technologie .......................... 52
III.
Vorschläge zur Realisierung von Historienkonzepten ................................. 53
III.1.
Einleitung und Problemstellung ............................................................................................... 53
III.2.
Der Änderungsbaum einer Entität ........................................................................................... 54
III.3.
Der Begriff der Historie ............................................................................................................ 56
III.4.
Die (eindimensionale) Abschnittshistorie ................................................................................. 56
III.4.1.
Die lückenlose Abschnittshistorie ........................................................................................ 57
III.4.2.
Beispiele für Abschnittshistorien .......................................................................................... 58
III.4.3.
Realisierung im Relationenschema ..................................................................................... 58
III.4.4.
Überlagerungskonflikte einer Abschnittshistorie .................................................................. 58
III.4.5.
Grundoperationen einer Abschnittshistorie.......................................................................... 59
III.4.6.
Abgeleitete Operationen einer Abschnittshistorie ................................................................ 60
III.4.7.
Konsistenzwahrende Operationen einer Abschnittshistorie................................................. 62
III.5.
vollständige (zweidimensionale) Historisierung ....................................................................... 64
III.5.1.
Beispiele .............................................................................................................................. 66
III.5.2.
Beispieloperationen ............................................................................................................. 66
III.6.
Vereinfachung des allgemeinen Verfahrens aus praktischer Sicht.......................................... 67
III.6.1.
III.6.1.1.
Tabellenorientierte Speicherung .................................................................................. 69
III.6.1.2.
Beispiele ...................................................................................................................... 74
III.7.
IV.
ii
Vorschlag zur Umsetzung des Historienkonzepts ............................................................... 68
Realisierungsmöglichkeiten ..................................................................................................... 79
III.7.1.
Historisierung in einer Tabelle ............................................................................................. 79
III.7.2.
Historisierung mit einer Archivtabelle .................................................................................. 80
III.7.3.
Die Vorgangstabelle ............................................................................................................ 80
Literaturverzeichnis ........................................................................................ 81
© GDV 1999
Datenmanager / Anhang
Das Verhältnis Database Middleware zum VAA-Datenmanager
Anhang zur Spezifikation des
Datenmanagers
In diesem Anhang wird auf Themen eingegangen, die nicht unmittelbar die Spezifikation des
Datenmanagers betreffen, aber in enger Beziehung zu ihm stehen, z.B. indem sie helfen, seine
Aufgabe innerhalb der VAA durch Vergleich mit am Markt verfügbaren Database-MiddlewareProdukten besser positionieren zu können oder Stellung zu technologischen Trends wie der
Objektorientierung zu beziehen. Einen weiteren Schwerpunkt bilden Vorschläge zur Realisierung von
Historienkonzepten.
I. Das Verhältnis Database Middleware zum
VAA-Datenmanager
I.1. Database Middleware: Definition und Zielsetzung
Unter Database Middleware werden Produkte oder Produktkomponenten verstanden, die dazu dienen,
eine „einheitliche Datenverwaltungsschnittstelle“ für die Entwicklung von Anwendungen zur
Verfügung zu stellen. Die gebotene Funktionalität isoliert die sie nutzende Anwendung beispielsweise
von Aspekten wie dem konkret zur Datenspeicherung verwendeten Datenbankmanagementsystem wie
z.B. DB2, Oracle oder Informix, dem Dateisystem, der Betriebssystemplattform oder gar Aspekten
verteilter Datenhaltung. Die Database Middleware bildet eine Isolationsschicht, auf der Anwendungen
unter verschiedensten Aspekten portabel implementiert werden können.
Der Begriff der Middleware allgemein ist im Zusammenhang mit verteilter Verarbeitung in
heterogenen Systemumgebungen aufgekommen. Es galt, die Probleme unterschiedlicher Plattformen,
unterschiedlicher APIs, unterschiedlicher Kommunikationsprotokolle für den Anwender so einfach
und sicher wie möglich zu machen. Dadurch, daß von verschiedensten Herstellern MiddlewareProdukte angeboten werden, die diese Probleme der Heterogenität teilweise reduzieren, sich die unterschiedlichen Produkte aber oft nicht ergänzen, sondern gegenseitig ausschließen, ist große Verwirrung
entstanden. Zur besseren Positionierung unterschiedlicher Middleware hilft das Ovum „model of
middleware“ [OvumMi95]:
© GDV 1999
3
Inhalt
Datenmanager / Anhang
Driver
Translation Layer
Management Layer
Gateway
Communication Layer
Network
transport
protocols/API
Transport Provider
Abb.: The Ovum model of middleware
I.1.1. Der Translation Layer
Haben Basisprodukte unterschiedliche APIs, so kann durch einen Translation Service und
Bereitstellung eines APIs die Komplexität für den Anwendungsentwickler reduziert und die
Interoperabilität der Anwendung wesentlich verbessert werden. Die Aufgaben des Translation
Layers sind deshalb:

Verbesserte Interoperabilität zwischen heterogenen Software-Produkten

Verbesserte Anpaßbarbeit von Applikationen an zugrundeliegende Basisprodukte

Reduktion der Komplexität in heterogenen Umgebungen durch Reduktion der APIs für den
Anwendungsentwickler
Viele Middleware-Produkte zielen genau auf diesen Translation Layer. Sie übersetzen ein API in das
Format eines anderen APIs. Beispiel aus dem Datenbank-Bereich: Wird z.B. ODBC als API für die
Schnittstelle zur Datenbank verwendet, so übersetzt spezifische Middleware (ODBC-Treiber) die
ODBC-Aufrufe in Aufrufe für das native API des zugrundeliegenden Datenbankmanagementsystems.
Die Anwendung verwendet so ein API und läuft (theoretisch) mit allen Datenbankmanagementsystemen, für die es einen ODBC-Treiber gibt. In der Praxis ist die Verwendung solcher Middleware
jedoch mit Einschränkungen verbunden.
4
© GDV 1999
Datenmanager / Anhang
Das Verhältnis Database Middleware zum VAA-Datenmanager
I.1.2. Der Communication Layer
Der Communication Layer schafft dem Anwendungsentwickler durch Bereitstellung einer virtuellen
Maschine Transparenz bzgl. Verteilung, zugrundeliegender Netzprotokolle usw. Der Communication
Layer schalt unterschiedlichste Netzsoftware ein und übernimmt die folgenden Aufgaben:

Datenkonvertierung in Übertragungsformate, Packetierung

Konformität mit dem Netzprotokoll herstellen

Adressierung

Aufbau und Überwachung der Verbindung zwischen Sender und Empfänger

Fehlerbehandlung der von der Netzsoftware gemeldeten Fehler
Gateways stellen eine Kombination von Translation Services und Communication Services dar. Sie
ermöglichen die Kommunikation von unterschiedlichen Netzwerkprodukten, indem sie die NetwerkProtokolle umsetzen. Während ein Datenbank-Treiber die reine Übersetzung von einem API in ein
anderes vornimmt, bewerkstelligen Datenbank-Gateways zusätzlich die Übertragung von Aufrufen im
Netz.
I.1.3. Der Management Layer
Der Management-Layer stellt eine Erweiterung des Communication Layers zum Zwecke des
Managements der verteilten Verarbeitung zur Verfügung. Typische Dienste des Management Layers
sind:

directory service

security service

guaranteed delivery service

exception handling, fault and problem management service

time service

synchronisation service

threads service

multi-tasking service ...
Middleware-Produkte, die neben den Communication Services auch Management Services beinhalten
sind ORB-Implementierungen, DCE-Middleware oder Transaktionsmonitore.
I.1.4. Database Middleware
Unter Database Middleware Produkten werden hauptsächlich Produkte verstanden, die sich im
Translation- und im Communication Layer (in der Zeichnung grau hinterlegt) positionieren. Vielfach
wird Middleware mit Database Middleware gleichgesetzt, was aber eine einseitige Reduktion der
© GDV 1999
5
Inhalt
Datenmanager / Anhang
Sichtweise auf die Isolationsschicht zwischen Applikation und Datenbank hin darstellt. Eine gute
Übersicht über Middleware allgemein findet sich in [1].
Die möglichen Vorteile des Einsatzes von Database Middleware Produkten liegen auf der Hand:
bessere Qualität der Anwendungen durch Reduktion der APIs und Komplexität in den
Anwendungskomponenten und - damit verbunden - geringere Implementierungsaufwände.
Problematisch ist der Einsatz von Database Middleware Produkten immer dann, wenn besondere
Eingenschaften bestimmter Datenbankmanagementsysteme zum Tragen kommen. Denn mit der
Umsetzung von Formaten oder den syntaktischen Unterschieden von SQL-Dialekten allein ist es nicht
getan. Unterschiedliche Datenbankmanagementsysteme haben entsprechend ihrer Historie und
Positionierung am Markt entsprechend unterschiedliche Konzepte implementiert und verhalten sich im
Detail dementsprechend anders. Es muß den Anwendungsentwicklern klar sein, daß völlige
Transparenz bzgl. der zugrundeliegenden Datenbankmanagementsysteme nicht möglich ist.
Typischerweise treten Unterschiede auf bei:

der Implementierung von Integritätsbedingungen

der Art des Datenzugriffs (mengenorientiert, navigierend, ...)

stored procedures

Locking und Vermeidung von Deadlock-Situationen

der Verwendung von dynamic SQL oder static SQL
Abhängig von den Mengengerüsten bildet dynamisches SQL einen potentiellen Performance-Engpaß
(bei großen Datenbanken) oder ist eher unkritisch im Vergleich zu anderen
Architekturentscheidungen. Database Middleware Produkte müssen vor ihrem Einsatz deshalb
unbedingt daraufhin untersucht und getestet werden, ob sie die erforderliche Effizienz im Datenzugriff
noch gewährleisten.
Deshalb werden in [OvumMi95] folgende Empfehlungen ausgesprochen:
Database Middleware Produkte können tendenziell verwendet werden, wenn



Daten auf mehrere Datenbanken oder unterschiedliche Datenbankmanagementsysteme verteilt sind
und über ein einheitliches API zugegriffen werden soll,
keine kritischen Antwortzeiten bestehen, insbesondere kurze Antwortzeiten bei komplexen Joins
über mehrere Datenbankmanagementsysteme verlangt werden,
keine Zugriffe auf nicht-standardisierte Datentypen wie Images, BLOBs usw. erfolgen.
Entsprechend sollten Database Middleware Produkte tendenziell nicht eingesetzt werden

im Hochleistungsbetrieb, bei sehr hohen Transaktionsraten oder großen Datenmengen,

bei großen Datenbank-übergreifenden Joins,

wenn sehr kurze Antwortzeiten gefordert sind,

wenn die Applikationen extensiven Gebrauch von stored procedures machen.
6
© GDV 1999
Datenmanager / Anhang
Das Verhältnis Database Middleware zum VAA-Datenmanager
Bezogen auf das Ziel der Transparenz des Datenzugriffs für die Anwendungen gelten dieselben
Argumente im Prinzip auch für 4GL-Umgebungen. Denn sie nutzen gerade die Database Middleware
zur Realisierung der Datenbankunabhängigkeit.
I.2. Standards und de-facto-Standards
Die wesentlichen Standards für remote database access, die im Folgenden kurz vorgestellt werden,
sind (vgl. [OvumMi95]):

ODBC

DRDA

ISO/ANSI RDA

SQL Access RDA

IDAPI

DAL (Database Access Language)
I.2.1. Microsoft’s Open Database Connectivity ODBC
ODBC ist Microsofts strategische Schnittstelle für den Zugriff auf im Prinzip beliebige
Datenbankmanagementsysteme. Es basiert auf dem CLI (call-level interface) der SQL Access Group
und verwendet entsprechend dynamic SQL.
Wenn auch ODBC primär ein Interface für Window-Applikationen ist, so gibt es mittlerweile auch
ODBC-Treiber für Apple und Unix-Systeme. Es ist zu erwarten, daß sich ODBC zu einem der
bedeutenden Standards für den Datenzugriff entwickelt und immer mehr Middleware-Produkte für
ODBC am Markt angeboten werden.
Da ODBC auf dynamic SQL basiert, gibt es immer wieder Diskussionen bzgl. möglicher oder
tatsächlicher Performance-Probleme. Grundsätzliche Wertungen lassen sich aber kaum abgeben.
Entscheidend sind vielmehr der jeweilige Anwendungsfall (Art des Datenzugriffs, Mengen, weitere
Verarbeitung) und die ausgewählte ODBC-Middleware.
© GDV 1999
7
Inhalt
Datenmanager / Anhang
I.2.1.1. Architektur
ODBC wurde für Client/Server-Architekturen entwickelt und optimiert. Ziel einer Client/ServerArchitektur ist die flexible Verteilung von Anwendungssystemen incl. Datenbasis auf den Client und
ein oder mehrere Server, die durch ein Netzwerk miteinander verbunden sind. Dadurch wird es
notwendig, die Schnittstellen zwischen Client und Server nicht nur so einfach wie möglich zu halten.
Ein weiterer wesentlicher Faktor in Client/Server-Systemen ist die Portabilität der Anwendungen, da
im Gegensatz zu Mainframe-Systemen häufiger Veränderungen in der Konfiguration vorgenommen
werden müssen. Nicht nur Clients und Server werden ausgetauscht, sondern auch die Datenbasen und
ggf. die Verteilung der Anwendung verändert. Daher sollten die Schnittstellen möglichst standardisiert
werden.
ODBC stellt einen solchen Standard dar. Es unterstützt die benötigte Flexibilität z.B. dadurch, daß es
dynamic SQL benutzt. Doch im Gegensatz zu der Verwendung von eingebettetem SQL muß das
Anwendungsprogramm nicht mit dem Precompiler des DBMS-Herstellers kompiliert werden, der
daraus DBMS-spezifische Funktionsaufrufe generiert. Stattdessen ermöglicht die Verwendung eines
CLI die Erstellung von DBMS-spezifischen Datenbank-Treibern, die dynamisch eingebunden werden
können. Dennoch bietet ODBC größtenteils dieselbe Funktionalität wie eingebettetes SQL mit ein
paar Ausnahmen:




Mangel an Unterstützung für die einfache Select-Anweisung in eingebettetem SQL. Daher können
Performance-Verluste auftreten.
eine Unterstützung von statischem SQL wird nur durch das Paradigma der gespeicherten
Prozeduren (stored procedures) unterstützt.
ODBC unterscheidet sich von SQL in der Cursor-Verwaltung. Dadurch ergeben sich Vorteile für
Ad-hoc-Abfragewerkzeuge und Nachteile in Anwendungsprogrammen.
ODBC ist bei der Zuordnung von Programmvariablen zu Ausgabespalten komplizierter
handhabbar.
Die ODBC-Architektur besteht aus folgenden Komponenten:
ODBC-konforme Applikation
Sie führt die ODBC-Aufrufe aus, stellt SQL-Statements zur Verfügung und bearbeitet die Ergebnisse
des Datenzugriffs. Bei der Erstellung der Anwendung ist es nicht notwendig, zu wissen, welche
Datenbanksysteme die Daten zur Verfügung stellen. Die Datenhaltung wird über „logische“ Namen
angesprochen.
ODBC-Treibermanager
Der Treiber-Manager verwaltet die Interaktionen zwischen den Anwendungsprogrammen und den
Datenbanktreibern. Er kann mehrere Anwendungen und mehrere Treiber gleichzeitig verwalten. Er
kann Treiber dynamisch laden und entladen.
ODBC-Treiber
8
© GDV 1999
Datenmanager / Anhang
Das Verhältnis Database Middleware zum VAA-Datenmanager
Der ODBC-Treiber verarbeitet die ODBC-Funktionsaufrufe, übersetzt die Abfrage, in die eigentliche
Datenbank-Syntax , liefert diese Abfragen an die bestimmte Datenquelle und gibt die Ergebnisse des
Zugriffs an das Anwendungsprogramm zurück. ODBC-Treiber sind abhängig von der Version des
DBMS.
Datenquelle
Eigentliche, physische Datenablage
ODBC-Treibermanager und ODBC-Treiber erscheinen für das Anwendungsprogramm als eine
Einheit, die die ODBC-Aufrufe vollständig bearbeitet. ODBC ordnet die Datenquelle dem Treiber, der
Netzwerksoftware, dem Server oder der Adresse und dem Kontext innerhalb des DBMS zu.
Außerdem enthält es Zugriffsschutz-Funktionalität.
Die Verwendung des Standards erleichtert nicht nur die Portabilität der ihn nutzenden Anwendungen.
Je häufiger ein Standard genutzt wird, umso wahrscheinlicher ist auch seine nutzergerechte
Weiterentwicklung.
Die ODBC-Treiber werden in der Regel von den Herstellern der Datenbank-Managementsysteme zur
Verfügung gestellt. Da diese ihr Produkt am besten kennen, können sie die Anforderungen der
Anwender an die Ausführung der ODBC-Aufrufe am optimalsten für ihr System umsetzen. Außerdem
verbessert die Verfügbarkeit eines ODBC-Treibers die Marktchancen für die DBMS-Hersteller, da
Anwendungen dadurch leichter auf ihr Produkt portierbar sind. Wenn es für ein DBMS eine Vielzahl
von Applikationen gibt , wird das DBMS attraktiver.
Sicht der DBMS-Hersteller auf ODBC
Eigentlich widerspricht ein ODBC-Treiber und eine Standardschnittstelle dem Bedürfnis der
Hersteller von Datenbanksystemen, seine Kunden an sein DBMS zu binden. Wenn z. B. ein Kunde ein
eigenes Interface geschaffen hat, will er dieses auch so häufig wie möglich nutzen. Doch wird heute
vom Markt eine Datenbank-Connectivity verlangt und ein Hersteller, der dieses Bedürfnis nicht zu
befriedigen vermag, hat mit Markteinbußen zu rechnen.
I.2.1.2. Anwendungsgebiete
Durch die Verwendung der ODBC-Schnittstelle ist das Anwendungsprogramm unabhängig von dem
oder den für die Datenzugriffe genutzten Datenbanksystemen., sofern für diese ein ODBC-Treiber
existiert. Der Anwendungsprogrammierer, der das ODBC-API nutzt, braucht keine eigene DBSchnittstelle zu schreiben und die internen Datei- und Indexformate des verwendeten DBMS für
dessen Nutzung nicht zu kennen. ODBC reduziert daher die Komplexität der Anwendungsentwicklung
in heterogenen Umgebungen für die Anwendungsprogrammierer erheblich. Außerdem verbessert es
die Interoperabilität zwischen heterogenen Software-Produkten und die Anpaßbarkeit von
Anwendungssystemen an zugrundeliegende Basisprodukte.
ODBC kann folgende Zielsetzungen unterstützen:

Der Programmierer soll auf einfache Art Anwendungen schreiben können, die unterschiedliche
Datenbanksysteme gleichzeitig nutzen. Vorzugsweise sind dies relationale DB-Systeme, obwohl
auch PC-Datenbanken, hierarchische Datenbanken usw. nicht ausgeschlossen sind. Er setzt dazu
© GDV 1999
9
Inhalt
Datenmanager / Anhang
ein herstellerunabhängiges API ein. Dieses bewahrt ihn davor, die internen Datei- und
Indexformate des verwendeten DBMS zu kennen und sogar ggf. eine eigene DB-Schnittstelle
schreiben zu müssen.




Dasselbe Entwicklungswerkzeug soll für unterschiedliche Datenbankentwicklungen benutzt
werden können, da die Kosten-Nutzen Relation umso besser ist, je häufiger ein
Entwicklungswerkzeug verwendet wird.
Es sollen Datenänderungen an verschiedene Datenbanksysteme auf unterschiedlichen Plattformen
weitergereicht werden. Obwohl diese Problemstellung mit einer Vervielfältigung sauberer gelöst
werden könnte, ist die Nutzung einer gemeinsamen API leichter pflegbar.
Entwicklung von verteilten Anwendungen mit Zugriff auf mehrere Datenbanksysteme, z.B. mit
lokalen und serverbasierten Datenspeichern im endgültigen Produktionssystem. dieser Fall tritt z.B.
bei Vertriebsinformationssystemen auf, wo individuelle Datensammlungen und
Datenbearbeitungen auf Notebook-Computern durchgeführt werden und diese lokalen Daten
beispielsweise über Nacht auf gemeinsamen Servern synchronisiert werden müssen.
Rapid Application Development (RAD): Während der Entwicklung des evolutionären Prototyps
kann der Entwickler mit einer lokalen Datenbasis auf seinem PC arbeiten, die Zielumgebung ist
jedoch eine Datenbank auf dem Server. Durch die Verwendung der ODBC-API muß die
Anwendung hierfür nach Abstimmung und Tests des Prototyps nicht mehr angepaßt werden.
I.2.1.3. Einschränkungen
Es gibt jedoch unterschiedliche ODBC-Conformance Standards. Dies sind unterschiedliche
Funktionalitätsgruppen zur Unterstützung der Anwendungs- und Treiberentwickler. Ein Treiber einer
bestimmten Konformitätsstufe garantiert, mindestens die Funktionen der angegebenen
Konformitätsstufe zu unterstützen, kann jedoch auch mehr unterstützen. Die Konformitätsstufe stellt
damit eine Richtschnur dar und engt die Funktionalität des Angebots nicht ein. Welche Funktionen
noch zusätzlich angeboten werden, kann von der Anwendung abgefragt werden.


API Function Level (Core API, Level 1 API, Level 2 API)
SQL Grammar Conformance (Minimum SQL Grammar Level, Core SQL Grammar Level,
Extended SQL Grammar Level)
Die meisten DBMS-Hersteller bieten Treiber für Core und Level 1 an. Die normalen Anwendungen
verlangen Level 1.
Die Anwendungsentwickler müssen sich entscheiden, welches Level sie benutzen wollen oder
müssen. Dies hängt einerseits von den fachlichen Anforderungen an die Anwendung, andererseits an
die Anforderungen an Portabilität, Flexibilität etc. ab. Die Treiberentwickler (Hersteller) müssen sich
entscheiden, welches Level sie anbieten wollen oder können. Dies hängt selbstverständlich von den
Möglichkeiten ihres DBMS ab.
Datenbanksysteme unterscheiden sich in:

der Implementierung von Integritätsbedingungen

der Art des Datenzugriffs (mengenorientiert, satzorientiert)
10
© GDV 1999
Datenmanager / Anhang
Das Verhältnis Database Middleware zum VAA-Datenmanager

stored procedures

Locking und Vermeidung von Deadlock-Situationen

der Verwendung von dynamic oder static SQL.
ODBC kann für den Zugriff auf alle Arten von Datenbanken verwendet werden. Das
Programmiermodell ist jedoch besser geeignet für relationale Datenbanksysteme als für PCDatenbanken oder ISAMs. Voraussetzung ist nur, daß die Daten in Zeilen und Spalten modelliert
werden können. ODBC kann sogar für dateiorientierte Datenspeicher wie etwa Tabellenkalkulationen
oder Textdateien eingesetzt werden.
Relationale Datenbanksysteme:



Beispiele sind: Sybase, Oracle, Gupta, DB2, DB2/2, RDB, Informix, Ingres, Microsoft SQL Server
Die meisten dieser Datenbanken können nicht „durchblättert“ werden, d.h. es wird noch kein
Scrolling nach dem SQL-92-Standard angeboten. Daher ist es auch nicht möglich, von einer
Ergebnismenge aus weiterzusuchen.
Die Daten sind in Tabellen abgelegt.
PC- oder Desktop-Datenbanken



Beispiele sind: Btrieve, dBase, Paradox, Microsoft Access, FoxPro
Viele Desktop-Datenbanken unterstützen die eine oder andere Form von SQL, aber in der Regel
erfolgt die Interaktion mit den Daten satzorientiert. Es handelt sich um eine Kombination von
ISAM- und 4GL-Konzepten: Befehle für den Datenzugriff nach dem ISAM-Paradigma kombiniert
mit Bildschirm-I/O-Befehlen.
Das SQL-Modell kann eingesetzt werden. Allerdings ergibt sich ein gewisser Verlust an
Funktionalität, Performance und Flexibilität.
Index-basierte Datenhaltungssysteme


Beispiele sind: IMS, VSAM, ISAM
Die Operationen, die auf diesen Datenhaltungssystemen ausgeführt werden, können in SQL nicht
besonders gut nachgebildet werden, wenn überhaupt. Der Grund ist, daß SQL mengenorientiert
arbeitet, ISAM-Funktionen jedoch sind zeilen- bzw. satzorientiert.
I.2.1.4. Entscheidungskriterien für eine Verwendung von ODBC
ODBC sollte verwendet werden, wenn



ein flexibler Austausch insbesondere von relationalen Datenbanken notwendig ist
weitergehende Unabhängigkeit von eingesetzten Datenbanksystemen und DBMS-Herstellern
angestrebt wird
keine DBMS-Funktionalität verwendet werden sollte, die durch den für das DBMS angebotenen
Treiber nicht unterstützt wird
© GDV 1999
11
Inhalt

Datenmanager / Anhang
keine kritischen Antwortzeiten, insbesondere kurze Antwortzeiten bei komplexen Joins über
mehrere DBMSen benötigt werden

die Verwendung von ODBC-fähigen Entwicklungswerkzeugen angestrebt wird

in der Entwicklungs- und Produktionsumgebung unterschiedliche DBMSen eingesetzt werden


die Entwicklung der benötigten Anwendungssystemen vereinfacht und standardisiert werden soll
und eine einheitliche Datenzugriffsschnittstelle Erleichterungen und Verbesserungen in der
Pflegbarkeit der Anwendungsprogramme bringt
im Desktop-Bereich ein Interface zu den Backend-Datenbanken gesucht wird
ODBC sollte nicht verwendet werden

im Hochleistungsbetrieb, bei sehr hohen Transaktionsraten oder großen Datenmengen

bei großen Datenbankübergreifenden Joins, wenn kurze Antwortzeiten gefordert sind,

wenn die Anwendungen intensiven Gebrauch von stored procedures machen

in Multi-Server-Rechenzentren mit unterschiedlichsten Diensten (z.B. Mail- und Fax-Server)
Vor einer Kaufentscheidung für oder gegen den Einsatz von ODBC sollte auch noch berücksichtigt
werden, daß die meisten ODBC-Treiber bisher nur Core und Level 1 komplett unterstützen. Bei Level
2 sind bisher nur die wichtigsten Funktionen wird sich dies, abhängig von den Möglichkeiten des
DBMS, durch die weitere Verbreitung des ODBC-Standards entsprechend verbessern.
I.2.2. IBM’s Distributed Relational Database Architecture DRDA
IBMs DRDA wurde speziell zur Kopplung von IBMs Datenbankplattformen (relational: DB2/VM,
DB2/VSE, DB2, DB2/400, DBM, hierarchisch: IMS) auf unterschiedlichsten Plattformen und unter
Verwendung verschiedener Netzwerkprotokolle entworfen und wird vorwiegend dafür eingesetzt,
kann prinzipiell aber auch zum Anschluß anderer Datenbankmanagementsysteme eingesetzt werden.
DRDA ist ein IBM-Firmenstandard, der nur IBM’s LU6.2-Protokoll unterstützt. DRDA ist jedoch ein
de-facto-Standard für Anwender von IBM-Datenbankmanagementsystemen.
I.2.3. ISO/ANSI’s Remote Data Access Standard RDA
Der ISO-Standard RDA besteht aus zwei Teilen: dem generic RDA (ISO/IEC DIS 9579-1) und der
SQL-Spezialisierung (ISO/IEC DIS 9579-2). Er ist also so breit angelegt, daß er nicht nur auf
relationale Datenbankmanagementsysteme zielt und sowohl die Anbindung von Applikationen an
Datenbanken wie auch die Datenbank-Datenbank-Kopplung behandelt. Bisher gibt es nur wenige
RDA-basierte Produkte am Markt.
I.2.4. SQL Access Group’s RDA
Die Aktivitäten der SQL Access Group richten sich auf die Interoperabilität und Portabilität von SQLbasierten Produkten unterschiedlicher Hersteller. Die Spezifikationen sind kompatibel zu den
12
© GDV 1999
Datenmanager / Anhang
Das Verhältnis Database Middleware zum VAA-Datenmanager
Standardisierungsaktivitäten von ISO und ANSI (insbesondere RDA und SQL2) und gehen in den
X/Open Portability Guide ein.
Das bisher wichtigste Ergebnis ist die Spezifikation des SQL CLI, das auch von Microsoft für ODBC
verwendet wird.
I.2.5. Borland’s Integrated Database API Archtecture IDAPI
IDAPI basiert ebenfalls auf dem CLI der SQL Access Group, wurde aber von Borland, IBM, Novell
und WordPerfect als Konkurrent zu Microsofts ODBC positioniert. Im Unterschied zu allen anderen
Standards basiert IDAPI auf der objektorientierten Technologie und will relationale und nichtrelationale Datenbanken integrieren.
IDAPI wird sich jedoch nicht gegen die Microsoft-Linie durchsetzen lassen, insbesondere aufgrund
der derzeitigen Probleme bei Borland.
I.2.6. Apple’s Data Access Language Standard DAL
Die DAL basiert ebenfalls auf dem CLI der SQL Access Group, wurde allerdings erweitert. DAL
fungiert für Macintosh-basierte Client-Anwendungen als Client-API zum Zugriff auf SQLDatenbanken.
Aber auch DAL wird aufgrund seiner Verknüpfung mit den Apple-Plattformen keine allgemeine
strategische Bedeutung erlangen.
© GDV 1999
13
Inhalt
Datenmanager / Anhang
I.3. Abgrenzung zum Datenmanager VAA
Die im Dokument [VAA1.3] beschriebenen Anforderungen an den Datenmanager gehen weit über die
Funktionalität hinaus, die üblicherweise unter Database Middleware verstanden wird. Die
Datenbeschaffungskomponente allerdings, die innerhalb des Datenmanagers den sog. „physischen
Zugriff“ auf die Daten organisiert, also die eigentliche Schnittstelle zu den
Datenbankmanagementsystemen darstellt, kann mit Hilfe von Database Middleware Produkten
realisiert werden.
Anwendungsbaustein
...
Datenmanager
Datensichtprozessor
log. Datenmodell
Datenbeschaffungskomponente
DBMS 1
DBMS 2
File
Abb.: Schematische Darstellung des Datenmanagers
Die Architektur der VAA geht nämlich davon aus, daß die Anwendungsbausteine von der
Datenbeschaffung und Datenspeicherung vollständig befreit sind. Der Datenmanager stellt für diese
Anwendungsbausteine zur Laufzeit die benötigten Instanzen im Vorgangsspeicher in der Form zur
Verfügung, wie sie von den Anwendungsbausteinen benötigt werden. Deshalb bedarf es im
Datenmanager neben der Datenbeschaffungskomponente einer weiteren Komponente des
Datensichtprozessors, der genau die Aufgabe der Übersetzung der logischen Datenanforderungen des
Anwendungsbausteins in Aufträge zur Beschaffung der zugehörigen Entitäten an die Datenbeschaffungskomponente übernimmt.
Die Aufgaben des Datensichtprozessors werden durch Database Middleware Produkte in der Regel
nicht abgedeckt.
14
© GDV 1999
Datenmanager / Anhang
Das Verhältnis Database Middleware zum VAA-Datenmanager
I.4. Produkte
Bei der folgenden Liste von (erweiterten) Database Middleware Produkten handelt es sich zum einen
um eine offene, d.h. ständig zu erweiternde, fortzuschreibende Liste, zum anderen werden bewußt
Exemplare unterschiedlicher Typen von Produkten mit Teilfunktionalität des Datenmanagers
beschrieben.
I.4.1. DataJoiner von IBM
Der DataJoiner realisiert einen sogenannten Multi-Database Server. Beim DataJoiner steht also der
Aspekt der Datenföderierung, d.h. der Integration heterogener Datenbestände im Vordergrund.
Für den Fall, daß im Rahmen der VAA-Architektur auf Daten in unterschiedlichen Datenbanken und
heterogenen Datenbankmanagementsystemen zugegriffen wird, ist der DataJoiner als
Datenzugriffskomponente ein hilfreiches Produkt. Denn den Clients dieses Multi-Database Servers
wird ein Single-Database Image bereitgestellt, das volle Datenbankfunktionalität beinhaltet. Die Daten
werden aus diversen, heterogenen, verteilten Systemen selektiert und zusammengeführt, um anschließend im lokalen System gespeichert und weiterverarbeitet werden zu können. Über eine SQLSchnittstelle wird auf diese Daten transparent zugegriffen, egal ob sie aus unterschiedlichen
relationalen oder auch nicht-relationalen Beständen stammen. (In der ersten Version nur SQLRetrieval-Funktionalität, später auch Update.)
OS/2
DataJoiner
AIX
Solaris
DB2 LAN Driver
Server Services
DOS
Client Services
WINDOWS
SQL-Interface
DRDA Driver
Oracle
SQL*Net
DB2 für MVS
DB2 für VM&VSE
DB2 für OS/400
DB2 für OS/2
DB2 für AIX
DB2 Parallel Ed.
Oracle
Sybase
Open Cl.
Sybase
CLIDriver
andere rel.
DBMS
Rel.
Gateway
IMS-DB
VSAM
IDMS, ...
HP-UX
Abb: IBM DataJoiner
Der DataJoiner läuft auf dem IBM RISC System/6000 mit Betriebssystem IBM AIX.
In der ersten Version unterstützt der DataJoiner folgende remote relationalen oder nicht-relationalen
Datenquellen, die über SQL-Aufrufe in den Clients transparent erreicht werden können:
© GDV 1999
15
Inhalt

Datenmanager / Anhang
DB2 für MVS, DB2 für OS/2, DB2 für OS/400, DB2 für AIX, DB2 für VM&VSE und DB2
Parallel Edition

DB2 für HP-UX

DB2 für Solaris

Oracle

Sybase

IMS

VSAM files

andere über das gewünschte CLI mit der Funktionalität von Microsofts OBDC-CLI
In Folgeversionen werden weitere Datenbankmanagementsysteme unterstützt.
Auf Client-Seite werden folgende Betriebssysteme mit zugehörigem Netzprotokoll zum Zugriff auf
den DataJoiner unterstützt:

AIX mit TCP/IP oder APPC

OS/2 mit TCP/IP oder APPC

DOS/Windows mit TCP/IP oder IPX/SPX

HP-UX mit TCP/IP

Solaris mit TCP/IP
Folgender Host-Language-Support steht zur Verfügung:

für embedded SQL: C, Fortran, COBOL und REXX

für CLI-SQL: ODBC-Kernfunktionalität und einige Erweiterungen
Eine besondere Stärke des DataJoiners liegt in der IBM Global Optimization Technology, die im
DataJoiner implementiert wurde. Der DataJoiner führt die globale Optimierung der SQL-Anfragen
durch, indem er die Stärken oder auch Schwächen der angesprochenen Datenhaltungssysteme in
Betracht zieht. Diese Optinizer-Techniken ermöglichen effiziente, verteilte Join-Operationen, die für
den Benutzer zu zufriedenstellender Query-Performance führen. Dies gilt sowohl für „dynamisches“
als auch für „statisches“ SQL.
Es ist möglich, im DataJoiner mehrere integrierte Datenbanken zu definieren, deren Tabellen und
Views sich auf verschiedene Quelldaten beziehen. Einzelne Quelltabellen können wiederum in
verschiedenen integrierten Datenbanken enthalten sein. Ein globaler Katalog, in dem der Benutzer bei
der Definition von Views oder SQL-Statements logische Bezeichner (nicknames) vergibt, sorgt für die
Transparenz und Unabhängigkeit, die der Benutzer für die produktive Informationsgewinnung
braucht.
Für OS/2- und AIX/6000-Clients stehen weitere Tools zur Datenauswertung zur Verfügung:

16
IBM Visualizer Query
© GDV 1999
Datenmanager / Anhang
Das Verhältnis Database Middleware zum VAA-Datenmanager

IBM Visualizer Charts

IBM Visualizer Procedures

IBM Visualizer Statistics

IBM Visualizer Plans

IBM Visualizer Development

IBM Visualizer Multimedia Query
Genauer beschrieben ist der DataJoiner in [IBMDaJo94] und [DBFo1/95].
I.4.2. Natural Active View von Software AG
Das Produkt NATURAL ACTIVE VIEW stellt ähnlich dem DataJoiner von IBM eine Middleware zur
Verfügung, die NATURAL-Applikationen einen transparenten Zugriff auf Daten in unterschiedlichen,
heterogenen Datenbanken ermöglicht. Eine sogenannte Active View ist aber mehr als eine reine
logische View auf heterogen verteilte Daten. Neben den Daten besteht die Active View aus Benutzerdefinierter Funktionalität, die beim Zugriff auf die Daten aufgerufen wird. So gesehen wird durch eine
Active View eine objekt-basierte Schicht zwischen einer NATURAL-Applikation und heterogenen,
physikalischen Datenhaltungen hergestellt.
Eine Active View wird durch ein View-Programm implementiert, das in extended NATURAL
geschrieben wird. In Client/Server-Umgebungen können Active Views und ihre Clients auf
unterschiedliche Plattformen verteilt werden.
© GDV 1999
17
Inhalt
Datenmanager / Anhang
Client
Programs
DDM
View-Program (Server)
DDM
DDM
DDM
DBMS1
DBMS2
DBMS3
z.B. ADABAS
z.B. DB2
Abb.: Prinzip von NATURAL ACTIVE VIEW
Die wesentlichen Aufgaben von NATURAL ACTIVE VIEW, auf die im Folgenden noch kurz
eingegangen wird, sind:

Bereitstellung logischer Datensichten von Daten aus heterogenen Quellen

Bereitstellung eines objekt-basierten Layers für den Datenzugriff

Sicherstellung von Datenintegrität

Unterstützung konzeptueller Modellierung und

Unterstützung von Cooperative Processing
Durch die Bereitstellung logischer Sichten wird die heterogene Natur der Daten transparent. Die Daten
können aus unterschiedlichen Datenbanken und aus dem Filesystem stammen und auf unterschiedliche
Rechner verteilt sein.
Das View-Programm besteht aus einer Beschreibung der individuellen Datenquellen, der
Datenbeziehungen, der Abbildung auf die Sichten und den Zugriffsmethoden. Neben der üblichen
Zugriffsfunktionalität (SELECT, UPDATE, STORE, DELETE) können Benutzer-definierte Methoden
auf einen Active View ausgeführt werden. NATURAL ACTIVE VIEW stellt auch eine automatische
Zugriffsoptimierung für unterschiedliche Datenhaltungssysteme zur Verfügung.
Dadurch daß NATURAL ACTIVE VIEW einen objekt-basierten Layer realisiert, kann der Zugriff auf
die Daten im Active View Programm kontrolliert werden: nur die bei der View definierten Aktionen
werden unter der Kontrolle des View-Programms ausgeführt. Zugriffsmethoden und Integritätschecks
18
© GDV 1999
Datenmanager / Anhang
Das Verhältnis Database Middleware zum VAA-Datenmanager
sind näher an den Daten, dadurch werden Modularisierung, spätere Wartung und Unabhängigkeit von
einem bestimmten Datenbankmanagementsystem verbessert.
Durch diesen Ansatz ist es ebenfalls möglich, die Integritätsregeln (implementiert in Standard
NATURAL) nahe bei den Daten und nicht in der Applikation zu implementieren.
Die konzeptuelle Modellierung wird unterstützt durch die Konstrukte

Aggregation

Partition

Klassifikation

Generalisierung und

Assoziation
Cooperative Processing wird unterstützt, indem Oberflächenfunktionalität, Business-Funktionalität
und Datenhaltungsfunktionalität beliebig auf Client und Server verteilt werden können.
Eine genauere Beschreibung mit Implementierungsbeispiel findet sich z.B. in [SAGNAV].
I.4.3. OpenDM von Siemens Nixdorf
Open Database Middleware, kurz OpenDM, ist eine generische und konfigurierbare Softwareschicht
oberhalb heterogener Datenhaltungssysteme wie relationaler Datenbankmanagementsysteme,
objektorientierter Datenbankmanagementsysteme, aber auch hierarchischer oder
Netzwerkdatenbankmanagementsysteme oder dem Filesystem. OpenDM stellt im Sinne einer
generischen und konfigurierbaren Softwareschicht kein fertiges Middleware-Endprodukt dar, sondern
bietet einen Baukasten für den Aufbau kundenspezifischer Database Middleware an. Bei diesem Baukasten selbst handelt es sich noch nicht um ein freigegebenes Produkt, sondern es befindet sich noch
in der Pilotierungsphase und wird in einigen Projekten erprobt. Das Spektrum von OpenDM ist sehr
weit gespannt: Es reicht von

Föderierung (Kopplung von Datenbanken mit Wahrung der Autonomie)

über „strenge“ Kopplung (transparenter Zugriff auf heterogene Datenhaltungssysteme)

bis hin zur Datenbank-Unabhängigkeit („beliebige“ Datenhaltungssystem mit aufgesetztem
„Standard Interface“) sowie

Migrationsfunktionalität zum Verschieben, Kopieren und Replizieren von Daten aus heterogenen
Datenhaltungssystemen.
Das Baukastenprinzip ermöglicht hohe Wiederverwendbarkeit einzelner Komponenten und breite
Einsatzmöglichkeiten.
Als Standard- bzw. Application-Interface bietet OpenDM derzeit ODMG ODL/OML und STEP
EXPRESS/SDAI an. Zum Zwecke der Föderierung wurde der ODMG-Standard um eine MultiDatabase-Language erweitert.
© GDV 1999
19
Inhalt
Datenmanager / Anhang
Abb.: Architektur von OpenDM
Das Übersichtsbild zeigt die modulare Struktur von OpenDM.
Die Spezifika für den Föderierungsaspekt sind in den DB-Adaptern gekapselt, alle anderen Module
und Schnittstellen sind generisch. Die DB-Adapter realisieren die Kommunikation mit den
verschiedenen Datenhaltungssystemen und transformieren die heterogenen Daten und Operationen in
das interne Modell des Objektmanagers. Nach oben wird den Anwendungen via einem Externen
Adapters (z.B. ODMG-Standard ODL/OML) ein entsprechender Database Coupling Layer zur
Verfügung gestellt, über den ein transparenter Zugriff auf die (optional föderierten) Datenhaltungssysteme ermöglicht wird.
Applikationen greifen entweder direkt auf das Datenhaltungssystem oder über einen Externen Adapter
mit Hilfe von OpenDM auf eine oder mehrere Datenhaltungssysteme zu. Die externen Adapter dienen
dazu, die individuellen Sprachmodelle der Applikationen auf das Common Internal Interface
abzubilden. OpenDM wird neben derzeit ODMG ODL/OML und STEP EXPRESS/SDAI externe
Adapter für Standard-Datenbank-Interfaces wie SQL, ODBC usw. zur Verfügung stellen, so daß nur
in Ausnahmefällen spezifische Adapter entwickelt werden müssen.
Mit Hilfe des Administration Interface wird das System gestartet, gestoppt, initialisiert und es werden
die Datenbankmanagementsysteme ge- und entkoppelt. Die Administrationsdienste werden mit Hilfe
des Process Managers, der Coupling Control und der User Administration realisiert.
Der Object Manager überführt den globalen Datenzugriff in den Zugriff auf den spezifischen lokalen
Zugriff. Der Object Manager nutzt dabei das Data Dictionary, in dem die Informationen für die
Schema-Integration stecken, und den Data-Identification-Module, der die Abbildung der ObjectIdentifiers in die Identifier der heterogenen Datenhaltungssysteme vornimmt. Der Storage Manager ist
für den effizienten Datentransfer, die Speicherung und ein Caching verantwortlich.
20
© GDV 1999
Datenmanager / Anhang
Das Verhältnis Database Middleware zum VAA-Datenmanager
Derzeit unterstützte Plattformen sind: SunOS 4.1 und Solaris, RM200/Sinix sowie PCs mit Windows
3.1x, künftig Windows 95.
Veröffentlichungen zu OpenDM sind z.B. [Bött95] und [Rad94].
Nutzung von OpenDM als Datensichtprozessor:
OpenDM (Open Database Middleware) ist ein ‘toolkit’ bzw. eine Produktfamilie, die Lösungen zur
Datenbankföderierung, Datenbankunabhängigkeit und Migration bei heterogenen
Datenhaltungssystemen (Datenbanksystemen, Dateisystemen, usw.) bietet. Dabei ist OpenDM eine
Softwareschicht zwischen (multiplen) Datenhaltungssystemen und (multiplen)
Datenbankanwendungen. Durch eine Adaptertechnik erlaubt OpenDM eine einfache Anpassung an
Datenhaltungsysteme als auch an die Datenbankschnittstellen der Anwendungen. OpenDM ist für
spezifische Lösungen konfigurierbar. Zur Erstellung einer Lösung stehen hierbei vielfältige
Werkzeuge zur Verfügung, die Anwendungsentwicklung mittels OpenDM unterstützen. Zur
Definition von Anwendungen als auch zum Zugriff auf Daten bietet OpenDM verschiedene Benutzerschnittstellen an. Hier werden momentan ER-basierte (Entity-Relationship) als auch objektorientierte Schnittstellen gemäß den Standards STEP/Express und ODMG angeboten. Da hier
Wahlfreiheit besteht, wird im weiteren einfach vom globalen Modell gesprochen.
Hier soll die mögliche Nutzung von OpenDM als „Datensichtprozessor“ dargestellt werden. Eine
Datensicht in OpenDM wird im globalen Modell beschrieben (ein Schemadefinition im Sinne von
OpenDM). Eine Datensichtdefinition kann



gegenüber dem Modell/Schema eines (oder mehreren) bestehenden Datenhaltungssystems(en) (z.B.
SQL Datenbanksystem) beschrieben werden. Somit kann auf bereits bestehende Daten gemäß der
Datensicht zugegriffen werden.
gegenüber weiteren Datensichten/Schemadefinitionen des globalen Modells beschrieben werden.
neue Strukturen definieren. Hierzu werden entsprechende Schemata in den geforderten
Datenhaltungssystemen angelegt. Auf diese kann gemäß der Datensichtdefinition gearbeitet
werden.
Durch die Datensicht wird eine Entkopplung von den eigentlichen Datenhaltungssystemen erreicht.
Man erzielt hierdurch eine Datenbankunabhängigkeit/Portabilität der Anwendungen und der Daten.
Hierbei erlauben die Datensichten den Zugriff (lesend/erzeugend/modifizierend) auf neue/bestehende
Daten. Wenn erforderlich, ist OpenDM so konfigurierbar, daß neben den Zugriff über das globale
Modell auch ein autonomer, lokaler Zugriff auf die darunterliegenden Datenhaltungssysteme möglich
ist.
Die Umsetzung einer Datensicht auf das jeweilige Datenhaltungssystem erfolgt unabhängig von der
Anwendung, d.h. nicht aus der Anwendung heraus, mittels OpenDM. Hierzu stehen verschiedene
Werkzeuge sowie ein leistungsfähiger Datenbank-Middleware-Kern zur Verfügung. Die
Werkzeugunterstützung umfaßt:

Beschreibung der Schnittstelle (graphisch/textuell)

Generierung der Anwendungsschnittstelle


Generierung der Abbildungsfunktionen auf die entsprechenden Datenhaltungssysteme sowie den
OpenDM Datenbank-Middleware-Kern
Definition von Datensichten aus bestehenden Modellen (z.B. relational nach ER/OO)
© GDV 1999
21
Inhalt

Datenmanager / Anhang
Die Werkzeuge spielen mit dem OpenDM-Kern zusammen. Letzterer bietet ein effizientes
Arbeiten durch:

ein Data Dictionary/Repository zur Speicherung der Schema/Datensichtbeschreibungen

ein eigenes Daten- und Systemmanagement zur Unterstützung der Daten- bzw.
Objektzugriffe (z.B. Caching, Objektmanager, Prozeß- und Zugangskontrolle, usw.).
I.4.4. DBA von Siemens Nixdorf
Der Database Access Service DBA von Siemens Nixdorf bietet über offene marktgängige
Schnittstellen einen einfachen, einheitlichen Zugriff von PCs und UNIX-Systemen aus auf
unterschiedlichste UNIX- und Host-Datenbanken - auch plattformübergreifend.
DBA bietet einen lokalen, entfernten und verteilten Zugriff über die

Schnittstellen ESQL/C, DDE, ODBC und künftig OLE

mit Clients unter Windows und SINIX

auf die Datenbanken INFORMIX, ORACLE, INGRES, DB2/6000, SESAM/SQL und UDS/SQL

auf den Plattformen SINIX, HP-UX, AIX und BS2000.
Insbesondere wird durch DBA das zunehmende Angebot an ODBC-fähigen Windows-Applikationen
und Tools effizient einsetzbar. Spezielle Treiber oder zusätzliche Datenbank-Netzwerk-Komponenten
sind nicht erforderlich.
Alle Daten erscheinen auf der Client-Seite unabhängig von allen Quellsystemen in derselben Form.
Bedienung und Programmierung vollziehen sich auf allen Systemplattformen deshalb so, als ob der
Benutzer auf dem lokalen System beim Zugriff auf verschiedene Datenbank-Technologien mit nur
einem Datenbanktyp arbeiten würde.
MS-Windows
SINIX
TCP/IP-, OSI-LAN / -WAN (ISO RDA-Protokoll)
SINIX
HP-UX
AIX
Abb.: DBA-Architektur
22
BS2000
DBA bietet als
Middleware
keine eigene
Endbenutzerober
fläche. Vielmehr
soll man mit den
Endbenutzerober
flächen seiner
Wahl seine
bevorzugten
Datenbankmanagementsysteme
erreichen
können.
Entsprechend
der VAAAnwendungsarc
hitektur stellt
DBA eine sehr
© GDV 1999
Datenmanager / Anhang
Das Verhältnis Database Middleware zum VAA-Datenmanager
komfortable und zugleich flexible Datenbeschaffungskomponente für eine bestimmte Anzahl von
Plattformen und Datenbankmanagementsysteme dar. Flexibilität bzgl. der auf DBA aufsetzenden
Client-Komponenten wird dadurch erreicht, daß verschiedene Schnittstellen wie die ISO-genormte
ESQL/C-Schnittstelle unter Unix und Windows sowie die Microsoft-Standards DDE, ODBC und
künftig OLE angeboten werden. Diese Schnittstellen sorgen für „freien Zugang“ über DBA zu den
genannten Datenquellen.
Dies ist möglich, weil DBA an allen unterschiedlichen Schnittstellen eine einheitliche SQL-Syntax
und Semantik beherrscht. Die „statischen“ und „dynamischen“ SQL-Statements werden vom DBAeigenen SQL-Laufzeitsystem am Client zielsystemneutral zum Server geschickt. Erst im Server wird
die DBA-SQL auf den speziellen SQL-Dialekt des Zielsystems abgebildet. Dabei werden selbst nicht
genormte und von den Datenbanksystemen völlig unterschiedlich angebotene Konstrukte wie BLOBs
durch DBA einheitlich dargestellt. DBA wirkt wie ein Multiplexer, der „alle“ Datenbankmanagementsysteme mit sämtlichen Anwendungen über eine Schaltstelle, eine .ini-Datei, ein
Netzprodukt verknüpft.
Der Anwendungssoftware- wie der Tool-Hersteller gewinnt durch DBA Freiheit bzgl. der Wahl seines
Datenbankmanagementsystems. Er spart sich Anpassungen seiner Produkte, er wird auch vom lästigen
Upgrade auf neue DBMS-Versionen befreit.
DBA ist unter anderem auch als ODBC-Treiber einsetzbar. DBA bietet hier folgende Vorteile:




Unterstützung der höchsten Conformance-Level von ODBC
einen Treiber für viele Datenbanksysteme und damit geringere Kosten, geringerer
Ressourcenverbrauch, geringerer Administrationsaufwand, ...
keine zusätzlichen Datenbanknetzprodukte notwendig und damit geringere Kosten, geringerer
Administrationsaufwand, ...
alles aus einer Hand und damit keine Probleme mit unverträglichen Komponenten verschiedener
Hersteller
© GDV 1999
23
Inhalt
Datenmanager / Anhang
Ein besonderer
Vorteil von
DBA ergibt
sich, wenn
Zugriff auf mehr
als ein Datenbankmanageme
ntsystem
notwendig ist.
Beim Einsatz
von DBA fallen
keine zusätzlichen Kosten für
mehrere ODBCTreiber und
DatenbankNetzprodukte
an. Neben
diesem Preisund
Ressourcenargu
ment gibt es
Abb.: ODBC mit und ohne DBA
noch einen
gravierenden technischen Vorteil. Ein generelles Problem bei ODBC-Treibern ist nämlich die
Abhängigkeit von der Datenbankversion. Bei UNIX-Datenbanken ist die Kompatibilität zwischen den
verschiedenen Versionen nämlich nicht unbedingt gegeben. So kommen z.B. Änderungen der
Schemainformationen recht häufig vor. Da sich ODBC sehr stark auf solche Informationen stützt, ist
eine starke Abhängigkeit der ODBC-Treiber von der Version des Datenbankmanagementsystems
gegeben. D.h. bei einem Umstieg auf die neue Datenbankversion kann es nötig sein, daß alle ODBCTreiber ausgetauscht werden müssen. Unter Umständen müssen auch die Datenbank-Netzprodukte auf
allen Clients ausgetauscht werden. Bei DBA ist nur eine geänderte Server-Komponente nötig. DBAServer können sogar problemlos mit alten DBA-Clients zusammenarbeiten und umgekehrt.
Zur Performance-Optimierung werden zwei Techniken angewandt: Mit dem MULTIPLE FETCH
werden Daten geblockt vom Server zum Client übergeben. Und für den Zugriff auf häufig benötigte
Daten der Schemainformation wird im Client ein Cache eingesetzt.
Verteilte Joins über unterschiedliche Datenbankmanagementsysteme sind mit DBA möglich, werden
aber nicht mit speziellen Funktionen unterstützt, Programmierung ist erforderlich. Während DBA
derzeit „nur“ entfernten Datenzugriff bietet, ist es vorgesehen, zukünftig im Rahmen eine „Open
Server Strategie“ auch Elemente der verteilten Verarbeitung wie Stored Procedures der
Datenbankmanagementsysteme oder Anwbindung beliebiger Serverprogramme anzubieten.
Weitere ausführliche Literatur zu DBA findet man in [SNIDBA94], [SNIDBA95] und [DBFo2/95].
I.4.5. ComUnity OT-Framework von Siemens Nidorf
Im Rahmen des ComUnity-Konzepts wird bei Siemens Nixdorf derzeit ein Open Technology (OT-)
Framework für die Entwicklung kommerzieller Applikationen auf den Microsoft 32-Bit-Plattformen
24
© GDV 1999
Datenmanager / Anhang
Das Verhältnis Database Middleware zum VAA-Datenmanager
Windows 95 und Windows NT mit Zugriff auf Datenbankserver über Level-2-konforme 32-Bit
ODBC-Treiber entwickelt. Dieses Framework wird Ende 1996 als Produkt verfügbar sein.
Diesem Framework liegt die folgende Architektur zugrunde:
Presentation
OLE-Client
OLE-Automation
OLE-Server
Business Management
OLE-Client
OLE-Automation
OLE-Server
Business Data Layer
Server-Link über ODBC
Server
Abb.: Schichten einer OT-Framework Applikation
Der Business Data Layer verfolgt einen ähnlichen funktionalen Anspruch wie der VAADatenmanager, allerdings nur für Applikationen auf den Microsoft-Plattformen, die über ODBC auf
Datenbanken zugreifen. Jede OT-Framework-Applikation wird durch ein Data Dictionary gesteuert;
das Data Dictionary enthält im wesentlichen das Objektmodell der komplexen Objekte des Business
Management Layers, des Datenbankschema und Konsistenzbedingungen.
Der Business Data Layer (BD Layer) übernimmt folgende Aufgaben:


Instantiierung und Verwaltung von Business Data-Objekten (BD-Objekten) als Antwort auf
Anforderungen des Business Management Layers. Verwaltung des Pools von BD-Objekten.
Generierung von SQL-Statements zum Einfügen und Lesen in bzw. aus der Datenbank via ODBCSchnittstelle. Die Abbildung von Objekten auf Relationen der Datenbank wird im Data Dictionary
definiert.

Einfache Plausibilitätsprüfungen für Attribute wie z.B. Bereichsüberprüfungen.

Steuerung von BD Layer-Transaktionen (Software Locks und Optimistic Transactions).

Protokollierung von Einfügen-, Ändern- und Löschoperationen (Logging).

Implementierung eines Domain-Konzeptes (Single Point of Definition)

Zugriff auf das Data Dictionary. Interpretation des Data Dictionaries.
© GDV 1999
25
Inhalt
Datenmanager / Anhang
Die folgende Abbildung zeigt die Grundkomponenten des BD Layers und seine Schnittstellen zu
anderen Teilen des OT Frameworks:
BM Layer
OLE Automation Interface
Data Layer Object Pool
BD-Object
BD-Object
BD-Object
BD-Object
BD-Object
Data
Dictionary
ODBC Interface
RDBMS
Abb.: BD-Layer
Der BD Layer ist für das Management von BD-Objekten verantwortlich. Wenn ein BM-Objekt eine
Verbindung zu „seinem” BD-Objekt aufbauen will, stellt es eine Anforderung über die OLEAutomations-Schnittstelle an den BD Layer. Der BD Layer prüft zuerst, ob das BD-Objekt bereits im
Objekt-Pool ist. Falls ja, wird die Verbindung direkt aufgebaut. Im anderen Fall muß der BD Layer
das angeforderte Objekt instantiieren und gleichzeitig in den Objektpool aufnehmen. Das Objekt wird
dabei über ein generiertes SQL-Statement (nähere Informationen weiter unten) aus der Datenbank
gelesen. Informationen über die Struktur des Objektes (z.B. welche Attribute es hat oder in welcher
Datenbanktabelle und -spalte die Attribute gespeichert sind) werden aus der Klassendefinition des
Objekts im Data Dictionary gelesen.
Wenn ein BD-Objekt einem BM-Objekt zugeordnet ist, stehen dem BM-Objekt alle
Attributinformationen des BD-Objekts zur Verfügung. Wichtig ist, daß der BD Layer den BM Layer
auch mit Informationen über Referenzen des BD-Objekts zu anderen BD-Objekten beliefert. Diese
Informationen benötigt der BM Layer, um den Objektbaum aufzubauen und auf die Daten
zuzugreifen. Wenn der BM Layer Objektdaten in die Datenbank zurückschreiben will, ruft er auch
dafür den BD Layer auf. Dieser führt den Auftrag anschließend aus.
Der Objekt-Pool ist ein Mechanismus, der die Anzahl Lese-/Schreibzugriffe auf die Datenbank
minimiert. Er arbeitet wie ein „Festplatten-Cache”. Die gepufferten Elemente sind jedoch keine
Sektoren oder Cluster, sondern BD-Objekte des BD Layers. Bei Bedarf werden neue Objekte
nachgeladen und nicht mehr benötigte aus dem Pool (Cache, Puffer) entfernt.
26
© GDV 1999
Datenmanager / Anhang
Das Verhältnis Database Middleware zum VAA-Datenmanager
I.4.6. SYBASE Client/Server Produkts
Im SYBASE Client/Server architectural framework sind rund um die Applikation eine Reihe von
Service-Komponenten definiert, die durch SYBASE Client/Server-Produkte unterstützt werden.
Transaction
Management
User Application
Application
Services
Application Programming Interfaces
Protocol
Services
Naming
Services
Security
Services
Transport
Session
Presentation
Application
Naming
Addressing
Directory
Authentication
Access Control
Data
Confidentiality
Data Integrity
Non-repudiation
Management
Services
Fault Mgt
Accounting Mgt
Config. Mgt
Perform. Mgt
Security Mgt
Abb.: SYBASE
Client/Server Architecture
Die Database Middleware Produkte sind in dieser Architektur unter den SYBASE Application
Services anzusiedeln. Alle diese Application Services beruhen auf den Open Client und Open Server
Produkten als building blocks.
© GDV 1999
27
z.B. Server Application
Open Server
z.B. User Interface
Server
Program
Open Client
Client
Program
Open Server
Datenmanager / Anhang
Open Client
Inhalt
Server
Program
z.B. Database Server
Abb.: Open Client
und Open Server als building blocks
Diese Strategie hat u.a. folgende Vorteile:



einheitliches Interface zwischen allen Produkten
keine Interoperabilitätsprobleme mit nicht von SYBASE entwickelten Open Client und Open
Server Applikationen
einheitliche Erweiterung aller Produkte, die auf Open Client/Open Server basieren, bei Update der
Open Client/Open Server Produkte
Die wesentlichen, von SYBASE ab System 10 unterstützten Application Services sind:


28
Replication Server: Ziel jeder Replikation ist, die im Client relevanten Daten so nahe wie möglich
an den Client zu bringen. Ein repliziertes Datenhaltungssystem kopiert deshalb möglicherweise
mehrere Datenbanken über viele Ressource Manager. Aber für jede Tabelle gibt es nur eine
Primärversion innerhalb des replizierten Systems. Die Besonderheit des SYBASE Replication
Servers besteht darin, daß zum Zeitpunkt des Commits einer Transaktion nicht alle beteiligten
Resource Manager verfügbar sein müssen. Dies kann dann natürlich dazu führen, daß lokale Daten
nicht immer synchron mit der Primärversion sind.
Navigation Server: Der Navigation Server erlaubt parallelen und transparenten Zugriff auf
partitionierte Tabellen und Schemata. Die wesentlichen Bestandteile sind der Control Server, der
Data Server, der DBA Server und der Navigation Server Manager. Der Control Server übernimmt
die Anfragen von den Open Client Applikationen, kompiliert und führt die SQL-Statements und
Stored Procedures aus und meldet die Ergebnisse zurück. Die Aufgabe des Data Servers ist, die
Daten auf die Tabellen zu verteilen bzw. umgekehrt zusammenzuführen. Der DBA Server über© GDV 1999
Datenmanager / Anhang
Das Verhältnis Database Middleware zum VAA-Datenmanager
nimmt die Verwaltungsfunktionalität rings um den Datenzugriff (backup, restore, dumping,
loading, deadlock detection, monitoring, restart, ...), der Navigation Server Manager unterstützt die
Administration.




OmniSQL Server: Der OmniSQL Server sorgt für die Ortstransparenz, für Transparenz in unterschiedlichen SQL-Dialekten und Unterschieden zwischen dem SYSBASE SQL Server, ORACLE,
DB2, RMS und ISAM-Dateien.
Der OmniSQL Server fungiert als Gateway mit einer Transact-SQL-Engine und unterschiedlichen
Access-Modulen für die jeweiligen Datenhaltungssysteme.
SQL Server and Backup Server: Der SQL Server und der Backup Server sind die eigentlichen
Datenbankmanagementsysteme, keine Middleware.
Net-Gateway: SYBASE’s Net-Gateway-Produkt ermöglicht die Client/Server-Kommunikation mit
IBM-Mainframe Datenquellen über CICS. Das Net-Gateway besteht aus zwei Komponenten, dem
Mainframe Server Gateway, das Anfragen von Open Client Applikationen an CICS Server
Applikationen via LU6.2 stellt, und dem Mainframe Client Gateway, das Anfragen von CICS
Client Applikationen an den SQL Server akzeptiert.
SQL-Monitor: Der SQL-Monitor ist eine spezifische Open Client Applikation, mit der real-time
Statistiken über viele SQL-Server ermittelt werden, z.B. über Locking, Caching, Device I/O,
Transaktions-Mix, Thread-Aktivität, ...

Secure Server (Sicherheitsdienste)

Audit Server (insbesondere Paßwort-Management)

SA Companion (System-Management, Administration)

SQL Debug (interaktiver Source-Level Debugger für SYBASE’s erweitertes SQL)

Database load and query tools
SYBASE bietet neben seinen Manualen auch eine Reihe von Übersichts-Bänden an. Die obige
Zusammenfassung beruht im wesentlichen auf [SybOv].
I.4.7. Der Datensichtprozessor der Württembergischen
Versicherung
Bei der Württembergischen Versicherung (WV) ist seit 1989 im Rahmen einer neuen
Anwendungsarchitektur eine Komponente im produktiven Einsatz, die wesentliche Aspekte des VAADatenmanagers berücksichtigt.
Folgende Voraussetzungen sind im Datensichtprozessor der WV abgedeckt:



Unabhängigkeit von der physischen Speicherung
unterschiedliche DBMS können integriert werden
Unabhängigkeit vom logischen DB-Design
die Datenanforderungen der Anwendungs-SW werden auf der Basis des logischen DM
formuliert
Datenkonsistenz gegenüber dem Modell
© GDV 1999
29
Inhalt
Datenmanager / Anhang
die Vorgangsdaten entsprechen zu jedem Zeitpunkt dem DM



Unterstützung langer Transaktionen
Vorgänge über mehrere Transaktionen mit Update am Ende
Integration der Zeitlogik durch die Definition von Informationsobjekten
zweidimensionale Zeit wird unterstützt Minimierung der "Zeitsprünge"
Basis für die Implementierung generischer Software-Bausteine
allgemeingültige Software-Algorithmen werden unterstützt
Der Datensichtprozessor wurde für einer Großrechner-Umgebung entwickelt, das überwiegend
genutzte Datenbank-System ist IMS/DB.
Datenanforderungen und Datenänderungen erfolgen aus Sicht der Anwendungen ausschließlich auf
Basis des Unternehmens-Datenmodells. Sie werden in Form von Datensichten formuliert, in denen
Umfang und Struktur der angeforderten Daten beschrieben sind.
Zur Zeit wird für den WV-Datensichtprozessor ein Redesign-Projekt durchgeführt mit den Zielen

Entwicklung graphischer Konfigurationswerkzeuge

Transformation zwischen logischem und physischem Modell

durch eine flexible Abbildungssprache

Portierbarkeit der Basisfunktionen auf weitere Plattformen

als Basis für eine Client/Server - Architektur

Unterstützung weiterer Datenbank-Managementsysteme
I.4.8. Weitere
In der Regel bieten die Hersteller von CASE-Werkzeugen wie z.B. Texas Instruments mit dem IEF
Composer grafische Modellierungswerkzeuge an, mit deren Hilfe E/R-Modelle und physische
Datenmodelle entwickelt werden können. Aus diesen Modelle lassen sich Datenbankschemata und
Standard-Zugriffe generieren. Die Anforderungen, die sich aus der Versionsmodellierung ergeben
sowie die Formulierung von Datansichten ist in der Regel nicht möglich.
II. Technologische Aspekte - insbesondere
Objektorientierung
II.1. Komponentenorientierung und Objektorientierung
In der Diskussion über Anforderungen an moderne Software-Architekturen werden die Themen
30
© GDV 1999
Datenmanager / Anhang


Technologische Aspekte - insbesondere Objektorientierung
Verbesserung der Möglichkeiten für Wiederverwendung zur Kostenreduktion in der SoftwareEntwicklung, -Wartung und -Pflege und
Verbesserung der Flexibilität der Softwaresysteme zur besseren Unterstützung des
prozeßorientierten Arbeitens und zur schnelleren Reaktion auf die Marktdynamik
vorrangig genannt. Komponentenorientierung wie Objektorientierung werden als Paradigmen der
Software-Entwicklung zum Erreichen dieser Ziele angesehen.
Die Umstrukturierung der Unternehmen von einer relativ starren, arbeitsteilig und hierarchisch
organisierten Arbeitsform zu flexibleren und prozeßorientierten Strukturen hat zum Prinzip, daß jeder
Mitarbeiter mehr Autonomie und größere Verantwortung für seine Aufgaben und damit den
Gesamterfolg seines Unternehmens erhält. Mehr Verantwortung tragen führt zu der Anforderung,
Zugriff zu aller für die jeweiligen Aufgaben notwendigen Information zu erhalten. Es muß möglich
sein, daß der in der Prozeßkette tätige Mitarbeiter sich die Informationen, die er zur Bewältigung
seiner Aufgaben benötigt, am „Endgerät“ seines Arbeitsplatzes beschafft; wo sich auch immer im Netz
die Informationsquelle befinden mag. Der Arbeitsplatzrechner wird zum Integrationspunkt für
Informationen.
User Centered Computing Paradigm
Personal Computer
as Workplace-Stations
Network
NT Servers
UNIX Servers
The IT-Infrastructure focusses on the Workplace and
Servers
integrates heterogeneous server environments Mainframe
(MVS/BS2000)
Abb.: Paradigma des User Centered Computing
Monolithische Anwendungssysteme sind in der Regel zu starr und implementieren vordefinierte
Geschäftsprozesse. Die IT-Technologie muß diesem Wandel folgen und die benötigten technischen
Mittel schaffen. Client/Server-Computing ist der erste Schritt in diese Richtung, reicht allein jedoch
nicht aus, die oben genannten Ziele der Wiederverwendung, Kostenreduktion und insbesondere der
Flexibilität in Bezug auf sich rasch wandelnde Marktanforderungen zu erreichen. Die SoftwareArchitekturen müssen mehr Flexibilität ermöglichen.
Die technischen Auswirkungen sind:



Das Netzwerk wird zum „System“.
Der Arbeitsplatz des Endanwenders wird zum Integrationspunkt für Informationen, die zentrale IT
steht nicht mehr im Mittelpunkt.
Die Software muß wesentlich modularer strukturiert, aus „Komponenten“ oder „Objekten“
konfigurierbar sein.
© GDV 1999
31
Inhalt
Datenmanager / Anhang
Application Architectural Evolution
Monolithic
Client/Server
Component Based
Presentation Logic
Presentation Logic
Presentation Objects
Business Logic
Business Logic
Business Objects
Data Management
File System + DBMS
Data Management
RDBMS
Data/Resource
Management
1970
1990
1997
2001
Abb.: Entwicklung hin zu
Komponenten-Software [nach Gardner Group]
II.1.1. Was ist eine Komponente, ein Objekt?
Die Frage „Was ist eine Komponente oder ein Objekt?“ läßt sich nicht zweifelsfrei beantworten,
insbesondere nicht, wenn nicht die Art ihrer Benutzung genauer differenziert wird. Gemeinsames
Merkmal jedes Objekts oder jeder Komponente ist, daß es sich um ein Stück Software handelt, das auf
eine bestimmte Art und Weise „verpackt“ ist, eindeutig identifiziert werden kann und über ein
Interface verfügt, über das Verhalten (Dienste) und Daten von außen zugänglich gemacht werden.
Bei der Konstruktion bzw. Implementierung von Software ist der Begriff des Objekts mit dem
Programmierparadigma einer objektorientierten Sprache verbunden. Im Kontext der
Implementierungstechnik wird weniger von der „Komponente“, viel mehr von Objekt, Klasse,
Klassenbibliothek gesprochen.
Jede Klasse, von der sinnvoll abgeleitet werden soll, hat drei verschiedene Interfaces:



Das externe (public) Interface: Dies ist die Sicht des Nutzers einer Klasse, insofern ist es das
„wichtigste“ Interface, weil es den Kontakt zwischen Klassennutzer und Klassenprovider definiert.
Es umfaßt Methoden mit Aufrufparametern (mit Typ), Returnwert (mit Typ), Verhalten,
Fehlerverhalten.
Das protected (virtuelle) Interface: Dies ist die Sicht des Modifizierers einer Klasse durch
Vererbung. Es beschreibt den Kontakt zwischen dem Klassenerweiterer und dem Klassenprovider.
Klassenerweiterungen sind kaum ohne den Sourcecode der Basisklasse machbar.
Das private Interface: Dies Interface umfaßt die internen, dem Nutzer der Klasse verborgenen
Schnittstellen, die zur Implementierung der Klasse benötigt werden.
Bei der Integration kompilierter Komponenten oder Objekte zu einem Softwaresystem steht der
Gedanke des „binären Standards“ im Vordergrund: Zwei unabhängig kompilierte SoftwareKomponenten können zur Runtime in zuverlässiger Weise zusammenarbeiten. Ovum [OvumDO95]
z.B. definiert Componentware folgendermaßen:
32
© GDV 1999
Datenmanager / Anhang
Technologische Aspekte - insbesondere Objektorientierung
Software designed to enable application elements to work together that were constructed
independently by different developers using different languages, tools and computing
environments.
Bei dieser Art der Verwendung werden die Begriffe „Komponente“ und „Objekt“ nahezu synonym
verwendet.

Komponenten stellen ihre Funktionalität über Interfaces zur Verfügung.

Ein Interface beschreibt eine Gruppe logisch zusammengehörender Methoden einer Komponente.

Jedes Interface stellt einen „Vertrag“ zwischen Komponentennutzer und Komponentenprovider
dar.
Damit eine solche Integration von wiederverwendbaren Software-Komponenten oder -Objekten über
System- und Rechnergrenzen hinweg möglich ist, ist die Orientierung und Ausrichtung an
internationalen Standards unabdingbar. Hervorzuheben sind dabei CORBA der Object Management
Group OMG und OLE/COM von Microsoft.
II.1.2. Common Object Requets Broker der OMG
Die OMG ist eine internationale Organisation, die von Herstellern, Softwareentwicklern und
Endbenutzern unterstützt wird (500+ Mitglieder). Die Aufgabe und Ziele der OMG sind die
Entwicklung und Beeinflussung der Technologie in den Bereichen Architektur, Referenz-Modell,
APIs für Objekte und Anwendungen, Distributed Object Management und Object Services.
Die Object Management Group OMG wurde 1989 als non profit Organisation in den USA gegründet
und umfaßt zur Zeit über 500 Mitglieder, praktisch alle bedeutenden Firmen der DV-Industrie sind
vertreten. Diese Organisation arbeitet an der Standardisierung objektorientierter Konzepte und
Technologien, die Interoperabilität und Portabilität von (objektorientierten) Anwendungen in einer
verteilten, heterogenen Umgebung ermöglichen soll. Das gesamte Framework, die technischen Ziele,
die Referenzarchitektur und das konzeptuelle Objektmodell sind im Dokument „Object Management
Architecture Guide“ beschrieben.
II.1.2.1. Object Management Architecture
Das Referenzmodell der OMG, die Object Management Architecture OMA, besteht aus vier
verschiedenen Komponenten bzw. Arten von Komponenten:

Object Request Broker

Object Services

Common Facilities

Application Objects
© GDV 1999
33
Inhalt
Datenmanager / Anhang
Common Facilities
Application Objects
OBJECT REQUEST BROKER
Object services
Abb.: Referenzmodell der OMG
Der Object Request Broker ist der eigentliche Kern der Object Management Architecture und stellt
Mechanismen zur Verfügung, mit denen Objekte auf transparente Weise Anfragen (Requests) senden
und Antworten (Responses) empfangen können. Dabei gewährleistet der ORB Interoperabilität
zwischen Anwendungen auf verschiedenen Rechnern in einer verteilten heterogenen Umgebung sowie
die nahtlose Verbindung multipler Objektsysteme.
Object Services bieten die grundlegende Dienste an, die von den meisten Objekten benötigt werden,
beispielsweise:
Implementation Repository (Mangement von Objektimlpementierungen)
Installation and Activation (Mechanismen zur Verteilung, Aktivierung, Deaktivierung

Interface Repository

Startup Services

Event Notification

Lifecycle (Erzeugen neuer Objekt, Kopieren und Löschen von Objekten)

Concurrency Control (gleichzeitiger Zugriff durch mehrere Clients)

Externalization (Eingabe und Ausgabe des Objektstatus von bzw. in Streams)

Relationship (Unterstützung der Beziehungen zwischen mehreren Objekten)

Transaktions (Transaktionsservice)

Security (Zugriffskontroole auf Objekte)

Time (Zeitsynchonisation in verteilten Systemen)

Licensing

Properties (dynamische Zuordnung von Attributen zu Objekten)

Query (Operationen auf Mengen von Objekten mit Mengen von Objekten als Ergebnis)
34
© GDV 1999
Datenmanager / Anhang
Technologische Aspekte - insbesondere Objektorientierung

Change Management (Konfigurations- und Versionsmanagement)

Trading (Zuordnung von bereitgestellten Services zu benötigten Services eines Clients)

Archive, Backup/Restore ...
Common Facilities bieten allgemeine Dienste an, die in vielen Anwendungen benötigt werden bzw.
nützlich sind (z.B. Drucken, E-Mail, Hilfesystem, usw.).
Application Objects repräsentieren die eigentlichen fachlichen Anwendungskomponenten.
II.1.2.2. Common Object Request Broker Architecture
Die „Common Object Request Broker Architecture (CORBA) and Specification V1.2“ ist die von der
OMG ausgewählte ORB Technologie, die auf einem gemeinsamen Vorschlag von DEC, HP,
HyperDesk, NCR, Object Design und SunSoft basiert. Diese Spezifikation definiert ein Framework
für verschiedene ORB Implementierungen, die einheitliche ORB Services und Interfaces für
portierbare Clients und Objekt-Implementierungen bieten; d.h. CORBA definiert die Services und
Schnittstellen eines ORB, jedoch nicht die Implementierung.
Client
Object Implementation
Request
ORB
Abb.: CORBA Grundprinzip
Objekte, welche Services benützen möchten, werden als Clients und Objekte, welche Services
anbieten, als Object Implementations bezeichnet. Clients nutzen Services durch Senden von Requests
an Object Implementations. Eine Request ist ein Event, welcher Informationen über Zielobjekt,
Operation, Parameter und einen optionalen Request Context enthält.
Die Struktur der ORB Interfaces zeigt das folgendes Bild:
© GDV 1999
35
Inhalt
Datenmanager / Anhang
Client
Dynamic
Invocation
IDL
Stubs
Object Implementation
ORB
Interface
IDL
Skeleton
Object
Adapter
ORB
Interface identical for all ORB implementations
There may be multiple object adapters
Up - call interface
There are stubs and a skeleton for each object type
ORB - dependent interface
Normal call interface
Abb.: ORB Interfaces
Um einen Request abzusetzen, kann der Client einen IDL (Interface Definition Language) Stub oder
das Dynamic Invocation Interface verwenden. IDL Stubs dienen zum Absetzen von Request, falls das
Interface des Zielobjekts zur Compilezeit bekannt ist; dieses Interface ist abhängig vom Interface des
Zielobjekts und damit objekt-spezifisch. Das Dynamic Invocation Interface dient zum Absetzen eines
Request, falls das Interface des Zielobjekts zur Compilezeit nicht bekannt ist; dieses Interface ist
unabhängig vom Interface des Zielobjekts und identisch für alle ORB-Implementierungen.
Der ORB bietet Services bzw. ist zuständig für Aufgaben wie: Request Dispatch, Parameter Encoding,
Delivery, Activation, Synchronization und Exception Handling.
Der Request wird vom ORB über den IDL Skeleton an die entsprechende Objekt-Implementierung
weitergereicht. Zur Nutzung von ORB Services (z.B.: Registrierung von Object Implementations,
Generierung von Object References, Aktivierung von Object Implementations etc.) kommuniziert die
Object Implementation mit dem ORB über den Object Adaptor; dies ist das primäre Interface
zwischen Object Implementation und ORB. IDL Skeletons sind spezifisch bezüglich Object
Implementation und Object Adaptor.
II.1.2.3. ORB-Implementierungen im Vergleich
Es gibt keine CORBA-Referenzimplementierung. Die CORBA-Spezifikation definiert (nicht immer
eindeutig) Funktionalität und Schnittstellen und läßt deren Umsetzung bewußt offen. Deshalb
unterscheiden sich die einzelnen CORBA-Implementierungen nicht nur hinsichtlich ihrer insgesamt
abgedeckten Funktionalität, sondern auch hinsichtlich ihres Verhaltens. In [Hor96] findet man eine
übersichtliche Darstellung einiger Produkte. Hier wird in Kurzfassung auf einige wichtige Produkte
eingegangen:

Object Broker von DEC
Der Objekt Broker ist eine Weiterentwicklung des ACA-Services von DEC. Er hat seine Stärken
bei der Verteilung von Anwendungen auf mehrere Rechner und bei der Integration existierender
Anwendungen. Die objektorientierten Ansätze werden bis V2.5 kaum unterstützt. Der Object
Broker ist auf Open VMS, einigen Unix-Plattformen und Windows NT verfügbar. Für Windows
3.1 und Apple Macintosh gibt es reine Client-Versionen.
36
© GDV 1999
Datenmanager / Anhang
Technologische Aspekte - insbesondere Objektorientierung
Als CORBA-konforme Services werden angeboten: Naming und Security. Zudem gibt es eine
Sprachanbindung an Visual Basic und die Möglichkeit, Server des Object Brokers als OLE-Server
anzusprechen.

Distributed Smalltalk von HP
HP Distributed Smalltalk ist eine Erweiterung der VisualWorks-Entwicklungsumgebung von
ParcPlace um die Möglichkeit, CORBA-konforme Anwendungen zu erstellen. HP Distributed
Smalltalk bietet bereits das CORBA2.0 Interoperabilitätsprotokoll und die CORBA-Services:
Naming, Events, Lifecycle, Relationships, Concurrency und Transactions. Distributed Smalltalk ist
derzeit der ORB für verteilte Smalltalk-Anwendungen.

DSOM IBM
Das Distributed System Object Model DSOM ist im wesentlichen eine Erweiterung von IBMs
System Object Model SOM in Richtung CORBA. Es ist auf OS/2, AIX und Windows verfügbar.
Wie der DEC Object Broker wurde SOM/DSOM ursprünglich nicht als CORBA-Implementierung
konzipiert. Es stand die Entwicklung eines Frameworks für die objektorientierte
Anwendungsentwicklung und nicht der Verteilungsaspekt im Vordergrund. DSOM bietet das
Dynamic Invocation Interface gemäß CORBA V1.2, es werden aber keine CORBA-Services
unterstützt. Allerdings besitzt SOM/DSOM Frameworks, die ähnliche Dienste bereitstellen.

Orbix von IONA
Orbix wurde als reine CORBA-Implementierung entwickelt, seit 1993 sind Versionen verfügbar. Die
aktuelle V1.3 unterstützt unter anderen nahezu alle Unix-Plattformen, Windows 3.1, Windows NT
und OS/2. Orbix unterstützt IDL nach der CORBA1.2-Spezifikation und bietet eine
Sprachanbindung an C++ an.
Orbix versteht sich als ein „schlankes“ Produkt, dessen Vorteile in der Unterstützung vieler
Plattformen, einer Implementierung mit hoher Performance und einer einfachen Benutzbarkeit
liegen. CORBA-Services werden nicht unterstützt. Zusätzliche Leistungsmerkmale erhält Orbix
durch die Integration mit anderen Produkten, die Integration von Microsoft OLE und künftig mit
SUN NEO.

ORBelinevon PostModern Computing
ORBeline ist eine von Grund auf neu entwickelte CORBA-Implementierung, verfügbar auf
mehreren Unix-Plattformen und Windows NT. ORBeline unterstützt die CORBA1.2-IDL-Syntax
und bietet eine C++-Sprachanbindung. ORBeline beinhaltet keine CORBA-Services. Es bietet
lediglich sogenannte „Event Handler“ an, die für alle wichtigen Systemereignisse sowohl auf
Client- als auch auf Implementierungsseite installiert werden können.
ORBeline ist eine leicht zu benutzende CORBA-Implementierung mit wenigen
Leistungsmerkmalen.
© GDV 1999
37
Inhalt

Datenmanager / Anhang
NEO von SUN
Network Enabled Objects NEO (früher unter dem Namen DOE bekannt; das Projekt DOE begann
bereits im Gründungsjahr der OMG) ist die CORBA-Implementierung von Sun Microsystems mit
vielen Leistungsmerkmalen und einer komfortablen Entwicklungsumgebung. Durch abgesichertes
Mulitthreading, viele CORBA-Services (Naming, Events, Properties, Relationships und
Persistency), dazu IDL nach CORBA1.2-Spezifikation, Sprachanbindung an C und C++, CORBAkonformer Implementierung des Basic Object Adapters bietet sich NEO für die Erstellung
komplexer Server-Komponenten an. NEO ist auf Solaris verfügbar und wird auf andere
Plattformen portiert, z.B. SNI-Server-Plattformen.

SORBET von Siemens Nixdorf
Als Mitglied arbeitet Siemens Nixdorf an den fortdauernden Standardisierungsverfahren der OMG
mit und unterstützt die wesentlichen Schnittstellen in den eigenen Produkten. Insbesondere bietet
Siemens Nixdorf mit SORBET eine Weiterentwicklung des von SUN realisierten CORBA1konformen ORB an, und zwar sowohl unter UNIX als auch unter BS2000/OSD. In der nächsten
Version wird SORBET im Rahmen der Realisierung der CORBA2-Funktionalität über das General
Inter-ORB Protocol (GIOP) eine Interoperabilität auch mit anderen CORBA2-konformen ORBs
und mit OLE/COM-konformen Anwendungen unterstützen. Weitere Dienste wie etwa der
Transaktionsdienst werden in SORBET realisiert werden.
II.1.3. Object Linking and Embedding
Das Component Object Model COM von Microsoft beschreibt eine Architektur für objektbasierte
Kommunikation. Diese ist vergleichbar der Funktionalität eines ORB, wenn auch heute noch nicht
verteilt über das Natz. Duch COM wir ein binärer Objektstandard definiert, der alle Objekte nach
außen hin mit einer oder mehreren wohldefinierten Schnittstelle erscheinen läßt und diese
Schnittstellen zur Benutzung durch beliebige andere Objekte freigibt. Dabei ist es gleichgültig, wie
und in welcher Programmiersprache die Objekte entwickelt wurden.
38
© GDV 1999
Datenmanager / Anhang
c
rfa
nte
Technologische Aspekte - insbesondere Objektorientierung
M
eE
I
Int
erf
ac
e
M
M
A
M
M
M
M
M
COM - Objekt
M
M
Interface B
Interface D
M
M
M
M
M
Interface C
Abb.: COM-Objekt
COM legt fest, wie Objekte auf Schnittstellen zugreifen, wie Fehlercodes übertragen und wie
Parameter übergeben werden. COM beinhaltet auch die Möglichkeit, Objekte aus anderen Objekten
zusammenzusetzen.
Object Linking and Enabling OLE ist aus einem Dokumenten-Integrationskonzept entstanden und mit
OLE2 zu einem Integrationskonzept für beliebige Anwendungsobjekte erweitert worden. OLE2
realisiert einen Layer oberhalb von COM, der z.Zt. einen ORB-Mechanismus auf einem WindowsRechner zur Verfügung stellt. Künftig wird mit Distributed OLE eine ORB-vergleichbare
Funktionalität auf Windows-Plattformen auch verteilt im Netz angeboten.
Client
(“Container”)
“Marshaling” über
Prozeßgrenzen
durch (L)RPC
RPC
RPC
Lokales Objekt
im EXE Server
Privates Objekt
Direkter Funktionsaufruf
RPC
In-Proc Objekt
im DLL Server
© GDV 1999
RPC
Remote Objekt
auf anderer
Maschine
“Marshaling” über
Maschinen Grenzen
durch DCE/RPC
39
Inhalt
Datenmanager / Anhang
Abb.: Unterschiedliche OLE-Aufrufbeziehungen
Die wesentlichen Eigenschaften von OLE2 auf Basis des Component Object Models sind:







Compound Document (Inplace-Activation, Visual Editing)
Ein Dokument (Container) bildet die logische Klammer für beinhaltete Komponenten. Ein
Mausklick auf ein eingebettetes Objekt an der Oberfläche wechselt die Umgebung (Menüs,
Toolbars, ...) in die Anwendungsfunktionalität, die zum ausgewählten Objekt gehört.
Drag&Drop
Objekttransfer zwischen verschiedenen Containern oder innerhalb eines Containers einfach
dadurch, daß das Objekt mit der Maus „angefaßt“ und in den anderen Container am Bildschirm
verschoben wird.
Naming and Binding
Naming and Binding stellt die Services zur Verfügung, die den transparenten Zugriff auf die
Schnittstelle der Komponenten realisieren.
Notification
Notification unterstützt den Nachrichtenaustausch zwischen Komponenten.
Structured Storage
Structured Storage realisiert die persistente Speicherung von OLE-Objekten.
Uniform Data Transfer
Uniform Data Transfer löst DDE ab und realisiert den Datenaustausch zwischen OLEKomponenten.
Automation
Automation bietet die Möglichkeit, daß OLE2-Objekte ihre komplette Funktionalität oder Teile
davon über Interfaces nach außen verfügbar machen. OLE2 läßt die Interaktion nicht nur in statisch
gebunden Programmen sondern auch dynamisch zur Laufzeit zu.
Die beiden ersten Komponenten sind User Interface fokussiert, während die restlichen Komponenten
technisch-objektorientierte Funktionalität realisieren.
II.1.4. Bewertung
Microsoft ist Mitglied der OMG, beteiligt sich aber nicht aktiv am Standardisierungsverfahren. OLE2
realisiert vielmehr ein Objektmodell vergleichbar mit dem, wie es von der OMG gefordert wird,
umfaßt dabei alle wichtigen Aspekte einer objektorientierten Architektur und ist pragmatisch. Statt
den OMG-Standard CORBA zu übernehmen, will Microsoft sicherstellen, daß es einen
standardisierten Weg zur Kommunikation zwischen CORBA- und OLE-Objekten gibt. Zudem wird
mit Partnern daran gearbeitet, OLE auf alle gängigen Plattformen zu portieren.
OLE2 ist damit eine allgemeine Integrationstechnologie, auch wenn ihre Herkunft von der
Dokumentenintegration nicht zu leugnen ist und sie zunächst auf die Windows-Plattformen beschränkt
ist. Da gerade für die Windows-Plattform aufgrund ihrer weiten Verbreitung viel Software entwickelt
wird, wird der Markt für Componentware auf dieser Plattform wesentlich schneller wachsen als auf
allen anderen Plattformen. Durch Partnerschaften wie der zwischen Microsoft und Siemens Nixdorf
werden die Anforderungen, die an die Microsoft-Plattform für die Entwicklung großer kommerzieller
Anwendungssysteme gestellt werden, schnellstmöglich befriedigt und so auch betriebswirtschaftliche
40
© GDV 1999
Datenmanager / Anhang
Technologische Aspekte - insbesondere Objektorientierung
Komponenten und Anwendungen auf Basis der Technologien von Microsoft realisiert. Die Anbindung
von Transaktionsmonitoren (z.B. openUTM) über ein OLE-Automation-Interface ist bereits möglich;
der Zugang zu Transaktionsverarbeitung auf Serversystemen ist damit geschaffen.
CORBA richtet sich vorrangig an die Entwickler verteilter objektorientierter Anwendungen auf UnixServern. Die OMG hat mit der CORBA-Spezifikation die Schnittstellen und das Verhalten eines ORB
festgelegt, die Implementierung abe bewußt offen gelassen. Dies hat den Vorteil, daß - obwohl
CORBA erst vor ca. drei Jahren verabschiedet wurde, auf den meisten Plattformen CORBAImplementierungen unterschiedlicher Hersteller vorliegen. Dies hat zur Folge, daß die einzelnen
ORBs auf unterschiedlichen Realisierungsphilosophien beruhen, damit unterschiedliche Stärken und
Schwächen haben. Der Nachteil ist, daß sich eine mit einem spezifischen ORB entwickelte Software
nicht direkt unter einem anderen ORB einsetzen läßt. Eine vollständige Identität aller ORBs ist auch
nicht das primäre Ziel der OMG. Im Vordergrund steht die Kooperation und die Interoperabilität der
einzelnen Komponenten. Deshalb wurde innerhalb der CORBA2.0-Spezifikation ein
Interoperabilitätsprotokoll definiert.
Ob der Einsatz eines ORBs zur Entwicklung unternehmenskritischer großer Anwendungen geboten
erscheint, bedarf einer genauen Prüfung: Kann das Risiko einer neuen Technologie eingegangen
werden? Welche CORBA-Implementierung ist die für den geplanten Einsatzfall richtige. Alle heute
verfügbaren CORBA-Implementierungen lassen noch alle Wünsche offen. Inbesondere bei hohen
Lastanforderungen, vielen Rechnern im Netz, Bedarf an einer Kombination komplexer Services wie
transaktionsbasierten Diensten, garantierter Auslieferung oder Sicherheit sind Machbarkeitsstudien
und Probeimplementierungen anzuraten.
II.2. Objektorientierte Modellierung und objektorientierte
Datenhaltungstechnologien
II.2.1. E/R-Modellierung und objektorientierte Modellierung
In diesem Abschnitt werden die Unterschiede und Gemeinsamkeiten von Entity-RelationshipModellen und Klassen- bzw. Objekt(typ-)modellen erläutert. Die Frage, wie diese beiden Modelltypen
miteinander zusammenhängen, ist von entscheidender Bedeutung, wenn Modelle und
Anwendungssysteme, die in unterschiedlichen Technologien entwickelt sind, als eigenständige
Anwendungskomponenten integriert werden.
Die klassischen Methoden zur Unterstützung der Anwendungsentwicklung sind die Strukturierte
Analyse (SA) zur Beschreibung der "Funktionssicht" und das Entity-Relationship-Modell (ERM) zur
Beschreibung der "Datensicht" eines Informationssystems.
© GDV 1999
41
Inhalt
Datenmanager / Anhang
Abb.: SA und ERM [FeSi93]
Die Trennung von Funktions- und Datensicht beruht auf dem Strukturparadigma imperativer
Programmiersprachen. Danach besteht ein Programm aus einer Algorithmusdefinition und einer
Beschreibung der zugehörigen Datenstrukturen. Für die Strukturierung eines Anwendungssystems
wird klassisch eine erweiterte Form dieses Strukturparadigmas verwendet: Die globale Datenstruktur
des Anwendungssystems wird in Form eines konzeptuellen Datenschemas modelliert. Funktionen benötigen in der Regel nur Ausschnitte aus dem Gesamtschema. Deshalb werden über diesem
konzeptuellen Datenschema externe Schemata (Views) definiert; jedes externe Schema stellt die
"lokale" Datensicht einer Funktion auf die globale Datenstruktur dar.
42
© GDV 1999
Datenmanager / Anhang
Technologische Aspekte - insbesondere Objektorientierung
Die Funktionen sind das Ergebnis einer hierarchischen Zerlegung der Gesamtfunktion des Anwendungssystems. Jede einzelne Funktion wird in Form eines Algorithmus dargestellt und folgt,
zusammen mit dem zugehörigen externen Datenschema, wiederum dem Strukturparadigma
imperativer Programmiersprachen.
Die konzeptuelle Datenmodellierung hat als integraler Bestandteil der Systementwicklung in den
letzten Jahren eine breite Akzeptanz gefunden. Dies wird u.a. deutlich an den Anstrengungen vieler
Unternehmen, sog. "unternehmensweite Datenmodelle" oder "Bereichsmodelle" aufzustellen. Ziel der
konzeptuellen Datenmodellierung ist es, im Rahmen einer Informationsanalyse einen gegebenen
Ausschnitt der Realität in Form eines konzeptuellen Datenschemas zu beschreiben, wobei die Art der
Beschreibung durch das verwendete semantische Datenmodell, derzeit dominieren Modelle auf der
Grundlage des Entity-Relationship-Modells, bestimmt wird.
Ein konzeptuelles Datenschema gemäß ERM besteht aus Datenobjekttypen (Entity-Typen) mit
zugeordneten (Daten-) Attributen, Schlüsselreferenzen zwischen Datenobjekttypen und
Integritätsbedingungen. Die statischen Integritätsbedingungen beschreiben zulässige Ausprägungen
der Daten, dynamische Integritätsbedingungen zulässige Transformationen. Abgesehen von diesen
dynamischen Integritätsbedingungen wird mit Hilfe eines Datenmodells (Entity-Relationship-Modells)
ausschließlich die Datensicht eines Systems beschrieben.
Im Gegensatz dazu beschreibt ein Klassenmodell (bzw. Objekttypenmodell) zusätzlich die
Funktionssicht und die Interaktionssicht eines Systems. Ein Klassenmodell unterstützt somit eine
ganzheitliche, "objektorientierte" Systembeschreibung. Dabei wird jedes Objekt als Instanz
(Ausprägung) einer Klasse (= Objekttyp) aufgefaßt. Eine Klasse wird als abstrakter Datentyp
verstanden, der durch Variablen (Attribute, Daten) und Methoden (Operatoren, Verhalten) beschrieben
wird. Jede Klasse kann als Spezialisierung (Subklasse) einer oder mehrerer Superklassen vereinbart
werden. Dabei vererbt eine Superklasse Variablen und Objektfunktionen (Methoden) an ihre
Subklassen. Die Objekte, also die Instanzen der einzelnen Klassen, interagieren mit Hilfe von
Nachrichten (Botschaften). Eine Nachricht löst beim Empfängerobjekt die Durchführung einer
Objektfunktion aus.
Um die Unterschiede zwischen einem ERM und einem Klassenmodell für die Realisierung einer
fachlichen Funktionalität etwas genauer zu beleuchten, werden unterschiedliche Arten von fachlichen
Objekten unterschieden. Denn die Spezifikation der fachlichen Funktionalität eines
Anwendungssystems differenziert sich bei genauerer Betrachtung (vgl. z.B. [Am93], [Booch93],
[FeSi93], [Ja92]) in die konzeptuelle, die Vorgangs- und die Schnittstellen-Funktionalität:

Die Vorgangs-Objektmodellierung bearbeitet die Fragestellung, welche aus den betrieblichen
Vorgängen ableitbaren und vorgangsspezifischen Eigenschaften ein Anwendungssystem benötigt.
Gegenstand der Vorgangs-Objektmodellierung ist die umfassende und objektorientierte Spezifikation der Vorgangs-Funktionalität eines Anwendungssystems.
Die Vorgangs-Funktionalität realisiert die unmittelbare Vorgangssteuerung und beschreibt das Zusammenwirken von vorgangsspezifischer, konzeptueller, Schnittstellen- sowie rein technischer
Funktionalität bei der Durchführung betrieblicher Vorgänge. Das Ergebnis der VorgangsObjektmodellierung ist ein Schema von Vorgangs-Objekttypen.

Die konzeptuelle Objektmodellierung setzt sich mit der Fragestellung auseinander, welche aus
den betrieblichen Vorgängen ableitbaren und vorgangsneutralen Eigenschaften die Objektbasis des
Anwendungssystems benötigt. Aufgabe der konzeptuellen Objektmodellierung ist die objektorientierte Spezifikation der Struktur des Anwendungssystems, also sowohl der Struktur der Daten
© GDV 1999
43
Inhalt
Datenmanager / Anhang
als auch der darauf operierenden Zugriffsfunktionalität. Ergebnis ist ein Schema konzeptueller
Objekttypen.

Die Schnittstellen-Objektmodellierung bearbeitet die Fragestellung, welche aus den betrieblichen
Vorgängen ableitbaren Schnittstellen-Eigenschaften ein Anwendungssystem benötigt.
Gegenstand der Schnittstellen-Objektmodellierung ist damit die einheitliche, umfassende und objektorientierte Spezifikation der Schnittstellen-Funktionalität eines Anwendungssystems zu der
Verfahrensumgebung; das Ergebnis wird in einem Schema von Schnittstellen-Objekttypen beschrieben. Schnittstellen-Objekttypen dienen also der fachlichen Spezifikation der Mensch-Computer-Kommunikation sowie der Computer-Computer-Kommunikation von Anwendungen.
Die Trennung zwischen konzeptueller Objektmodellierung und Vorgangsobjektmodellierung
unterstützt die Flexibilität des Anwendungssystems durch eine erhöhte Daten- und
Funktionsunabhängigkeit. Schnittstellen-Klassen schaffen einen weitgehend unabhängigen Entwurf
von konkreten Interface-Systemen.
Aufgrund der obigen Erläuterungen wird deutlich, daß das konzeptuelle Datenschema eines ERM
eine Projektion des zugehörigen konzeptuellen Objektschemas in Bezug auf seine Attribute
darstellt. Dadurch wird die Kompatibilität zwischen Objektmodell und Datenmodell gewährleistet, die
durch die folgende begriffliche Zuordnung beschrieben wird:
Datenmodell
Objektmodell
(Daten-) Objekttyp, Entitytyp
Klasse, Objekttyp
(Daten-) Objekt, Entität, Instanz
Instanz, Objekt
Attribut
Instanzvariable, (Instanz-) Attribut
Gegenüber der objektorientierten Modellierung weist der klassische Ansatz (Strukturierte Analyse und
Entity-Relationship-Modellierung) die Defizite auf, die nur durch Umsicht und Erfahrung der
Modellierer ausgeglichen werden können:



44
SA und ERM beschränken sich i.a. auf das Anwendungssystem, also den automatisierten Teil eines
Informationssystems. D.h. eine ganzheitliche Beschreibung der Diskurswelt fehlt; Beziehungen
zwischen Anwendungssystem und seinen umgebenden Teilsystemen, auch personellen
Aufgabenträgern, sind nicht sichtbar. Erfahrene Modellierer wie auch Weiterentwicklungen der
klassischen Ansätze beziehen die Umwelt sowie personelle Aufgabenträger deshalb mit ein.
Datensicht (Datenschemata gemäß ERM) und Funktionssicht (Datenflußdiagramme gemäß SA)
werden weitgehend eigenständig entwickelt; eine Kopplung erfolgt lediglich über View-Schemata,
also externe Sichten auf einen Ausschnitt des Datenschemas. Denn es gibt kein integriertes MetaModell von SA und ERM. Die Abstimmung von Daten- und Funktionssicht wird nicht methodisch
erzwungen, sondern obliegt der Verantwortung und Umsicht der Analytiker und Designer.
Datenmodelle sind deshalb zunächst weniger stabil als Objektmodelle; beim Abgleich von
Funktionssicht und Datensicht sind oft umfangreiche Nacharbeiten erforderlich.
Ein strenges Vorgehensmodell ist ursprünglich für ERM nicht verfügbar. Das Auffinden der
Datenobjekttypen und Beziehungen wird durch Interviews, Textanalysen und Formularanalysen
nur unzureichend unterstüzt. Deshalb wird bei der Datenanalyse zunehmend auch die
Funktionalität in Form von funktionalen Einheiten, Geschäftsprozessen, Geschäftsvorfällen mit
herangezogen, also "objektorientiert" gedacht. Allerdings wird, wenn Szenarien, Geschäftsvorfälle
© GDV 1999
Datenmanager / Anhang
Technologische Aspekte - insbesondere Objektorientierung
in Form von "Walk-Throughs" über den Datenmodellen durchgespielt werden, in der Regel die den
Datenobjekten zuzuordnende Funktionalität nicht dort dokumentiert. D.h. selbst bei ausgereiften
Datenmodellen ist diese Information verschüttet bzw. an anderer Stelle dokumentiert.
II.2.2. Der VAA-Datenmanager im Vergleich zu objektorientierten
und relationalen Datenbankmanagementsystemen
Der VAA-Datenmanager implementiert ein Konzept, das sich in vieler Hinsicht vom Zugriff auf
relationale Datenbanken unterscheidet und Ähnlichkeiten mit dem Zugriff auf objektorientierte
Datenbanken aufweist.
Folgende Ähnlichkeiten des VAA-DM zu objektorientierten Datenbanken existieren:



Der navigierende Zugriff über die Beziehungen im E/R-Modell entspricht dem Zugriff über
Objekt-Assoziationen in der Welt der objektorientierten Datenbanken. (Bei relationalen
Datenbanken geht die Navigation nur über Indizes oder Schlüssel und ist mühsamer als im
objektorienterten Fall)
Die Verwaltung eines Caches (Vorgangsspeicher) ist ähnlich zum Cache bei objektorientierten
Datenbanken. Der Vorgangsspeicher ist Blackboard (für Kommunikation verschiedener
Komponenten untereinander) und Cache in einem. (Der Datenmanager enthält also
Datenbankfunktionalität!)
Ein vererbungsähnliches Konzept kann zur Bildung von einstufigen Subentitäten z. B. für
Spartenspezifika eingesetzt (siehe übernächstes Kapitel) werden.
Daneben gibt es aber viele gravierende Unterschiede, die dem objektorientierten Gedanken
widersprechen:



Durch die Datensicht erhält man eine Daten-getriebene Abarbeitungsfolge der Entities, während
man bei einer objektorientierten Datenbank frei navigiert.
Das fundamentale Konzept der Objektorientierung, Daten und Funktionen zu Objekten zu kapseln,
wird nicht eingehalten.
Es wird kein Information Hiding betrieben, da alle Attribute eines Entities im Vorgangsspeicher für
alle Funktionsbausteine frei zugänglich sind. (Auf Entity-Ebene werden natürlich nur die in der
Datensicht angeforderten und in der Treffertabelle gelieferten Entities bekannt gemacht.)
Im folgenden werden die fundamentalen Unterschiede vom VAA Datenmanager zu relationalen
Datenbanken mit SQL-Abfragesprache aufgelistet:



Die Beschreibungssprache der logischen Datensicht ist auf einem logischen Niveau angesiedelt und
kann auch unterschiedliche Entities mit den zugehörigen Beziehungen in einer Tabelle
zurückliefern.
Die Anwendungsschnittstelle ist unabhängig von der Struktur des physischen Datenmodells
(Indizes, usw.).
Der Abstraktionsgrad beim VAA-Datenmanager ist höher, daher ergibt sich ein potentiell größerer
Wiederverwendungseffekt.
© GDV 1999
45
Inhalt



46
Datenmanager / Anhang
Mit dem VAA-Datenmanager sind keine Joins über verschiedene Tabellen oder Projektionen auf
bestimmte Attribute möglich. Einmal definierte Entities können nicht von der Datensicht
eingeschränkt oder erweitert werden.
Die in den VAA-Datenmanager integrierte Zeitlogik ist bei direkter Implementierung mittels
relationaler Datenbanken nur schwer zu handhaben.
Es gibt beim VAA-Datenmanager keine Selektion von einzelnen Attributen wie in SQL, sondern es
wird immer ein ganzer logischer Rekord abgeliefert, in dem man die wirklich benötigten Attribute
auswählen kann.
© GDV 1999
Datenmanager / Anhang
Technologische Aspekte - insbesondere Objektorientierung
II.2.3. Objektorientierte Zugriffsschichten zu relationalen
Datenbankystemen
Es gibt zwei verschiedene Ansätze, in einer objektorientierten Anwendung auf relationale
Datenbanken zuzugreifen:
1. Objektifizieren der relationalen Datensicht: Bei diesem Ansatz bietet die Zugriffsschicht dem
Anwendungskern Klassen wie „Tabelle“, „Reihe“, „Spalte“ und „Query“. Diese Klassen bilden
eine syntaktische Anbindung an die entsprechenden Konstrukte der relationalen Datenbank. Sie
befinden sich also im Sinne der Schichtenarchitektur eher auf der Ebene des Datenmanagers.
Dieser Ansatz erlaubt zwar den Einsatz einer relationalen Datenbank aus einer objektorientierten
Anwendung heraus, doch können die fachlichen Objekte nicht direkt in der Datenbank gespeichert
werden. Für eine Anwendung, die gemäß den Regeln der objektorientierten Analyse erstellt wurde,
ist dieser Ansatz daher nicht verwendbar.
2. Persistente Objekte: Dieser Ansatz hat zum Ziel, die Lebensdauer von Objekten über die
Lebensdauer des Prozesses zu verlängern, sie also persistent zu machen. Dabei soll der Einsatz der
Datenbank vor dem Anwendungsprogrammierer weitgehend verborgen werden, damit dieser sich
auf die fachlichen Aspekte seiner Arbeit konzentrieren kann. Für die Zugriffsschicht bedeutet das
aber, daß ein Paradigmen-Wechsel implementiert werden muß, also ein Brückenschlag zwischen
den beiden Welten der Objektorientierung und der E/R-Modellierung. Das Konzept der
persistenten Objekte wird auch von den kommerziellen Objektdatenbanken verfolgt. Details zur
Sprachanbindung enthält z.B. Rick G. G. Cattell (Ed.) et al 1993 [ODMG-Standard].
Im folgenden wird der zweite Ansatz beschritten, da nur er die Vorteile objektorientierten Vorgehens
voll ausschöpft.
II.2.3.1. Probleme des Paradigmen-Wechsels
Grundsätzlich erfolgt die Abbildung zwischen Objekten und Tabellen nach dem folgenden Schema:
1 Klasse  1 Tabelle
1 Instanz  1 Zeile
1 Attribut1  1 Feld
Leider birgt diese einfache Abbildung einige Fallen und Probleme, die im folgenden diskutiert
werden.
II.2.3.2. Komplexe Datentypen
Die objektorientierten Programmiersprachen lassen sich anhand ihres Typkonzepts grob in zwei
Klassen unterteilen: Nicht typisierte Sprachen wie Smalltalk und Objective-C und streng typisierte
Sprachen wie Eiffel und (mit Einschränkungen) C++. Letztere verfügen über ein komplexes
Typkonzept mit Ausschnitts- und Verbundtypen, wie es z.B. in PASCAL zur Anwendung kam.
1
In der Literatur werden synonym zum „Attribut“ auch die Begriffe „Instanzvariable“ und „member variable“ verwendet
© GDV 1999
47
Inhalt
Datenmanager / Anhang
Zusätzlich stehen in allen OO-Sprachen Listen, Mengen und ähnliche Konstrukte zur Verfügung, die
in Form von Klassenbibliotheken in das System integriert werden.
Die üblichen Datenbanken kennen hingegen meist nur Zahlen und Zeichenketten in einigen festen
Variationen. Die einzige Möglichkeit zur Strukturierung besteht in der Zusammenstellung von
Tabellen.
Für die Umsetzung zwischen einem objektorientierten Anwendungskern und einer relationalen
Datenbank müssen somit hierarchische Typen „flachgeklopft“ bzw. wieder zusammengefügt werden.
Nachdem Listen, Mengen u.ä. in OO-Sprachen selbst wieder durch Objekte realisiert wird, könnte
man auf die Idee verfallen, sie keiner besonderen Behandlung zu unterwerfen, sondern sie ebenso wie
fachliche Objekte in der Datenbank zu speichern. Datenbanken unterstützen jedoch gerade die Arbeit
mit Massendaten in besonders performanter Weise, so daß solche Konstrukte einer speziellen
Behandlung bedürfen.
II.2.3.3. Objekt-Identität
In relationalen Systemen werden Records innerhalb einer Tabelle einzig über ihren Inhalt identifiziert:
Wenn der Schlüssel eines Records bekannt ist, kann dieser eindeutig gefunden werden und es kann in
einer Tabelle keine zwei Records mit identischem Schlüssel geben. Aus Performancegründen wird
diese Eigenschaft zwar nicht immer von den Datenbanksystemen erzwungen, es gilt jedoch als
schlechte Programmierpraxis, sich auf solche Ausnahmen zu verlassen.
In der objektorientierten Welt besitzen Objekte dagegen eine eigene Identität, unabhängig von ihrem
Inhalt. Dadurch entstehen zwei Probleme:
1. Objekte müssen identifiziert werden. Objektorientierte Programmiersprachen verwenden zu diesem
Zweck üblicherweise Speicheradressen, die aber für eine Speicherung in der Datenbank nicht in
Frage kommen. Statt dessen müssen eigene Datenbank-Identifier vergeben werden, die für das
gesamte System eindeutig sind. (Ein spezielles Problem entsteht, wenn die Datenbank-Tabellen
nicht verändert werden sollen!)
2. Ähnlich den Variablen in einer herkömmlichen Programmiersprache kann es beliebig viele
unterschiedliche Objekte einer Klasse geben, die identischen Inhalt besitzen. Es muß also
sichergestellt werden, daß zwei unterschiedliche Instanzen einer Klasse auch dann in
unterschiedlichen Zeilen der Datenbank gespeichert werden, wenn ihr Inhalt identisch ist.
Umgekehrt muß dafür gesorgt werden, daß mehrfache Lesezugriffe auf die gleiche Zeile auch
immer das gleiche Objekt ergeben. Ein Beispiel möge das Problem erläutern:
Im Rahmen eines Geschäftsvorfalls sind mehrere Vertragsabschlüsse mit dem
gleichen Kunden zu tätigen, wobei das Alles-oder-Nichts-Prinzip gelte. Um eine
Überlastung des Kunden durch das Gesamtpaket zu vermeiden, ist vor dem
Abschluß eines jeden einzelnen Vertrages die Bonität des Kunden zu überprüfen,
wobei die bereits abgeschlossenen Verträge zu berücksichtigen sind. Zur Prüfung
der Bonität wendet sich der Anwendungskern jedes Mal an die Datenbank, um das
Objekt „Kunde xy“ zu holen.
Wenn die Zugriffsschicht in diesem Szenario nicht beachtet, daß bei jedem Zugriff
das bereits anfangs geholte Objekt „Kunde xy“ gefordert ist, sondern sie jedesmal
ein neues Objekt aus der Datenbank holt und im Speicher neu erzeugt, so spiegelt
dieses neue Objekt den Stand in der Datenbank wider, reflektiert also die bisher
abgeschlossenen Verträge nicht: Der Geschäftsvorfall wird fehlerhaft bearbeitet, da
48
© GDV 1999
Datenmanager / Anhang
Technologische Aspekte - insbesondere Objektorientierung
die Vetragsabschlüsse mit einem anderen Objekt durchgeführt werden, als die
Bonitätsprüfungen.
II.2.3.4. Beziehungen zwischen Objekten
Objektorientierte Systeme weisen in der Regel eine große Anzahl relativ einfacher Klassen auf, die
über sehr komplexe Beziehungen mit einander interagieren. Die fachliche Komplexität eines Problems
wird bei objektorientiertem Design nicht so sehr durch komplexe Algorithmen repräsentiert, sondern
eher durch eine enge Verflechtung von Objekten. (Siehe dazu z.B. Sneed 1995, Soukup 1994, Gamma
1991). Zur Modellierung dieser Verflechtung stehen dem Designer eine Fülle verschiedener
Beziehungsformen zur Verfügung, die sich grob gliedern lassen in Aggregation, Referenzen und
verschiedene Anwendungen der Vererbung. Diese Beziehungen zu verfolgen und an ihnen entlang
„Nachrichten zu versenden“ bzw. „Methoden aufzurufen“ ist ein wesentliches Element
objektorientierter Programmierung.
Relationale Systeme unterstützen Beziehungen dagegen nur in Form der Fremdschlüssel-Beziehung.
Diese werden mit Hilfe von Joins verfolgt, also der aufwendigsten Operation in relationalen
Datenbanken! Hier muß man besondere Vorsicht walten lassen.
Ein wichtiger Schritt ist hier (wie üblich) die Denormalisierung des Datenmodells, indem von der
einfachen Formel 1 Klasse  1 Tabelle abgewichen wird. Dies ist insbesondere bei Aggregationen
sinnvoll:
In den meisten OO-Systemen existiert eine eigene Klasse zur Darstellung des Datums.
Würde in diesem Falle nicht denormalisiert, so erhielte man eine eigene Tabelle, in der
alle Datumsangaben der Datenbank gespeichert werden. Daß ein solches Design nicht
sinnvoll sein kann, ist intuitiv klar.
Zu beachten ist auch, daß Beziehungen in objektorientierten Sprachen immer unidirektional sind, also
gerichtet, während Fremdschlüssel-Beziehungen in relationalen Systemen immer in beiden
Richtungen verfolgt werden können. Insbesondere 1:n-Beziehungen lassen sich in objektorientierten
Systemen nur mit zusätzlichem Aufwand implementieren, indem z.B. Listen von Referenzen
eingesetzt werden.
II.2.3.5. Vererbung und Polymorphismus
Vererbung und Polymorphismus sind zwei zentrale Elemente des objektorientierten Paradigmas.
Gamma (Gamma 1991) unterscheidet z.B. fünf verschiedene Formen der Vererbung, andere Autoren
kommen zu ähnlichen Ergebnissen. Die gute Wartbarkeit eines geschickt entworfenen OO-Systems ist
insbesondere der Möglichkeit zu verdanken, verschiedene, ähnliche Klassen durch Polymorphismus
wie eine Klasse behandeln zu können.
Relationale Systeme sehen diese Möglichkeit nicht vor. Zwar bietet die E/R-Modellierung die
Möglichkeit, sog. „Is-A-Beziehungen“ zu formulieren, doch die meisten Datenbank-Systeme sehen
dafür keine direkte Implementierung vor.
Das Problem der Umsetzung zerfällt bei genauerer Betrachtung in zwei Teilprobleme:
© GDV 1999
49
Inhalt
Datenmanager / Anhang
1. Vererbung von Attributen: Eine Klasse besitzt nicht nur „ihre eigenen“ Attribute, sondern auch
noch ihres Vaters, ihres Großvaters usw. Diese Hierarchie muß in der Datenbank abgebildet
werden.
2. Dynamisches Binden: Der Zugriff auf Objekte soll auch über ihre Supertypen erfolgen können. So
wünscht man sich z.B., einen Kunden aus der Datenbank holen zu können, unabhängig davon, ob
es sich um einen Privatkunden oder um einen Geschäftskunden handelt. Trotzdem soll ein Objekt,
das aus der Datenbank geholt wurde, vom korrekten (Sub-)Typ sein, da z.B. die Bonitätsprüfung
eines Privatkunden anders implementiert ist als die eines Geschäftskunden.
Die Zugriffsschicht muß also sowohl die Vererbungshierarchie kennen, als auch den exakten Typ
eines Objekts, das sich in der Datenbank befindet. Sie muß in der Lage sein, Objekte typrichtig zu
erzeugen.
II.2.3.6. Allgemeine Probleme
Die oben beschriebenen Anforderungen ergeben sich direkt aus der Abbildung der unterschiedlichen
Konzepte aufeinander. Um eine Zugriffsschicht auch praktisch einsetzen zu können, sollten noch
einige weitere Forderungen aufgestellt werden, deren Ziel vor allem darin besteht, die Handhabung
der Zugriffsschicht bei der Entwicklung so einfach wie möglich zu gestalten.
II.2.3.7. Transaktionskonzept
Objektorientierte Programmierung läßt sich sehr gut kombinieren mit dem Einsatz grafischer
Bedienoberflächen. Diese Oberflächen entfalten ihren vollen Nutzen bei hoch interaktiven
Anwendungen, die dem Anwender große Freiheiten in der Bedienerführung anbieten müssen. Ein
typischer Vertreter dieser Anwendungen ist z.B. ein Management-Informations-System, welches das
Management über die betriebswirtschaftlichen Kennzahlen des Unternehmens informiert oder
Beratungssysteme, die Außenmitarbeiter dabei unterstützen, für den Kunden optimale Angebote zu
erarbeiten.
Im Gegensatz dazu stehen typische Transaktionssysteme, die darauf optimiert sind, sehr genau
definiert Geschäftsvorfälle stark parallelisiert abzuarbeiten. Systeme zur Auftragsbearbeitung oder
Buchhaltungssysteme sind hier typische Vertreter.
Für diese unterschiedlichen Anforderungen muß die Datenbank unterschiedliche Arten von
Transaktionen zur Verfügung stellen:
1. Optimistische Transaktionslogik: Bei stark interaktiven Anwendungen werden wenige Anwender
eine großen Datenmenge über einen langen Zeitraum analysieren, um dann eine einzelne
Entscheidung zu fällen, die zu wenigen Schreibzugriffen führt. Die Bereiche, für die ein einzelner
Anwender zuständig sind, überlappen sich nur wenig. Es handelt sich also um langlaufende
Transaktionen, die auf große Bereiche einer Datenbank lesend zugreifen. Um Deadlocks und
unnötige Sperren zu vermeiden, wird hier meist so vorgegangen, daß die Daten während der langen
Analysephase nicht gesperrt werden. Erst wenn der Anwender seine Entscheidung getroffen hat
und die Transaktion dadurch beendet, wird geprüft, ob in der Zwischenzeit andere Anwender die
Daten verändert haben. In diesem Falle muß der Anwender den (statistisch seltenen) Konflikt
auflösen.
50
© GDV 1999
Datenmanager / Anhang
Technologische Aspekte - insbesondere Objektorientierung
2. Pessimistische Transaktionslogik: Hier werden die Daten bereits beim Lesen gegen Änderungen
durch andere Anwendungen gesperrt, was Kollisionen von vornherein vermeidet. Solche Sperren
sollten jedoch nur für kurze Zeit gehalten werden, da sonst der Zugriff durch andere Prozesse
spürbar beeinträchtigt würde. Im Extremfall sind Szenarien denkbar, in denen die Prozesse nur
noch sequentiell auf die Datenbank zugreifen können, da jeder Prozeß die gleichen Daten sperrt.
Da die Wahl der Transaktionslogik von der jeweiligen Anwendung abhängt, sollte die Zugriffsschicht
beide Möglichkeiten bieten. Wenn nur die pessimistische Transaktionslogik vom Datenmanager
angeboten wird, so muß die optimistische Variante in der objektorientierten Zugriffsschicht
implementiert werden.
II.2.3.8. Transparenz bei der Programmierung
Relationale Datenbanken stellen ein eigenes Konzept dar, das unabhängig ist von der
Programmiersprache.2 Objektorientierten Datenbanken und Zugriffsschichten liegt hingegen die Idee
der persistenten Objekte zugrunde, die sich nahtlos in die Programmierung einfügt. Daher ist die
Forderung sinnvoll, daß sich der Anwendungscode von persistenten Objekten nicht unterscheidet von
dem transienter Objekte. Die Funktionen der Datenhaltung sollten mit den üblichen Mitteln der
Programmiersprache formuliert werden, Spracherweiterungen sollten vermieden werden.
Diese Forderung wird auch von allen marktüblichen Objektdatenbanken erfüllt (s. nächsten
Abschnitt): Spracherweiterungen werden von ihnen nur zur Definition des Datenbankschemas
eingesetzt.
II.2.3.9. ODMG-Verträglichkeit
Die Object Data Management Group (ODMG) ist ein Gremium der führenden Hersteller von
Objektdatenbanken, welches sich in Zusammenarbeit mit der Object Management Group (OMG)
bemüht, die Schnittstellen von Objektdatenbanken zu standardisieren. Ein erster Vorschlag wurde
1993 veröffentlicht (Rick G. G. Cattell (Ed.) et al 1993 [ODMG-Standard]), der mittlerweile als de
facto Standard akzeptiert ist.
Der ODMG-Standard beschreibt verschiedene Aspekte der Datenbanken:

Das „Language Binding“, also das API. Derzeit sind Bindings für C++ und Smalltalk festgelegt.
Eine Anbindung für OO-COBOL ist nicht in Planung, derzeit finden lediglich
Sondierungsgespräche zwischen der ODMG und Herstellern von OO-COBOL-Compilern statt.3

Die „Object Definition Language“ ODL. Diese ist angelehnt an die „Interface Definition
Language“ der OMG und beschreibt die Klassen in einer C++-ähnlichen Syntax.

Die „Object Query Language“ OQL, eine Abfragesprache ähnlich embedded SQL. Sie bildet eine
Alternative zu den Abfragemöglichkeiten des Language Binding.
In der Theorie läßt sich das dadurch begründen, daß SQL eine „deklarative“ Sprache ist, ähnlich PROLOG: Der Programmier
formuliert nur das Ziel, also wie das Ergebnis aussehen soll, der Weg dorthin wird vom Compiler ermittelt. Alle gängigen AnwendungsSprachen sind hingegen „ablauforientiert“, sie definieren also den Weg zum Ziel, nicht das Ziel selbst.
2
Auskunft von Doug Barry, ODMG Executive Director: „The ODMG does not have a workgroup for this binding. There has only
been some very preliminary discussions with OOCOBOL vendors. Nothing official.“
3
© GDV 1999
51
Inhalt
Datenmanager / Anhang

Die „Object Management Language“ OML, welche ähnlich SQL die Datenpflege unterstützt.

Festlegungen zur Funktionalität, wie Versionsführung, geschachtelte und lange Transaktionen.
Im Rahmen der VAA ist es nicht sinnvoll, alle diese Leistungen zu implementieren. Die
Programmierschnittstelle der Zugriffsschicht sollte sich jedoch möglichst an das ODMG Language
Binding der entsprechenden Sprache halten. Dies erspart zum einen die ansonsten notwendigen
Konzeptarbeiten und erleichtert zum anderen den Programmierern die Einarbeitung in die
Zugriffsschicht, da sie auf ausreichende Standardliteratur zurückgreifen können.
II.2.4. Beispielhafte Modellierung bei einer Versicherung
Bei der Württembergischen Versicherung wird das Vorbild des VAA-Datenmanagers, der sogenannte
Datensichtprozessor bereits seit einigen Jahren eingesetzt. Begleitet wird der Einsatz des
Datensichtprozessors bei den Sachsparten durch organisatorische Maßnahmen, die eine
Vereinheitlichung des Unternehmens-Datenmodells zulassen. Dadurch entstand eine Abstraktion auf
relativ wenige Entity-Typen, die untereinander in Beziehung stehen. Diese Beziehungen können auch
für eine bestimmte Sparte leer sein. Zur Abbildung von Spartenspezifika werden die allgemeinen
Entities um ein Spartenflag und spartenspezifische Attribute, aber keinesfalls um weitere Beziehungen
ergänzt. Damit wird praktisch ein einstufiges Vererbungskonzept (OO-Konzept) auf Datenebene mit
dem Datenmanager implementiert.
In der Anwendung des Datensichtprozessors bei der Württembergischen Versicherung werden
Entities mit ca. 10 bis 200 Attributen eingesetzt. Mittels der Datensichtsprache kann über
spartenunabhängige Beziehungen mittels Selektionskriterien, die auch spartenabhängig sein können,
navigiert werden.
Die interne Strukturierung von Entities ist dem Daten-Manager primär egal. Sie muß aber dem
Anwendungs-Baustein bekannt gegeben werden, damit es auf die gewünschten Attribute zugreifen
kann. (Bei der Württembergischen geht das indirekt über eine globale Tabelle, die dynamisch
aufgebaut wird, so daß bei Erweiterungen und Umstrukturierung der Attribute die einzelnen
Funktionsbausteine nicht neu kompiliert werden müssen)
Hieraus ergibt sich natürlich ein Problem aus der Datenmodellierung: Nicht jedes
Versicherungsunternehmen ist in der Lage, seine verschiedenen Sparten so homogen, wie bei der
Württembergischen inzwischen üblich, zu behandeln. (Wie leicht ist es möglich, möglichst viele
Spartenspezifika durch „Gleichschaltung“ aller Sparten zu eliminieren?)
II.2.5. VAA-Datenmanager: Warum nicht alles in objektorientierter
Technologie
Der navigierende Zugriff auf Entities über den Vorgangsspeicher ist sicher dem Zugriff über einen
guten Cache sehr ähnlich. Ein Konzept von gekapselten Datentypen ist bisher nicht vorgesehen. Die
Idee, Komponenten verschiedenster Hersteller zusammen in einer Anwendung einzusetzen, läßt sich
wohl nur dann verwirklichen, wenn harte Typ- und Zugriffsprüfungen vorgesehen sind. (Smalltalk ist
auch nicht Typ-orientiert, aber nach der Instanziierung besitzt jede Variable durch ihren Wert einen
festen Datentyp, den man auch prüfen kann!) Das Konzept des Datenmanagers abstrahiert sicher einen
52
© GDV 1999
Datenmanager / Anhang
Vorschläge zur Realisierung von Historienkonzepten
großen Teil der Datenbankzugriffe, kann vorerst aber noch nicht komplett die Ablösung des
Datenmanagers von den Lieferanten der Funktionsbausteine bewerkstelligen.
Bisher ist das fundamentale Performance-Problem beim Zugriff bei Massentransaktionen, die
objektorientiert implementiert sind, noch ungelöst. Deshalb kann man auch keine uneingeschränkte
Empfehlung für den Einsatz objektorientierter Technologien in allen Lebenslagen geben.
III. Vorschläge zur Realisierung von
Historienkonzepten
Die vorliegende Ausarbeitung diskutiert den Themenbereich der zeitabhängigen Speicherung von
Entitätszuständen. Neben einer allgemeinen theoretischen Diskussion wird ein Verfahren zur
Abbildung von Zeitabhängigkeiten in Tabellen vorgeschlagen und diskutiert.
Alle Algorithmen sind beispielhaft und reflektieren nicht unbedingt die performanteste
Vorgehensweise. Aus Gründen der Klarheit sind auch keine Fehlersituationen berücksichtigt.
Beispiele für Abfragen beziehen sich auf relationale Systeme und SQL. Die Klarheit der Darstellung
geht vor der syntaktischen Korrektheit der dargestellten SQL-Abfragen.
III.1. Einleitung und Problemstellung
Im Versicherungsunternehmen fallen häufig Daten an, deren Änderungen im Laufe der Zeit
nachvollzogen werden müssen. Dies sind insbesondere Informationen über rechtlich wirksame
Vertragskonstellationen. So sind vergangenheitsbezogene Daten zur Prüfung von
Deckungsansprüchen z.B. bei nachträglicher Schadenmeldung zu verwenden. Dieser Themenkomplex
wird mit dem Schlagwort Historisierung tituliert.
Unter zeitabhängiger Datenspeicherung wird die Speicherung von verschiedenen zeitlichen Zuständen
einer Entität verstanden. Generell lassen sich folgende Kategorien unterscheiden:

Daten der Zukunft

aktuelle Daten

vergangene oder historische Daten
Im Sprachgebrauch wird der Begriff Historie unterschiedlich verwendet. Wir beschreiben eine
Historie als die Veränderungen der Attribute einer Entität in der Vergangenheit. Da allerdings abhängig von aktuell verwendeten Datum - ein verwendbares Historienkonzept auch die aktuellen wie
mögliche zukünftige Daten erfassen sollte, wird als Historienkonzept eine Methode zur zeitabhängigen
Speicherung von Daten in Datenbanken verstanden. Von dieser Problematik ist der häufig synonym
verwendete Begriff des Archivs abzugrenzen. Ein Archiv nimmt vollständige Entitäten auf, enthält
also gegebenenfalls auch die notwendigen zeitlichen Zustände.
Die Datenmodellierung betrachtet normalerweise nur eine Zeitebene. Zeitliche Zustände innerhalb
einer Entität werden allenfalls über Zuständsübergänge betrachtet, die mit den entsprechenden
Statuskennzeichen eine eigenständige Modellierung von zeitlich diskreten Zuständen als Entitätstypen
erlauben. So werden abgeschlossene Mahnverfahren z.B. in einem eigenständigen Archiv abgelegt
© GDV 1999
53
Inhalt
Datenmanager / Anhang
oder über entsprechende Mahnstufen gekennzeichnet. Historisierung wird erst dann zu einem
Problem, wenn ein logisches Datenmodell in physische Strukturen überführt wird. Ein logisches
Datenmodell darf keine historisierenden Elemente außer natürlich den erwähnten Statuskonzepten und
notwendigen Archiven besitzen. Allenfalls kann es Informationen über den Bedarf einer zeitlichen
Speicherung beinhalten.
In der Realität der physischen Datenspeicherung ist die Speicherung zeitlicher Entitätszustände
allerdings in vielen Fällen notwendig. Beispiele sind:

Vergangene, aktuelle und zukünftige Vertragszustände

Zustände, auf denen Änderungen aufgesetzt werden.

Verfolgung von sich zeitlich entwickelnden Attributwerten.
Die zeitabhängige Speicherung von Entitätsattributen kann zur Erfüllung verschiedener
Anforderungen konzipiert werden.


Der (rechtlich wirksame) Stand der Entitätsattribute muß zu jedem Zeitpunkt rekonstruiert werden
können. Damit müssen auch Werte, die im Nachhinein überschrieben worden sind, nachvollziehbar
sein. Derartige Qualität wird z.B. für das Nachvollziehen von Deckungszusagen im Schadenfall
benötigt.
Es müssen nur die derzeit gültigen Werte eines vergangenen, aktuellen oder zukünftigen
Zeitabschnitts bekannt sein. Werte, die im Nachhinein geändert worden sind, können nicht
rekonstruiert werden. Sie werden durch den resultierenden aktuellen Zustand ersetzt. Beispiele für
derartige Anforderungen sind Parametertabellen.
III.2. Der Änderungsbaum einer Entität
Der elementare Zugang zu einer Darstellung zeitlicher Abhängigkeiten in Datenbanksystemen ist der
Baum möglicher Änderungen einer Entität. Eine Entität nimmt im Laufe ihres Lebens neue Zustände
bzw. neue Attributwerte an. Diese Zustände sind für einen bestimmten Zeitraum, der Gültigkeitsdauer
bzw. dem Gültigkeitsabschnitt, relevant. Zur Beschreibung von Gültigkeitsabschnitten sind die
Attribute Beginn- und Endezeitpunkt notwendig. Je nach geforderter Genauigkeit können für diese
Attribute Zeitstempel oder Datumsfelder verwendet werden. Nicht bekannte Zeitpunkte werden
physisch z.B. als maximale/minimale Feldinhalte dargestellt. Der Endezeitpunkt muß größer oder
gleich dem Beginnzeitpunkt sein. Die Gültigkeitsabschnitte überlagern sich nicht, da jede Entität zu
einem Zeitpunkt einen eindeutigen Zustand besitzt. Gültigkeitsabschnitte können mathematisch als
rechts offene Intervalle aufgefaßt werden. Sie werden im folgenden mit [GB,GE) bezeichnet. Dieses
Intervall repräsentiert den Gültigkeitsabschnitt, der für alle Zeitpunkte Z1 mit GB <= Z1 < GE) die
gültigen Attributwerte beinhaltet.
Generell sind zwei Änderungsarten zu unterscheiden:

54
Fortschreibungen: Dies sind Änderungen des letzten gültigen Zustands eines Pfades, die den
aktuellen Zweig fortsetzen. Fortschreibungen sind nur dann möglich, wenn der Beginn des neuen
Abschnitts nach dem Ende bzw. wenn bei undefiniertem Endezeitpunkt der Beginn des neuen
Zustands nach dem Beginn des letzten gültigen Abschnitts liegt.
© GDV 1999
Datenmanager / Anhang

Vorschläge zur Realisierung von Historienkonzepten
Rückwirkende Änderungen, die einen neuen Zweig aufbauen. Derartige Änderungen liegen
immer dann vor, wenn Beginn- oder Endezeitpunkte geändert werden müssen, die nicht minimal
oder maximal (offen) sind.
Die während der Lebenszeit einer Entität auftauchenden Gültigkeitsabschnitte können als Baum von
aufeinander aufbauenden Zuständen aufgefaßt werden. Dieser Änderungsbaum wird im folgenden
Beispiel veranschaulicht. Es wird von
Gültigkeitsfolgen ohne zeitliche Lücken
i
j
k
l
Pfad C
ausgegangen. Dies kann jedoch nicht immer
vorausgesetzt werden.
f
g
h
Pfad B
Der Änderungsbaum wird von links nach
a
b
c
d
e
Pfad A
rechts und von unten nach oben
fortgeschrieben. Aktuell ist immer der obere
a
b
c
d
e
Gültigkeitsfolge A
Pfad mit all seinen Knoten. Ausgehend von
rückw irkende Änderung
dem Zustand (a) einer Entität werden die
Zustände (b) - (e) im Zuge der Zeit
a
b
f
g
h
Gültigkeitsfolge B
eingefügt. Hierdurch wird der Pfad A
rückw irkende Änderung
gebildet der durch die Gültigkeitsfolge A
a
i
j
k
l
Gültigkeitsfolge C
repräsentiert wird. Im Pfad B und C werden
durch rückwirkende Änderungen bereits
bestehende Zustände überschrieben. Daraus
Abb.: Änderungsbaum einer Entität
resultieren die dann jeweils aktuellen
Gültigkeitsfolgen B und C. Nach den letzten Änderungen ist dann die Gültigkeitsfolge C aktuell.
© GDV 1999
55
Inhalt
Datenmanager / Anhang
III.3. Der Begriff der Historie
Unter dem Begriff einer Historie werden alle Gültigkeitsabschnitte zu einer Entität gesehen. die in
einem Änderungsbaum auftreten können. Dies umfaßt sowohl vergangene, rückwirkend geänderte,
aktuelle und zukünftige Zustände der Attribute einer Entität. Als Archiv wird ein Speicher für alle
überschriebenen Pfade des Änderungsbaums oder alle nicht mehr direkt relevante Entitätszustände
verstanden.
Am obigen Beispiel können die verschiedenen Formen von Historisierung verdeutlicht werden:
1. Keine Historisierung:
Es ist jeweils der letzte geänderte Stand der Entität verfügbar. Der jeweils vorherige Zustand
wird überschrieben und steht somit nicht mehr zu Verfügung.
2. Abschnittshistorie (Eindimensionale Historisierung):
Alle Änderungszustände eines Pfades stehen zu Verfügung. Falls Gültigkeitszeiträume
verändert werden müssen, gehen die Informationen über die Gültigkeitsabschnitte des
vorhergehenden Pfades verloren.
3. Vollständige Historie (Zweidimensionale Historisierung):
Alle Änderungszustände aller Pfade stehen zu Verfügung. Es kann zu jeder Zeit festgestellt
werden, welcher Entitätszustand zu welcher Zeit der Vergangenheit gültig war.
Die obigen Formen bilden die Grundformen einer Historisierung, aus denen sich noch besondere
Spezialfälle ableiten lassen. So kann die Abschnittshistorie noch danach unterschieden werden, ob
zeitliche Lücken, Überlagerungen von Gültigkeitszeiträumen oder keine Lücken oder Überlagerungen
zugelassen sind.
III.4. Die (eindimensionale) Abschnittshistorie
Die einfachste Form der Historisierung ist die eindimensionale Historisierung der Abschnittshistorie,
die aus der Aneinanderreihung von Gültigkeitsabschnitten einer Entität entsteht. Zwischen den
einzelnen Abschnitten sind Lücken erlaubt. Dies repräsentiert die Aussage, daß zu diesem Zeitpunkt
keine Informationen vorliegen. Zu jedem Gültigkeitszeitpunkt ist genau ein oder kein Zustand der
Gültigkeitsfolge aktuell. Überlagerungen von
zugelassen.
Mit dieser Form der Historisierung können
verschiedene aktuelle Zustände einer Entität
dargestellt werden. Wie eine vorherige
Gültigkeitsfolge ausgesehen hat, ist nicht
bekannt.
Die Abbildung zeigt ein Beispiel von
Gültigkeitsabschnitten einer Entität. Die
einzelnen Gültigkeitsabschnitte entstehen durch
Einfügen neuer Datensätze, die jeweils mit
56
Veränderungszeitpunkt
Gültigkeitsabschnitten sind somit nicht
1
2
01.01.95
01.03.95
3
4
Gültigkeit des Datensatzes
Gültigkeitsabschnitte
1
15.04.95
2
31.07.95
33
offen
44
Abb.: Gültigkeitsabschnitte einer Entität
© GDV 1999
Datenmanager / Anhang
Vorschläge zur Realisierung von Historienkonzepten
einem fachlichen Beginndatum und einem Endedatum versehen worden sind. Beim Einfügen eines
neuen Zustands wird der Endezeitpunkt des vorherigen und der Beginnzeitpunkt eines eventuell
vorhandenen Folgezustandes entsprechend verändert. Die vorher vorhandenen Datumsangaben sind in
diesem einfachen Verlaufsmodell dann nicht mehr verfügbar, da sie überschrieben worden sind. Die
offenen Zustände werden durch entsprechende minimale oder maximale Datumsangaben realisiert.
Zur allgemeinen Darstellung einer Abschnittshistorie werden jeweils ein Beginn- und Endezeitpunkt
als zusätzliche Attribute benötigt. Da keine Überlagerungen von Gültigkeitsabschnitten zugelassen
sind, muß der Übergang vom Ende eines Gültigkeitsabschnitts auf den Beginn des nächsten
Gültigkeitsabschnitts festgelegt werden. Dies wird am einfachsten dadurch erreicht, daß ein
Gültigkeitsabschnitt als rechts offenes Intervall definiert wird. Durch diese Definition kann der
Beginnzeitpunkt eines Gültigkeitsabschnitts auf den Endezeitpunkt des vorherigen
Gültigkeitsabschnitts gesetzt werden. Dies vermeidet unnötige Datums- bzw. Zeitberechnungen. Somit
ergibt sich die folgende Definition der Zusatzattribute:
GÜLTIG_AB
Beginnzeitpunkt der fachlichen Gültigkeit der Entitätsattribute für die
verarbeitenden Anwendungen.
UNGÜLTIG_AB
Endezeitpunkt der fachlichen Gültigkeit der Entitätsattribute für die
verarbeitenden Anwendungen.
Entitätsattribute sind somit zum Zeitpunkt T1 gültig in einem Gültigkeitsabschnitts, wenn folgende
Bedingung erfüllt ist:
GÜLTIG_AB <= T1 < UNGÜLTIG_AB
Diese Bedingung gilt solange, wie keine Überlagerungen von Gültigkeitsabschnitten zugelassen sind.
III.4.1. Die lückenlose Abschnittshistorie
Eine Sonderform der Abschnittshistorie liegt dann vor, wenn keine Lücken zwischen den einzelnen
Gültigkeitsabschnitten zugelassen werden. Zu jedem Zeitpunkt zwischen Beginn des frühesten
Zustands und dem Ende des letzten Zustands sind Informationen über die Attributwerte vorhanden.
Ungültige Zustände müssen durch fachliche Attribute kenntlich gemacht werden. Der Endezeitpunkt
eines Gültigkeitsabschnittes ist dann immer identisch mit dem Beginnzeitpunkt des folgenden
Gültigkeitsabschnitts. Somit könnte auf das Attribut UNGÜLTIG_AB verzichtet werden, da ein
Gültigkeitsabschnitt immer durch das Beginndatum des Folgeabschnitts ungültig wird. Der Vorteil
dieser Lösung liegt in der einfachen Einfügung neuer Zustände in eine Gültigkeitsfolge, sofern kein
bereits vergebener Zeitpunkt verwendet wird. Nachteilig ist der erhöhte Ermittlungsaufwand bei der
Ermittlung der Gültigkeitsgrenzen, da immer der Folgesatz interpretiert werden muß. Dies
widerspricht insbesondere der Philosophie relationaler Datenbanksysteme, die von einer gegenseitigen
Unabhängigkeit der einzelnen Entitäten eines Entitätstyps ausgehen. Auch sind Schwierigkeiten bei
© GDV 1999
57
Inhalt
Datenmanager / Anhang
der Darstellung bei der Begrenzung der Gültigkeit des letzten Gültigkeitsabschnitts zu erwarten, der
dann ja per Definition immer unbegrenzt gültig sein muß.
III.4.2. Beispiele für Abschnittshistorien


Schlüsselwerte, die in bestimmten Zeiten gültig, in anderen ungültig sind.
Schlüsselwerte, die in bestimmten Zeiten gültig sind, für die jedoch in anderen Zeiten keine
Informationen vorliegen.
III.4.3. Realisierung im Relationenschema
Am Beispiel eines relationalen Schemas wird die Verwendung einer Abschnittshistorie diskutiert. In
hierarchischen Datenbanken können performante Lösungen unter Umständen einfacher gestaltet
werden.
Da für eine Entität mehrere Zeitzustände gespeichert werden müssen, reicht der eigentliche
Primärschlüssel der Entität nicht mehr als eindeutiger Schlüssel der physischen Tabelle aus. Der
Primärschlüssel muß durch ein zustandsidentifizierendes Feld ergänzt werden. Dazu wird das Attribut
GÜLTIG_AB verwendet. Zusätzlich wird das Attribut UNGÜLTIG_AB als Attribut aufgenommen, so
daß sich folgender Aufbau ergibt:
Tabelle (
Primärschlüssel,
GÜLTIG-AB,
UNGÜLTIG-AB,
Attribute ...)
Auf dieser Tabelle sind mindestens die grundlegenden Operationen Selektion, Löschen und Einfügen
zu definieren. Ergänzend können noch weitere Operationen betrachtet werden. Zu beachten ist, daß die
folgenden Operationen sich stets auf eine konkrete Entität mit Ihren Zuständen beziehen.
Alle Algorithmen sind beispielhaft und reflektieren nicht unbedingt die performanteste
Vorgehensweise. Aus Gründen der Klarheit sind auch keine Fehlersituationen berücksichtigt.
Beispiele für Abfragen beziehen sich auf relationale Systeme und SQL. Die Klarheit der Darstellung
geht vor der syntaktischen Korrektheit der dargestellten SQL-Abfragen.
III.4.4. Überlagerungskonflikte einer Abschnittshistorie
Der Aufbau einer Abschnittshistorie ist nicht so einfach, wie es auf den ersten Blick scheinen mag.
Insbesondere die Erhaltung der Überlagerungsfreiheit von Zuständen führt zu aufwendigen
Dateioperationen, um möglicherweise entstehende Überlagerungen zu beseitigen.
Die folgende Tabelle beschreibt die Überlagerungsmöglichkeiten und bietet einen Vorschlag zur
Beseitigung der entstehenden Konflikte. Konsistenzerhaltende Operationen auf einer
Abschnittshistorie müssen je nach Situation die vorgeschlagene Lösung realisieren.
58
© GDV 1999
Datenmanager / Anhang
Vorschläge zur Realisierung von Historienkonzepten
Tabelle: Überlagerungsmöglichkeiten beim Einfügen in eine Abschnittshistorie
Beginnüberlagerung
Endeüberlagerung
neu
neu
Nachfolger
Vorläufer
Vorläufer
neu
neu
Beginnüberlagerung mit Lücken
neu
Nachfolger
Endeüberlagerung mit Lücken
neu
Vorläufer
Nachfolger
Vorläufer
neu
neu
Beginnüberlagerung mit
Lückenbeseitigung
neu
Nachfolger
Endeüberlagerung mit
Lückenbeseitigung
neu
Vorläufer
Nachfolger
Vorläufer
neu
neu
vollständige Einbettung
neu
neu
vollständige Überlagerung
neu
Vorläufer
Vorläufer
Nachfolger
Zustand alt
Nachfolger
neu
Besonders hervorzuheben ist der Fall der vollständigen Einbettung eines neuen Zustands in einen
vorhandenen Zustand. In diesem Fall ist es nämlich notwendig, den Vorläufer anzupassen und ihn
zusätzlich als neuen Nachfolger einzufügen.
In der Diskussion der Operationen auf einer Abschnittshistorie wird auf die möglichen Situationen und
die Möglichkeiten zur Konfliktbeseitigung detaillierter eingegangen.
III.4.5. Grundoperationen einer Abschnittshistorie
Zur Verarbeitung einer Abschnittshistorie sind eine Reihe von Operationen denkbar, die jeweils nicht
durch Kombination der anderen Operationen abgebildet werden können (Orthogonalität). Diese
© GDV 1999
59
Inhalt
Datenmanager / Anhang
Operationen sind ohne Berücksichtigung eventueller fachlicher Zugriffe zu betrachten. Zur
Erinnerung: Es existieren keine Überlagerungszustände in einer Abschnittshistorie.

SELEKTIEREN(T1, DATEN):

Selektion eines Zustands [GB,GE) zu einem Gültigkeitszeitpunkt T1. Dies betrifft alle Zustände, für
die der Gültigkeitszeitpunkt die Bedingung GB <= T1 < GE erfüllt:

Zur Ermittlung eines eindeutigen Entitätszustandes ist immer ein Zeitpunkt anzugeben, zu dem die
jeweils gültigen Attribute ermittelt werden sollen. Die notwendige Abfrage für relationale Systeme
lautet dann:

SELECT * FROM Tabelle
WHERE Primärschlüssel
AND GÜLTIG_AB
AND UNGÜLTIG_AB
=
<=
>
Schlüsselwert
T1
T1.


EINFÜGEN(GB, GE, DATEN):

Ein neuer Gültigkeitszustand [GB,GE) wird eingefügt.



LÖSCHEN(T1, T2):
Löschen von vollständig enthaltenen Zuständen [GB,GE) einer Abschnittshistorie zwischen den
Zeitpunkten T1 , T2. Die zu löschenden Sätze müssen folgende Bedingung erfüllen: T1 <= GB und
GE <= T2
Die obigen Zugriffe sind nicht konsistenzerhaltend. Wenn der Anwender nicht entsprechende
Zeitpunkte vorgibt, können z.B. Überlagerungen entstehen.
III.4.6. Abgeleitete Operationen einer Abschnittshistorie
Dieser Abschnitt enthält Vorschläge für weitere nützliche Operationen, die die eigentlichen
konsistenzwahrenden Bearbeitungsoperationen vereinfachen.

ANPASSEN(T1, GB, GE, DATEN):

Änderung der Beginn- und Endezeitpunkte des zur Zeit T1 existierenden Gültigkeitszustands
[GB,GE) auf den neuen Beginnzeitpunkt GB und den neuen Endezeitpunkt GE.

Nicht zu verändernde Beginn- oder Endezeitpunkte werden durch „*“ gekennzeichnet.


60
VORLÄUFER(GB, DATEN):
= SELEKTIERE(GB-1, DATEN) bei einer lückenlosen Abschnittshistorie
© GDV 1999
Datenmanager / Anhang
Vorschläge zur Realisierung von Historienkonzepten

Gültigkeitsabschnitt [GBV,GEV) vor einem Gültigkeitsabschnitt [GB,GE) ermitteln. Der Vorläufer
eines Gültigkeitszustands bezeichnet den zeitlich direkt vorangehenden Satz einer Tabelle. Der
Vorläufer wird durch das maximale Beginndatum identifiziert, welches gerade noch kleiner als das
Beginndatum GB ist.

Um den vorangehenden Zustand zu ermitteln, muß unterschieden werden, ob eine
Abschnittshistorie mit oder ohne Lücken vorliegt, da bei einer lückenlosen Historie performanter
zugegriffen werden kann. In diesem Fall braucht nur das Beginndatum des aktuellen Zustands - 1
als neuer Gültigkeitszeitpunkt der Selektion benutzt zu werden. Falls Lücken vorliegen, ist jeweils
der Zustand mit maximalem Beginndatum aller früheren Zustände zu finden. Ein derartiger Zugriff
kann z.B. durch SQL-Mittel oder durch sequentielles Lesen einer nach Beginnzeitpunkten
absteigend geordneten Liste erfolgen.


NACHFOLGER(GE, DATEN):
= SELEKTIERE(GE, DATEN) bei einer lückenlosen Abschnittshistorie

Gültigkeitsabschnitt [GBN,GEN) nach einem Gültigkeitsabschnitt [GB,GE) ermitteln Der Nachfolger
eines Gültigkeitszustands bezeichnet den zeitlich direkt folgenden Satz einer Tabelle. Der
Nachfolger wird durch das minimale Beginndatum identifiziert, welches gerade noch größer oder
gleich dem Endedatum GE ist.

Um den nachfolgenden Zustand zu ermitteln, muß unterschieden werden, ob eine
Abschnittshistorie mit oder ohne Lücken vorliegt, da bei einer lückenlosen Historie performanter
zugegriffen werden kann. In diesem Fall braucht nur das Endedatum des aktuellen Zustands als
neuer Gültigkeitszeitpunkt der Selektion benutzt zu werden. Falls Lücken vorliegen, ist jeweils der
Zustand mit minimalem Beginndatum aller späteren Zustände zu finden. Ein derartiger Zugriff
kann z.B. durch SQL-Mittel oder durch sequentielles Lesen einer nach Beginnzeitpunkten
aufsteigend geordneten Liste erfolgen.


ZUSTANDSFOLGE(T1,T2, DATENTABELLE):

Zustandsfolge zwischen zwei Zeitpunkten T1 < T2 ermitteln

Diese Funktion kann durch eine einfache Selektion unter Angabe der begrenzenden Zeitpunkte und
der gewünschten Sortierfolge realisiert werden. Es muß nur beachtet werden, daß nicht nur die
vollständig enthalten Gültigkeitsabschnitte gelesen werden. Die Abfrage könnte wie folgt lauten:

SELECT * FROM Entitätstyp
WHERE Primärschlüssel
=
Schlüsselwert
AND UNGÜLTIG_AB
>
T1
AND GÜLTIG_AB
<=
T2
ORDER BY GÜLTIG_AB ABSTEIGEND


Ein Spezialfall dieser Operation ist die Ermittlung der vollständig zwischen den Zeitpunkten
enthaltenen Gültigkeitsabschnitte. Hierzu sind die entsprechenden Abfragebedingungen
anzupassen:

SELECT * FROM Entitätstyp
WHERE Primärschlüssel
© GDV 1999
=
Schlüsselwert
61
Inhalt
Datenmanager / Anhang
AND GÜLTIG_AB
>=
T1
AND UNGÜLTIG_AB
<=
T2
ORDER BY GÜLTIG_AB ABSTEIGEND
III.4.7. Konsistenzwahrende Operationen einer Abschnittshistorie
Alle oben beschriebenen Änderungsoperationen sind nicht konsistenzwahrend. Inwieweit zum
Beispiel Lücken oder Überlagerungen entstehen, ist Sache des Anwenders dieser Operatoren.
Deshalb werden im folgenden noch einige konsistenzwahrende Operationen beschrieben, die unter
bestimmten Annahmen stets Abschnittshistorien ohne Überlagerung und - falls gefordert - ohne
zeitliche Lücken erzeugen.
Alle Algorithmen sind beispielhaft und reflektieren nicht unbedingt die performanteste
Vorgehensweise. Aus Gründen der Klarheit sind auch keine Fehlersituationen berücksichtigt.
Beispiele für Abfragen beziehen sich auf relationale Systeme und SQL. Die Klarheit der Darstellung
geht vor der syntaktischen Korrektheit der dargestellten SQL-Abfragen.

ÜBERSCHREIBEN(GB,GE, DATEN):

Überschreiben von Zuständen mit den neuen Intervallgrenzen [GB,GE) mit Anpassung der eventuell
vorhandenen Zeitabschnitte, die den Bereich [GB,GE) nach Einfügung überlagern würden.

Die Tabelle: Überlagerungsmöglichkeiten beim Einfügen in eine Abschnittshistorie enthält die
möglichen Überlagerungskonflikte, die im Zuge der Überschreibungsoperation beseitigt werden
müssen.

Der Algorithmus in der AbbAlgorithmus zur
Einfügung eines Zustands mit Lücken
beschreibt die Vorgehensweise bei
Überschreibung durch einen neuen Zustand.
Diese Form des Algorithmus berücksichtigt
auch den Fall der vollständigen Einbettung.
Überlagerungen werden durch
entsprechende Korrekturen der Beginn und
Endezeitpunkte beseitigt. Lücken zwischen
dem Vorläufer und dem Nachfolger des
neuen Gültigkeitsabschnitts werden nicht
erkannt bzw. beseitigt. Falls keine Lücken
erlaubt sind, sind zwei Reaktionen möglich:
62
Ermittle Zustandsfolge(GB,GE)
Verarbeite alle ermittelten Gültigkeitsabschnitte [GB1,GE1)
| alten Zustand [GB1,GE1) merken
| Gültigkeitsabschnitt in Tabelle löschen
| Falls GB in [GB1,GE1) Einfügen alten Zustand mit Ende GB
| Falls GE in [GB1,GE1) Einfügen alten Zustand mit Beginn GE
 Beseitigung von Lücken / Prüfung auf Lücken
Einfügen des neuen Gültigkeitsabschnitts
Änderungen bestätigen.
Abb.: Algorithmus zur Einfügung eines Zustands mit Lücken
© GDV 1999
Datenmanager / Anhang




Vorschläge zur Realisierung von Historienkonzepten
Die Operation wird als fehlerhaft
zurückgewiesen
Die betreffenden Gültigkeitsabschnitte werden
angepaßt
Beispielhaft wird in der AbbAlgorithmus zur
Beseitigung von Lücken bei Einfügung ein
Algorithmus zur Beseitigung von Lücken durch
Anpassung des Vorläufers und des Nachfolgers
aufgezeigt.
Entscheidend ist bei der Einfügung neuer
Zustände, daß die Beginn- und Endezeitpunkte der
einzelnen Zustände auch nach der Änderung keine
Überlagerungen von Zeitabschnitten erzeugen.
© GDV 1999
...
VORLÄUFER(GB)
Falls GB > GEV ANPASSEN(GEV,*,GB)
| alten Zustand in Tabelle löschen
| alten Zustand mit Ende GB einfügen
NACHFOLGER(GE)
Falls GE < GBV ANPASSEN(GBV,GE,*)
| alten Zustand in Tabelle löschen
| alten Zustand mit Beginn GE einfügen
...
Abb.: Algorithmus zur Beseitigung von Lücken bei
Einfügung
63
Inhalt
Datenmanager / Anhang

FORTSCHREIBEN(GB, DATEN) = ÜBERSCHREIBEN(GB, offen, DATEN):

Einfügen eines neuen Zustands mit den Intervallgrenzen [GB, offen) ab dem Beginnzeitpunkt GB.

Der Algorithmus in der AbbAlgorithmus
zur Fortschreibung einer Abschnittshistorie
mit Lücken beschreibt die grundsätzliche,
optimierte Vorgehensweise. Alle eventuell
vorhandenen vollständigen Überlagerungen
werden beseitigt. Falls ein Vorläufer
existiert, muß sein Endezeitpunkt korrigiert
werden, wenn er in dem neuen Zustand
enthalten ist. Zum Abschluß wird der neue
Zustand eingefügt und die Änderungen
werden bestätigt.
LÖSCHE(GB, offen)
vollständige Überlagerungen löschen
ANPASSEN(GB, unverändert, GB)
Teilüberlagerung anpassen
EINFÜGEN(GB, offen)
Änderungen bestätigen.
Abb.: Algorithmus zur Fortschreibung einer Abschnittshistorie mit Lücken
LÖSCHE(GB, offen)
vollständige Überlagerungen löschen
ANPASSEN(VORLÄUFER(GB), GB)
Erweitern Vorläufer
EINFÜGEN(GB, offen)
Änderungen bestätigen.
Abb.: Algorithmus zur lückenlosen Fortschreibung einer Abschnittshistorie

Mit den obigen Grundoperationen lassen sich
die notwendigen Datenoperationen abbilden. Dazu gehört der Aufbau von neuen Gültigkeitsfolgen wie
auch die Korrektur vorhandener Daten. Vorstellbar sind Komfortfunktionen, die z.B. den Zustand
einer kompletten Gültigkeitsfolge anhand einer Tabelle von Gültigkeitsabschnitten verändern.
III.5. vollständige (zweidimensionale) Historisierung
Bei Verwendung einer Abschnittshistorie gehen Informationen verloren, wenn die Zeiteinteilung einer
Gültigkeitsfolge durch rückwirkende Änderungen geändert wird. Auch geänderte Attribute eines
Gültigkeitsabschnittes können nicht mehr rekonstruiert werden. In diesem Abschnitt wird ein
allgemeines Verfahren vorgestellt, welches jede Änderung zu jedem Zeitpunkt nachvollziehbar und
rekonstruierbar macht. Der vorher diskutierte Fall der Abschnittshistorie erweist sich als Spezialfall
der vollständigen Historisierung.
Zur hinreichenden Beschreibung der zeitlichen Aspekte von Datensätzen reicht ein
Gültigkeitsabschnitt mit Aussagen über fachliche Gültigkeit nicht aus. Es sind grundsätzlich zwei
Zeitdimensionen notwendig:




64
Aussagen über die Gültigkeit des Datensatzes in der Datenbank. Durch diese Angabe wird der
Zeitraum konkretisiert, in dem die Daten überhaupt einzelnen Anwendungen bekannt sein können.
Diese Dimension wird im folgenden als Kenntnisstand der Datenbank oder kurz als
Kenntnisstand bezeichnet.
Aussagen über die fachliche Gültigkeit der im Datensatz enthaltenen Daten. Durch diese Angaben
wird konkretisiert, ob die von einer Anwendung gefundenen Daten überhaupt verarbeitet werden
dürfen.
Diese Dimension wird im folgenden als Gültigkeitszeitraum eines Datensatzes oder kurz als
Gültigkeitszeitraum bezeichnet.
© GDV 1999
Datenmanager / Anhang
Vorschläge zur Realisierung von Historienkonzepten
Kenntnisstand der Datenbank
Ein Historienkonzept muß beide
Zeitdimensionen entsprechend den jeweiligen
Anforderungen berücksichtigen. Damit ergibt
sich folgendes Bild: Das grau schattierte
31.12.99
2
3
Rechteck beschreibt die Gültigkeit der Daten
des Datensatzes sowohl aus Sicht der
Datenbank wie auch aus Sicht der
Anwendung. Außerhalb des Kenntnisstands
der Datenbank findet die Anwendung keinen
gültigen Datensatz mehr. Das
Zugriffsverhalten muß so arbeiten, als ob
31.12.94
1
4
kein Datensatz mehr vorhanden ist. Wird
01.01.95
31.12.96
Gültigkeit des Datensatzes
jedoch ein Datensatz gefunden, liefert der
Gültigkeitszeitraum des Datensatzes die
Abb.: Gültigkeitsdimensionen
fachliche Relevanz der enthaltenen Daten.
Um das Gültigkeitsrechteck abzubilden, werden jeweils Beginn und Ende der hier betrachteten
Gültigkeitsdimensionen (Gültigkeitsabschnitte) als zusätzliche Attribute benötigt:
KENNTNIS_AB
Beginn des Vorhandenseins des Datensatzes in der
Datenbank. Dies Datum wird maschinell gefüllt
(Einfügezeitpunkt)
UNKENNTNIS_AB
Ende des Vorhandenseins des Datensatzes in der
Datenbank.
GÜLTIG_AB
Beginn der fachlichen Gültigkeit der Datensatzinhalte
für die verarbeitenden Anwendungen.
UNGÜLTIG_AB
Ende der fachlichen Gültigkeit der Datensatzinhalte für
die verarbeitenden Anwendungen.
Je nach geforderter Genauigkeit sind entsprechende Datenformate vorzusehen. In der Regel reicht bei
der fachlichen Gültigkeit Tagesgenauigkeit. Deshalb kann als Format der entsprechenden Attribute
„DATE“ verwendet werden. Beim Kenntnisstand der Datenbank reicht Tagesgenauigkeit in der Regel
nicht aus. Deshalb wird hier als Format ein Zeitstempel mit hinreichender Genauigkeit verlangt
(„TIMESTAMP“). Offene Zeitpunkte werden durch ein minimales bzw. maximales Datum dargestellt.
In der betrieblichen Praxis eines Versicherungsunternehmens wird davon ausgegangen, daß
Datensätze, die in operativen Bestandsdatenbanken eingestellt werden, unbegrenzt gespeichert
werden. Deshalb wird in der Regel die UNKENNTNIS_AB als offen gekennzeichnet werden. Da bei
Einfügen eines neuen Datensatzes dieses Attribut nicht geändert werden darf - Informationsverlust aus
Zugriffssicht wäre die Folge - kommt es bei Einfügungen neuer Zustände zu Überlagerungen der
einzelnen Rechtecke. Dies bedeutet in der Praxis, daß bei entsprechendem Zugriff mehr als ein
Datensatz gefunden werden kann. Deshalb muß eine (zeitliche) Ordnung innerhalb der einzelnen
Rechtecke definiert werden, um festzustellen, welche Rechtecke andere Rechtecke überlagern. Da
gefordert werden kann, daß der KENNTNIS_AB niemals das aktuelle Datum bei Einfügung
unterschreiten kann, enthält dieses Attribut die gewünschte Information über die zeitliche
Einfügereihenfolge der einzelnen Datensatzzustände.
© GDV 1999
65
Inhalt
Datenmanager / Anhang
Aus Sicht der heute eingesetzten Datenbanken wie z.B. DB2 ist eine derartige Überlagerung von
zeitlichen Zustände mit der daraus resultierenden Selektion des vom Betrachtungszeitpunkts jüngsten
Datensatzes ein aufwendiger Zugriff, der vermieden werden sollte. Im IMS entstehen derartige
Probleme aufgrund des hier grundsätzlichen sequentiellen Zugriffs bei entsprechender
Einfügereihenfolge nicht. Ein Zugriff mit einem definierten Kenntnisstand K1 und einem definierten
Gültigkeitsdatum G1 sollte immer auf einfache Weise einen eindeutigen Datensatz mit den zu diesen
Koordinaten gültigen Attributen einer physischen Entität liefern.
Mit dem obigen Modell lassen sich grundsätzlich Fragen der Art beantworten:
„Welche Werte waren zu einem bestimmten Gültigkeitszeitpunkt G1 und zu einem bestimmten
Kenntniszeitpunkt K1 für eine bestimmte physische Entität technisch bekannt bzw. verfügbar?“
offen
Kenntnisstand der Datenbank
Die folgende Abbildung beschreibt die Darstellung
von Änderungen einer physischen Entität in einer
historisierten Datenbank. Da dies zu
Informationsverlusten führt, dürfen bei einer echten
Historienführung keine alten Daten überschrieben
werden. Deshalb überlagern sich die einzelnen
Zustände. Bei Einfügung des Satzes (3) existieren
weiterhin die Zustände (1) und (2), da sie nicht
geändert werden dürfen. Ein lesender Zugriff liefert
somit ohne ein weiteres Ordnungskriterium stets
mehrere Datensätze, die nicht auseinander gehalten
werden können. Deshalb muß ein Attribut verwendet
werden, um die Reihenfolge der Einfügung in die
Datenbank festzuhalten. Hierzu kann das Attribut
KENNTNIS_AB verwendet werden. Nur so kann der
derzeit gültige Datensatz ermittelt werden (siehe
oben).
2
3
15.06.95
01.03.95
1
31.12.94
01.01.95
31.12.96
31.12.96
offen
Gültigkeit des Datensatzes
Abb.: Zustandsänderungen einer physischen Entität im Zeitverlauf
III.5.1. Beispiele

juristisch wirksame Vertragsdaten
III.5.2. Beispieloperationen
Die hier beschriebenen Operationen beschränken sich auf einige Beispiele, mit einer vollständigen
Historie umzugehen. Die notwendigen Operationen sind aufgrund der zu beseitigenden
Überlagerungen nicht trivial. Die elementare Grundoperationen sind die Ermittlung des aktuellen
Zustands und seiner tatsächlichen Datumsgrenzen und die Ermittlung der zu einem Pfaden des
Änderungsbaums vorliegende Abschnittshistorien. Auf diese Abschnittshistorien können dann die für
Abschnittshistorien definierten Grundoperationen angewendet werden.
66
© GDV 1999
Datenmanager / Anhang
Vorschläge zur Realisierung von Historienkonzepten

SELEKTIERE-ÜBERLAGERUNG(G1, K1, DATEN)

Aktuellen Zustand [GA,GE) zum Kenntnisstand K1 und Gültigkeitsdatum G1 ermitteln

Zur Ermittlung des aktuellen Zustands der Datenbank sind zwei Zeitpunkte notwendig. Der
aktuelle Zustand [GA,GE) zur Zeitkoordinate (K1,G1) muß folgende Bedingung erfüllen:


GA <= G1 < GE)

KA <= K1 < KE)
Da als Ergebnis mehrere Datensätze in Frage kommen können, muß noch der zuletzt eingefügte
Zustand über den maximalen Beginnkenntniszeitpunkt aller Zustände zum Kenntnisstand ermittelt
werden. Damit ergibt sich folgende Selektion:

SELECT * FROM Tabelle A
WHERE Primärschlüssel
=
Schlüsselwert
AND GÜLTIG_AB
<=
G1
AND UNGÜLTIG_AB
>
G1
AND KENNTNIS_AB
<=
K1
AND UNKENNTNIS_AB
>
K1
AND KENNTNIS_AB
= SELECT MAX(KENNTNIS_AB) FROM Tabelle B
WHERE B.Primärschlüssel
=
A.Primärschlüssel
AND KENNTNIS_AB
<=
K1
AND UNKENNTNIS_AB
>
K1)


SELEKTIERE-ABSCHNITTE (K1, DATENTABELLE)

Abschnittshistorie zu einem gegebenen Kenntnisstand ermitteln

Unter der Annahme der lückenlosen und in die Zukunft offenen Speicherung ergibt sich ein
einfacher Algorithmus, der darauf basiert, das der Zeitpunkt UNGÜLTIG_AB des direkt
vorangehenden Zustands gleich dem Zeitpunkt GÜLTIG_AB des aktuellen Zustands ist. Gleiches
gilt für den Folgezustand bezogen auf den Endezeitpunkt. Damit kann der Pfad ausgehend vom
aktuellen Zustand durch Selektion der Vorläufer anhand des Endezeitpunkts einfach ermittelt
werden.

SELEKTIERE-ÜBERLAGERUNG(offen,K1)
DO WHILE noch Daten da
| SELEKTIERE-ÜBERLAGERUNG(,GA-1,K1)
| IF gefunden GE = GA
| END


Ergebnis ist eine lückenlose Abschnittshistorie zum vorgegebenen Kenntnisstand.
III.6. Vereinfachung des allgemeinen Verfahrens aus
praktischer Sicht
Die in der Praxis zu verwendende Historisierungstechnik bewegt sich Spannungsfeld der Forderungen:

Speicherplatzminimierung
© GDV 1999
67
Inhalt

einfache Zugriffe

Nachvollziehbarkeit
Datenmanager / Anhang
In diesem Spannungsfeld gilt es einen tragfähigen Kompromiß zu finden, der aus der Sicht der
üblichen VU-Anwendungen sowohl die Forderung nach der notwendigen Nachvollziehbarkeit wie
auch die Forderung nach geringem Ressourcenverbrauch erfüllt.
III.6.1. Vorschlag zur Umsetzung des Historienkonzepts
Das gravierendste Hindernis für eine praktikable Lösung der oben diskutierten vollständigen
Historisierung ist die Überlagerung von zeitlichen Zuständen einer Entität. Deshalb ist diese
Eigenschaft durch eindeutige Zustände zu einem Gültigkeits- und Kenntniszeitpunkt zu ersetzen.
Damit wird der Zugriff auf die Daten wesentlich vereinfacht. Allerdings verkompliziert sich das
Einfügen neuer Zustände, da ja immer schon vorhandene Zustände entsprechend angepaßt werden
müssen. Die Forderung nach absoluter Nachvollziehbarkeit führt in diesem Fall zu einem sehr stark
anwachsenden Speicherbedarf, da bei jeder Änderung stets ein neuer Änderungspfad aufzubauen und
einzufügen ist. Deshalb muß die obige Einschränkung durch eine Regelung ergänzt werden, die
zumindest für die häufigste Operation der Fortschreibung eines vorhandenen Zustands nur einen neuen
Satz in die Datenbasis einstellt. Dies wird allerdings nicht ohne Informationsverluste vonstatten gehen
können. Eine praktikable Umsetzung des Historienkonzepts legt also seine Schwerpunkte auf die
Kriterien Speicherplatzminimierung und einfache Zugriffe auf Kosten der absoluten
Nachvollziehbarkeit. Die Nachvollziehbarkeit darf allerdings nur soweit eingeschränkt werden, daß
die Geschäftsprozesse eines VU weiterhin adäquat unterstützt werden können.
Eine Umsetzung des Historienkonzepts ist auf der Basis folgender Alternativen möglich:

Feldweise Historisierung

Zeilen- oder tabellenorientierte Historisierung

Geschäftsobjektorientierte Historisierung
Wir werden nur die tabellenorientierte Historisierung betrachten, die auf der Ebene der physischen
Entitäten wirkt. Bei Änderung von Attributen einer physischen Entität wird jeweils ein neuer Zustand
als Tabellenzeile aufgebaut. Alle anderen Alternativen sind auf der Anwendungsebene nicht
praktikabel. Allenfalls als integrierte Funktionalität in Datenbanksystemen sind derartige Lösungen
effizient realisierbar.
Folgende Grundannahmen liegen dem vorgeschlagenen Verfahren zugrunde:

Sämtliche Zustände einer physischen Entität werden ohne Überlagerungen gespeichert.

Die einzelnen Kenntnisstände folgen lückenlos aufeinander.

Die einzelnen Gültigkeitsabschnitte folgen lückenlos aufeinander.

Es dürfen nur in die Zukunft offene Zeitpunkte geändert werden.

Jede neue zukünftige Zeitangabe ist immer offen.

Eine Historisierung erfolgt immer auf der Ebene der physischen Entität.
68
© GDV 1999
Datenmanager / Anhang

Vorschläge zur Realisierung von Historienkonzepten
Das Attribut KENNTNIS_AB wird immer auf den aktuellen Zeitpunkt gesetzt.
III.6.1.1. Tabellenorientierte Speicherung
Ziel ist der Aufbau einer überlagerungsfreien Darstellung der einzelnen Zustände einer physischen
Entität. Dazu wird wie folgt verfahren:


Bei Einfügen eines neuen Zustands zu einer physischen Entität wird der Endezeitpunkt des
Überlagerungskandidaten auf den jeweiligen Beginnzeitpunkt des neuen Zustands gesetzt. Als
Konstrukt wird also eine Abschnittshistorie mit Fortschreibung für die Gültigkeitszeiträume
gewählt. Rückwirkende Änderungen, die keine Lücken auffüllen, führen zu einer Einfügung eines
neuen Pfades
Bei Einfügung eines neuen Pfades werden alle vorhandenen Pfade entsprechend durch Setzen des
Attributs UNKENNTNIS_AB auf den Einfügezeitpunkt des neuen Pfades beendet.
Damit wird eine lückenlose und überlagerungsfreie Zustandsfolge erreicht, sofern man das Attribut
KENNTNIS_AB unberücksichtigt läßt.
In relationalen Systemen kann eine historisierte Tabelle wie folgt aufgebaut werden:
Tabelle (
primary key-attribute,
KENNTNIS_AB,
UNKENNTNIS_AB,
GÜLTIG_AB,
UNGÜLTIG_AB,
fachliche Attribute)
Die jeweiligen Vorschläge für die Attribute des Primärindex sind unterstrichen. Die vorgeschlagene
Indexwahl ist natürlich nur bei einer überlagerungsfreien Speicherung mit Sicherheit eindeutig. Mit
dieser Indexwahl werden die im folgenden diskutierten Zugriffe effizient ausgeführt.
Die obige Art der Historisierung erlaubt eine effiziente Aufteilung der Daten nach Zugriffshäufigkeit.
Vergangene Pfade könnten z.B. in einer separaten Tabelle abgelegt werden, so daß in der eigentlichen
Tabelle nur die zum Tageszeitpunkt gültigen Zustände abgelegt werden. Diese Vorgehensweise
erlaubt natürlich einen effizienteren Indexaufbau und effizientere Zugriffe in der aktuellen Tabelle, da
z.B. auf das Attribut UNKENNTNIS_AB, welches ja immer offen ist, verzichtet werden kann. Wir
erhalten bei dieser Vorgehensweise eine lückenlose Abschnittshistorie für die aktuellen Zustände und
eine Historientabelle mit allen vergangenen Pfaden und ihren einzelnen Zuständen.
Um das vereinfachte Verfahren näher zu betrachten werden beispielhaft die folgenden,
konsistenzerhaltende Grundoperationen erläutert:
1. Fortschreibung bzw. Auffüllen eventueller Lücken eines Pfades
2. Einfügen eines neuen Pfades im Falle rückwirkender Änderungen
3. Löschung eines bestehenden Pfades
© GDV 1999
69
Inhalt
Datenmanager / Anhang
III.6.1.1.1. Fortschreibung eines bestehenden Änderungspfads
Es wird immer der letzte Zustand eines
Änderungspfades fortgeschrieben. Dabei wird
vorausgesetzt, daß der letzte Zustand immer in
offen
Zukunft offenen Zustand fortgeschrieben wird.
Die Fortschreibung beendet den bisher
aktuellen Zustand, indem sein UNGÜLTIG_AB
Attribut auf den Beginnzeitpunkt des neuen
15.06.95
Zustands gesetzt wird. Für diese häufigste
Operation in VU-Anwendungen wird kein
zusätzlicher Speicherplatz zur Abspeicherung
Kenntnisstand der Datenbank
die Zukunft offen ist und durch einen in die
2
Informationsverlust
1
Informationsverlust
31.12.94
alter Pfadzustände benötigt. Allerdings geht hier
Gültigkeit des Datensatzes
Information über in den in der Vergangenheit
01.01.95
01.03.97
offen
gültigen Änderungspfad verloren, so daß
korrekte Ergebnisse nur für einen
Kenntniszeitpunkt der Datenbank ermittelt
1
31.12.94
15.06.95
1
Zustand alt
Zustand
neu
2
werden können, der nach dem Einfügezeitpunkt
der Fortschreibung liegt. Dies führt zu der
akzeptablen Einschränkung, daß hier nur mit
Abb.: Fortschreiben eines Pfades einer vollständigen Historie
dem aktuellen Zeitpunkt zugegriffen werden
darf, wenn man korrekte Ergebnisse erhalten will. Dies hängt damit zusammen, daß der letzte aktuelle
Pfadzustand beendet wird, somit für Gültigkeitszeitpunkte nach diesem Zustand keine Informationen
mehr vorliegen. Man kann allerdings die Tatsache ausnutzen, daß nur von offenen Endezeitpunkten
auf konkrete Endezeitpunkte geändert werden darf, um gegebenenfalls den vorherigen Zustand z.B.
manuell zu rekonstruieren. Dies setzt impliziert allerdings die Forderung nach zusätzlicher
Attributierung für kurzfristige Zustände, die ansonsten eventuell durch eine konkrete Endesetzung
abgebildet werden könnte.
Alle anderen Änderungen der Gültigkeitsabschnitte erzwingen den Aufbau eines neuen Pfades, sofern
sie keine Lücken im Zeitablauf auffüllen. Diese Situation tritt natürlich bei einer lückenlosen
Speicherung außer bei Einfügung eines vor dem ersten Zustand liegenden Gültigkeitsabschnitts nicht
auf. Die oben beschriebene Vorgehensweise erzeugt allerdings lückenlose Abschnittshistorien
innerhalb eines Pfades.
Zur Verarbeitung eines Pfades mit seinen Gültigkeitsabschnitten oder Zuständen können die für die
Abschnittshistorie verwendeten Operationen verwendet werden.
Der letzte Zustand eines Änderungspfades kann stets durch Abfrage auf den Zustand mit offenem
Endezeitpunkt ermittelt werden. Beispielhaft wird hier die Abfrage in relationalen Systemen
aufgeführt:
SELECT *
FROM tabelle
WHERE key = entity-key
70
© GDV 1999
Datenmanager / Anhang
Vorschläge zur Realisierung von Historienkonzepten
AND UNGÜLTIG_AB = offen
Dies setzt natürlich voraus, daß mindestens ein in die Zukunft offener Zustand existiert. Anderenfalls
ist der Pfad leer und enthält keinen Zustand.
III.6.1.1.2. Einfügen eines neuen Änderungspfads
Jede Änderung der Pfadeinteilung,
sofern sie keine Lücken auffüllt und
sofern sie keine Fortschreibung des
Einfügung eines neuen Pfades in die
Historie. Dies geschieht dadurch,
daß der UNKENNTNIS_AB Zeit-
15.06.95
punkt auf den Einfügezeitpunkt des
neuen Pfades gesetzt wird. Dies muß
Kenntnisstand der Datenbank
offen
letzten Zustandes ist, führt zur
2
3
4
Informationsverlust
1
für alle Zustände des alten Än31.12.94
derungspfades geschehen, da
Gültigkeit des Datensatzes
ansonsten wieder Überlagerungen
01.01.95
01.01.96
01.03.97
offen
auftreten können. Gleichzeitig liefert
diese Begrenzung des
Kenntnisstands der Datenbank ein
Selektionskriterium für die Selektion
1
31.12.94
15.06.95
2
3
Pfad A
2
4
Pfad B
Abb.: Einfügung eines neuen Pfades bei vollständiger Historie
eines Pfades, da der
UNKENNTNIS_AB Zustand immer auf den Beginnzeitpunkt des ersten Pfadzustands des neuen
Pfades gesetzt wird, somit jeder Pfad eindeutig von einem anderen Pfad unterschieden werden kann.
Voraussetzung ist, daß der alte Kenntnisstand in der Datenbank offen gewesen ist, und daß der neue
Änderungspfad ebenfalls einen in die Zukunft offenen Kenntnisstand erzeugt. Durch diese Art der
Änderung gehen ebenfalls Informationen verloren. Alle Zustände, die nach der Beendigung des alten
Pfades irgendwann in der Vergangenheit als zukünftige Zustände gesehen worden sind, würden mit
den gleichen Zeitpunkten jetzt andere Informationen liefern. Dies impliziert ebenfalls wie oben die
Einschränkung nach Abfrage mit dem aktuellen Zeitpunkt des Zugriffs. Diese Einschränkung ist
durchaus praxisnah.
Zur Ermittlung der Zustände einzelner Pfade kann der jeweilige UNKENNTNIS_AB Zeitpunkt
verwendet werden, wobei noch einmal darauf hingewiesen wird, daß offene Zeitpunkte der Zukunft
durch eine maximale Zeitangabe realisiert werden.. Im Beispiel relationaler Systeme könnte z.B.
folgende nicht optimierte Abfrage zur Ermittlung der einzelnen Pfade verwendet werden:
SELECT DISTINCT UNKENNTNIS_AB
FROM tabelle
WHERE key = entity-key
© GDV 1999
71
Inhalt
Datenmanager / Anhang
Bei vergangenheitsbezogenen Abfragen kann der einzelne Pfad nur über das einheitliche
UNKENNTNIS_AB eines jeden Zustands des Pfades verarbeitet werden. Andere im Kenntnisintervall
des Pfades liegende Zeitpunkte führen unter Umständen zu unterschiedlichen Ergebnissen, da die
verschiedenen Zustände innerhalb eines Pfades zu unterschiedlichen Zeitpunkten eingefügt werden.
Folgende Abfrage verdeutlicht die Ermittlung aller Zustände des aktuellen Pfades:
SELECT *
FROM tabelle
WHERE key = entity-key
AND UNKENNTNIS_AB = offen
III.6.1.1.3. Die Löschung von Pfaden
Die Löschung eines Pfades erfolgt durch entsprechende Setzung des Attributs UNKENNTNIS_AB
auf den Löschzeitpunkt. Diese Operation darf nur auf einem Pfad ausgeführt werden, der im Attribut
UNKENNTNIS_AB den Wert offen enthält.
Werden keine neuen Pfade eingefügt, liegen ab dem Zeitpunkt der Löschung aus Anwendungssicht
keine Informationen mehr in der Datenbasis vor.
Diese Vorgehensweise beim Löschen führt zu einem Widerspruch zur Konsistenzregel der
offenen aktuellen Zustände!
Auf jeden Fall ist im Rahmen einer Löschoperation ein neuer offener Änderungspfad in die Datenbasis
einzufügen.
Deshalb kann die Löschung des aktuellen offenen Änderungspfades nur durch Setzung entsprechender
Attribute der Entität wie z.B. Stornomerkmal erfolgen. In einer physischen Umsetzung, die alle alten
Pfade in einem Archiv auslagert kann die oben beschriebene Löschoperation jedoch durchaus
angewendet werden.
III.6.1.1.4. Blättern in historischen Zuständen
Es gibt zwei grundlegende Blätteralgorithmen:

Blättern durch die Gültigkeitsabschnitte eines festgelegten Pfades

Wechsel des Pfades auf einen anderen Pfad.
Eine Anzeige von Gültigkeitsabschnitten aus verschiedenen Pfaden ist in der Regel nicht sinnvoll.
72
© GDV 1999
Datenmanager / Anhang
Vorschläge zur Realisierung von Historienkonzepten
III.6.1.1.5. Zukünftige Änderungen
Das vorgeschlagene Historisierungsverfahren gilt sowohl für vergangene, aktuelle wie zukünftige
Zustände einer Entität. Zu beachten ist nur, wenn ein zukünftiger Zustand eingefügt worden ist,
bewirkt die Änderung des aktuellen Zustands den Aufbau eines neuen Pfades. Dies ist keine
gravierende Einschränkung, da in der Regel immer der letzte Zustand eines Pfades geändert werden
sollte.
III.6.1.1.6. Problem des fachlichen Vorläufers
Die bisher vorgestellte Vorgehensweisen liefern keine Informationen über den Zustand einer Entität,
auf dem eine Änderung aufgesetzt worden ist. Dieser Zustand wird als fachlicher Vorläufer
bezeichnet. Sollten derartige Informationen benötigt werden, ist ein entsprechendes Attribut mit dem
Verweis auf den Einfügezeitpunkt (KENNTNIS_AB) vorzusehen. Sofern der Einfügezeitpunkt
eindeutig ist, reicht diese Information aus.
III.6.1.1.7. Das Problem kurzfristiger Zustände
Kurzfristige Zustände verändern einen Zustand für einen begrenzten Zeitraum. Es handelt sich hierbei
um eine vollständige Einbettung. Dies bedeutet, daß der umfassende Zustand die Zeitabschnitte vor
und nach der kurzfristigen Zustandsänderung festlegt. Da anhand des gesetzten Endezeitpunkts der
fachlichen Gültigkeit nicht entschieden werden kann, ob ein Zustand von vornherein nur kurzfristig
war oder durch Änderung seines fachlichen Endezeitpunkts von offen auf den vorliegenden
Endezeitpunkt entstanden ist, muß die Information, daß ein kurzfristiger Zustand vorliegt, in
entsprechenden Attributen dargestellt werden.
III.6.1.1.8. Die Bildung von Informationsobjekten
In der Regel wird ein zu bearbeitendes Objekt aus verschiedenen Entitätstypen zusammengesetzt.
Beispiel ist die Zusammenstellung eines Versicherungsvertrags aus einem Vertragskopf, den
Objektdaten, den Risikodaten und den Unterrisikoinformationen. Durch die Aufteilung eines
Informationsobjektes wie z.B. eines Versicherungsvertrages in seine Normalisierungsfragmente ist es
unter Umständen sehr aufwendig, die Zeitpunkte von Änderungen über alle Tabellen hinweg zu
ermitteln. Auch Attribute, die Informationsobjektbezogen ermittelt werden müssen wie z.B. die
Identifikation des ändernden Sachbearbeiters können nicht ohne weiteres bestimmt werden. Es
empfiehlt sich, die übergreifenden Änderungsdaten in einem separaten Entitätstyp zu verankern. Diese
Tabelle beinhaltet alle vorgangsbezogenen Daten, die für die Änderungen einer zusammengehörenden
Gruppe von Entitäten relevant sind. Dies sind z.B.:

Zeitpunkt oder Datum der Änderung

Art der Änderung

Identifikation des bearbeitenden Sachbearbeiters
© GDV 1999
73
Inhalt
Datenmanager / Anhang
Auch kann diese Tabelle auf einfache Art und Weise redundante Daten aus den zugeordneten Tabellen
aufnehmen, um Zugriffe zu beschleunigen und häufig benötigte Daten im direkten Zugriff zu halten.
Probleme treten nicht auf, da derartige Daten nicht verändert werden müssen.
III.6.1.2. Beispiele
In diesem Abschnitt werden die oben diskutierten Historisierungsverfahren anhand einiger kleinerer
Beispiele erläutert. Der jeweilige Speicherbedarf wird grob abgeschätzt. Folgende Verfahren werden
im einzelnen diskutiert:



Historisierung durch Überlagerung: Dies ist die reine Form der zweidimensionalen
Historisierung mit ihrem geringen Speicherverbrauch bei komplexen Zugriffen.
Historisierung durch Pfadhistorie: Dieses Verfahren vermeidet Überlagerungen, ohne auf die
Rekonstruierbarkeit in der Vergangenheit zu verzichten.
Historisierung durch Fortschreibung: Dies Verfahren ist eine mögliche praktische Umsetzung,
die bei etwas erhöhtem Speicherverbrauch eine überlagerungsfreie Historienbildung unter Verzicht
auf nicht sehr relevante Informationen realisiert.
Zur Abschätzung der je Verfahren zu erwartenden Tabellenzeilen gehen wir von einem
Aufbewahrungszeitraum von mindestens 7 Jahren aus. Dies ist in Versicherungsunternehmen eine
gängige Größenordnung.
Unser Fallbeispiel geht von einer intensiv geänderten Vertragstabelle aus, die nach den verschiedenen
Verfahren historisiert wird. Die hier angegebenen Größenordnungen sind real und treten so z.B. in der
Kraftfahrt-Versicherung auf.
Anzahl Verträge/Zeilen zu Beginn
Änderungen im Jahr
davon rückwirkende Änderungen (10%)
2.500.000
1.500.000
150.000
Damit ergibt sich folgende Wachstumstabelle
Tabelle: Wachstum einer
historisierten Tabellenach Jahren
Zeilen nach Jahren in 1000
Art der Historisierung anfangs
1. Jahr 2. Jahr 7. Jahr 10. Jahr Zuwachs

Überlagerung
2.500
4.000
5.500
13.000
17.500
700%

Pfadhistorie
2.500
6.500
12.000
53.500
89.500
3580%

Fortschreibung
2.500
4.150
5.950
16.200
25.750
1030%
Der geringste Speicherverbrauch tritt bei der Überlagerungstechnik auf. Der Zuwachs für die
Fortschreibung hält sich ebenfalls in Grenzen, wird aber stark durch die Häufigkeit von rückwirkenden
74
© GDV 1999
Datenmanager / Anhang
Vorschläge zur Realisierung von Historienkonzepten
Änderungen beeinflußt. Der für eine Pfadhistorie zu verbrauchende Speicherplatz disqualifiziert dies
Verfahren.
III.6.1.2.1. Historisierung durch Überlagerung
Neue Zustände werden mit den vier
Zustände, so daß bei der Ermittlung
der Datensätze zu einem definierten
offen
15.08.95
15.07.95
Kenntnisstand und
Gültigkeitszeitpunkt (K1,G1) in der
15.06.95
Regel mehrere Zustände gefunden
werden können. Der relevante Zustand
ist der Zustand mit dem maximalen
Kenntnisstand der Datenbank
Sie überlagern die vorhandenen













notwendigen Zeitangaben eingefügt.
4
3
2
1











31.12.94
Einfügezeitpunkt unter allen
Gültigkeit des Datensatzes
möglichen selektierten Zuständen.
01.01.95
01.01.96
01.03.97
offen
Gültig sind alle Datensätze, die zu
31.12.94
1
Pfad A
einem definierten Kenntnisstand vom
Zeitstrahl geschnitten werden. Die
15.06.95
2
3
2
4
Pfad B
folgende Tabelle zeigt den Zustand der
Abb.: Historienbildung durch Überlagerung
Tabelle. Aus diesen gespeicherten
Informationen müssen dann die fachlich relevanten und notwendigen Gültigkeitsabschnitte ermittelt
werden.
Der Vorteil dieser Lösung liegt in der einfachen Einfügelogik und im minimalen
Speicherplatzverbrauch. Der Nachteil liegt in den komplexen Zugriffsalgorithmen.
© GDV 1999
75
Inhalt
Tabelle:
Tabellenbeispiel
einer Überlagerung
Datenmanager / Anhang
Schlüssel
KENNTNIS
AB
UNKENNTNIS
AB
GÜLTIG
AB
UNGÜLTIG
AB
Attribute
Urzustand
...
31.12.94
offen
01.01.95
offen
...
1. Überlagerung
...
15.06.95
offen
01.01.95
01.01.96
...
2. Überlagerung
...
15.07.95
offen
01.01.96
01.03.97
...
3. Überlagerung
...
15.08.95
offen
01.03.97
offen
...
III.6.1.2.2. Historisierung auf Pfadebene
Bei der Einfügung neuer Zustände wird













generell der komplette Pfad des
15.08.95
mitgespeichert. Vergangene Pfade werden
unverändert gespeichert.
15.07.95
15.06.95
Die folgende Tabelle zeigt den Zustand einer
Tabelle. Aus diesen gespeicherten
Informationen müssen dann die fachlich
relevanten und notwendigen
Gültigkeitsabschnitte ermittelt werden.
Kenntnisstand der Datenbank
offe n
Änderungsbaums als Abschnittshistorie
2
3
4
2
3
1
2
1
1
31.12.94
Gültigkeit des Datensatzes
01.01.95
Der Vorteil dieses Verfahrens liegt im
einfachen Zugriff. Der Nachteil ist der hohe
Speicherverbrauch, da sehr viele Daten
redundant gespeichert werden. Auch die
Änderungsoperationen sind aufwendig. Dieser
Nachteil schließt dieses Verfahren für die
meisten praktischen Fälle aus.











01.01.96
01.03.97
offe n
1
31.12.94
Pfad A
15.06.95
2
15.07.95
2
3
2
1
Pfad C
2
3
2
4
Pfad D
15.08.95
1
Pfad B
Abb.: Historienbildung durch Pfadbildung
Die folgende Tabelle zeigt den immensen
Speicherbedarf dieser Lösung auf:
76
© GDV 1999
Datenmanager / Anhang
Tabelle:
Tabellenbeispiel
einer Pfadhistorie
Urzustand
Vorschläge zur Realisierung von Historienkonzepten
Schlüssel
KENNTNIS
AB
UNKENNTNIS
AB
GÜLTIG
AB
UNGÜLTIG
AB
Attribute
...
31.12.94
offen
01.01.95
offen
...
Zustand der Tabelle nach der ersten Änderung
Urzustand
...
31.12.94
15.06.95
01.01.95
offen
...
Pfad A, Satz 2
...
15.06.96
offen
01.01.95
01.01.96
...
Pfad A, Satz 1
...
15.06.96
offen
01.01.96
offen
...
Zustand der Tabelle nach der zweiten Änderung
Urzustand
...
31.12.94
15.06.95
01.01.95
offen
...
Pfad A, Satz 2
...
15.06.96
15.07.95
01.01.95
01.01.96
...
Pfad A, Satz 1
...
15.06.96
15.07.95
01.01.96
offen
...
Pfad B, Satz 2
...
15.07.96
offen
01.01.95
01.01.96
...
Pfad B, Satz 3
...
15.07.96
offen
01.01.96
01.03.96
...
Pfad B, Satz 1
...
15.07.96
offen
01.03.96
offen
...
Zustand der Tabelle nach der dritten Änderung
Urzustand
...
31.12.94
15.06.95
01.01.95
offen
...
Pfad A, Satz 2
...
15.06.96
15.07.95
01.01.95
01.01.96
...
Pfad A, Satz 1
...
15.06.96
15.07.95
01.01.96
offen
...
Pfad B, Satz 2
...
15.07.96
15.08.96
01.01.95
01.01.96
...
Pfad B, Satz 3
...
15.07.96
15.08.96
01.01.96
01.03.96
...
Pfad B, Satz 1
...
15.07.96
15.08.96
01.03.96
offen
...
Pfad C, Satz 2
...
15.08.96
offen
01.01.95
01.01.96
...
Pfad C, Satz 3
...
15.08.96
offen
01.01.96
01.03.96
...
Pfad C, Satz 4
...
15.08.96
offen
01.03.96
offen
...
© GDV 1999
77
Inhalt
Datenmanager / Anhang
III.6.1.2.3. Historisierung durch Fortschreibung
Dieses Verfahren verbindet minimalen
offe n
Informationsverluste in Kauf zu nehmen, die
15.08.95
aber bei Zugriffen über das aktuelle
15.07.95
Tagesdatum oder über den
15.06.95
Beendigungszeitpunkt eines Pfades nicht
auftreten.
Kenntnisstand der Datenbank
Zugriffen. Allerdings sind einige













Speicherplatzverbrauch mit einfachen











4
3
2
?
?
1
31.12.94
In diesem Verfahren werden die jeweils
letzten Zustände eines Pfades bzw. der letzte
Pfad durch in Zukunft offene Zustände
überschrieben.
Rückwirkende Änderungen, also Änderungen,
die nicht nur den letzten Zustand einer
Gültigkeitsfolge eines Pfades ändern, führen
zum Aufbau eines neuen Pfades.
Ausgenommen davon sind Ergänzungen, die
eventuelle Lücken vor dem ersten Zustand des
Pfades auffüllen.
Gültigkeit des Datensatzes
01.01.95
01.01.96
01.03.97
offe n
31.12.94
1
Pfad A
15.06.95
2
Pfad B
15.07.95
2
3
2
3
15.08.95
Pfad B
4
Pfad B
Abb.: Historienbildung durch Fortschreibung
Die folgende Tabelle zeigt die einzelnen Zustände, wie sie z.B. in einer DB2-Tabelle entstehen, auf:
78
© GDV 1999
Datenmanager / Anhang
Tabelle:
Tabellenbeispiel
einer
Fortschreibung
Urzustand
Vorschläge zur Realisierung von Historienkonzepten
Schlüssel
KENNTNIS
AB
UNKENNTNIS
AB
GÜLTIG
AB
UNGÜLTIG
AB
Attribute
...
31.12.94
offen
01.01.95
offen
...
Zustand der Tabelle nach der ersten Änderung
Urzustand
...
31.12.94
15.06.95
01.01.95
offen
...
Pfad A, Satz 2
...
15.06.96
offen
01.01.95
offen
...
Zustand der Tabelle nach der zweiten Änderung
Urzustand
...
31.12.94
15.06.95
01.01.95
offen
...
Pfad A, Satz 2
...
15.06.96
offen
01.01.95
01.01.96
...
Pfad A, Satz 3
...
15.07.96
offen
01.01.96
offen
...
Zustand der Tabelle nach der dritten Änderung
Urzustand
...
31.12.94
15.06.95
01.01.95
offen
...
Pfad A, Satz 2
...
15.06.96
offen
01.01.95
01.01.96
...
Pfad A, Satz 3
...
15.07.96
offen
01.01.96
01.03.96
...
Pfad A, Satz 4
...
15.08.96
offen
01.03.96
offen
...
Neue Pfade werden nur bei rückwirkenden Änderungen aufgenommen.
III.7. Realisierungsmöglichkeiten
Im Folgenden werden zwei Möglichkeiten betrachtet, die oben diskutierten Vereinfachungen in
relationalen Datenbanksystemen umzusetzen. Wie in Teilen schon oben diskutiert, sind zwei
grundsätzliche Vorgehensweisen denkbar:


Alle Gültigkeitsabschnitte des Änderungsbaums werden in einer einzigen Tabelle festgehalten.
Nur die „aktuellen“ Zustände, die Gültigkeitsabschnitte des aktuellen Pfades werden in der
eigentlichen Entitätstabelle festgehalten. Alle alten Pfade werden in eine Archivtabelle ausgelagert.
Die Grundzüge dieser beiden Möglichkeiten werden in den folgenden Abschnitten näher detailliert.
Eine praktische Umsetzung wird als kleine Übung für den Themenkomplex Historisierung empfohlen.
III.7.1. Historisierung in einer Tabelle
Die Historisierung in einer Tabelle liefert alle notwendigen Informationen an einem Ort. Zugriffe
können nur über die zwei Einflußparameter Kenntnisstand und Gültigkeitszeitpunkt jeden beliebigen
Zustand der Entität mittels einer SQL-Abfrage liefern. Diesem Vorteil steht der Nachteil gegenüber,
© GDV 1999
79
Inhalt
Datenmanager / Anhang
daß auch wenig benutzte Daten bei jedem Zugriff berücksichtigt werden müssen. Die so entstehenden
Tabellen werden schnell sehr umfangreich und reduzieren somit die Möglichkeiten perfomanter
Zugriffe.
III.7.2. Historisierung mit einer Archivtabelle
Die zweite Möglichkeit, eine zu historisierende Tabelle abzulegen, besteht in der Aufteilung in eine
aktuelle Tabelle und in eine Archivtabelle.
Die aktuelle Tabelle enthält nur die Zustände des aktuellen Pfades oder keine Zustände, falls zu
dieser Entität keine Informationen vorhanden sein sollen. Sie kann somit sehr einfach als lückenlose
Abschnittshistorie realisiert werden. Zugriffe werden in der Regel auf dieser Tabelle ausgeführt. Für
diese Tabelle reichen die zwei Gültigkeitsattribute aus:

GÜLTIG_AB

UNGÜLTIG_AB
Die Archivtabelle enthält alle Zustände vergangener Pfade. Diese Daten sind in der Regel in
operativen Anwendungen nur von untergeordneter Bedeutung. Aus sie wird deshalb nicht sehr häufig
zugegriffen. Sie wird in Form einer Historie durch Fortschreibung realisiert. Diese Tabelle benötigt
deshalb alle vier Attribute:

KENNTNIS_AB

UNKENNTNIS_AB

GÜLTIG_AB

UNGÜLTIG_AB
III.7.3. Die Vorgangstabelle
Zusammengehörige Tabellen bilden in ihrer Gesamtheit ein Informationsobjekt eines VU. Dies kann
z.B. ein Versicherungsvertrag mit den Komponenten:

allgemeine Vertragsdaten

Risikodaten je möglichem Risiko

Unterrisikodaten je Unterrisiko zu einem Risiko

abweichende Deckungszusagen

Objektdaten

etc.
sein. Es empfiehlt sich, alle übergreifenden Daten über die Entwicklung eines Informationsobjekts in
einer eigenen Tabelle zu führen. Diese Tabelle enthält z.B. folgende Daten:

80
Identifikation des ändernden Sachbearbeiters
© GDV 1999
Datenmanager / Anhang
Literaturverzeichnis

Datum des Vorgangs

Art des Vorgangs

fachlicher Beginn des durch den Vorgang erzeugten Zustands des Informationsobjekts

etc.
Mittels einer derartigen Tabelle kann dann eine einfache Zugriffssteuerung auf die einzelnen Zustände
der betroffenen Komponenten zugegriffen werden.
IV. Literaturverzeichnis
[Am93]
Amberg, M.: Konzeption eines Software-Architekturmodells für die objektorientierte
Entwicklung betrieblicher Anwendungssysteme, Inaugural-Dissertation zur Erlangung
des Grades eines doctor rerum politicarum der Fakultät Sozial- und Wirtschaftswissenschaften der Universität Bamberg, Bamberg 1993
[Bött95]
R. Böttger, ...: Efendi V1.0: Database Federation Services, Cadlab-Joint R&D Institute
der Universität Paderborn und Siemens Nixdorf Informationssysteme AG, Paderborn
1995
[Booch93]
Booch, G.: Object Oriented Analysis and Design With Applications, Benjamin/Cummings, Redwood City 1993
[DBFo1/95]
„IBM DataJoiner für die Integration heterogener Datenbestände“ in: Datenbank
Fokus, Heft 1/95, S. 35 - 39
[DBFo2/95]
„Vom Eigenbau zum Produkt: Normiertes Verbindungsstück“ in: Datenbank Fokus,
Heft 2/95, S. 30 - 34
[FeSi93]
Ferstl, O.K., Sinz, E.J.: Grundlagen der Wirtschaftsinformatik, Oldenbourg, München,
Wien 1993
[Hor96]
Hornig, P.:Die Kinder der OMA - Überblick über CORBA-Implementierungen, in:
OBJEKTspektrum 1/96
[IBMDaJo94] DataJoiner - A Multidatabase Server, IBM White Paper 10/94 aus der Reihe „Data
Management Solutions“
[Ja92]
Jacobson, I.: Object-Oriented Software Engineering, A Use Case Driven Approch,
Addison-Wesley, ACM Press1992
[OvumMi95]
Rock-Evans, R., Woods, E.: Middleware the Key to Distributed Computing, Ovum
Report, London 1995
[OvumDo95]
Ring, K., Carnelley, Ph.: Distributed Objects: Creating the Virtual Mainframe, Ovum
Report, London 1995
© GDV 1999
81
Inhalt
Datenmanager / Anhang
[Rad94]
E. Radeki: Efendi: Federated Database System of Cadlab, Cadlab Report 39/94,
Cadlab-Joint R&D Institute der Universität Paderborn und Siemens Nixdorf
Informationssysteme AG, Paderborn 1994
[SAGNAV]
NATURAL ACTIVE VIEW Manual für NATURAL ACTIVE VIEW Version 1.1,
Software AG, Darmstadt 1993, Manual-Nr.: NVI-111-030
[SNIDBA94]
Database Access Service (DBA): Zugriff auf unternehmensweite Daten, Siemens
Nixdorf Informationssysteme AG, Paderborn 1994, Best.-Nr.: U22455-J-Z411-1
[SNIDBA95]
Database Access - der universelle Zugriff auf Datenbanken im heterogenen Umfeld,
Siemens Nixdorf Informationssysteme AG, Paderborn 1995, Best.-Nr.: U23555-JZ810-1
[SybOv]
SYBASE Client/Server Architectural Overview, SYBASE, Emeryville, California,
USA, Band-Nr. 8203-0294
[VAA1.3]
VAA, Die Anwendungsarchitektur der Versicherungswirtschaft Version 1.3
82
© GDV 1999