Zum Inhalt springen

Datenbanken und betriebliche Datenmodelle – Datenänderungen kontrolliert durchführen

Aus MOOCsWiki Staging
aiMOOC-Siegel aiMOOC

Datenbanken und betriebliche Datenmodelle – Datenänderungen kontrolliert durchführen

QR-Code



Einleitung

Datenbanken und betriebliche Datenmodelle – Datenänderungen kontrolliert durchführen

Zielgruppe: Auszubildende in IT-Berufen, insbesondere Fachinformatikerinnen und Fachinformatiker.

Dauer: ca. 60–75 Minuten in sechs kurzen Lerneinheiten.

Ausbildungsfall: Eine Lagerumbuchung in einem fiktiven Unternehmen.

Deine Lernziele: Du kannst ein betriebliches Datenmodell verstehen, Transaktionen sicher durchführen, Fehler zurücksetzen, Datenbankzustände prüfen und das ACID-Prinzip anwenden.

Technik: Python 3 und SQLite aus der Python-Standardbibliothek. Die praktischen Übungen funktionieren lokal und ohne Internetverbindung.

Sicherheitsregel: Nutze ausschließlich selbst erstellte lokale Testdatenbanken oder ausdrücklich autorisierte Übungsumgebungen. Verwende keine Produktivsysteme, echten Kunden- oder Zugangsdaten und keine fremden Netzwerke. Übertrage keine betrieblichen Daten an externe Dienste.


Ausbildungsfall: Sichere Lagerumbuchung

Du arbeitest bei der fiktiven Firma Nordlicht IT-Zubehör. Drei USB-C-Kabel sollen von Lagerplatz A nach Lagerplatz B umgebucht werden.


Die Ausgangslage

Lagerplatz Vorher Nach erfolgreicher Umbuchung
A 12 9
B 4 7
Gesamt 16 16

Die entscheidende Geschäftsregel: Die Gesamtmenge bleibt bei einer reinen Lagerumbuchung gleich. Kein Lagerbestand darf negativ werden.

VORHER                 TRANSAKTION                NACHHER

Lager A  ████████████ 12  ── 3 entnehmen ──►      █████████ 9
Lager B  ████          4   ── 3 hinzufügen ─►     ███████   7

Gesamt: 16                                        Gesamt: 16

FEHLER?
       └── ROLLBACK ──► Ausgangszustand wiederherstellen

Leitfrage: Was passiert, wenn die drei Kabel von Lager A abgezogen werden, die Buchung nach Lager B aber fehlschlägt?

Antwort: Beide Änderungen müssen Bestandteil einer einzigen Transaktion sein. Andernfalls könnte ein falscher Bestand entstehen.


Lerneinheit 1: Das betriebliche Datenmodell verstehen

Zeitbedarf: 7 Minuten

Medienimpuls: Erkenne Entitäten und ihre Beziehungen in einem Entity-Relationship-Modell.

Ein ER-Modell beschreibt, welche betrieblichen Objekte gespeichert werden und wie sie zusammenhängen.

Unser vereinfachtes Lagermodell besteht aus drei Tabellen.

Tabelle Attribute Zweck
Artikel id, name Beschreibt den Artikel
Lagerort code Beschreibt einen Lagerplatz
Bestand artikel_id, ort, menge Verknüpft Artikel, Lagerort und Menge
     ARTIKEL                      LAGERORT
   ┌──────────┐                 ┌──────────┐
   │ id  (PK) │                 │ code (PK)│
   │ name     │                 └────┬─────┘
   └────┬─────┘                      │
        │                            │
        └──────────┬─────────────────┘
                   ▼
             ┌─────────────┐
             │   BESTAND   │
             ├─────────────┤
             │ artikel_id  │
             │ ort         │
             │ menge       │
             └─────────────┘

   Primärschlüssel Bestand: (artikel_id, ort)
   Fremdschlüssel: artikel_id und ort

Primärschlüssel: Identifiziert einen Datensatz eindeutig. In der Tabelle Bestand besteht er aus zwei Spalten.

Fremdschlüssel: Verweist auf einen existierenden Artikel oder Lagerort.

Integritätsbedingung: `CHECK (menge >= 0)` verhindert negative Bestände bei normalen Schreiboperationen.

Basisaufgabe: Warum ist die Kombination aus Artikel und Lagerort als Schlüssel geeignet?

Feedback: Derselbe Artikel darf in mehreren Lagerorten vorkommen. Die Kombination identifiziert genau einen Bestandssatz pro Artikel und Ort.


Lerneinheit 2: ACID – vier Regeln für sichere Transaktionen

Zeitbedarf: 7 Minuten

ACID-Eigenschaft Bedeutung Lagerbeispiel
Atomicity – Atomarität Alles oder nichts Abbuchung und Zubuchung werden gemeinsam bestätigt oder verworfen
Consistency – Konsistenz Gültige Zustände bleiben erhalten Keine negativen Bestände; die Umbuchung erhält die Gesamtmenge
Isolation – Isolation Gleichzeitig ablaufende Transaktionen beeinflussen sich nur gemäß den geltenden Isolationsregeln Eine zweite Verbindung sieht keine unfertige Umbuchung
Durability – Dauerhaftigkeit Bestätigte Änderungen bleiben im dauerhaft gespeicherten Datenbestand erhalten Nach erfolgreichem COMMIT bleiben die Lagerdaten auch nach einem Neustart bestehen

Wichtig: Konsistenz entsteht nicht automatisch allein durch COMMIT. Datenbankregeln und Anwendungslogik müssen die betrieblichen Anforderungen prüfen.

Eine SQLite-Datenbank mit `:memory:` eignet sich hervorragend für sichere Übungen, aber nicht für den Nachweis der Dauerhaftigkeit über das Schließen der Verbindung hinaus.

Vertiefung: „ACID Properties in Databases With Examples“ von ByteByteGo. Englischsprachiges Erklärvideo.

Basisaufgabe: Ordne den vier ACID-Eigenschaften jeweils ein Risiko aus dem Lagerfall zu.

Begründetes Feedback: Eine fehlende Abbuchung oder Zubuchung gefährdet die Atomarität. Negative Bestände verletzen eine Konsistenzregel. Unkontrollierte parallele Zugriffe betreffen die Isolation. Verlorene bestätigte Änderungen betreffen die Dauerhaftigkeit.


Lerneinheit 3: BEGIN, COMMIT und ROLLBACK

Zeitbedarf: 6 Minuten

               BEGIN
                 │
                 ▼
         Quellbestand prüfen
                 │
                 ▼
         Bestand A verringern
                 │
                 ▼
          Zielort prüfen
                 │
                 ▼
          Bestand B erhöhen
                 │
          ┌──────┴───────┐
          │              │
       Erfolg          Fehler
          │              │
          ▼              ▼
        COMMIT        ROLLBACK
          │              │
          ▼              ▼
       Neuer         Alter
       Zustand       Zustand
SQL-Befehl Funktion
BEGIN Beginnt eine explizite Transaktion
UPDATE Verändert passende Datensätze
COMMIT Bestätigt die Transaktion
ROLLBACK Verwirft Änderungen der laufenden Transaktion
SAVEPOINT Definiert einen Rücksetzpunkt innerhalb einer Transaktion

Praxisfalle: Ein `UPDATE` kann erfolgreich ausgeführt werden, obwohl keine Zeile geändert wurde. Deshalb kontrollieren wir im folgenden Programm ausdrücklich `rowcount`.

Anwendungsfrage: Was wäre falsch daran, nach der Abbuchung sofort COMMIT auszuführen und erst danach die Zubuchung zu versuchen?

Feedback: Die erste Änderung wäre bereits bestätigt. Scheitert danach die Zubuchung, kann ein gewöhnliches ROLLBACK die erste bestätigte Transaktion nicht mehr zurücknehmen.

Vertiefung: „SQL Server Datenbank Transaktionen Einführung“. Das Video demonstriert Transaktionsbefehle an SQL Server; unsere Praxisumgebung verwendet dagegen SQLite.


Lerneinheit 4: Interaktives SQLite-Labor

Zeitbedarf: 15 Minuten

Labor A: Sichere Lagerumbuchung

Dieses Labor nutzt ausschließlich eine lokale Datenbank im Arbeitsspeicher. Es benötigt keinen Datenbankserver, keine Zugangsdaten und keine Netzwerkverbindung.

Anleitung: Speichere den folgenden Python-Code als `lager_labor.py` und starte ihn in einem lokalen Terminal mit `python lager_labor.py` oder `python3 lager_labor.py`.

import sqlite3

# Isolierte Datenbank nur im Arbeitsspeicher
db = sqlite3.connect(":memory:", isolation_level=None)
db.execute("PRAGMA foreign_keys = ON")

db.executescript("""
CREATE TABLE artikel (
    id INTEGER PRIMARY KEY,
    name TEXT NOT NULL
);

CREATE TABLE lagerort (
    code TEXT PRIMARY KEY
);

CREATE TABLE bestand (
    artikel_id INTEGER NOT NULL REFERENCES artikel(id),
    ort TEXT NOT NULL REFERENCES lagerort(code),
    menge INTEGER NOT NULL CHECK (menge >= 0),
    PRIMARY KEY (artikel_id, ort)
);

INSERT INTO artikel VALUES (1, 'USB-C-Kabel');
INSERT INTO lagerort VALUES ('A'), ('B');
INSERT INTO bestand VALUES (1, 'A', 12), (1, 'B', 4);
""")

def stand():
    return dict(
        db.execute("SELECT ort, menge FROM bestand ORDER BY ort")
    )

def umbuchung(anzahl, ziel):
    try:
        db.execute("BEGIN")

        if anzahl <= 0:
            raise ValueError("Menge muss positiv sein")

        if ziel == "A":
            raise ValueError("Quelle und Ziel sind identisch")

        minus = db.execute(
            "UPDATE bestand SET menge = menge - ? "
            "WHERE artikel_id = 1 AND ort = 'A' AND menge >= ?",
            (anzahl, anzahl)
        )

        if minus.rowcount != 1:
            raise ValueError("Quellbestand reicht nicht")

        plus = db.execute(
            "UPDATE bestand SET menge = menge + ? "
            "WHERE artikel_id = 1 AND ort = ?",
            (anzahl, ziel)
        )

        if plus.rowcount != 1:
            raise ValueError("Zielort unbekannt")

        db.execute("COMMIT")
        return True

    except (ValueError, sqlite3.Error) as fehler:
        if db.in_transaction:
            db.execute("ROLLBACK")
        print("ROLLBACK:", fehler)
        return False

print("Start:", stand())
assert stand() == {"A": 12, "B": 4}

assert umbuchung(3, "B")
assert stand() == {"A": 9, "B": 7}
print("Nach COMMIT:", stand())

assert not umbuchung(99, "B")
assert stand() == {"A": 9, "B": 7}

assert not umbuchung(2, "X")
assert stand() == {"A": 9, "B": 7}

assert not umbuchung(0, "B")
assert stand() == {"A": 9, "B": 7}

assert not umbuchung(1, "A")
assert stand() == {"A": 9, "B": 7}

print("Alle lokalen Prüfungen bestanden.")
print("Gesamtbestand:", sum(stand().values()))

while True:
    eingabe = input("Menge und Ziel eingeben, z. B. 2 B, oder ende: ")
    if eingabe.lower() == "ende":
        break

    teile = eingabe.split()
    if len(teile) != 2:
        print("Eingabeformat: Menge Ziel")
        continue

    try:
        anzahl = int(teile[0])
    except ValueError:
        print("Bitte eine ganze Zahl eingeben")
        continue

    umbuchung(anzahl, teile[1])
    print("Aktueller Stand:", stand())

db.close()


Visualisierte Testfälle

Eingabe Ergebnis Lager A Lager B Gesamt
Start Ausgangslage 12 4 16
3 B COMMIT 9 7 16
99 B ROLLBACK 9 7 16
2 X ROLLBACK 9 7 16
0 B ROLLBACK 9 7 16
1 A ROLLBACK 9 7 16

Interaktiver Versuch: Gib nacheinander `2 B`, `20 B`, `2 X` und `ende` ein.

Erwartung: Nach `2 B` beträgt der Bestand A = 7 und B = 9. Die beiden folgenden fehlerhaften Umbuchungen lassen diesen Zustand unverändert.

Feedback: Du kannst eine sichere Implementierung daran erkennen, dass auch nach einem Fehler keine teilweise ausgeführte Umbuchung zurückbleibt. Die Fehlermeldung allein wäre noch kein ausreichender Nachweis.


Gestufte Hilfen für Labor A

Stufe Hilfe
Hilfe 1 – Denke nach Was muss nach jeder abgeschlossenen Lagerumbuchung für die Summe der beiden Bestände gelten?
Hilfe 2 – Finde die Prüfstelle Untersuche die beiden UPDATE-Befehle und die Prüfungen auf rowcount.
Hilfe 3 – Lösungsweg Bei einem Fehler wird eine Ausnahme ausgelöst. ROLLBACK stellt alle Änderungen seit BEGIN zurück. Erst nach zwei erfolgreich geprüften UPDATE-Befehlen folgt COMMIT.


Lerneinheit 5: Isolation mit zwei Verbindungen untersuchen

Zeitbedarf: 10 Minuten

Labor B: Was sieht eine zweite Datenbankverbindung?

Für diesen Versuch benötigen beide Verbindungen dieselbe lokale Datenbankdatei. Sie liegt ausschließlich in einem automatisch wieder entfernten temporären Verzeichnis.

Speichere den Code als `isolation_labor.py`.

import sqlite3
from pathlib import Path
from tempfile import TemporaryDirectory

with TemporaryDirectory() as ordner:
    pfad = str(Path(ordner) / "sichtbarkeit.db")

    a = sqlite3.connect(pfad, isolation_level=None)
    b = sqlite3.connect(pfad, isolation_level=None)

    a.execute("CREATE TABLE probe (bestand INTEGER)")
    a.execute("INSERT INTO probe VALUES (16)")

    a.execute("BEGIN IMMEDIATE")
    a.execute("UPDATE probe SET bestand = 13")

    vor_a = a.execute(
        "SELECT bestand FROM probe"
    ).fetchone()[0]

    vor_b = b.execute(
        "SELECT bestand FROM probe"
    ).fetchone()[0]

    print("Verbindung A vor COMMIT:", vor_a)
    print("Verbindung B vor COMMIT:", vor_b)

    assert vor_a == 13
    assert vor_b == 16

    a.execute("COMMIT")

    nach_b = b.execute(
        "SELECT bestand FROM probe"
    ).fetchone()[0]

    print("Verbindung B nach COMMIT:", nach_b)
    assert nach_b == 13

    a.close()
    b.close()

print("Isolationstest erfolgreich.")

Beobachtung:

Zeitpunkt Verbindung A Verbindung B
Vor COMMIT 13 16
Nach COMMIT 13 13
VERBINDUNG A                       VERBINDUNG B

BEGIN IMMEDIATE
UPDATE 16 -> 13
                                   SELECT -> 16
COMMIT
                                   SELECT -> 13

Erklärung: Die zweite Verbindung sieht die noch nicht bestätigte Änderung nicht. Im gezeigten SQLite-Test gilt die normale Trennung zwischen zwei Datenbankverbindungen ohne freigegebenen Cache.

Wichtig: Eine Datei in einem temporären Verzeichnis eignet sich hier zum Isolationstest, aber der Test beweist keine langfristige Speicherung. Für eine Dauerhaftigkeitsprüfung müsste eine persistente lokale Testdatei nach dem Schließen und erneuten Öffnen kontrolliert werden. Eine solche Prüfung darf ebenfalls nur mit eigenen Testdaten erfolgen.


Lerneinheit 6: Datenfehler analysieren und vermeiden

Zeitbedarf: 8 Minuten

Medienimpuls: Eine Änderungsanomalie zeigt, weshalb ein gutes Datenmodell und kontrollierte Updates zusammengehören.

Ein Änderungsfehler kann auch dann entstehen, wenn eine SQL-Anweisung syntaktisch richtig ist.

Problem Gegenmaßnahme
Bestandsabzug ohne Zubuchung Gemeinsame Transaktion
Negativer Bestand CHECK-Regel und Bestandsprüfung
Unbekannter Lagerort Fremdschlüssel und Zielprüfung
UPDATE betrifft keine Zeile rowcount kontrollieren
Unfertige parallele Änderung Geeignete Isolation
SQL aus ungeprüften Eingaben Parametrisierte Abfragen

Transferfrage: Kann eine Datenbanktransaktion allein garantieren, dass eine Lagerumbuchung fachlich richtig ist?

Feedback: Nein. Eine technisch erfolgreiche Transaktion kann fachlich falsche Werte enthalten. Deshalb müssen Prozessregeln wie Artikelidentität, positive Mengen, vorhandene Zielorte und zulässige Bestandsveränderungen geprüft werden.


Interaktive Aufgaben


Quiz: Teste Dein Wissen

Basisniveau

Welcher Befehl startet in SQLite eine explizite Transaktion? (BEGIN) (!COMMIT) (!ROLLBACK) (!SELECT)




Was bewirkt COMMIT? (Die Änderungen einer Transaktion bestätigen) (!Die gesamte Datenbank löschen) (!Alle Tabellen zurücksetzen) (!Einen Fremdschlüssel erstellen)




Was bewirkt ROLLBACK? (Die Änderungen der laufenden Transaktion zurücknehmen) (!Alle Daten dauerhaft archivieren) (!Einen neuen Lagerort erstellen) (!Den Primärschlüssel ändern)




Was bedeutet Atomarität? (Alle zusammengehörenden Änderungen oder keine) (!Jede Tabellenzeile hat denselben Wert) (!Jede Änderung wird einzeln bestätigt) (!Alle Datenbanken nutzen dieselbe Programmiersprache)




Anwendungsniveau

Welche Maßnahme hilft gegen negative Lagerbestände? (Eine CHECK Bedingung) (!Eine zusätzliche SELECT Spalte) (!Das Löschen des Primärschlüssels) (!Das Abschalten aller Prüfungen)




Warum prüft das Python-Programm rowcount? (Weil ein UPDATE keine passende Zeile treffen kann) (!Weil SELECT keine Tabellen lesen darf) (!Weil SQLite keine Transaktionen kennt) (!Weil jeder Datensatz zweimal geändert werden muss)




Was geschieht bei einem unbekannten Zielort im Lagerlabor? (Die Umbuchung wird vollständig zurückgenommen) (!Die Menge wird automatisch gelöscht) (!Die Menge wird einem beliebigen Ort zugeordnet) (!Die Transaktion wird trotzdem bestätigt)




Wozu dient der zusammengesetzte Primärschlüssel der Bestandstabelle? (Zur eindeutigen Zuordnung eines Artikels zu einem Lagerort) (!Zur automatischen Verdoppelung des Bestands) (!Zur Speicherung aller Transaktionsprotokolle) (!Zur Deaktivierung der Fremdschlüssel)




Transferniveau

Was sieht Verbindung B im Isolationstest vor COMMIT? (Den zuvor bestätigten Wert) (!Immer den unbestätigten neuen Wert) (!Überhaupt keine vorhandenen Tabellen) (!Automatisch einen negativen Bestand)




Warum beweist das erste Labor keine dauerhafte Speicherung? (Weil seine Datenbank nur im Arbeitsspeicher existiert) (!Weil SQLite keine COMMIT Befehle unterstützt) (!Weil Fremdschlüssel jede Speicherung verhindern) (!Weil Python keine Dateien lesen kann)





Begründetes Quiz-Feedback

Frage Rückmeldung
1–2 BEGIN eröffnet den Transaktionsblock; COMMIT bestätigt ihn. Die Reihenfolge entscheidet über die Wirksamkeit der Änderungen.
3–4 ROLLBACK stellt den vorherigen Zustand wieder her. Damit wird die Alles-oder-nichts-Eigenschaft praktisch genutzt.
5–6 Integritätsbedingungen verhindern ungültige Werte. rowcount deckt zusätzlich nicht ausgeführte Bestandsänderungen auf.
7–8 Fachliche Prüfungen und passende Schlüssel verhindern unvollständige oder mehrdeutige Buchungen.
9–10 Isolation schützt vor unbestätigten Änderungen anderer Verbindungen. Dauerhaftigkeit erfordert einen dauerhaft gespeicherten Datenbestand.


Memory

Finde die passenden Begriffspaare.

Atomarität Alles oder nichts
Konsistenz Gültige Zustandsregeln
Isolation Unfertige Änderungen bleiben verborgen
Dauerhaftigkeit Bestätigte Speicherung bleibt erhalten
COMMIT Änderungen bestätigen
ROLLBACK Änderungen zurücknehmen
Fremdschlüssel Beziehung zwischen Datensätzen
Primärschlüssel Eindeutige Kennzeichnung





Drag and Drop

Ordne die Datenbankbefehle und Schutzmaßnahmen ihren Funktionen zu.

Ordne die richtigen Begriffe zu. Funktion
BEGIN Transaktion starten
COMMIT Änderungen bestätigen
ROLLBACK Unbestätigte Änderungen zurücknehmen
CHECK Ungültige Werte verhindern
Fremdschlüssel Beziehungen zu existierenden Datensätzen prüfen





Kreuzworträtsel

Atomaritaet Wie heißt die ACID-Eigenschaft nach dem Alles-oder-nichts-Prinzip?
Rollback Welcher SQL-Befehl verwirft unbestätigte Transaktionsänderungen?
Commit Welcher Befehl bestätigt eine Transaktion?
Isolation Welche ACID-Eigenschaft regelt die Trennung gleichzeitiger Transaktionen?
Konsistenz Wie heißt die Eigenschaft, bei der gültige Zustandsregeln erhalten bleiben?
Fremdschluessel Welcher Schlüssel verweist auf Datensätze einer anderen Tabelle?





LearningApps

Suche ergänzende Lernspiele zu betrieblichen Datenmodellen und kontrollierten Datenänderungen. Dies ist eine thematische Suche und kein als geprüft gekennzeichnetes Einzelspiel.


Lückentext

Vervollständige den Text.
Eine logisch zusammengehörende Folge von Datenbankänderungen bezeichnet man als

.
Das ACID-Prinzip beginnt mit der Eigenschaft

.
Eine Transaktion soll gültige Zustandsregeln erhalten und damit die

sichern.
Die Trennung gleichzeitig ablaufender Transaktionen heißt

.
Die Beständigkeit bestätigter Änderungen bezeichnet man als

.
In SQLite beginnt eine explizite Transaktion mit

.
Erfolgreiche Änderungen werden mit

bestätigt.
Unbestätigte Änderungen können mit

zurückgenommen werden.
Ein Datensatz wird eindeutig durch einen

identifiziert.
Eine Beziehung zu einem anderen Tabellendatensatz wird durch einen

beschrieben.
Negative Mengen können durch eine

Bedingung verhindert werden.
In Python wird die Anzahl betroffener Zeilen mit

kontrolliert.
Eine nur im Arbeitsspeicher gespeicherte Datenbank wird als

bezeichnet.
In unserem Lagerfall muss die Gesamtmenge nach einer erfolgreichen reinen Umbuchung

bleiben.




Offene Aufgaben

Bearbeite die Aufgaben ausschließlich mit fiktiven Daten. Dokumentiere bei Programmieraufgaben Ausgangszustand, Eingabe, Ergebnis und Begründung.


Leicht – Basisaufgaben

  1. Datenmodell: Zeichne ein kleines ER-Modell mit den Tabellen Artikel, Lagerort und Bestand. Markiere Primär- und Fremdschlüssel.
  2. Datenbanktransaktion: Erstelle ein Flussdiagramm für die Umbuchung von drei USB-C-Kabeln zwischen zwei Lagerplätzen.
  3. ACID: Gestalte vier Lernkarten, auf denen Du die ACID-Eigenschaften jeweils anhand eines Lagerbeispiels erklärst.
  4. Datenintegrität: Vergleiche zwei fiktive Bestandstabellen. Kennzeichne negative Bestände, fehlende Lagerorte und widersprüchliche Buchungen.


Standard – Anwendungsaufgaben

  1. SQLite: Starte das lokale Lagerlabor. Teste mindestens fünf unterschiedliche Umbuchungen und dokumentiere die Ergebnisse in einer Tabelle.
  2. ROLLBACK: Ergänze einen weiteren absichtlich ungültigen Testfall. Weise nach, dass der Bestand nach dem Abbruch unverändert bleibt.
  3. SQL: Erweitere die lokale Übungsdatenbank um einen dritten Lagerort C. Passe die Testdaten an und überprüfe eine Umbuchung nach C.
  4. Isolation: Führe das zweite Labor aus. Erstelle eine Bildschirmaufnahme oder ein Erklärvideo, in dem Du die Sichtbarkeit vor und nach COMMIT erläuterst.


Schwer – Transferaufgaben

  1. Transaktionsverarbeitung: Entwickle eine Erweiterung für mehrere Artikel. Beschreibe, wie Du verhinderst, dass eine Umbuchung versehentlich den falschen Artikel verändert.
  2. Datenbankanomalie: Untersuche ein Szenario mit zwei gleichzeitig arbeitenden Lagerbeschäftigten. Entwirf einen sicheren Ablauf und begründe die erforderlichen Prüfungen.
  3. Datenkonsistenz: Gestalte ein fiktives Bestellsystem mit Bestellung, Bestellposition und Lagerbestand. Lege fest, welche Datenänderungen in einer gemeinsamen Transaktion ausgeführt werden müssen.
  4. Verteilte Datenbank: Vergleiche eine lokale Lagerumbuchung mit einer Buchung zwischen zwei unabhängigen Datenbanksystemen. Erläutere, weshalb eine einzelne lokale Transaktion dafür nicht ausreicht, und skizziere ein geeignetes Abstimmungs- oder Ausgleichsverfahren.


Gestufte Hilfen für die offenen Aufgaben

Niveau Erste Hilfe Zweite Hilfe Weiterführende Unterstützung
Basis Identifiziere Objekte und Regeln. Zeichne Tabellen und Beziehungen. Vergleiche Dein Modell mit dem Beispielschema.
Anwendung Beginne mit einem funktionierenden Testfall. Variiere jeweils nur eine Eingabe. Prüfe COMMIT, ROLLBACK und den Gesamtbestand.
Transfer Formuliere die Geschäftsregel zuerst. Suche mögliche Zwischen- und Fehlerzustände. Entwickle anschließend Transaktionen und Nachweistests.


Begründetes Feedback zu den Aufgaben

Basis: Deine Lösung ist tragfähig, wenn Tabellen, Beziehungen und Schutzregeln nachvollziehbar dargestellt sind. Das ist wichtig, weil Transaktionskontrolle auf einem verständlichen Datenmodell aufbaut.

Anwendung: Deine Lösung ist erfolgreich, wenn gültige Buchungen bestätigt und ungültige Buchungen vollständig zurückgenommen werden. Dokumentierte Vorher-nachher-Werte sind aussagekräftiger als eine bloße Erfolgsmeldung.

Transfer: Deine Lösung ist überzeugend, wenn Du auch parallele Zugriffe, zusätzliche Fachregeln und Fehler außerhalb einer einzelnen Datenbank berücksichtigst. Begründe dabei ausdrücklich die Grenzen Deiner gewählten Technik.




Text bearbeiten Bild einfügen Video einbetten Interaktive Aufgaben erstellen



Lernkontrolle

Bearbeite mindestens fünf der folgenden Aufgaben schriftlich oder mit lokal erstellten Tests. Im Mittelpunkt stehen Zusammenhänge und Entscheidungen, nicht auswendig gelernte Definitionen.

  1. Atomarität: Ein Programm führt einen Bestandsabzug aus und bestätigt ihn sofort. Die anschließende Zubuchung schlägt fehl. Analysiere den entstandenen Fehlerzustand und entwickle eine verbesserte Transaktionsgrenze.
  2. Konsistenz: Eine Datenbank verhindert negative Mengen, erlaubt aber eine Umbuchung auf den falschen Artikel. Erkläre, warum eine einzelne CHECK-Regel fachliche Konsistenz nicht vollständig gewährleisten kann.
  3. Isolation: Zwei Mitarbeitende wollen gleichzeitig einen knappen Lagerbestand umbuchen. Untersuche mögliche Konflikte und zeige, wie die Anwendung ungültige Buchungen verhindert.
  4. Datenbankmodellierung: Eine Lagerverwaltung speichert Bestandsmengen und Artikelbezeichnungen mehrfach. Analysiere mögliche Änderungsanomalien und entwickle eine passendere Tabellenstruktur.
  5. Fehlerbehandlung: Entwirf für eine Bestandsumbuchung drei verschiedene Fehlerfälle und lege fest, was die Anwendung vor einem möglichen COMMIT überprüfen muss.
  6. Dauerhaftigkeit: Vergleiche die Datenbank im Arbeitsspeicher mit einer dauerhaft gespeicherten lokalen Datenbankdatei. Entwickle einen Testplan zur Kontrolle der Speicherung nach dem erneuten Öffnen.
  7. Softwaretest: Erstelle eine Testmatrix für gültige und ungültige Umbuchungen. Begründe, weshalb neben Erfolgsfällen auch Abbruchfälle getestet werden müssen.

Bewertungskriterien: Fachliche Richtigkeit, konsistente Zustände, nachweisbare Tests, verständliche Fehleranalyse und begründete Entscheidungen.


Lernnachweis

Ein vollständiger Lernnachweis umfasst folgende Bestandteile:

  1. Ein korrektes Modell mit Artikel, Lagerort und Bestand einschließlich der wichtigsten Schlüssel.
  2. Eine nachvollziehbare Erklärung des ACID-Prinzips anhand des Ausbildungsfalls.
  3. Ein lokal ausführbares Programm für eine sichere Lagerumbuchung.
  4. Nachweise über mindestens eine erfolgreiche und drei absichtlich fehlgeschlagene Umbuchungen.
  5. Eine Dokumentation, die zeigt, dass ROLLBACK keine teilweise ausgeführte Buchung hinterlässt.
  6. Eine begründete Auswertung des Isolationstests mit zwei Verbindungen.
  7. Eine eigenständige Transferlösung, die auch mögliche Grenzen der lokalen Transaktionskontrolle beschreibt.
  8. Eine kurze Reflexion zu Datensicherheit, Testumgebungen und dem Umgang mit fiktiven betrieblichen Daten.

Mindestanforderung: Die praktischen Tests müssen konsistente Endzustände zeigen; Fehlerfälle dürfen keine ungültigen Bestände hinterlassen.

Vertiefte Leistung: Du erkennst darüber hinaus die Grenzen von Integritätsbedingungen, Isolationsverfahren und Transaktionen über mehrere unabhängige Systeme hinweg.




OERs zum Thema


Wikipedia: Transaktion in der Informatik

Wikipedia-Artikel direkt öffnen

Weitere Artikel: ACID, Relationale Datenbank, SQL, Datenbanktransaktion, Datenintegrität, Entity-Relationship-Modell, SQLite und Concurrency Control.


Fachlich überprüfbare Quellen

  1. SQLite-Dokumentation: Transaction – BEGIN, COMMIT und ROLLBACK.
  2. SQLite-Dokumentation: Isolation – Sichtbarkeit und konkurrierende Verbindungen.
  3. SQLite-Dokumentation: Foreign Keys – Fremdschlüssel und ihre Aktivierung.
  4. SQLite-Dokumentation: CREATE TABLE – Schlüssel und Integritätsbedingungen.
  5. SQLite-Dokumentation: In-Memory Databases – Eigenschaften flüchtiger Testdatenbanken.
  6. Python-Dokumentation: sqlite3 – lokale Datenbankzugriffe und Transaktionssteuerung.
  7. PostgreSQL-Dokumentation: Transactions – grundlegende Transaktionsprinzipien und Savepoints.


Bildnachweise und Medienrechte

Die folgenden Wikimedia-Commons-Dateien wurden anhand ihrer Beschreibungsseiten und Lizenzangaben ausgewählt.

  1. Entity-Relationship-Modell.svg – Fleshgrinder; gemeinfrei.
  2. Relational key SVG.svg – IkamusumeFan; Creative Commons BY-SA 3.0.
  3. Relational database terms.svg – Booyabazooka; gemeinfrei.
  4. Acid transaction properties.svg – FeedMeGrapes; Creative Commons BY-SA 4.0.
  5. Update anomaly.svg – Nabav; gemeinfrei.

Die jeweiligen Bildbeschreibungsseiten enthalten die verbindlichen Lizenzbedingungen und gegebenenfalls weitere Angaben zur Namensnennung. Bei Veränderungen von CC-BY-SA-Medien sind die Bedingungen der jeweiligen Lizenz zu beachten.

Videos: Die beiden angegebenen YouTube-Videos sind externe Lernmedien. Ihre Einbettung bedeutet nicht, dass sie unter einer freien OER-Lizenz stehen. Vor einer Wiederveröffentlichung außerhalb der Plattform müssen die jeweiligen Nutzungsrechte gesondert geprüft werden.

Datenschutz: Externe Video- und iFrame-Angebote können beim Aufruf Daten an Drittanbieter übertragen. In schulischen oder betrieblichen Lernumgebungen sind die dafür geltenden Datenschutz- und Einwilligungsregeln zu beachten. Sämtliche praktischen Datenbankübungen dieses Kurses funktionieren dagegen lokal und offline.


Verknüpfte Lernbereiche


aiMOOC-Projekte



Schulfach+




aiMOOCs



aiMOOC Projekte









MOOCwiki · Deutsch

Nach dem Lernen ist vor dem Lernen

Entdecke direkt den nächsten Lernkurs. Weitere Inhalte erscheinen, wenn Du weiter nach unten scrollst.

Zur MOOCwiki-Hauptseite

Mediathek

Inhalte werden geladen ...

Mediathek wird aus dem Wiki geladen ...