INF-DB - Datenbanken und relationale Datenmodelle — Informatik · Matura-Zusammenfassung

ER-Diagramme und relationales Modell#

StandardINF-DB-1.1

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

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.

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.

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.

Entitätstabellen
`Schüler(SNr PK, Name, Klasse)` und `Kurs(KNr PK, Titel, Lehrkraft)`.
Beziehungstabelle bei n:m
`Belegung(SNr FK, KNr FK, Note)` mit zusammengesetztem Primärschlüssel (SNr, KNr).
Fremdschlüssel verlinken
Belegung.SNr -> Schüler.SNr; Belegung.KNr -> Kurs.KNr.
Bei 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
Das ER-Modell ist die Sprache, in der Datenbankentwickler über den Anwendungsbereich sprechen.
ER-Diagramm Schüler - Belegt - Kurs
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
Kardinalitäten kommen aus den Geschäftsregeln - sie zu klären ist die wichtigste Modellierungsfrage.
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.

Deine Antwortwird nicht automatisch bewertet

Typische Fehler

n:m-Beziehung in einer Tabelle modelliert (statt separate Tabelle).
Kardinalität aus dem Bauch heraus geschätzt (1:n vs. n:m verwechselt).
PK aus mehreren Feldern wird nicht als zusammengesetzt notiert.

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.

Aktiv abrufen

Erinnere dich an die Kernpunkte — dann aufdecken.

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

Normalformen 1NF, 2NF, 3NF#

StandardINF-DB-2.1

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

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.

Das Werkzeug dazu sind funktionale Abhängigkeiten:

A \to B

heißt „der Wert von

A

bestimmt eindeutig den Wert von

B

". 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

(\text{BNr}, \text{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 \to B \to C

, bei denen

B

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).

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

Transitive Abhängigkeit

Musterbeispiel

Tabelle in 3NF normalisieren

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

1NF prüfen
Alle Zellen atomar, keine Wiederholungsgruppen -> bereits 1NF.
2NF prüfen
PK = (BNr, ArtNr). KdNr, KdName hängen nur von BNr ab, ArtBez nur von ArtNr -> Verletzung 2NF (Teilabhängigkeit).
Zerlegen
`Bestellung(BNr PK, KdNr, KdName)` und `Position(BNr FK, ArtNr FK, Menge)` und `Artikel(ArtNr PK, ArtBez)`.
3NF prüfen
In Bestellung gilt: KdName transitiv abhängig von KdNr -> verletzt 3NF.
Weiter 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
Die Normalformen sind eine Treppe von steigender Strenge - mit jedem Schritt verschwinden Anomalien.
Normalformen 1NF - 2NF - 3NF
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
Du brauchst funktionale Abhängigkeiten als Werkzeug, um die Normalformen anzuwenden.
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)`.

Deine Antwortwird nicht automatisch bewertet

Typische Fehler

3NF wird ohne Prüfung der 2NF angesetzt.
Transitive Abhängigkeit wird mit funktionaler Abhängigkeit verwechselt.
PK nicht eindeutig festgelegt -> Normalisierung schwankt.

Aktive Wiederholung

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

Aktiv abrufen

Erinnere dich an die Kernpunkte — dann aufdecken.

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

SQL - DDL, DML, DQL und Joins#

StandardINF-DB-3.1INF-DB-3.2

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

Abb. 3INNER, LEFT, RIGHT und FULL OUTER JOIN visualisiert.

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.

Musterbeispiel

SQL-Query aus deutscher Anforderung herleiten

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

Tabellen identifizieren
Schüler, Kurs, Belegung.
Join-Bedingungen
Schüler.SNr = Belegung.SNr UND Kurs.KNr = Belegung.KNr.
Filter
Kurs.Titel = 'Mathematik' AND Belegung.Note < 3.
Projektion
SELECT Schüler.Name.
Query 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
SQL ist eine deklarative Sprache - du beschreibst, was du willst, nicht wie es berechnet wird.
2
Joins verbinden Tabellen; entscheidend ist die ON-Bedingung, sonst entsteht ein kartesisches Produkt.
SQL-Join-Typen als Mengen-Venn
Abb.INNER, LEFT, RIGHT und FULL OUTER JOIN visualisiert.
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.

Deine Antwortwird nicht automatisch bewertet

Typische Fehler

SELECT ohne FROM-Klausel (Sonderfall, oft nicht erlaubt).
WHERE und HAVING verwechselt (HAVING für Aggregate, WHERE für Zeilen).
Implizite Joins ohne ON-Bedingung -> kartesisches Produkt.

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.

Aktiv abrufen

Erinnere dich an die Kernpunkte — dann aufdecken.

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

Transaktionen und ACID#

VertiefungINF-DB-4.1

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

Abb. 4Mit steigender Isolationsstufe werden mehr Anomalien ausgeschlossen - auf Kosten der Parallelität.

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.

Musterbeispiel

Banktransaktion in SQL

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

Start
`BEGIN TRANSACTION;`
Abbuchen
`UPDATE Konto SET Saldo = Saldo - 100 WHERE KNr = 'A';`
Prüfung
Wenn Saldo < 0 -> `ROLLBACK;` und Fehler ausgeben.
Gutschrift
`UPDATE Konto SET Saldo = Saldo + 100 WHERE KNr = 'B';`
Abschluss
`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
ACID ist das Versprechen, das relationale Datenbanken seit Jahrzehnten machen.
2
Stell dir Atomicity wie eine "Alles-oder-Nichts"-Schaltung vor: entweder das gesamte Update zählt, oder gar nichts.
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.

Deine Antwortwird nicht automatisch bewertet

Typische Fehler

Atomicity und Consistency werden synonym verwendet.
Isolationslevel wird mit Sicherheitslevel (Berechtigungen) verwechselt.
Deadlock wird nicht von Livelock unterschieden.

Aktive Wiederholung

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

Aktiv abrufen

Erinnere dich an die Kernpunkte — dann aufdecken.

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

NoSQL-Datenbanken und CAP-Theorem#

VertiefungINF-DB-5.1

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

Abb. 5Vier Hauptklassen mit ihrem Datenmodell und typischen Einsatzgebieten.

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.

Musterbeispiel

CAP-Entscheidung an Beispielen

Welche CAP-Tradeoffs gehen typische Systeme ein?

CP-System
MongoDB (Single Replica Set), HBase: bei Partition werden Schreibvorgänge blockiert -> Konsistenz, aber kurze Nicht-Verfügbarkeit.
AP-System
Cassandra, DynamoDB: schreiben immer, akzeptieren später Konsistenz (eventual consistency).
CA-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
NoSQL ist nicht Anti-SQL - es ist eine Ergänzung für spezielle Anforderungen.
2
Das CAP-Theorem ist ein scharfes mathematisches Ergebnis: in verteilten Systemen gibt es keinen Gratisluxus.
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.

Deine Antwortwird nicht automatisch bewertet

Typische Fehler

NoSQL als "kein SQL" wortwörtlich genommen (richtig: "Not only SQL").
Relationale Datenbanken werden als veraltet bezeichnet.
CAP wird so verstanden, dass eine der drei Eigenschaften "fehlt".

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.

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.)

Indizes und Anfrageoptimierung#

VertiefungINF-DB-3.1INF-DB-3.2

Ohne Hilfsstruktur muss die Datenbank für jede Suche die ganze Tabelle durchlesen (Full Table Scan,

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

Abb. 6Ein Index beschleunigt das Lesen drastisch, belastet aber Schreiboperationen und Speicher.

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)

Schritte statt

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.

T_{\text{Index}} = O(\log_{b} n) \ll T_{\text{Scan}} = O(n)

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

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`.

Schritt 1 - Ist-Zustand
Ohne Index: Full Table Scan über 2 Mio. Zeilen, $O(n)$ - bei jeder Abfrage werden alle Zeilen gelesen.
Schritt 2 - Index anlegen
`CREATE INDEX idx_kunde ON Bestellung(KundenNr);` baut einen B+-Baum über die Spalte.
Schritt 3 - Lesegewinn
Suche sinkt auf $O(\log n) \approx 21$ Vergleiche statt 2 Mio. - drastisch schneller.
Schritt 4 - Kosten
Jeder `INSERT`/`UPDATE` von `KundenNr` muss den Index mitpflegen; zusätzlicher Speicher für den B+-Baum.
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)$ auf $O(\log n)$ ; 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?

Schritt 1
`WHERE Nachname = 'Huber'` - nutzt den Index (Linksprefix erfüllt).
Schritt 2
`WHERE Nachname = 'Huber' AND Vorname = 'Anna'` - nutzt den Index voll.
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
Ein Index ist wie das Stichwortverzeichnis eines Buches: man muss nicht jede Seite durchblättern.
2
Der Gewinn beim Lesen ( $O(\log n)$ ) wird mit Mehraufwand beim Schreiben erkauft - deshalb nicht jede Spalte indizieren.
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.

Deine Antwortwird nicht automatisch bewertet

Typische Fehler

Annahme, mehr Indizes seien immer besser - jeder Index bremst Schreiboperationen und kostet Platz.
Funktion auf der indizierten Spalte im `WHERE` (z.B. `WHERE YEAR(datum)=2024`) macht den Index unbrauchbar.
Zusammengesetzten Index falsch herum genutzt (Abfrage nur auf der zweiten Spalte).
Index mit Primärschlüssel gleichgesetzt - ein Index ist nicht eindeutig, ein Schlüssel schon.

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.

Aktiv abrufen

Erinnere dich an die Kernpunkte — dann aufdecken.

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