Die "Structured Query Language" (SQL) ist aus der Welt moderner Datenbank-Management-Systeme kaum noch wegzudenken: immerhin wurde sie bereits durch das American National Standards Institute (Ansi) standardisiert. Allerdings weist SQL auch einige Schwächen auf. Günter Tolkmit* setzt sich damit auseinander.

SQL war mit dem Anspruch angetreten, dem Endbenutzer auf natürliche Weise die Suche in Datenbanken zu ermöglichen. Es zeigt sich jedoch daß die Sprachkonstrukte nicht als natürliche Anfragesprache bezeichnet werden können. Viele SQL-Statements werden schnell zu komplex und Abfragen, die sich auf rekursive Datenstrukturen beziehen, können gar nicht gestellt werden. Das entscheidende Problem ist dabei nicht SQL selbst, sondern das zugrundeliegende relationale Datenmodell.

Gehen wir einmal von einem stark vereinfachten Linienplan einer Fluggesellschaft aus, der sämtliche Streckenverbindungen zwischen den einzelnen Städten enthält. Wollte ein Endbenutzer nun wissen, welche Städte von Frankfurt aus erreicht werden können, dann wäre diese Anfrage mit SQL nicht nur schwer zu formulieren, vielmehr ist sie überhaupt nicht formulierbar, denn SQL unterstützt in keiner Weise rekursive Datenstrukturen. (Die Stadt hat eine Verbindung zu der, die wiederum zu der etc.) Damit können wichtige Aufgaben wie die Stücklistenverarbeitung nicht oder zumindest nur sehr schwer gelöst werden.

Ein Sprachkonstrukt wie

FIND city

REFERENCED RECURSIVELY VIA flight-connected-to

BY city = "Frankfurt"

könnte genau diese rekursive Datenstruktur abbilden. In SQL bedeutet das jedoch, ad infinitum SELECTED-Statements zu schachteln, da zumindest die maximale Suchtiefe im voraus bekannt sein müßte .

Dennoch hat sich SQL als Standard durchgesetzt. Wie kommt's? Liegt das allein an der in Aussicht gestellten Protabilität der Anwendungen?

Bei der Betrachtung von SQL wird man zuerst einmal zugestehen, daß diese Datensubsprache entscheidende Fortschritte gebracht hat. Mit SQL wurde eine mengenorientierte Schnittstelle geboten, die die Beschränkung früherer Abfragesprachen, die nur einen Satz pro Datenbank-Zugriff verarbeiten konnten, aufhob; allerdings entfällt dieser Vorteil, wenn SQL in eine Sprache der dritten Generation eingebettet wird.

Zudem ist SQL eine deskriptive Sprache, der Programmierer gibt also nur noch an, welche Informationen er will, aber nicht, wie auf die Daten zugegriffen werden soll. Damit ist zudem die völlige physische Datenunabhängigkeit gegeben, so daß physische Datenbank-Reorganisationen (zum Beispiel ein neuer Index) vorgenommen werden können, ohne daß Anwenderprogramme angepaßt werden müssen. Außerdem gibt es eine einheitliche Sprachsyntax für Datendefinitions- und Datenmanipulationsbestandteile der Sprache.

Das alles ist möglich, weil SQL auf einem mathematischen Modell, der Relationenalgebra, basiert und somit eine klar definierte Sprache ist. Doch die Vorteile sind teuer erkauft. Die reale Welt, die wir natürlichsprachlich dadurch beschreiben, daß wir von Objekten und ihren Beziehungen untereinander sprechen, wird im Verlauf der Normalisierung in eine Vielzahl von flachen, zweidimensionalen Tabellen zerschlagen. Also muß der Anwendungsprogrammierer selbst wieder für die Herstellung der Beziehungen sorgen, die eben nicht explizit im System selbst vorliegen.

So wird die Eindeutigkeit durch künstliche Attribute, die Primärschlüssel nämlich, erzwungen und auch die Beziehungen werden künstlich, über Fremdschlüssel (foreign keys), simuliert. Problematisch hieran ist allein schon die Wartung, denn da kein globales RENAME möglich ist, müssen Primärschlüssel und ihr redundantes Vorkommen als foreign key in anderen Relationen vom Anwendungsprogrammierer per Hand nachgeändert werden.

Was schiefgehen kann, das geht auch einmal schief. Eine Abfrage wie SELECT * FROM city, flight-connection WHERE cnr <= flugdauer ist unsinnig. Was soll denn dabei (citynummer < = flugdauer) herauskommen? Dennoch sind solche Fehler, sei es aus Flüchtigkeit oder aufgrund der semantischen Unklarheit der Feldnamen, nicht selten. Man müßte eigentlich erwarten können, daß das System so eine Frage zurückweist. Das ist jedoch nicht der Fall, da das System die Semantik nicht kennt.

Relationale Theoretiker wollen solche Probleme durch ein "Domain"-Konzept lösen. Doch dies beseitigt die Probleme nicht grundsätzlich. Denn: Was, wenn mehrere Beziehungen zwischen Domains bestehen? Als Beispiel sei die Beziehung "Kunde-Auftrag" genannt, bei der drei Beziehungen auftauchen können: "bestellt", "bezahlt" und "hat noch nicht bezahlt".

Ein Fortschritt hin zu echten Dialog- und Abfragesprachen kann nur dadurch erreicht werden, daß möglichst viele Strukturinformationen, die wir bei der Modellierung gewinnen, auch in der Datenbank abgebildet werden können. Und dann sollte es möglich sein, mit einer entsprechenden Abfragesprache - die natürlich weit über den Sprachumfang von SQL hinausgehen muß - darauf zuzugreifen.

Nun wird interessanterweise während der Datenbankdesignphase bereits seit Jahren mit dem Entity-Relationship-Modell gearbeitet. Auf natürliche Weise stellt diese Methode die Entitäten und die zwischen ihnen bestehenden Beziehungen dar. Bei der Implementierung kam es jedoch bisher zu einem schweren semantischen Verlust. Denn ob im hierarchischen, netzwerkorientierten oder relationalen Modell - , die Beziehungen sind nicht mehr explizit.

Wenn wir also über Dialog- und Abfragesprachen reden, reicht es nicht, zu diskutieren, ob SQL nun eine geeignete Sprache ist. Vielmehr muß auf der Datenbankebene die Voraussetzung geschaffen werden, damit mit einer entsprechend gut ausgerüsteten Sprache dann auch gefragt werden kann.

Nur wäre selbst das noch keine geeignete Endbenutzersprache. Auch hier kann ja wie bei SQL eine Komplexität erreicht werden, die dem Endbenutzer nicht mehr zumutbar ist. Ein verhältnismäßig einfaches Statement wie

FIND city REFERENCED VIA flightconnected-to BY city REFERENCING VIA situated-in continent = "europe" (also: Finde alle Städte, die von einer europäischen Stadt aus direkt erreicht werden können)

zeigt bereits, daß solche Sprachkonstrukte für den Endbenutzer nicht besonders komfortabel und einfach zu handhaben sind. Einfach zu bedienende Abfragesprachen, wird man daher wohl nur über objektorientierte, grafische und vollständig interaktiv arbeitende Front-ends bekommen. Der Benutzer wird mit der Maus nur noch Icons anticken, das System stellt ihm Fragen zur genaueren Spezifierung etcetera. Nur wenn die Datenbanktechnologie und die Benutzeroberfläche dem natürlichen Denken des Benutzers in dieser Weise entgegenkommen, kann von Dialog- und Abfragesprache die Rede sein.