Notizen · InformatikDE · Abitur

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. 18Min Lesezeit3KompetenzenNiveauBasis 2 · Standard 2 · Vertiefung 2Stand 06/2026

T·0444 / 8

Prüfungsprofil

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:modellierenanalysierenimplementierenbeurteilenerlä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.

Tiefe

Schrift

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

ER-Diagramm: Schüler — belegt — Kurs

Abb. 1Klassischer 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).

Das Entity-Relationship-Modell (Peter Chen 1976) ist die Standardmethode, um die Daten eines Anwendungsbereichs vor der Implementierung konzeptuell zu modellieren. Seine grafischen Bausteine in Chen-Notation: Entität (Rechteck — ein unterscheidbares Objekt der realen Welt, etwa Schüler), Attribut (Ellipse — eine Eigenschaft), Beziehung (Raute — eine Verknüpfung zwischen Entitäten) und das Schlüsselattribut (unterstrichen — identifiziert eine Entität eindeutig).

Die Kardinalitäten einer Beziehung geben an, wie viele Instanzen der einen Entität mit wie vielen der anderen verknüpft sein können: 1:1, 1:n und n:m. Beispiel: Ein Kunde gibt viele Bestellungen auf, jede Bestellung gehört einem Kunden (1:n); ein Schüler belegt viele Kurse, jeder Kurs hat viele Schüler (n:m).

Die (min,max)-Notation präzisiert die Kardinalität pro Entität: Sie gibt an, an wie wenigen und wie vielen Beziehungen eine Instanz mindestens und höchstens teilnimmt — (1,1) genau einmal (Pflicht, eindeutig), (0,) optional beliebig oft. Sie erfasst damit zusätzlich die Teilnahmepflicht*, die die einfache 1:n-Angabe nicht zeigt. Achtung: Chen-(min,max) und die UML-Multiplizität werden an gegenüberliegenden Enden notiert — eine häufige Verwechslungsquelle.

Eine schwache Entität kann nicht allein durch eigene Attribute identifiziert werden, sondern nur in Abhängigkeit von einer starken Entität (z. B. eine Rechnungsposition nur im Kontext ihrer Rechnung). Sie wird durch doppelte Umrandung dargestellt und erbt einen Teil ihres Schlüssels von der starken Entität.

Wie in der OOP lassen sich Entitäten spezialisieren/generalisieren: Eine Oberentität (Person) wird in Unterentitäten (Schüler, Lehrkraft) aufgegliedert, die deren Attribute erben und eigene ergänzen — das ER-Pendant zur Klassenhierarchie (Querverweis OOP).

Ein sauberes ER-Diagramm vor der Implementierung verhindert Datenredundanz und die daraus folgenden Anomalien; es ist die konzeptuelle Stufe, die anschließend systematisch in das Relationenmodell überführt wird (nächster Abschnitt). Insbesondere wird jede n:m-Beziehung dort in eine eigene Verknüpfungstabelle aufgelöst.

Typische Fehler

Beziehung als Entität modelliert (oder umgekehrt) — Rechteck und Raute verwechselt.
Kardinalität am falschen Ende notiert (Chen-(min,max) vs. UML-Multiplizität).
Schlüsselattribut vergessen — keine eindeutige Identifikation der Entität möglich.
Schwache und starke Entität nicht unterschieden.

LK-Vertiefung

eA-Vertiefung: Überführen Sie ein ER-Modell mit einer n:m-Beziehung (z. B. Schüler–belegt–Kurs mit dem Beziehungsattribut Note) in das Relationenmodell und begründen Sie, warum die Beziehung samt ihrem Attribut eine eigene Tabelle mit zusammengesetztem Primärschlüssel erfordert.

Aktive Wiederholung

Modellieren Sie für eine Bibliothek die Entitäten `Buch`, `Leser`, `Ausleihe` mit allen Attributen, Kardinalitäten und Schlüsseln; stellen Sie das Ergebnis als ER-Diagramm dar.

Aktiv abrufen

Erinnere dich an die Kernpunkte — dann aufdecken.

Relationenmodell und Normalisierung (1NF–3NF)#

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

Das Relationenmodell (E. F. Codd, IBM, 1970) ist die theoretische Grundlage relationaler Datenbanken. Eine Relation (Tabelle) ist eine Menge von Tupeln (Zeilen) über einem festen Schema (den Spalten mit ihren Datentypen). Der Primärschlüssel identifiziert jedes Tupel eindeutig; ein Fremdschlüssel verweist auf den Primärschlüssel einer anderen Relation und stellt so die referenzielle Integrität zwischen Tabellen sicher.

Die Überführung ER → Relationenmodell folgt festen Regeln: Jede Entität wird eine Tabelle (Attribute → Spalten, Schlüsselattribut → Primärschlüssel). Eine 1:n-Beziehung wird realisiert, indem die „n"-Seite einen Fremdschlüssel auf die „1"-Seite erhält. Eine n:m-Beziehung verlangt eine eigene Verknüpfungstabelle, deren Primärschlüssel aus den beiden Fremdschlüsseln zusammengesetzt ist und die etwaige Beziehungsattribute aufnimmt.

Grundbegriff der Normalisierung ist die funktionale Abhängigkeit A → B („der Wert von A bestimmt den von B eindeutig"). Die erste Normalform (1NF) verlangt, dass alle Attributwerte atomar sind — keine Listen, Mengen oder zusammengesetzten Werte in einer Zelle. „Atomar" heißt unteilbar, nicht „keine Duplikate".

Die zweite Normalform (2NF) verlangt 1NF und dass jedes Nicht-Schlüssel-Attribut voll (nicht nur von einem Teil) vom Primärschlüssel abhängt. Sie ist nur bei zusammengesetzten Schlüsseln relevant: Hängt ein Attribut nur von einem Teil des Schlüssels ab (partielle Abhängigkeit), wird es in eine eigene Tabelle ausgelagert. Bei einfachem Primärschlüssel folgt 2NF automatisch.

Die dritte Normalform (3NF) verlangt 2NF und das Fehlen transitiver Abhängigkeiten: Kein Nicht-Schlüssel-Attribut darf von einem anderen Nicht-Schlüssel-Attribut abhängen (A → B → C). Hängt etwa KundenName von KundenNr und KundenNr von BestellNr ab, wird KundenName in eine eigene Kunde-Tabelle ausgelagert. Die strengere BCNF verlangt zusätzlich, dass die linke Seite jeder funktionalen Abhängigkeit ein Schlüsselkandidat ist.

Die Normalisierung zerlegt Tabellen so, dass jede Information genau einmal gespeichert wird, und beseitigt damit Redundanz und die daraus folgenden Anomalien: die Update-Anomalie (ein Wert muss an vielen Stellen geändert werden), die Insert-Anomalie (ein Datum lässt sich ohne ein anderes nicht einfügen) und die Delete-Anomalie (mit einem Datensatz gehen ungewollt weitere Informationen verloren). Der Preis ist, dass Abfragen die Daten per Join wieder zusammenführen müssen — ein bewusster Kompromiss zwischen Integrität und Abfragegeschwindigkeit.

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 die Atomarität der Werte.
2NF an Tabellen mit einfachem Primärschlüssel „geprüft" — dort gilt sie ohnehin automatisch.
3NF und BCNF gleichgesetzt — BCNF ist die strengere Form.
ER-Überführung falsch: 1:n als Verknüpfungstabelle statt als Fremdschlüssel auf der n-Seite.

LK-Vertiefung

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

Aktive Wiederholung

Analysieren Sie eine gegebene Tabelle `BestellungVoll(BestellNr, KundenNr, KundenName, ArtikelNr, ArtikelName, Menge)` auf Normalformverletzungen und überführen Sie sie nach 3NF.

Aktiv abrufen

Erinnere dich an die Kernpunkte — dann aufdecken.

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

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

SQL (Structured Query Language) ist die standardisierte (ANSI/ISO) Sprache relationaler Datenbanken; sie ist deklarativ — man beschreibt was man will, nicht wie es berechnet wird (das übernimmt der Anfrageoptimierer). SQL gliedert sich in DDL (Data Definition: `CREATE`, `ALTER`, `DROP` für Schemata), DML (Data Manipulation: `SELECT`, `INSERT`, `UPDATE`, `DELETE` für Daten) und DCL (Data Control: `GRANT`, `REVOKE` für Rechte).

Das Herzstück ist die `SELECT`-Anfrage mit fester Klauselstruktur: ```sql SELECT spalten FROM tabelle WHERE bedingung GROUP BY spalte HAVING aggregat-bedingung ORDER BY spalte ASC|DESC; ```

Entscheidend ist die logische Auswertungsreihenfolge, die von der Schreibreihenfolge abweicht: FROM → WHERE → GROUP BY → HAVING → SELECT → ORDER BY. Daher filtert WHERE einzelne Zeilen vor der Gruppierung, HAVING dagegen ganze Gruppen nach der Aggregation; ein in SELECT vergebener Spaltenalias ist in WHERE/HAVING noch unbekannt, in ORDER BY aber bereits nutzbar.

Die Aggregatfunktionen `COUNT`, `SUM`, `AVG`, `MIN`, `MAX` verdichten viele Zeilen zu einem Wert und werden meist mit GROUP BY je Gruppe berechnet (z. B. Umsatz je Kunde). Für die Mustersuche dient `LIKE` mit den Platzhaltern `%` (beliebig viele Zeichen) und `_` (genau ein Zeichen) — `WHERE Name LIKE 'A%'` findet alle mit A beginnenden Namen.

Der besondere Wert NULL steht für „unbekannt/nicht vorhanden" und ist nicht gleich dem leeren String oder der Zahl null. Vergleiche mit NULL ergeben in SQLs dreiwertiger Logik (true/false/unknown) stets unknown — deshalb prüft man mit `IS NULL`/`IS NOT NULL`, niemals mit `= 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; ```

Musterlösung

SQL-Aggregation mit GROUP BY und HAVING

Listen Sie alle Kunden mit einem Gesamtumsatz über 1000 € im Jahr 2025 auf, absteigend nach Umsatz sortiert.

Schritt 1 — Tabelle und Zielgröße
Gegeben sei Bestellung(BestellNr, KundenNr, Datum, Betrag). Gesucht ist je Kunde die Summe der Beträge, gefiltert auf das Jahr 2025 und auf Summen über 1000.
Schritt 2 — Zeilen vor der Aggregation filtern (WHERE)
Die Jahresbedingung betrifft einzelne Zeilen und gehört daher in die WHERE-Klausel: WHERE Datum >= '2025-01-01' AND Datum < '2026-01-01'.
Schritt 3 — Gruppieren und Aggregat filtern (HAVING)
GROUP BY KundenNr bildet je Kunde eine Gruppe; SUM(Betrag) aggregiert sie. Die Bedingung über das Aggregat steht in HAVING — nicht in WHERE: HAVING SUM(Betrag) > 1000.
Schritt 4 — Vollständige Abfrage und Auswertungsreihenfolge
```sql SELECT KundenNr, SUM(Betrag) AS Umsatz FROM Bestellung WHERE Datum >= '2025-01-01' AND Datum < '2026-01-01' GROUP BY KundenNr HAVING SUM(Betrag) > 1000 ORDER BY Umsatz DESC; ``` Logisch wird FROM → WHERE → GROUP BY → HAVING → SELECT → ORDER BY ausgewertet; deshalb ist der SELECT-Alias „Umsatz" in WHERE/HAVING noch unbekannt, in ORDER BY aber bereits nutzbar.

Ergebnis: WHERE filtert Zeilen vor, HAVING filtert Gruppen nach der Aggregation; Sortierung absteigend nach dem Aggregat.

Typische Fehler

`= NULL` statt `IS NULL` verwendet — der Vergleich liefert immer unknown.
Aggregatfunktion in WHERE statt in HAVING geschrieben.
Spaltenalias aus SELECT in WHERE referenziert — dort ist er noch nicht definiert.
GROUP BY vergessen, obwohl neben einem Aggregat noch eine Einzelspalte selektiert wird.

LK-Vertiefung

eA-Vertiefung: Erläutern Sie SQLs dreiwertige Logik (true/false/unknown) und ihre Folgen für WHERE-Bedingungen mit NULL-Werten sowie den Unterschied zwischen `COUNT(*)` und `COUNT(spalte)`, das NULL-Werte überspringt.

Aktive Wiederholung

Geben Sie SQL-Anweisungen an, die alle Kunden mit mehr als drei Bestellungen im Jahr 2025 nach absteigendem Gesamtumsatz auflisten.

Aktiv abrufen

Erinnere dich an die Kernpunkte — dann aufdecken.

SQL — Joins, Subqueries und Indizes#

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

B-Baum-Index (Ordnung 3) für Datenbankzugriffe

Abb. 2Mehrwege-Suchbaum mit sortierten Schlüsseln je Knoten; balanciert, daher Zugriff in O(log n) auch bei Millionen Datensätzen. Suche 50: 50 > 30 und 50 < 60 → mittlerer Teilbaum → Treffer.

Ein Join führt die durch die Normalisierung getrennten Tabellen über ihre Schlüsselbeziehungen wieder zusammen. Der INNER JOIN liefert nur die Tupel, die in beiden Tabellen einen Partner finden (Match über die `ON`-Bedingung, meist Fremdschlüssel = Primärschlüssel). Er ist der häufigste Join und entspricht dem Equi-Join der Relationenalgebra.

Die OUTER JOINs behalten auch partnerlose Tupel: Der LEFT OUTER JOIN liefert alle Zeilen der linken Tabelle und füllt fehlende Werte der rechten mit NULL (z. B. „alle Kunden, auch solche ohne Bestellung"); der RIGHT macht es spiegelbildlich, der FULL OUTER JOIN behält partnerlose Tupel beider Seiten. Der CROSS JOIN bildet das kartesische Produkt (jede Zeile mit jeder) und wird selten direkt benötigt.

In der Relationenalgebra ist der Join ein abgeleiteter Operator: Der Theta-Join R ⋈θ S = σθ(R × S) wendet eine Selektion mit Prädikat θ auf das kartesische Produkt an; der Equi-Join ist der Spezialfall mit Gleichheitsprädikat, der natürliche Join verbindet zusätzlich über gleichnamige Spalten. Diese Algebra ist die formale Grundlage der SQL-Auswertung.

Eine Unterabfrage (Subquery) ist eine in eine andere Abfrage geschachtelte `SELECT`-Anweisung: skalar (liefert genau einen Wert), mengenwertig (mit `IN`, `EXISTS`) oder korreliert (die innere Abfrage referenziert die äußere und wird pro äußerer Zeile neu ausgewertet). Korrelierte Subqueries sind ausdrucksstark, aber häufig langsamer als ein äquivalenter Join.

Ein Index (typisch ein B-Baum, siehe nebenstehende Abbildung) ist eine sortierte Hilfsstruktur, die Zugriffe in `WHERE`- und `JOIN`-Bedingungen von O(n) auf O(log n) beschleunigt — ohne ihn muss die Datenbank die ganze Tabelle durchsuchen (full table scan). Der Preis: Jeder Index kostet Speicher und verlangsamt `INSERT`/`UPDATE`/`DELETE`, weil er mitgepflegt werden muss.

Die Indexwahl ist eine Abwägung: Indizes lohnen auf Spalten mit hoher Selektivität (vielen verschiedenen Werten), die häufig in WHERE, JOIN oder ORDER BY auftreten; auf Spalten mit wenigen verschiedenen Werten (z. B. Geschlecht) bringen sie kaum Nutzen. Ein zusammengesetzter Index (z. B. (KundenNr, Datum)) kann Abfragen bedienen, die nach beiden Spalten in genau dieser Reihenfolge filtern.

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

Theta-Join der Relationenalgebra

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

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 formuliert — Ergebnis ist das kartesische Produkt.
Korrelierte Subquery genutzt, wo ein äquivalenter (schnellerer) Join möglich wäre.
Index auf eine Spalte mit wenigen verschiedenen Werten gelegt — geringer Nutzen.
INNER und LEFT JOIN verwechselt — partnerlose Zeilen fallen beim INNER JOIN weg.

LK-Vertiefung

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

Aktive Wiederholung

Implementieren Sie eine SQL-Abfrage mit LEFT OUTER JOIN, die alle Kunden inklusive solcher ohne Bestellungen auflistet; geben Sie zusätzlich die äquivalente Subquery-Form an.

Aktiv abrufen

Erinnere dich an die Kernpunkte — dann aufdecken.

Datenschutz, DSGVO und Datenbankethik#

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

Die Datenschutz-Grundverordnung (DSGVO, EU-Verordnung 2016/679, anwendbar seit 25. Mai 2018) ist das maßgebliche europäische Datenschutzrecht. Sie regelt die Verarbeitung personenbezogener Daten — aller Informationen, die sich auf eine identifizierte oder identifizierbare natürliche Person beziehen. Als EU-Verordnung gilt sie unmittelbar in allen Mitgliedstaaten; das deutsche BDSG ergänzt sie nur, wo sie Spielräume lässt. Verstöße können mit bis zu 4 % des weltweiten Jahresumsatzes oder 20 Mio. € geahndet werden.

Art. 5 nennt die Grundprinzipien jeder Verarbeitung: Rechtmäßigkeit (es braucht eine Rechtsgrundlage, etwa Einwilligung oder Vertrag), Zweckbindung (Daten nur für den festgelegten Zweck), Datenminimierung (nur das Nötige erheben), Richtigkeit, Speicherbegrenzung (nicht länger als nötig speichern), Integrität und Vertraulichkeit (technische Sicherheit) sowie die Rechenschaftspflicht (der Verantwortliche muss die Einhaltung nachweisen können).

Die DSGVO gibt den Betroffenen durchsetzbare Rechte: Auskunft (Art. 15), Berichtigung (Art. 16), Löschung / Recht auf Vergessenwerden (Art. 17), Datenübertragbarkeit (Art. 20) und Widerspruch (Art. 21). Für die Datenbankpraxis ist besonders Art. 17 relevant — er verlangt das technische Umsetzen von Löschungen, etwa über kaskadierende DELETE entlang der Fremdschlüssel oder eine Markierung als gelöscht, einschließlich der Backups.

Privacy by Design (Datenschutz durch Technikgestaltung) und Privacy by Default (datenschutzfreundliche Voreinstellungen) verlangen, den Datenschutz von Anfang an in das Systemdesign einzubauen, statt ihn nachträglich aufzusetzen — etwa über knappe Standard-Sichtbarkeiten, sparsame Datenfelder und eingebaute Löschfristen.

Sorgfältig zu trennen sind Pseudonymisierung und Anonymisierung: Pseudonymisierte Daten sind mit einem separat verwahrten Schlüssel re-identifizierbar und bleiben deshalb personenbezogen (DSGVO-pflichtig); nur die irreversible Anonymisierung entzieht Daten dem Anwendungsbereich der DSGVO. Wer „anonym" sagt, aber re-identifizieren kann, hat in Wahrheit nur pseudonymisiert.

Zu den technischen Standardmaßnahmen gehören die Verschlüsselung der Daten at rest (in der Datenbank) und in transit (per TLS), eine restriktive Zugriffskontrolle (Rollen, das relationale DCL mit `GRANT`/`REVOKE`), Protokollierung sowie regelmäßige Löschung. Datenschutz ist damit nicht nur eine rechtliche, sondern eine technische Aufgabe der Datenbankgestaltung.

Typische Fehler

DSGVO und BDSG verwechselt — die DSGVO ist EU-Recht, das BDSG das deutsche Ergänzungsgesetz.
„Anonymisiert" behauptet, obwohl re-identifizierbar — tatsächlich nur pseudonymisiert.
Backups beim Löschrecht vergessen — auch dort muss eine Löschstrategie greifen.
Datenschutz als rein rechtliches Thema behandelt — technische Maßnahmen (Verschlüsselung, DCL) fehlen.

LK-Vertiefung

eA-Vertiefung: Erörtern Sie das Spannungsfeld zwischen Datenminimierung und Speicherbegrenzung der DSGVO einerseits und dem Wunsch nach umfassender Datenanalyse (Big Data, Profilbildung) andererseits und beurteilen Sie, inwieweit Anonymisierung dieses Spannungsfeld auflösen kann.

Aktive Wiederholung

Beurteilen Sie ein Schülerverwaltungssystem hinsichtlich DSGVO-Konformität; identifizieren Sie mindestens drei Datenschutzrisiken und schlagen Sie technische Maßnahmen vor.

Aktiv abrufen

Erinnere dich an die Kernpunkte — dann aufdecken.

Transaktionen, ACID und Mehrbenutzerbetrieb#

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

Eine Transaktion ist eine logisch zusammengehörige Folge von Datenbankoperationen, die als eine unteilbare Einheit ausgeführt wird. Das Standardbeispiel ist die Überweisung: Abbuchung beim einen und Gutschrift beim anderen Konto dürfen nur gemeinsam oder gar nicht wirksam werden — käme nur die Abbuchung durch, ginge Geld verloren. Eine Transaktion beginnt mit `BEGIN` und endet mit `COMMIT` (alles dauerhaft schreiben) oder `ROLLBACK` (alles verwerfen).

Die vier ACID-Eigenschaften garantieren die Verlässlichkeit: Atomarität (alles oder nichts — eine halb ausgeführte Transaktion wird zurückgerollt), Konsistenz (die Integritätsbedingungen der Datenbank bleiben vor und nach der Transaktion gewahrt), Isolation (parallele Transaktionen beeinflussen einander nicht, als liefen sie nacheinander) und Dauerhaftigkeit/Durability (ein bestätigter `COMMIT` überdauert auch einen anschließenden Systemabsturz).

Atomarität und Dauerhaftigkeit setzt ein Recovery-Manager über Logging um: Nach dem Prinzip des Write-Ahead-Logging (WAL) wird jede Änderung zuerst in ein Protokoll geschrieben, bevor sie die eigentlichen Daten erreicht. Nach einem Absturz spielt der Manager das Log ein — bestätigte Transaktionen werden wiederholt (redo), unbestätigte rückgängig gemacht (undo) — und stellt so einen konsistenten Zustand wieder her.

Im Mehrbenutzerbetrieb entstehen ohne Schutz Nebenläufigkeitsanomalien: Beim Lost Update überschreibt eine Transaktion die Änderung einer anderen; beim Dirty Read liest man noch nicht bestätigte Werte; beim Non-Repeatable Read liefert dieselbe Leseoperation innerhalb einer Transaktion verschiedene Werte; beim Phantom Read ändert sich die Treffermenge einer Bedingung. Genau diese Anomalien sollen Isolationsmechanismen verhindern.

Der ANSI-Standard definiert vier Isolationsstufen mit steigender Strenge: Read Uncommitted, Read Committed, Repeatable Read und Serializable. Jede höhere Stufe schließt mehr Anomalien aus — Read Committed verhindert Dirty Reads, Repeatable Read zusätzlich Non-Repeatable Reads, Serializable auch Phantome —, kostet aber zunehmend Parallelität und Durchsatz. Die Wahl ist ein bewusster Kompromiss; oft genügt Read Committed.

Umgesetzt wird Isolation meist über Sperren (Locks). Das Zwei-Phasen-Sperrprotokoll (2PL) — erst nur Sperren anfordern (Wachstumsphase), dann nur freigeben (Schrumpfphase) — garantiert Serialisierbarkeit. Sperren können jedoch zu einem Deadlock führen: Zwei Transaktionen warten wechselseitig auf die vom jeweils anderen gehaltene Sperre. Ein Deadlock ist keine Endlosschleife, sondern gegenseitiges Sperrenwarten; er wird per Timeout oder über einen Wartegraphen (Zyklenerkennung) aufgelöst, indem eine Transaktion abgebrochen wird.

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.

Aktive Wiederholung

Analysieren Sie einen parallelen Ablauf zweier Transaktionen auf demselben Konto und weisen Sie nach, wie ein Lost Update entsteht; beurteilen Sie, welche Isolationsstufe ihn verhindert.

Aktiv abrufen

Erinnere dich an die Kernpunkte — dann aufdecken.

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

6Abschnitteca. 18Min Lesezeit3KompetenzenNiveauBasis 2 · Standard 2 · Vertiefung 2Stand 06/2026