Das relationale Datenmodell: Tabellen, Schlüssel, Beziehungen

Das Modell steht: drei Entitäten, zwei Beziehungen, Schlüssel vergeben. Jetzt soll daraus eine Datenbank werden, mit der man wirklich arbeiten kann.

Der Übergang ist erstaunlich mechanisch. Es gibt genau drei Regeln, und welche greift, hängt allein von der Kardinalität ab. Wer sie kennt, übersetzt ein ER-Modell ohne Nachdenken in Tabellen, und, was wichtiger ist, erkennt umgekehrt an einem Tabellenaufbau sofort, welches Modell dahintersteckt.

Eine Relation ist das, was man umgangssprachlich Tabelle nennt. Sie hat feste Spalten und beliebig viele Zeilen.

• Eine Zeile heißt Tupel oder Datensatz. Sie beschreibt genau ein Ding.
• Eine Spalte heißt Attribut. Sie steht für eine Eigenschaft.
• Der Wertebereich einer Spalte heißt Domäne: Ganzzahl, Text, Datum, Wahrheitswert.

Zwei Regeln gelten dabei streng, und beide haben einen Grund:

In jeder Zelle steht genau ein Wert. „Deutsch, Mathe, Sport“ in einem Feld wäre bequem, macht aber jede Auswertung unmöglich: Man könnte nicht mehr zählen, wie viele Schüler Sport belegen, ohne den Text zu zerlegen.

Die Reihenfolge der Zeilen bedeutet nichts. Eine Relation ist eine Menge von Tupeln. Wer eine Reihenfolge braucht, muss sie als Attribut speichern, etwa ein Datum oder eine Platznummer.

Der Primärschlüssel ist die Spalte, die jede Zeile eindeutig bestimmt. Er ist der Schlüssel aus dem vorigen Kapitel, jetzt mit seinem Fachnamen.

Neu ist der Fremdschlüssel. Er ist eine Spalte, deren Werte auf den Primärschlüssel einer anderen Tabelle verweisen. Damit werden die getrennten Tabellen wieder verbunden.

In der Ausleihtabelle steht keine einzige Namensangabe. Es steht dort nur die Nummer, unter der man den Namen nachschlagen kann. Genau das beseitigt die Redundanz: Der Name „Mara Weber“ ist einmal gespeichert, obwohl sie zweimal ausgeliehen hat. Ändert sich der Name, ändert man eine Zelle.

Jetzt der mechanische Teil. Aus dem ER-Modell werden Tabellen nach drei Regeln, und die Kardinalität entscheidet, welche gilt.

Regel 1: Jede Entität wird eine Tabelle. Ihre Attribute werden Spalten, ihr Schlüssel wird Primärschlüssel.

Regel 2: Eine 1:n-Beziehung wird ein Fremdschlüssel auf der n-Seite.

Beispiel Klasse und Schüler (1:n): Die Schülertabelle bekommt eine Spalte klassenNr.

Warum auf der n-Seite und nicht umgekehrt? Weil in jeder Zelle nur ein Wert stehen darf. Ein Schüler ist in genau einer Klasse, also passt die eine Klassennummer in seine Zeile. Umgekehrt müsste in der Klassenzeile eine Liste aller Schüler stehen, und das verbietet die Zellenregel.

Regel 3: Eine n:m-Beziehung wird eine eigene Tabelle.

Sie enthält die Primärschlüssel beider Seiten als Fremdschlüssel. Zusammen bilden diese den Primärschlüssel der neuen Tabelle.

Auch hier folgt das Warum aus derselben Zellenregel. Bei Schüler und Kurs (n:m) müsste ein Fremdschlüssel auf einer der beiden Seiten mehrere Werte tragen, egal welche Seite man wählt. Das geht nicht, also braucht es einen dritten Ort, an dem jede einzelne Zuordnung eine eigene Zeile bekommt.

Schueler(schuelerNr, vorname, nachname, klasse)
Kurs(kursNr, bezeichnung, lehrer)
Belegung(schuelerNr, kursNr, note)
        └── beide zusammen sind der Primärschlüssel,
            jeder für sich ist ein Fremdschlüssel

Die Belegungstabelle löst zugleich das Problem aus dem vorigen Kapitel: Die Note gehört weder zum Schüler noch zum Kurs, sondern zur Zuordnung. Hier hat sie ihren Platz.

Was passiert, wenn in der Ausleihtabelle die schuelerNr 7 steht, es aber gar keinen Schüler 7 gibt?

Man hätte einen Verweis ins Leere. Die Ausleihe wäre keinem zuzuordnen, und jede Auswertung würde sie entweder verschlucken oder mit einer Fehlermeldung abbrechen.

Ein Datenbanksystem verhindert das. Die Regel heißt referenzielle Integrität und besagt: Jeder Fremdschlüsselwert muss als Primärschlüssel in der Zieltabelle vorhanden sein. Daraus folgen zwei Verhaltensweisen:

• Ein Eintrag mit unbekanntem Fremdschlüssel wird abgelehnt.
• Wird eine Zeile gelöscht, auf die noch verwiesen wird, gibt es drei mögliche Reaktionen: ablehnen, die verweisenden Zeilen mitlöschen oder den Verweis auf „leer“ setzen. Welche gilt, legt man beim Anlegen fest.

Das ist ein wichtiger Punkt für das Verständnis von Datenbanken überhaupt: Sie prüfen nicht nur, sie verhindern ungültige Zustände. Eine Tabellenkalkulation lässt jede Eingabe zu, eine Datenbank nicht.

Bibliothek mit drei Entitäten und einer n:m-Beziehung über die Ausleihe:

Schueler(schuelerNr, vorname, nachname, klasse)
Buch(buchNr, titel, autor, verlag)
Ausleihe(ausleihNr, schuelerNr, buchNr, ausleihdatum, rueckgabedatum)

Die Ausleihe hat hier einen eigenen Primärschlüssel und nicht die Kombination aus schuelerNr und buchNr. Der Grund: Derselbe Schüler kann dasselbe Buch zweimal ausleihen, im Februar und im November. Wäre die Kombination der Schlüssel, ließe sich die zweite Ausleihe nicht speichern.

Merke dir diese Prüfung: Kann dieselbe Zuordnung mehrfach vorkommen? Wenn ja, braucht die Beziehungstabelle einen eigenen Schlüssel oder zusätzlich das Datum im Schlüssel.