Relationales Datenmodell

Vor langer Zeit, als die Dinosaurier noch groß waren... naja, genauer gesagt im Jahr 1970, hat ein Typ namens Edgar Codd beschlossen, dass das Daten-Chaos schon längst kein kreatives Durcheinander mehr ist, sondern eher ein schwarzes Loch, das Zeit und Ressourcen schluckt. Edgar hat lange gegrübelt und sich einen Weg ausgedacht, wie man alles ordnen kann – und dabei gleich das Fundament für eine ganze Welt gelegt, in der Daten in ordentliche Tabellen gepackt werden, wie Bücher im Regal einer perfekten Bibliothek. Zeilen, Spalten, Ordnung – und kein „passt schon“ oder „ist doch eh klar“ mehr.

Das relationale Modell basiert darauf, Daten als Tabellen darzustellen, wobei jede Tabelle aus Zeilen und Spalten besteht. Das ist ziemlich intuitiv: Zeilen sind Datensätze, Spalten sind Eigenschaften oder Attribute des Datensatzes. So wird das Arbeiten und Manipulieren mit Daten viel einfacher.

Stell dir vor, du bestellst was in einem Online-Shop. Damit deine Bestellung erfolgreich bearbeitet und geliefert wird, muss das System viele Details berücksichtigen: Wer bist du (Kunde), welchen Lieferservice hast du gewählt, wohin soll geliefert werden und wie kann man den Status des Pakets verfolgen.

Wenn all diese Infos in einer riesigen Tabelle gespeichert wären, gäbe es totales Chaos: Daten würden sich ständig wiederholen, Updates wären schwierig und das schnelle Finden von Infos wäre noch schlimmer. Der relationale Ansatz bringt Ordnung rein, indem er die Infos auf verschiedene Tabellen verteilt, die miteinander kommunizieren können.

Auf diesem Schema siehst du ein Beispiel, wie Daten für das Tracking von Lieferungen organisiert werden können:

• Kunden – hier werden Infos zu jedem Kunden gespeichert – mit einer einzigartigen Kundennummer.
• Lieferservices – diese Tabelle enthält eine Liste der Services, die liefern können, mit ihrer eigenen Servicenummer.
• Lieferung der Bestellung – das ist die zentrale, verbindende Tabelle. Jede Zeile steht für eine konkrete Lieferung. Sie hat ihre eigene Liefernummer und verweist auf den Kunden, den Lieferservice, eventuell auf die Bestellung, das Datum und den aktuellen Status.

Pfeile zeigen, wie Einträge aus der Tabelle Lieferung der Bestellung mit Einträgen in den Tabellen Kunden und Lieferservices verbunden sind.

Ein Beispiel für die Tabelle Lieferung der Bestellung:

Vorteile von diesem Ansatz:

• Infos zu Kunden oder Lieferservices werden nur einmal gespeichert, so gibt’s keine Wiederholungen in jedem einzelnen Lieferdatensatz.
• Verknüpfungen über eindeutige Nummern (auch Keys genannt) sorgen dafür, dass es z.B. keine Lieferungen ohne existierenden Kunden oder Service gibt.
• Man kann Daten aus verschiedenen Tabellen easy kombinieren, um komplexe Reports oder gezielte Abfragen zu machen.
• Änderungen werden an einer Stelle gemacht und sind sofort für alle verknüpften Aktionen sichtbar (z.B. Telefonnummer vom Lieferservice).

Struktur einer relationalen Datenbank

Das Herzstück einer relationalen Datenbank sind Tabellen. Jede Tabelle hat:

• Einen Namen (Table Name), damit wir sie identifizieren können – zum Beispiel customers.
• Eine Menge von Spalten (Columns/Attributes), die die Eigenschaften des Objekts definieren.
  • Beim Benennen von Spalten, die als eindeutige Nummern (Primärschlüssel) dienen, nimmt man oft das Muster name_id. Das Suffix _id steht hier für "identifier". Beispiel: Kundennummer wird zu customer_id.
  • Zum Beispiel für die Tabelle customers: Das könnten customer_id, first_name, email usw. sein.
• Daten in Zeilen (Rows/Records) – eine Zeile in der Tabelle customers enthält alle Infos zu einem bestimmten Kunden (101, Alex Song usw.).

Schauen wir uns ein Beispiel für die Tabelle customers an:

Tabellen-Keys

Um jede Zeile in einer Tabelle eindeutig zu bestimmen, gibt es den Primärschlüssel (Primary Key, PK). Das ist eine Spalte (oder mehrere), deren Werte für jede Zeile einzigartig und niemals leer sind. Stell dir das wie eine eindeutige Nummer für jeden Datensatz vor, z.B. customer_id in unserer customers-Tabelle: Damit kann man jeden Kunden eindeutig identifizieren.

Der Primärschlüssel ist wie ein Ausweis, genauer gesagt wie die Ausweisnummer: Sie ist für jedes Objekt einzigartig. So gibt’s keine Probleme mit gleichnamigen Zeilen.

Um Beziehungen zwischen Tabellen herzustellen, nutzt man den Fremdschlüssel (Foreign Key, FK). Das ist eine Spalte in einer Tabelle, die auf den Primärschlüssel einer anderen Tabelle verweist. Fremdschlüssel sind die „Brücken“ zwischen Tabellen. Oft heißt die Fremdschlüssel-Spalte genauso wie der Primärschlüssel, auf den sie verweist. Zum Beispiel ist in der Tabelle deliveries die Spalte customer_id ein Fremdschlüssel, der Werte aus der Spalte customer_id der Tabelle customers speichert – so wird die Lieferung mit dem Kunden verknüpft.

Das ist das bekannte Schema, aber jetzt sieht es schon realistischer aus.

• Die Tabelle customers enthält Infos zu Kunden; ihr Primärschlüssel ist customer_id.
• Die Tabelle delivery_services speichert Daten zu Lieferservices; ihr Primärschlüssel ist service_id.
• Die Tabelle orders (nur der Vollständigkeit halber, weil order_id aus der Liefer-Tabelle darauf verweist) ist für Bestellinfos da, mit dem Primärschlüssel order_id.
• Die Tabelle deliveries ist die zentrale für das Tracking von Lieferungen. Sie hat:
  • Ihren eigenen Primärschlüssel: delivery_id.
  • Drei Fremdschlüssel für die Verknüpfungen:
    • customer_id (FK): verbindet die Lieferung mit einem bestimmten Kunden aus customers.
    • service_id (FK): verbindet die Lieferung mit dem gewählten Service aus delivery_services.
    • order_id (FK): verbindet die Lieferung mit der passenden Bestellung aus orders.
  • Das Feld created_date zeigt das Erstellungsdatum und die Uhrzeit des Lieferdatensatzes an.

So ein Einsatz von Primär- und Fremdschlüsseln sorgt für Datenintegrität. Das System lässt dich keinen Lieferdatensatz anlegen, wenn der angegebene customer_id oder order_id nicht in den jeweiligen Tabellen existiert – und du kannst flexibel verknüpfte Infos abrufen.

Vorteile des relationalen Modells

Das relationale Modell hat einige starke Vorteile, die es zum Leader unter den Datenbank-Ansätzen machen:

1. Einfache Struktur. Tabellen mit Spalten und Zeilen sind verständlich und simpel.
2. Flexibilität beim Umgang mit Daten. Neue Daten hinzufügen oder ändern geht easy, ohne dass die Integrität leidet.
3. Unterstützung für komplexe Abfragen. Mit SQL kannst du Daten aus vielen Tabellen holen, kombinieren, filtern und eigentlich alles machen, was deine Aufgabe verlangt. Zum Beispiel: Alle Studenten finden, die in einem bestimmten Kurs eingeschrieben sind – easy!
4. Datenintegrität durch Keys. Primär- und Fremdschlüssel sorgen dafür, dass die Daten konsistent bleiben. Du kannst z.B. keinen Studenten für einen Kurs eintragen, wenn es diesen Kurs gar nicht gibt.

Das relationale Datenmodell ist das Fundament moderner Datenbanken. Es ist einfach, mächtig und perfekt für strukturierte Daten. Wie Edgar Codd gesagt hat: „Ordne oder stirb!“ (okay, er hat’s ein bisschen anders formuliert, aber das war ungefähr der Sinn...). In der nächsten Vorlesung schauen wir uns an, wie sich das relationale Modell von anderen Datenbanktypen (wie NoSQL) unterscheidet und wo man was besser einsetzt.