Melden Sie sich hier an, um auf Kommentare und die Whitepaper-Datenbank zugreifen zu können.

Kein Log-In? Dann jetzt kostenlos registrieren.

Falls Sie Ihr Passwort vergessen haben, können Sie es hier per E-Mail anfordern.

Der Zugang zur Reseller Only!-Community ist registrierten Fachhändlern, Systemhäusern und Dienstleistern vorbehalten.

Registrieren Sie sich hier, um Zugang zu diesem Bereich zu beantragen. Die Freigabe Ihres Zugangs erfolgt nach Prüfung Ihrer Anmeldung durch die Redaktion.

21.08.1992 - 

Eine mögliche Lösung bietet die sogenannte Inhouse-Norm

Das Prädikat des Standards hat SQL nur zum Teil verdient

*Andreas Wehringer ist im Beratungszentrum der Rainer Fein Gesellschaft für Informationssysteme mbH in München tätig, wo er sich mit der Planung und Analyse von Datenbankanwendungen sowie mit Studien zu relationalen Datenbanksystemen beschäftigt.

Die Abfragesprache SQL gilt in der relationalen Datenbankwelt als Industriestandard. Dennoch kann, so Andreas Wehringer*, eine Applikation nicht ohne weiteres von einem Datenbanksystem auf ein anderes portiert werden. Die Gründe sind vielfältig, das Ergebnis immer gleich: Hat der Anwender sich einmal für ein Datenbanksystem entschieden, so ist ein Wechsel nur mit großem Aufwand möglich.

Lassen Sie uns einen Augenblick lang folgendes Szenario erträumen: SQL ist der Standard; wenn wir uns an diesen Standard halten und keine der herstellerspezifischen Erweiterungen verwenden so laufen unsere Applikationen mit jedem relationalen Datenbanksystem. Zu diesem Zweck müssen die Programme lediglich in C (ebenfalls ein Standard) mit eingebundenen SQL-Befehlen geschrieben werden.

Je nach Benutzeranzahl und Mengengerüst wird die Anwendung wahlweise unter MVS mit DB2 unter Unix mit Informix unter OS/2 mit SQL-Server oder im DOS-Netzwerk mit Oracle installiert. Und in jeder dieser Umgebungen ist unsere Anwendung unverändert lauffähig - schließlich halten sich ja alle Datenbankhersteller an den SQL Standard.

Wegen der großen Flexibilität verzichten wir dann gern auf die Erweiterungen, die jeder Hersteller in seine Datenbank aufgenommen hat. In unserem Traum können wir uns über gesunkene Wartungskosten freuen, weil wir weniger Datenbankspezialisten brauchen. Außerdem betreiben wir je nach Belieben ein Up- oder Downscaling, und wir verfügen über einheitliche Benutzerschnittstellen.

Nicht völlig deckungsgleich

Nicht zuletzt nehmen wir eine gestärkte Verhandlungsposition gegenüber den Datenbankherstellern ein. Erstmals sitzen wir nicht mehr am kürzeren Hebel, wenn wir weitere Lizenzen benötigen. Im Klartext: Falls unser "Hauslieferant" uns mit seinem Datenbankprodukt kein günstiges Angebot macht sind wir so frei, zum Konkurrenten zu wechseln .

Leider wird dieser Traum nicht in Erfüllung gehen. Die beiden existierenden Standards (ISO/IEC und X/Open) sind nämlich nicht völlig deckungsgleich und enthalten außerdem Lücken, die von jedem Anbieter auf eine andere Weise geschlossen werden. So fehlt etwa in einem der beiden Standards der Befehl DROP TABLE. Bezüglich essentieller Bereiche wie etwa Table Locking und Record Locking hüllen sich beide Normungsgremien in Schweigen.

Der als Entwurf verabschiedete ISO/IEC-Standard SQL2 geht über die bestehende Normierung weit hinaus - allein die Anzahl der Druckseiten ist auf ein Mehrfaches gestiegen. Aber es dürfte noch lange dauern, bis er tatsächlich in Form verfügbarer Datenbanksysteme umgesetzt ist. Problematisch ist vor allem, daß bei den bestehenden Normen jene Bereiche am wenigsten standardisiert sind, in denen die getätigten Investitionen am höchsten sind (siehe Tabelle).

Es gibt derzeit nur eine Moglichkeit, die gewünschte Unabhängigkeit zu erreichen: Der Anwender selbst muß einen Standard definieren, der eine Durchschnittsmenge der ins Auge gefaßten Datenbanksysteme enthält. In einem Programm, das nach diesem Standard erstellt wird, dürfen demnach nur SQL-Befehle oder Klauseln verwendet werden, die in jedem der Datenbanksysteme enthalten sind.

Der Weg zu einem solchen Standard ist lang und beschwerlich - insbesondere, wenn man berücksichtigt, daß von jedem Datenbanksystem mindestens - einmal im Jahr ein neues Release mit größeren funktionalen Erweiterungen freigegeben wird. Um den selbstdefinierten Standard aktuell zu halten, muß er also mehrmals jährlich überarbeitet werden.

Damit er sinnvoll angewandt werden kann, hat ein solcher Standard drei Voraussetzungen

zu erfüllen: Zum einen ist eine formale Beschreibung, beispielsweise in Backus-Naur-Form, notwendig. Zum anderen benötigt der Software-Entwickler lesbare und handliche Unterlagen. Beliebt sind hier die von allen Datenbankherstellern als Ergänzung zum Handbuch angebotenen "Quick-Reference-Guides", in denen alle verfügbaren Befehle mit Syntax und Optionen übersichtlich verzeichnet sind. Ein solcher Guide kann aus der formalen Beschreibung durch Verdichtung abgeleitet und optisch aufbereitet werden.

Darüber hinaus müssen die erstellten Programme validiert werden, um späteren Überraschungen vorzubeugen. Der Parser, der die Validierung durchführt, sollte möglichst automatisch aus dem formalen

Sandard generiert werden, um einerseits die Fehlerquellen einzuschränken und andererseits rasch und

einfach auf neue Releases des Standards reagieren zu können.

Mit diesen Voraussetzungen im Hinterkopf kann der Anwender darangehen, einen Inhouse-Standard für die in seinem Unternehmen eingesetzten DB-Systeme zu schaffen. Kernstück dieser Norm ist eine Datenbank, in die alle real existierenden SQL-Dialekte und die berücksichtigten SQL-Normen in formaler Notation eingebracht werden. Aus dieser Datenbank läßt sich dann eine formale Standardbeschreibung in Backus-Naur-Form gewinnen.

Der Standard kann nach den Anforderungen des Anwenders maßgeschneidert werden, also beispielsweise nur zwei SQL-Dialekte in bestimmten Release-Ständen umfassen, oder aber die Durchschnittsmenge aus einer großen Anzahl verschiedener SQL-Versionen abbilden. Im letzten Fall wird der gewonnene Standard selbstverständlich weniger Befehle umfassen als im ersten Fall, da nur jene Teilbereiche eines SQL-Dialekts im Standard enthalten sein können, die auch in allen anderen Dialekten enthalten sind.

Weiterhin lassen sich aus der Datenbank der hauseigene Quick-Reference-Guide sowie ein Validierungsprogramm generieren, das die Applikationen auf Einhaltung des soeben definierten Standards prüft. Um Anwendungsprogramme in verschiedenen Programmiersprachen validieren zu können, muß dieser Syntax-Checker um einen Preprozessor für die jeweilige Programmiersprache ergänzt werden, der aus den Anwendungsprogrammen die puren SQL-Befehle extrahiert. Diese werden dann vom Parser syntaktisch auf Konformität mit dem SQL-Standard geprüft.

Wir haben diese Möglichkeit bereits in der Praxis durchgespielt - und zwar für drei verschiedene relationale Datenbanksysteme unter Unix. Zentrale Funktionen übernahmen dabei die Hilfsmittel des Unix-Werkzeugkastens, insbesondere Lex und Yacc.

Eines der schwierigsten und zeitaufwendigsten Probleme bestand darin, die Handbücher der einzelnen Datenbanksysteme in eine formale Darstellung zu übersetzen. Die Genauigkeit dieser Darstellung war in den meisten Fällen gerade noch ausreichend, im Einzelfall traten Lücken und gelegentlich auch Widersprüche auf.

Wiederholte Konsolidierungssitzungen im Team waren notwendig, um eine heimtückische Fehlerquelle auszuschalten: Manchmal ließen sich in verschiedenen Datenbanksystemen syntaktisch gleiche Konstrukte feststellen, die jedoch eine unterschiedliche Semantik aufwiesen. Verglichen mit dem

vorangegangenen Arbeitsaufwand war das Erstellen der Generatoren relativ rasch erledigt.

Die abschließende, letztendlich jedoch entscheidende Frage, ob sich der Aufwand gelohnt hat und der gewonnene Standard einsetzbar ist, muß differenziert betrachtet werden: Die wichtigste Erkenntnis war die, daß Programme unabhängig vom zugrunde liegenden Datenbanksystem erstellt werden können, wenn bestimmte Einschränkungen beachtet werden.

Selbstverständlich muß auf alle herstellerspezifischen Erweiterungen verzichtet werden.

Die machen nun aber oft gerade den Charme eines Datenbanksystems aus - man denke etwa an die Oracle-eigene Funktion zur Stücklisten-Auflösung: SELECT ... CONNECT BY mit dem verbleibenden Rest läßt es sich jedoch durchaus leben.

Beschreibung der Semantik

Ein Problem stellen allerdings die Unterschiede im Kern des Datenbanksystems dar, die sich nicht in der Syntax der Befehle wiederspiegeln. Beispiels weise differiert die für Mehrbenutzersysteme unerläßliche Funktion der LOCK-Befehle von Datenbunksystem zu Datenbanksystem ein wenig.

Um diese Unterschiede aus zugleichen, muß der SQL-Standard, der sich in der bisherigen Betrachtung nur auf syntaktische Merkmale stützt, durch Beschreibungen der Semantik ergänzt werden. Das geht am besten mit begleitenden Programmierrichtlinien, bestehend aus einer textuellen Beschreibung und aus Funktionsbibliotheken. Eine Funktionsbibliothek enthält für jedes Datenbanksystem eine fertige Lösung bestimmter Basisdienste, die von Anwendungsprogramm aufgerufen werden. Die Funktionen müssen so definiert sein, daß sie von jedem Datenbanksystem in gleicher Weise erfüllt werden können.

Im Bereich der Data-Definition-Language (CREATE TABLE, CREATE INDEX etc.) sind

für alle Datenbanksysteme Parameter anzugeben, die die Performance oder Speicherverwaltung entscheidend beeinflussen. Diese Parameter sind in keiner Norm berücksichtigt, denn sie werden sehr stark von der inneren Architektur der Datenbank bestimmt. Ohne diese Parameter läßt sich jedoch keines der Datenbanksysteme sinnvoll betreiben, wodurch in diesem Bereich eine starre Bindung an das Datenbanksystem festgeschrieben wird.

Glücklicherweise treten diese Befehle oft nur in den Installationsroutinen der Applikation auf. Die Installationsroutinen müssen dann eben - und das ist auch aus anderen Gründen unerläßlich - für jedes Datenbanksystem angepaßt werden. Das ist jedoch ein durchaus vertretbarer Aufwand, wenn die gesamte übrige Anwendung unverändert eingesetzt werden kann.