Datenbanken und betriebliche Datenmodelle – Datenänderungen kontrolliert durchführen
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
Offene Aufgaben
Bearbeite die Aufgaben ausschließlich mit fiktiven Daten. Dokumentiere bei Programmieraufgaben Ausgangszustand, Eingabe, Ergebnis und Begründung.
Leicht – Basisaufgaben
- Datenmodell: Zeichne ein kleines ER-Modell mit den Tabellen Artikel, Lagerort und Bestand. Markiere Primär- und Fremdschlüssel.
- Datenbanktransaktion: Erstelle ein Flussdiagramm für die Umbuchung von drei USB-C-Kabeln zwischen zwei Lagerplätzen.
- ACID: Gestalte vier Lernkarten, auf denen Du die ACID-Eigenschaften jeweils anhand eines Lagerbeispiels erklärst.
- Datenintegrität: Vergleiche zwei fiktive Bestandstabellen. Kennzeichne negative Bestände, fehlende Lagerorte und widersprüchliche Buchungen.
Standard – Anwendungsaufgaben
- SQLite: Starte das lokale Lagerlabor. Teste mindestens fünf unterschiedliche Umbuchungen und dokumentiere die Ergebnisse in einer Tabelle.
- ROLLBACK: Ergänze einen weiteren absichtlich ungültigen Testfall. Weise nach, dass der Bestand nach dem Abbruch unverändert bleibt.
- SQL: Erweitere die lokale Übungsdatenbank um einen dritten Lagerort C. Passe die Testdaten an und überprüfe eine Umbuchung nach C.
- 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
- Transaktionsverarbeitung: Entwickle eine Erweiterung für mehrere Artikel. Beschreibe, wie Du verhinderst, dass eine Umbuchung versehentlich den falschen Artikel verändert.
- Datenbankanomalie: Untersuche ein Szenario mit zwei gleichzeitig arbeitenden Lagerbeschäftigten. Entwirf einen sicheren Ablauf und begründe die erforderlichen Prüfungen.
- Datenkonsistenz: Gestalte ein fiktives Bestellsystem mit Bestellung, Bestellposition und Lagerbestand. Lege fest, welche Datenänderungen in einer gemeinsamen Transaktion ausgeführt werden müssen.
- 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.


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.
- 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.
- 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.
- Isolation: Zwei Mitarbeitende wollen gleichzeitig einen knappen Lagerbestand umbuchen. Untersuche mögliche Konflikte und zeige, wie die Anwendung ungültige Buchungen verhindert.
- Datenbankmodellierung: Eine Lagerverwaltung speichert Bestandsmengen und Artikelbezeichnungen mehrfach. Analysiere mögliche Änderungsanomalien und entwickle eine passendere Tabellenstruktur.
- Fehlerbehandlung: Entwirf für eine Bestandsumbuchung drei verschiedene Fehlerfälle und lege fest, was die Anwendung vor einem möglichen COMMIT überprüfen muss.
- Dauerhaftigkeit: Vergleiche die Datenbank im Arbeitsspeicher mit einer dauerhaft gespeicherten lokalen Datenbankdatei. Entwickle einen Testplan zur Kontrolle der Speicherung nach dem erneuten Öffnen.
- 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:
- Ein korrektes Modell mit Artikel, Lagerort und Bestand einschließlich der wichtigsten Schlüssel.
- Eine nachvollziehbare Erklärung des ACID-Prinzips anhand des Ausbildungsfalls.
- Ein lokal ausführbares Programm für eine sichere Lagerumbuchung.
- Nachweise über mindestens eine erfolgreiche und drei absichtlich fehlgeschlagene Umbuchungen.
- Eine Dokumentation, die zeigt, dass ROLLBACK keine teilweise ausgeführte Buchung hinterlässt.
- Eine begründete Auswertung des Isolationstests mit zwei Verbindungen.
- Eine eigenständige Transferlösung, die auch mögliche Grenzen der lokalen Transaktionskontrolle beschreibt.
- 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
- SQLite-Dokumentation: Transaction – BEGIN, COMMIT und ROLLBACK.
- SQLite-Dokumentation: Isolation – Sichtbarkeit und konkurrierende Verbindungen.
- SQLite-Dokumentation: Foreign Keys – Fremdschlüssel und ihre Aktivierung.
- SQLite-Dokumentation: CREATE TABLE – Schlüssel und Integritätsbedingungen.
- SQLite-Dokumentation: In-Memory Databases – Eigenschaften flüchtiger Testdatenbanken.
- Python-Dokumentation: sqlite3 – lokale Datenbankzugriffe und Transaktionssteuerung.
- PostgreSQL-Dokumentation: Transactions – grundlegende Transaktionsprinzipien und Savepoints.
Bildnachweise und Medienrechte
Die folgenden Wikimedia-Commons-Dateien wurden anhand ihrer Beschreibungsseiten und Lizenzangaben ausgewählt.
- Entity-Relationship-Modell.svg – Fleshgrinder; gemeinfrei.
- Relational key SVG.svg – IkamusumeFan; Creative Commons BY-SA 3.0.
- Relational database terms.svg – Booyabazooka; gemeinfrei.
- Acid transaction properties.svg – FeedMeGrapes; Creative Commons BY-SA 4.0.
- 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-HauptseiteMediathek
Mediathek wird aus dem Wiki geladen ...
Keine passenden Inhalte gefunden. Bitte ändere Suche oder Filter.
NEWSLernweltNOAH fragen