Übungsaufgaben zu INSERT, UPDATE und DELETE

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

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.

UPDATE artikel
SET gewicht_kg = 1.00
WHERE gewicht_kg IS NULL;

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

Betroffen ist nur Artikel 11 (Kette). Reihenfolge: Solange noch ein NULL in der Spalte steht, lehnt MariaDB die Änderung auf NOT NULL im Strict Mode (Voreinstellung) mit einem Fehler ab; ohne Strict Mode würde der Wert mit einer Warnung in 0.00 umgewandelt. Deshalb erst die Lücken füllen, dann die Struktur ändern.

Bewertung: UPDATE mit IS NULL 1 P (= NULL trifft keine Zeile: 0 P), ALTER TABLE … MODIFY … NOT NULL mit Datentyp 2 P, Begründung 1 P. CHANGE gewicht_kg gewicht_kg DECIMAL(6,2) NOT NULL ist ebenso richtig.

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');

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

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;

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;

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)

ALTER TABLE altdaten_import
ADD COLUMN nachname VARCHAR(50),
ADD COLUMN vorname  VARCHAR(50);

UPDATE altdaten_import
SET nachname = TRIM(SUBSTRING_INDEX(name, ',', 1)),
    vorname  = TRIM(SUBSTRING_INDEX(name, ',', -1));

ALTER TABLE altdaten_import
DROP COLUMN name;

Ergebnis (Auszug):

Bewertung: ALTER TABLE … ADD 1 P, SUBSTRING_INDEX mit 1 und -1 2 P, TRIM für das Leerzeichen nach dem Komma 1 P, DROP COLUMN erst nach dem UPDATE 1 P. Vor dem DROP COLUMN lohnt eine Kontrolle mit SELECT name, nachname, vorname FROM altdaten_import; – das Entfernen der Spalte lässt sich nicht zurücknehmen.

gb)

UPDATE altdaten_import
SET geburtsdatum = '2002-03-08'
WHERE nachname = 'Haddad'
  AND vorname  = '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;

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 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';

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 = 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);

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.datum, t.slot, t.auftragsnr
FROM montagetermin AS t
  INNER JOIN anlage AS a ON a.anlage_id = t.anlage_id
WHERE a.bezeichnung = 'Prüfstand E-Antrieb'
  AND t.datum = '2026-11-05'
ORDER BY t.slot;

Bewertung: Verbund mit anlage (1 Punkt), beide Bedingungen mit ISO-Datum (1 Punkt), Spalten und Sortierung (1 Punkt). Diese Abfrage ist zugleich die Kontrolle vor dem UPDATE in b): Sie zeigt, welche Zeilen sich ändern werden.

UPDATE montagetermin
SET datum = datum + INTERVAL 7 DAY   -- oder DATE_ADD(datum, INTERVAL 7 DAY)
WHERE datum = '2026-11-05'
  AND anlage_id = (SELECT anlage_id
                   FROM anlage
                   WHERE bezeichnung = 'Prüfstand E-Antrieb');

UPDATE montagetermin
SET datum = DATEADD(DAY, 7, datum)
WHERE datum = '2026-11-05'
  AND anlage_id = (SELECT anlage_id
                   FROM anlage
                   WHERE bezeichnung = 'Prüfstand E-Antrieb');

UPDATE montagetermin
SET datum = datum + 7                -- date + integer = Tage
WHERE datum = DATE '2026-11-05'
  AND anlage_id = (SELECT anlage_id
                   FROM anlage
                   WHERE bezeichnung = 'Prüfstand E-Antrieb');

UPDATE montagetermin
SET datum = datum + 7                -- DATE + Zahl = Tage
WHERE datum = DATE '2026-11-05'
  AND anlage_id = (SELECT anlage_id
                   FROM anlage
                   WHERE bezeichnung = 'Prüfstand E-Antrieb');

Bewertung: UPDATE montagetermin SET datum = … (1 Punkt), Datumsrechnung um sieben Tage mit einer Datumsfunktion bzw. INTERVAL (2 Punkte), Bedingung auf das Datum (1 Punkt), Anlage über eine Unterabfrage auf die Bezeichnung (1 Punkt). Statt der Unterabfrage ist in MariaDB auch UPDATE montagetermin AS t INNER JOIN anlage AS a ON … SET t.datum = … richtig.

Ursache (1 Punkt): Die Kombination aus Anlage, Datum und Slot ist eindeutig (uq_belegung). Am 12.11.2026 ist Slot 2 des Prüfstands schon mit Auftrag W-2026-0160 belegt; der verschobene Termin W-2026-0152 würde denselben Slot belegen.

Wirkung (1 Punkt): Bei InnoDB-Tabellen wird eine einzelne Anweisung ganz oder gar nicht ausgeführt. Auch der bereits verschobene Termin aus Slot 1 wird zurückgenommen – es sind 0 Termine verschoben.

Lösungsweg (2 Punkte): Zuerst den Konflikt auflösen, dann verschieben, z. B. den Termin W-2026-0160 auf den freien Slot 3 legen (nach Rücksprache mit Bastian Ludwig) und danach das UPDATE aus b) erneut ausführen. Beide Anweisungen gehören in eine Transaktion, damit nie ein halber Stand entsteht:

START TRANSACTION;

UPDATE montagetermin
SET slot = 3
WHERE auftragsnr = 'W-2026-0160';

UPDATE montagetermin
SET datum = datum + INTERVAL 7 DAY
WHERE datum = '2026-11-05'
  AND anlage_id = (SELECT anlage_id
                   FROM anlage
                   WHERE bezeichnung = 'Prüfstand E-Antrieb');

COMMIT;

Danach liegen am 12.11.2026 auf dem Prüfstand die Slots 1 (W-2026-0151), 2 (W-2026-0152), 3 (W-2026-0160) und 4 (W-2026-0155). Andere sinnvolle Wege (betroffenen Termin auf einen anderen Tag legen, Konflikt vorher mit einer Abfrage suchen) sind ebenfalls richtig.

MariaDB rechnet bei datum + 7 nicht mit Tagen, sondern wandelt das Datum in die Zahl 20261105 um und addiert 7 (1 Punkt). Das Ergebnis 20261112 lässt sich zufällig wieder als gültiges Datum 2026-11-12 lesen (1 Punkt). Geht die Rechnung über ein Monatsende, entsteht kein gültiges Datum: Aus dem 28.11.2026 würde 20261135. MariaDB lehnt das im Strict Mode mit „Incorrect date value“ ab, ohne Strict Mode wird 0000-00-00 gespeichert (1 Punkt). Richtig ist datum + INTERVAL 7 DAY oder DATE_ADD(datum, INTERVAL 7 DAY). In Oracle und PostgreSQL bedeutet datum + 7 dagegen tatsächlich „sieben Tage später“ – ein Grund, die Schreibweise des eingesetzten DBMS zu kennen.

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.