DE-Abitur · InformatikT·044 / 8

Daten und Datenbanken — ER-Modell, Relationenmodell, SQL, Normalisierung

Die EPA Informatik verlangt das systematische Modellieren realweltlicher Daten im ER-Modell, die Überführung in das Relationenmodell, die Normalisierung bis 3NF sowie die sichere Abfrage und Manipulation mit SQL. Datenschutz und DSGVO sind in allen Bundesländern explizit verankert.

6Abschnitteca. 8Min Lesezeit3Kompetenzen

KB-MI · Modellieren und Implementieren — Datenmodelle entwerfen und in SQL umsetzen.KB-SD · Strukturieren und Darstellen — ER-Diagramme und relationale Schemata präzise notieren.KB-BB · Begründen und Bewerten — Anomalien und Normalformverletzungen erkennen, Datenschutzaspekte reflektieren.

Operatoren:modellieren · analysieren · implementieren · beurteilen · erläutern

grundlegendes Niveau

gA: ER-Diagramm zu einem Anwendungsfall zeichnen, SQL-SELECT/WHERE/ORDER BY auf einer Tabelle anwenden, 1NF/2NF prüfen.

erhöhtes Niveau

eA: Komplexe Joins (INNER, LEFT, FULL), Subqueries und Aggregatfunktionen formulieren, 3NF und BCNF unterscheiden, Indexstrategien beurteilen.

Inhalt · 6 Abschnitte

Daten und Datenbanken — ER-Modell, Relationenmodell, SQL, Normalisierung

ER-Modell — Entitäten, Beziehungen, Kardinalitäten#

BasisKMK-EPA-Inf-ModellierenNRW-IF3BY-Inf-4

Kernpunkte

Entity-Relationship-Modell (Chen 1976): Entität (Rechteck), Attribut (Ellipse), Beziehung (Raute), Schlüsselattribut unterstrichen.
Kardinalitäten: 1:1, 1:n, n:m — beschreiben, wie viele Instanzen einer Entität an einer Beziehung teilnehmen.
Min-Max-Notation präzisiert: (1,1) genau einmal, (0,*) optional beliebig oft.
Schwache Entitäten existieren nur mit zugeordneter starker Entität (z.B. Rechnungsposition zu Rechnung).
Spezialisierung/Generalisierung modellieren Vererbung im ER (analog OOP-Klassenhierarchie).
Vor der Implementation immer ein ER-Diagramm zeichnen — verhindert Datenredundanz und Anomalien.

ER-DIAGRAMM: SCHÜLER — BELEGT — KURS

Welche drei Beschriftungen in "ER-Diagramm: Schüler — belegt — Kurs" sind prüfungsrelevant?

Folgeaufgabe: Skizziere dasselbe Schema ohne Beschriftungen und ergänze sie aus dem Gedächtnis.

Klassischer Chen-Notation-ER-Ausschnitt; Beziehung „belegt" trägt das Attribut Note und ist n:m (wird später über die Verknüpfungstabelle Belegt aufgelöst).

Typische Fehler

Beziehung als Entität modelliert oder umgekehrt.
Kardinalitäten verkehrt notiert (Java/UML- vs. Chen-Konvention).
Schlüsselattribut vergessen — keine eindeutige Identifikation möglich.

Relationenmodell und Normalisierung (1NF–3NF)#

StandardKMK-EPA-Inf-ImplementierenNRW-IF3BY-Inf-4

Kernpunkte

Eine Relation ist eine Menge von Tupeln mit festem Schema; Primärschlüssel identifiziert eindeutig, Fremdschlüssel verweist auf Primärschlüssel einer anderen Relation.
Überführung ER → Relationenmodell: Jede Entität wird Tabelle; 1:n-Beziehung integriert Fremdschlüssel in „n"-Seite; n:m-Beziehung wird eigene Verknüpfungstabelle.
1. Normalform (1NF): alle Attributwerte atomar — keine Listen, keine Mehrfachwerte.
2. Normalform (2NF): 1NF + jedes Nicht-Schlüsselattribut hängt voll vom Primärschlüssel ab (relevant bei zusammengesetzten Schlüsseln).
3. Normalform (3NF): 2NF + keine transitiven Abhängigkeiten (kein Nicht-Schlüssel-Attribut hängt von einem anderen Nicht-Schlüssel-Attribut ab).
Normalisierung reduziert Redundanz und vermeidet Update-/Insert-/Delete-Anomalien — kann aber Joins verlangsamen.
Querverweis: Die ER-Spezialisierung/Generalisierung entspricht der Vererbungshierarchie aus dem Topic Objektorientierte Modellierung; ein ER-Modell lässt sich analog zum UML-Klassendiagramm lesen.

Musterlösung

Tabelle in 3. Normalform überführen

Gegeben sei die Relation Bestellung(BestellNr, KundenNr, KundenName, ArtikelNr, Bezeichnung, Menge). Normalisieren Sie bis zur 3NF.

Schritt 1 — 1NF prüfen
Alle Attribute atomar — 1NF erfüllt. Primärschlüssel: (BestellNr, ArtikelNr).
Schritt 2 — 2NF: partielle Abhängigkeiten lösen
KundenNr und Bezeichnung hängen nur von Teilen des Schlüssels ab. Aufteilen in Bestellung(BestellNr, KundenNr, KundenName), Position(BestellNr, ArtikelNr, Menge), Artikel(ArtikelNr, Bezeichnung).
Schritt 3 — 3NF: transitive Abhängigkeiten lösen
KundenName ist von KundenNr abhängig (transitiv über BestellNr). Auslagern in Kunde(KundenNr, KundenName); Bestellung enthält nur noch (BestellNr, KundenNr).
Schritt 4 — Endresultat
Vier Relationen: Kunde, Bestellung, Position (Beziehungstabelle), Artikel. Fremdschlüssel verknüpfen die Tabellen.

Ergebnis: Zerlegung in vier 3NF-Relationen; jede Tabelle erfüllt 1NF, 2NF und 3NF.

Typische Fehler

1NF mit „keine Duplikate" verwechselt — gemeint ist atomar.
2NF auf Tabellen mit einfachem Primärschlüssel geprüft — dort folgt 2NF automatisch.
3NF und BCNF gleichgesetzt; BCNF ist strenger.

LK-Vertiefung

eA-Vertiefung: Erläutern Sie den Unterschied zwischen 3NF und BCNF an einem Beispiel mit überlappenden Schlüsselkandidaten.

SQL — SELECT, WHERE, ORDER BY, INSERT, UPDATE, DELETE#

BasisKMK-EPA-Inf-ImplementierenNRW-IF3BY-Inf-4

Kernpunkte

SQL gliedert sich in DDL (CREATE, ALTER, DROP), DML (SELECT, INSERT, UPDATE, DELETE) und DCL (GRANT, REVOKE).
SELECT-Struktur: ```sql SELECT spalten FROM tabelle WHERE bedingung GROUP BY spalte HAVING aggregat-bedingung ORDER BY spalte ASC|DESC; ```
Aggregatfunktionen: COUNT, SUM, AVG, MIN, MAX — meist kombiniert mit GROUP BY.
LIKE mit `%` (beliebig viele Zeichen) und `_` (genau ein Zeichen) für Mustersuche.
NULL ist nicht gleich leerer String — Prüfung mit `IS NULL`/`IS NOT NULL`, niemals `= NULL`.
Beispiel: ```sql SELECT KundenNr, SUM(Betrag) AS Umsatz FROM Bestellung WHERE Datum >= '2025-01-01' GROUP BY KundenNr HAVING SUM(Betrag) > 1000 ORDER BY Umsatz DESC; ```

Typische Fehler

`= NULL` statt `IS NULL` verwendet — liefert immer unknown.
Aggregatfunktion in WHERE — gehört in HAVING.
Spaltenalias in WHERE referenziert — die Spalte ist dort noch nicht definiert.

SQL — Joins, Subqueries und Indizes#

VertiefungNRW-IF3BY-Inf-4BW-Inf-5

Kernpunkte

INNER JOIN: nur Tupel mit Match in beiden Tabellen.
LEFT OUTER JOIN: alle Tupel der linken Tabelle, NULL bei fehlendem Match rechts; analog RIGHT/FULL.
CROSS JOIN = kartesisches Produkt; selten direkt verwendet.
Theta-Join wird in der Relationenalgebra als σ(R × S) formuliert — Equi-Join ist Spezialfall mit Gleichheitsprädikat.
Subqueries: skalar (liefern einen Wert), zeilenweise (`IN`, `EXISTS`), korreliert (Outer-Query-Referenz in Inner-Query).
Indizes beschleunigen WHERE/JOIN auf indexierten Spalten in O(log n), kosten aber Schreibperformance — typisch B-Baum, in MySQL auch Hash-Index.

THETA-JOIN DER RELATIONENALGEBRA

R \bowtie_{\theta} S = \sigma_{\theta}(R \times S)

Verbindet R und S über das Prädikat θ; Spezialfall Equi-Join, wenn θ Gleichheit prüft.

B-BAUM-INDEX (ORDNUNG 3) FÜR DATENBANKZUGRIFFE

Welche drei Beschriftungen in "B-Baum-Index (Ordnung 3) für Datenbankzugriffe" sind prüfungsrelevant?

Folgeaufgabe: Skizziere dasselbe Schema ohne Beschriftungen und ergänze sie aus dem Gedächtnis.

Mehrwege-Suchbaum mit sortierten Schlüsseln je Knoten; balanciert, daher Zugriff in O(log n) auch bei Millionen Datensätzen.

Musterlösung

SQL-Inner-Join über Schüler und Kurs

Geben Sie eine SQL-Abfrage an, die alle Schülernamen zusammen mit den belegten Kurstiteln liefert; sortieren Sie nach Schülername.

Schritt 1 — Tabellen identifizieren
Schüler(SNr, Name), Belegt(SNr, KNr, Note), Kurs(KNr, Titel). Belegt ist Beziehungstabelle aus dem ER-Diagramm.
Schritt 2 — Join-Pfad festlegen
Zweimaliger Join: Schüler ⨝ Belegt über SNr, Belegt ⨝ Kurs über KNr.
Schritt 3 — SQL-Statement
```sql SELECT s.Name, k.Titel FROM Schüler s JOIN Belegt b ON b.SNr = s.SNr JOIN Kurs k ON k.KNr = b.KNr ORDER BY s.Name; ```
Schritt 4 — Erwartungshorizont
Equi-Join über Fremdschlüssel; Sortierung in O(n log n); kein DISTINCT nötig, falls eine Schüler-Kurs-Kombination eindeutig ist.

Ergebnis: Inner-Join-Pfad über die Beziehungstabelle Belegt; sortiertes Ergebnis nach Schülername.

Typische Fehler

INNER JOIN ohne ON-Klausel → kartesisches Produkt.
Korrelierte Subquery mit Performance-Problemen, wenn äquivalenter JOIN möglich wäre.
Index auf Spalten mit wenigen distinct values (z.B. Geschlecht) — geringer Nutzen.

LK-Vertiefung

eA-Vertiefung: Beurteilen Sie, in welchen Fällen ein zusammengesetzter Index `(KundenNr, Datum)` schneller ist als zwei einzelne Indizes.

Datenschutz, DSGVO und Datenbankethik#

StandardKMK-EPA-Inf-BewertenNRW-IF6BY-Inf-4

Kernpunkte

DSGVO (EU-Verordnung 2016/679, gilt seit Mai 2018) regelt Verarbeitung personenbezogener Daten; Verstöße bis 4 % Jahresumsatz oder 20 Mio. €.
Grundprinzipien: Rechtmäßigkeit, Zweckbindung, Datenminimierung, Richtigkeit, Speicherbegrenzung, Integrität, Rechenschaftspflicht.
Rechte der Betroffenen: Auskunft (Art. 15), Berichtigung (Art. 16), Löschung (Art. 17), Datenübertragbarkeit (Art. 20), Widerspruch (Art. 21).
Privacy by Design / Privacy by Default verlangen datenschutzfreundliche Voreinstellungen und systemische Schutzmaßnahmen.
Pseudonymisierung (Re-Identifikation möglich mit Schlüssel) vs. Anonymisierung (irreversibel) — nur Anonymisierung entzieht der DSGVO.
Verschlüsselung at-rest (Datenbank) und in-transit (TLS) sind Standardmaßnahmen.

Typische Fehler

DSGVO und BDSG verwechselt — DSGVO ist EU-Recht, BDSG ist deutsches Ausführungsgesetz.
„Anonymisiert" sagen, obwohl re-identifizierbar — tatsächlich pseudonymisiert.
Backups beim Löschrecht vergessen — auch dort muss eine Löschstrategie greifen.

Transaktionen, ACID und Mehrbenutzerbetrieb#

VertiefungNRW-IF3BY-Inf-4BW-Inf-5

Kernpunkte

Eine Transaktion ist eine logisch zusammengehörige Folge von Datenbankoperationen, die atomar ausgeführt werden — Beispiel: Überweisung als Abbuchung + Gutschrift.
ACID: Atomarität (alles oder nichts), Konsistenz (Integritätsbedingungen bleiben gewahrt), Isolation (parallele Transaktionen stören sich nicht), Dauerhaftigkeit (bestätigte Änderungen überdauern Abstürze).
Abschluss über `COMMIT` (dauerhaft schreiben) oder `ROLLBACK` (alle Änderungen verwerfen); ein Recovery-Manager stellt nach Absturz den konsistenten Zustand her (Logging, WAL).
Im Mehrbenutzerbetrieb entstehen Anomalien: Lost Update, Dirty Read, Non-Repeatable Read, Phantom Read — sie werden durch Isolationsstufen gesteuert.
Isolationsstufen (ANSI): Read Uncommitted, Read Committed, Repeatable Read, Serializable — höhere Stufen schließen mehr Anomalien aus, kosten aber Parallelität.
Sperrverfahren: Zwei-Phasen-Sperrprotokoll (2PL) garantiert Serialisierbarkeit; Sperren können zu Deadlocks führen, die per Timeout oder Wartegraph aufgelöst werden.
SQL-Beispiel: ```sql BEGIN TRANSACTION; UPDATE Konto SET Saldo = Saldo - 100 WHERE Nr = 1; UPDATE Konto SET Saldo = Saldo + 100 WHERE Nr = 2; COMMIT; ```

Typische Fehler

Konsistenz mit Isolation verwechselt — Konsistenz betrifft Integritätsregeln, Isolation die Nebenläufigkeit.
COMMIT vergessen — Änderungen bleiben offen oder werden bei Verbindungsabbruch zurückgerollt.
Serializable pauschal fordern — höchste Isolation kostet Durchsatz; oft genügt Read Committed.
Deadlock mit Endlosschleife gleichgesetzt — ein Deadlock ist gegenseitiges Sperrenwarten.

LK-Vertiefung

eA-Vertiefung: Erläutern Sie das strenge Zwei-Phasen-Sperrprotokoll und begründen Sie, warum es Serialisierbarkeit garantiert, aber Deadlocks nicht ausschließt.

Wird geladen

EuraStudy

Dein Lernraum wird vorbereitet — Curriculum, Notizen und KI verbinden sich.

Daten und Datenbanken — ER-Modell, Relationenmodell, SQL, Normalisierung

6Abschnitteca. 8Min Lesezeit3Kompetenzen

Operatoren:modellieren · analysieren · implementieren · beurteilen · erläutern

grundlegendes Niveau

gA: ER-Diagramm zu einem Anwendungsfall zeichnen, SQL-SELECT/WHERE/ORDER BY auf einer Tabelle anwenden, 1NF/2NF prüfen.

erhöhtes Niveau

eA: Komplexe Joins (INNER, LEFT, FULL), Subqueries und Aggregatfunktionen formulieren, 3NF und BCNF unterscheiden, Indexstrategien beurteilen.

ER-Modell — Entitäten, Beziehungen, Kardinalitäten#

BasisKMK-EPA-Inf-ModellierenNRW-IF3BY-Inf-4

Kernpunkte

Entity-Relationship-Modell (Chen 1976): Entität (Rechteck), Attribut (Ellipse), Beziehung (Raute), Schlüsselattribut unterstrichen.
Kardinalitäten: 1:1, 1:n, n:m — beschreiben, wie viele Instanzen einer Entität an einer Beziehung teilnehmen.
Min-Max-Notation präzisiert: (1,1) genau einmal, (0,*) optional beliebig oft.
Schwache Entitäten existieren nur mit zugeordneter starker Entität (z.B. Rechnungsposition zu Rechnung).
Spezialisierung/Generalisierung modellieren Vererbung im ER (analog OOP-Klassenhierarchie).
Vor der Implementation immer ein ER-Diagramm zeichnen — verhindert Datenredundanz und Anomalien.

ER-DIAGRAMM: SCHÜLER — BELEGT — KURS

Welche drei Beschriftungen in "ER-Diagramm: Schüler — belegt — Kurs" sind prüfungsrelevant?

Folgeaufgabe: Skizziere dasselbe Schema ohne Beschriftungen und ergänze sie aus dem Gedächtnis.

Klassischer Chen-Notation-ER-Ausschnitt; Beziehung „belegt" trägt das Attribut Note und ist n:m (wird später über die Verknüpfungstabelle Belegt aufgelöst).

Typische Fehler

Beziehung als Entität modelliert oder umgekehrt.
Kardinalitäten verkehrt notiert (Java/UML- vs. Chen-Konvention).
Schlüsselattribut vergessen — keine eindeutige Identifikation möglich.

Relationenmodell und Normalisierung (1NF–3NF)#

StandardKMK-EPA-Inf-ImplementierenNRW-IF3BY-Inf-4

Kernpunkte

Eine Relation ist eine Menge von Tupeln mit festem Schema; Primärschlüssel identifiziert eindeutig, Fremdschlüssel verweist auf Primärschlüssel einer anderen Relation.
Überführung ER → Relationenmodell: Jede Entität wird Tabelle; 1:n-Beziehung integriert Fremdschlüssel in „n"-Seite; n:m-Beziehung wird eigene Verknüpfungstabelle.
1. Normalform (1NF): alle Attributwerte atomar — keine Listen, keine Mehrfachwerte.
2. Normalform (2NF): 1NF + jedes Nicht-Schlüsselattribut hängt voll vom Primärschlüssel ab (relevant bei zusammengesetzten Schlüsseln).
3. Normalform (3NF): 2NF + keine transitiven Abhängigkeiten (kein Nicht-Schlüssel-Attribut hängt von einem anderen Nicht-Schlüssel-Attribut ab).
Normalisierung reduziert Redundanz und vermeidet Update-/Insert-/Delete-Anomalien — kann aber Joins verlangsamen.
Querverweis: Die ER-Spezialisierung/Generalisierung entspricht der Vererbungshierarchie aus dem Topic Objektorientierte Modellierung; ein ER-Modell lässt sich analog zum UML-Klassendiagramm lesen.

Musterlösung

Tabelle in 3. Normalform überführen

Gegeben sei die Relation Bestellung(BestellNr, KundenNr, KundenName, ArtikelNr, Bezeichnung, Menge). Normalisieren Sie bis zur 3NF.

Schritt 1 — 1NF prüfen
Alle Attribute atomar — 1NF erfüllt. Primärschlüssel: (BestellNr, ArtikelNr).
Schritt 2 — 2NF: partielle Abhängigkeiten lösen
KundenNr und Bezeichnung hängen nur von Teilen des Schlüssels ab. Aufteilen in Bestellung(BestellNr, KundenNr, KundenName), Position(BestellNr, ArtikelNr, Menge), Artikel(ArtikelNr, Bezeichnung).
Schritt 3 — 3NF: transitive Abhängigkeiten lösen
KundenName ist von KundenNr abhängig (transitiv über BestellNr). Auslagern in Kunde(KundenNr, KundenName); Bestellung enthält nur noch (BestellNr, KundenNr).
Schritt 4 — Endresultat
Vier Relationen: Kunde, Bestellung, Position (Beziehungstabelle), Artikel. Fremdschlüssel verknüpfen die Tabellen.

Ergebnis: Zerlegung in vier 3NF-Relationen; jede Tabelle erfüllt 1NF, 2NF und 3NF.

Typische Fehler

1NF mit „keine Duplikate" verwechselt — gemeint ist atomar.
2NF auf Tabellen mit einfachem Primärschlüssel geprüft — dort folgt 2NF automatisch.
3NF und BCNF gleichgesetzt; BCNF ist strenger.

LK-Vertiefung

eA-Vertiefung: Erläutern Sie den Unterschied zwischen 3NF und BCNF an einem Beispiel mit überlappenden Schlüsselkandidaten.

SQL — SELECT, WHERE, ORDER BY, INSERT, UPDATE, DELETE#

BasisKMK-EPA-Inf-ImplementierenNRW-IF3BY-Inf-4

Kernpunkte

SQL gliedert sich in DDL (CREATE, ALTER, DROP), DML (SELECT, INSERT, UPDATE, DELETE) und DCL (GRANT, REVOKE).
SELECT-Struktur: ```sql SELECT spalten FROM tabelle WHERE bedingung GROUP BY spalte HAVING aggregat-bedingung ORDER BY spalte ASC|DESC; ```
Aggregatfunktionen: COUNT, SUM, AVG, MIN, MAX — meist kombiniert mit GROUP BY.
LIKE mit `%` (beliebig viele Zeichen) und `_` (genau ein Zeichen) für Mustersuche.
NULL ist nicht gleich leerer String — Prüfung mit `IS NULL`/`IS NOT NULL`, niemals `= NULL`.
Beispiel: ```sql SELECT KundenNr, SUM(Betrag) AS Umsatz FROM Bestellung WHERE Datum >= '2025-01-01' GROUP BY KundenNr HAVING SUM(Betrag) > 1000 ORDER BY Umsatz DESC; ```

Typische Fehler

`= NULL` statt `IS NULL` verwendet — liefert immer unknown.
Aggregatfunktion in WHERE — gehört in HAVING.
Spaltenalias in WHERE referenziert — die Spalte ist dort noch nicht definiert.

SQL — Joins, Subqueries und Indizes#

VertiefungNRW-IF3BY-Inf-4BW-Inf-5

Kernpunkte

INNER JOIN: nur Tupel mit Match in beiden Tabellen.
LEFT OUTER JOIN: alle Tupel der linken Tabelle, NULL bei fehlendem Match rechts; analog RIGHT/FULL.
CROSS JOIN = kartesisches Produkt; selten direkt verwendet.
Theta-Join wird in der Relationenalgebra als σ(R × S) formuliert — Equi-Join ist Spezialfall mit Gleichheitsprädikat.
Subqueries: skalar (liefern einen Wert), zeilenweise (`IN`, `EXISTS`), korreliert (Outer-Query-Referenz in Inner-Query).
Indizes beschleunigen WHERE/JOIN auf indexierten Spalten in O(log n), kosten aber Schreibperformance — typisch B-Baum, in MySQL auch Hash-Index.

THETA-JOIN DER RELATIONENALGEBRA

R \bowtie_{\theta} S = \sigma_{\theta}(R \times S)

Verbindet R und S über das Prädikat θ; Spezialfall Equi-Join, wenn θ Gleichheit prüft.

B-BAUM-INDEX (ORDNUNG 3) FÜR DATENBANKZUGRIFFE

Welche drei Beschriftungen in "B-Baum-Index (Ordnung 3) für Datenbankzugriffe" sind prüfungsrelevant?

Folgeaufgabe: Skizziere dasselbe Schema ohne Beschriftungen und ergänze sie aus dem Gedächtnis.

Mehrwege-Suchbaum mit sortierten Schlüsseln je Knoten; balanciert, daher Zugriff in O(log n) auch bei Millionen Datensätzen.

Musterlösung

SQL-Inner-Join über Schüler und Kurs

Geben Sie eine SQL-Abfrage an, die alle Schülernamen zusammen mit den belegten Kurstiteln liefert; sortieren Sie nach Schülername.

Schritt 1 — Tabellen identifizieren
Schüler(SNr, Name), Belegt(SNr, KNr, Note), Kurs(KNr, Titel). Belegt ist Beziehungstabelle aus dem ER-Diagramm.
Schritt 2 — Join-Pfad festlegen
Zweimaliger Join: Schüler ⨝ Belegt über SNr, Belegt ⨝ Kurs über KNr.
Schritt 3 — SQL-Statement
```sql SELECT s.Name, k.Titel FROM Schüler s JOIN Belegt b ON b.SNr = s.SNr JOIN Kurs k ON k.KNr = b.KNr ORDER BY s.Name; ```
Schritt 4 — Erwartungshorizont
Equi-Join über Fremdschlüssel; Sortierung in O(n log n); kein DISTINCT nötig, falls eine Schüler-Kurs-Kombination eindeutig ist.

Ergebnis: Inner-Join-Pfad über die Beziehungstabelle Belegt; sortiertes Ergebnis nach Schülername.

Typische Fehler

INNER JOIN ohne ON-Klausel → kartesisches Produkt.
Korrelierte Subquery mit Performance-Problemen, wenn äquivalenter JOIN möglich wäre.
Index auf Spalten mit wenigen distinct values (z.B. Geschlecht) — geringer Nutzen.

LK-Vertiefung

eA-Vertiefung: Beurteilen Sie, in welchen Fällen ein zusammengesetzter Index `(KundenNr, Datum)` schneller ist als zwei einzelne Indizes.

Datenschutz, DSGVO und Datenbankethik#

StandardKMK-EPA-Inf-BewertenNRW-IF6BY-Inf-4

Kernpunkte

DSGVO (EU-Verordnung 2016/679, gilt seit Mai 2018) regelt Verarbeitung personenbezogener Daten; Verstöße bis 4 % Jahresumsatz oder 20 Mio. €.
Grundprinzipien: Rechtmäßigkeit, Zweckbindung, Datenminimierung, Richtigkeit, Speicherbegrenzung, Integrität, Rechenschaftspflicht.
Rechte der Betroffenen: Auskunft (Art. 15), Berichtigung (Art. 16), Löschung (Art. 17), Datenübertragbarkeit (Art. 20), Widerspruch (Art. 21).
Privacy by Design / Privacy by Default verlangen datenschutzfreundliche Voreinstellungen und systemische Schutzmaßnahmen.
Pseudonymisierung (Re-Identifikation möglich mit Schlüssel) vs. Anonymisierung (irreversibel) — nur Anonymisierung entzieht der DSGVO.
Verschlüsselung at-rest (Datenbank) und in-transit (TLS) sind Standardmaßnahmen.

Typische Fehler

DSGVO und BDSG verwechselt — DSGVO ist EU-Recht, BDSG ist deutsches Ausführungsgesetz.
„Anonymisiert" sagen, obwohl re-identifizierbar — tatsächlich pseudonymisiert.
Backups beim Löschrecht vergessen — auch dort muss eine Löschstrategie greifen.

Transaktionen, ACID und Mehrbenutzerbetrieb#

VertiefungNRW-IF3BY-Inf-4BW-Inf-5

Kernpunkte

Eine Transaktion ist eine logisch zusammengehörige Folge von Datenbankoperationen, die atomar ausgeführt werden — Beispiel: Überweisung als Abbuchung + Gutschrift.
ACID: Atomarität (alles oder nichts), Konsistenz (Integritätsbedingungen bleiben gewahrt), Isolation (parallele Transaktionen stören sich nicht), Dauerhaftigkeit (bestätigte Änderungen überdauern Abstürze).
Abschluss über `COMMIT` (dauerhaft schreiben) oder `ROLLBACK` (alle Änderungen verwerfen); ein Recovery-Manager stellt nach Absturz den konsistenten Zustand her (Logging, WAL).
Im Mehrbenutzerbetrieb entstehen Anomalien: Lost Update, Dirty Read, Non-Repeatable Read, Phantom Read — sie werden durch Isolationsstufen gesteuert.
Isolationsstufen (ANSI): Read Uncommitted, Read Committed, Repeatable Read, Serializable — höhere Stufen schließen mehr Anomalien aus, kosten aber Parallelität.
Sperrverfahren: Zwei-Phasen-Sperrprotokoll (2PL) garantiert Serialisierbarkeit; Sperren können zu Deadlocks führen, die per Timeout oder Wartegraph aufgelöst werden.
SQL-Beispiel: ```sql BEGIN TRANSACTION; UPDATE Konto SET Saldo = Saldo - 100 WHERE Nr = 1; UPDATE Konto SET Saldo = Saldo + 100 WHERE Nr = 2; COMMIT; ```

Typische Fehler

Konsistenz mit Isolation verwechselt — Konsistenz betrifft Integritätsregeln, Isolation die Nebenläufigkeit.
COMMIT vergessen — Änderungen bleiben offen oder werden bei Verbindungsabbruch zurückgerollt.
Serializable pauschal fordern — höchste Isolation kostet Durchsatz; oft genügt Read Committed.
Deadlock mit Endlosschleife gleichgesetzt — ein Deadlock ist gegenseitiges Sperrenwarten.

LK-Vertiefung

eA-Vertiefung: Erläutern Sie das strenge Zwei-Phasen-Sperrprotokoll und begründen Sie, warum es Serialisierbarkeit garantiert, aber Deadlocks nicht ausschließt.