Kaum hat sich die Structured Query Language (SQL) zumindest ansatzweise als Standard etabliert, droht sie schon wieder zu veralten, da sie in der vorliegenden Form auf den Einsatz mit relationalen Datenbanksystemen beschraenkt ist. De facto bemueht sich die ISO jedoch, die Abfragesprache an objektorientierte Systeme anzupassen.

Nichts geht beim Zugriff auf relationale Datenbanken ohne SQL. Die Zugriffssprache, deren Urspruenge in die IBM-Labors zurueckreichen, hat in den vergangenen Jahren weitreichende Akzeptanz und zentrale Bedeutung gewonnen. Kein Datenbankhersteller kann es sich mehr leisten, eine eigene Zugriffssprache auf relationale Datenbanken einzufuehren. Vielmehr wird er am Markt nur dann bestehen, wenn er ueber eine ANSI- beziehungsweise ISO-konforme SQL-Implementierung verfuegt, denn nahezu jede Ausschreibung verlangt die Konformitaet zu diesem Standard.

Die allgemeine Akzeptanz, die weitreichende Bedeutung und die kontrollierte Weiterentwicklung durch Normungsgremien bedeuten aber keineswegs, dass SQL frei von Defiziten waere. Im Verlauf seiner mehr als zehnjaehrigen Geschichte hinkte SQL stets der technologischen Entwicklung hinterher. Dieser Umstand war Anlass fuer manche Schelte, die sich vornehmlich an die Adresse des ANSI- Gremiums richtete.

Kein Anbieter hat den Standard uebernommen

Waehrend sich SQL immer am puren relationalen Modell orientierte, implementierten Hersteller zusaetzliche, fuer die Praxis durchaus sinnvolle und wichtige Features. Diese mussten selbstverstaendlich durch herstellerspezifische Erweiterungen der SQL-Sprache, also durch eigene Sprachkonstrukte, unterstuetzt werden.

Der SQL-Standard in der reinen Form wurde von keinem einzigen Datenbank-Hersteller uebernommen. Stets implementierten die Hersteller eine Uebermenge des SQL-Standards, oder sie folgten bei der Interpretation des Standards ihren eigenen Interessen.

So kann es durchaus vorkommen, dass ein und derselbe Befehl bei verschiedenen Datenbanksystemen ein voellig unterschiedliches Sperrverhalten bewirkt. An Offenheit war also nicht wirklich zu denken.

Eine Chance, die de facto sehr unterschiedlichen SQL- Implementierungen wieder enger zusammenzufuehren, eroeffnet sich mit ISO-SQL-92, dem aktuellen Stand der Standardisierung. Waehrend in der Vergangenheit nahezu alle SQL-Implementierungen den Standard in wesentlichen praxisrelevanten Punkten uebertrafen, uebernimmt nun der Standard eine Fuehrungsrolle.

Schwerpunkte der Standardisierung bilden jetzt vor allem die erstmalige Strukturierung eines Systemkatalogs sowie Aenderungsmoeglichkeiten bei der Definition von Datenbank-Objekten. Hin- zu kommen Dynamisches SQL, zusaetzliche relationale Operatoren sowie neue Datentypen. Auch die zumindest in Ansaetzen definierte Client-Server-Architektur zaehlt zu den wichtigen Neuerungen.

Das Volumen von ISO-SQL-92 entspricht etwa dem Fuenffachen von ISO- SQL-89. Das funktionale "Netto-Volumen", also die Merkmale, die von Herstellern noch nicht realisiert wurden, laesst sich auf etwa 100 bis 150 Prozent der Vergleichsbasis von ISO-SQL-89 beziffern. Dieses Verhaeltnis hat jedoch keine Aussagekraft fuer eine spezifische SQL-Implementierung, da die Datenbankhersteller auch Funktionen - beispielsweise Prozedurkonzepte und Trigger - implementieren, die auch von ISO-SQL-92 nicht abgedeckt werden.

Nicht alle Anforderungen der Praxis sind abgedeckt

Trotz der bedeutenden, mit ISO-SQL-92 eingefuehrten Erweiterungen und Konkretisierungen wurden bei weitem noch nicht alle Anforderungen der Praxis gedeckt. Keinesfalls sind bereits alle Verfahren hinreichend exakt und eindeutig standardisiert. Dies betrifft in besonderer Weise den Verbindungsaufbau zwischen Client und Server.

Viele Verhaltensweisen bei der Ausfuehrung von SQL-Befehlen sind ebenfalls nicht standardisiert und koennen deshalb vom Hersteller nach eigenem Ermessen festgelegt werden. So ist es beispielsweise dem Hersteller ueberlassen, ob innerhalb einer Transaktion nicht nur Datenmanipulations-Befehle, sondern auch Datendefinitions- beziehungsweise Schema-Befehle ausgefuehrt werden koennen. Darueber hinaus wurden auch noch nicht alle Operationen der relationalen Algebra explizit im Sprachumfang abgebildet.

Insgesamt gesehen bleibt auch mit ISO-SQL-92 fuer die Hersteller noch genuegend Spielraum fuer herstellerspezifische Festlegungen.

Die meisten heutigen SQL-Implementierungen entsprechen in etwa dem "Entry Level" von ISO-SQL-92. Doch realisieren, wie bereits erwaehnt, einige Herstellerimplementierungen schon Leistungsmerkmale, die erst fuer SQL3 vorgesehen sind. Allerdings kann zu diesem Zeitpunkt kein Hersteller davon ausgehen, dass die Syntax der jeweiligen SQL-Implementierung dem dann gueltigen ISO- SQL-Standard entsprechen wird.

Die Herstellerbindung bleibt voll erhalten

Trotz ISO-SQL-92 bleibt also die Herstellerbindung voll erhalten. Aeusserst problematische Auswirkungen ergeben sich daraus fuer echt verteilte Datenbankloesungen. Hier ist entscheidend, dass alle beteiligten Datenbanksysteme zumindest ueber einen einheitlichen Kern-Sprachumfang verfuegen und ausserdem die SQL-Befehle in identischer Weise interpretieren. Proprietaere Sprachimplementierungen mit unterschiedlichem Leistungsumfang machen die Realisierung mit Datenbanksystemen unterschiedlicher Hersteller deshalb zu einem kritischen Unterfangen. Eine echte Chance fuer Interoperabilitaet eroeffnet sich nur, wenn es gelingt, SQL wirklich zu einem Praxis-Standard zu erheben.

Aber selbst dann waere SQL immer noch eine auf relationale Datenbanksysteme beschraenkte Sprache. Zwar existieren heute schon Moeglichkeiten zum Zugriff auf konventionelle Dateiverwaltungssysteme sowie auf hierarchische und Netzwerk- Datenbanken, ja sogar auf objektorien- tierte Datenbanken mit SQL- aehnlicher Syntax; doch handelt es sich hier ausschliesslich um herstellerspezifische Loesungen.

Kursaenderung vor etwa eineinhalb Jahren

Unter dem Aspekt zukuenftiger Datenbankentwicklungen muss zumindest eine Oeffnung in Richtung objektorientierter Systeme stattfinden. Und genau dies ist eine der Richtungen, in die sich SQL weiterentwickeln wird.

Seit mehreren Jahren wird an SQL3, der dritten Generation des SQL- Standards, gearbeitet. Oberflaechlich mag SQL3 als eine Sammlung von Features gesehen werden, die fuer ISO-SQL-92 nicht mehr beruecksichtigt werden konnten. Da die Hersteller den Zeitbedarf fuer die vollstaendige Umsetzung von ISO-SQL-92 (Full Level) in konkrete Sprachimplementierungen ohnehin auf etwa acht bis zehn Jahre schaetzten, kam SQL3 schon fast keine Bedeutung mehr zu.

Vor etwa eineinhalb Jahren vollzog sich jedoch eine bedeutsame Kursaenderung: SQL3 wird bedeutende objektorientierte Erweiterungen enthalten und damit die Bindung an das relationale Modell verlieren.

Relationale und objektorien- tierte Datenbanken gehen von voellig unterschiedlichen Philosophien aus. Waehrend bei relationalen Datenbanken die Datenwerte sichtbar sind, koennen diese bei objektorientierten Datenbanken nur durch die mit den Daten in den Objekten verkapselten Methoden sichtbar gemacht werden. Mit SQL3 wird nun das Ziel verfolgt, beide Welten soweit wie moeglich ueber eine Zugriffssprache zusammenzufuehren. Der Anwendungsentwickler soll kuenftig Techniken objektorientierter Programmierung in seinen Applikationen anwenden koennen, ohne sich darum kuemmern zu muessen, ob sich die Daten in einer relationalen oder einer objektorientierten Datenbank befinden. Diese Transparenz schliesst auch ein, dass innerhalb derselben Transaktion der Zugriff auf unterschiedliche Datenbanken moeglich ist.

Die Liste der Features fuer SQL3 ist lang. Auf der Kandidatenliste stehen:

- Trigger (aktive Regeln),

- Prozeduren ("Multistatement Procedures" und "Stored Procedures"),

- anwenderdefinierte Datentypen (abstrakte Datentypen) und anwenderdefinierte Funktionen,

- Spezialisierung und Generalisierung (Subtypes und Super- types),

- Generalisierung des Datenmodells,

- Unterstuetzung verteilter Datenbanken,

- ein mehrstufiges Sicherheitskonzept sowie

- Schnittstellen zu anderen Standards (zum Beispiel "Remote Database Access" und "Transaction Processing").

Bei Beruecksichtigung aller genannten Features wuerde der Umfang von SQL3 jedes sinnvolle Mass sprengen. Die Abfragesprache wuerde sich im wahrsten Sinn des Wortes zu einem Moloch entwickeln. Davon abgesehen duerften nicht alle Features fuer jede Anwenderinstallation oder fuer jeden Hersteller notwendig sein. Die Absicht der Normungsgremien, SQL3 in einen Kern und mehrere optionale Teile zu gliedern, kann deshalb als sinnvoll angesehen werden.

Bei zuegigem Vorwaertsschreiten koennte der Kern von SQL3 vielleicht schon 1995 verabschiedet werden. Weitere Teile wuerden spaeter folgen beziehungsweise bei Dringlichkeit sogar vorgezogen und als Erweiterung von ISO-SQL-92 veroeffentlicht werden. Dies betraefe mit grosser Sicherheit "Stored Procedures", "Multistatement Procedures" und ein "Call Level Interface".

Bemerkenswert ist vor allem der Entschluss, eine prozedurale Sprache als Bestandteil von SQL zu definieren. Damit wird der Charakter von SQL als strikt nicht-prozedurale Sprache aufgegeben.

Obwohl dieser Entschluss vermutlich sehr schwer gefallen ist, fuehrte kein Weg an dieser Entscheidung vorbei: Die in Client- Server-Umgebungen faktisch unverzichtbaren Prozeduren ("Stored Procedures" und "Multistatement Procedures") koennen ohne eine prozedurale Sprache nicht realisiert werden. Ausserdem ist eine prozedurale Sprache dringend erforderlich, um in einer objektorientierten Umgebung Methoden zu erstellen, die "mit den Daten umgehen".

Natuerlich koennte auch eine konventionelle Sprache der dritten Generation (3G) die Funktion der prozeduralen Sprache uebernehmen. Dem steht jedoch ein Problem entgegen, naemlich die eingeschraenkte Verfuegbarkeit von 3G-Sprachcompilern ueber mehrere Plattformen hinweg. Wenn SQL3 in den derzeit sichtbaren Bahnen weiterentwickelt wird, eroeffnen sich fuer alle Datenbankanwender interessante Perspektiven.

Relationale Datenbanken eignen sich bekanntlich am besten fuer relativ einfache Datenmodelle. Falls dies nicht der Fall und das Mengengeruest nicht eben klein ist, muss aus Performance-Gruenden oft eine kontrollierte Denormalisierung erfolgen. Abstrakte Datentypen werden in relationalen Sytemen - abgesehen von spezifischen Herstellerimplementierungen - nicht unterstuetzt.

Moeglichkeit des sanften Uebergangs

Objektorientierte Datenbanken hingegen koennen komplexere Datenstrukturen ungleich besser und einfacher verwalten. Insbesondere lassen sich in abstrakten Datentypen beispielsweise grafische und fotografische Daten sowie Audio- und Video- Informationen beschreiben.

SQL3 kaeme hier - aus Sicht der Anwendung - die Aufgabe eines wirklichen Integrators zu. Die Frage, ob ein relationales oder ein objektorientiertes Datenbanksystem einzusetzen ist, wuerde demnach an Bedeutung verlieren. Darueber hinaus waere die Moeglichkeit fuer einen "sanften" Uebergang zu objektorientierten Datenbanken gegeben, falls dies im jeweiligen Umfeld opportun sein sollte.

Aber alles hat seinen Preis: Waehrend das ISO-SQL-92-Dokument "nur" runde 600 Seiten umfasst, duerfte SQL3 bestimmt mindestens 1000 Seiten stark sein. Die Herstellerhandbuecher werden dieses Volumen widerspiegeln. Ausserdem nimmt mit Sicherheit auch die Komplexitaet ueberproportional zu.

Eine Angelegenheit fuer Spezialisten

Vor diesem Hintergrund stellt sich die Frage: Wie kann man mit der wachsenden Komplexitaet Schritt halten?

Schon jetzt wagen selbst SQL-Kenner kaum zu behaupten, den SQL- Standard in gesamtem Umfang zu beherrschen. Der Umgang mit SQL wird sich deshalb zwangslaeufig - und dies noch viel mehr als bisher - zu einer Angelegenheit fuer Spezialisten entwickeln.

Trotzdem ist SQL ohne Zweifel auf einem richtigen Weg. Wenn es gelingt, die derzeit noch als schmerzlich empfundenen Luecken durch ein Addendum zu ISO-SQL-92 wenigstens grob zu schliessen, wachsen die Chancen fuer eine echte Interoperabilitaet von Datenbanksystemen unterschiedlicher Hersteller. Damit steht dann auch in der Praxis ein wesentlich besseres Fundament fuer die Zusammenfuehrung der Informationsinseln zur Verfuegung.

* Dieter Jenz ist geschaeftsfuehrender Gesellschafter bei der Unternehmensberatung Jenz & Partner GmbH in Erlensee.