Relationale Datenbanken

Tabellen, Schlüssel, Beziehungen

Ein kleiner Online-Shop: Kunden geben Bestellungen auf, eine Bestellung enthält mehrere Positionen, jede Position verweist auf einen Artikel.

Warum die Daten auf mehrere Tabellen verteilt werden, statt Name und E-Mail des Kunden in jede Bestellung zu schreiben? Weil sonst eine geänderte E-Mail-Adresse an hundert Stellen geändert werden müsste – und irgendwann irgendwo nicht. Diese Aufteilung heißt Normalisierung: jede Tatsache genau einmal. Für Auswertungen, bei denen nur gelesen wird, verdoppelt man manchmal bewusst Daten, um Abfragen zu beschleunigen – das ist dann Denormalisierung.

SQL und JOINs

Verteilte Daten muss man beim Lesen wieder zusammenführen. Das macht der JOIN: Er verknüpft Zeilen zweier Tabellen, deren Schlüssel zusammenpassen. Welche Art von JOIN man nimmt, entscheidet, was mit Zeilen ohne Partner passiert:

Indizes: vier Zugriffe statt zehn Millionen

Ohne Hilfe muss die Datenbank für WHERE email = '…' jede Zeile anschauen – ein Full Table Scan. Ein Index ist eine zusätzliche, sortierte Struktur, meist ein B-Baum (genauer ein B+-Baum): ein sehr breiter, sehr flacher Suchbaum, dessen Knoten genau eine Speicherseite füllen. In jedem Knoten steht, in welchem Teilbaum ein Wert liegen muss. Gesucht wird von oben nach unten – wie im Telefonbuch erst die richtige Seite, dann der Name.

Weil jeder Knoten Hunderte Verweise hat, wächst die Tiefe des Baums extrem langsam: Von einer Million auf eine Milliarde Zeilen kommt gerade eine Ebene hinzu. Die oberen Ebenen liegen ohnehin fast immer im Arbeitsspeicher. Und weil die Blätter sortiert und miteinander verkettet sind, helfen B-Bäume auch bei Bereichen (BETWEEN, >) und bei ORDER BY.

Umsonst ist ein Index nicht: Jedes INSERT, UPDATE und DELETE muss ihn mitpflegen, und er braucht Platz. Ob die Datenbank ihn nutzt, sieht man mit EXPLAIN – das zeigt den Ausführungsplan, den der Abfrageoptimierer gewählt hat.

Transaktionen und ACID

Eine Buchung besteht aus mehreren Schritten: Platz reduzieren, Buchung anlegen, vielleicht Zahlung vermerken. Eine Transaktion fasst sie zusammen. Sie garantiert vier Dinge, zusammengefasst als ACID:

Der letzte freie Platz

Das „I“ ist das tückischste. Die meisten Datenbanken – PostgreSQL, Oracle, SQL Server – arbeiten standardmäßig mit READ COMMITTED: Jede Abfrage sieht alles, was andere bis dahin bestätigt haben. Das verhindert viel, aber nicht alles. Zwei Kunden buchen gleichzeitig den letzten Platz eines Flugs. Probier die Varianten durch:

Für Entwickler übersetzt

void buche(long flugId, long kundeId) throws SQLException {
    try (Connection con = dataSource.getConnection()) {      // aus dem Pool, z. B. HikariCP
        con.setAutoCommit(false);                            // Transaktion beginnt
        try {
            try (var ps = con.prepareStatement(
                    "UPDATE flug SET frei = frei - 1 WHERE id = ? AND frei > 0")) {
                ps.setLong(1, flugId);
                if (ps.executeUpdate() == 0) throw new AusgebuchtException(flugId);
            }
            try (var ps = con.prepareStatement(
                    "INSERT INTO buchung (flug_id, kunde_id) VALUES (?, ?)")) {
                ps.setLong(1, flugId);
                ps.setLong(2, kundeId);
                ps.executeUpdate();
            }
            con.commit();
        } catch (SQLException | RuntimeException e) {
            con.rollback();
            throw e;
        }
    }
}

Häufige Irrtümer

Verwandte Begriffe