Neben den Tendenzen, SQL weiter zu normieren, bemühen sich immer mehr Softwarehersteller darum, ihre Werkzeuge und Anwendungen Datenbank-unabhängig zu entwickeln. Dies dient nicht nur dazu, den breiten Markt der Datenbanken mit derselben Software bedienen zu können. Nach Einschätzung von Veit Irtenkauf wollen die Softwarehäuser unabhängig von den Entwicklungsstrategien der Datenbankhersteller sein.

Die am häufigsten verwendete Schnittstelle zur Datenbank ist aufgrund ihrer Normierung die Structured Query Language (SQL), die explizit als Embedded SQL in C oder Cobol oder implizit in 4GLs benutzt wird. Dabei bleibt unbeachtet, daß sich SQL auf verschiedenen Datenbanken meist syntaktisch und vor allem in ihrer jeweiligen Implementierung auf dem Betriebssystem unterscheiden.

Dieser Aspekt spielt später eine erhebliche Rolle bei der Portierung der Anwendung auf eine andere Datenbank und erfordert zusätzliche, meist im Zeitplan und im Budget nicht vorhergesehene Aufwände, die nicht selten zu einem vollständigen Re-Design einer Anwendung führen können. Deshalb ist die Kenntnis über den Umfang, die verschiedenen Dialekte und vor allem die Weiterentwicklung von SQL schon vor Beginn eines Projektes von großer Wichtigkeit.

Wie soviele andere Entwicklungen wurde auch SQL ursprünglich von IBM mit dem Hintergrund entwickelt, eine einfache und leicht erlernbare Sprache zu schaffen, um Informationen aus relationalen Datenbanksystemen (RBMS) zu gewinnen. Heute hat sich SQL als die Standard-Abfragesprache im Markt etabliert. Trotz der inzwischen erfolgten Normierung durch ANSI gibt es aber immer noch kleine Unterschiede in den jeweiligen Implementierungen der Datenbank-Hersteller, nicht zuletzt, um über den Standard hinausgehende Eigenschaften und Features zu implementieren. Dies führt dazu, daß SQL-Anwendungen beziehungsweise ESQL-(Embedded SQL in C oder Cobol-)Programme nicht portierbar sind.

Wer oder was sind nun die treibenden Kräfte hinter der SQL-Standardisierung? Als erstes muß hierbei natürlich ANSI genannt werden. Das Komitee hat den heute noch gültigen ANSI-Standard 1 geschaffen, der im wesentlichen sowohl die einfache Abfrage und Manipulation von Daten (Select, Update, Insert, Delete) durch die sogenannte DML (Data Manipulation Language) in der SQL regelt, als auch die Erstellung und Modifikation von Tabellen und Views im Data Dictionary (Create, Alter, Drop) und der Datenbank-Zugriffsrechte (Grant, Revoke) durch die DDL (Data Definition Language) ermöglicht. Dieser ANSI-Standard 1 ist ziemlich rudimentär und wird in Kürze durch einen ANSI- Standard 2 ersetzt, der zum einen erweiterte Möglichkeiten der DML und der DDL enthält, zum anderen Dynamic-SQL in C oder Cobol unterstützt.

Dynamic SQL bedeutet, daß in einem C-Programm eine Abfrage nicht statisch programmiert werden muß (zum Beispiel: Select Firmenname from Firma), sondern auch dynamisch aus Variablen zusammengesetzt sein kann (Select Var1 from Var2), eine wesentliche Erweiterung, die eine effizientere Programmierung erlaubt. Auch X/Open ist inzwischen auf den ANSI-Standard eingeschwenkt. Am ANSI-Standard orientieren sich heute fast alle RDBMS am Unix-Markt (zum Beispiel Informix, Ingres, Sybase, Unify). Am weitesten entfernt vom ANSI-SQL-Standard ist Oracle.

Der zweite, sicherlich genauso wichtige Marktfaktor für SQL ist IBM. Im Rahmen von DB2 wurde SQL als das Standard-Abfragesystem für DB2 konzipiert und wird von der IBM - trotz Kooperation mit ANSI - als "Industriestandard" SQL im Markt gesehen. Der Umfang der DB2-SQL entspricht etwa dem der ANSI-SQL. Obwohl sich auch ANSI bei seiner Definition des Standards an die IBM angelehnt hat, gibt es neben syntaktischen Unterschieden (zum Beispiel Wildcards *, ? in ANSI, %, _ in DB2) auch funktionale Unterschiede (Zugriffsrechte über Schema-Konzept in ANSI, User-Konzept in DB2) zwischen IBM und ANSI.

Dies führt zu Problemen beim Transfer von Programmen zwischen den beiden Welten. Oracle als bekanntestes Unix-RDBMS orientiert sich voll an dem "Industriestandard" DB2.

Da die technologische Entwicklung bei RDBM-Systemen inzwischen weit über den Stand der Abfragen und Manipulationen fortgeschritten ist, hat heute jeder RDBMS-Anbieter Erweiterungen in SQL implementiert, die diesen technologischen Fortschritt im jeweiligen Produkt unterstützen und damit natürlich über den ANSI-Standard hinausreichen.

Als wichtigste funktionale Erweiterungen sind dabei zu sehen:

- Stored Procedures (Ingres, Sybase) zur Definition der Referential Integrity auf logischer Ebene,

- Links (Unify) zur Definition der Referential Integrity auf physikalischer Ebene,

- Objectoriented Definitions (Ingres) zur Definition eigener Objekte inklusive Regeln für diese Objekte,

- Remote Database Access (Client-Server Architecture) sowie Distributed Databases (Informix, Ingres, Oracle, Sybase, Unify), um Datenbanken in Netzwerkumgebungen beziehungsweise Verteilungskonzepte zu unterstützen.

Diese Aufstellung verdeutlicht, daß nicht alle RDBMS-Anbieter an den gleichen Erweiterungen arbeiten, beziehungsweise diese Erweiterungen bereits im Produkt anbieten. Dies führt dann dazu, daß Anwender, die verschiedene Datenbanken benutzen, aus Kompatibilitätsgründen auf die Nutzung dieser Erweiterungen verzichten müssen.

Der Weg zur Kompatibilität

Da die Kompatibilität auch bei solchen, über den Standard hinausgehenden Erweiterungen vom Anwender nicht nur gewünscht, sondern ausdrücklich gefordert wird, wurden in den USA verschiedene Gruppierungen gegründet, um sich mit der Vereinheitlichung und damit der Kompatibilität einzelner Entwicklungen zu befassen. Als wichtigstes Themengebiet wäre hier die Verteilung von relationalen Datenbanken zu nennen, mit dem sich gleich zwei Gruppierungen, nämlich die SQL Access Group sowie Sybase, beschäftigen.

Mit Ausnahme von Sybase haben sich die oben genannten RDBMS-Anbieter mit einigen Hardwareherstellern (unter anderem HP, DEC, Sun, nicht jedoch IBM) zur SQL Access Group zusammengeschlossen, um auf Basis der ANSI-SQL - so erklärt sich das Fernbleiben der IBM - eine "New, extended SQL" zu definieren, die im wesentlichen die "Interoperability", also die Zusammenarbeit verschiedener Datenbankprodukte in homogenen oder heterogenen Netzwerkumgebungen, beinhaltet. Dies ist vor allem sinnvoll, wenn mehrere Datenbanken verschiedener Hersteller zu einer großen, verteilten Datenbank zusammengefaßt oder mehrere SQLs beziehungsweise 4GLs verschiedener Hersteller in Client-Server-Umgebungen genutzt werden sollen.

Zu diesem Zweck hat die SQL Access Group ein gemeinsames Protokoll, das Remote Database Access (RDA) Protocol, ausgewählt, das von der European Computer Manufacturers Association (ECMA) entworfen wurde. Da an RDA zur Zeit noch gearbeitet wird, sollen zukünftige Entwicklungen auf diesem Protokoll basieren, die dann von den jeweiligen Datenbank- Produkten beziehungsweise SQL-Implementierungen angesprochen werden können.

Im Gegensatz dazu kann Sybase, unterstützt von Apple und Microsoft, die beide an Sybase beteiligt sind, bereits ein fertiges Produkt, den SQL Open Server, beziehungsweise SQL Open Client vorweisen. Bei Open Server und Open Client handelt es sich jeweils um ein Software-Interface, das in Fremddatenbanken eingelinkt werden kann und somit den gesamten Client-Server-Betrieb und damit den RDA handhabt.

Dabei zerlegt der Open Client die Datenbankabfrage einer Fremddatenbank in ein eigenes Sybase-Protokoll, übergibt die Daten dann über das Netz an den Open Server, der die Abfrage wiederum zurückverwandelt in die jeweilige SQL der Server-Datenbank. Auf dem gleichen Weg werden die Ergebnisse wieder zurücktransportiert.

Laut Aussagen von Sybase ist dieses Verfahren auch nicht auf SQL beschränkt. Problematisch für die Durchsetzung der Sybase-Technologie werden sicherlich die Lizenzgebühren sein, die ein RDBMS-Anbieter abführen muß, wenn er das Open-Client- Server-Konzept in seine Architektur einbindet. Im Falle der SQL Access Group entfallen solche Lizenzgebühren.

Eine weitere Gruppierung ist die Object Management Group (OMG), der auch die meisten der namhaften Datenbank- und Hardwarehersteller angehören. Diese Gruppierung beschäftigt sich mit der weiteren Entwicklung von Objectoriented Databases, wie bereits der Name der Gruppierung aussagt. Unter dem Begriff "objectoriented" wird dabei zum einen die Definition von eigenen, abstrakten Datentypen mit allen Beschreibungen und Regeln verstanden, so daß diese mit der relationalen Algebra unter SQL voll verarbeitet werden können.

Zum zweiten versteht man darunter aber auch die Einteilung aller vorhandenen Objekte, also auch der Standardobjekte wie Strings und so weiter sowie der Domänen, in eigenen Klassen, Subclasses, Instanzen, Aggregate, die untereinander durch eigene Messages und deren Protokolle kommunizieren. Die wesentliche Erleichterung beim Einsatz von Objectoriented Databases wird sein, daß alle Arten von Aktionen und Manipulationen mit und von Objekten grundsätzlich erlaubt sind und entsprechend eingeschränkt werden können, während bei den heutigen Entwicklungsansätzen eine Aktion und Manipulation von Datenelementen nur dann geschieht, wenn diese explizit vorher programmiert wird.

Dies wird zu einer erheblichen Verbesserung der heutigen Entwicklungsmethoden und damit zu einer spürbaren Steigerung der Produktivität führen. Funktionalitäten und Features wie Farbe, Grafik, Hypertexte, BLOBs, Drag & Drop, Cut & Paste, "Canvas"-Felder, Mouse-Clicks und so weiter, die heute vor allem von grafischen Oberflächen beziehungsweise Spezialanwendungen her bekannt sind, werden dann auch auf die objektorientierte Datenbank abgebildet beziehungsweise können in dieser abgelegt und mit SQL manipuliert werden.

Weitere Gruppierungen existieren zum Beispiel für den Bereich der Normierung von Benchmarks, das sogenannte Transaction Processing Council (TPC), an dem ebenfalls die obengenannten RDBMS-Anbieter beteiligt sind.

In vielen Marktübersichten und Projektausschreibungen, ja zum Teil sogar in Marktstudien wird SQL mit der relationalen Datenbank selbst gleichgesetzt, obwohl SQL ja nur eines, wenn auch die wichtigste, Schnittstelle zum RDBMS ist. Auch beim Anwender trifft man oft die "Checklistenmentalität", das heißt die (ANSI-)SQL steht als einziger Punkt neben der Verteilung beziehungsweise Client-Server-Architektur auf der Checkliste bei der Auswahl einer auf einem RDBMS (und eventuell sogar 4GL) basierenden Anwendung. Ist eine solche Vereinfachung zweckmäßig und angebracht?

Nein, sicherlich nicht. Da es sich bei der SQL nur um eine Schnittstelle, nicht aber um die Datenbank selbst handelt, kann die Datenbank nicht anhand der Funktionalität und des Befehlsumfangs einer Schnittstelle beurteilt werden. Folgende Aussagen über ein RDBMS sind immer unabhängig von der SQL:

- Performance,

- Zugriffsarten (Hash, Btree, Link, Direct, Sequential),

- Datentypen, feste/variable Satzlänge,

- Data Integrity, Referential Integrity,

- Unterstützung von RAW-Devices, um die Datenbank über mehrere Platten sowohl auf einem Rechner als auch in einer verteilten Datenbankumgebung zu verteilen,

- Clustering,

- Verfügbarkeit und Leistungsumfang anderer RDBMS-Tools (zum Beispiel Online Backup, Automatische Reorganisation),

- Automatischer Wiederanlauf (Automatic Recovery) nach Systemabsturz,

- Implementierung von tieferliegenden Schnittstellen (Host Language Interfaces),

- Implementierung von höherliegenden Schnittstellen (4GLs),

- Implementierung von Schnittstellen zu Fremdprodukten (4GLs vor anderen Herstellern).

Diese Punkte sollten immer unabhängig von der Leistungsfähigkeit der jeweiligen SQL-Implementierung bei einer Datenbankauswahl geprüft werden, um die wirkliche Leistungsfähigkeit des RDBMS festzustellen.

Auf der anderen Seite erfordert diese Betrachtungsweise natürlich ein gewisses Know-how über relationale Datenbanken, das in der Regel beim Anwender nicht vorhanden ist und deshalb mühsam erlernt oder teuer erkauft werden muß.

Durch die Datenbankwelt "geistert" seit einiger Zeit ein neues Schlagwort: Interoperabilität. Darunter versteht man die Möglichkeit, Anwendungsprogramme auf Basis von Entwicklungstools wie 4GLs zu entwickeln, die selbst Datenbank-unabhängig sind und damit diese Unabhängigkeit auf einer höheren Entwicklungsebene als auf einer 3GL im Zusammenspiel mit der ESQL anbieten.

In diesen Entwicklungs-Tools wird dann als Datenbankschnittstelle für den Entwickler ein ANSI/SQL-Subset (enthält meistens die volle DML) angeboten, der sich zwangsläufig exakt am Standard orientieren muß, um alle Datenbanksysteme abdecken zu können. Sind deshalb alle zusätzlichen, über den Standard hinausgehenden Eigenschaften der jeweiligen Datenbanksysteme für den Entwickler nicht nutzbar?

Bei der Entwicklung mit 4GLs arbeitet der Entwickler auf dem logischen Datenbankmodell. Davon abhängig ist immer das physikalische Datenbankmodell. Die Unabhängigkeit zwischen logischem und physikalischem Datenbankmodell ist eine explizite Stärke relationaler Datenbanken. Dies bedeutet, daß alle Features eines RDBMS, die sich auf die physikalische Implementierung der Datenbank beziehen, immer genutzt werden können, auch wenn diese nicht ANSI-konform sind. Als solche Features wären aus den oben aufgezählten Eigenschaften zu nennen:

- alle Zugriffsmethoden (Hash, Btree, Link, Direct, Sequential),

- Links zur Unterstützung der physikalisch abgebildeten Referential Integrity,

- Remote Database Access (RDA),

- Verteilungskonzepte,

- Clustering,

- Aufteilung der Datenbank auf verschiedene Volumes (zum Beispiel Platten).

Nicht genutzt werden können jedoch solche Features, die sich direkt auf das logische Datenbankmodell beziehen, zum Beispiel:

- stored procedures,

- objektorientierte Erweiterungen,

- eigene Data Integrity Systeme.

Beispiele für Entwicklungsumgebungen der 4. Generation, die auf verschiedenen RDBMS verfügbar sind, sind UNIFACE (verfügbar auf Oracle und Sybase) von Uniface BV sowie ACCELL/SQL (Informix, Oracle, Sybase, Unify2000) von Unify.

Anwender vertrauen auf Standards - eine allseits bekannte Tatsache. Fehlendes Know-how des Anwenders und Vertrauen auf Standards sind die Gründe, warum es sich aus Sicht der RDBMS-Anbieter bei SQL nicht nur um eine technische Schnittstelle, sondern auch um ein Marketing-Schlagwort handelt.

Deshalb darf bei einer Betrachtung von SQL der vertriebliche Aspekt nicht unberücksichtigt bleiben, da dieser nicht nur Auswirkungen auf die Entwicklung, sondern auch Einfluß auf so wichtige Punkte wie den technischen Support für das RDBMS hat. Unter vertrieblichen Aspekten wird in der Regel nicht nur über SQL, sondern allgemeiner über das jeweilige RDBMS gesprochen.

Schließlich ist jede SQL-Implementierung eines Datenbank-Anbieters fest mit dem jeweiligen Datenbank-Kern verbunden. Deshalb kann die SQL auch nicht als Stand-alone-Schnittstelle, sondern nur in Verbindung mit dem RDBMS gekauft werden. Nicht vergessen werden sollte in diesem Zusammenhang auch der Markt der schon oben erwähnten 4GLs, in dem heute nicht nur jeder RDBMS-Anbieter sein eigenes 4GL-Produkt anbietet, sondern in dem bereits die ersten Datenbank-unabhängigen Produkte (Uniface, Accell/SQL, siehe oben) verfügbar sind.

Im deutschen Markt sind dabei im wesentlichen zwei unterschiedliche Vertriebsansätze zu beobachten. Der erste Ansatz ist der indirekte Vertrieb über Hardwarehersteller, Distributoren beziehungsweise Händler, wobei das Produkt ähnlich wie Unix als "commodity product" verkauft wird. Neueste Studien über relationale Datenbanken wie zum Beispiel die Butler-Bloor-Studie aus England sagen voraus, daß am SQL-Standard orientierte Datenbanken in Zukunft als reine "commodity products" über die Händler-Vertriebsschiene verkauft werden, ja sogar in nichtall zu ferner Zukunft in PROMÆs "gegossen" direkt mit der Hardware mitgeliefert werden.

Voraussetzung für diese Art des Vertriebs ist die absolute Orientierung an Standards, einfache und leicht erlernbare Bedienbarkeit (zum Beispiel menügeführt), sowie einfacher Support, da dieser vom Distributor beziehungsweise Händler erbracht werden muß, der in der Regel über weniger gut ausgebildetes Personal verfügt wie der Hersteller selbst.

Beim zweiten Ansatz handelt es sich um den Direktvertrieb, bei dem die Produkte direkt von der Niederlassung verkauft und supportet werden. Dies ist vonnöten, wenn die Produkte über den Standard hinausgehende Erweiterungen beinhalten (siehe oben), beziehungsweise im Falle von 4GLs auf Fremd-Datenbanken aufsetzen. Diese Produkte sind in der Regel beim Vertrieb erklärungs- und präsentationsbedürftig und benötigen gerade im Zusammenspiel mit Fremdprodukten eine gut ausgebildete Support-Mannschaft beim Hersteller.

Beispiele für diesen Vertriebsansatz sind Ingres, Oracle (vertreibt auch über die indirekte Schiene), Sybase und Unify.

Jede Datenbank muß mit jeder anderen Datenbank in jeder Umgebung uneingeschränkt mit über den heutigen Standard hinausgehenden Eigenschaften kommunizieren können - dies ist der Weg, den relationale Datenbanken und damit auch SQL gehen werden.

Parallelen zur Entwicklung von Unix sind durchaus angebracht. Kriterien, die heute den Erfolg von Unix bestimmen (X/Open-Kompatibilität, Mehrsprachigkeit, Performance, grafische Oberflächen, Menüshell, Kommunikation mit anderen Betriebssystemen, Verfügbarkeit von Fremdsoftware, Applikationen) werden auch den Erfolg eines RDBMS bestimmen (ANSI-SQL Kompatibilität, Mehrsprachigkeit, Performance, 4GLs, Kommunikation mit anderen RDBMS, Verfügbarkeit, Applikationen).

Auch der rasch wachsende 4GL-Markt mit seinen Vorteilen trägt hierzu wesentlich bei. Gerade weil sich neben dem SQL-Standard die 4GLs immer weiterentwickeln, muß der Anwender darauf setzen, denn - in einer anspruchsvollen Anwendung kommt er heute um eine relationale Datenbank nicht mehr herum.

Veit Irtenkauf ist Support Manager bei der Unify GmbH, Baldham

Die wichtigsten Erweiterungen des ANSI/SQL 2 Vorschlags gegenüber dem ANSI/SQL 1 Standard:

- Dynamic SQL - Aufbau von variablen SQL-Statements;

- Updateable Views - Update, Delete, Insert auch auf Views;

- Grant with grant - Berechtigungen können weitergereicht werden;

- Cascaded Deletes - Löschen von Vater-Sätzen zugleich mit allen über die Referential Integrity zugeordneten, hierarchischen Sohn-Sätzen;

- Check Option - Aufbau eigener Datenintegritäts-Regeln beim Erzeugen der Tabelle;

- Neue Datentypen (Numeric, Real, Double precision);

- Erweiterter Select - Outer reference, Distinct functions, all,

- Erweiterte Cursor-Funktionen - Declare, Delete current, Update current.