3 Relationale Datenbanken

3.1 Eine Einführung

Relationale Datenbanken sind heute der am weitesten verbreitete Datenbanktyp. Sie basieren auf dem von E.F. Codd in den 1970er Jahren entwickelten relationalen Modell, das Daten in Tabellen organisiert und diese über Beziehungen (Relationen) miteinander verknüpft.

3.1.1 Abgrenzung zu anderen Datenbanken

Im Vergleich zu anderen Datenbanktypen zeichnen sich relationale Datenbanken durch folgende Merkmale aus:

Tabellenstruktur: Alle Daten werden in Tabellen gespeichert, die aus Zeilen (Datensätze) und Spalten (Attribute) bestehen.
Beziehungen: Tabellen können über Schlüssel miteinander verknüpft werden, um Beziehungen zwischen den Daten herzustellen.
Standardisierte Abfragesprache: Mit SQL (Structured Query Language) gibt es eine einheitliche Sprache zur Definition, Manipulation und Abfrage von Daten.
ACID-Eigenschaften: Relationale Datenbanken gewährleisten die Datenkonsistenz durch die Einhaltung der ACID-Eigenschaften (Atomicity, Consistency, Isolation, Durability).
Schema: Die Struktur der Daten wird in einem Schema festgelegt, das die Tabellen, Spalten und Beziehungen definiert.

Im Gegensatz dazu gibt es andere Datenbanktypen wie:

NoSQL-Datenbanken: Diese haben ein flexibleres Datenmodell und sind oft schemafrei, was die Speicherung unstrukturierter Daten erleichtert.
Objektdatenbanken: Diese sind speziell auf die Speicherung von komplexen Objekten und deren Beziehungen ausgelegt.
Hierarchische Datenbanken: Hier werden die Daten in einer baumartigen Struktur organisiert.
Netzwerkdatenbanken: Die Daten werden hier über Pointer miteinander verknüpft.

3.1.2 Tabelle, Zeile und Spalte

In einer relationalen Datenbank werden alle Daten in Tabellen organisiert. Eine Tabelle besteht aus Zeilen (auch Datensätze oder Tupel genannt) und Spalten (auch Attribute oder Felder genannt).

Beispiel einer Kundentabelle:

+----+-----------+------------+---------+
| ID | Vorname   | Nachname   | Ort     |
+----+-----------+------------+---------+
| 1  | Max       | Mustermann | Berlin  |
| 2  | Erika     | Musterfrau | Hamburg |
| 3  | Hans      | Schmidt    | München |
+----+-----------+------------+---------+

Wichtige Eigenschaften von Tabellen sind:

Jede Spalte hat einen eindeutigen Namen, der die Art der darin enthaltenen Daten beschreibt.
Jede Spalte hat einen festgelegten Datentyp (z.B. Integer, String, Date), der den Wertebereich einschränkt.
Die Reihenfolge der Zeilen ist nicht relevant, da sie über Schlüssel eindeutig identifiziert werden.
Jede Zeile muss eindeutig identifizierbar sein, meist über einen Primärschlüssel.

3.1.3 Schlüssel, Primärschlüssel und Fremdschlüssel

Schlüssel sind ein zentrales Konzept in relationalen Datenbanken. Sie dienen der eindeutigen Identifizierung von Datensätzen und der Verknüpfung von Tabellen.

Primärschlüssel:

Ein Primärschlüssel ist ein Attribut oder eine Kombination von Attributen, das einen Datensatz eindeutig identifiziert.
Er muss eindeutig sein, d.h. kein Wert darf mehrfach vorkommen.
Er darf keine NULL-Werte (fehlende Werte) enthalten.
Oft verwendet man eine künstliche ID-Spalte als Primärschlüssel.
Ein Primärschlüssel kann auch aus mehreren Spalten bestehen (zusammengesetzter Primärschlüssel).

Beispiel für die Definition eines Primärschlüssels in SQL:

CREATE TABLE Kunden (
    KundenID INT PRIMARY KEY,
    Vorname VARCHAR(50),
    Nachname VARCHAR(50)
);

Fremdschlüssel:

Ein Fremdschlüssel ist ein Attribut oder eine Kombination von Attributen, das auf den Primärschlüssel einer anderen (oder derselben) Tabelle verweist.
Er stellt eine Beziehung zwischen zwei Tabellen her.
Ein Fremdschlüssel kann NULL-Werte enthalten, wenn die Beziehung optional ist.
Fremdschlüssel sichern die referentielle Integrität, d.h. sie stellen sicher, dass keine ungültigen Beziehungen entstehen.

Beispiel für die Definition eines Fremdschlüssels in SQL:

CREATE TABLE Bestellungen (
    BestellID INT PRIMARY KEY,
    KundenID INT,
    Datum DATE,
    FOREIGN KEY (KundenID) REFERENCES Kunden(KundenID)
);

3.1.4 Kardinalitäten und ER-Modell

Kardinalitäten beschreiben die Art und die Anzahl der Beziehungen zwischen Tabellen. Sie geben an, wie viele Datensätze der einen Tabelle mit wie vielen Datensätzen der anderen Tabelle verknüpft sein können.

Man unterscheidet folgende Kardinalitäten:

3.1.4.1 1:1-Beziehung

Eine 1:1-Beziehung liegt vor, wenn ein Datensatz der ersten Tabelle mit maximal einem Datensatz der zweiten Tabelle verknüpft ist und umgekehrt.

Beispiel: Ein Mitarbeiter hat höchstens einen Firmenwagen, und ein Firmenwagen ist höchstens einem Mitarbeiter zugeordnet.

CREATE TABLE Mitarbeiter (
    MitarbeiterID INT PRIMARY KEY,
    Name VARCHAR(100)
);

CREATE TABLE Firmenwagen (
    WagenID INT PRIMARY KEY,
    Kennzeichen VARCHAR(10),  
    MitarbeiterID INT UNIQUE,
    FOREIGN KEY (MitarbeiterID) REFERENCES Mitarbeiter(MitarbeiterID)
);

Die Kardinalität kann weiter spezifiziert werden:

(1,1):(1,1) - Jeder Datensatz muss verknüpft sein (z.B. jeder Mitarbeiter hat genau einen Ausweis).
(0,1):(0,1) - Die Verknüpfung ist optional (z.B. ein Mitarbeiter kann, muss aber keinen Firmenwagen haben).
(0,1):(1,1) - In einer Richtung ist die Verknüpfung optional, in der anderen zwingend (z.B. ein Firmenwagen gehört immer zu einem Mitarbeiter, aber nicht jeder Mitarbeiter hat einen Firmenwagen).

3.1.4.2 1:n-Beziehung

Eine 1:n-Beziehung liegt vor, wenn ein Datensatz der ersten Tabelle mit mehreren Datensätzen der zweiten Tabelle verknüpft sein kann, aber jeder Datensatz der zweiten Tabelle nur mit maximal einem Datensatz der ersten Tabelle verknüpft ist.

Beispiel: Ein Kunde kann mehrere Bestellungen aufgeben, aber jede Bestellung gehört zu genau einem Kunden.

CREATE TABLE Kunden (
    KundenID INT PRIMARY KEY,
    Name VARCHAR(100)
);

CREATE TABLE Bestellungen (
    BestellID INT PRIMARY KEY,
    KundenID INT,
    Datum DATE,
    FOREIGN KEY (KundenID) REFERENCES Kunden(KundenID)
);

3.1.4.3 n:m-Beziehung

Eine n:m-Beziehung liegt vor, wenn mehrere Datensätze der ersten Tabelle mit mehreren Datensätzen der zweiten Tabelle verknüpft sein können und umgekehrt.

Beispiel: Ein Student kann mehrere Kurse belegen, und ein Kurs kann von mehreren Studenten belegt werden.

In relationalen Datenbanken können n:m-Beziehungen nicht direkt abgebildet werden. Stattdessen verwendet man eine Zwischentabelle, die die Beziehung auflöst:

CREATE TABLE Studenten (
    MatrNr INT PRIMARY KEY,
    Name VARCHAR(100)
);

CREATE TABLE Kurse (
    KursNr INT PRIMARY KEY,
    Titel VARCHAR(100)
);

CREATE TABLE Belegungen (
    MatrNr INT,
    KursNr INT,
    PRIMARY KEY (MatrNr, KursNr),
    FOREIGN KEY (MatrNr) REFERENCES Studenten(MatrNr),  
    FOREIGN KEY (KursNr) REFERENCES Kurse(KursNr)
);

Die Kardinalitäten werden oft in einem ER-Diagramm (Entity-Relationship-Diagramm) visualisiert. Dabei werden Entitäten (Tabellen) als Rechtecke und Beziehungen als Rauten dargestellt, die mit Linien verbunden sind. An den Linien werden die Kardinalitäten notiert.

3.1.5 Referentielle Integrität

Die referentielle Integrität ist ein Konzept, das die Konsistenz zwischen verknüpften Tabellen sicherstellt. Sie garantiert, dass Fremdschlüssel immer auf existierende Primärschlüssel verweisen und dass beim Löschen oder Ändern von referenzierten Datensätzen die Konsistenz gewahrt bleibt.

Das Datenbanksystem überwacht die referentielle Integrität automatisch, wenn Fremdschlüssel definiert sind. Dabei gibt es verschiedene Möglichkeiten, wie sich das System beim Löschen oder Ändern von referenzierten Datensätzen verhalten kann:

Verhalten beim Löschen eines referenzierten Datensatzes:

CASCADE: Löscht auch alle verknüpften Datensätze in der referenzierenden Tabelle.
RESTRICT: Verhindert das Löschen, wenn verknüpfte Datensätze existieren.
SET NULL: Setzt den Fremdschlüssel in den verknüpften Datensätzen auf NULL.
NO ACTION: Verhindert das Löschen, wenn verknüpfte Datensätze existieren (Standardverhalten).

Verhalten beim Ändern eines referenzierten Schlüssels:

CASCADE: Ändert auch den Fremdschlüssel in allen verknüpften Datensätzen.
RESTRICT: Verhindert die Änderung, wenn verknüpfte Datensätze existieren.
SET NULL: Setzt den Fremdschlüssel in den verknüpften Datensätzen auf NULL.
NO ACTION: Verhindert die Änderung, wenn verknüpfte Datensätze existieren (Standardverhalten).

Das gewünschte Verhalten kann bei der Definition des Fremdschlüssels festgelegt werden, z.B.:

CREATE TABLE Bestellungen (
    BestellID INT PRIMARY KEY,
    KundenID INT,
    Datum DATE,
    FOREIGN KEY (KundenID) REFERENCES Kunden(KundenID) ON DELETE CASCADE ON UPDATE CASCADE
);

3.1.6 Normalisierung und Normalformen

Die Normalisierung ist ein Prozess, bei dem eine Datenbank in eine strukturierte Form gebracht wird, die Redundanz und Inkonsistenz vermeidet. Dazu werden die Daten in mehrere Tabellen aufgeteilt, die über Beziehungen miteinander verknüpft sind.

Die Normalisierung folgt bestimmten Regeln, den sogenannten Normalformen. Die wichtigsten sind:

3.1.6.1 Erste Normalform (1NF)

Jede Spalte enthält nur atomare Werte (keine Listen oder zusammengesetzte Werte).
Es gibt keine Wiederholungsgruppen (keine Spalten mit gleichem Inhalt).
Jede Spalte hat einen eindeutigen Namen.
Die Reihenfolge der Zeilen ist irrelevant.

Beispiel für eine Tabelle, die nicht in 1NF ist:

+----+------------------+---------------------------+
| ID | Name             | Telefonnummern            |
+----+------------------+---------------------------+
| 1  | Max Mustermann   | 030-1234567, 0171-1234567 |
| 2  | Erika Musterfrau | 040-7654321               |
+----+------------------+---------------------------+

In der ersten Normalform sieht die Tabelle so aus:

+----+------------------+--------------+
| ID | Name             | Telefon      |
+----+------------------+--------------+
| 1  | Max Mustermann   | 030-1234567  |
| 1  | Max Mustermann   | 0171-1234567 |
| 2  | Erika Musterfrau | 040-7654321  |
+----+------------------+--------------+

3.1.6.2 Zweite Normalform (2NF)

Die Tabelle ist in der ersten Normalform.
Jedes Nicht-Schlüssel-Attribut hängt vom ganzen Primärschlüssel ab, nicht nur von einem Teil.

3.1.6.3 Dritte Normalform (3NF)

Die Tabelle ist in der zweiten Normalform.
Es gibt keine transitiven Abhängigkeiten zwischen Nicht-Schlüssel-Attributen.

Die Normalformen bauen aufeinander auf, d.h. eine Tabelle in 3NF ist automatisch auch in 2NF und 1NF.

Ziel der Normalisierung ist es, Anomalien bei Einfüge-, Lösch- und Änderungsoperationen zu vermeiden, die Datenintegrität zu wahren und Redundanzen zu minimieren. Allerdings kann eine zu starke Normalisierung auch zu komplexen Abfragen und Performanzeinbußen führen. In der Praxis wird meist ein Kompromiss zwischen Normalität und Effizienz angestrebt, oft die 3NF.