Datenbanken — Strukturiert speichern und abfragen

Einführung

Jede App, jede Website, fast jede Software hat im Hintergrund eine Datenbank. Spotify speichert Millionen Songs und ihre Metadaten. Amazon verwaltet Millionen Bestellungen. Deine Schule hat eine Datenbank mit Schülern, Kursen und Noten.

Aber warum nicht einfach Dateien? Warum nicht eine Excel-Tabelle für alles?

Bei kleinen Mengen könnte das funktionieren. Aber bei Millionen Einträgen, gleichzeitigen Zugriffen von tausend Nutzern, und der Anforderung, dass keine Daten verloren gehen — da braucht man ein System, das dafür gebaut wurde: eine Datenbank mit einem Datenbankmanagementsystem (DBMS).

Grundidee

Eine Datenbank organisiert Daten strukturiert und ermöglicht:

Schnelles Finden spezifischer Daten (Abfragen)
Gleichzeitigen Zugriff vieler Nutzer ohne Konflikte
Sicherheit gegen Datenverlust (Transaktionen)
Konsistenz (keine widersprüchlichen Daten)

Das meistverbreitete Modell ist das relationale Modell: Daten werden in Tabellen gespeichert, die durch Schlüssel miteinander verbunden sind.

Erklärung

Das relationale Modell

Eine relationale Datenbank besteht aus Tabellen (auch: Relationen). Jede Tabelle hat:

Spalten (Attribute): Die Art der Daten (z. B. Name, Alter, Email).
Zeilen (Tupel): Einzelne Datensätze (z. B. ein Nutzer).

Beispiel: Tabelle Schueler

ID	Name	Klasse	Geburtsjahr
1	Anna Meier	11a	2007
2	Tom Braun	12b	2006
3	Lisa Schmidt	11a	2007

Primärschlüssel und Fremdschlüssel

Der Primärschlüssel (Primary Key) ist ein eindeutiges Feld in einer Tabelle, das jeden Datensatz identifiziert. In der Tabelle Schueler ist ID der Primärschlüssel — keine zwei Schüler haben dieselbe ID.

Der Fremdschlüssel (Foreign Key) ist ein Feld in einer Tabelle, das auf den Primärschlüssel einer anderen Tabelle verweist. Damit werden Tabellen verknüpft.

Beispiel: Tabelle Noten

NoteID	SchuelerID	Fach	Note
1	1	Mathematik	2
2	1	Deutsch	3
3	2	Mathematik	1

SchuelerID in Noten ist ein Fremdschlüssel, der auf ID in Schueler verweist. So weiß die Datenbank: Note 1 gehört zu Anna Meier.

SQL: Structured Query Language

SQL ist die Sprache, mit der man mit relationalen Datenbanken kommuniziert.

SELECT — Daten abfragen:

SELECT Name, Klasse
FROM Schueler
WHERE Klasse = '11a';

Ergebnis: Anna Meier (11a), Lisa Schmidt (11a).

WHERE — filtern:

SELECT Name
FROM Schueler
WHERE Geburtsjahr < 2007;

Ergebnis: Tom Braun.

JOIN — Tabellen verknüpfen: Um die Noten von Anna Meier zu bekommen, muss man die Tabellen Schueler und Noten verbinden:

SELECT Schueler.Name, Noten.Fach, Noten.Note
FROM Schueler
JOIN Noten ON Schueler.ID = Noten.SchuelerID
WHERE Schueler.Name = 'Anna Meier';

Ergebnis: Anna Meier | Mathematik | 2 und Anna Meier | Deutsch | 3.

Der JOIN kombiniert Zeilen beider Tabellen, wenn der Fremdschlüssel dem Primärschlüssel entspricht.

Normalisierung

Normalisierung ist das Prinzip, Redundanz in einer Datenbank zu vermeiden und Konsistenz zu sichern.

Schlechtes Design (nicht normalisiert):

SchuelerID	Name	Fach	Note	LehrerName
1	Anna Meier	Mathematik	2	Dr. Müller
1	Anna Meier	Deutsch	3	Fr. Schmidt

Problem: Wenn Anna Meier ihren Namen ändert, muss man in jeder Zeile aktualisieren. Wenn Dr. Müller die Schule verlässt — wo ist das gespeichert?

Normalisiert: Schüler, Fächer, Lehrer und Noten in eigenen Tabellen, verknüpft durch Fremdschlüssel.

Normalisierung folgt formalen Regeln (1. bis 3. Normalform) — das Ziel ist, jeden Sachverhalt an genau einer Stelle zu speichern.

ACID: Eigenschaften von Transaktionen

Eine Transaktion ist eine Folge von Datenbankoperationen, die als Einheit behandelt wird. Das ACID-Prinzip garantiert:

A — Atomarität: Entweder alle Operationen einer Transaktion werden durchgeführt oder keine. Wenn du Geld überweist (Konto A um 100 € reduzieren, Konto B um 100 € erhöhen) und mitten in der Transaktion der Strom ausfällt — dann wird alles rückgängig gemacht. Das Geld verschwindet nicht einfach.

C — Konsistenz: Die Datenbank bleibt in einem gültigen Zustand. Regeln (z. B. „ein Konto darf nicht negativ werden”) werden nie verletzt.

I — Isolation: Gleichzeitig laufende Transaktionen sehen sich nicht gegenseitig. Sie laufen so ab, als wären sie nacheinander ausgeführt worden.

D — Dauerhaftigkeit: Wenn eine Transaktion abgeschlossen ist, bleiben ihre Änderungen dauerhaft — auch bei Systemabsturz.

NoSQL

Nicht alle Daten passen gut in Tabellen. Für manche Anwendungen gibt es NoSQL-Datenbanken:

Dokumentendatenbanken (MongoDB): Speichern JSON-ähnliche Dokumente. Gut für variable Strukturen.
Key-Value-Stores (Redis): Schnelle Schlüssel-Wert-Paare. Gut für Caches.
Spaltenorientierte DBs (Cassandra): Gut für sehr große Mengen an Schreiboperationen.
Graphdatenbanken (Neo4j): Gut für stark vernetzte Daten (Social Networks).

Wann NoSQL? Bei sehr großen Datenmengen, die horizontal skaliert werden müssen (viele Server), bei flexiblen Schemata, oder wenn ACID weniger wichtig ist als Geschwindigkeit und Skalierbarkeit.

Nachteil: Oft schwächere Konsistenzgarantien, keine standardisierte Abfragesprache.

Beispiel aus dem Alltag

Webshop (Amazon):

Drei Tabellen: Kunden, Bestellungen, Produkte. Ein Kauf ist eine Transaktion: Produkt aus Lager abziehen + Bestellung anlegen + Zahlung buchen — alles atomar. Wenn die Zahlung fehlschlägt, wird die Bestellung nicht angelegt und das Produkt nicht abgezogen.

Schulverwaltung:

Tabellen: Schueler, Kurse, Lehrer, Noten, Stundenplan. JOINs erlauben Abfragen wie „Alle Schüler mit Note unter 4 in Mathematik in der 11. Klasse” — über mehrere Tabellen verknüpft.

Spotify:

Songs, Künstler, Alben, Playlisten, Nutzer — relationale Daten. Empfehlungen, Streaming-Statistiken, Echtzeit-Daten — dafür nutzt Spotify zusätzlich NoSQL-Lösungen. Oft kombinieren große Systeme beide Ansätze.

Anwendung

Entwirf ein einfaches Datenbankschema für eine Schulbibliothek:

Welche Tabellen brauchst du? (Mindestens: Bücher, Ausleihen, Schüler)
Welche Felder hat jede Tabelle? Was ist der Primärschlüssel?
Welche Fremdschlüssel verbinden die Tabellen?
Schreibe eine SQL-Abfrage: „Welche Bücher hat Anna Meier gerade ausgeliehen?”

Typische Fehler

Alles in eine Tabelle: Das führt zu Redundanz und Anomalien. Normalisierung sorgt dafür, dass jeder Sachverhalt einmal gespeichert ist.

Fremdschlüssel ignorieren: Ohne Fremdschlüsselconstraints kann eine Note für einen nicht existierenden Schüler gespeichert werden — die Datenbank bleibt inkonsistent.

Transaktionen vergessen: Wer mehrere Operationen ohne Transaktion ausführt, riskiert inkonsistente Zustände bei Fehlern oder gleichzeitigen Zugriffen.

NoSQL für alles: NoSQL ist keine Verbesserung von SQL — es ist eine Alternative für andere Anwendungsfälle. Für strukturierte, konsistente Daten mit komplexen Beziehungen ist relationales SQL oft besser.

Zusammenfassung

Relationale Datenbanken organisieren Daten in Tabellen, die durch Primär- und Fremdschlüssel verknüpft sind
SQL ermöglicht Abfragen (SELECT, WHERE), Filterung und Tabellenverknüpfung (JOIN)
Normalisierung vermeidet Redundanz und sichert Konsistenz
ACID garantiert Atomarität, Konsistenz, Isolation und Dauerhaftigkeit von Transaktionen
NoSQL-Datenbanken (Dokument, Key-Value, Spalten, Graph) sind Alternativen für spezifische Anwendungsfälle mit anderen Anforderungen
Große Systeme kombinieren oft relationale und NoSQL-Datenbanken je nach Anwendungsfall

Quiz

Frage 1: Was ist der Unterschied zwischen Primärschlüssel und Fremdschlüssel?

Frage 2: Was macht ein JOIN in SQL — und warum braucht man ihn?

Frage 3: Was bedeutet das „A” in ACID — und warum ist es wichtig bei Banküberweisungen?

Frage 4: Wann sollte man NoSQL statt einer relationalen Datenbank verwenden?