Datenbanken

Relationales Datenmodell

Eine relationale Datenbank speichert Daten in Tabellen (Relationen). Jede Tabelle besteht aus Zeilen (Datensätze/Tupel) und Spalten (Attribute/Felder). Jede Spalte hat einen festen Datentyp, der bestimmt, welche Werte gespeichert werden dürfen.

Wichtige Datentypen, die dir in der Prüfung begegnen:

• INT / INTEGER — ganze Zahlen
• DECIMAL(m,n) / FLOAT — Kommazahlen (z. B. Preise)
• VARCHAR(n) — Zeichenketten variabler Länge
• CHAR(n) — Zeichenketten fester Länge
• DATE / DATETIME — Datum bzw. Datum mit Uhrzeit
• BOOLEAN — Wahrheitswert (0/1)

Ziel des relationalen Modells: Daten redundanzarm, konsistent und in Beziehung zueinander abzulegen, statt sie in einer einzigen unübersichtlichen Tabelle zu sammeln.

ER-Modell & Kardinalitäten

Das Entity-Relationship-Modell (ER-Modell) beschreibt die reale Welt vor der technischen Umsetzung. Es besteht aus drei Grundbausteinen:

• Entität — ein eindeutig identifizierbares Objekt (z. B. Kunde, Bestellung, Artikel)
• Attribut — eine Eigenschaft einer Entität (z. B. Kundenname, Bestelldatum)
• Beziehung (Relationship) — eine Verbindung zwischen zwei Entitäten (z. B. "Kunde tätigt Bestellung")

Kardinalitäten

Die Kardinalität gibt an, wie viele Instanzen einer Entität mit wie vielen Instanzen einer anderen Entität in Beziehung stehen können:

• 1:1 — genau eine Entität A gehört zu genau einer Entität B (z. B. Mitarbeiter — Dienstausweis)
• 1:n — eine Entität A kann zu mehreren Entitäten B gehören, umgekehrt aber nur zu einer (z. B. Kunde — Bestellung: ein Kunde hat mehrere Bestellungen, jede Bestellung gehört zu genau einem Kunden)
• n:m — mehrere Entitäten A gehören zu mehreren Entitäten B (z. B. Bestellung — Artikel: eine Bestellung enthält mehrere Artikel, ein Artikel kommt in mehreren Bestellungen vor)

Beispiel: Kunde und Bestellung

Ein Kunde (Kunde) kann mehrere Bestellungen (Bestellung) aufgeben, eine Bestellung gehört aber immer zu genau einem Kunden. Das ist eine 1:n-Beziehung. Umgesetzt wird das, indem die Tabelle Bestellung eine Spalte kunden_id erhält, die auf den Primärschlüssel der Tabelle Kunde verweist (Fremdschlüssel). Enthält eine Bestellung mehrere Artikel und ein Artikel taucht in mehreren Bestellungen auf, entsteht eine n:m-Beziehung zwischen Bestellung und Artikel, die durch eine zusätzliche Verknüpfungstabelle (z. B. Bestellposition mit bestellung_id, artikel_id, menge) aufgelöst wird.

Normalisierung

Normalisierung reduziert Redundanzen und vermeidet Anomalien (Einfüge-, Änderungs-, Löschanomalien) durch schrittweise Aufteilung von Tabellen.

1. Normalform (1NF)

Kernkriterium: Jedes Attribut enthält nur atomare (unteilbare) Werte, keine Wiederholungsgruppen.

Verletzung: Eine Spalte Telefonnummern mit Wert "0221-123, 0221-456". Auflösung: Auslagern in eine eigene Tabelle Telefonnummer mit Fremdschlüssel auf den Kunden, sodass jede Zeile nur eine Nummer enthält.

2. Normalform (2NF)

Kernkriterium: Tabelle erfüllt die 1NF, und jedes Nicht-Schlüsselattribut ist voll funktional abhängig vom gesamten Primärschlüssel (relevant bei zusammengesetzten Schlüsseln).

Verletzung: Tabelle Bestellposition(bestellung_id, artikel_id, artikel_bezeichnung, menge) — artikel_bezeichnung hängt nur von artikel_id ab, nicht vom gesamten Schlüssel. Auflösung: artikel_bezeichnung in eine eigene Tabelle Artikel(artikel_id, artikel_bezeichnung) auslagern.

3. Normalform (3NF)

Kernkriterium: Tabelle erfüllt die 2NF, und es gibt keine transitiven Abhängigkeiten (kein Nicht-Schlüsselattribut hängt von einem anderen Nicht-Schlüsselattribut ab).

Verletzung: Tabelle Kunde(kunden_id, plz, ort) — ort hängt von plz ab, nicht direkt vom Schlüssel kunden_id. Auflösung: Auslagern in eine Tabelle PLZ(plz, ort), in Kunde bleibt nur die plz als Fremdschlüssel.

Primär- und Fremdschlüssel

Der Primärschlüssel (Primary Key) identifiziert jeden Datensatz einer Tabelle eindeutig. Er darf nicht NULL sein und muss pro Tabelle eindeutig sein (z. B. kunden_id).

Der Fremdschlüssel (Foreign Key) ist eine Spalte, die auf den Primärschlüssel einer anderen Tabelle verweist und so Beziehungen zwischen Tabellen herstellt (z. B. kunden_id in der Tabelle Bestellung).

Referenzielle Integrität bedeutet: Ein Fremdschlüsselwert muss entweder NULL sein oder auf einen tatsächlich existierenden Primärschlüsselwert verweisen. Das Datenbanksystem verhindert z. B., dass eine Bestellung auf einen nicht existierenden Kunden zeigt, oder dass ein Kunde gelöscht wird, solange noch Bestellungen auf ihn verweisen (je nach ON DELETE-Regel wie CASCADE, RESTRICT oder SET NULL).

SQL-Grundlagen

SELECT, WHERE, ORDER BY, GROUP BY, HAVING

• SELECT name, ort FROM kunde WHERE ort = 'Köln' ORDER BY name ASC; — Spalten auswählen, filtern, sortieren
• SELECT ort, COUNT(*) FROM kunde GROUP BY ort HAVING COUNT(*) > 5; — Gruppieren und Gruppen filtern

Wichtig: WHERE filtert einzelne Zeilen vor der Gruppierung, HAVING filtert Gruppen nach der Gruppierung (z. B. mit Aggregatfunktionen wie COUNT(), SUM(), AVG()).

INSERT, UPDATE, DELETE

• INSERT INTO kunde (name, ort) VALUES ('Müller', 'Köln'); — neuen Datensatz einfügen
• UPDATE kunde SET ort = 'Bonn' WHERE kunden_id = 3; — Datensatz ändern
• DELETE FROM kunde WHERE kunden_id = 3; — Datensatz löschen

JOIN-Typen

• INNER JOIN — liefert nur Zeilen, bei denen es in beiden Tabellen einen passenden Datensatz gibt.
• LEFT JOIN — liefert alle Zeilen der linken Tabelle, auch wenn es keinen passenden Datensatz in der rechten Tabelle gibt (fehlende Werte werden mit NULL aufgefüllt).
• RIGHT JOIN — analog zu LEFT JOIN, aber mit allen Zeilen der rechten Tabelle.

Beispiel: SELECT k.name, b.datum FROM kunde k LEFT JOIN bestellung b ON k.kunden_id = b.kunden_id; liefert alle Kunden, auch solche ohne Bestellung — bei ihnen steht dann NULL im Feld datum.

Transaktionen: ACID

Eine Transaktion fasst mehrere Datenbankoperationen zu einer logischen Einheit zusammen, die entweder komplett oder gar nicht ausgeführt wird. Das ACID-Prinzip beschreibt die Eigenschaften, die eine Transaktion garantieren muss:

• Atomicity (Atomarität): Eine Transaktion wird vollständig ausgeführt oder komplett zurückgerollt (ROLLBACK) — es gibt keinen halb fertigen Zustand.
• Consistency (Konsistenz): Die Datenbank befindet sich vor und nach der Transaktion in einem gültigen Zustand (alle Integritätsregeln sind erfüllt).
• Isolation (Isolierung): Parallel laufende Transaktionen beeinflussen sich nicht gegenseitig, als würden sie nacheinander ausgeführt.
• Durability (Dauerhaftigkeit): Einmal mit COMMIT bestätigte Änderungen bleiben auch nach einem Systemausfall dauerhaft gespeichert.

Klassisches Beispiel: eine Überweisung zwischen zwei Konten. Abbuchung beim einen und Gutschrift beim anderen Konto müssen als eine Transaktion behandelt werden — schlägt ein Schritt fehl, wird die gesamte Transaktion per ROLLBACK rückgängig gemacht, damit kein Geld "verschwindet".