Die Avantgarde ist natürlich schon weiter. Doch überholt oder nicht - Relational ist zum Datenbankstandard und SQL zur zugehörigen Universalsprache geworden. Nach der relationalen Theorie im ersten Teil nun etwas Praxis.

Was bedeutet es, daß ein Datenbank-Managementsystem (DBMS) dem relationalen Modell genügt? Ganz einfach: Alle Daten präsentieren sich dem Benutzer als Werte in Tabellen. Die Data Definition Language (DDL) erlaubt die Definition von Relationen, so daß bei deren Manipulation die Integritätsregeln eingehalten werden. Die Data Manipulation Language (DML) erlaubt den Einsatz der relationalen Algebra.

Es gibt einige Sprachen, die diesen Anforderungen mehr oder weniger entsprechen. Die bekannteste und am weitesten Verbreitete ist SQL (Structured Query Language). SQL beinhaltet neben DDL und DML, auch noch eine Data Control Language (DCL), die aber im Prinzip nichts mit der Relationalität zu tun hat. Mit ihr werden die Zugriffsrechte von Benutzern oder Benutzergruppen bezüglich bestimmte Daten definiert. (Durch GRANT wird einem Benutzer für bestimmte Datenobjekte ein Subset der DDL und DML zugewiesen, durch REVOKE kann es ihm wieder entzogen werden.)

Um es vorweg zu sagen: SQL ist im Prinzip tatsächlich eine Implementierung des relationalen Modells, wobei es allerdings heiße Diskussionen darüber gibt, ob es nicht besser und vollständiger sein könnte. Diese Diskussion wäre hier fehl am Platz. Was aber hierher gehört, ist die Feststellung, daß es die SQL gar nicht gibt. Was es gibt, ist ein ANSI-Standard, an den sich die Hersteller in ihren diversen Dialekten halten. Im folgenden einige grundsätzliche Bemerkungen und Hinweise, worauf man bei einer SQL achten sollte. Aber Vorsicht: Die SQL-Schnittstelle - garantiert nicht, daß es sich um ein RDBMS handelt. Es gibt durchaus die Möglichkeit, ein konventionelles System um SQL zu erweitern. Dann werden die Daten weiter hierarchisch oder im CODASYL-Schema gespeichert, und das System hat einen enormen internen Übersetzungs-Overhead, meist funktionale Einschränkungen und ist im allgemeinen hochkomplex zu warten.

Datendefinition: DDL

Die Objektdefinition findet durch CREATE statt, und es werden damit zunächst einmal Basistabellen definiert. Wir hatten gesagt, daß in den Tabellen die Domains der Attribute nicht zum Ausdruck kommen. In der Tat wird das Domain-Konzept im allgemeinen nur rudimentär unterstützt, etwa indem man den Attributen, also den Spalten. Typen wie INTEGER, CHARACTER etc. zuordnen kann. Es läßt sich ein Primärschlüssel zur Tabelle festlegen, und bei Systemen, die nicht nur die Entitätsintegrität, sondern die referentielle Integrität unterstützen, auch ein Fremdschlüssel.

Mit CREATE kann man noch eine zweite Art von Objekten definieren: VIEWs. Hierbei handelt es sich um virtuelle Relationen, das heißt, die Tabellen, die sie repräsentieren, werden anders als Basistabellen - nicht gespeichert, sondern jeweils aktuell erstellt. Ihr Inhalt ist immer ein bestimmter Ausschnitt aus einer oder mehreren Basistabellen. VIEWs dienen dazu, Benutzern - seien es interaktive User oder Applikationen eine für sie konstruierte Sicht der Daten zu ermöglichen. Diese bleibt - in gewissem Rahmen - konstant, auch bei Veränderung der Basistabellen.

Im DDL-Bereich sieht es also gut aus mit der Realisierung des relationalen Modells.

Einzig merkwürdig ist, daß die meisten Systeme auch die Definition eines INDEX unterstützen. So etwas kommt im relationalen Modell nämlich ganz und gar nicht vor. Wir werden später sehen, was es damit auf sich hat und welche Bedeutung die Komponente mit dem schönen Namen "Optimizer" hat.

Datenmanipulation: DML

Die relationale Algebra hat es mit gegebenen Relationen zu tun. Diese können per Selektion und Projektion als Teilausschnitte betrachtet und mittels Union, Intersection, Differenz und Join kombiniert werden. Die einzelnen Werte, die in den Relationen vorkommen, bleiben dabei unverändert. Ebensowenig werden neue Werte in sie aufgenommen (betrachtet man die Vereinigungsmenge aller Tupel). Eine DML muß also von vornherein mehr bieten, als das relationale Model 1 vorschreibt. SQL enthält für Lesezugriffe den Befehl:

SELECT Attribute

FROM tabellen

WHERE bedingung.

Die Attributauswahl bei SELECT stellt eine Projektion P, die Bedingung im allgemeinen eine Selektion SL dar.

Da der Bedingungsausdruck sehr flexibel ist und bei FROM mehrere Tabellen angegeben werden können, lassen sich damit die relationalen Operationen weitgehend darstellen. Man erreicht sogar viel mehr, denn SELECT erlaubt Anordnungen der Tupel, Gruppenbildung und auch arithmetische Veränderungen der Werte.

Bei den Schreiboperationen (INSERT, UPDATE, DELETE) werden konkrete Werte in den Relationen geändert beziehungsweise Tupel eingefügt oder gelöscht. Das hat mit der relationalen Algebra eigentlich nichts mehr zu tun. Diese ist auf Relationen definiert, während die Schreiboperationen sich zunächst auf Tupel oder einzelne Werte richten. Chris Date hat einmal 19 Vorteile Von RDBMS gegenüber anderen also im wesentlichen hierarchischen oder Netzwerk-Datenbank-Management-Systemen, angeführt ("Why relational?", in: Selected Writings, Reading 1990).

Im Gegensatz zur Datenspeicherung im relationalen System enthielt der Aufsatz viel Redundanz - womit wir bereits beim ersten Vorteil wären.

Datenbankdesign

Anders als beim relationalen Modell handelt es sich bei einem Relationenmodell, nicht um ein Konzept für das DBMS, sondern um eines für die Datenbank selbst. Die in einem Unternehmen in, verschiedenen Geschäftsprozessen verwendet en Daten lassen sich sinnvoll als Relationen, deren Zusammenhang über Schlüssel darstellbar ist, modellieren. Werden bestimmte Regeln - die Normalformen - beachtet, erhält man eine (bis auf die Schlüssel) redundanzfreie Darstellung der Datenbasis. Diese ist in einem RDBMS unmittelbar implementierbar, sie kann - freilich modifiziert - auch in anderen Systemen realisiert werden.

Daß in der rauhen Praxis im allgemeinen kein von normalisiertes DB-Design verwirklicht wird, tut hier nichts zur Sache. Solch ein Konzept ist jedenfalls die Grundlage der Implementierung - auch und gerade dann, wenn aufgrund von Performance-Gesichtspunkten von ihm abgewichen wird. Dies soll möglichst kontrolliert geschehen und nicht nach dem Gusto der Systemspezialisten.

Data Independence

Das nun ist der eigentliche Witz an der ganzen Sache. Vergegenwärtigen wir uns einmal eine Datenstruktur aus der vorrelationalen Zeit, sagen wir einen Satz S (A, B, C), wobei die Teile A, B und C verschiedene Datentypen darstellen und von unterschiedlicher Länge sein sollen. Dieser Satz wird für eine ganz bestimmte Applikation A konstruiert. Speichert man ihn in dieser Form, beginnen bereits die Schwierigkeiten: Andere Anwendungen benötigen unter Umständen genau dieselben Datenelemente - aber in einer anderen Form!

Deshalb gibt es in großen Datenbasen häufig Redundanz, und zwar immer auch - wenigstens zum feil - unkontrollierte. So kann es dann schon einmal vorkommen, daß ein Brief an eine längst überholte Adresse geschickt und eine Überweisung auf ein nicht mehr existentes Konto getätigt wird.

In der Praxis wird außerdem die Speicherungsform, also etwa die Speicherungshierarchie, den Anforderungen eines Programms angepaßt. So kann man dann leicht - und vor allem schnell - über die Versicherungsnehmer kommen. Dafür aber gibt das System keine Auskunft darüber, welche Versicherungen ein und derselbe Versicherungsnehmer eigentlich hat. (Das ist kein Witz, sondern leidvolle Erfahrung.)

Dies ist natürlich keine prinzipielle Notwendigkeit. Auch in einem hierarchischen System wie IMS lassen sich verschiedene Sichten der Daten in sogenannten logischen Datenbanken festlegen. Aber die physische Speicherung entspricht immer nur einer Sicht, alle anderen Sichten müssen über Pointer zusammengesetzt werden, so daß ein - für die Anwendung - sequentielles Lesen physisch als eine Folge von IOs realisiert wird, von denen jeder auf ein anderes Segment zielt.

Die simple, aber gleichwohl geniale Idee, die dem relationalen Modell zugrunde liegt, besteht darin, die Speicherstruktur vollständig von der verarbeiteten Datenstruktur zu trennen. Genau das leistet ein RDBMS: Sämtliche Daten werden in einem, etwa SQL, kann sich jede Anwendung dann aus der korrekten Datenbasis ihre Datenstrukturell zusammensetzen. Eine Änderung der Applikation berührt die Datenbank dann nicht mehr, und umgekehrt betreffen Änderungen der Datenbank die Applikation nur unter gewissen Umständen.

Der Preis für diese Trennung ist, daß die gewünschte Datenstruktur durch ein geeignetes SELECT jeweils aktuell hergestellt werden muß. Die Leistung eines Programmierers, die Navigation in der hierarchischen Datenbank zu gestalten und damit Einfluß auf die Performance zu nehmen, übernimmt beim RDBMS das System.

Dem relationalen Modell ist das Antwortzeitverhalten gleichgültig. Eine Lösung für Performance-Probleme ergibt sich aus ihm nicht. Eher vergrößern die vielfältigen Möglichkeiten, die gleiche Frage in SQL zu stellen, diese Probleme noch. Führt das DBMS die Schritte eines SQL-Statements starr hintereinander aus, so hängt von einer mehr oder weniger geschickt formulierten Query die Antwortzeit in ganz fataler Weise ab.

Betrachten wir ein berühmtes Beispiel (siehe Chris Date: An Introduction to Database- Systems I", S. 457ff, Reading 1990. 5. Aufl.). Zugrunde liegen die Relationen L, weiche die Lieferanten durch die Attribute L#. Name etc. beschreibt, und S, in der die Sendungen mit den Attributen S#, L#, F# etc. gespeichert sind, wobei T# eine Kennung des gelieferten Teils sein soll. Befassen wir uns mit folgendem Statement, das eine Möglichkeit darstellt, nach den Namen der Lieferanten von Teil T2 zu fragen:

SELECT L.Name

FROM L,S

WHERE, L.L # = S.L # AND S.T # = "T2"

Nehmen wir an, es handle sich um 100 Lieferanten und 10 000 Sendungen. Das System könnte etwa so vorgehen: Für jede L# aus L wird S gelesen, bis die entsprechende L# gefunden wird. Dann wird die in dem entsprechenden Tupel stehende T# mit "T2" verglichen und im Fall der Übereinstimmung der Name aus in die Ergebnistabelle geschrieben usw.

Es versteht sich von selbst, daß diese Zugriffsstrategie extrem ungünstig ist; da in jedem Schritt Sendungen gelesen werden, die eigentlich gar nicht in Betracht kommen. Viel effektiver wäre es, die Relation S zunächst auf die Tupel zu reduzieren, die T2 enthalten. Daraufhin könnte ein Join von und S über L# vollzogen und aus der Ergebnistabelle mit einer Projektion der Name der Lieferanten von T2 extrahiert werden.

Da sich aus der direkten Zerlegung von SQL-Statements im allgemeinen keine kluge Zugriffsstrategie ergibt gehören zu einem RDBMS wesentlich zwei Dinge, die dem relationalen Modell selbst wesensfremd sind: ein Optimizer und Indizes.

Optimizer

Hierbei handelt es sich um eine Systemkomponente, die den nach gewissen Gesichtspunkten günstigsten Zugriffspfad auswählt. Sie zerlegt das SQL-Statement, berechnet für verschiedene alternative Wege die "Kosten" und wählt dann den günstigsten aus. Das muß nicht unbedingt eine Optimierung im Wortsinn sein, da der Optimizer nicht sämtliche Faktoren berücksichtigt, die das Zeitverhalten beeinflussen, sondern nur einige gravierende, etwa die Anzahl der verschiedenen Werte pro Attribut, die der Tupel (Kardinalität) und - die Indizes.

Indizes

Ein RDBMS bietet Datenunabhängigkeit in zwei Stufen. Dem SQL-Benutzer gegenüber zeigt es eine anwendungsunabhängige Datenstruktur - die Relationen. Wie diese Relationen physisch gespeichert sind, ist eine andere Sache. In dieser Nische, zwischen Anwendung und Platte, sitzt der Index. Das System speichert die Tabelle als sequentielle Datei und zusätzlich eine vom Programmierer bestimmte Spalte zusammen mit direkten Verweisen auf die Tabelle. Nun kann je nach SELECT auf zwei Arten zugegriffen werden. Entweder liest das System sequentiell oder es greift via Index zu. Die Wahl hat der Optimizer.

Und danach?

Das Konzept eines RDBMS hat durch die radikale Trennung von Anwendung und Datenbank etwas Bestechendes. Die Datenbasis des Unternehmens ist unter sämtlichen Gesichtspunkten verfügbar und kann mittels einer relativ einfachen Schnittstelle verarbeitet werden. Gibt es Probleme, sind sie kaum grundsätzlicher Natur (jedenfalls dann nicht, wenn man an kommerzielle Daten denkt, die satzähnlich strukturiert sind). Meist geht es um ausstehende Verbesserungen von SQL oder um Performance-Fragen, die durch größere Puffer im, Haupt- und Erweiterungsspeicher, bessere Optimizer oder kleine Tricks in den Griff zu bekommen sind.

Für satzähnlich strukturierte Daten scheint mir deshalb ein RDBMS das System der Zukunft zu sein. Etwas anders sieht es bei komplexen Datentypen aus. Typen wie Texte und Bilder, die im Office-Bereich eine wichtige Rolle spielen, kann man in einem RDBMS zwar als BLOBs (Binary Large Objects) speichern, aber man verwendet das System dann bereits entgegen seinem ursprünglichen Sinn. Das überlange Feld, in dem beispielsweise ein Paßfoto gespeichert ist, kann in einer Tabelle unter irgendeinem Spaltennamen angelegt werden. Es bleibt dann jedoch der Applikation überlassen, zu erkennen, daß es nur auf eine ganz spezielle Weise bearbeitet werden darf und nicht mit den anderen Daten der Tabelle, etwa Namen oder Altersangaben, vergleichbar ist.

Will man in seine Anwendungen und Datenbanken Texte, Bilder und Grafiken integrieren, wird man am Ende doch so etwas wie "Orion" brauchen. In Zukunft werden so die objektorientierten DBMS nicht statt, aber durchaus neben den relationalen DBMS existieren.