Modellierung von Beziehungen zwischen Tabellen zur Normalisierung

Heute tauchen wir tiefer in ein echt wichtiges Thema ein: das Modellieren von Beziehungen zwischen Tabellen. Normalisierung ist nämlich nicht nur atomare Daten und das Entfernen von Redundanz, sondern auch das Erstellen der richtigen Beziehungen zwischen Tabellen.

Wenn Datenbanken ein organisiertes System zur Speicherung von Infos sind, dann sind Beziehungen zwischen Tabellen die logischen Brücken, die zeigen, wie Daten miteinander interagieren. Stell dir eine Bibliothek vor, wo Infos über Bücher getrennt von Infos über Autoren gespeichert werden, aber jedes Buch "kennt" seinen Autor über eine spezielle Beziehung. Oder nimm einen Online-Shop: Produktdaten existieren unabhängig von Kundendaten, aber wenn jemand bestellt, verbindet das System einen bestimmten Kunden mit bestimmten Produkten über die Bestelltabelle.

In einer medizinischen Klinik sind Patienten mit ihren Krankenakten verbunden, Ärzte mit dem Terminplan, und Medikamente mit den Verschreibungen. Diese Beziehungen helfen dem System zu verstehen, welche Infos zu was gehören, ohne Daten unnötig zu duplizieren.

Die wichtigsten Beziehungstypen funktionieren wie Beziehungen im echten Leben: Ein Pass gehört nur zu einer Person (eins-zu-eins), ein Dozent kann mehrere Kurse geben (eins-zu-viele), und Studierende können sich für verschiedene Fächer anmelden, wobei jedes Fach von verschiedenen Studierenden besucht wird (viele-zu-viele).

Eins-zu-eins (1:1)

Das ist eine Beziehung, bei der ein Eintrag in Tabelle "A" genau einem Eintrag in Tabelle "B" entspricht. Zum Beispiel haben wir die Tabellen "Mitarbeiter" und "Passdaten". Ein Mitarbeiter kann nur einen Pass haben, und jeder Pass gehört zu genau einem Mitarbeiter.

Beispiel:

Mitarbeiter

Passdaten

Hier wird die Beziehung über den Foreign Key mitarbeiter_id hergestellt, der auf die id in der Tabelle "Mitarbeiter" zeigt.

Eins-zu-viele (1:N)

Das ist der am häufigsten genutzte Beziehungstyp. Hier kann jeder Eintrag aus Tabelle "A" mit mehreren Einträgen in Tabelle "B" verbunden sein, aber jeder Eintrag aus Tabelle "B" ist nur mit einem Eintrag aus Tabelle "A" verbunden. Zum Beispiel haben wir die Tabellen "Dozenten" und "Kurse". Ein Dozent kann mehrere Kurse geben.

Beispiel:

Dozenten

Kurse

Die Beziehung wird über den Foreign Key dozent_id in der Tabelle "Kurse" hergestellt.

Viele-zu-viele (M:N)

Wenn du ganz viele Sachen hast, macht das Spaß, ist aber auch tricky. Hier kann jeder Eintrag in Tabelle "A" mit mehreren Einträgen aus Tabelle "B" verbunden sein – und umgekehrt. Zum Beispiel: Studierende können sich für mehrere Kurse anmelden, und jeder Kurs kann von mehreren Studierenden besucht werden.

Beispiel:

Studierende

Kurse

Um das zu verbinden, brauchen wir eine Zwischentabelle, die die Zuordnung zwischen Studierenden und Kursen speichert:

Anmeldungen

Modellierung von Beziehungen mit Foreign Keys

Ein Foreign Key ist eine Spalte (oder mehrere Spalten), die auf die Spalte des Primary Keys in einer anderen Tabelle zeigt. Das ist die Basis für Beziehungen zwischen Tabellen.

Beispiel für einen Foreign Key:

CREATE TABLE Kurse (
    id SERIAL PRIMARY KEY,
    kursname VARCHAR(255)
);

CREATE TABLE Anmeldungen (
    id SERIAL PRIMARY KEY,
    student_id INT,
    kurs_id INT,
    FOREIGN KEY (kurs_id) REFERENCES Kurse(id)
);

Wie vermeidet man Fehler beim Design von Foreign Keys? Wichtig ist vor allem, dass die Datentypen zwischen den Spalten von Foreign Key und Primary Key übereinstimmen – sonst lässt die Datenbank die Beziehung gar nicht zu. Außerdem solltest du dir vorher überlegen, was beim Löschen von Einträgen passieren soll. Wenn du zum Beispiel eine Zeile aus der Elterntabelle löschst, was passiert dann mit den Kind-Einträgen? Eine beliebte Option ist ON DELETE CASCADE, damit verbundene Daten automatisch mitgelöscht werden. Das hält alles sauber und verhindert "hängende" Verweise.

Umsetzung der "Viele-zu-viele"-Beziehung

Nehmen wir das Beispiel: Wir haben Studierende und Kurse. Ein Student kann in mehreren Kursen angemeldet sein, und ein Kurs kann mehrere Studierende haben. Für die M:N-Beziehung erstellen wir drei Tabellen: Studierende, Kurse und Anmeldungen.

CREATE TABLE Studierende (
    id SERIAL PRIMARY KEY,
    name VARCHAR(255)
);

CREATE TABLE Kurse (
    id SERIAL PRIMARY KEY,
    kursname VARCHAR(255)
);

CREATE TABLE Anmeldungen (
    id SERIAL PRIMARY KEY,
    student_id INT,
    kurs_id INT,
    FOREIGN KEY (student_id) REFERENCES Studierende(id),
    FOREIGN KEY (kurs_id) REFERENCES Kurse(id)
);

Jetzt können wir Einträge in die Tabelle Anmeldungen hinzufügen, um Studierende und Kurse zu verbinden.

Praktische Aufgabe

Erstelle die Datenbankstruktur für ein Kursverwaltungssystem. Du brauchst die Tabellen Studierende, Kurse und Anmeldungen. Setz alle Beziehungen zwischen den Tabellen um. Dann füge Beispieldaten zu Studierenden, Kursen und deren Anmeldungen ein. Schauen wir uns mal an, wie das geht.

1. Tabellen erstellen:

CREATE TABLE Studierende (
    id SERIAL PRIMARY KEY,
    name VARCHAR(255)
);

CREATE TABLE Kurse (
    id SERIAL PRIMARY KEY,
    kursname VARCHAR(255)
);

CREATE TABLE Anmeldungen (
    id SERIAL PRIMARY KEY,
    student_id INT,
    kurs_id INT,
    FOREIGN KEY (student_id) REFERENCES Studierende(id),
    FOREIGN KEY (kurs_id) REFERENCES Kurse(id)
);

2. Daten einfügen:

INSERT INTO Studierende (name) VALUES ('Otto Lin'), ('Maria Chi');
INSERT INTO Kurse (kursname) VALUES ('SQL Grundlagen'), ('Datenbankadministration');
INSERT INTO Anmeldungen (student_id, kurs_id) VALUES (1, 1), (1, 2), (2, 1);

3. Daten prüfen:

SELECT
    Studierende.name AS student, 
    Kurse.kursname AS kurs
FROM Anmeldungen
JOIN Studierende ON Anmeldungen.student_id = Studierende.id
JOIN Kurse ON Anmeldungen.kurs_id = Kurse.id;

Ergebnis:

Schwierigkeiten und Besonderheiten beim Modellieren von Beziehungen

Wenn du Beziehungen zwischen Tabellen modellierst, können Probleme auftauchen wie:

• Fehler beim Löschen von Daten (zum Beispiel, wenn es Einträge in der Kind-Tabelle gibt, die von einem Eintrag in der Elterntabelle abhängen).
• Performance von Abfragen bei großen Datenmengen. M:N-Beziehungen sind besonders "hungrig", weil sie zusätzliche Joins brauchen.

Das kannst du lösen durch:

• Indizes auf Foreign Keys
• Durchdachtes Datenbank-Design.
• Balance zwischen Normalisierung und Performance.

Wir haben uns die Modellierung von Beziehungen zwischen Tabellen auf ganz einfachem Level angeschaut und das praktisch umgesetzt, indem wir eine Datenbankstruktur für ein Kursverwaltungssystem gebaut haben. Klar, ein großes Beispiel wäre cool, aber mir ist nix eingefallen, wie man das spannend machen könnte. Ein großes Beispiel wird schnell kompliziert und langweilig. Bringt dann auch nicht viel. Ich versuch, das Thema gegen Ende vom Kurs nochmal aufzugreifen.