Coding Garden
Anmelden

Was sind relationale Datenbanken?

Du hast bereits gelernt, dass SQL-Datenbanken Daten in Tabellen speichern. Aber warum heißen sie relationale Datenbanken? Und warum nutzen wir mehrere Tabellen statt einer einzigen großen Tabelle? In diesem Artikel verstehst du das Kernkonzept relationaler Datenbanken.

Was bedeutet "relational"?

Das Wort "relational" bedeutet "auf Beziehungen basierend". Eine relationale Datenbank speichert Daten nicht in einer einzigen großen Tabelle, sondern verteilt sie auf mehrere Tabellen, die miteinander in Beziehung stehen.

Diese Beziehungen (englisch: Relations) sind das zentrale Konzept. Tabellen werden über gemeinsame Werte miteinander verknüpft.

Note
Der Begriff "relational" kommt aus der Mathematik, genauer aus der Mengenlehre. Für uns ist wichtig: Es geht um Beziehungen zwischen Tabellen.

Das Problem: Eine große Tabelle

Stell dir einen Online-Buchladen vor. Du könntest alle Informationen in einer einzigen Tabelle speichern:

Alle Daten in einer Tabelle (schlechtes Design)
BestellNrKundenNameKundenEmailKundenStadtBuchTitelBuchAutorBuchPreis
1001Anna Mülleranna@beispiel.deBerlinDer ProzessFranz Kafka12.99
1002Anna Mülleranna@beispiel.deBerlin1984George Orwell14.99
1003Tom Schmidttom@beispiel.deHamburgDer ProzessFranz Kafka12.99

Auf den ersten Blick funktioniert das. Aber es gibt massive Probleme:

Problem 1: Datenduplikation

Anna Müllers Daten (Name, Email, Stadt) stehen zweimal in der Tabelle. Bei 100 Bestellungen von Anna stehen ihre Daten 100-mal drin. Das verschwendet Speicherplatz.

Problem 2: Inkonsistenz

Anna zieht nach München. Du musst ihre Stadt in allen Zeilen ändern. Vergisst du eine Zeile, hast du inkonsistente Daten: Annas Bestellungen zeigen unterschiedliche Städte.

Problem 3: Verschwendung

Das Buch "Der Prozess" erscheint zweimal mit allen Details. Bei 1000 Verkäufen des Buches stehen Titel, Autor und Preis 1000-mal in der Datenbank.

Problem 4: Preisänderung

Der Buchpreis ändert sich. Du müsstest alle Zeilen mit diesem Buch finden und aktualisieren. Sehr fehleranfällig.

Die Lösung: Mehrere verknüpfte Tabellen

Eine relationale Datenbank löst diese Probleme, indem sie die Daten auf mehrere Tabellen verteilt:

Tabelle 1: Kunden

Kunden-Tabelle
KundenIDNameEmailStadt
1Anna Mülleranna@beispiel.deBerlin
2Tom Schmidttom@beispiel.deHamburg

Jeder Kunde erscheint genau einmal. Die KundenID ist eindeutig.

Tabelle 2: Bücher

Bücher-Tabelle
BuchIDTitelAutorPreis
1Der ProzessFranz Kafka12.99
21984George Orwell14.99

Jedes Buch erscheint genau einmal. Die BuchID ist eindeutig.

Tabelle 3: Bestellungen

Bestellungen-Tabelle
BestellNrKundenIDBuchIDDatum
1001112024-01-15
1002122024-01-20
1003212024-01-22

Die Bestellungen-Tabelle speichert nur noch die IDs. Sie verknüpft Kunden mit Büchern.

Important
Bestellnr 1001 bedeutet: Kunde mit ID 1 (Anna) hat Buch mit ID 1 (Der Prozess) bestellt. Die Details zu Anna und dem Buch stehen in den anderen Tabellen.

Primärschlüssel und Fremdschlüssel

Um Tabellen zu verknüpfen, nutzen relationale Datenbanken zwei wichtige Konzepte:

Primärschlüssel (Primary Key)

Ein Primärschlüssel ist eine Spalte, die jeden Datensatz eindeutig identifiziert.

  • In der Kunden-Tabelle: KundenID
  • In der Bücher-Tabelle: BuchID
  • In der Bestellungen-Tabelle: BestellNr

Jeder Wert im Primärschlüssel muss einzigartig sein. Keine zwei Kunden haben die gleiche KundenID.

Fremdschlüssel (Foreign Key)

Ein Fremdschlüssel ist eine Spalte, die auf den Primärschlüssel einer anderen Tabelle verweist.

  • In der Bestellungen-Tabelle: KundenID verweist auf die Kunden-Tabelle
  • In der Bestellungen-Tabelle: BuchID verweist auf die Bücher-Tabelle

Der Fremdschlüssel stellt die Beziehung her. Er sagt: "Diese Bestellung gehört zu diesem Kunden und diesem Buch."

Tip
Merke: Der Primärschlüssel identifiziert einen Datensatz. Der Fremdschlüssel verknüpft Datensätze aus verschiedenen Tabellen.

Vorteile relationaler Datenbanken

Durch die Aufteilung auf mehrere Tabellen gewinnen wir:

1. Keine Duplikate

Anna Müllers Daten stehen nur einmal in der Kunden-Tabelle. Egal wie viele Bestellungen sie hat.

2. Konsistenz

Anna zieht um? Du änderst ihre Stadt an einer Stelle in der Kunden-Tabelle. Alle Bestellungen zeigen automatisch die neue Stadt, weil sie über die KundenID verknüpft sind.

3. Einfache Änderungen

Der Buchpreis ändert sich? Du aktualisierst ihn in der Bücher-Tabelle. Fertig. Du musst nicht tausende Bestellungen durchgehen.

4. Speicherplatz

Statt Annas vollständige Daten bei jeder Bestellung zu speichern, speicherst du nur ihre ID (eine kleine Zahl). Das spart massiv Platz.

5. Flexibilität

Du kannst neue Tabellen hinzufügen ohne bestehende zu ändern. Willst du Bewertungen speichern? Erstelle eine Bewertungen-Tabelle und verknüpfe sie mit Büchern und Kunden.

Redundanzfreiheit als Ziel

All diese Vorteile lassen sich in einem Fachbegriff zusammenfassen: Redundanzfreiheit.

Redundanz bedeutet "Überflüssigkeit" oder "unnötige Wiederholung". In Datenbanken bedeutet Redundanz, dass die gleiche Information mehrfach gespeichert wird.

Beispiel für Redundanz

In der schlechten Tabelle vom Anfang:

  • Annas Name, Email und Stadt stehen bei jeder ihrer Bestellungen
  • Das Buch "Der Prozess" mit Autor und Preis steht bei jedem Verkauf

Das ist redundant – die gleiche Information wird unnötig oft wiederholt.

Warum ist Redundanz problematisch?

  • Speicherplatz: Dieselben Daten werden tausendfach gespeichert
  • Inkonsistenz: Wenn Anna umzieht, müssen alle Kopien aktualisiert werden – vergisst du eine, hast du widersprüchliche Daten
  • Wartungsaufwand: Jede Änderung muss an vielen Stellen vorgenommen werden

Relationale Datenbanken erreichen Redundanzfreiheit, indem sie:

  1. Jede Information nur einmal speichern
  2. Tabellen über Schlüssel (IDs) verknüpfen
  3. Bei Bedarf Daten über JOINs zusammenführen
Tip
Redundanzfreiheit ist ein Grundprinzip guter Datenbank-Designs. Später lernst du die Normalformen kennen – systematische Regeln, um Redundanz zu vermeiden.

Wie werden Tabellen verknüpft?

Um Daten aus mehreren Tabellen zusammen abzufragen, nutzt du SQL-Befehle wie JOIN. Beispiel:

SQL
SELECT Kunden.Name, Buecher.Titel
FROM Bestellungen
JOIN Kunden ON Bestellungen.KundenID = Kunden.KundenID
JOIN Buecher ON Bestellungen.BuchID = Buecher.BuchID;

Diese Abfrage holt:

  • Den Kundennamen aus der Kunden-Tabelle
  • Den Buchtitel aus der Bücher-Tabelle
  • Verknüpft über die Bestellungen-Tabelle

Ergebnis:

NameTitel
Anna MüllerDer Prozess
Anna Müller1984
Tom SchmidtDer Prozess
Note
Mach dir keine Sorgen, wenn du JOIN noch nicht verstehst. Du lernst es später in der Serie. Wichtig ist jetzt: Die Datenbank kann Daten aus verschiedenen Tabellen zusammenführen.

Relational vs. NoSQL

Der Unterschied zu NoSQL wird jetzt klarer:

Relationale Datenbank (SQL)

  • Daten in mehreren Tabellen
  • Verknüpfung über Schlüssel
  • Keine Duplikate durch Normalisierung
  • JOIN kombiniert Tabellen bei Bedarf

NoSQL (z.B. MongoDB)

  • Alle Daten oft in einem Dokument
  • Keine Verknüpfungen nötig
  • Duplikate sind akzeptiert
  • Schneller Zugriff auf komplette Dokumente

Beide Ansätze haben Vor- und Nachteile. Relationale Datenbanken sind ideal, wenn Daten stark verknüpft sind und Konsistenz wichtig ist.

Die drei Säulen relationaler Datenbanken

Zusammengefasst basieren relationale Datenbanken auf drei Konzepten:

  1. Tabellen: Daten werden in strukturierten Tabellen gespeichert
  2. Beziehungen: Tabellen werden über Schlüssel verknüpft
  3. Integrität: Regeln stellen sicher, dass Verknüpfungen gültig bleiben

Diese drei Prinzipien machen relationale Datenbanken so mächtig und zuverlässig.

Zusammenfassung

Relationale Datenbanken heißen so, weil sie auf Beziehungen zwischen Tabellen basieren:

  • Daten werden auf mehrere Tabellen verteilt statt in einer großen Tabelle
  • Primärschlüssel identifizieren Datensätze eindeutig
  • Fremdschlüssel verknüpfen Tabellen miteinander
  • Das vermeidet Duplikate und sorgt für Konsistenz
  • JOIN-Befehle kombinieren Daten aus mehreren Tabellen

In den nächsten Artikeln lernst du Schritt für Schritt, wie du eine relationale Datenbank planst: Vom Erkennen der Entities bis zum fertigen Datenbankschema.