Aufgaben Datenintegrität
Diese letzte Lektion des Kurses dient zur Prüfungsvorbereitung. Wir gehen 12 typische IHK-Aufgaben durch, die genau zu den Themen Integritätstypen, Constraints, ACID, Isolation, Deadlocks und Indizes passen. Lösungen sind ausklappbar – versuche die Antworten erst selbst zu formulieren.
Die Aufgabentypen entsprechen denen aus realen Prüfungen: Begriff & Definition, Szenario-Analyse, SQL-Konstrukt erzeugen, Fehler erkennen und Beratung mit Begründung. Diese fünf Muster decken alle prüfungsrelevanten Formate ab.
1) Überblick: Aufgabenverteilung
So setzt sich der Aufgaben-Block typischerweise zusammen:
Aufgaben in dieser Lektion
12
Aufgaben
6
Thema A: Integrität
6
Thema B: Transakt.
~30
Punkte total
Punktzahlen sind Orientierungswerte – reale IHK-Aufgaben können davon abweichen. Der wichtige Skill ist das Erkennen des Aufgabentyps: eine reine Wissensfrage („Was bedeutet ACID?") braucht eine andere Antwort als eine Szenario-Aufgabe („Welcher Constraint löst dieses Problem?"). Beim Lesen markieren: ist die Frage konzeptionell, technisch oder beratend?
2) Aufgaben Teil A – Datenintegrität
Klick eine Aufgabe um sie zu öffnen. Versuch erst selbst zu antworten, bevor du die Musterlösung aufklappst:
Aufgaben 1–6: Integrität & Constraints
Vier Integritätstypen benennen
Nennen Sie die vier klassischen Integritätstypen einer relationalen Datenbank und beschreiben Sie jeweils kurz, worauf sie sich beziehen.
Musterlösung
- Entitätsintegrität: jede Zeile einer Tabelle muss eindeutig identifizierbar sein – realisiert durch den Primary Key (NOT NULL + UNIQUE).
- Referenzielle Integrität: jeder Fremdschlüsselwert muss in der Zieltabelle als Primary Key existieren (oder NULL sein).
- Domänenintegrität: jeder Wert einer Spalte muss aus dem definierten Wertebereich (Datentyp, NOT NULL, CHECK, UNIQUE) stammen.
- Benutzerdefinierte Integrität: fachliche Geschäftsregeln, die das DBMS nicht von selbst kennt – via CHECK, Trigger oder Anwendungscode durchgesetzt.
Tipp: Bei IHK-Aufgaben den Typ und ein Beispiel nennen – das gibt volle Punktzahl, selbst wenn die Definition knapp ist.
Welcher Integritätstyp wurde verletzt?
In einer Tabelle
bestellungen mit der Spalte kunden_id (Fremdschlüssel auf kunden.id) befindet sich eine Zeile mit kunden_id = 4711 – obwohl es in der Tabelle kunden keinen Datensatz mit dieser ID gibt. Welcher Integritätstyp ist verletzt, und welcher Constraint hätte das verhindert?Musterlösung
Verletzt ist die referenzielle Integrität: ein Fremdschlüssel verweist auf einen nicht existierenden Datensatz (verwaiste Zeile, „orphan row").
Verhindert hätte das ein
FOREIGN KEY-Constraint:
ALTER TABLE bestellungen
ADD CONSTRAINT fk_kunde FOREIGN KEY (kunden_id) REFERENCES kunden(id);
Beim Insert mit ungültiger kunden_id würde das DBMS dann mit ADD CONSTRAINT fk_kunde FOREIGN KEY (kunden_id) REFERENCES kunden(id);
ERROR 1452: foreign key constraint fails ablehnen.
Falle: nicht „Konsistenz" oder „ACID Consistency" antworten – das ist die Garantie auf Transaktionsebene, nicht der Integritätstyp.
Tabelle mit Constraints anlegen
Erstellen Sie eine SQL-Tabelle
mitarbeiter mit folgenden Anforderungen: eindeutige ID (auto-generiert), Nachname (Pflicht, max 50 Zeichen), E-Mail (eindeutig, Pflicht), Alter (mindestens 18), Abteilung-ID (Verweis auf Tabelle abteilungen).Musterlösung
CREATE TABLE mitarbeiter (
id BIGINT AUTO_INCREMENT PRIMARY KEY,
nachname VARCHAR(50) NOT NULL,
email VARCHAR(120) NOT NULL UNIQUE,
alter INT CHECK (alter >= 18),
abteilung_id BIGINT,
FOREIGN KEY (abteilung_id) REFERENCES abteilungen(id)
);
Erfüllt alle Anforderungen: PRIMARY KEY (Entitätsintegrität), NOT NULL (Pflicht), UNIQUE (eindeutig), CHECK (Mindestalter, Domänenintegrität), FOREIGN KEY (referenzielle Integrität).
id BIGINT AUTO_INCREMENT PRIMARY KEY,
nachname VARCHAR(50) NOT NULL,
email VARCHAR(120) NOT NULL UNIQUE,
alter INT CHECK (alter >= 18),
abteilung_id BIGINT,
FOREIGN KEY (abteilung_id) REFERENCES abteilungen(id)
);
Tipp: In Klausuren nichts vergessen – PRIMARY KEY auch wenn nicht explizit verlangt, ist Pflicht für eine ordentliche Tabelle.
ON DELETE-Verhalten begründen
In einem Online-Shop gibt es die Tabellen
bestellungen (FK auf kunden) und bestellpositionen (FK auf bestellungen). Welches ON DELETE-Verhalten würden Sie für die zwei Beziehungen wählen und warum?Musterlösung
- bestellpositionen → bestellungen: ON DELETE CASCADE. Eine Bestellposition ergibt ohne ihre Bestellung keinen Sinn – wird die Bestellung gelöscht, müssen die Positionen mit. Ohne CASCADE wären verwaiste Positionen die Folge.
- bestellungen → kunden: ON DELETE RESTRICT (oder SET NULL). Bestellungen sind buchhalterisch relevant und sollten nicht stillschweigend mit dem Kunden verschwinden. RESTRICT zwingt die Anwendung, eine bewusste Entscheidung zu treffen (Bestellung archivieren, dem System „Gelöschter Kunde" zuordnen, etc.). Bei vorhandenen Bestellungen kann der Kunde nicht einfach gelöscht werden.
Tipp: Bei „warum"-Fragen immer fachliche Begründung mitliefern – nicht nur die SQL-Klausel nennen. Audit, Buchhaltung, Datenschutz sind starke Argumente.
Was ist hier falsch?
Eine Kollegin schreibt: „Wir brauchen keine FOREIGN-KEY-Constraints in der Datenbank. Wir prüfen im Anwendungscode, dass nur gültige IDs verwendet werden." Nennen Sie drei Gründe, warum diese Strategie problematisch ist.
Musterlösung
- Mehrere Clients: sobald ein zweiter Client oder ein Migrations-Skript direkt auf die DB schreibt, wird die App-seitige Prüfung umgangen. Die DB ist die letzte Verteidigungslinie.
- Race Conditions: zwischen Prüfung und Insert kann der referenzierte Datensatz gelöscht werden. Ohne DB-Constraint bleiben verwaiste Zeilen.
- Bugs in der Anwendung: ein Logikfehler im Code wirft sofort schlechte Daten in die DB, ohne dass es jemand bemerkt. Mit Constraint kommt sofort ein Fehler.
Merksatz: „Defense in depth" – Validierung in App UND DB, nicht entweder/oder.
Unterschied PRIMARY KEY vs. UNIQUE
Erklären Sie den Unterschied zwischen einem
PRIMARY KEY und einem UNIQUE-Constraint. Welche Gemeinsamkeiten haben sie?Musterlösung
Gemeinsamkeiten: beide garantieren Eindeutigkeit der Werte in der betroffenen Spalte (oder Spaltenkombination). Beide bekommen automatisch einen Index.
Unterschiede:
- Ein PRIMARY KEY pro Tabelle, beliebig viele UNIQUE-Constraints.
- PRIMARY KEY ist implizit
NOT NULL, UNIQUE erlaubtNULL-Werte (meist sogar mehrere NULLs, je nach DBMS). - PRIMARY KEY ist die zentrale Identität der Zeile – Fremdschlüssel verweisen darauf. UNIQUE ist „nur" eine zusätzliche Eindeutigkeitsregel.
- PRIMARY KEY bestimmt in InnoDB die physische Sortierung (Clustered Index).
Eselsbrücke: PRIMARY KEY = „Identität" der Zeile. UNIQUE = „darf nur einmal vorkommen, aber muss nicht da sein".
3) Aufgaben Teil B – Transaktionen, ACID, Performance
Aufgaben 7–12: Transaktionen & Performance
ACID erklären
Wofür steht das Akronym ACID im Datenbankkontext? Erklären Sie jede der vier Eigenschaften in einem Satz.
Musterlösung
- A – Atomicity (Atomarität): eine Transaktion wird vollständig oder gar nicht ausgeführt – nie halb.
- C – Consistency (Konsistenz): die Datenbank ist vor und nach jeder Transaktion in einem regelkonformen Zustand (alle Constraints eingehalten).
- I – Isolation: parallele Transaktionen sehen einander nicht (oder nur kontrolliert) – jede fühlt sich an als wäre sie allein im System.
- D – Durability (Dauerhaftigkeit): committed Änderungen sind permanent gespeichert und überleben Crashs (per Write-Ahead-Log).
Tipp: die Buchstaben einzeln aufschreiben mit deutschem Begriff dahinter – das gibt strukturpunkte selbst wenn die Definitionen nicht perfekt sind.
Banküberweisung & ACID
Bei einer Banküberweisung von Konto A nach Konto B fällt mitten in der Verarbeitung der Server aus – nachdem A schon abgebucht, aber bevor B gutgeschrieben wurde. Welche ACID-Eigenschaft sorgt dafür, dass nach dem Neustart kein Geld verloren geht? Was passiert konkret beim Recovery?
Musterlösung
Die entscheidende Eigenschaft ist die Atomicity (Atomarität): die Transaktion wird entweder ganz oder gar nicht wirksam. Da kein COMMIT erfolgt ist, gilt die Transaktion als nicht abgeschlossen.
Beim Recovery:
- Das DBMS startet neu und liest das Transaktions-Log (Write-Ahead-Log).
- Es findet eine Transaktion ohne „committed"-Marker.
- Mithilfe der im Log gespeicherten alten Werte führt es einen automatischen
ROLLBACKaus. - Konto A wird auf den ursprünglichen Saldo zurückgesetzt.
Welche Anomalie ist das?
Zwei Mitarbeiter buchen gleichzeitig den letzten Lagerartikel. Beide lesen
menge = 1, beide rechnen 1 - 1 = 0, beide schreiben menge = 0. Tatsächlich wurden zwei Artikel verkauft, aber das System zeigt nur eine Verkaufstransaktion an. Wie heißt diese Anomalie? Welche Isolationsstufe würde sie verhindern?Musterlösung
Es handelt sich um ein Lost Update: die Schreiboperation einer Transaktion „verliert" die Änderung einer anderen, weil beide auf demselben Ausgangsstand rechnen.
Verhindert wird das ab Isolationsstufe
REPEATABLE READ – dort wird beim ersten Lesen einer Zeile in einer Transaktion eine Sperre gehalten (oder per MVCC ein Snapshot fixiert), sodass die zweite Transaktion warten muss oder einen Konflikt-Fehler bekommt.
Alternativ: optimistic locking auf Anwendungsebene mit einer Versionsspalte: UPDATE … WHERE id = ? AND version = ?. Wird die Version inzwischen geändert, schlägt das UPDATE fehl und die App kann retryen.
Tipp: diese Aufgabe kommt fast jährlich – Lost Update, Dirty Read, Non-Repeatable Read und Phantom Read sicher unterscheiden können.
Transaktion korrekt umsetzen
Schreiben Sie eine Transaktion in SQL, die 100 € von Konto 1 auf Konto 2 überweist und einen Log-Eintrag in die Tabelle
buchungen einfügt. Bei Fehler soll die ganze Operation zurückgenommen werden.Musterlösung
BEGIN;
-- 1) Abbuchen
UPDATE konten SET saldo = saldo - 100 WHERE id = 1;
-- 2) Gutschreiben
UPDATE konten SET saldo = saldo + 100 WHERE id = 2;
-- 3) Logeintrag
INSERT INTO buchungen (von_id, nach_id, betrag, zeitpunkt)
VALUES (1, 2, 100, NOW());
-- bei Erfolg:
COMMIT;
-- bei Fehler stattdessen: ROLLBACK;
In Anwendungscode wäre das umrahmt von einem try/catch-Block: bei Exception wird -- 1) Abbuchen
UPDATE konten SET saldo = saldo - 100 WHERE id = 1;
-- 2) Gutschreiben
UPDATE konten SET saldo = saldo + 100 WHERE id = 2;
-- 3) Logeintrag
INSERT INTO buchungen (von_id, nach_id, betrag, zeitpunkt)
VALUES (1, 2, 100, NOW());
-- bei Erfolg:
COMMIT;
-- bei Fehler stattdessen: ROLLBACK;
ROLLBACK aufgerufen, sonst COMMIT.
Punkte-Plus: einen
CHECK-Constraint auf saldo >= 0 erwähnen – damit verhindert das DBMS automatisch negative Stände bei zu wenig Guthaben.Deadlock vermeiden
In Ihrer Anwendung kommen unter Last regelmäßig Deadlock-Fehler vor – immer wenn Geldtransfers in beide Richtungen gleichzeitig zwischen denselben zwei Konten passieren. Nennen Sie zwei Maßnahmen, die das Problem reduzieren.
Musterlösung
- Konsistente Sperrreihenfolge: die beteiligten Konten immer in derselben Reihenfolge sperren – z.B. immer aufsteigend nach ID. Wenn beide Transaktionen Konto 1 vor Konto 2 sperren, kann kein Zyklus entstehen → kein Deadlock.low = LEAST(from_id, to_id);
high = GREATEST(from_id, to_id);
SELECT * FROM konten WHERE id IN (low, high) ORDER BY id FOR UPDATE; - Retry-Pattern in der Anwendung: Deadlock-Errors (SQL-State 40001) fangen und die Transaktion mit Random Backoff bis zu 3-mal wiederholen. Schützt vor verbleibenden seltenen Deadlocks.
SELECT … FOR UPDATE früh beim Lesen statt erst beim Schreiben.
Index sinnvoll oder nicht?
Eine Tabelle
mitarbeiter (1.500 Zeilen) hat die Spalten id, nachname, email, geschlecht, abteilung_id. Welche Spalten würden Sie mit einem Index versehen, welche nicht – und warum?Musterlösung
Mit Index:
id– automatisch durch PRIMARY KEY.email– wenn UNIQUE: automatisch indexiert. Wenn nicht: trotzdem sinnvoll für Login-Suche.abteilung_id– Foreign Key, oft in WHERE und JOINs verwendet. In MySQL/InnoDB automatisch indexiert.nachname– je nach Abfragen. Wenn oft per Nachname gesucht wird, ja.
geschlecht– niedrige Selektivität (2–4 unterschiedliche Werte). Ein Index würde nichts beschleunigen, weil das DBMS bei 50% Treffern sowieso Full Scan macht.
Tipp: Selektivität in den Antworten erwähnen – das ist der Fachbegriff den IHK-Prüfer hören wollen.
4) Mini-Quiz: schnelle Zuordnung
Vier kurze Multiple-Choice-Fragen zum Schluss – typisch für die ganzheitliche Aufgabe in Teil 1:
Schnell-Quiz
5) Cheatsheet – das musst du auswendig wissen
Kurz und kompakt zur Wiederholung vor der Prüfung:
Spickzettel
4 Integritätstypen
Entität, Referenz, Domäne, Benutzerdef.
ACID
Atomicity, Consistency, Isolation, Durability
TX-Befehle
BEGIN, COMMIT, ROLLBACK, SAVEPOINTON DELETE-Optionen
CASCADE, RESTRICT, NO ACTION, SET NULL, SET DEFAULT4 Anomalien
Dirty Read, Non-Repeatable Read, Phantom Read, Lost Update
4 Isolation Levels
READ UNCOMMITTED, READ COMMITTED, REPEATABLE READ, SERIALIZABLE
6 Constraint-Typen
PK, FK, UNIQUE, NOT NULL, CHECK, DEFAULT
Deadlock-Fehler
SQL-State
40001, MySQL ERROR 1213Index-Komplexität
Full Scan O(n) → Index Lookup O(log n)
Vor der Prüfung am Tag vorher noch einmal überfliegen. Diese Begriffe in der Klausur korrekt zu benennen gibt häufig die letzten 5–10 Punkte und entscheidet zwischen „bestanden" und „bestanden mit gut".
Zusammenfassung & Kurs-Abschluss
Dieser Kurs hat dich durch die zwei zentralen Themen der Datenbankqualität geführt: Datenintegrität (welche Regeln gelten, wie das DBMS sie durchsetzt) und Transaktionen (wie Operationen verlässlich zusammenarbeiten, auch bei Crashs und Nebenläufigkeit). Mit den vier Integritätstypen, dem ACID-Akronym, den vier Anomalien plus Isolation Levels, dem Verständnis von Deadlocks und Indizes hast du das gesamte prüfungsrelevante Werkzeug-Set für die Themenbereiche B2b und A4e abgedeckt. Übe die obigen Aufgaben mehrfach – die Muster wiederholen sich in fast jeder IHK-Prüfung. Wer die zwölf Aufgaben hier sicher beantworten kann, ist auf den DB-Teil der Abschlussprüfung gut vorbereitet.