EuraStudy
Notizen/Informatik/INF-DB - Datenbanken und relationale Datenmodelle
AT · Matura

INF-DB - Datenbanken und relationale Datenmodelle

Vom konzeptionellen ER-Modell über die Normalisierung bis zu SQL-Abfragen, Transaktionen und ACID. Datenbanken sind der Standardweg, Information persistent und konsistent zu halten.

6 Abschnitte·~22 Min Lesezeit·4 Kompetenzen·Stand 06/2026

T·0444 / 12
Prüfungsprofil
INF-DB-1 · ER-Modelle entwerfen und in relationale Schemata umsetzenINF-DB-2 · Normalformen 1NF bis 3NF anwendenINF-DB-3 · SQL DDL/DML/DQL schreiben und lesenINF-DB-4 · Transaktionen und ACID-Eigenschaften erklären
Tiefe

Lesetiefe: Vertiefung

Schrift

Schriftgröße: Standard · Zeilenabstand: Kompakt

Medien immer laden: aus

Inhalt · 6 Abschnitte▾
  1. INF-DB - Datenbanken und relationale Datenmodelle
    • 01ER-Diagramme und relationales Modell◐
    • 02Normalformen 1NF, 2NF, 3NF◐
    • 03SQL - DDL, DML, DQL und Joins◐
    • 04Transaktionen und ACID●
    • 05NoSQL-Datenbanken und CAP-Theorem●
    • 06Indizes und Anfrageoptimierung●

6 Abschnitte · 30 Merksätze · 2 Formeln · 30 Fehlerwarnungen

§ 01
§ 01

ER-Diagramme und relationales Modell#

~3 Min Lesezeit●●○StandardLPINF-DB-1.1

Kernpunkte

Bevor man eine Datenbank baut, modelliert man die Welt: Welche Dinge gibt es, und wie hängen sie zusammen? Das Entity-Relationship-Modell (ER) ist die Sprache dafür - eine konzeptionelle, implementierungsunabhängige Skizze, aus der später das konkrete Tabellenschema entsteht ().

ER-Diagramm Schüler - Belegt - Kurs

ER-Modell: Schüler - belegt - KursNetzgraph, Schüler → belegt, belegt → Kurs, belegt → NoteSchülerbelegtKursNotenm
Abb. 1Entitäten Schüler und Kurs, verbunden über die Beziehung belegt mit den Kardinalitäten n:m und dem Attribut Note. Eine n:m-Beziehung wird als eigene Tabelle Belegung(SNr, KNr, Note) umgesetzt.
Abb. 1 ↓
Drei Grundelemente: Entitätstypen (Dinge wie Schüler, Kurs - als Rechtecke), Beziehungstypen (wie „belegt" - als Rauten) und Attribute (Eigenschaften wie Name - als Ellipsen). Ein Attribut kann auch an einer Beziehung hängen, etwa die Note in „belegt" - das wird in Prüfungen gern übersehen.
Kardinalitäten legen fest, wie viele Instanzen sich verknüpfen können: 1:1 (Person-Pass), 1:n (Abteilung-Mitarbeiter) und n:m (Schüler-Kurs). Sie folgen aus den Geschäftsregeln; sie richtig zu bestimmen ist die wichtigste Modellierungsentscheidung überhaupt.
Die Überführung ins relationale Modell folgt festen Regeln: Jede Entität wird zu einer Tabelle; eine 1:n-Beziehung bekommt einfach einen Fremdschlüssel auf der „n"-Seite (keine eigene Tabelle nötig); eine n:m-Beziehung braucht eine eigene Beziehungstabelle mit beiden Fremdschlüsseln als zusammengesetztem Primärschlüssel - dort lebt auch das Beziehungsattribut (siehe Beispiel).
Ein Primärschlüssel (PK) identifiziert jede Zeile eindeutig und ist nie NULL; ein Fremdschlüssel (FK) verweist auf einen PK einer anderen Tabelle und sichert so die referenzielle Integrität. Schwache Entitäten (z. B. eine Bestellposition) existieren nur abhängig von einer Hauptentität und übernehmen deren Schlüssel in ihren eigenen.
Häufige Fehler: eine n:m-Beziehung in nur einer Tabelle abbilden (das erzeugt Redundanz und Anomalien), Kardinalitäten „aus dem Bauch" schätzen (1:n und n:m verwechseln), oder einen zusammengesetzten PK nicht als solchen notieren. Faustregel: erst ein sauberes ER-Modell, dann die mechanische Umwandlung.

Vokabeln

→ Kartei
  • EntitätObjekt der realen Welt, über das Daten gespeichert werden.
  • BeziehungVerknüpfung zwischen Entitäten; sie kann eigene Attribute tragen.
  • KardinalitätAngabe, wie viele Instanzen einer Entität an der Beziehung teilnehmen (1:1, 1:n, n:m).
  • PrimärschlüsselAttribut oder Attributkombination, die einen Datensatz eindeutig identifiziert.
  • FremdschlüsselAttribut, das auf den Primärschlüssel einer anderen Tabelle verweist.
  • ZwischentabelleEigene Tabelle zur Auflösung einer n:m-Beziehung.
Musterbeispiel

ER-Diagramm in relationales Schema überführen

Wandle das ER-Diagramm Schüler -< belegt >- Kurs (n:m, mit Attribut Note) in ein relationales Schema um.

  1. 01Entitätstabellen

    `Schüler(SNr PK, Name, Klasse)` und `Kurs(KNr PK, Titel, Lehrkraft)`.

  2. 02Beziehungstabelle bei n:m

    `Belegung(SNr FK, KNr FK, Note)` mit zusammengesetztem Primärschlüssel (SNr, KNr).

  3. 03Fremdschlüssel verlinken

    Belegung.SNr -> Schüler.SNr; Belegung.KNr -> Kurs.KNr.

  4. 04Bei 1:n

    Bei 1:n könnte der Fremdschlüssel direkt in der "n"-Seite ergänzt werden, ohne separate Tabelle.

Ergebnis: Drei Tabellen, alle in 3NF. Note ist nur im Beziehungstuple speicherbar - so vermeidet man Anomalien.

Schritt-für-Schritt Erklärung3 Schritte
  1. 1

    Das ER-Modell ist die Sprache, in der Datenbankentwickler über den Anwendungsbereich sprechen.

    ER-Diagramm Schüler - Belegt - Kurs

    ER-Modell: Schüler - belegt - KursNetzgraph, Schüler → belegt, belegt → Kurs, belegt → NoteSchülerbelegtKursNotenm
    Abb.Entitäten Schüler und Kurs, verbunden über die Beziehung belegt mit den Kardinalitäten n:m und dem Attribut Note. Eine n:m-Beziehung wird als eigene Tabelle Belegung(SNr, KNr, Note) umgesetzt.
  2. 2

    Kardinalitäten kommen aus den Geschäftsregeln - sie zu klären ist die wichtigste Modellierungsfrage.

  3. 3

    Die Umwandlung in Tabellen folgt mechanischen Regeln - aber nur, wenn das ER-Modell sauber ist.

SRDP-Aufgaben

SelbsttestAus der Fragenbank7 Punkte

Aufgabenstellung

Modelliere für eine Schulbibliothek (Bücher, Schüler, Ausleihen) ein ER-Diagramm. Bestimme Kardinalitäten und überführe das Modell in ein relationales Schema mit PK und FK.

Maturafokus

  • Zeichne das ER-Diagramm in EINER Notation - Chen oder Krähenfuß - und beschrifte Entitäten, Beziehungen und Kardinalitäten vollständig.
  • Begründe jede Kardinalität am Sachverhalt statt sie zu schätzen: „Eine Schülerin belegt mehrere Fächer, ein Fach wird von mehreren belegt" ergibt n:m.
  • Löse jede n:m-Beziehung beim Übergang ins relationale Modell in eine EIGENE Tabelle auf.
  • Vergiss die Beziehungsattribute nicht - die Note in „belegt" gehört in die Zwischentabelle, nicht zu Schülerin oder Fach.
  • Notiere zusammengesetzte Primärschlüssel ausdrücklich als solche und begründe, warum ein einzelnes Feld nicht reicht.

Typische Fehler

  • Eine n:m-Beziehung wird in einer der beiden Tabellen untergebracht; das erzwingt Mehrfachwerte in einem Feld.
  • Die Kardinalität wird geraten statt aus dem Sachverhalt abgeleitet.
  • Ein zusammengesetzter Primärschlüssel wird nicht als solcher gekennzeichnet.
  • Das Beziehungsattribut wandert in eine Entitätstabelle und wird dort mehrdeutig.
  • Fremdschlüssel und Primärschlüssel werden verwechselt; der Fremdschlüssel verweist, er identifiziert nicht.

§ 01

Aktive Wiederholung

Modelliere "Eine Lehrkraft unterrichtet mehrere Klassen, eine Klasse kann von mehreren Lehrkräften unterrichtet werden." Welche Kardinalität? Skizziere das ER-Diagramm und überführe in Tabellen.

Passende Aufgaben üben50 Fragen zum Thema→

Aktiv abrufen

Erinnere dich an die Kernpunkte — dann aufdecken.

Quellen: Chen: The Entity-Relationship Model (ACM TODS)

§ 02
§ 02

Normalformen 1NF, 2NF, 3NF#

~4 Min Lesezeit●●○StandardLPINF-DB-2.1

Kernpunkte

Schlecht entworfene Tabellen leiden an Anomalien: Dieselbe Kundenadresse steht in jeder Bestellzeile (Redundanz), eine Adressänderung muss überall nachgezogen werden (Update-Anomalie), und löscht man die letzte Bestellung, verschwindet der Kunde (Lösch-Anomalie). Die Normalisierung beseitigt das systematisch über eine Treppe von Normalformen ().

Normalformen 1NF - 2NF - 3NF

Normalformen 1NF - 2NF - 3NFTabelle mit 3 Spalten und 3 Zeilen, Daten: Normalform · Bedingung · beseitigt; 1NF · atomare Werte · Wiederholgruppen; 2NF · voll vom Primärschlüssel · partielle Abhängigkeit; 3NF · keine transitive Abh. · transitive AbhängigkeitNormalformBedingungbeseitigt1NFatomare WerteWiederholgruppen2NFvoll vom Primärschlüsselpartielle Abhängigkeit3NFkeine transitive Abh.transitive Abhängigkeit
Abb. 2Jede Stufe zerlegt funktionale Abhängigkeiten weiter. Beispiel Bestellung(KdNr, KdName, ArtNr, ArtBezeichnung, Menge) wird zerlegt in Kunde(KdNr, KdName), Artikel(ArtNr, Bezeichnung) und Bestellung(KdNr, ArtNr, Menge); Update- und Lösch-Anomalien verschwinden.
Abb. 2 ↓
Das Werkzeug dazu sind funktionale Abhängigkeiten: A→BA \to BA→B heißt „der Wert von AAA bestimmt eindeutig den Wert von BBB". Diese explizit aufzuschreiben ist der erste Schritt jeder Normalisierung - ohne sie lässt sich keine Normalform begründen.
Die 1. Normalform (1NF) verlangt atomare Attributwerte: keine Listen, Mengen oder Wiederholungsgruppen in einer Zelle. Statt „Telefon: 0699…, 0676…" nimmt man mehrere Zeilen oder eine eigene Tabelle.
Die 2NF setzt 1NF voraus und verlangt: Jedes Nicht-Schlüssel-Attribut hängt vom gesamten Primärschlüssel ab, nicht nur von einem Teil. Eine Teilabhängigkeit kann nur bei zusammengesetzten Schlüsseln auftreten - etwa wenn bei PK (BNr,ArtNr)(\text{BNr}, \text{ArtNr})(BNr,ArtNr) die Artikelbezeichnung allein von ArtNr abhängt; dann lagert man ArtNr und Bezeichnung in eine eigene Tabelle aus.
Die 3NF setzt 2NF voraus und verbietet transitive Abhängigkeiten A→B→CA \to B \to CA→B→C, bei denen BBB kein Schlüssel ist (etwa KdNr →\to→ KdName oder PLZ →\to→ Stadt). Solche Ketten löst man durch Auslagern auf; das Ergebnis sind mehrere kleine, redundanzfreie Tabellen (siehe Beispiel). Die BCNF (Boyce-Codd) verschärft die 3NF noch, im Schulkontext genügt aber meist die 3NF.
Normalisierung ist kein Selbstzweck: Stark normalisierte Schemata erfordern beim Lesen viele Joins, was Performance kostet - im Data Warehouse wird daher bewusst denormalisiert. Häufige Fehler: die 3NF prüfen, ohne die 2NF sicherzustellen; transitive mit funktionaler Abhängigkeit verwechseln; oder den PK nicht eindeutig festlegen (dann „schwankt" die ganze Normalisierung).

Vokabeln

→ Kartei
  • funktionale Abhängigkeit$A\to B$: Zu jedem Wert von $A$ gehört genau ein Wert von $B$.
  • erste NormalformAlle Attributwerte sind atomar; keine Mehrfachwerte in einem Feld.
  • zweite Normalform1NF und keine Abhängigkeit von einem TEIL des zusammengesetzten Schlüssels.
  • dritte Normalform2NF und keine transitiven Abhängigkeiten über Nichtschlüsselattribute.
  • AnomalieUnerwünschte Nebenwirkung beim Einfügen, Ändern oder Löschen redundanter Daten.
  • DenormalisierungBewusste Rücknahme der Normalisierung zugunsten der Abfragegeschwindigkeit.

Transitive Abhängigkeit

A→B, B→C  ⟹  A→C (transitive Abh.)A \to B,\, B \to C \implies A \to C \text{ (transitive Abh.)}A→B,B→C⟹A→C (transitive Abh.)

AAA ist der Schlüssel, BBB und CCC sind Nichtschlüsselattribute. Genau diese Kette verletzt die dritte Normalform und wird durch Auslagern von B→CB\to CB→C in eine eigene Tabelle aufgelöst.

Musterbeispiel

Tabelle in 3NF normalisieren

Normalisiere `Bestellung(BNr, KdNr, KdName, ArtNr, ArtBez, Menge)` schrittweise bis 3NF.

  1. 011NF prüfen

    Alle Zellen atomar, keine Wiederholungsgruppen -> bereits 1NF.

  2. 022NF prüfen

    PK = (BNr, ArtNr). KdNr, KdName hängen nur von BNr ab, ArtBez nur von ArtNr -> Verletzung 2NF (Teilabhängigkeit).

  3. 03Zerlegen

    `Bestellung(BNr PK, KdNr, KdName)` und `Position(BNr FK, ArtNr FK, Menge)` und `Artikel(ArtNr PK, ArtBez)`.

  4. 043NF prüfen

    In Bestellung gilt: KdName transitiv abhängig von KdNr -> verletzt 3NF.

  5. 05Weiter zerlegen

    Kunden in `Kunde(KdNr PK, KdName)` auslagern. Bestellung enthält nur noch KdNr als FK.

Ergebnis: `Kunde(KdNr, KdName)` | `Artikel(ArtNr, ArtBez)` | `Bestellung(BNr, KdNr)` | `Position(BNr, ArtNr, Menge)`. Anomalien bei Updates und Löschungen sind eliminiert.

Schritt-für-Schritt Erklärung3 Schritte
  1. 1

    Die Normalformen sind eine Treppe von steigender Strenge - mit jedem Schritt verschwinden Anomalien.

    Normalformen 1NF - 2NF - 3NF

    Normalformen 1NF - 2NF - 3NFTabelle mit 3 Spalten und 3 Zeilen, Daten: Normalform · Bedingung · beseitigt; 1NF · atomare Werte · Wiederholgruppen; 2NF · voll vom Primärschlüssel · partielle Abhängigkeit; 3NF · keine transitive Abh. · transitive AbhängigkeitNormalformBedingungbeseitigt1NFatomare WerteWiederholgruppen2NFvoll vom Primärschlüsselpartielle Abhängigkeit3NFkeine transitive Abh.transitive Abhängigkeit
    Abb.Jede Stufe zerlegt funktionale Abhängigkeiten weiter. Beispiel Bestellung(KdNr, KdName, ArtNr, ArtBezeichnung, Menge) wird zerlegt in Kunde(KdNr, KdName), Artikel(ArtNr, Bezeichnung) und Bestellung(KdNr, ArtNr, Menge); Update- und Lösch-Anomalien verschwinden.
  2. 2

    Du brauchst funktionale Abhängigkeiten als Werkzeug, um die Normalformen anzuwenden.

  3. 3

    Im Data Warehouse wird oft denormalisiert, weil Lesegeschwindigkeit wichtiger ist als Anomaliefreiheit.

SRDP-Aufgaben

SelbsttestAus der Fragenbank8 Punkte

Aufgabenstellung

Erläutere die Normalformen 1NF bis 3NF. Demonstriere die Normalisierung am Beispiel `Verkauf(VNr, ProdNr, ProdBez, Kunde, KdAdresse, Menge, Preis)`.

Maturafokus

  • Schreibe alle funktionalen Abhängigkeiten in Pfeilnotation auf, bevor du normalisierst.
  • Bestimme zuerst den Primärschlüssel eindeutig - ohne ihn ist keine Normalform prüfbar.
  • Begründe jeden Schritt mit dem vorigen: 2NF setzt 1NF voraus und verlangt zusätzlich, dass keine Teilabhängigkeit vom zusammengesetzten Schlüssel besteht.
  • Zeige die Anomalien am konkreten Beispiel - Einfüge-, Änderungs- und Löschanomalie sind der eigentliche Grund der Normalisierung.
  • Nenne den Preis: Mehr Tabellen bedeuten mehr Joins; in Auswertungssystemen wird deshalb bewusst denormalisiert.

Typische Fehler

  • Die 3NF wird geprüft, ohne die 2NF sichergestellt zu haben.
  • Transitive und funktionale Abhängigkeit werden verwechselt; die transitive läuft über ein Nichtschlüsselattribut.
  • Der Primärschlüssel wird nicht festgelegt; die Normalisierung wird dadurch beliebig.
  • Die 1NF wird als erfüllt angenommen, obwohl ein Feld mehrere Werte enthält.
  • Normalisierung wird als Selbstzweck betrieben, ohne den Zielkonflikt mit der Abfragegeschwindigkeit zu nennen.

§ 02

Aktive Wiederholung

Prüfe `Mitarbeiter(MNr, Name, AbtNr, AbtName, Büro)` auf 3NF. Wenn nicht erfüllt, zerlege.

Passende Aufgaben üben50 Fragen zum Thema→

Aktiv abrufen

Erinnere dich an die Kernpunkte — dann aufdecken.

Quellen: Codd: A Relational Model of Data for Large Shared Data Banks (CACM)

§ 03
§ 03

SQL - DDL, DML, DQL und Joins#

~4 Min Lesezeit●●○StandardLPINF-DB-3.1LPINF-DB-3.2

Kernpunkte

SQL ist die Standardsprache relationaler Datenbanken und deklarativ: Man beschreibt, was man haben will, nicht wie es berechnet wird - das Wie übernimmt der Query Optimizer. SQL gliedert sich in drei Teilsprachen, die man sicher unterscheiden können muss.
DDL (Data Definition Language: `CREATE`, `ALTER`, `DROP`) definiert Strukturen; DML (`INSERT`, `UPDATE`, `DELETE`) ändert Daten; DQL (`SELECT`) liest Daten ohne Änderung. Diese Dreiteilung ist ein häufiger Prüfungseinstieg.
Die `SELECT`-Anweisung hat eine feste logische Auswertungsreihenfolge: `FROM`/`JOIN` (Quellen bilden) → `WHERE` (Zeilen filtern) → `GROUP BY` (gruppieren) → `HAVING` (Gruppen filtern) → `SELECT` (projizieren) → `ORDER BY` → `LIMIT`. Geschrieben wird `SELECT` zuerst, ausgewertet aber zuletzt - das erklärt, warum man im `WHERE` keinen im `SELECT` vergebenen Spaltenalias verwenden kann.
Joins verknüpfen Tabellen über eine `ON`-Bedingung (): `INNER JOIN` liefert nur passende Paare (Schnitt), `LEFT`/`RIGHT JOIN` erhält zusätzlich alle Zeilen der einen Seite (fehlende Werte werden NULL), `FULL OUTER` vereinigt beide, `CROSS JOIN` bildet das kartesische Produkt. Vergisst man die `ON`-Bedingung, entsteht ungewollt ebendieses kartesische Produkt.

SQL-Join-Typen als Mengen-Venn

INNER JOIN A INTERSECT B LEFT JOIN A ohne B-Match -> NULL RIGHT JOIN B ohne A-Match -> NULL FULL OUTER A UNION B CROSS JOIN entspricht dem kartesischen Produkt A x B
Abb. 3INNER, LEFT, RIGHT und FULL OUTER JOIN visualisiert.
Abb. 3 ↓
Aggregatfunktionen (`COUNT, SUM, AVG, MIN, MAX`) verdichten viele Zeilen zu einem Wert, mit `GROUP BY` je Gruppe. Entscheidend: `WHERE` filtert Einzelzeilen vor der Gruppierung, `HAVING` filtert Gruppen nach der Aggregation - die beiden nicht verwechseln.
NULL bedeutet „unbekannt" und folgt einer dreiwertigen Logik (TRUE/FALSE/UNKNOWN): `wert = NULL` ergibt nie TRUE, man muss `IS NULL`/`IS NOT NULL` schreiben. Vorgehen bei Aufgaben (siehe Beispiel): Tabellen identifizieren → Joins → Filter → Projektion. Häufige Fehler: `WHERE` und `HAVING` verwechseln, die `ON`-Bedingung vergessen, oder NULL mit `=` vergleichen.

Vokabeln

→ Kartei
  • DDLData Definition Language; CREATE, ALTER und DROP für die Struktur.
  • DMLData Manipulation Language; INSERT, UPDATE und DELETE für die Daten.
  • INNER JOINVerknüpfung, die nur Zeilen mit Treffer in beiden Tabellen liefert.
  • LEFT JOINVerknüpfung, die alle Zeilen der linken Tabelle behält und fehlende Werte mit NULL füllt.
  • AggregatfunktionFunktion über eine Gruppe von Zeilen wie COUNT, SUM oder AVG.
  • NULLMarker für einen fehlenden Wert; jeder Vergleich damit ergibt UNKNOWN.
Musterbeispiel

SQL-Query aus deutscher Anforderung herleiten

"Liste alle Schüler-Namen, die im Kurs mit Titel 'Mathematik' eine Note besser als 3 haben."

  1. 01Tabellen identifizieren

    Schüler, Kurs, Belegung.

  2. 02Join-Bedingungen

    Schüler.SNr = Belegung.SNr UND Kurs.KNr = Belegung.KNr.

  3. 03Filter

    Kurs.Titel = 'Mathematik' AND Belegung.Note < 3.

  4. 04Projektion

    SELECT Schüler.Name.

  5. 05Query zusammensetzen

    ```sql SELECT s.Name FROM Schüler s JOIN Belegung b ON s.SNr = b.SNr JOIN Kurs k ON b.KNr = k.KNr WHERE k.Titel = 'Mathematik' AND b.Note < 3; ```

Ergebnis: In Österreich gilt 1 = Sehr gut, 5 = Nicht genügend; "besser als 3" bedeutet Note < 3 (also 1 oder 2).

Schritt-für-Schritt Erklärung3 Schritte
  1. 1

    SQL ist eine deklarative Sprache - du beschreibst, was du willst, nicht wie es berechnet wird.

  2. 2

    Joins verbinden Tabellen; entscheidend ist die ON-Bedingung, sonst entsteht ein kartesisches Produkt.

    SQL-Join-Typen als Mengen-Venn

    INNER JOIN A INTERSECT B LEFT JOIN A ohne B-Match -> NULL RIGHT JOIN B ohne A-Match -> NULL FULL OUTER A UNION B CROSS JOIN entspricht dem kartesischen Produkt A x B
    Abb.INNER, LEFT, RIGHT und FULL OUTER JOIN visualisiert.
  3. 3

    Aggregat- und Gruppierungsfunktionen verwandeln Detaildaten in zusammengefasste Berichte.

SRDP-Aufgaben

SelbsttestAus der Fragenbank7 Punkte

Aufgabenstellung

Erläutere die Aufgaben von DDL, DML und DQL in SQL. Formuliere für eine Tabelle `Verkauf(VNr, Datum, KundeNr, Betrag)` eine Abfrage, die den Gesamtumsatz pro Kunde absteigend sortiert ausgibt.

Maturafokus

  • Baue jede Abfrage in fester Reihenfolge: benötigte Tabellen, dann Joins mit ON-Bedingung, dann WHERE, dann Gruppierung, zuletzt die Projektion.
  • Trenne WHERE und HAVING: WHERE filtert ZEILEN vor der Gruppierung, HAVING filtert GRUPPEN danach.
  • Nenne in der SELECT-Liste bei GROUP BY nur Gruppierungsspalten und Aggregatfunktionen.
  • Erkläre die Dreiwertigkeit bei NULL: Ein Vergleich mit NULL ergibt UNKNOWN, deshalb braucht es IS NULL statt === NULL.
  • Unterscheide die Join-Arten: INNER liefert nur Treffer, LEFT behält alle Zeilen der linken Tabelle.

Typische Fehler

  • WHERE und HAVING werden vertauscht; Aggregate lassen sich in WHERE nicht filtern.
  • Ein Join ohne ON-Bedingung erzeugt das kartesische Produkt mit entsprechend riesiger Ergebnismenge.
  • In der SELECT-Liste steht bei GROUP BY eine Spalte, die weder gruppiert noch aggregiert ist.
  • NULL wird mit === verglichen; das Ergebnis ist nie wahr.
  • COUNT(*) und COUNT(spalte) werden gleichgesetzt; letzteres zählt NULL-Werte nicht mit.

§ 03

Aktive Wiederholung

Tabelle `Schüler(SNr, Name, Klasse)` und `Note(SNr, Fach, Wert)`. Schreibe Queries: (a) Durchschnittsnote pro Klasse; (b) Schüler ohne eingetragene Note; (c) Top 5 Schüler nach Durchschnittsnote.

Passende Aufgaben üben50 Fragen zum Thema→

Aktiv abrufen

Erinnere dich an die Kernpunkte — dann aufdecken.

Quellen: SQL Standard ISO/IEC 9075 (ISO) · PostgreSQL Documentation - SQL Tutorial (PostgreSQL Global Development Group)

§ 04
§ 04

Transaktionen und ACID#

~3 Min Lesezeit●●●VertiefungLPINF-DB-4.1

Kernpunkte

Viele Datenbankaufgaben bestehen aus mehreren Schritten, die nur gemeinsam sinnvoll sind - eine Überweisung etwa aus Abbuchen und Gutschreiben. Eine Transaktion fasst solche Operationen zu einer logischen Einheit zusammen, die vollständig oder gar nicht wirkt.
Relationale Datenbanken garantieren dafür ACID: Atomicity (alles oder nichts - bei Fehler ROLLBACK), Consistency (alle Integritätsregeln bleiben gewahrt), Isolation (parallele Transaktionen stören sich nicht, das Ergebnis ist wie bei serieller Ausführung) und Durability (ein bestätigtes COMMIT überlebt selbst einen Stromausfall, meist über ein Write-Ahead-Log).
Gesteuert wird mit `BEGIN`/`START TRANSACTION`, `COMMIT` (übernehmen) und `ROLLBACK` (zurücksetzen). Beispiel Überweisung: abbuchen, Saldo prüfen, gutschreiben, COMMIT - reißt zwischendurch der Strom ab, macht die DB beim Neustart automatisch ROLLBACK, sodass nie nur die Hälfte gebucht ist (siehe Beispiel).
Isolation ist abstufbar (): von Read Uncommitted (schnell, aber alle Anomalien möglich) über Read Committed und Repeatable Read bis Serializable (strikt, aber teuer). Mit steigender Stufe werden mehr Anomalien ausgeschlossen: Dirty Read (ungesicherte fremde Daten lesen), Non-Repeatable Read (dieselbe Zeile liefert zweimal Verschiedenes) und Phantom Read (zwischendurch erscheinen neue Zeilen).

Isolationslevel und Anomalien

Isolationslevel und AnomalienTabelle mit 4 Spalten und 4 Zeilen, Daten: Isolationslevel · Dirty Read · Non-Repeatable · Phantom; Read Uncommitted · möglich · möglich · möglich; Read Committed · verhindert · möglich · möglich; Repeatable Read · verhindert · verhindert · möglich; Serializable · verhindert · verhindert · verhindertIsolationslevelDirty ReadNon-RepeatablePhantomRead UncommittedmöglichmöglichmöglichRead CommittedverhindertmöglichmöglichRepeatable ReadverhindertverhindertmöglichSerializableverhindertverhindertverhindert
Abb. 4Mit steigender Isolationsstufe werden mehr Anomalien ausgeschlossen - auf Kosten der Parallelität.
Abb. 4 ↓
Aus der Parallelität entstehen weitere Probleme: Lost Update (zwei Transaktionen überschreiben einander) und Deadlocks (zwei warten zyklisch auf gegenseitig gehaltene Sperren - die DB löst das durch Abbruch einer der beiden). Höhere Isolation verhindert mehr davon, kostet aber Parallelität.
Im verteilten Kontext wird strikte Konsistenz teuer: Das CAP-Theorem besagt, dass bei einer Netzwerk-Partition nur zwei von Consistency, Availability und Partition Tolerance zugleich garantierbar sind (mehr im NoSQL-Abschnitt). Häufige Fehler: Atomicity und Consistency gleichsetzen, Isolationslevel mit Zugriffsrechten verwechseln, oder Deadlock und Livelock nicht trennen.

Vokabeln

→ Kartei
  • TransaktionFolge von Operationen, die als Einheit ausgeführt wird.
  • AtomaritätGanz oder gar nicht; ein Abbruch macht alle Teilschritte rückgängig.
  • IsolationNebenläufige Transaktionen beeinflussen einander nicht sichtbar.
  • CommitEndgültiges Bestätigen einer Transaktion.
  • RollbackZurücknehmen aller Änderungen einer Transaktion.
  • DeadlockGegenseitige Blockade zweier Transaktionen; keine kann fortfahren.
Musterbeispiel

Banktransaktion in SQL

Schreibe eine Transaktion, die 100 EUR von Konto A auf Konto B überweist.

  1. 01Start

    `BEGIN TRANSACTION;`

  2. 02Abbuchen

    `UPDATE Konto SET Saldo = Saldo - 100 WHERE KNr = 'A';`

  3. 03Prüfung

    Wenn Saldo < 0 -> `ROLLBACK;` und Fehler ausgeben.

  4. 04Gutschrift

    `UPDATE Konto SET Saldo = Saldo + 100 WHERE KNr = 'B';`

  5. 05Abschluss

    `COMMIT;`

Ergebnis: Atomicity: ohne COMMIT bleibt der Stand unverändert. Bei Stromausfall vor COMMIT macht die DB beim Neustart automatisch ROLLBACK (Recovery via WAL).

Schritt-für-Schritt Erklärung3 Schritte
  1. 1

    ACID ist das Versprechen, das relationale Datenbanken seit Jahrzehnten machen.

  2. 2

    Stell dir Atomicity wie eine "Alles-oder-Nichts"-Schaltung vor: entweder das gesamte Update zählt, oder gar nichts.

  3. 3

    In verteilten Systemen ist ACID schwer - dort taucht das CAP-Theorem auf.

SRDP-Aufgaben

SelbsttestAus der Fragenbank8 Punkte

Aufgabenstellung

Erläutere das ACID-Prinzip in Datenbanksystemen. Veranschauliche die einzelnen Eigenschaften an einer Online-Buchung.

Maturafokus

  • Modelliere die Geldüberweisung als Transaktion aus Abbuchung und Gutschrift und zeige, warum sie ungeteilt ablaufen muss.
  • Erkläre alle vier ACID-Eigenschaften an diesem einen Beispiel statt sie einzeln aufzuzählen.
  • Ordne die Isolationsanomalien zu: Dirty Read, Non-Repeatable Read und Phantom Read entstehen bei zu schwacher Isolation.
  • Trenne Atomarität (ganz oder gar nicht) von Konsistenz (Einhaltung aller Regeln vor und nach der Transaktion).
  • Unterscheide Deadlock (zwei Transaktionen warten wechselseitig, nichts geht mehr) von Livelock (beide arbeiten, kommen aber nicht voran).

Typische Fehler

  • Atomarität und Konsistenz werden synonym verwendet.
  • Der Isolationslevel wird mit Zugriffsberechtigungen verwechselt.
  • Deadlock und Livelock werden gleichgesetzt.
  • Dauerhaftigkeit wird als Backup gedeutet; gemeint ist, dass ein bestätigter Commit auch einen Absturz übersteht.
  • Es wird angenommen, ein höherer Isolationslevel sei stets besser; er kostet Nebenläufigkeit.

§ 04

Aktive Wiederholung

Erläutere die ACID-Eigenschaften an einer Banktransaktion. Welches Problem entsteht, wenn Atomicity verletzt wird?

Passende Aufgaben üben50 Fragen zum Thema→

Aktiv abrufen

Erinnere dich an die Kernpunkte — dann aufdecken.

Quellen: Garcia-Molina, Ullman, Widom: Database Systems - The Complete Book (Pearson)

§ 05
§ 05

NoSQL-Datenbanken und CAP-Theorem#

~3 Min Lesezeit●●●VertiefungLPINF-DB-5.1

Kernpunkte

Das relationale Modell ist mächtig, aber sein festes Schema und ACID skalieren über viele Server hinweg schlecht. NoSQL („Not only SQL") bündelt nicht-relationale Datenbanken mit flexiblen Schemata, die für bestimmte Anforderungen besser passen - als Ergänzung, nicht als Ersatz.
Es gibt vier Hauptklassen (): Key-Value (Redis, DynamoDB - einfachste Schlüssel→Wert-Zuordnung, ideal für Caches/Sessions), Document (MongoDB - JSON-artige Dokumente, gut für CMS/Kataloge), Column-Family (Cassandra, HBase - spaltenorientiert, für riesige Schreibvolumina) und Graph (Neo4j - Knoten und Kanten, für soziale Netze und Empfehlungen).

NoSQL-Datenbankklassen im Überblick

NoSQL-KlassenTabelle mit 4 Spalten und 4 Zeilen, Daten: Typ · Beispiele · Datenmodell · Einsatz; Key-Value · Redis, DynamoDB · Schlüssel → Wert · Caches, Sessions; Document · MongoDB, Couchbase · JSON-Dokumente · CMS, Kataloge; Column-Family · Cassandra, HBase · Spaltenfamilien · Logs, IoT, Big Data; Graph · Neo4j, JanusGraph · Knoten + Kanten · soziale Netze, EmpfehlungenTypBeispieleDatenmodellEinsatzKey-ValueRedis, DynamoDBSchlüssel → WertCaches, SessionsDocumentMongoDB, CouchbaseJSON-DokumenteCMS, KatalogeColumn-FamilyCassandra, HBaseSpaltenfamilienLogs, IoT, Big DataGraphNeo4j, JanusGraphKnoten + Kantensoziale Netze, Empfehlungen
Abb. 5Vier Hauptklassen mit ihrem Datenmodell und typischen Einsatzgebieten.
Abb. 5 ↓
Das CAP-Theorem (Brewer) ist der theoretische Kern verteilter Datenbanken: Bei einer Partition (Netzwerktrennung) muss man zwischen Consistency (alle sehen denselben Stand) und Availability (jede Anfrage wird beantwortet) wählen - beides zugleich geht dann nicht. CAP heißt nicht, dass eine Eigenschaft „fehlt", sondern dass im Partitionsfall ein Kompromiss nötig wird.
Statt ACID setzen viele NoSQL-Systeme auf BASE (Basically Available, Soft state, Eventual consistency): Sie nehmen kurzzeitige Inkonsistenz in Kauf und gleichen sich „irgendwann" ab, gewinnen dafür horizontale Skalierbarkeit - mehr Knoten statt eines stärkeren Servers.
Konkret (siehe Beispiel): CP-Systeme (MongoDB-Replica-Set, HBase) blockieren bei Partition lieber Schreibvorgänge, um konsistent zu bleiben; AP-Systeme (Cassandra, DynamoDB) schreiben immer und akzeptieren spätere Konsistenz. Die Wahl folgt dem Geschäftsfall: Bankkonten → CP (Inkonsistenz verboten), soziale Likes → AP (kurzzeitig unkritisch).
Anwendungsfälle für NoSQL sind hohe Schreibvolumina (IoT, Logs), unstrukturierte Daten und sehr große Graphen; relationale DBs bleiben aber das Standardwerkzeug für transaktionale Geschäftsdaten. Häufige Fehler: „NoSQL = kein SQL" wörtlich nehmen, relationale DBs für veraltet erklären, oder CAP so deuten, als ob generell eine Eigenschaft wegfiele.

Vokabeln

→ Kartei
  • Key-Value-StoreEinfachste NoSQL-Form; Zugriff ausschließlich über den Schlüssel.
  • DokumentdatenbankSpeichert strukturierte Dokumente, meist als JSON.
  • GraphdatenbankSpeichert Knoten und Kanten; stark bei Beziehungsabfragen.
  • CAP-TheoremBei Netzwerkpartition ist zwischen Konsistenz und Verfügbarkeit zu wählen.
  • Eventual ConsistencyAlle Repliken gleichen sich nach einiger Zeit an.
  • ShardingHorizontale Aufteilung der Daten auf mehrere Knoten.
Musterbeispiel

CAP-Entscheidung an Beispielen

Welche CAP-Tradeoffs gehen typische Systeme ein?

  1. 01CP-System

    MongoDB (Single Replica Set), HBase: bei Partition werden Schreibvorgänge blockiert -> Konsistenz, aber kurze Nicht-Verfügbarkeit.

  2. 02AP-System

    Cassandra, DynamoDB: schreiben immer, akzeptieren später Konsistenz (eventual consistency).

  3. 03CA-System

    Klassische relationale DB auf einem Server - aber das ist nicht verteilt, daher keine Partition Tolerance nötig.

Ergebnis: Wahl hängt vom Geschäftsfall ab. Bankkonten -> CP (Inkonsistenz verboten); soziale Likes -> AP (kurzzeitige Inkonsistenz akzeptabel).

Schritt-für-Schritt Erklärung3 Schritte
  1. 1

    NoSQL ist nicht Anti-SQL - es ist eine Ergänzung für spezielle Anforderungen.

  2. 2

    Das CAP-Theorem ist ein scharfes mathematisches Ergebnis: in verteilten Systemen gibt es keinen Gratisluxus.

  3. 3

    Wähle die Datenbank nach Datenmodell und Konsistenzanforderung - nicht nach Hype.

SRDP-Aufgaben

SelbsttestAus der Fragenbank7 Punkte

Aufgabenstellung

Vergleiche relationale und NoSQL-Datenbanken. Erläutere das CAP-Theorem und gib je ein Beispiel für CP- und AP-Systeme.

Maturafokus

  • Nenne die vier Typen mit je einem Produkt und einem Einsatzfall: Key-Value, Dokument, Spaltenfamilie, Graph.
  • Erkläre das CAP-Theorem richtig: Bei einer NETZWERKPARTITION muss zwischen Konsistenz und Verfügbarkeit gewählt werden.
  • Ordne Systeme ein und begründe die Zuordnung mit ihrem Verhalten im Partitionsfall.
  • Stelle den Zielkonflikt dar: ACID-Garantien kosten horizontale Skalierbarkeit, BASE-Systeme tauschen sie gegen Verfügbarkeit.
  • Löse „NoSQL" richtig auf - es heißt „not only SQL" und schließt relationale Systeme nicht aus.

Typische Fehler

  • „NoSQL" wird wörtlich als „kein SQL" gelesen.
  • Relationale Datenbanken werden als veraltet dargestellt; sie sind für strukturierte Daten mit Konsistenzanforderung weiterhin erste Wahl.
  • CAP wird so gedeutet, als fehle einem System dauerhaft eine der drei Eigenschaften; die Wahl stellt sich nur im Partitionsfall.
  • Schemafreiheit wird als „kein Schema nötig" verstanden; das Schema wandert nur in die Anwendung.
  • Eventual Consistency wird mit Inkonsistenz gleichgesetzt; gemeint ist eine verzögerte Angleichung.

§ 05

Aktive Wiederholung

Welche NoSQL-Klasse wählst du für (a) eine soziale Netz-App, (b) ein IoT-Sensor-Logging-System, (c) ein dokumentbasiertes CMS? Begründe.

Passende Aufgaben üben50 Fragen zum Thema→

Aktiv abrufen

Erinnere dich an die Kernpunkte — dann aufdecken.

Quellen: Brewer: CAP Twelve Years Later - How the "Rules" Have Changed (InfoQ) · MongoDB Manual (MongoDB Inc.)

§ 06
§ 06

Indizes und Anfrageoptimierung#

~5 Min Lesezeit●●●VertiefungLPINF-DB-3.1LPINF-DB-3.2

Kernpunkte

Ohne Hilfsstruktur muss die Datenbank für jede Suche die ganze Tabelle durchlesen (Full Table Scan, O(n)O(n)O(n)) - bei Millionen Zeilen untragbar. Ein Index ist eine zusätzliche, sortierte Datenstruktur (meist ein B+-Baum), die das Auffinden beschleunigt, ganz wie das Stichwortverzeichnis eines Buches ().

Index - Nutzen und Kosten

Index-AbwägungTabelle mit 3 Spalten und 4 Zeilen, Daten: Operation · ohne Index · mit Index; Suche nach Schlüssel · O(n) Full Scan · O(log n) B+-Baum; INSERT / UPDATE · nur Tabelle · Tabelle + Index; Speicherbedarf · gering · höher (Indexbaum); ORDER BY indizierte Spalte · extra Sortierschritt · bereits sortiertOperationohne Indexmit IndexSuche nach SchlüsselO(n) Full ScanO(log n) B+−BaumINSERT / UPDATEnur TabelleTabelle + IndexSpeicherbedarfgeringhöher (Indexbaum)ORDER BY indizierte Spalteextra Sortierschrittbereits sortiert
Abb. 6Ein Index beschleunigt das Lesen drastisch, belastet aber Schreiboperationen und Speicher.
Abb. 6 ↓
Der B+-Baum hält die indizierten Werte sortiert in einem flachen, balancierten Baum; eine Suche steigt von der Wurzel zu den Blättern ab und braucht nur O(log⁡n)O(\log n)O(logn) Schritte statt O(n)O(n)O(n). Bei 2 Mio. Zeilen sind das rund 21 statt 2 Mio. Vergleiche. Der Primärschlüssel erhält automatisch einen Index; weitere legt man gezielt mit `CREATE INDEX` an.
Indizes sind ein Kompromiss (): Sie beschleunigen `SELECT`, `JOIN`, `WHERE` und `ORDER BY`, verlangsamen aber `INSERT`/`UPDATE`/`DELETE`, weil jeder Index mitgepflegt werden muss, und kosten zusätzlichen Speicher. Daher gilt: nicht jede Spalte indizieren, sondern gezielt die häufig gefilterten oder verbundenen.
Ein Index lohnt sich besonders auf selektiven Spalten (mit vielen verschiedenen Werten). Ein zusammengesetzter Index auf `(a, b)` folgt der Linksprefix-Regel: Er hilft Abfragen auf `a` und auf `(a, b)`, nicht aber auf `b` allein - dafür bräuchte es einen eigenen Index.
Welche Indizes tatsächlich genutzt werden, entscheidet der Query Optimizer anhand von Statistiken (Selektivität, Kardinalität); mit `EXPLAIN` macht man den gewählten Ausführungsplan sichtbar und sieht, ob ein Index greift oder doch gescannt wird.
Weitere Hebel: eine sinnvolle Join-Reihenfolge, kein `SELECT `, und sargable* Prädikate - eine Funktion auf der indizierten Spalte (`WHERE YEAR(datum)=2024`) macht den Index unbrauchbar, besser `WHERE datum >= '2024-01-01'`. Häufige Fehler: „mehr Indizes sind immer besser" (sie bremsen das Schreiben), einen Index mit dem Schlüssel gleichsetzen (ein Index ist nicht eindeutig), oder den zusammengesetzten Index falsch herum nutzen.

Vokabeln

→ Kartei
  • IndexZusatzstruktur, die den Zugriff auf bestimmte Spalten beschleunigt.
  • Full Table ScanVollständiges Durchlesen einer Tabelle ohne Indexnutzung.
  • zusammengesetzter IndexIndex über mehrere Spalten; nur ein Linkspräfix der Spaltenfolge ist nutzbar.
  • SelektivitätAnteil der durch eine Bedingung ausgewählten Zeilen; hohe Selektivität lohnt einen Index.
  • AusführungsplanVom Optimierer gewählter Weg zur Beantwortung einer Abfrage.
  • Kardinalität einer SpalteAnzahl verschiedener Werte; entscheidet über den Nutzen eines Index.

Suchkosten mit B+-Baum-Index vs. Full Table Scan

TIndex=O(log⁡bn)≪TScan=O(n)T_{\text{Index}} = O(\log_{b} n) \ll T_{\text{Scan}} = O(n)TIndex​=O(logb​n)≪TScan​=O(n)

bbb ist der Verzweigungsgrad des Indexbaums, nnn die Zeilenzahl. Bei einer Million Zeilen und typischem bbb genügen wenige Blockzugriffe statt einer Million - deshalb ist der Index die wirksamste Einzelmaßnahme der Abfrageoptimierung.

Musterbeispiel

Index-Entscheidung für eine Filterabfrage

Eine Tabelle `Bestellung` mit 2 Mio. Zeilen wird häufig mit `WHERE KundenNr = ?` abgefragt. Erläutere den Effekt eines Index auf `KundenNr`.

  1. Schritt 1 - Ist-Zustand

    Ohne Index: Full Table Scan über 2 Mio. Zeilen, O(n)O(n)O(n) - bei jeder Abfrage werden alle Zeilen gelesen.

  2. Schritt 2 - Index anlegen

    `CREATE INDEX idx_kunde ON Bestellung(KundenNr);` baut einen B+-Baum über die Spalte.

  3. Schritt 3 - Lesegewinn

    Suche sinkt auf O(log⁡n)≈21O(\log n) \approx 21O(logn)≈21 Vergleiche statt 2 Mio. - drastisch schneller.

  4. Schritt 4 - Kosten

    Jeder `INSERT`/`UPDATE` von `KundenNr` muss den Index mitpflegen; zusätzlicher Speicher für den B+-Baum.

  5. Schritt 5 - Abwägung

    Da die Tabelle leseintensiv ist und KundenNr selektiv (viele verschiedene Werte), überwiegt der Nutzen klar.

Ergebnis: Ein Index auf `KundenNr` lohnt sich: Lesezeit von O(n)O(n)O(n) auf O(log⁡n)O(\log n)O(logn); geringe Mehrkosten beim Schreiben werden durch den Lesegewinn aufgewogen.

Musterbeispiel

Linksprefix-Regel beim zusammengesetzten Index

Gegeben ein Index auf `(Nachname, Vorname)`. Welche der Abfragen nutzen ihn?

  1. Schritt 1

    `WHERE Nachname = 'Huber'` - nutzt den Index (Linksprefix erfüllt).

  2. Schritt 2

    `WHERE Nachname = 'Huber' AND Vorname = 'Anna'` - nutzt den Index voll.

  3. Schritt 3

    `WHERE Vorname = 'Anna'` - nutzt den Index nicht, da der führende Schlüsselteil fehlt.

Ergebnis: Nur Abfragen, die mit der führenden Spalte beginnen, profitieren; ein eigener Index auf `Vorname` wäre für Fall 3 nötig.

Schritt-für-Schritt Erklärung3 Schritte
  1. 1

    Ein Index ist wie das Stichwortverzeichnis eines Buches: man muss nicht jede Seite durchblättern.

  2. 2

    Der Gewinn beim Lesen (O(log⁡n)O(\log n)O(logn)) wird mit Mehraufwand beim Schreiben erkauft - deshalb nicht jede Spalte indizieren.

  3. 3

    Mit EXPLAIN zeigt die Datenbank, ob sie den Index nutzt oder doch scannt.

SRDP-Aufgaben

SelbsttestAus der Fragenbank6 Punkte

Aufgabenstellung

Erkläre, wie Indizes Datenbankabfragen beschleunigen. Diskutiere die Nachteile und nenne ein Kriterium, wann ein Index sinnvoll ist.

Maturafokus

  • Erkläre den Zielkonflikt: Ein Index beschleunigt das Lesen und verlangsamt jedes Schreiben, weil er mitgepflegt werden muss.
  • Entscheide anhand der Abfrage, welche Spalte zu indizieren ist - Spalten in WHERE, JOIN und ORDER BY sind die Kandidaten.
  • Ordne die Größenordnungen ein: Index-Suche O(log⁡n)O(\log n)O(logn) gegen Full Table Scan O(n)O(n)O(n) - bei einer Million Zeilen sind das rund 20 statt 10610^{6}106 Zugriffe.
  • Wende die Linkspräfix-Regel an: Ein zusammengesetzter Index über (A, B) hilft bei Abfragen auf A und auf A+B, nicht aber auf B allein.
  • Vermeide Funktionen auf der indizierten Spalte im WHERE - sie machen den Index unbrauchbar.

Typische Fehler

  • Mehr Indizes werden pauschal als besser angesehen; jeder kostet Schreibleistung und Speicher.
  • Eine Funktion auf der indizierten Spalte im WHERE verhindert die Indexnutzung.
  • Ein zusammengesetzter Index wird auf der zweiten Spalte allein abgefragt und greift deshalb nicht.
  • Index und Primärschlüssel werden gleichgesetzt; ein Index muss nicht eindeutig sein.
  • Der Ausführungsplan wird nicht geprüft; die Vermutung ersetzt die Messung.

§ 06

Aktive Wiederholung

Beurteile für die Abfrage `SELECT * FROM Bestellung WHERE KundenNr = 4711 AND Datum > '2024-01-01'`, welche Indizes sinnvoll sind, und begründe den Effekt auf Lese- und Schreiboperationen.

Passende Aufgaben üben50 Fragen zum Thema→

Aktiv abrufen

Erinnere dich an die Kernpunkte — dann aufdecken.

Quellen: Use The Index, Luke! - SQL Indexing (Markus Winand)

Stand 06/2026 · Vollständige Fassung über den Tiefenregler — gleiche Stelle, gleiche Anker

Inhalt

Abschnitt -- / 06

    • 01ER-Diagramme und relationales Modell◐
    • 02Normalformen 1NF, 2NF, 3NF◐
    • 03SQL - DDL, DML, DQL und Joins◐
    • 04Transaktionen und ACID●
    • 05NoSQL-Datenbanken und CAP-Theorem●
    • 06Indizes und Anfrageoptimierung●

0/6 Gelesen

Aus den Notizen ins Training

INF-DB - Datenbanken und relationale Datenmodelle

Festige dieses Thema an passenden Aufgaben aus der Fragenbank.

~22
Min
4
Kompetenzen
50
Fragen
Üben
Beispielfrage

Modelliere für eine Schulbibliothek (Bücher, Schüler, Ausleihen) ein ER-Diagramm. Bestimme Kardinalitäten und überführe das Modell in ein relationales Schema mit PK und FK.

7 BE · 2022

Zur Fragenbank
Wiederholung planen

Belege & Quellen

Quellen

ACM TODS

  • Chen: The Entity-Relationship Model

CACM

  • Codd: A Relational Model of Data for Large Shared Data Banks

ISO

  • SQL Standard ISO/IEC 9075

PostgreSQL Global Development Group

  • PostgreSQL Documentation - SQL Tutorial

Pearson

  • Garcia-Molina, Ullman, Widom: Database Systems - The Complete Book

InfoQ

  • Brewer: CAP Twelve Years Later - How the "Rules" Have Changed

MongoDB Inc.

  • MongoDB Manual

Markus Winand

  • Use The Index, Luke! - SQL Indexing

Siehe auch

  • INF-DS - DatenstrukturenIndizes sind Bäume, Hashjoins nutzen Hashtabellen.
  • INF-WebSE - Webentwicklung und Software EngineeringFast jede Webanwendung spricht im Hintergrund mit einer Datenbank.
  • INF-Sec - IT-Sicherheit, Kryptografie und DatenschutzZugriffsrechte, Verschlüsselung und DSGVO betreffen zuerst die Datenhaltung.

Vorheriges Thema

INF-DS - Datenstrukturen

Nächstes Thema

INF-Net - Netzwerke und Internet

EuraStudy·Notizen T·04·MMXXVI

Weiter mit dem nächsten Thema — der Lernpfad bleibt erhalten.