Von der Datensammlung zum Datenmodell

Eine Klasse führt ihre Bücherausleihe in einer Tabellenkalkulation. Eine Zeile je Ausleihe, alles drin: Buchtitel, Autor, Verlag, Name des Schülers, Klasse, Ausleihdatum.

Nach einem halben Jahr sind es 400 Zeilen, und es beginnen Merkwürdigkeiten. Ein Autor ist dreimal verschieden geschrieben. Eine Schülerin hat geheiratet, ihr alter Name steht noch in 12 Zeilen. Und ein Buch, das gerade niemand ausgeliehen hat, verschwindet aus der Liste, sobald man die letzte Ausleihzeile löscht.

Das ist kein Bedienfehler und keine Schlamperei. Es sind drei vorhersagbare Folgen einer einzigen Entscheidung: alles in eine Tabelle zu schreiben. Wer die Ursache kennt, kann sie von vornherein vermeiden.

Fällt dir auf, was hier mehrfach dasteht? „Kästner“ und „Dressler“ stehen dreimal, „Mara Weber“ und „10a“ zweimal. Man nennt das Redundanz: Dieselbe Angabe ist mehr als einmal gespeichert.

Redundanz ist nicht bloß Platzverschwendung. Sie erzeugt drei ganz konkrete Probleme, und die haben Namen.

Änderungsanomalie. Der Verlag wird umbenannt. Jetzt muss die Angabe in allen Zeilen geändert werden, in denen sie steht. Wird eine übersehen, enthält die Tabelle zwei verschiedene Wahrheiten, und keine Abfrage kann noch entscheiden, welche stimmt.

Löschanomalie. Die letzte Ausleihe von „Das fliegende Klassenzimmer“ wird gelöscht. Damit verschwindet auch die Information, dass es dieses Buch überhaupt gibt. Man wollte eine Ausleihe entfernen und hat ein Buch verloren.

Einfügeanomalie. Die Bibliothek kauft ein neues Buch. Wohin damit? Es gibt noch keine Ausleihe, also keine Zeile. Man kann das Buch erst eintragen, wenn es jemand ausleiht, und das ist offensichtlich verkehrt herum.

Alle drei haben dieselbe Ursache: In einer Tabelle stecken Dinge, die gar nicht zusammengehören. Ein Buch existiert unabhängig davon, ob es ausgeliehen ist. Ein Schüler existiert unabhängig von Büchern. Nur die Ausleihe verbindet beide.

Die Lösung folgt direkt aus der Ursache. Man sucht die eigenständigen Dinge und gibt jedem eine eigene Tabelle.

Ein solches eigenständiges Ding heißt Entität. Woran erkennt man eine? An zwei Fragen:

1. Existiert es unabhängig? Ein Buch gibt es auch ohne Ausleihe. Ein Autorenname für sich ist dagegen nur eine Angabe über ein Buch.
2. Hat es eigene Eigenschaften? Ein Schüler hat Vorname, Nachname, Klasse. Ein Ausleihdatum hat keine eigenen Eigenschaften; es ist selbst eine Angabe.

Für unsere Bibliothek ergibt das drei Entitäten: Buch, Schüler und Ausleihe.

Beachte, dass die Ausleihe auch eine Entität ist, obwohl sie zwischen den beiden anderen steht. Sie hat ein eigenes Datum, eine Rückgabefrist, vielleicht eine Verlängerung. Solche Dinge, die eine Beziehung mit eigenen Angaben sind, kommen häufig vor.

Jede Entität hat Attribute, so wie ein Objekt im vorigen Kapitel. Zusätzlich braucht sie etwas Neues: eine Angabe, mit der sich jede Zeile eindeutig ansprechen lässt. Das ist der Schlüssel.

Warum eindeutig? Ohne Eindeutigkeit kann man eine bestimmte Zeile nicht sicher meinen. Gibt es zwei Schüler namens „Jonas Kraus“, so ist „ändere die Klasse von Jonas Kraus“ eine Anweisung, die niemand ausführen kann, weil unklar bleibt, welcher gemeint ist.

Ein guter Schlüssel erfüllt drei Bedingungen:

• eindeutig: Kein Wert kommt zweimal vor.
• unveränderlich: Er ändert sich nie, denn alle Verweise hängen daran.
• immer vorhanden: Er darf nie leer sein.

Deshalb ist der Name ein schlechter Schlüssel, denn er ist weder eindeutig noch unveränderlich. Auch die Telefonnummer ist schlecht, weil sie wechselt. In der Praxis vergibt man eine künstliche Nummer, etwa schuelerNr oder buchNr. Sie hat keinerlei Bedeutung, und genau das ist ihre Stärke: Was nichts bedeutet, kann sich auch nicht ändern.

Zwischen Entitäten bestehen Beziehungen. Sie sind das, was die getrennten Tabellen wieder verbindet.

Wichtig ist dabei, wie viele auf jeder Seite stehen können. Diese Angabe heißt Kardinalität, und man bestimmt sie, indem man die Beziehung in beide Richtungen durchspricht.

1:1, jedem einen, und umgekehrt auch. Beispiel: Schüler und Schülerausweis. Ein Schüler hat einen Ausweis, ein Ausweis gehört einem Schüler.

1:n, einer zu vielen. Beispiel: Klasse und Schüler. Eine Klasse hat viele Schüler, aber jeder Schüler ist in genau einer Klasse.

n:m, viele zu vielen. Beispiel: Buch und Schüler über die Ausleihe. Ein Buch kann nacheinander von vielen Schülern ausgeliehen werden, und ein Schüler leiht viele Bücher.

🔴 Die Richtung muss man einzeln prüfen. Bei „Klasse und Schüler“ verführt das Wort „viele“ dazu, n:m zu sagen. Sprich beide Sätze aus:

• „Eine Klasse hat viele Schüler.“ → n auf der Schülerseite.
• „Ein Schüler ist in einer Klasse.“ → 1 auf der Klassenseite.

Also 1:n und nicht n:m. Wer nur die erste Richtung prüft, entscheidet falsch, und der Fehler wirkt sich später auf den ganzen Tabellenaufbau aus.

Ein Entity-Relationship-Modell stellt das Ergebnis grafisch dar:

• Rechtecke für Entitäten
• Ovale für Attribute (der Schlüssel wird unterstrichen)
• Rauten für Beziehungen, an den Verbindungslinien steht die Kardinalität

 [Schüler] ------< leiht aus >------ [Buch]
    1                n : m               1
     |                                    |
  (schuelerNr)                        (buchNr)
  (vorname)                           (titel)
  (nachname)                          (autor)
  (klasse)                            (verlag)

Aus diesem Bild wird im nächsten Kapitel der Tabellenaufbau. Das ER-Modell ist also kein Selbstzweck, sondern der Plan, nach dem die Datenbank gebaut wird.

Zum Schluss dieselbe Einsicht wie bei der objektorientierten Modellierung: Es gibt nicht das eine richtige Datenmodell. Es kommt darauf an, welche Fragen die Datenbank beantworten soll.

Soll die Bibliothek auch erfassen, wie oft ein Buch gelesen wurde, braucht die Ausleihe ein Rückgabedatum. Soll sie das nicht, wäre es überflüssiger Aufwand. Bewertet wird ein Modell deshalb nicht mit „richtig oder falsch“, sondern mit „beantwortet es die gestellten Fragen ohne Redundanz?“