Übungsaufgaben zu INSERT, UPDATE und DELETE

Kopiere den Text in ein KI-Sprachmodell Deiner Wahl und passe Kompetenzstufe, Anzahl, Bearbeitungszeit und Szenario bei Bedarf an. Wie die Aufgaben aufgebaut sind, beschreibt der Artikel Wie sind die Aufgaben aufgebaut?. Prüfe die Ergebnisse mit dem Lehrartikel: KI-Sprachmodelle machen Fehler.

Erstelle neue Übungsaufgaben zum Thema „INSERT, UPDATE und DELETE“.

Bauplan: Halte Dich an Aufbau, Kompetenzstufen, Operatoren,
Anforderungsbereiche, Punkte und Zeitschätzung, die im Artikel
https://oer-informatik.de/aufgaben-aufbau beschrieben sind.

Fachliche Grundlage:
- https://oer-informatik.de/sql-dml-insert
- https://oer-informatik.de/sql-dml-update
- https://oer-informatik.de/sql-dml-delete
- https://oer-informatik.de/sql-dml-selektion-projektion
- https://oer-informatik.de/sql-dml-singlerowfunctions
- Stilbeispiel: https://oer-informatik.de/sql-dml-uebungsaufgaben

Die Aufgaben sollen Inhalte zu diesen Schlagwörtern abdecken:
- SQL
- DML
- INSERT
- UPDATE
- DELETE
- Fremdschlüssel
- Transaktion
- MariaDB
- Datenmigration
- referentielle Integrität

Kompetenzstufe: Kernkompetenz (alternativ: Basiskompetenz, Profilkompetenz, Expertise)
Anzahl: 1 Aufgabe mit Teilaufgaben
Bearbeitungszeit in Minuten ca.: <5 bis 30 min>
Szenario: eines der Szenarien aus dem Bauplan

Vorgehen:
1. Lies zuerst die verlinkten Artikel. Kannst Du keine Webseiten
   abrufen, sag mir das, statt zu raten.
2. Steht bei einer Angabe noch ein Platzhalter in <…>, frag mich
   zuerst danach. Richte Punkte und Zahl der Teilaufgaben nach der
   Bearbeitungszeit (ca. 0,9 min je Punkt).
3. Gib je Aufgabe Titel mit Kompetenzstufe, Ausgangssituation und
   Teilaufgaben mit Operator und Punktzahl aus, dazu die geschätzte
   Bearbeitungszeit.
4. Gib die Beispiellösungen mit Punkteverteilung erst aus, wenn ich
   danach frage.

Bewertung: je Zeile 0,5 P, wenn Sprachfamilie, CRUD-Operation und die Angabe „verändert …“ stimmen. Bei SELECT ist „DML“ mit Hinweis auf den SQL-Standard ebenfalls richtig.

INSERT INTO kategorie (bezeichnung, ober_kategorie_id)
VALUES ('Antrieb', 5);

INSERT INTO artikel (artikelnr, bezeichnung, kategorie_id, netto_preis,
                     lagerbestand, mindestbestand, gewicht_kg)
VALUES ('BRE-BEL-02', 'Bremsbelag-Satz Scheibenbremse', 9, 18.40, 30, 10, 0.10),
       ('KET-11-E', 'Kette 11-fach E-Bike',
        (SELECT kategorie_id FROM kategorie WHERE bezeichnung = 'Antrieb'),
        32.90, 15, 5, NULL);

INSERT INTO kategorie (bezeichnung, ober_kategorie_id)
VALUES ('Antrieb', 5);

INSERT INTO artikel (artikelnr, bezeichnung, kategorie_id, netto_preis,
                     lagerbestand, mindestbestand, gewicht_kg)
VALUES ('BRE-BEL-02', 'Bremsbelag-Satz Scheibenbremse', 9, 18.40, 30, 10, 0.10),
       ('KET-11-E', 'Kette 11-fach E-Bike',
        (SELECT kategorie_id FROM kategorie WHERE bezeichnung = 'Antrieb'),
        32.90, 15, 5, NULL);

INSERT INTO kategorie (bezeichnung, ober_kategorie_id)
VALUES ('Antrieb', 5);

INSERT INTO artikel (artikelnr, bezeichnung, kategorie_id, netto_preis,
                     lagerbestand, mindestbestand, gewicht_kg)
VALUES ('BRE-BEL-02', 'Bremsbelag-Satz Scheibenbremse', 9, 18.40, 30, 10, 0.10),
       ('KET-11-E', 'Kette 11-fach E-Bike',
        (SELECT kategorie_id FROM kategorie WHERE bezeichnung = 'Antrieb'),
        32.90, 15, 5, NULL);

INSERT INTO kategorie (bezeichnung, ober_kategorie_id)
VALUES ('Antrieb', 5);

-- mehrere Zeilen in einem VALUES erst ab Oracle 23ai,
-- davor eine Anweisung mit INSERT … SELECT und UNION ALL
INSERT INTO artikel (artikelnr, bezeichnung, kategorie_id, netto_preis,
                     lagerbestand, mindestbestand, gewicht_kg)
SELECT 'BRE-BEL-02', 'Bremsbelag-Satz Scheibenbremse', 9, 18.40, 30, 10, 0.10
FROM dual
UNION ALL
SELECT 'KET-11-E', 'Kette 11-fach E-Bike', kategorie_id, 32.90, 15, 5, NULL
FROM kategorie
WHERE bezeichnung = 'Antrieb';

INSERT INTO kategorie (bezeichnung, ober_kategorie_id)
VALUES ('Antrieb', 5);

INSERT INTO artikel (artikelnr, bezeichnung, kategorie_id, netto_preis,
                     lagerbestand, mindestbestand, gewicht_kg)
VALUES ('BRE-BEL-02', 'Bremsbelag-Satz Scheibenbremse', 9, 18.40, 30, 10, 0.10),
       ('KET-11-E', 'Kette 11-fach E-Bike',
        (SELECT kategorie_id FROM kategorie WHERE bezeichnung = 'Antrieb'),
        32.90, 15, 5, NULL);

Ergebnis: Die Kategorie erhält die kategorie_id 10, die Artikel die artikel_id 10 und 11. mwst_satz (19.00), konfigurierbar (FALSE) und aktiv (TRUE) kommen aus den DEFAULT-Werten.

Bewertung: INSERT der Kategorie mit Spaltenliste ohne Schlüssel 1 P; Spaltenliste beim Artikel ohne artikel_id und ohne Spalten mit passendem Standardwert 1 P; mehrere Zeilen in einer Anweisung 1 P; Fremdschlüssel der neuen Kategorie per Unterabfrage oder LAST_INSERT_ID() 1 P; Literale korrekt (Text in Hochkommata, Dezimalpunkt, NULL ohne Hochkommata) 1 P.

Alternativen: gewicht_kg weglassen (wird ebenfalls NULL). Statt der Unterabfrage ist LAST_INSERT_ID() in der Zeile der Kette ebenso richtig, wenn das Artikel-INSERT unmittelbar auf das Einfügen der Kategorie folgt: Die gerade laufende Anweisung verändert den Wert von LAST_INSERT_ID() nicht, er bleibt während des ganzen INSERT bei 10. Die feste Zahl 10 ist nur richtig, wenn man vorher geprüft hat, welcher Wert vergeben wurde (0,5 P Abzug ohne Begründung).

UPDATE artikel
SET netto_preis = ROUND(netto_preis * 1.06, 2)
WHERE kategorie_id = (SELECT kategorie_id
                      FROM kategorie
                      WHERE bezeichnung = 'Schlösser');

Neue Preise: Bügelschloss 62,18 € · 1,06 = 65,9108 € → 65,91 €, Rahmenschloss 41,18 € · 1,06 = 43,6508 € → 43,65 €.

Bewertung: UPDATE … SET mit Faktor 1.06 (selbstbezüglich) 1 P, ROUND(…, 2) 1 P, Auswahl über Unterabfrage auf kategorie 1 P, beide Preise 1 P.

Alternative (MariaDB): UPDATE artikel AS a INNER JOIN kategorie AS k ON k.kategorie_id = a.kategorie_id SET a.netto_preis = ROUND(a.netto_preis * 1.06, 2) WHERE k.bezeichnung = 'Schlösser';. Ohne ROUND rundet die Spalte DECIMAL(10,2) beim Speichern selbst (Ergebnis gleich, 0,5 P Abzug, weil die Absicht nicht erkennbar ist). Falsch: netto_preis + 6, netto_preis * 0.06 oder netto_preis * 6 %.

• Vertraglich gilt der Preis zum Zeitpunkt der Bestellung; Kund*innen haben zu diesem Preis gekauft.

• Rechnungen sind Buchungsbelege und müssen unverändert und nachvollziehbar bleiben (Aufbewahrungspflicht, GoBD); eine spätere Preisänderung darf alte Rechnungsbeträge nicht verfälschen.

• Auswertungen (z. B. Umsatz eines Quartals) müssen später dieselben Zahlen liefern. Deshalb ist der Preis in der Bestellposition ein bewusst gespeicherter historischer Wert und keine Redundanz.

Im Datenbestand bleiben z. B. Bestellung 1, Position 2 (62,18 €) und Bestellung 5, Position 1 (41,18 €) unverändert.

Bewertung: je tragfähigem Argument 1 P.

UPDATE artikel
SET mindestbestand = CASE kategorie_id
                       WHEN 8 THEN 25
                       WHEN 9 THEN 12
                     END
WHERE kategorie_id IN (8, 9);

Geändert werden Artikel 7 (Lichtset, 25), Artikel 8 (Scheibenbremse, 12) und der neue Artikel 10 (Bremsbelag-Satz, bisher 10, jetzt 12).

Bewertung: CASE mit zwei Zweigen 2 P, WHERE auf die beiden Kategorien 1 P, betroffene Artikel einschließlich des neuen Artikels 10 1 P.

Ebenso volle Punktzahl: ohne WHERE, dafür mit ELSE mindestbestand (dann werden alle Zeilen durchlaufen, aber nur drei geändert). Ohne WHERE und ohne ELSE setzt das CASE bei allen anderen Artikeln NULL – das scheitert im Strict Mode an NOT NULL, ohne Strict Mode wird mit Warnung 0 gespeichert. Die Suche mit CASE WHEN kategorie_id = 8 THEN … ist ebenso richtig, ebenso zwei getrennte UPDATE-Anweisungen mit 1 P Abzug (nicht „eine Anweisung“).

Korrektur:

UPDATE artikel
SET netto_preis = ROUND(netto_preis * 0.9, 2)
WHERE artikelnr = 'LIC-SET-01';

Ergebnis: 75,63 € · 0,9 = 68,067 € → 68,07 € (1 Zeile geändert).

Bewertung: drei Fehler mit Folge je 1 P (Rundung als vierter Punkt ersatzweise), Korrektur 3 P (Faktor 1 P, WHERE am richtigen Platz mit eindeutiger Bedingung 1 P, Rundung 1 P).

ga) Die Bedingung trifft Artikel 9. Auf ihn verweist noch eine Bestellposition; der Fremdschlüssel bestellposition.artikel_id hat keine ON DELETE-Regel, es gilt also RESTRICT. MariaDB bricht mit Fehler 1451 ab („Cannot delete or update a parent row: a foreign key constraint fails …“), es wird nichts gelöscht. Die referentielle Integrität verhindert, dass Bestellpositionen auf einen nicht mehr vorhandenen Artikel zeigen. (2 P)

gb)

DELETE FROM artikel
WHERE aktiv = FALSE
  AND NOT EXISTS (SELECT *
                  FROM bestellposition AS bp
                  WHERE bp.artikel_id = artikel.artikel_id);

Ergebnis: 0 Zeilen gelöscht – Artikel 9 bleibt erhalten. Alternative: AND artikel_id NOT IN (SELECT artikel_id FROM bestellposition) (hier unproblematisch, weil artikel_id in bestellposition nie NULL ist).

Stellungnahme: Artikel 9 sollte nicht gelöscht werden, auch nicht über ON DELETE CASCADE (dann verschwänden Bestellpositionen und damit Teile von Bestell- und Rechnungsdaten, die aufbewahrt werden müssen). Er bleibt mit aktiv = FALSE gespeichert und wird im Shop nicht angezeigt; wer die Tabelle entlasten will, kopiert ihn in eine Archivtabelle, ohne den Verweis zu brechen.

Bewertung: DELETE mit NOT EXISTS/NOT IN und korrekter Korrelation 2 P, Ergebnis 1 P, Stellungnahme 1 P.

ha) Artikel 11 (Kette) hat noch kein Gewicht, in der Spalte steht also ein NULL. Im Strict Mode (Voreinstellung) lehnt MariaDB die Änderung auf NOT NULL deshalb ab („Invalid use of NULL value“) (1 P). Ohne Strict Mode würde das NULL mit einer Warnung in 0.00 umgewandelt – die Kette wöge dann scheinbar nichts und die Versandkosten würden falsch berechnet. Erst müssen die Lücken mit echten Werten gefüllt sein, dann kann die Struktur geändert werden (1 P).

hb)

UPDATE artikel AS a
  INNER JOIN herstellerdaten AS h ON h.artikelnr = a.artikelnr
SET a.gewicht_kg = ROUND(h.gewicht_g / 1000, 2)
WHERE a.gewicht_kg IS NULL;

-- Kontrolle: SELECT COUNT(*) FROM artikel WHERE gewicht_kg IS NULL;  -- 0
ALTER TABLE artikel
MODIFY gewicht_kg DECIMAL(6,2) NOT NULL;

UPDATE a
SET a.gewicht_kg = ROUND(h.gewicht_g / 1000.0, 2)   -- 1000.0: keine Ganzzahldivision
FROM artikel AS a
  INNER JOIN herstellerdaten AS h ON h.artikelnr = a.artikelnr
WHERE a.gewicht_kg IS NULL;

ALTER TABLE artikel
ALTER COLUMN gewicht_kg DECIMAL(6,2) NOT NULL;

UPDATE artikel AS a
SET gewicht_kg = ROUND(h.gewicht_g / 1000.0, 2)     -- 1000.0: keine Ganzzahldivision
FROM herstellerdaten AS h
WHERE h.artikelnr = a.artikelnr
  AND a.gewicht_kg IS NULL;

ALTER TABLE artikel
ALTER COLUMN gewicht_kg SET NOT NULL;

UPDATE artikel a
SET gewicht_kg = (SELECT ROUND(h.gewicht_g / 1000, 2)
                  FROM herstellerdaten h
                  WHERE h.artikelnr = a.artikelnr)
WHERE a.gewicht_kg IS NULL
  AND EXISTS (SELECT 1 FROM herstellerdaten h WHERE h.artikelnr = a.artikelnr);

ALTER TABLE artikel
MODIFY gewicht_kg NOT NULL;

UPDATE artikel
SET gewicht_kg = (SELECT ROUND(h.gewicht_g / 1000.0, 2)
                  FROM herstellerdaten AS h
                  WHERE h.artikelnr = artikel.artikelnr)
WHERE gewicht_kg IS NULL
  AND EXISTS (SELECT 1 FROM herstellerdaten AS h WHERE h.artikelnr = artikel.artikelnr);

-- SQLite kennt kein ALTER TABLE … MODIFY: Tabelle mit geänderter Spalte
-- neu anlegen, Daten umkopieren, alte Tabelle ersetzen
PRAGMA foreign_keys = OFF;
BEGIN TRANSACTION;

CREATE TABLE artikel_neu (
  artikel_id      INTEGER       PRIMARY KEY AUTOINCREMENT,
  artikelnr       VARCHAR(12)   NOT NULL UNIQUE,
  bezeichnung     VARCHAR(100)  NOT NULL,
  kategorie_id    INTEGER       NOT NULL REFERENCES kategorie (kategorie_id),
  netto_preis     DECIMAL(10,2) NOT NULL CHECK (netto_preis >= 0),
  mwst_satz       DECIMAL(4,2)  NOT NULL DEFAULT 19.00,
  lagerbestand    INT           NOT NULL DEFAULT 0,
  mindestbestand  INT           NOT NULL DEFAULT 0,
  gewicht_kg      DECIMAL(6,2)  NOT NULL,
  konfigurierbar  BOOLEAN       NOT NULL DEFAULT FALSE,
  aktiv           BOOLEAN       NOT NULL DEFAULT TRUE
);

INSERT INTO artikel_neu SELECT * FROM artikel;
DROP TABLE artikel;
ALTER TABLE artikel_neu RENAME TO artikel;

COMMIT;
PRAGMA foreign_keys = ON;

Geändert wird nur Artikel 11: 248 g ergeben 0.25 kg. Der Bremsbelag-Satz BRE-BEL-02 hat schon 0.10 kg und bleibt unverändert, obwohl der Großhändler 112 g angibt – die Bedingung IS NULL schützt gepflegte Werte. LIC-SET-01 ist ebenfalls schon gepflegt.

Bewertung: Verbund bzw. Unterabfrage über die Artikelnummer 1 P, Umrechnung in kg mit ROUND(…, 2) 1 P, Bedingung IS NULL (= NULL trifft keine Zeile: 0 P) 1 P, danach ALTER TABLE … MODIFY … NOT NULL mit Datentyp 1 P. CHANGE gewicht_kg gewicht_kg DECIMAL(6,2) NOT NULL ist ebenso richtig. Hätte die Kontrolle noch Artikel ohne Gewicht gezeigt, müssten diese zuerst nachgewogen werden.

INSERT INTO person (vorname, nachname, email, organisation)
VALUES ('Samira', 'Benali', 'samira.benali@example.org', 'Senne-Logistik GmbH');

INSERT INTO anmeldung (veranstaltung_id, person_id, ticketart, angemeldet_am,
                       essen, badge_code)
VALUES (1, LAST_INSERT_ID(), 'Referent', '2026-10-18 10:30:00',
        'vegan', 'BC27R015');

INSERT INTO person (vorname, nachname, email, organisation)
VALUES ('Samira', 'Benali', 'samira.benali@example.org', 'Senne-Logistik GmbH');

-- SCOPE_IDENTITY(): zuletzt vergebener IDENTITY-Wert;
-- Zeitpunkt mit „T“, damit er unabhängig von der Spracheinstellung gelesen wird
INSERT INTO anmeldung (veranstaltung_id, person_id, ticketart, angemeldet_am,
                       essen, badge_code)
VALUES (1, SCOPE_IDENTITY(), 'Referent', '2026-10-18T10:30:00',
        'vegan', 'BC27R015');

INSERT INTO person (vorname, nachname, email, organisation)
VALUES ('Samira', 'Benali', 'samira.benali@example.org', 'Senne-Logistik GmbH');

-- lastval(): zuletzt in dieser Sitzung vergebener Sequenzwert
INSERT INTO anmeldung (veranstaltung_id, person_id, ticketart, angemeldet_am,
                       essen, badge_code)
VALUES (1, lastval(), 'Referent', '2026-10-18 10:30:00',
        'vegan', 'BC27R015');

INSERT INTO person (vorname, nachname, email, organisation)
VALUES ('Samira', 'Benali', 'samira.benali@example.org', 'Senne-Logistik GmbH');

-- Fremdschlüssel über die eindeutige E-Mail-Adresse
INSERT INTO anmeldung (veranstaltung_id, person_id, ticketart, angemeldet_am,
                       essen, badge_code)
VALUES (1, (SELECT person_id FROM person WHERE email = 'samira.benali@example.org'),
        'Referent', TIMESTAMP '2026-10-18 10:30:00', 'vegan', 'BC27R015');

INSERT INTO person (vorname, nachname, email, organisation)
VALUES ('Samira', 'Benali', 'samira.benali@example.org', 'Senne-Logistik GmbH');

INSERT INTO anmeldung (veranstaltung_id, person_id, ticketart, angemeldet_am,
                       essen, badge_code)
VALUES (1, last_insert_rowid(), 'Referent', '2026-10-18 10:30:00',
        'vegan', 'BC27R015');

Ergebnis: person_id 15, anmeldung_id 15; foto_einwilligung erhält den Standardwert FALSE, bedarf_barrierefreiheit, checkin_zeit und geburtsjahr bleiben NULL.

Bewertung: Reihenfolge Person vor Anmeldung (Fremdschlüssel) 1 P, INSERT Person 1 P, INSERT Anmeldung mit Spaltenliste 1 P, Fremdschlüssel per LAST_INSERT_ID() oder Unterabfrage (SELECT person_id FROM person WHERE email = 'samira.benali@example.org') 1 P, Datum/Zeit im ISO-Format und ENUM-Werte richtig geschrieben 1 P. foto_einwilligung = FALSE ausdrücklich anzugeben ist ebenso richtig.

UPDATE session
SET status      = 'angenommen',
    raum_id     = (SELECT raum_id FROM raum WHERE bezeichnung = 'A.105'),
    slot_id     = (SELECT slot_id FROM slot WHERE beginn = '11:00:00'),
    max_plaetze = 32
WHERE session_id = 5;

Ergebnis: Session 5 hat jetzt status = 'angenommen', raum_id = 3, slot_id = 2, max_plaetze = 32.

Bewertung: mehrere Zuweisungen mit Komma 1 P, zwei Unterabfragen 2 P, WHERE auf den Primärschlüssel 1 P. Bei mehreren Veranstaltungen müsste die Slot-Unterabfrage zusätzlich AND veranstaltung_id = 1 enthalten. Werden die Zuweisungen mit AND verbunden, ist die Anweisung falsch (0,5 P für den Ansatz).

ca)

SELECT s.session_id, s.titel, r.bezeichnung, r.barrierefrei
FROM session AS s
  INNER JOIN raum AS r ON r.raum_id = s.raum_id
WHERE s.status = 'angenommen'
  AND r.barrierefrei = FALSE;

Bewertung: Verbund 1 P, beide Bedingungen 1 P, Ergebnis 1 P.

cb)

UPDATE session
SET raum_id = (SELECT raum_id FROM raum WHERE bezeichnung = 'B.201')
WHERE session_id = 2;

uq_raum_slot verlangt, dass jede Kombination aus Raum und Slot nur einmal vorkommt. B.201 (Raum 5) ist nur im Slot 3 belegt (Session 3); Session 2 liegt im Slot 2, die Kombination (5, 2) ist frei. Wäre sie belegt, würde MariaDB das UPDATE mit „Duplicate entry“ ablehnen.

Bewertung: UPDATE 2 P (WHERE session_id = 2 oder gleichwertige Bedingung), Begründung 1 P. Der Weg „erst mit SELECT prüfen, dann mit derselben Bedingung ändern“ ist bewusst so gewählt: So sieht man vorher, welche Zeilen betroffen sind.

NULL steht für „unbekannt“. Ein Vergleich mit NULL (=, <>, < …) ergibt deshalb ebenfalls „unbekannt“ und nie „wahr“ – keine Zeile erfüllt die Bedingung. Leere Felder findet man nur mit IS NULL. (2 P)

UPDATE session
SET max_plaetze = (SELECT r.plaetze
                   FROM raum AS r
                   WHERE r.raum_id = session.raum_id)
WHERE status = 'angenommen'
  AND max_plaetze IS NULL;

Geändert wird nur Session 1 (Aula): max_plaetze = 250. Session 5 hat seit b) bereits 32 Plätze, Session 7 ist abgelehnt.

Bewertung: korrelierte Unterabfrage im SET 2 P, WHERE mit IS NULL und Status 1 P, Ergebnis 1 P.

Alternative (MariaDB): UPDATE session AS s INNER JOIN raum AS r ON r.raum_id = s.raum_id SET s.max_plaetze = r.plaetze WHERE s.status = 'angenommen' AND s.max_plaetze IS NULL;

CREATE TABLE session_archiv LIKE session;

INSERT INTO session_archiv
SELECT *
FROM session
WHERE status IN ('abgelehnt', 'zurueckgezogen');

DELETE FROM session
WHERE session_id IN (SELECT session_id FROM session_archiv);

-- SELECT … INTO legt die Tabelle an und füllt sie in einem Schritt
-- (ohne Primärschlüssel, Indizes und Fremdschlüssel)
SELECT *
INTO session_archiv
FROM session
WHERE status IN ('abgelehnt', 'zurueckgezogen');

DELETE FROM session
WHERE session_id IN (SELECT session_id FROM session_archiv);

CREATE TABLE session_archiv (LIKE session INCLUDING INDEXES);

INSERT INTO session_archiv
SELECT *
FROM session
WHERE status IN ('abgelehnt', 'zurueckgezogen');

DELETE FROM session
WHERE session_id IN (SELECT session_id FROM session_archiv);

-- leere Tabelle mit denselben Spalten (ohne Schlüssel und Indizes)
CREATE TABLE session_archiv AS
SELECT * FROM session WHERE 1 = 0;

INSERT INTO session_archiv
SELECT *
FROM session
WHERE status IN ('abgelehnt', 'zurueckgezogen');

DELETE FROM session
WHERE session_id IN (SELECT session_id FROM session_archiv);

-- leere Tabelle mit denselben Spalten (ohne Schlüssel und Indizes)
CREATE TABLE session_archiv AS
SELECT * FROM session WHERE 1 = 0;

INSERT INTO session_archiv
SELECT *
FROM session
WHERE status IN ('abgelehnt', 'zurueckgezogen');

DELETE FROM session
WHERE session_id IN (SELECT session_id FROM session_archiv);

Ergebnis: Session 7 („Krypto-Trading für Einsteiger“) steht im Archiv und nicht mehr in session (6 Sessions verbleiben).

Mitgelöscht würden wegen ON DELETE CASCADE die zugehörigen Zeilen in session_person (Rollen), session_buchung (Buchungen) und – in der vollständigen Datenbank – feedback. Bei Session 7 gibt es keine solchen Zeilen; bei einer angenommenen, später zurückgezogenen Session gingen die Buchungen aber verloren und die Teilnehmenden müssten informiert werden. Die Referent*innen-Zuordnung landet nicht im Archiv – soll sie erhalten bleiben, braucht man auch eine session_person_archiv.

Bewertung: CREATE TABLE … LIKE 1 P (ausgeschriebenes CREATE TABLE mit allen Spalten ebenso), INSERT … SELECT * mit IN 2 P, DELETE mit Bezug auf das Archiv oder derselben Bedingung 2 P, Erläuterung CASCADE 1 P.

SELECT * ist hier zulässig, weil beide Tabellen dieselbe Spaltenreihenfolge haben. Hinweis: CREATE TABLE … LIKE übernimmt Indizes, aber keine Fremdschlüssel; für ein Archiv ist das meist erwünscht. Ebenfalls richtig ist CREATE TABLE session_archiv AS SELECT * FROM session WHERE status IN ('abgelehnt', 'zurueckgezogen'); – es ersetzt CREATE TABLE und INSERT (dann ohne Primärschlüssel und Indizes).

fa)

DELETE FROM anmeldung
WHERE person_id = (SELECT person_id
                   FROM person
                   WHERE email = 'fatma.oeztuerk@rrb-bielefeld.example');

Bewertung: DELETE FROM … WHERE 1 P, Unterabfrage über die E-Mail-Adresse 1 P (bei mehreren Veranstaltungen zusätzlich AND veranstaltung_id = 1).

fb) Der Fremdschlüssel session_buchung.anmeldung_id ist mit ON DELETE CASCADE definiert: Ihre drei Buchungen (Sessions 2, 4 und 6) werden automatisch mitgelöscht; die Plätze werden frei. MariaDB zählt als betroffene Zeilen nur die der Tabelle, aus der ausdrücklich gelöscht wurde, nicht die kaskadierten Zeilen. (2 P)

fc)

DELETE FROM person
WHERE NOT EXISTS (SELECT * FROM anmeldung AS a
                  WHERE a.person_id = person.person_id)
  AND NOT EXISTS (SELECT * FROM session_person AS sp
                  WHERE sp.person_id = person.person_id)
  AND NOT EXISTS (SELECT * FROM orga_aufgabe AS oa
                  WHERE oa.verantwortlich_id = person.person_id);

Gelöscht wird nur Fatma Öztürk (person_id 6); 14 Personen bleiben.

Bewertung: drei NOT EXISTS- bzw. NOT IN-Bedingungen mit AND 3 P, Ergebnis 1 P. Mit NOT IN (SELECT person_id FROM anmeldung) usw. ist es ebenso richtig, solange die Unterabfragen kein NULL liefern (die Spalten sind hier alle NOT NULL). Ohne die Bedingung zu orga_aufgabe würde das DELETE bei einer Person mit Orga-Aufgabe am Fremdschlüssel scheitern.

DELETE FROM orga_aufgabe
WHERE status = 'erledigt'
  AND faellig_am BETWEEN '2026-09-01' AND '2026-10-31';

Gelöscht wird die Aufgabe „Call for Participation veröffentlichen“ (fällig am 01.10.2026).

Bewertung: Bedingung auf den Status 1 P, BETWEEN mit ISO-Datumswerten 1 P, Verknüpfung mit AND 1 P. BETWEEN schließt beide Grenzen ein; bei faellig_am (Typ DATE) ist das unproblematisch. >= '2026-09-01' AND <= '2026-10-31' ist ebenso richtig; '01.09.2026' ist kein gültiges Datumsliteral.

INSERT INTO aktivitaet_archiv (aktivitaet_id, titel, hobby, ort, monat,
                               teilnehmende, sterne_schnitt)
SELECT a.aktivitaet_id,
       a.titel,
       h.bezeichnung,
       tp.ort,
       DATE_FORMAT(a.beginn, '%Y-%m'),
       (SELECT COUNT(*)
        FROM teilnahme AS t
        WHERE t.aktivitaet_id = a.aktivitaet_id
          AND t.status = 'teilgenommen'),
       (SELECT AVG(b.sterne)
        FROM bewertung AS b
        WHERE b.aktivitaet_id = a.aktivitaet_id)
FROM aktivitaet AS a
  INNER JOIN hobby AS h       ON h.hobby_id = a.hobby_id
  INNER JOIN treffpunkt AS tp ON tp.treffpunkt_id = a.treffpunkt_id
WHERE a.status = 'stattgefunden'
  AND a.beginn < CURDATE() - INTERVAL 14 DAY;

INSERT INTO aktivitaet_archiv (aktivitaet_id, titel, hobby, ort, monat,
                               teilnehmende, sterne_schnitt)
SELECT a.aktivitaet_id,
       a.titel,
       h.bezeichnung,
       tp.ort,
       FORMAT(a.beginn, 'yyyy-MM'),
       (SELECT COUNT(*)
        FROM teilnahme AS t
        WHERE t.aktivitaet_id = a.aktivitaet_id
          AND t.status = 'teilgenommen'),
       (SELECT AVG(CAST(b.sterne AS DECIMAL(3,2)))  -- AVG über INT liefert sonst eine ganze Zahl
        FROM bewertung AS b
        WHERE b.aktivitaet_id = a.aktivitaet_id)
FROM aktivitaet AS a
  INNER JOIN hobby AS h       ON h.hobby_id = a.hobby_id
  INNER JOIN treffpunkt AS tp ON tp.treffpunkt_id = a.treffpunkt_id
WHERE a.status = 'stattgefunden'
  AND a.beginn < DATEADD(DAY, -14, CAST(GETDATE() AS date));

INSERT INTO aktivitaet_archiv (aktivitaet_id, titel, hobby, ort, monat,
                               teilnehmende, sterne_schnitt)
SELECT a.aktivitaet_id,
       a.titel,
       h.bezeichnung,
       tp.ort,
       TO_CHAR(a.beginn, 'YYYY-MM'),
       (SELECT COUNT(*)
        FROM teilnahme AS t
        WHERE t.aktivitaet_id = a.aktivitaet_id
          AND t.status = 'teilgenommen'),
       (SELECT AVG(b.sterne)
        FROM bewertung AS b
        WHERE b.aktivitaet_id = a.aktivitaet_id)
FROM aktivitaet AS a
  INNER JOIN hobby AS h       ON h.hobby_id = a.hobby_id
  INNER JOIN treffpunkt AS tp ON tp.treffpunkt_id = a.treffpunkt_id
WHERE a.status = 'stattgefunden'
  AND a.beginn < CURRENT_DATE - 14;          -- date - integer = Tage

INSERT INTO aktivitaet_archiv (aktivitaet_id, titel, hobby, ort, monat,
                               teilnehmende, sterne_schnitt)
SELECT a.aktivitaet_id,
       a.titel,
       h.bezeichnung,
       tp.ort,
       TO_CHAR(a.beginn, 'YYYY-MM'),
       (SELECT COUNT(*)
        FROM teilnahme t
        WHERE t.aktivitaet_id = a.aktivitaet_id
          AND t.status = 'teilgenommen'),
       (SELECT AVG(b.sterne)
        FROM bewertung b
        WHERE b.aktivitaet_id = a.aktivitaet_id)
FROM aktivitaet a
  INNER JOIN hobby h       ON h.hobby_id = a.hobby_id
  INNER JOIN treffpunkt tp ON tp.treffpunkt_id = a.treffpunkt_id
WHERE a.status = 'stattgefunden'
  AND a.beginn < TRUNC(SYSDATE) - 14;        -- DATE - Zahl = Tage

INSERT INTO aktivitaet_archiv (aktivitaet_id, titel, hobby, ort, monat,
                               teilnehmende, sterne_schnitt)
SELECT a.aktivitaet_id,
       a.titel,
       h.bezeichnung,
       tp.ort,
       strftime('%Y-%m', a.beginn),
       (SELECT COUNT(*)
        FROM teilnahme AS t
        WHERE t.aktivitaet_id = a.aktivitaet_id
          AND t.status = 'teilgenommen'),
       (SELECT AVG(b.sterne)
        FROM bewertung AS b
        WHERE b.aktivitaet_id = a.aktivitaet_id)
FROM aktivitaet AS a
  INNER JOIN hobby AS h       ON h.hobby_id = a.hobby_id
  INNER JOIN treffpunkt AS tp ON tp.treffpunkt_id = a.treffpunkt_id
WHERE a.status = 'stattgefunden'
  AND a.beginn < DATE('now', '-14 days');

CURDATE() - INTERVAL 14 DAY ist der 04.10.2026 (00:00 Uhr). Die Wanderung (Aktivität 2) beginnt am 04.10.2026 um 10:00 Uhr und ist damit noch nicht älter als 14 Tage.

Bewertung: INSERT INTO … (Spaltenliste) SELECT 1 P, Verbund mit hobby und treffpunkt 1 P, DATE_FORMAT (oder CONCAT(YEAR(…), '-', LPAD(MONTH(…), 2, '0'))) 1 P, Teilnehmende mit Statusbedingung 1 P, Durchschnitt der Sterne 1 P, Statusbedingung 1 P, Datumsbedingung 1 P, Ergebniszeile 1 P.

Typischer Fehler: teilnahme und bewertung gleichzeitig per LEFT JOIN verbinden und dann gruppieren. Jede der 4 Teilnahmen wird dann mit jeder der 2 Bewertungen kombiniert: COUNT liefert 8 statt 4 Teilnehmende (der Durchschnitt bleibt gleich, weil jede Bewertung gleich oft vervielfacht wird). Abhilfe sind die Unterabfragen in der Spaltenliste – oder COUNT(DISTINCT t.benutzer_id) (dann aber nicht für SUM). Eine Lösung ohne Statusbedingung bei den Teilnahmen zählt auch die Teilnahme mit Status 'nicht_erschienen' mit (5 statt 4 Teilnehmende). Mit NOW() - INTERVAL 14 DAY statt CURDATE() wird nach 10:00 Uhr auch die Wanderung (Aktivität 2) erfasst; das ist vertretbar, wenn man „14 Tage“ auf die Uhrzeit genau versteht (Datumsbedingung trotzdem 1 P).

DELETE FROM aktivitaet
WHERE aktivitaet_id IN (SELECT aktivitaet_id FROM aktivitaet_archiv);

• teilnahme und bewertung: Wegen ON DELETE CASCADE werden die fünf Teilnahmen und zwei Bewertungen von Aktivität 1 automatisch mitgelöscht.

• meldung: Die Meldung bleibt erhalten (Nachvollziehbarkeit der Moderation), ihr Fremdschlüssel aktivitaet_id wird wegen ON DELETE SET NULL auf NULL gesetzt.

Bewertung: DELETE mit Unterabfrage auf das Archiv 2 P (dieselbe Bedingung wie in a) ist ebenfalls richtig, siehe aber c), 1 P), Erläuterung CASCADE 1 P, SET NULL 1 P.

Verweis auf das Archiv: Gelöscht wird nur, was nachweislich archiviert wurde. Eine wiederholte Bedingung kann eine andere Menge treffen – etwa wenn zwischen den Anweisungen der Status einer Aktivität auf 'stattgefunden' gesetzt wird oder um Mitternacht CURDATE() wechselt. Dann würde eine Aktivität gelöscht, ohne archiviert zu sein. (1 P)

Fehler zwischen a) und b): Ohne Transaktion bliebe ein halber Zustand zurück (archiviert, aber nicht gelöscht – oder bei umgekehrter Reihenfolge gelöscht, aber nicht archiviert, was die Daten für immer vernichtet). Eine Transaktion macht beide Schritte zu einer Einheit: Entweder beide wirken oder keiner. (1 P)

START TRANSACTION;

INSERT INTO aktivitaet_archiv (…)
SELECT …;                      -- Anweisung aus a)

DELETE FROM aktivitaet
WHERE aktivitaet_id IN (SELECT aktivitaet_id FROM aktivitaet_archiv);

COMMIT;                        -- bei einem Fehler stattdessen ROLLBACK;

Bewertung: Rahmen mit START TRANSACTION (oder BEGIN) und COMMIT 1 P, ROLLBACK für den Fehlerfall 1 P. Das CREATE TABLE der Archivtabelle gehört nicht in die Transaktion – DDL-Anweisungen lösen in MariaDB einen impliziten COMMIT aus.

DELETE FROM aktivitaet
WHERE status = 'abgesagt'
  AND beginn < CURDATE() - INTERVAL 14 DAY;

Gelöscht wird Aktivität 6 („Schach im Park“, 27.09.2026) und per CASCADE ihre eine Teilnahme.

Bewertung: Statusbedingung 1 P, Datumsbedingung 1 P, Ergebnis mit Hinweis auf die kaskadierte Teilnahme 1 P. DATEDIFF(CURDATE(), beginn) > 14 ist ebenso richtig.

ea)

UPDATE benutzer
SET vorname    = 'gelöscht',
    nachname   = 'gelöscht',
    email      = CONCAT('geloescht-', benutzer_id, '@anonym.example'),
    strasse    = NULL,
    hausnr     = NULL,
    geschlecht = NULL,
    status     = 'geloescht'
WHERE status = 'gesperrt'
  AND DATEDIFF(CURDATE(), letzter_login) > 180;

UPDATE benutzer
SET vorname    = 'gelöscht',
    nachname   = 'gelöscht',
    email      = CONCAT('geloescht-', benutzer_id, '@anonym.example'),
    strasse    = NULL,
    hausnr     = NULL,
    geschlecht = NULL,
    status     = 'geloescht'
WHERE status = 'gesperrt'
  AND DATEDIFF(DAY, letzter_login, GETDATE()) > 180;

UPDATE benutzer
SET vorname    = 'gelöscht',
    nachname   = 'gelöscht',
    email      = CONCAT('geloescht-', benutzer_id, '@anonym.example'),
    strasse    = NULL,
    hausnr     = NULL,
    geschlecht = NULL,
    status     = 'geloescht'
WHERE status = 'gesperrt'
  AND CURRENT_DATE - CAST(letzter_login AS date) > 180;

UPDATE benutzer
SET vorname    = 'gelöscht',
    nachname   = 'gelöscht',
    email      = 'geloescht-' || benutzer_id || '@anonym.example',
    strasse    = NULL,
    hausnr     = NULL,
    geschlecht = NULL,
    status     = 'geloescht'
WHERE status = 'gesperrt'
  AND TRUNC(SYSDATE) - TRUNC(letzter_login) > 180;

UPDATE benutzer
SET vorname    = 'gelöscht',
    nachname   = 'gelöscht',
    email      = 'geloescht-' || benutzer_id || '@anonym.example',
    strasse    = NULL,
    hausnr     = NULL,
    geschlecht = NULL,
    status     = 'geloescht'
WHERE status = 'gesperrt'
  AND julianday(DATE('now')) - julianday(DATE(letzter_login)) > 180;

Ergebnis: Das Konto 11 hat jetzt vorname = nachname = 'gelöscht', email = 'geloescht-11@anonym.example', strasse, hausnr, geschlecht sind NULL, status = 'geloescht' (231 Tage seit dem letzten Login).

Bewertung: sieben Zuweisungen mit Komma 2 P (davon CONCAT mit der eigenen benutzer_id 1 P), NULL setzen mit = NULL im SET 1 P, Statusbedingung 1 P, Datumsbedingung 1 P, Status wird mitgeändert (sonst trifft die Regel das Konto beim nächsten Lauf erneut) 1 P. letzter_login < CURDATE() - INTERVAL 180 DAY ist ebenso richtig. Eine konstante E-Mail-Adresse für alle Konten scheitert an UNIQUE, sobald zwei Konten anonymisiert werden.

eb) Nicht vollständig: Geburtsdatum, Postleitzahl, Ort, Registrierungszeitpunkt und der Passwort-Hash bleiben stehen; zusammen mit der verbleibenden Meldung, in der Elena als gemeldete Person eingetragen ist (bei anderen Konten auch mit Teilnahmen oder Freundschaften), lässt sich die Person ggf. wieder bestimmen. Damit ist der Datensatz eher pseudonymisiert. Vorschlag: Geburtsdatum auf das Geburtsjahr vergröbern, Passwort-Hash überschreiben, nicht mehr benötigte verknüpfte Daten löschen – und prüfen, ob Meldungen aus Gründen der Nachvollziehbarkeit (berechtigtes Interesse) noch gebraucht werden. (2 P für Einschätzung mit Begründung)

• Das Semikolon nach FALSE beendet das UPDATE: Es setzt verifiziert = FALSE bei allen Konten. Die zweite Zeile ist eine eigene Anweisung und erzeugt einen Syntaxfehler – der Schaden ist aber schon passiert (ohne Transaktion nicht rückgängig zu machen). (1 P)

• = NULL ist nie wahr; auch mit richtig gesetztem WHERE würde keine Zeile getroffen. Es muss IS NULL heißen. (1 P)

UPDATE benutzer
SET verifiziert = FALSE
WHERE (strasse IS NULL OR hausnr IS NULL)
  AND status <> 'geloescht';

Getroffen wird nur Jana Meier (8). Weil sie bereits nicht verifiziert ist, meldet MariaDB „Rows matched: 1 Changed: 0“. Ohne die Klammern bindet AND stärker als OR: Die Bedingung hieße strasse IS NULL OR (hausnr IS NULL AND status <> 'geloescht') und würde anonymisierte Konten (dort ist strasse NULL) doch erfassen – im Datenbestand Elena Wagner (11). (2 P für die Korrektur einschließlich Klammern)

ga) Mit INT ginge die führende Null verloren: Aus 0521 würde 521, aus 030 würde 30 – die Vorwahl wäre unbrauchbar. Telefonnummern sind Kennungen, mit denen niemand rechnet; außerdem könnten später Zeichen wie +49 vorkommen. Passend sind Textspalten, z. B. VARCHAR(6) und VARCHAR(12).

ALTER TABLE altdaten_import
ADD COLUMN vorwahl   VARCHAR(6),
ADD COLUMN rufnummer VARCHAR(12);

UPDATE altdaten_import
SET vorwahl   = SUBSTRING_INDEX(telefon, ' ', 1),
    rufnummer = REPLACE(SUBSTRING(telefon, LOCATE(' ', telefon) + 1), ' ', '');

-- Kontrolle: SELECT telefon, vorwahl, rufnummer FROM altdaten_import;
ALTER TABLE altdaten_import
DROP COLUMN telefon;

ALTER TABLE altdaten_import
ADD vorwahl   VARCHAR(6),
    rufnummer VARCHAR(12);
GO  -- neue Spalten sind erst im nächsten Batch bekannt

UPDATE altdaten_import
SET vorwahl   = LEFT(telefon, CHARINDEX(' ', telefon) - 1),
    rufnummer = REPLACE(SUBSTRING(telefon, CHARINDEX(' ', telefon) + 1, LEN(telefon)), ' ', '');

ALTER TABLE altdaten_import
DROP COLUMN telefon;

ALTER TABLE altdaten_import
ADD COLUMN vorwahl   VARCHAR(6),
ADD COLUMN rufnummer VARCHAR(12);

UPDATE altdaten_import
SET vorwahl   = SPLIT_PART(telefon, ' ', 1),
    rufnummer = REPLACE(SUBSTRING(telefon FROM POSITION(' ' IN telefon) + 1), ' ', '');

ALTER TABLE altdaten_import
DROP COLUMN telefon;

ALTER TABLE altdaten_import
ADD (vorwahl   VARCHAR2(6),
     rufnummer VARCHAR2(12));

UPDATE altdaten_import
SET vorwahl   = SUBSTR(telefon, 1, INSTR(telefon, ' ') - 1),
    rufnummer = REPLACE(SUBSTR(telefon, INSTR(telefon, ' ') + 1), ' ', '');

ALTER TABLE altdaten_import
DROP COLUMN telefon;

-- je Spalte ein ADD COLUMN; DROP COLUMN ab SQLite 3.35
ALTER TABLE altdaten_import
ADD COLUMN vorwahl VARCHAR(6);

ALTER TABLE altdaten_import
ADD COLUMN rufnummer VARCHAR(12);

UPDATE altdaten_import
SET vorwahl   = SUBSTR(telefon, 1, INSTR(telefon, ' ') - 1),
    rufnummer = REPLACE(SUBSTR(telefon, INSTR(telefon, ' ') + 1), ' ', '');

ALTER TABLE altdaten_import
DROP COLUMN telefon;

Ergebnis (Auszug):

Bewertung: Begründung gegen INT (führende Null, keine Rechengröße) 2 P, ADD COLUMN mit Textdatentyp 1 P, Vorwahl über SUBSTRING_INDEX(telefon, ' ', 1) 1 P, Rufnummer als Rest nach dem ersten Leerzeichen mit REPLACE 1 P, DROP COLUMN erst nach dem UPDATE 1 P. SUBSTRING_INDEX(telefon, ' ', -1) für die Rufnummer liefert in Zeile 10 nur 9087 – genau solche Fälle zeigt die Kontrolle mit SELECT vor dem DROP COLUMN, das sich nicht zurücknehmen lässt.

gb)

UPDATE altdaten_import
SET geburtsdatum = '2002-03-08'
WHERE name = 'Haddad, Malik'
  AND geburtsdatum = '1902-03-08';

Bewertung: Zuweisung im ISO-Format 1 P, Bedingung, die genau diesen Datensatz trifft (Primärschlüssel zeile = 2 ist ebenso richtig) 1 P. Durch die Bedingung auf den alten Wert ändert eine zweite Ausführung nichts mehr.

UPDATE nutzer
SET aktiv = FALSE
WHERE TIMESTAMPDIFF(YEAR, geburtsdatum, CURDATE()) < 18
  AND einwilligung_eltern IS NULL;

-- DATEDIFF(YEAR, …) zählt nur Jahreswechsel und taugt nicht für das Alter
UPDATE nutzer
SET aktiv = 0
WHERE geburtsdatum > DATEADD(YEAR, -18, CAST(GETDATE() AS date))
  AND einwilligung_eltern IS NULL;

UPDATE nutzer
SET aktiv = FALSE
WHERE geburtsdatum > CURRENT_DATE - INTERVAL '18 years'
  AND einwilligung_eltern IS NULL;

UPDATE nutzer
SET aktiv = 0   -- ab Oracle 23ai auch FALSE
WHERE MONTHS_BETWEEN(TRUNC(SYSDATE), geburtsdatum) / 12 < 18
  AND einwilligung_eltern IS NULL;

UPDATE nutzer
SET aktiv = FALSE
WHERE geburtsdatum > DATE('now', '-18 years')
  AND einwilligung_eltern IS NULL;

Deaktiviert wird nur Lina Hartwig (8).

Bewertung: SET aktiv = FALSE 1 P, Altersberechnung mit TIMESTAMPDIFF (oder geburtsdatum > CURDATE() - INTERVAL 18 YEAR) 2 P, IS NULL 1 P. YEAR(CURDATE()) - YEAR(geburtsdatum) < 18 ist ungenau (berücksichtigt den Geburtstag nicht): 1 P für die Altersbedingung.

DELETE FROM gesuch
WHERE status = 'offen'
  AND nutzer_id IN (SELECT nutzer_id
                    FROM nutzer
                    WHERE aktiv = FALSE);

Gelöscht wird Gesuch 4. Linas Buchung 3 bezieht sich auf Angebot 1, nicht auf ein Gesuch (gesuch_id ist NULL); und selbst wenn sie auf das Gesuch verwiese, würde wegen ON DELETE SET NULL nur der Verweis geleert, die Buchung bliebe erhalten.

Bewertung: DELETE mit Unterabfrage 2 P, Statusbedingung 1 P, Erläuterung SET NULL bzw. fehlender Verweis 1 P.

UPDATE angebot AS a
  INNER JOIN haltepunkt AS h ON h.haltepunkt_id = a.haltepunkt_id
SET a.kostenbeitrag_eur = ROUND(h.entfernung_km * 0.10, 2)
WHERE a.status = 'offen'
  AND a.kostenbeitrag_eur > h.entfernung_km * 0.10;

Geändert wird nur Angebot 5 von Niklas Fischer (Bad Salzuflen, 19,4 km): von 2,50 € auf 1,94 €. Alle anderen offenen Angebote liegen unter ihrer Grenze (z. B. Gütersloh: 1,80 € ≤ 1,86 €).

Bewertung: UPDATE … INNER JOIN … ON 2 P, Zuweisung mit Berechnung und Rundung 1 P, Bedingung „überschreitet“ 1 P, Statusbedingung 1 P, Ergebnis 1 P.

Alternative ohne Verbund (Standard-SQL, korrelierte Unterabfragen):

UPDATE angebot
SET kostenbeitrag_eur = (SELECT ROUND(h.entfernung_km * 0.10, 2)
                         FROM haltepunkt AS h
                         WHERE h.haltepunkt_id = angebot.haltepunkt_id)
WHERE status = 'offen'
  AND kostenbeitrag_eur > (SELECT h.entfernung_km * 0.10
                           FROM haltepunkt AS h
                           WHERE h.haltepunkt_id = angebot.haltepunkt_id);

Wird abgerundet statt gerundet (FLOOR(h.entfernung_km * 10) / 100), ist das ebenso richtig – „höchstens“ ist damit sogar sicher eingehalten.

UPDATE buchung
SET status = 'storniert'
WHERE status = 'angefragt'
  AND angebot_id IN (SELECT angebot_id
                     FROM angebot
                     WHERE status = 'offen'
                       AND datum <= '2026-10-20');

UPDATE angebot
SET status = 'durchgefuehrt'
WHERE status IN ('offen', 'voll')
  AND datum <= '2026-10-20';

UPDATE gesuch
SET status = 'abgelaufen'
WHERE status = 'offen'
  AND datum <= '2026-10-20';

Ergebnis: Buchung 5 → 'storniert'; Angebote 1, 2, 3 und 4 → 'durchgefuehrt'; Gesuch 1 → 'abgelaufen'.

Reihenfolge: Schritt 1 erkennt die betroffenen Angebote am Status 'offen'. Nach Schritt 2 hätten sie diesen Status nicht mehr, die Unterabfrage fände kein Angebot und die Anfrage bliebe auf 'angefragt' stehen.

Bewertung: je Anweisung 1,5 P (Bedingungen mit IN bzw. <= und Datumsliteral im ISO-Format), Begründung 1,5 P. Mit CURDATE() statt '2026-10-20' ist es ebenfalls richtig, wenn der Abschluss am selben Tag läuft.

ea)

INSERT INTO fahrzeug (nutzer_id, sitzplaetze)
VALUES (7, 4);

typ kommt aus dem DEFAULT, farbe bleibt NULL, die fahrzeug_id vergibt AUTO_INCREMENT. (1 P Anweisung, 1 P Datensatz)

eb) Die Bedingung chk_sitze erlaubt nur 1 bis 8 Mitfahrplätze. MariaDB lehnt das INSERT ab (Fehler 4025 „CONSTRAINT chk_sitze failed“), es wird kein Datensatz gespeichert. Ein Kleinbus mit Fahrer*in und 9 Mitfahrenden bräuchte ohnehin eine andere Führerscheinklasse – die Regel ist also auch fachlich sinnvoll. (2 P)

fa)

START TRANSACTION;

DELETE FROM bewertung
WHERE buchung_id IN (SELECT bu.buchung_id
                     FROM buchung AS bu
                       INNER JOIN angebot AS a ON a.angebot_id = bu.angebot_id
                     WHERE a.datum < '2026-10-16');

DELETE FROM buchung
WHERE angebot_id IN (SELECT angebot_id
                     FROM angebot
                     WHERE datum < '2026-10-16');

DELETE FROM angebot
WHERE datum < '2026-10-16';

DELETE FROM gesuch
WHERE datum < '2026-10-16';

ROLLBACK;

Nach ROLLBACK sind alle Datensätze wieder vorhanden.

Bewertung: Transaktion mit START TRANSACTION und ROLLBACK 2 P, DELETE für bewertung mit Unterabfrage über buchung und angebot 2 P, buchung 1 P, angebot 1 P, gesuch 1 P, Anzahlen 1 P.

fb) Die Datensätze werden von unten nach oben gelöscht: Bewertungen verweisen auf Buchungen, Buchungen auf Angebote. Ohne CASCADE würde das Löschen eines Angebots mit Buchungen am Fremdschlüssel scheitern (Fehler 1451). Das Gesuch kann vor oder nach den Buchungen gelöscht werden, weil buchung.gesuch_id mit SET NULL definiert ist (sonst müsste es nach den Buchungen kommen). Mit den vorhandenen Regeln wären die ersten beiden DELETE-Anweisungen entbehrlich: DELETE FROM angebot … löscht per CASCADE die Buchungen und darüber per CASCADE die Bewertungen. Die ausdrückliche Reihenfolge macht die Routine aber unabhängig von den Regeln und zeigt im Protokoll, was gelöscht wird. (1 P Reihenfolge, 1 P Gesuch/SET NULL, 1 P Kaskade)

fc) TRUNCATE ist hier ungeeignet:

• Es löscht immer alle Zeilen, eine Bedingung (Stichtag) ist nicht möglich.

• Es gehört zur DDL und beendet in MariaDB eine laufende Transaktion mit einem impliziten COMMIT; ein ROLLBACK ist danach nicht möglich.

• Bei InnoDB wird TRUNCATE für eine Tabelle abgelehnt, auf die ein Fremdschlüssel einer anderen Tabelle verweist (hier bewertung.buchung_id).

Bei den kleinen Datenmengen einer Schul-App ist der Geschwindigkeitsvorteil zudem unerheblich. DELETE mit Bedingung in einer Transaktion ist die richtige Wahl. (je Argument 1 P)

INSERT INTO bestellweg (bezeichnung)
VALUES ('Portal'), ('Telefon'), ('E-Mail');

Bewertung: Spaltenliste ohne Schlüsselspalte (die Werte vergibt AUTO_INCREMENT) 1 Punkt, drei Wertetupel in einer Anweisung mit Texten in Hochkommata 1 Punkt. Die Datenbank vergibt die Schlüssel 1, 2 und 3.

Referentielle Integrität bedeutet, dass jeder Fremdschlüsselwert auf einen vorhandenen Primärschlüsselwert der referenzierten Tabelle verweist oder NULL ist (1 Punkt). Das DBMS prüft das bei jedem INSERT, UPDATE und DELETE (1 Punkt). haendler.bestellweg_id verweist auf bestellweg: Gäbe es dort noch keine Zeilen, würde jede Übernahme mit gesetztem Bestellweg abgelehnt – also werden Nachschlage- und Elterntabellen zuerst befüllt, abhängige Tabellen danach (1 Punkt).

INSERT INTO haendler (haendler_nr, firma, ansprechperson, strasse, plz, ort,
                      email, rabatt_prozent, kunde_seit, bestellweg_id)
SELECT h.`HNr`, h.`Firma`, h.`Ansprechperson`, h.`Strasse`, h.`PLZ`, h.`Ort`,
       h.`E-Mail`, h.`Rabatt`, h.`Kunde seit`, w.bestellweg_id
FROM haendler_bereinigt AS h
  LEFT JOIN bestellweg AS w
         ON w.bezeichnung = CASE h.`Bestellweg`
                              WHEN 'Programm' THEN 'Portal'
                              ELSE h.`Bestellweg`
                            END
WHERE h.`Status` = 'A';

INSERT INTO haendler (haendler_nr, firma, ansprechperson, strasse, plz, ort,
                      email, rabatt_prozent, kunde_seit, bestellweg_id)
SELECT h.[HNr], h.[Firma], h.[Ansprechperson], h.[Strasse], h.[PLZ], h.[Ort],
       h.[E-Mail], h.[Rabatt], h.[Kunde seit], w.bestellweg_id
FROM haendler_bereinigt AS h
  LEFT JOIN bestellweg AS w
         ON w.bezeichnung = CASE h.[Bestellweg]
                              WHEN 'Programm' THEN 'Portal'
                              ELSE h.[Bestellweg]
                            END
WHERE h.[Status] = 'A';

-- Bezeichner mit Sonder- oder Leerzeichen in doppelten Anführungszeichen
INSERT INTO haendler (haendler_nr, firma, ansprechperson, strasse, plz, ort,
                      email, rabatt_prozent, kunde_seit, bestellweg_id)
SELECT h."HNr", h."Firma", h."Ansprechperson", h."Strasse", h."PLZ", h."Ort",
       h."E-Mail", h."Rabatt", h."Kunde seit", w.bestellweg_id
FROM haendler_bereinigt AS h
  LEFT JOIN bestellweg AS w
         ON w.bezeichnung = CASE h."Bestellweg"
                              WHEN 'Programm' THEN 'Portal'
                              ELSE h."Bestellweg"
                            END
WHERE h."Status" = 'A';

-- Bezeichner in doppelten Anführungszeichen (Groß-/Kleinschreibung zählt),
-- Tabellenaliase ohne AS
INSERT INTO haendler (haendler_nr, firma, ansprechperson, strasse, plz, ort,
                      email, rabatt_prozent, kunde_seit, bestellweg_id)
SELECT h."HNr", h."Firma", h."Ansprechperson", h."Strasse", h."PLZ", h."Ort",
       h."E-Mail", h."Rabatt", h."Kunde seit", w.bestellweg_id
FROM haendler_bereinigt h
  LEFT JOIN bestellweg w
         ON w.bezeichnung = CASE h."Bestellweg"
                              WHEN 'Programm' THEN 'Portal'
                              ELSE h."Bestellweg"
                            END
WHERE h."Status" = 'A';

-- Bezeichner in doppelten Anführungszeichen (Backticks wie in MariaDB gehen auch)
INSERT INTO haendler (haendler_nr, firma, ansprechperson, strasse, plz, ort,
                      email, rabatt_prozent, kunde_seit, bestellweg_id)
SELECT h."HNr", h."Firma", h."Ansprechperson", h."Strasse", h."PLZ", h."Ort",
       h."E-Mail", h."Rabatt", h."Kunde seit", w.bestellweg_id
FROM haendler_bereinigt AS h
  LEFT JOIN bestellweg AS w
         ON w.bezeichnung = CASE h."Bestellweg"
                              WHEN 'Programm' THEN 'Portal'
                              ELSE h."Bestellweg"
                            END
WHERE h."Status" = 'A';

Bewertung: Spaltenliste von haendler ohne portal_aktiv und angelegt_am, damit beide ihre Standardwerte erhalten (2 Punkte); SELECT mit denselben Spalten in derselben Reihenfolge – zugeordnet wird nur nach der Position, die Spaltennamen dürfen abweichen (2 Punkte); Spaltennamen mit Bindestrich bzw. Leerzeichen in Backticks (1 Punkt); Verbund mit bestellweg statt fester Schlüssel (2 Punkte); Umsetzen von „Programm“ auf „Portal“ mit CASE (1 Punkt); Bedingung Status = 'A' (1 Punkt).

Ergebnis: 5 Zeilen eingefügt.

Der LEFT JOIN sorgt dafür, dass ein Händler auch dann übernommen wird, wenn sein Bestellweg nicht in bestellweg vorkommt (dann mit NULL); ein INNER JOIN ist hier ebenfalls richtig, weil alle Bestellwege vorhanden sind. Ebenfalls richtig ist eine Unterabfrage in der Spaltenliste: (SELECT w.bestellweg_id FROM bestellweg AS w WHERE w.bezeichnung = CASE … END). Die Zeilen 1012 (Dublette), 1026 (Klärung) und 1031 (geschlossen) werden bewusst nicht übernommen. Zur Kontrolle vergleicht man die Zeilenzahl der Quelle (SELECT COUNT(*) FROM haendler_bereinigt WHERE Status = 'A'; liefert 5) mit den eingefügten Zeilen.

Der Vorschlag scheitert: Ohne Spaltenliste erwartet haendler Werte für alle 12 Spalten, SELECT * liefert aber nur 11 (MariaDB: „Column count doesn’t match value count“) (1 Punkt). Selbst bei gleicher Spaltenzahl ordnet MariaDB nur nach der Position zu, nicht nach Namen oder Inhalt: Status ('A') würde in bestellweg_id landen und Bestellweg ('Programm') in portal_aktiv – das scheitert oder speichert Unsinn (1 Punkt). Außerdem fehlt die Umsetzung „Programm“ → „Portal“ über die Tabelle bestellweg. SELECT * eignet sich nur, wenn Quelle und Ziel exakt gleich aufgebaut sind (z. B. eine mit CREATE TABLE … LIKE angelegte Archivtabelle) (1 Punkt).

UPDATE haendler
SET portal_aktiv = TRUE
WHERE bestellweg_id = (SELECT bestellweg_id
                       FROM bestellweg
                       WHERE bezeichnung = 'Portal')
  AND kunde_seit <= CURDATE() - INTERVAL 1 YEAR;

UPDATE haendler
SET portal_aktiv = 1
WHERE bestellweg_id = (SELECT bestellweg_id
                       FROM bestellweg
                       WHERE bezeichnung = 'Portal')
  AND kunde_seit <= DATEADD(YEAR, -1, CAST(GETDATE() AS date));

UPDATE haendler
SET portal_aktiv = TRUE
WHERE bestellweg_id = (SELECT bestellweg_id
                       FROM bestellweg
                       WHERE bezeichnung = 'Portal')
  AND kunde_seit <= CURRENT_DATE - INTERVAL '1 year';

UPDATE haendler
SET portal_aktiv = 1   -- ab Oracle 23ai auch TRUE
WHERE bestellweg_id = (SELECT bestellweg_id
                       FROM bestellweg
                       WHERE bezeichnung = 'Portal')
  AND kunde_seit <= ADD_MONTHS(TRUNC(SYSDATE), -12);

UPDATE haendler
SET portal_aktiv = TRUE
WHERE bestellweg_id = (SELECT bestellweg_id
                       FROM bestellweg
                       WHERE bezeichnung = 'Portal')
  AND kunde_seit <= DATE('now', '-1 year');

Bewertung: UPDATE … SET portal_aktiv = TRUE (1 Punkt); Bestellweg über eine Unterabfrage auf die Bezeichnung (2 Punkte); Datumsbedingung relativ zum heutigen Datum (1 Punkt). Freigeschaltet sind 1004 (Radhaus Bielefeld-Süd, Kunde seit 05.11.2024) und 1017 (Velowerk Münster) (1 Punkt). Pedale & Co. hat in kunde_seit den Wert NULL; jeder Vergleich mit NULL ergibt unbekannt, und WHERE übernimmt nur Zeilen, bei denen die Bedingung wahr ist (1 Punkt). Zweirad Lohmann und Leipziger Radkontor bestellen nicht über das Portal.

UPDATE haendler
SET ansprechperson = 'Elif Demir',
    email          = 'elif.demir@velowerk-ms.example'
WHERE haendler_nr = 1017;

Bewertung: zwei Zuweisungen mit Komma getrennt (1 Punkt), Bedingung auf den Primärschlüssel (1 Punkt), Begründung (1 Punkt): Nur der Primärschlüssel identifiziert genau einen Datensatz. Firmennamen sind nicht als eindeutig definiert und werden unterschiedlich geschrieben (siehe die Dublette „Radhaus Bielefeld Süd“); eine Bedingung wie WHERE firma = 'Velowerk Münster GmbH' träfe womöglich mehrere oder gar keine Zeilen.

Fehler (je 1 Punkt, höchstens 4):

• Die Spalte heißt email; e-mail liest MariaDB als Rechnung e minus mail – in einer Spaltenliste ein Syntaxfehler.

• Der Firmenname ist ein Text und muss in Hochkommata stehen.

• 3,5 mit Dezimalkomma sind zwei Werte (3 und 5); damit stimmt die Zahl der Werte nicht mehr mit der Spaltenliste überein. Richtig ist 3.5.

• Das Datum muss als Zeichenkette im ISO-Format stehen: '2026-11-01'.

• Die Postleitzahl ist als CHAR(5) definiert und gehört in Hochkommata; als Zahl verlöre z. B. 04275 die führende Null.

INSERT INTO haendler (haendler_nr, firma, ansprechperson, strasse, plz, ort, email,
                      rabatt_prozent, kunde_seit)
VALUES (1040, 'Fahrradwerkstatt Kessebohm', 'Anke Kessebohm', 'Herforder Straße 120',
        '33609', 'Bielefeld', 'werkstatt@kessebohm.example', 3.5, '2026-11-01');

Korrigierte Anweisung: 2 Punkte. bestellweg_id bleibt NULL, portal_aktiv erhält FALSE, angelegt_am den aktuellen Zeitpunkt.

DELETE FROM haendler_bereinigt
WHERE `HNr` IN (SELECT haendler_nr
                FROM haendler);

Bewertung: DELETE FROM mit Bedingung (1 Punkt), Unterabfrage auf die übernommenen Schlüssel (1 Punkt), Ergebnis (1 Punkt): 5 Zeilen gelöscht, übrig bleiben 1012 (Dublette), 1026 (Klärung offen) und 1031 (geschlossen). TRUNCATE wäre falsch, weil es alle Zeilen entfernt. Eine Bedingung WHERE Status = 'A' führt hier zum selben Ergebnis, prüft aber nicht, ob die Übernahme wirklich geklappt hat.

SELECT t.slot, a.bezeichnung, t.auftragsnr,
       k.auftragsnr AS schon_bei_timo
FROM montagetermin AS t
  INNER JOIN mitarbeiter AS m ON m.mitarbeiter_id = t.mitarbeiter_id
  INNER JOIN anlage      AS a ON a.anlage_id      = t.anlage_id
  LEFT JOIN  montagetermin AS k
         ON  k.datum = t.datum
         AND k.slot  = t.slot
         AND k.mitarbeiter_id = (SELECT mitarbeiter_id FROM mitarbeiter WHERE kuerzel = 'TKA')
WHERE m.kuerzel = 'LBR'
  AND t.datum = '2026-11-10'
ORDER BY t.slot;

Bewertung: Verbund mit mitarbeiter und anlage, Auswahl über das Kürzel und ISO-Datum (2 Punkte), LEFT JOIN auf eine zweite Instanz von montagetermin mit Datum, Slot und Timo als Bedingung im ON (1 Punkt), Spalten und Sortierung (1 Punkt). Steht Timos Bedingung im WHERE statt im ON, fallen die Zeilen ohne Treffer weg – dann fehlen die Slots 3 und 4. Der Termin am 11.11.2026 (W-2026-0154) gehört nicht ins Ergebnis.

MariaDB bricht mit Duplicate entry '2-2026-11-10-1' for key 'uq_einsatz' ab (1 Punkt): Timo ist am 10.11.2026 in Slot 1 schon mit W-2026-0160 eingeplant und kann nicht zwei Termine gleichzeitig haben. Bei InnoDB-Tabellen wird eine einzelne Anweisung ganz oder gar nicht ausgeführt – auch Zeilen, die schon geändert waren, werden zurückgenommen, es sind 0 Termine umgebucht (1 Punkt).

Auch ohne den Konflikt wäre die Anweisung falsch: Ohne Datumsbedingung würde auch Leas Termin am 11.11.2026 (W-2026-0154) an Timo gehen (1 Punkt). Außerdem verlässt sich Jonas auf auswendig gewusste Schlüsselwerte; die Auswahl über das eindeutige Kürzel ist lesbarer und weniger fehleranfällig (1 Punkt).

START TRANSACTION;

UPDATE montagetermin
SET mitarbeiter_id = (SELECT mitarbeiter_id FROM mitarbeiter WHERE kuerzel = 'YDE')
WHERE auftragsnr = 'W-2026-0160';

UPDATE montagetermin
SET mitarbeiter_id = (SELECT mitarbeiter_id FROM mitarbeiter WHERE kuerzel = 'TKA')
WHERE datum = '2026-11-10'
  AND mitarbeiter_id = (SELECT mitarbeiter_id FROM mitarbeiter WHERE kuerzel = 'LBR');

COMMIT;

BEGIN TRANSACTION;

UPDATE montagetermin
SET mitarbeiter_id = (SELECT mitarbeiter_id FROM mitarbeiter WHERE kuerzel = 'YDE')
WHERE auftragsnr = 'W-2026-0160';

UPDATE montagetermin
SET mitarbeiter_id = (SELECT mitarbeiter_id FROM mitarbeiter WHERE kuerzel = 'TKA')
WHERE datum = '2026-11-10'
  AND mitarbeiter_id = (SELECT mitarbeiter_id FROM mitarbeiter WHERE kuerzel = 'LBR');

COMMIT TRANSACTION;

BEGIN;

UPDATE montagetermin
SET mitarbeiter_id = (SELECT mitarbeiter_id FROM mitarbeiter WHERE kuerzel = 'YDE')
WHERE auftragsnr = 'W-2026-0160';

UPDATE montagetermin
SET mitarbeiter_id = (SELECT mitarbeiter_id FROM mitarbeiter WHERE kuerzel = 'TKA')
WHERE datum = DATE '2026-11-10'
  AND mitarbeiter_id = (SELECT mitarbeiter_id FROM mitarbeiter WHERE kuerzel = 'LBR');

COMMIT;

-- Oracle startet die Transaktion mit der ersten Änderung selbst

UPDATE montagetermin
SET mitarbeiter_id = (SELECT mitarbeiter_id FROM mitarbeiter WHERE kuerzel = 'YDE')
WHERE auftragsnr = 'W-2026-0160';

UPDATE montagetermin
SET mitarbeiter_id = (SELECT mitarbeiter_id FROM mitarbeiter WHERE kuerzel = 'TKA')
WHERE datum = DATE '2026-11-10'
  AND mitarbeiter_id = (SELECT mitarbeiter_id FROM mitarbeiter WHERE kuerzel = 'LBR');

COMMIT;

BEGIN TRANSACTION;

UPDATE montagetermin
SET mitarbeiter_id = (SELECT mitarbeiter_id FROM mitarbeiter WHERE kuerzel = 'YDE')
WHERE auftragsnr = 'W-2026-0160';

UPDATE montagetermin
SET mitarbeiter_id = (SELECT mitarbeiter_id FROM mitarbeiter WHERE kuerzel = 'TKA')
WHERE datum = '2026-11-10'
  AND mitarbeiter_id = (SELECT mitarbeiter_id FROM mitarbeiter WHERE kuerzel = 'LBR');

COMMIT;

Bewertung: Transaktion mit Abschluss (1 Punkt), Konflikt zuerst auflösen (1 Punkt), zweites UPDATE mit Datums- und Personenbedingung (2 Punkte), Personen über Unterabfragen auf das Kürzel (1 Punkt). Danach betreut Timo am 10.11.2026 die Slots 1, 3 und 4 (W-2026-0151, W-2026-0152, W-2026-0155), Yusuf die Slots 1 und 3 (W-2026-0160, W-2026-0153); W-2026-0154 am 11.11.2026 bleibt bei Lea. In umgekehrter Reihenfolge scheitert das zweite UPDATE wie in b). Ebenfalls richtig ist, Leas Slot-1-Termin direkt an Yusuf zu geben und nur die übrigen an Timo.

uq_belegung verhindert, dass eine Anlage im selben Zeitfenster zweimal belegt wird: Ein weiterer Termin auf dem Prüfstand E-Antrieb am 10.11.2026 in Slot 1 würde abgelehnt, auch wenn ihn eine andere Person übernehmen soll (1 Punkt). uq_einsatz verhindert, dass eine Person gleichzeitig an zwei Anlagen eingeplant ist – genau das hat in b) die Umbuchung von W-2026-0151 auf Timo blockiert (1 Punkt).

INSERT INTO pruefprotokoll (anlage_id, auftragsnr, akku_temp_c, bestanden)
VALUES (3, 'W-2026-0154', 31.4, FALSE);

Bewertung: Spaltenliste ohne protokoll_id und zeitpunkt – beide setzt die Datenbank (AUTO_INCREMENT, DEFAULT CURRENT_TIMESTAMP) (1 Punkt); Dezimalpunkt statt Komma (1 Punkt); Wahrheitswert FALSE bzw. 0 ohne Hochkommata und Auftragsnummer als Text (1 Punkt). Ebenfalls richtig ist die Anlage über eine Unterabfrage ((SELECT anlage_id FROM anlage WHERE bezeichnung = 'Prüfstand E-Antrieb')).

UPDATE leistungsart
SET stundensatz = ROUND(stundensatz * 1.025, 2);

Bewertung: Faktor 1.025 (1 Punkt), ROUND(…, 2) (1 Punkt), neuer Satz Akku-Diagnose 78,00 € · 1,025 = 79,95 € (1 Punkt). Ein WHERE ist hier nicht nötig, weil ausdrücklich alle Zeilen geändert werden sollen; die übrigen Sätze lauten danach 59,45 €, 69,70 € und 57,40 €.

UPDATE werkstattauftrag
SET zahlstatus = CASE zahlstatus
                   WHEN '1' THEN 'bezahlt'
                   WHEN '0' THEN 'offen'
                 END
WHERE zahlstatus IN ('0', '1');

Bewertung: CASE mit beiden Fällen (2 Punkte), Bedingung, die nur die fehlerhaften Zeilen auswählt (1 Punkt), Werte als Text in Hochkommata (1 Punkt). 4 Zeilen werden geändert (0141 und 0148 auf „bezahlt“, 0147 und 0151 auf „offen“). Ohne WHERE würde CASE bei den übrigen Zeilen keinen Zweig finden und NULL liefern – das scheitert an NOT NULL bzw. löscht den Status. Ebenfalls richtig ist ELSE zahlstatus statt der Bedingung. Zwei einzelne UPDATE-Anweisungen lösen das Problem auch, erfüllen aber nicht die Vorgabe „eine Anweisung“ (1 Punkt Abzug).

Die Bedingung prüft eine Spalte bezahlt, die es nicht gibt – MariaDB meldet „Unknown column ‘bezahlt’ in ‘where clause’“ (1 Punkt). Gemeint ist die fehlerhafte Spalte selbst: WHERE zahlstatus = '1'. Außerdem bleibt der Fall '0' → „offen“ unbearbeitet (1 Punkt).

Das DELETE wird abgelehnt (MariaDB-Fehler 1451 „Cannot delete or update a parent row: a foreign key constraint fails“) (1 Punkt). Die Arbeitsposition 2 des Auftrags W-2026-0141 verweist über fk_ap_leistung auf die Leistungsart 3 (1 Punkt). Für diesen Fremdschlüssel ist keine ON DELETE-Regel angegeben, also gilt RESTRICT: Ein Elterndatensatz mit abhängigen Datensätzen darf nicht gelöscht werden, sonst ginge die referentielle Integrität verloren (1 Punkt).

Mit Löschweitergabe würden beim Löschen der Leistungsart auch alle Arbeitspositionen gelöscht, die sie verwenden – hier die Position des abgeschlossenen Auftrags W-2026-0141. Damit fehlen abgerechnete Leistungen in Aufträgen und Rechnungen, die aufbewahrt werden müssen (2 Punkte). CASCADE passt nur für Teile, die ohne ihr Ganzes keinen Sinn haben (wie fk_ap_auftrag: Positionen eines gelöschten Auftrags). Besser ist es, die Leistungsart nur zu deaktivieren (2 Punkte):

UPDATE leistungsart
SET aktiv = FALSE
WHERE leistungsart_id = 3;

Die Werkstattsoftware bietet dann nur noch aktive Leistungsarten an; alte Aufträge bleiben vollständig. Die Bedingung über die eindeutige Bezeichnung ist ebenfalls richtig.