Echte Datenbank-Avantgardisten halten Relationale Datenbank-Management-Systeme (RDBMS) für total überholt. Für sie ist "Orion" (kein Raumschiff!) "in", denn Orion ist objektorientiert. SQL hingegen gehört ihres Erachtens auf den Müllhaufen der Geschichte. Solche Leute sind wirklich ihrer Zeit voraus.
Für den Praktiker nämlich stellt sich die Welt der Datenbanken ein wenig anders dar: Gerade jetzt, da die Produkte für die verschiedenen Betriebssystem- und Hardwareplattformen einen solchen Qualitätsstandard erreicht haben, daß RDBMS sich in der professionellen Informationsverarbeitung durchsetzen und langsam in großem Stil in Produktion genommen werden, rücken sie erst richtig ins Zentrum des Interesses.
So ungefähr weiß jeder, was ein RDBMS ist: eine Datenbank, die mit Tabellen und SQL und ähnlichem arbeitet. Edgar F. Codd, der das R zum DBMS Ende der 60er Jahre (!) erfunden hat, weiß das natürlich genauer und betont immer wieder, daß vor allem die "sound theoretical basis" das Tolle daran sei. Daß diese enorm mathematisch und deshalb quasi unbestreitbar sei, ist allerdings ein vom Urheber und seinen lagert gezielt verbreitetes Gerücht, das auch durch die Umständlichkeit, mit der er seine Definitionen formuliert, nicht bewiesen wird.
Aber es gibt so etwas wie ein Relationales Modell (RM), und daß dieses unter Zuhilfenahme von Versatzstücken ans Mengenlehre und linearer Algebra zustandegekommen ist, ist schwer zu bestreiten. Zunächst einmal ist ein RDBMS nichts weiter als ein Datenbank-Management-System, das mehr oder weniger das Relationale Modell verwirklicht.
Dieses Modell ist mehrfach von Codd selbst sowie von Chris Date, seinem langjährigen Mitarbeiter und Partner, dargestellt worden. Angefangen hat alles mit Codds klassischem Papier "A Relational Model For Large Shared Data Banks" (Communications of the ACM 13, Juni 1970). Wichtig waren in der Folge Dates Veröffentlichungen: einerseits sein Lehrbuch "An Introduction To Database Systems" (5. Aufl., Reading 1990) und andererseits die "Selected Writings" (Reading 1986).
Nicht berücksichtigen werde ich bei der folgenden Darstellung des relationalen Modells Codds neues Buch "The Relational Model For Database Management Version 2" (Reading 1990). Zum einen wird es noch sehr kontrovers diskutiert etwa in der US-Zeitschrift "Database Programming & Design" - und zum anderen vermengt Codd in seinen nunmehr 333 (!) Regeln für RDBMS das Basismodell mit mehr oder weniger praktischen Anforderungen an ein DBMS.
Natürlich ist das Konzept des RDBMS nicht nur aus Liebe zur Theorie erfunden worden. Der Ausgangspunkt war ein absolut praktisches Problem: das der Änderung und Anpassung von Applikationen, die auf konventionelle, meist hierarchische DBMS zugreifen. In der Welt von IMS und ähnlichen Systemen sind Anwendung und DB-Design sehr eng verquickt. Der Programmierer beziehungsweise sein Programm muß selbst durch die Datenbank navigieren, und die physische Speicherungsstruktur ist ganz speziell auf bestimmte Anwendungen zugeschnitten. Die fundamentale Idee, von der Codd ausging, bestand dagegen in einer säuberlichen Trennung der Verarbeitung der Daten in der Applikation von ihrer Speicherung in der Datenbank. So würde die Wartung vereinfacht und die Flexibilität der DB gegenüber neuen Anforderungen, erhöht. Erst auf dieser Basis ergibt sich das Bedürfnis nach einem Modell der Daten, das von, einer bestimmten Verarbeitungsweise unabhängig ist.
Ein solches Modell ist das relationale (RM), und es besteht wie jedes andere Datenmodell auch - aus der Definition von:
- Objekten,
- generellen Integritätsregeln und
- Operatoren.
Der Ausdruck "Objekt" bezeichnet hier, was als Daten in welcher Form auch immer vorliegt. Er ist also nicht zu verwechseln mit dem Objektbegriff, der heute im Zusammenhang mit der objektorientierten Programmierung in Mode ist, wo darunter ein abstrakter Datentyp verstanden wird.
In unserem Fall stellen die Objekte Relationen dar. Eine Relation R besteht aus dem relationalen Schema und einer Menge von Tupeln.
Das relationale Schema notiert man beispielsweise so: R (A1, ... An), wobei die Ai im Klammerausdruck Attribute heißen. Ihre Anzahl n wird Grad der Relation R genannt. Zu jedem Attribut Ai, das heißt für alle i von i = 1 bis i = n, existiert eine Domain. Den Sinn dieser dunklen Namen werden uns die Tupel erhellen.
Domains sorgen für saubere Werte
Ein zur Relation R mit dem relationalen Schema R (A1,..... An) gehöriges Tupel ist die geordnete Menge (a1, ... an), wobei ai als Wert eine konkrete Ausprägung des Attributs Ai darstellt. Die zugehörige Domain Di ist ein Wertebereich für die ai, und Ai ist eine semantische Kennzeichnung. Ein Attribut stellt demnach eine inhaltliche Interpretation der zugehörigen Werte dar. Ein Beispiel bringt vielleicht etwas mehr Licht in die Sache. Betrachten wir die Tabelle M:
Sie ist die Darstellung einer Relation M mit dem Schema M (Mitarbeiter#, Name, Alter) und den Tupeln (1, Fritz, 31), (2, Franz, 52) und (3, Hans, 18). Die zugehörigen Domains sind etwa:
- D1, die natürlichen Zahlen von 1 bis 100 (wenn wir davon ausgehen, daß es nicht mehr Mitarbeiter geben wird);
- D2, deutsche Vornamen, eine Teilmenge der Buchstabenketten;
- D3, die natürlichen Zahlen von 18 bis 100 (da ältere Mitarbeiter vermutlich nicht beschäftigt werden).
Relationen sind nicht identisch mit Tabellen
Man bemerkt, daß die Domains zu völlig unterschiedlichen Attributen teilweise oder zur Gänze übereinstimmen können: Der Zahl 45 beispielsweise ist nicht anzumerken, ob sie als Mitarbeiternummer oder als Alter eine Kollegen zu interpretieren ist.
Oft wird nicht zwischen der Relation und ihrer Repräsentation in einer Tabelle, die als sequentielle Datei gespeichert werden kann, unterschieden. Das ist nicht ganz richtig:
- Erstens finden die Domains in der Tabelle keinen Ausdruck. Sie können aber eine wichtige Rolle bei Änderungsoperationen spielen. Verfügt das System über Domain-Unterstützung, so können erweiterte Typprüfungen unabhängig vom Programm stattfinden. Das DBMS weist zum Beispiel das Tupel (115, Han7, 312). wegen dreifachen Domain-Fehlers zurück, und zwar ohne daß das eigens Codiert wurde!
- Zweitens haben die Zeilen einer Tabelle eine Reihenfolge, die Tupel, die sie repräsentieren, jedoch nicht,
Hinzu kommt, daß in ein und derselben Relation keine identischen Tupel erlaubt sind das heißt, es ist nicht zulässig, daß die zugehörige Tabelle gleiche Zeilen mehrfach enthält.
Dies ist eine Konsequenz dessen, daß die Tupel eine Menge im mathematischen Sinn darstellen und alle Elemente einer Menge per definitionem verschieden sind.
Die Anzahl der Tupel oder Zeilen heißt Kardinalität von R. Sie kann sich selbstverständlich im Lauf der Bearbeitung durch Einfügen und Löschen von Tupeln ändern.
Unter dem Schlüssel einer Relation R versteht man eine Untermenge der Attribute der Relation, für die gilt:
- Jedes Tupel der Relation läßt sich bereits durch die Werte, die zu den Schlüsselattributen gehören, eindeutig identifizieren. Falls die Attribute Ai,... Ak einen Schlüssel in R(A1, ... Ai, .. Ak, ..Al) bilden, müssen also sämtliche (Unter-)Tupel (ai, ... ak) verschieden sein (keine doppelten Schlüssel).
- Diese Untermenge ist minimal, das heißt, jedes Schlüsselattribut Ist für die Identifikation notwendig (keine unnötig langen Schlüssel). Man kann kein Schlüsselattribut weglassen, ohne die erste Bedingung - eindeutige Identifizierbarkeit - zu verletzen.
Gibt es mehrere Schlüssel, so wird ein Primärschlüssel ausgewählt. Für diese Wahl existiert kein formales Kriterium. In unserem Beispiel gibt es drei Schlüsselkandidaten, da jedes Attribut ausschließlich verschiedene Werte annimmt, also das jeweilige Tupel eindeutig festlegt.
Man würde selbstverständlich Mitarbeiter als Primärschlüssel wählen, da bei einer Vergrößerung des Betriebs vielleicht noch ein 18jähriger Hans eingestellt wird. Die Auswahl des Primärschlüssels ist also kein reiner Formalismus, sondern man muß den Inhalt, den die Werte anzeigen, die Attribute also, bedenken.
Eine zweite Tabelle PM wird deutlich machen, was ein Fremdschlüssel ist. Sie hält fest, welche Mitarbeiter in welchen Projekten arbeiten.
Man kann an PM sehen, daß jede Relation einen Schlüssel hat. Da keine gleichen Tupel in derselben Relation vorkommen dürfen, ist im Extremfall, das heißt, wenn weniger Attribute nicht ausreichen, eben die Gesamtzahl der Attribute ein Schlüssel.
Hier dient nun ein Fremdschlüssel dazu, die Beziehungen von Relationen darzustellen. Es handelt sich schlicht um eine Menge von Attributen einer Relation R2, die Primärschlüssel in einer anderen Relation R, sind.
In unserem Beispiel ist das Attribut Mitarbeiter # Fremdschlüssel in P, da es Primärschlüssel in M ist. Daß Mitarbeiter # in P auch Teil des Primärschlüssels ist, tut hier nichts zur Sache.
Noch etwas kann man an PM bemerken: Der Sachverhalt, daß zum Projekt 1 mehrere Mitarbeiter gehören, kann nicht in einer Zeile ausgedruckt werden. Es gibt keine "repeating groups".
Nehmen wir an, ein Projekt sei gekennzeichnet durch die Tabelle P: Diese Tabelle ist nicht erlaubt, da nicht zu jedem Attribut in jeder Spalte genau ein Wert existiert. Man sagt, sie befinde sich nicht in der ersten Normalform. Die Lösung besteht darin, das relationale Schema von P um P-Mitarbeiter zu verkürzen und die Tabelle PM wie oben zu definieren. Projekt# ist dann Fremdschlüssel in PM und Primärschlüssel in P. So wird der Zusammenhang, die Beziehung zwischen Mitarbeitern, die in M beschrieben werden, und Projekten, die in P charakterisiert werden, in einer eigenen Relation PM dargestellt. Relationen können also sowohl Sachverhalte (Entitäten) als auch ihr Verhältnis zueinander (Relationship) repräsentieren.
Integrität
Die generellen Integritätsregeln verbieten in allgemeiner Weise - das heißt unabhängig vom konkreten Inhalt der Relationen - Operationen, die zu notwendig falschen Resultaten führen. Es gibt zwei solcher Vorschriften:
- Kein Wert, der zu einem Attribut des Primärschlüssels gehört, darf auf NULL gesetzt werden (Entitätsintegrität). NULL bedeutet nun keineswegs den Wert 0, sondern soviel wie "unbekannt". Diese Möglichkeit, NULL zuzuordnen, ist sinnvoll, da es Situationen gibt, in denen bestimmte Informationen noch nicht vorliegen, aber eine Bearbeitung des Vorhandenen sinnvoll erscheint.
Den Wert ganz undefiniert zu lassen, würde einen Typfehler nach sich ziehen. Mittels NULL aber kann Hans bereits einem Projekt zugeordnet werden, auch wenn der Datenbank sein Alter noch unbekannt ist. Die Regel besagt nun lediglich, daß man keine Tupel generieren darf, die nicht eindeutig identifizierbar sind.
- Sei PS ein Primärschlüssel in der Relation R, und FS ein Fremdschlüssel (zu PS) in R2, dann muß gesichert werden, daß ein Wert aus FS auch in PS vorkommt oder daß der gesamte Schlüsselwert in FS (bei zusammengesetzten Schlüsseln) NULL ist (referentielle Integrität).
Das klingt unübersichtlich, ist in Wahrheit aber ganz einfach. Denken wir an P. Würde man dem Projekt 2 noch einen Mitarbeiter 7 zuordnen, so wäre das Unfug, solange in der Relation, welche die Mitarbeiter definiert (und in der deshalb Mitarbeiter# Primärschlüssel ist), "7" nicht vorkommt. Wird auf der anderen Seite ein neues Projekt gestartet, nennen wir es 3, so macht es durchaus Sinn, schon mit ihm zu arbeiten, auch wenn noch kein Mitarbeiter zugeordnet ist, Mitarbeiter# also NULL ist (in unserem Beispiel darf wegen Regel 1 allerdings kein Tupel, in dem die Mitarbeiter# unbekannt ist, eingefügt werden). Wichtig ist, daß mit dieser Regel an sich legale Operationen auf einer Relation zurückgewiesen werden oder Folgeoperationen auf andere Relationen notwendig machen, rein wegen des durch Schlüssel definierten Verhältnisses der Relationen untereinander.
Es gibt in der sogenannten relationalen Algebra zwei Sorten von Operationen, und zwar solche, die auf eine Relation wirken (unitäre Operationen) und solche, die zwei Relationen kombinieren.
- Der Selektionsoperator SL sucht aus einer gegebenen Relation R eine Untermenge der Tupel gemäß einer zu spezifizierenden Bedingung aus. Man sollte ihn nicht mit der SQL-Anweisung SELECT verwechseln.
- Der Projektionsoperator P reduziert das relationale Schema, das heißt, er wählt eine Untermenge der Attribute aus.
Die auf zwei Relationen wirkenden sogenannten binären Operatoren werden nach Vorbildern der Mengenlehre gebildet. Seien R, und R2 Relationen vom Grad n und die verschiedenen Attribute kompatibel. Das bedeutet, daß einander entsprechende Attribute A, von R, und A1 von R2 zwar nicht identisch, aber auf derselben Domain definiert und inhaltlich verträglich sein müssen:
- Union U basiert auf der Vereinigungsmenge; U (R1, R2) ist eine Relation, die alle Tupel so. wohl aus R1 als auch aus R2 enthält.
- Intersection I basiert auf der Schnittmenge; also I (R1, R2) ist die Relation mit all den Tupeln, die sowohl im R1 als auch im R2 vorkommen.
- Differenz D (R1, R2) bezeichnet die Relation derjenigen Tupel, die Elemente von R1, nicht aber von R2 sind.
Das Join erweitert das relationale Schema
Der Join J ist et geht hier um die von Relationen, aber Beibehaltung des relationalen Schemas, Union -, sondern durch Erweiterung desselben, indem die Tupel von R1 und R2 aneinandergekettet werden. Es gibt mehrere Varianten des Joins. Wichtig ist der sogenannte natürlich Join zweier Relationen R1 und R2. Die Voraussetzung des gleichen relationalen Schemas (bis auf unterschiedliche Attributnamen) können wir fallenlassen, aber es muß ein gemeinsame Attribut Aj vorhanden sein: R1 (A1, ... Aj, An) und R2 (A 1, ... Aj, Am). Dann ist die Relation JAj (R1, R2) die Menge aller Tupel, die aus der Vereinigung der Tupel von R1 und R2 hervorgehen, wenn die Werte für Aj übereinstimmen.
Es gibt noch mehr Operationen, aber für unsere Zwecke reichen die vorgestellten aus.
Soviel zur theoretischen Basis. Im zweiten Teil dieses Beitrags wird es praktischer - mit SQL, DDL und DML sowie mit Anmerkungen zu Optimizern, Indexen und der Zukunft.