SQL: Hersteller ziehen noch nicht mit

Umfang und Leistung eines vieldiskutierten Standards
von Heinz Axel Pürner, Unternehmensberatung Pürner in Dortmund

aus COMPUTERWOCHE Nr. 38 vom 16.09.1988

An Vorschlägen zur Verbesserung des bestehenden SQL-Standards mangelt es nicht. Doch bislang scheitern alle Bemühungen an den Herstellern, die lieber ihre eigenen Erweiterungen stricken. Das ist einer der Gründe, warum der Standard noch lange kein Anlaß für Anwender-Euphorie sein kann.

Im Standard ist nicht explizit festgelegt wie Sichten (Views) zu implementieren sind. Dennoch unterliegen die Views Restriktionen, die sich nur dadurch erklären lassen, daß auf die Basistabellen scheinbar eine Operation ausgeführt wird, die durch die Zusammenfassung des Select-Ausdrucks in der View-Definition mit dem gerade abgesetzten Befehl entsteht. Dies entspricht der heute üblichen Implementierung von Sichten in relationalen Datenbanksystemen. Dies kann aber einem Benutzer, dem seine Sichten vorgegeben wurden und der sie nicht kennt, auch unangenehme Überraschungen bereiten.

Die Auswahl kann zu einem Fehler führen, wenn die aktuelle Sicht bereits Funktionen wie Summenbildung über Spalten enthält, und diese zum Beispiel in der Auswahlbedingung benutzt werden. Die Sicht wird so interpretiert, als laute die Auswahl auf die Basistabelle, so daß Funktionen als Operanden in einer Suchbedingung auftreten, was verboten ist. Chris Date kommentiert dazu in seinem Buch über den SQL-Standard: "The whole area of views (the retrieval aspect in particular) is one of the ugliest parts of the SQL language." Vom Standard kann man allerdings hier auch keine Bereinigung erwarten, er wäre zu diesem Zeitpunkt überfordert!

Im Standard nur fünf Funktionen definiert

Im Standard sind nur fünf Funktionen definiert: COUNT0, SUM0 AVG0, MAX0, MIN0. Für die Funktion COUNT0 ist die Angabe DISTINCT vorgeschrieben, die Form COUNT(*) zur Zählung der Zeilen ist eine Spezialform. Unter den Vergleichoperatoren fällt nur < > für "ungleich" auf, die anderen haben die gewohnten Symbole.

Für den Vergleich von Zeichenketten wurde der Operator [NOT] LIKE definiert. Als transparente Zeichen wurden "%" für eine Folge von Zeichen und "-" für ein einzelnes Zeichen festgelegt. Es stellt sich hier die Frage, ob es nicht sinnvoll gewesen wäre, die weit verbreiteten Symbole "*" und "?" auch in SQL zu übernehmen. Mit Hilfe des neuen Schlüsselwort ESCAPE kann ein Zeichen vom Benutzer vorgegeben werden, das die Interpretation der transparenten Zeichen aussetzt, zum Beispiel bedeutet LIKE '/-%' ESCAPE '/', daß der gesuchte String mit einem Unterstrich beginnen soll.

Der Operator [NOT] IN vergleicht gegen eine vorzugebende Menge. Diese kann als Aufzählung oder als Unterabfrage (Subquery) angegeben werden. In Verbindung mit einer Unterabfrage ist IN äquivalent zu = ANY. Die wichtigste Gruppe der Mengenoperatoren ist die der Vergleiche. Sie haben die Form Vergleichsoperator und eines der Schlüsselwörter ANY, SOME, ALL. Zum Beispiel bedeutet ALL, daß zur Erfüllung des Vergleichs der Vergleichsoperand größer als alle Werte in der Vergleichsmenge sein muß. ANY und SOME sind völlig gleichwertig und besagen, daß mindestens irgendein Wert der Menge die Vergleichsbedingung erfüllen muß.

EXISTS und NOT EXISTS sind logische Mengenoperatoren, sie nehmen den Wert "wahr" (TRUE) an, wenn der Mengenoperand leer beziehungsweise nicht leer ist. Eine Unterabfrage als Mengenoperand ist also so zu formulieren, daß ihr Ergebnis eine leere oder nicht leere Menge ist.

Mathematisch-theoretisch ausgerichtete Leute wie Chris Date vertreten die Ansicht, diese Mengenoperatoren seien völlig überflüssig, da sich alle Vergleiche auch in EXISTS-Vergleiche umsetzen ließen. Die tägliche Praxis und die Erfahrungen aus unserem SQL-Training haben jedoch gezeigt, daß in der Mengenlehre nicht vorgebildete SQL-Anwender gerade mit EXISTS ihre Probleme haben und mit den anderen Vergleichsoperatoren besser zurechtkommen.

Der Standard definiert zwei Sprachebenen (Level). Level 2 ist der gesamte Sprachumfang, Level 1 eine Untermenge. Der Level 1 wurde eingeführt, um zu existierenden Produkten den kleinsten gemeinsamen Nenner zu finden. Folgende Funktionen fehlen in Level 1: Die Systemvariable USER, Unterabfragen mit Bezug zur Hauptabfrage (Correlated Subqueries), der Vergleichsoperator, NOT LIKE sowie die ESCAPE-Angabe in LIKE beziehungsweise NOT LIKE, die Mengenoperatoren EXISTS und UNION, das SCHEMA sowie die Funktion UNIQUE auf Basistabellen - es ist freigestellt, wie eine solche Beschränkung implementiert wird, zum Beispiel mit CREATE INDEX -; darüber hinaus sind nicht integriert die CHECK-Option bei Sichten (Views), die Datentypen REAL, DOUBLE PRECISION und NUMERIC, INSERT...SELECT, UPDATE...WHERE CURRENT, DELETE...WHERE CURRENT und weitere Funktionen.

Es ist den Herstellern freigestellt, ihr SQL über den Standard hinaus um individuelle Leistungen zu erweitern. Leider wird häufig nicht angegeben, welche der beiden Ebenen unterstützt wird. Der Anwender sollte aber auf einer eindeutigen Aussage bestehen, denn die Unterschiede sind durchaus beachtlich, wie wir gesehen haben.

Verbesserungen bei der Datenintegrität

Von großer Bedeutung sind die vorgeschlagenen Erweiterungen zu SQL (Database Language SQL Addendum-2 (working draft), X3H2-86-61). Sie beinhalten wesentliche Verbesserungen von SQL hinsichtlich der Datenintegrität: Mit dem Schlüsselwort DEFAULT sollen Standardwerte in der Tabellendefinition (CREATE TABLE) vorgegeben werden können. Spalten, die bei der Erfassung neuer Zeilen nicht explizit angegeben wurden, müssen damit nicht mehr nur den Wert NULL annehmen. Automatische Plausibilitätsprüfungen sollen in Zukunft bereits mit dem Parameter CHECK bei der Tabellendefinition vorgegeben werden können.

Primärschlüssel, wie sie das relationale Modell zwingend vorschreibt, sind heute in SQL unbekannt. In Zukunft sollen Primärschlüssel zu Tabellen definiert werden können. Sie sind per definitionem eindeutig (UNIQUE). Auch sollen in SQL zukünftig Fremdschlüssel unterstützt werden. Sie geben die Beziehung von Tabellen untereinander wider und beinhalten die Primärschlüsselwerte einer anderen Tabelle.

Ein großer Mangel heutiger relationaler Datenbanksysteme ist es, daß die referentielle Integrität ausschließlich durch die eigene Software des Anwenders sichergestellt werden muß. Zum Beispiel muß durch Anwendungsprogramme erzwungen werden, daß nicht in einer Tabelle Fremdschlüsselwerte existieren, die es als Primärschlüssel nicht gibt. Es muß daher bei der Erfassung und Änderung von Daten für Fremdschlüssel jeweils geprüft werden, ob deren Werte schon als Primärschlüssel existieren.

Bei Änderungen eines Primärschlüsselwertes sind die zugehörigen Fremdschlüssel immer mit zu ändern. Bei Löschungen ist zu prüfen, ob zugehörige Fremdschlüssel noch vorhanden sind; je nach Inhalt der Beziehung ist auf eine Löschung zu verzichten, sind die Zeilen mit dem Fremdschlüssel ebenfalls zu löschen oder nur der Fremdschlüsselwert auf NULL zu setzen.

Systemfunktionen decken die Eigenprogrammierung ab

Diese Eigenprogrammierung, die in Datenbanksystemen nach einem anderen Modell größtenteils durch Systemfunktionen abgedeckt wird, soll nach den Erweiterungsvorschlägen in Zukunft entfallen können.

Die vorgesehenen Fremdschlüssel-Definitionen im CREATE TABLE enthalten auch die Angaben für Regeln bei Lösch- und Änderungsoperationen: RESTRICT unterbindet die Operation auf die Tabelle mit dem Primärschlüssel, CASCADE führt sie auf der Tabelle mit dem Fremdschlüssel nach, und SET setzt die betroffenen Fremdschlüsselwerte auf NULL oder den DEFAULT-Wert.

IBM hat kürzlich die Implementierung dieser Vorschläge für die nächste Version von DB2 und SQL/DS angekündigt. Weitere Vorschläge zur Ergänzung von SQL beziehen sich auf Datenmanipulationen: Die Vereinigung von Mengen (UNION) soll erlaubt werden in Sichten, Unterabfragen sowie in INSERT...SELECT- und FROM-Angaben. Sie bleibt aber weiter verboten im SELECT-Befehl, da dieser ja als einzelsatzorientiert aufgefaßt wird.

In der zeigergestützten Verarbeitung ist es zur Zeit nur erlaubt, daß sich der CURSOR jeweils auf die nächste Zeile positioniert. Mit einem SCROLL CURSOR soll es in Zukunft möglich sein, die Positionierung mit den Schlüsselwörtern NEXT, PRIOR, FIRST, LAST, ABSOLUT n und RELATIVE n frei zu wählen.

Die sehr wichtigen Vorschläge zur Erweiterung des Standards werden übrigens heute noch von keinem Hersteller unterstützt!

Es konnte hier nur ein kurzer Überblick über den SQL-Standard gegeben werden. Es gibt noch eine Reihe von Feinheiten, auf die beim Vergleich zwischen existierenden Produkten und dem Standard auch geachtet werden muß.

Die Norm kann die Portabilität von Programmen gewährleisten und so die Investitionen von Softwarehäusern und Anwendern in ihre SQL-gestützten Lösungen sichern. Wer im Zuge von Systemumstellungen die Vorteile der alten Norm-Vorschläge der CODASYL Data Base Task Group kennengelernt hat, weiß, wie hoch eine Standardisierung einzuschätzen ist! Daß überflüssige Restriktionen aus den bestehenden Produkten übernommen wurden, sollte die Leistung des Standardisierungskommittees nicht schmälern.

Dennoch besteht kein Anlaß zur Euphorie. Der Level 1 des Standards ist eine schmale Basis für portable Programme, und seine Unterstützung darf nur als Übergangslösung gesehen werden. Die Anwender sollten gezielt nach dem Level 2 fragen und Druck auf die Hersteller ausüben, die sonst vielleicht dazu neigen werden, sich auf der untersten Ebene schon auszuruhen.

Unser Ziel kann letztlich nur sein, den Level 2 und die Erweiterungsvorschläge zu erhalten. Erst die verbesserten, einheitlichen Datendefinitionen machen den Standard rund. Genügend Freiraum für die Hersteller zur individuellen und optimalen Gestaltung ihrer Produkte bleibt dann ebenso wie für das Kommittee zur Erweiterung und Verbesserung des Standards.