Verteilte, heterogene Datenbanken sind ein komplexes und schier unerschöpfliches Thema. Eine der noch weitgehend ungelösten Herausforderungen ist dabei der transparente Datenaustausch zwischen heterogenen Systemen. Der nachfolgende Artikel beschreibt in einer Übersicht die Bemühungen diverser Hersteller, dieses Problem zu lösen.

Die Globalisierung der Märkte, und damit der zunehmende Konkurrenzdruck, bedeutet für die meisten großen Unternehmen, daß sie noch mehr als früher auf die Verfügbarkeit von "up to date"-Informationen angewiesen sind.

So sollte beispielsweise die Materialbestellung abhängig vom Produktionsstatus erfolgen, damit unnötige Lagerkosten vermieden werden. Durch gleichzeitige Rechnungsübermittlung kann der Lieferant auf der anderen Seite seine Außenstände gering halten.

Unterschiedliche Daten müssen integriert werden

Im Einzelhandel ermöglichen "Point of Sales"-Systeme eine sofortige Kontrolle der Kreditwürdigkeit des Kunden, beziehungsweise eine schnelle Gutschrift des Kaufpreises. Diese Entwicklungen bedeuten für das DV-Management Herausforderungen in mehrfacher Hinsicht.

- Die ständige Verfügbarkeit unternehmensweiter Daten muß gesichert sein

- verschiedene Insellösungen müssen zusammengeführt werden

- neue Technologien müssen unterstützt werden.

- Die DV-Abteilungen sehen sich dabei mit folgenden Problemen konfrontiert:

- Bestehende Applikationen

- und "ererbte Daten" müssen eingebunden werden,

- die Daten sind eventuell geographisch verstreut und

- sie befinden sich auf Rechnern unterschiedlicher Hersteller,

- in den Fachabteilungen hat die PC-Welle eine Eigendynamik entwickelt, die sich einer zentralen Kontrolle weitestgehend entzieht.

Eine Umfrage bei Kunden von Digital Equipment in den USA hat ergeben, daß:

- 90 Prozent der Anwender drei oder mehr Betriebssysteme haben,

- 50 Prozent in Fusionen oder

- Firmenübernahmen involviert sind,

- 65 Prozent multinational operieren

- 50 Prozent ein Netzwerk mit Kunden betreiben.

Es müssen also nicht nur die unterschiedlichen Systeme des eigenen Unternehmens, sondern auch externe Datenquellen integriert werden.

Anwender und Hersteller müssen demzufolge einen Weg finden, der vom Datenbanksystem eines Herstellers zum heterogenen Datenbank-Management-System (DBMS), also einem Informations-Netzwerk, führt.

Ziel eines solchen Informations-Netzwerkes muß es sein:

- existierende und neue Dateien und Datenbanken in eine einzelne, unternehmensweite Informationsbasis zu integrieren

- eine einheitliche Sicht auf die Daten für den Benutzer und die Anwendungen zu gewährleisten, so daß die hersteller- beziehungsweise systemspezifischen Eigenarten der einzelnen Mitglieder dieses Datennetzwerkes transparent bleiben können - ein solides architektonisches Grundgerüst für zukünftige Erweiterungen zu schaffen.

In der Praxis bedeutet das die Einrichtung eines verteilten, heterogenen DBMS. Damit sind sowohl an die Technik als auch an die Administration hohe Anforderungen gestellt.

Bei der Definition, welche Voraussetzungen ein echtes, verteiltes Datenbanksystem erfüllen muß, hat C.J. Date in seinem Buch "Introduction to Database Systems Vol II" Maßstäbe vorgegeben.

Die Möglichkeit, in einer Transaktion Veränderungen in mehreren Datenbeständen gleichzeitig vornehmen zu können, ist eine wesentliche Voraussetzung, die allerdings alleine nicht ausreicht, um von einer verteilten DB im Sinne von Daten sprechen zu können. Außerdem muß zwischen dem Verteilen von Applikationen und dem Verteilen von Daten unterschieden werden.

Verteilt vereinigt oder integriert verteilt

Um Daten verteilen zu können oder um Daten unterschiedlicher Quellen dem Benutzer gegenüber logisch als einen zusammenhängenden Bestand erscheinen zu lassen, gibt es allerdings zwei Konzepte, die hier ein wenig näher getrachtet werden sollen:

1. Die "Verteilte Vereinigung von Datenbank Management Systemen" (FDBS).

2. Das "Integriert verteilte Datenbank Management System".

In einem FDBS wird jede Datenbank als unabhängig zu verwaltende Einheit angesehen, aber alle in dieser Förderation vorkommenden DB-Systeme können über ein einheitliches SQL-API angesprochen werden. Nun sind die jeweiligen herstellerspezifischen SQL-Implementierungen, unter anderem aus historischen Gründen, alles andere als einheitlich.

SQL wurde bereits 1974 entwickelt, konnte sich aber erst 1986 als Standard etablieren. Die in der Zwischenzeit entstandenen, relationalen Datenbanksysteme konnten daher jeweils unterschiedliche SQL-Dialekte entwickeln.

Außerdem gibt es weiterhin bei den meisten Herstellern sogenannte "Add Ons", welche über den definierten Standard hinausgehen, um beispielsweise die Systeme optimal an das entsprechende Betriebssystem anzupassen.

Um diesem Zustand abzuhelfen, hat eine Reihe von DB-Herstellern und -Benutzern ein Konsortium gegründet, das SQL-Access-Komitee, welches momentan aus 42 Mitgliedern besteht.

Nun ist für ein funktionierendes Informations-Netzwerk ein einheitliches API, nennen wir es "SQL-Access", erforderlich. Jede Datenbank in diesem Verbund muß aus der Sicht des zugreifenden "Clients" über die gleiche SQL-Funktionalität verfügen.

Das Info-Netzwerk sollte diese Transparenz auch dort zur Verfügung stellen, wo etwa ein "Bundesmitglied" nicht die volle "SQL-Access"-Kompatibilität aufweisen kann. Andere DB-Systeme, welche den neuen Standard (noch) nicht unterstützen, können somit leicht in das Informations-Netzwerk integriert werden.

Für jedes Datenbanksystem innerhalb dieser Förderation bleiben aber seine typischen Eigenschaften erhalten, auch wenn sie nicht "SQL-Access" konform sind. Das heißt, daß ein DBMS, welches als Mitglied in einer Förderation arbeitet, auch weiterhin von Applikationen, welche nicht innerhalb dieser Förderation angesiedelt sind, angesprochen werden

kann.

So ist etwa vorstellbar, daß in einem Verbund einige Benutzer nur die Förderation mit einem einheitlichen API sehen, während andere, lokalspezifische Applikationen, weiterhin mit Herstellerspezifischen SQL-Erweiterungen arbeiten.

Das Konzept der Förderation steht im Gegensatz zum Konzept der "integriert verteilten Datenbank". Diese Datenbank erfüllt im Idealfall alle wesentlichen Coddschen Regeln der Verteilung. Hier wesentliche Unterschied zur Förderation liegt darin, daß der gesamte verteilte Datenbestand eines Unternehmens als eine einzelne Verwaltungseinheit angesehen wird. Das bedeutet, daß in jeder Lokation, die Datenbestände hält, das gleiche DB-System (die gleiche "Native DB Engine") vorhanden ist. Ein Informations-Netzwerk kann auch aus der Kombination beider Modelle bestehen.

Die aktuellen Szenarien in den meisten großen Unternehmen sind von dem Vorhandensein vieler heterogener DB-Systeme geprägt. Daher besteht zunächst dort die Notwendigkeit, das Modell der FDBS zu verwirklichen.

Momentane Lösungen vieler Hersteller bieten Zugriffsmöglichkeiten über Gateways oder APIs zu Fremdsystemen. Da es jedoch noch keinen verabschiedeten Standard für den Datenaustausch verschiedener DB-Systeme untereinander gibt, sind diese Werkzeuge proprietär und somit untereinander nicht austauschbar, selbst dann, wenn die jeweiligen Client-Server-Schnittstellen offengelegt werden. Kleinster gemeinsamer Nenner kann hier immer nur der aktuelle SQL-Standard sein, in weichem ein "Remote Data Access" aber noch nicht definiert ist.

Wie werden nun die Voraussetzungen geschaffen, um unterschiedliche Systeme oder sogar Systeme unterschiedlicher Hersteller sinnvoll in eine Förderation einzugliedern?

Zwei Projekte verdienen in diesem Zusammenhang besondere Aufmerksamkeit: Die "SQL-Access Group", ein Konsortium verschiedener Datenbankhersteller und die "Distributed Relational Database Architecture" (DRDA) von IBM.

IBMs DRDA ist eine Architektur innerhalb von SAA, also zunächst innerhalb der "IBM-Welt", welche den Zugriff auf verteilte relationale Daten beschreibt. DRDA definiert zum Beispiel die Formate und Protokolle für das Management verteilter Datenbanken, entsprechende Erweiterungen in SQL sowie die Verbindungspfade unterschiedlicher Datenbanksysteme, so etwa den Zugriff ein er OS/2-Applikation auf die OS/400-Datenbank und DB2.

Der Begriff "Heterogene Systeme" schließt dabei zunächst alle in der SAA-Umgebung vorkommenden Datenbanksysteme ein und bietet den SAA-Anwendern somit umfangreiche Möglichkeiten der Datenintegration.

DRDA basiert auf dem "Client-Server-Modell". IBM beabsichtigt auch die AIX-Familie in DRDA einzugliedern (Statement of Direction vom Februar 1990).

Im SQL-Access-Komitee, dessen Technologie beispielsweise

im Information Network von Digital Equipment zur Anwendung kommt, ist die IBM nicht vertreten.

Der wesentliche Unterschied zu DRDA besteht jedoch darin, daß der Begriff "Heterogene Systeme" im Sinne von SQL-Access Datenbanksysteme unterschiedlicher Hersteller meint. Weiterhin verfolgt SQL-Access das Ziel, daß alle beteiligten DB-Server gleiche SQL-Syntax und -Semantik, sowie gleiche Datentypen und "Message-Formate"

benutzen. SQL Access spricht hier vom "common-subset canonical form approach".

In DRDA behalten Clients und Server ihren jeweiligen SQL-Dialekt sowie ihre Datentypen ("anything-goes, receiver-makes-it-right").

Das SQL-Access-Konsortium befaßt sich unter anderem mit der Definition eines SQL-APIs und einer "Format-und-Protokoll"-Spezifikation (FAP), welche auf den existierenden ANSI- und ISO-, SQL2- und Remote-Database-Access-Spezifikationen (RDA) basiert. RDA ist eine ISO-Gruppe, in welcher die IBM wiederum vertreten ist.

Die SQL-Access-Konsortium-Aktivitäten zielen schließlich auf ein einheitliches SQL-API für ein Informations Netzwerk ab. Dabei können die einzelnen Datenbanken, wie auch bei DRDA, als "Serversysteme" und die API-Benutzer (Online oder per Programm) als Clientsysteme" irgendwo im Netzwerk liegen.

Wichtig dabei ist, daß die SQL-Access-Spezifikationen auf existierenden Standards aufbauen und durch X/Open veröffentlicht worden sind. Dadurch ist eine wesentliche Beeinflussung der weiteren Standardisierungsbemühungen durch SQL-Access möglich.

Die API-Spezifikationen setzen auf SQL-89 auf und sind mit Elementen von SQL-2 (dem erwarteten SQL-89 Nachfolger) erweitert worden um etwa das Client-Server-Modell zu unterstützen.

Obwohl sie gleichartige Problemlösungen zur Verfügung stellen, haben DRDA und SQL Access unterschiedliche Ziele: Einmal wird den Anwendern homogener Systeme (in diesem Fall Systeme eines Herstellers) und zum anderen denen heterogener Systeme (in diesem Fall Systeme mehrerer Hersteller) eine geeignete Integrationsumgebung geboten. Bereits heute gibt es von vielen der in der SQL Access Group vertretenen Hersteller Brücken in die IBM-Welt, welche in der Regel auf SNA-LU6.2-Basis mit DB2 kommunizieren. Außerdem haben einige der im SQL-Access-Konsortium vertretenen Hersteller ihre Unterstützung für die DRDA-Architektur angekündigt.

Es sind noch einige Wünsche offen

Ob dadurch beide, nicht zuletzt auch von taktischen Überlegungen getriebenen, Allianzen schneller zusammenwachsen, bleibt allerdings abzuwarten.

Immerhin ist es bereits heute möglich, etwa aus einem MS-Windows-System heraus Transaktionssysteme aufzurufen, welche den Datenzugriff auf heterogene Systeme verteilen (Rdb von Digital und DB2 von der IBM oder Oracle). Derartige Werkzeuge sind jedoch in bezug auf Transparenz, Kommunikation, Integritätskontrolle und Benutzerfreundlichkeit noch erheblich zu verbessern.

*Jürgen Berg ist Technologieberater bei Digital Equipment GmbH in

Unterföhring bei München mit dem Schwerpunkt OLTP-Systeme.