Der Weg zu einer Welt, in der jede Datenbank problemlos mit einer anderen kommunizieren kann, ist noch weit. Zu diesem Ergebnis kommt Dieter E. Jenz* in seinem Beitrag, mit dem er zeigt, daß die Konzepte aus den Hochglanzbroschüren häufig an den ganz alltäglichen Problemen des DV-Alltags scheitern. Vor allem kritisiert er die Alleingange von Unternehmen wie der IBM bei der Suche nach verbindlichen Standards.

Die zunehmende Dezentralisierung der Datenbestände im Unternehmen, verbunden mit dem Einsatz heterogener Datenbanksysteme, verlangt nach einem schlüssigen Konzept für die Interoperabilität. Für Mainframe-Anwender wird sich vor allem die Frage stellen, wie die Datenbanksysteme der zweiten Ebene mit dem Mainframe-Datenbanksystem, zumeist DB2, zusammenwirken sollen. Den Anwendern der Fachabteilung soll es möglich sein, nicht nur auf lokale, sondern auch auf Host-Datenbestände zuzugreifen.

Zum gegenwärtigen Zeitpunkt ist es alles andere als einfach, eine sinnvolle Strategie für die Interoperabilität zu entwickeln. Die verbreiteten relationalen Datenbanksysteme unterscheiden sich in gravierenden Punkten, die sich im Anwendungscode widerspiegeln. Man braucht eine Brückenfunktion, damit mehrere heterogene Datenbanksysteme zusammenwirken können.

Im wesentlichen stehen zwei Möglichkeiten zur Wahl: Datenbank-"Gateways" und standardisierte Protokolle. Dieser Beitrag gliedert sich in zwei Teile, von denen jeder eine der Möglichkeiten erläutert.

Gateways verbinden die Datenbanksysteme

Die bisherigen Gateway-Lösungen können als vertikal bezeichnet werden. Das heißt sie schlagen die Brücke von einem Datenbanksystem der zweiten Ebene (zum Beispiel Oracle, Ingres, Informix, Sybase) zu DB2. Horizontale Gateways, die zum Beispiel den Zugriff von einer Oracle-Datenbank auf eine Ingres-Datenbank ermöglichen, sind so gut wie nicht verfügbar.

Im einzelnen haben die Datenbank-Gateways folgende Funktionen:

- Entgegennehmen von SQL-Befehlen von der "Fontend"-Anwendung und gegebenenfalls Übersetzen der SQL-Befehle in den SQL-Dialekt des Ziel-Datenbanksystems,

- Übermitteln der empfangenen SQL-Befehle an das Ziel-Datenbanksystem und

- Empfangen der Ergebnismenge und/oder des "Return Codes", Übermitteln und gegebenenfalls Übersetzen der Ergebnismenge und/oder des Return Codes an die Frontend-Anwendung.

Zur Erfüllung dieser Aufgaben müssen Datenbank-Gateways eine Reihe gravierender Probleme lösen.

Unterschiedliche SQL-Dialekte:

Die meisten Datenbank-Hersteller behaupten zwar, über eine ISO-SQL-entsprechende Sprachimplementierung der Datenbank-Abfragesprache zu verfügen. Dennoch bleibt genügend Raum für herstellerspezifische Besonderheiten. Dies zeigt sich insbesondere in den sehr unterschiedlichen Sperrkonzepten, die den Entwickler in die Abhängigkeit vom Hersteller zwingen.

Darüber hinaus führten nahezu alle Hersteller eigene SQL-Erweiterungen ein. Die wichtigsten herstellerspezifischen Erweiterungen betreffen neben dem Sperrkonzept das Integritäts- und Transaktionskonzept sowie die Technik der Cursor-Verarbeitung, die die Bearbeitung einer vorselektierten Ergebnismenge auf der Ebene der Tabellenzeile erlaubt.

Schließlich wurde SQL um prozedurale Konstrukte erweitert. Der Entwickler sollte zum Beispiel die Möglichkeit erhalten, SQL-Prozeduren im System-Katalog des Datenbanksystems in der bereits vom Optimizer bearbeiteten Form abzulegen und Leistungsvorteile bei der Ausführung zu realisieren. Jeder Hersteller implementierte ein eigenes Prozedur-Konzept. Als spezifische Erweiterung dieses Konzeptes sind sogenannte "Trigger" zu sehen, die als gespeicherte Prozeduren bei Auftreten eines definierten Ereignisses ausgelöst werden.

Inkompatibilität von Dntentypen:

Die ISO-SQL-Normung umfaßt nur wenige Datentypen. Derzeit sind die "Integer"-Datentypen die einzigen, wirklich über alle Datenbanksysteme hinweg einheitlichen Datentypen. Ein klassisches Beispiel für Inkompatibilität liefert der DB2-Datentyp "TIMESTAMP", der von keinem Gateway konvertiert werden kann.

Selbst Character-Datentypen können sich als Problem erweisen. Beispielsweise verbirgt sich hinter dem Oracle-Datentyp "CHAR" in Wirklichkeit "VARCHAR". Erfolgt nun ein "JOIN" zwischen zwei Tabellen über eine Tabellenspalte mit Datentyp "CHAR" (in beiden Tabellen), so kann der Anwender durchaus mit Verwunderung feststellen, daß kein Ergebnis zustande kommt, daß zum Beispiel "MAIER" in dem einen Fall mit Blanks aufgefüllt wird und im anderen nicht.

Im Zusammenhang mit der Inkompatibilität der Datentypen ist auch das Problem unterschiedlicher Zeichenverschlüsselungen (EBCDIC, ASCII), aber auch das Problem unterschiedlicher Zeichensätze zu beachten. Weitere Probleme ergeben sich mit der Doppelbelegung von Zeichen (zum Beispiel $ für Dollar und Pfund Sterling) und den nationalsprachlichen Besonderheiten, wie etwa in Deutschland die Umlaute.

Gerade hier ist nicht nur mit Schwierigkeiten im Zusammenwirken unterschiedlicher Datenbanksysteme, sondern auch bei den Frontend-Werkzeugen zu rechnen. Tools wie Oracle-Card können Umlaute nicht konvertieren. Die mit Microsoft Windows verwendete Verschlüsselung nach der ANSI-Code-Tabelle korrespondiert nicht mit der bei vielen Datenbanksystemen gebräuchlichen ASCII-Code-Tabelle und schon gar nicht mit der EBCDIC-Code-Tabelle.

Unterschiedliche Fehlercodes:

Der ISO-SQL-Standard sieht vor, daß die Belegung der Fehlerstatuswerte "<0" den Herstellern überlassen bleibt. Aufgrund der unterschiedlichen Funktionalität der Datenbanksysteme gibt es Fehlercodes, die untereinander keine Entsprechung haben. Der Entwickler ist gezwungen, die Fehlerbehandlung für die nicht direkt übersetzbaren Fehlercodes selbst zu übernehmen.

Unterschiedlicher Aufbau der System-Kataloge:

Der ISO-SQL-Standard gibt den Datenbank-Herstellern vollkommene Freiheit im Aufbau der System-Kataloge. Auch mit SQL2 erfolgt die Normierung nur in Ansätzen. So erschwert die Inkompatibilität der System-Kataloge das Zusammenwirken unterschiedlicher Datenbanksysteme. Jede bedeutendere Versionsänderung führt fast zwangsläufig zu einem Anpassungsbedarf des Gateway oder gar der Anwendung.

Unterschiedliche Transfer-Protokolle:

Jeder Datenbank-Hersteller entwickelte ein eigenes Transfer-Protokoll zwischen Anwendung und Datenbanksystem. Das Transfer-Protokoll beschreibt die Formatierung der Datenströme, die über die Schnittstelle von Anwendung und Datenbanksystem ausgetauscht werden; das heißt Format, Länge einer Übertragungseinheit, Reihenfolge der Funktionsaufrufe (Calls), interne Verschlüsselung von Parametern und Daten etc.

Intransparenz der Netzwerk-Schnittstelle:

Die Netzwerk-Software bestimmt über die Verwendbarkeit von Protokollen mit. Da jeder Hersteller seine eigenen Protokoll-Ebenen definiert hat - wie Novell mit SPX oder IBM mit Netbios -, müssen alle an das Netzwerk angeschlossenen Systeme das jeweilige Protokoll beherrschen. Die Problematik wird dadurch entschärft, daß die Datenbank-Hersteller Softwareprodukte anbieten, die die Ebenen 1 bis 6 nach dem OSI-Schichtenmodell von der Anwendung abschotten.

Wird eine Host-Anbindung realisiert, so muß eine Protokoll-Konvertierung entweder über das LU6.2-Protokoll oder über TCP/IP erfolgen, falls nicht ohnehin im Netzwerk eines dieser Protokolle gefahren wird. Unter diesen Rahmenbedingungen muß mit Reibungsverlusten gerechnet werden, die sich bis auf den Anwendungs-Code auswirken können.

Entscheidend ist ferner, in welchem Dialekt SQL-Befehle formuliert werden müssen. In der Praxis werden folgende Ansätze unterschieden:

Zum einen geschieht die Formulierung in der Syntax des Ziel-Datenbanksystems. Dem Anwendungsentwickler wird die Beherrschung eines zweiten SQL-Dialekts aufgebürdet Der Vorteil dieses Ansatzes liegt in der uneingeschränkten Unterstützung des Ziel-Datenbanksystems, der Nachteil in der Intransparenz der beteiligten Datenbanksysteme.

Die zweite Methode hält sich an die Syntax des lokalen Datenbanksystems. Hier liegt der Vorteil in der einheitlichen SQL-Schnittstelle. Dieser Vorteil wird aber mit einem gravierenden Nachteil erkauft: Der Entwickler muß sich auf den gemeinsamen Sprachvorrat einstellen, den das Gateway in den SQL-Dialekt des Ziel-Datenbanksystems übersetzen kann. Bezogen auf IBMs DB2-Datenbank als Ziel-Datenbanksystem bedeutet dies auch, daß herstellerspezifische Erweiterungen wie zum Beispiel "Trigger" und "stored procedures" nicht verwendet werden können. Diese SQL-Erweiterungen müssen in CICS-Programme umgesetzt und über Remote Procedure Calls (RPC) aktiviert werden.

Naheliegend wäre auch der Einsatz eines 4G-Werkzeugs von einem unabhängigen Hersteller, um via lokaler Datenbank und Gateway auf Host-Datenbestände zuzugreifen. Der Entwickler sollte sich bei einer solchen Konstellation, die drei Sprachebenen vereinen würde, allerdings nicht nur auf die Werbeaussagen der Hersteller verlassen, um nicht zwischen den Spezifikationen der beteiligten Produkte zerrieben zu werden.

Ein schwerwiegendes Problem liegt darin, daß die meisten Gateway-Lösungen nur über dynamische SQL auf DB2-Datenbestände zugreifen können. Der Zugriffsplan kann nicht vorher, sondern erst zum Zeitpunkt der Programmausführung ermittelt werden. Performanceprobleme können aber eher vermieden werden, wenn auf der Host-Seite mit statischer SQL gearbeitet wird. Allerdings geht dies auf Kosten der Flexibilität der Anwender-Schnittstelle und erhöht die Belastung des Datenbank-Administrators Dieser muß sich mit einer noch größeren Anzahl von Ausführungsplänen auseinandersetzen.

Schwierigkeiten mit IBMs DB2-Produkt

Nicht weniger wichtig ist die Sperr-Problematik. Kein anderes Datenbanksystem bildet die Sperrmechanismen von DB2 exakt ab. Die niedrigste Sperrebene von DB2 ist die "Page", das heißt, die physische Speicherseite. Wenn das lokale Datenbanksystem auf der Ebene der Tabellenzeilen sperrt, setzt DB2 demgemäß eine Sperre auf Seitenebene. Darüber hinaus sind durchaus noch diffizilere Sperr-Probleme, die in der Praxis großes Unbehagen auslösen können, zu beachten (etwa bei der Cursor-Verarbeitung). Die Applikation muß deshalb vollständig auf die Sperrmechanismen von DB2 ausgerichtet werden.

Gateways können nur ein sehr eingeschränktes Maß an Transparenz bieten, da die Unterschiede zwischen den verschiedenen relationalen Datenbanksystemen groß sind. Gateways sind am besten für OLTP-charakteristische Aufgabenstellungen mit kurzen Transaktionen geeignet, wobei die Ergebnismenge von SQL-Abfragen nur sehr klein ist und kritische Datentyp-Konversionen nicht erforderlich sind. In jedem Fall aber müssen Applikationen, die das Gateway nutzen sollen - auch in bezug auf Designüberlegungen - sehr sorgfältig geplant werden, um auf der Host-Seite keine Ressourcen zu verschleudern. In Unternehmen mit einem zentralen Mainframe und dezentralen Ablegern mit eigener Datenhoheit sind Gateways heute unverzichtbar, bieten aber noch keine freie Fahrt zu DB2-Datenbeständen. Eine langfristig zufriedenstellende Integration unterschiedlicher Datenbanksysteme von verschiedenen Herstellern ist nur auf Basis übergreifender Architekturen zu realisieren. Diese Architekturen müssen einige wichtige Anforderungen erfüllen: Durchsetzungsfähigkeit, Offenheit, Akzeptanz, technologische Aktualität.

Das anvisierte Ziel ist alles andere als einfach zu erreichen. Je höher der Grad der Interoperabilität, desto mehr Standards müssen ineinandergreifen. Die Bandbreite möglicher Lösungen umfaßt folgende Ansätze:

- Remote Request: Eine Anfrage wird dabei eine entfernte Datenbank übermittelt, wobei aber jedes SQL-Statement als eigenständige Transaktion behandelt wird.

- Remote Unit of Work: Ein Client kommuniziert mit einer bestimmten entfernten Datenbank und hat die Möglichkeit, mehrere SQL-Befehle innerhalb einer Transaktion auszuführen.

- Distributed Unit of Work: Ein Client hat zusätzlich die Möglichkeit zur Verarbeitung knotenübergreifender Transaktionen. Jeder SQL-Befehl wirkt auf eine Datenbank. Hier ist ein Two Phase Commit-Protokoll zwingend erforderlich.

- Distributed Request: Das differenzierende Merkmal ist die Möglichkeit, knotenübergreifend wirkende SELECT-Befehle einzusetzen. Eine von allen beteiligten Knoten verständliche SQL-Version ist unabdingbar, ebenso ein globaler (herstellerneutraler) Optimizer. Dem Optimizer kommt in einem Weitverkehrs-Netzwerk ganz entscheidende Bedeutung zu.

Das ANSI-Normungsgremium aber auch die Datenbank-Hersteller sind damit beschäftigt, Standards für die Interoperabilität zu entwickeln.

Bis dato bildeten sich drei Fraktionen:

- Das ANSI-Sub-Komitee X3H2.1 arbeitet an der Remote Database Access-Standardisierung (RDA).

- Die SQL Access Group fixiert derzeit den RDA-Standard. Dieser Vereinigung gehören nahezu alle Datenbank Hersteller an - nicht allerdings der SQL-Erfinder IBM. Die Spezifikationen der SQL Access Group werden auch von der Open-Systems Organisation X/Open unterstützt.

- IBM entwickelt eine eigene Distributed Relational Database Architecture (DRDA). Einige zur SQL Access Group zählende Datenbank Hersteller haben bereits DRDA-Unterstützung zugesagt. Dazu zählen Oracle, Sybase, Informix und Computer Associates. Auf der Dringlichkeitsliste der Hersteller stehen lediglich die beiden ersten Komplexitätsstufen. Distributed Unit of Work und Distributed Request müssen sowohl von der SQL Access Group als auch von IBM erst noch spezifiziert werden.

Dieser Prozeß wird sich noch über die nächsten Jahre hinziehen.

Die zentrale Rolle der SQL Access Group

Etwas vereinfacht können RDA- und SQL-Access-Group-Spezifikationen als Architekturvarianten gesehen werden. In gewisser Weise repräsentieren die SQL-Access-Group-Spezifikationen die reale Implementierung des RDA-Vorschlags. Auf durchaus vorhandene Unterschiede soll hier nicht weiter eingegangen werden. Immerhin ist es gelungen, im Juni 1991 in New York die Machbarkeit des Konzepts, allerdings auf Basis relativ weniger Gemeinsamkeiten zu demonstrieren.

Was die tatsächlich vorgenommenen Implementierungen anbelangt, gibt es zwei Machtblöcke: IBM und der Rest der Welt. Allerdings hat sich eine ganze Reihe von Herstellern zum Tanz auf beiden Hochzeiten entschlossen.

Bei genauerer Betrachtung zeigen sich zwischen den Architekturen ganz gravierende Unterschiede:

Das RDA-Protokoll befindet sich sowohl auf dem Client- als auch auf dem Server-System und ist auf der Ebene 7 des OSI-Schichtenmodells angesiedelt. Es basiert auf verbindungsorientierter Kommunikation zwischen gleichberechtigten Partnern. Allerdings kann nur der Client RDA-Operationen initiieren. Da diese asynchron abgewickelt werden, kann eine Client-Anwendung mehrere davon anstoßen, ohne erst die Antwort auf eine Anfrage (Request) abwarten zu müssen.

Die Verbindung zwischen Kommunikationspartnern wird über den Aufbau eines Dialoges hergestellt. Dialoge sind temporäre, logische Beziehungen, die auch über mögliche Störungen auf darunterliegenden Ebenen 1 bis 6 erhalten bleiben. Zu Beginn des Dialogs wird eine standardisierte Datenbank-Sprache ausgewählt.

Bereits heute ist abzusehen, daß der derzeitige Funktionsumfang den zukünftigen Anforderungen nicht genügen wird. So wird meist davon ausgegangen, daß nur ein Hardware-System die Server-Funktion übernimmt. Außerdem postulieren die Hersteller, daß nur eine einzige allgemeinverbindliche SQL-Version zum Einsatz kommt. Dies ist jedoch keineswegs der Fall, denn jeder Datenbank-Hersteller verwendet eine vom offiziellen SQL-Standard mehr oder weniger abweichende Implementierung, meist eine Erweiterung des offiziellen SQL-Standards.

RDA-Standard keine in sich geschlossene Norm

Zweifellos bedeutet die Verständigung auf eine standardisierte SQL-Version eine massive Einschränkung. Alle herstellerspezifischen Erweiterungen, wie prozedurale Konstrukte, Trigger-Konzepte und so weiter, könnten vom Entwickler nicht mehr verwendet werden.

Offen ist noch eine Reihe weiterer Probleme, etwa die Unterstützung von SQL-Modulen (Prozeduren), die Unterstützung weiterer Datentypen sowie die Unterbrechbarkeit von RDA-Dialogen.

Der RDA-Standard kann keine in sich geschlossene Norm sein, sondern wird eine Reihe anderer, bereits verabschiedeter, aber auch noch in der Entwicklung befindlicher Normen mit einschließen.

Im Zusammenhang mit RDA sind insbesondere folgende Normierungen beziehungsweise Ansätze zur Normierung zu berücksichtigen:

ISO ASN. 1 (Abstract Syntax Notation One):

Diese Norm ist als ein Mittel zur systemübergreifenden Beschreibung von Daten und Informationen zu verstehen. Mit ASN.1 können Daten in Form von Datenwerten und Datenstrukturen beschrieben werden. Für das Zusammenwirken unterschiedlicher Datenbanksysteme mit verschiedenen Datentypen kann ASN.1 die Funktion einer herstellerneutralen Datendefinitionssprache übernehmen.

In dieser Weise ist ASN.1 aber nicht auf relationale Datenbanken beschränkt, sondern kann als ein Eckpfeiler standardisierter Kommunikation angesehen werden. Dies kommt auch durch die Einbindung in eine Reihe weiterer internationaler wie FTAM, CMIP, ODA/ODIF, ACSE zur Geltung.

ISO ACSE (Association Control Service Element):

Die ACSE-Spezifikationen definieren Protokolle zur Kontrolle der Verbindung zwischen zwei Anwendungen (Wunsch zum Aufbau einer Verbindung, Bestätigung dieses Wunsches, und so weiter).

ISO OSI DTP (Distributed Transaction Processing):

In einer verteilten Umgebung mit ebenso verteilten Transaktionen reichen die innerhalb der RDA-Spezifikation vorgesehenen Befehle nicht mehr aus Der noch nicht verabschiedete DTP-Standard füllt diese Lücke aus. Mit Hilfe dieses Protokolls kann eine Client-Anwendung parallel mehrere Verbindungen mit mehreren Server-Systemen aufbauen. Somit ist dieses Protokoll notwendige Voraussetzung für jegliche Art Serverübergreifender Datenverteilung (Distributed Unit of Work und Distributed Request) bildet auch die Basis für das dann unverzichtbare Two Phase Commit-Protokoll.

Die IBM-DRDA-Architektur ordnet sich in die proprietären Spezifikationen der IBM ein. Sie basiert nicht auf internationalen Standards, sondern auf den SAA-Standards des Unternehmens DRDA kann ebensowenig wie RDA für sich alleine stehen. Sie ist im wesentlichen in folgende IBM-Architekturen eingebunden

- Distributed Data Management Architecture (DDM)

- Formatted Data Object Content Architecture (FD:OCA)

- Character Data Representation Architecture (CDRA),

- Logical Unit Type 6.2 (LU6.2).

DRDA beschreibt das Regelwerk für die Interoperabilität der Datenbanksysteme innerhalb der SAA-Welt. Auch das geplante AIX-Datenbanksystem wird von DRDA unterstützt. Datenbanksysteme von Fremd-Herstellern sind integrierbar, allerdings müssen diese zwingend DRDA vollständig unterstützen.

Die Client-Anwendungsprogramme verwenden ebenfalls einen durch die "SAA CPI Database Interface Level 2"-Spezifikationen quasi-standardisierten 5 Sprachumfang. Datenbanksysteme von Fremd-Herstellern müssen sich ebenfalls an die genannte Spezifikation halten, wenn sie DRDA-konform sein sollen.

DDM-Protokoll steuert und überwacht

Auf Basis des LU6.2-Protokolls als Träger übernimmt das DDM-Protokoll die Steuerung und Überwachung des logischen Datenaustauschs zwischen den beteiligten DV-Systemen. Die DDM-Architektur ist unabhängig von der Hardware und von Betriebssystemen. Gegenüber dem jeweiligen DV-System stellt es somit eine allgemeine Schnittstelle auf hoher Ebene bereit. "DDM"-Befehle werden synchron ausgeführt.

Die FD:OCA-Architektur übernimmt zusammen mit der CDRA-Architektur im Vergleich mit RDA die Funktion der ASN.1-Spezifikationen, um einen Datenaustausch zwischen DV-Systemen zu ermöglichen, die mit unterschiedlichen System-Codes (zum Beispiel EBCDIC und ASCII) oder verschiedenen Code-Tabellen arbeiten.

Insgesamt spiegelt die DRDA-Architektur alle Normen internationaler Standardisierungs-Gremien mit entsprechenden proprietären Standards wider. Die IBM-DRDA-Architektur kann unter Berücksichtigung des derzeitigen Entwicklungsstandes deshalb als vollständig bezeichnet werden. Sie hat durchaus das Potential, sich als Industriestandard zu etablieren.

Die Bedeutung der Standardisierung

Welche Schlüsse kann der Anwender zum gegenwärtigen Zeitpunkt aus diesem Standardisierungs-Wirrwarr ziehen? Wenn das Fundament schwankt, läßt sich schlecht ein Haus bauen. Im übertragenen Sinne: Wenn keine einheitliche SQL-Implementierung existiert, wird die Zusammenarbeit unterschiedlicher Datenbanksysteme zum Problem.

Die RDA-Einschränkung auf eine standardisierte SQL-Implementierung ist weltfremd. Die SQL Access Group stützt sich zwar auf RDA-Definitionen,

weicht aber in der Sprach-Implementierung vom ISO-SQL-Standard ab. X/Open weicht sowohl vom ISO-SQL-Standard als auch von den RDA-Spezifikationen ab. In der IBM-Welt stellt sich die Situation keinen Deut besser dar.

Die einschlägigen IBM-Dokumente legen mit einer Vielzahl grüngedruckter Anmerkungen Zeugnis davon ab, daß auch die bis dato vier maßgeblichen IBM internen SQL-Dialekte nicht vollständig miteinander kompatibel sind. Man darf spekulieren, daß für das geplante AIX-Datenbanksystem die SQL-Dialekte Nummer 5 und 6 ins Haus stehen.

Wie wirken sich die beiden geschilderten Ansätze in der Praxis aus? Hier werden gravierende Unterschiede sichtbar: Während RDA von einer allgemeinverbindlichen, standardisierten SQL ausgeht, ist DRDA wesentlich flexibler.

Auf spezifische Leistungsmerkale, wie zum Beispiel performancesteigernde Optionen bei DB2, muß der Entwickler nicht verzichten.

Außerdem hat DRDA den wesentlichen Vorteil auf seiner Seite, auch statische SQL (Packages) zu unterstützen. RDA hingegen kennt nur dynamische SQL, das heißt der Ausführungsplan für eine Abfrage wird erst zum Zeitpunkt der Ausführung ermittelt und verbraucht damit zusätzliche Ressourcen. Die wesentlichen, für die Praxis relevanten Punkte, zeigt die Grafik.

Welche Konsequenzen haben die gegenwärtigen Positionskämpfe für den Anwender? Die klare Antwort lautet: Alle werden verlieren. Gerade in einem Bereich, der das reibungslose Ineinandergreifen mehrerer Standards erfordert, sind proprietäre Alleingänge fehl am Platz. Je heterogener das Umfeld, desto mehr müssen internationale Standards verbindlich eingehalten werden. Derzeit erscheint die Realisierung dieser Maxime als purer Wunschtraum.

Darüber hinaus gibt es äußerst kritische Bereiche, die von internationalen Standards überhaupt nicht tangiert werden. Dazu zahlt zum Beispiel die Frage, wie ein Optimizer den Ausführungsplan für einen SQL-Befehl ermittelt. Zwischen guten und schlechten Strategien der Optimierung liegen erfahrungsgemäß Welten.

In Weitverkehrsnetzwerken mit verteilten Knoten bestimmt die Qualität des Optimizer über die Höhe der Kosten für die Datenübertragungskosten entscheidend mit. Wie aber sollte es jemals möglich sein, daß sich Hersteller dazu bereit finden, ein Betriebsgeheimnis, nämlich die Arbeitsweise ihres Optimizers, offenzulegen und einen "herstellerneutralen" Optimizer zu entwickeln? Der darauf hoffende Anwender wird mit Sicherheit bis zum Sankt-Nimmerleins-Tag warten.

Für den Anwender bleibt die Erkenntnis: Je stärker der Integrationsgrad, desto mehr wird die Entscheidung für die Datenbankumgebung zu einer Entscheidung über das gesamte Systemumfeld.

Der Anwender ist am besten beraten, wenn er eine möglichst homogene Datenbank-Strategie verfolgt. Damit gibt er aber die Offenheit, die er zuvor gewann, zu einem guten Teil wieder auf.

Anwender sucht den Generalunternehmer

Noch etwas kommt hinzu: Wie sollen Anwender ein weiteres 500-Seiten-Dokument (zu erwartende Seitenstärke des offiziellen SQL2-Standards) überschauen und Hersteller-Implementierungen daran messen? Eine Reihe anderer Standards sind natürlich ebenfalls zu untersuchen. Schon aus Zeitgründen wird der Anwender schlichtweg überfordert sein, sich aus dem Selbstbedienungsladen der "offenen Welt" die für ihn geeigneten Komponenten herauszusuchen und auf Interoperabilität abzuklopfen. Er wird deshalb nach einem Hersteller, einer Art Generalunternehmer, Ausschau halten, der ihm ein funktionierendes Gesamtsystem garantiert.

Vorteile für die Hersteller

Aus Herstellersicht macht der Kampf um die Durchsetzung eigener Standards durchaus Sinn. Hersteller müssen versuchen, die entscheidenden strategischen Positionen zu besetzen um die Kundeninvestitionen auch in offenen Umgebungen kontrollieren zu können. Neben Bereichen wie Netzwerk-Management und Repository ist das Daten-Management eine dieser entscheidenden Schlüsselpositionen.

Auf mittlere und lange Sicht gesehen werden Architekturen wie IBMs DRDA und ANSI/ISO-RDA (SQL-Access-Group- und X/Open-Spezifikationen) ein sehr viel größeres Maß an Interoperabilität bringen. Die Marktmacht wird letztlich entscheiden, welche der Architekturen sich durchsetzt. Manches spricht für die IBM-DRDA-Architektur -, nicht zuletzt auch die Entscheidungen nahezu aller Datenbank-Hersteller von Rang die IBM-Architektur zu unterstützen. Konkrete Produkte müssen jedoch erst nachweisen ob es Informix, Ingres, Oracle, Sybase und anderen wirklich ernst ist oder ob man nur aus Gründen der Marketingstrategisch erst einmal Flagge zeigen wollte.