Datenbankmodellierung: ER-Modell und Tabellen

Eine Datenbank bildet einen Ausschnitt der Wirklichkeit ab. Eine Entität ist ein einzelnes Objekt, das man eindeutig erkennen kann, zum Beispiel der Angestellte Müller oder das Projekt 3232. Gleichartige Entitäten fasst man zu einem Entitätstyp zusammen, etwa Angestellter, Projekt, Buch oder Autor. In einem ER-Diagramm (ER steht für Entity-Relationship, also „Dinge und ihre Beziehungen“) zeichnet man Entitätstypen meistens als Rechteck.

Attribute beschreiben einen Entitätstyp näher. Beim Entitätstyp Angestellter sind das zum Beispiel Nachname, Vorname und Eintrittsdatum. Nicht jedes Attribut muss man speichern: Das Alter eines Mitarbeiters kann man aus dem Geburtsdatum und dem Tagesdatum berechnen. Deshalb besteht keine zwingende Notwendigkeit, es direkt in der Datenbank zu speichern.

Jede Zeile einer Tabelle muss eindeutig erkennbar sein. Dafür dient ein Schlüssel: eine einzelne Spalte oder eine Gruppe von Spalten, deren Werte in jeder Zeile eine einmalige Kombination ergeben. Oft gibt es mehrere mögliche Schlüssel, die Schlüsselkandidaten. Einer davon wird als Primärschlüssel ausgewählt.

Ein Primärschlüssel wird üblicherweise möglichst klein gewählt, hat also möglichst wenige Attribute oder einen möglichst einfachen Datentyp. Er sollte zeitlich stabil sein, sich also nicht ändern. Außerdem muss er die Objekte wirklich eindeutig unterscheiden. Wählst du Name und Geburtstag zusammen, legst du fest, dass es keine zwei gleichnamigen Personen mit demselben Geburtstag geben darf. Ein künstlicher Schlüssel (Surrogatschlüssel), zum Beispiel eine fortlaufende Nummer, vermeidet dieses Problem in jedem Fall. Eine Kundennummer ist ein solcher Schlüssel.

Eine Beziehung verknüpft zwei oder mehr Entitäten. Gleichartige Beziehungen fasst man zu einem Beziehungstyp zusammen. Im ER-Diagramm sind das Verbindungslinien zwischen den Rechtecken. Wichtig ist, wie viele Entitäten auf jeder Seite beteiligt sein können oder müssen.

Bei einer 1:n-Beziehung steht jede Entität auf der einen Seite mit beliebig vielen Entitäten der anderen Seite in Beziehung. In der Gegenrichtung steht jede Entität mit einer Entität in Beziehung. Beispiel: Ein Kind hat genau eine leibliche Mutter, eine Mutter kann mehrere Kinder haben.

Bei einer n:m-Beziehung können auf beiden Seiten beliebig viele Entitäten in Beziehung stehen. Schreibe nicht „n:n“: Das würde andeuten, dass auf beiden Seiten gleich viele Entitäten vorhanden sind.

So überführst du eine 1:n-Beziehung in Tabellen: Die Tabelle auf der n-Seite (die Detail-Tabelle) bekommt eine zusätzliche Spalte. Diese Spalte nimmt als Fremdschlüssel den Primärschlüssel der anderen Tabelle (der Haupttabelle) auf. Ein Fremdschlüssel ist also eine Spalte, die auf eine Zeile einer anderen Tabelle zeigt.

n:m-Beziehungen können in den meisten relationalen Datenbanken nicht direkt umgesetzt werden. Man erstellt eine zusätzliche Tabelle, die Hilfstabelle. Sie enthält die Primärschlüssel beider Tabellen als Fremdschlüssel. So entstehen zwei 1:n-Beziehungen.

Gehören zu einer n:m-Beziehung weitere Attribute, bildet man häufig schon im ER-Modell einen eigenen Entitätstyp. Beispiel: Ein Hotel ist reserviert für eine Person. Es entsteht der neue Entitätstyp „Reservierung“ mit n:1-Beziehungen zu Person und Hotel. Er bekommt weitere Attribute wie Reservierungszeitraum und Reservierungsstatus.

In einer relationalen Datenbank liegen alle Daten in Tabellen. Eine Tabelle heißt dort auch Relation. Jede Zeile ist ein Datensatz, die Spalten sind die Attribute, also die Eigenschaften. Das Relationenschema legt die Anzahl und den Typ der Attribute einer Tabelle fest. Im ER-Modell bedeutet „Relation“ dagegen die Beziehung zwischen Entitäten.

Das Schema der ganzen Datenbank legt fest, welche Daten gespeichert werden und wie sie in Beziehung zueinander stehen. Es zu erstellen, nennt man Datenmodellierung.

Jede Tabelle hat einen Primärschlüssel. Will eine andere Tabelle auf einen Datensatz zeigen, verwendet sie dessen Primärschlüssel als Fremdschlüssel. Ein Fremdschlüssel verweist auf einen Primärschlüssel einer anderen oder der gleichen Tabelle. Er zeigt an, welche Zeilen inhaltlich zusammengehören.

Beim Übertragen eines ER-Modells in Tabellen gilt: Ein Entitätstyp wird eine Tabelle. Ein Beziehungstyp wird ein Fremdschlüssel. Nur bei n:m kommt eine zusätzliche Tabelle dazu. Ein Attribut bleibt ein Attribut.

Auch ein Schlüssel kann aus mehreren Spalten bestehen. In der Hilfstabelle einer n:m-Beziehung sind beide Fremdschlüssel zusammen der Primärschlüssel. Ändert sich ein Primärschlüsselwert, müssten auch die zugehörigen Fremdschlüsselwerte geändert werden. Das ist oft aufwendig. Darum soll ein Primärschlüssel stabil bleiben.

Beim Planen von Tabellen passiert leicht ein Fehler: Dieselbe Information steht an mehreren Stellen. Das nennt man Redundanz, also mehrfaches Festhalten des gleichen Sachverhalts. Normalisierung ist ein Entwurfsansatz für relationale Datenbanken. Sie strukturiert die Daten anhand einer Folge von Regeln, den Normalformen, die aufeinander aufbauen.

Ihr Zweck: Redundanzen verringern und dadurch Anomalien verhindern. Eine Anomalie ist zum Beispiel, dass eine Änderung nicht an allen Stellen gemacht wird. Dann sind die Daten nicht mehr konsistent: Sie widersprechen sich, und man weiß nicht, welche stimmen. Mit Normalisierung ändert man lediglich an einer Stelle.

Beispiel: Eine Tabelle enthält für jedes Lied einer CD auch Albumtitel, Interpret, Gründungsjahr und Erscheinungsjahr. Bei einer CD mit drei Liedern stehen diese vier Angaben dreimal da. Ändert jemand den Albumtitel nur in einer Zeile, passen die Daten nicht mehr zusammen. Das nennt man Update-Anomalie.

Die Lösung: Man teilt die Tabelle. Die Angaben zur CD stehen nur noch einmal pro CD in einer eigenen Tabelle CD. In der Tabelle Lied bleibt die CD_ID als Fremdschlüssel, der auf den Primärschlüssel der Tabelle CD verweist. CD_ID und Track bilden zusammen den Primärschlüssel von Lied.

Auch das Gründungsjahr lässt sich auslagern. Es hängt vom Interpreten ab, und der Interpret hängt von der CD_ID ab. Kommt eine neue CD mit einem schon vorhandenen Interpreten dazu, würde das Gründungsjahr noch einmal gespeichert. Deshalb lagert man die beiden voneinander abhängigen Angaben in eine eigene Tabelle aus. Der Schlüssel der neuen Tabelle bleibt als Fremdschlüssel in der alten Tabelle. Das gilt nur, wenn der Interpret weltweit eindeutig ist. Sonst braucht die Künstler-Tabelle eine synthetische (künstliche) ID.

Eine weitere Regel: Jedes Attribut soll nur einen einfachen, unteilbaren Wert enthalten. Die Adresse zerlegt man daher, sofern es der zugrunde liegende Prozess erfordert und erlaubt, in PLZ (Postleitzahl), Ort, Straße und Hausnummer. Zum Schluss ein Hinweis: In speziellen Anwendungsfällen steht Redundanzfreiheit in Konkurrenz zur Verarbeitungsgeschwindigkeit oder zu anderen Zielen. Dann kann es sinnvoll sein, auf Normalisierung zu verzichten.