Die Druckversion wird nicht mehr unterstützt und kann Darstellungsfehler aufweisen. Bitte aktualisiere deine Browser-Lesezeichen und verwende stattdessen die Standard-Druckfunktion des Browsers.

aiMOOC

Datenbanken und betriebliche Datenmodelle – Datenmodelle auf Redundanz prüfen

QR-Code

Einleitung

Datenbanken und betriebliche Datenmodelle – Datenmodelle auf Redundanz prüfen

Zielgruppe: Ausbildung, insbesondere Fachinformatikerinnen und Fachinformatiker, kaufmännische IT-Berufe und Berufsschule.

Lernziel: Du erkennst Datenredundanzen, erklärst typische Anomalien und überführst ein einfaches betriebliches Datenmodell in die ersten drei Normalformen.

Praxisfall: Die fiktive Fahrradwerkstatt „RadWerk“ möchte ihre Auftragsverwaltung verbessern.

Lernzeit: etwa 60–75 Minuten, aufgeteilt in sechs kurze Lerneinheiten.

Einheit	Thema	Ergebnis
Start	Redundanz erkennen	Fehler finden
Basis	Erste Normalform	Einzelwerte prüfen
Aufbau	Zweite Normalform	Abhängigkeiten trennen
Vertiefung	Dritte Normalform	Kundendaten auslagern
Labor A	Fehler simulieren	Anomalie nachweisen
Labor B	Normalisiertes Modell	SQL und Tests ausführen

Sicheres Arbeiten: Alle Geschäftsdaten dieses Kurses sind erfunden. Die Python-Beispiele verwenden ausschließlich lokale SQLite-Datenbanken mit :memory:. Es werden keine Datenbanken auf fremden Rechnern, keine betrieblichen Produktivsysteme und keine echten Kundeninformationen verwendet. Externe Videos und Lernangebote sind optional und keine SQL-Testumgebungen.

Lerneinheit 1: Redundanz im Ausbildungsbetrieb erkennen

Dauer: 8 Minuten

Der Ausbildungsfall

RadWerk speichert Aufträge, Kunden und Artikel in einer einzigen Tabelle.

Vereinfachte Geschäftsregel: Jeder Artikel kommt innerhalb eines Auftrags höchstens einmal vor.

Auftrag	Datum	Kunde-ID	Kundenname	Artikel-ID	Artikel	Preis in €	Menge
R1001	01.10.2026	K01	Mia Beck	A10	Kette	20	2
R1001	01.10.2026	K01	Mia Beck	A20	Bremse	35	1
R1002	02.10.2026	K02	Ben Ali	A10	Kette	20	1
R1003	03.10.2026	K01	Mia Beck	A30	Licht	15	1

Beobachte: „Mia Beck“ erscheint dreimal. „Kette“ und der Preis 20 erscheinen zweimal.

Eine solche mehrfache Speicherung derselben Sachinformation nennt man Redundanz.

Wichtig: Nicht jede Wiederholung ist problematisch. Die wiederholte Kunden-ID als Fremdschlüssel ist eine beabsichtigte Verknüpfung. Kritisch ist vor allem die unnötige Wiederholung veränderlicher Sachinformationen.

Abbildung: Beispiel einer überflüssigen Beziehung in einem Datenbankschema. Das Bild zeigt ein anderes Modell als der RadWerk-Fall.

Drei typische Datenbankanomalien

Problem	Beispiel bei RadWerk
Änderungsanomalie	Ein Artikel wird nur in einer von mehreren Zeilen umbenannt.
Einfügeanomalie	Ein neuer Artikel lässt sich im bisherigen Positionsmodell nicht unabhängig von einem Auftrag erfassen.
Löschanomalie	Beim Löschen des letzten Auftrags mit Artikel A30 verschwinden zugleich die einzigen gespeicherten Informationen über diesen Artikel.

1. Änderungsanomalie

Wenn „Kette“ in einer Zeile zu „Fahrradkette“ wird und in einer anderen unverändert bleibt, entstehen widersprüchliche Daten.

2. Einfügeanomalie

Ein neuer Artikel sollte erfasst werden können, auch wenn noch niemand ihn bestellt hat.

3. Löschanomalie

Das Löschen einer Auftragsposition darf nicht unbeabsichtigt den letzten gespeicherten Artikelstammsatz entfernen.

Mini-Aufgabe: Welche Information gehört dauerhaft zu einem Artikel, welche zu einem einzelnen Auftrag?

Feedback: Artikelbezeichnung und aktueller Listenpreis gehören zum Artikelstamm. Datum und Kunde gehören zum Auftrag. Die Menge gehört zur Auftragsposition, weil sie erst durch die Kombination von Auftrag und Artikel bestimmt wird.

Lerneinheit 2: Erste Normalform – einzelne Werte

Dauer: 7 Minuten

Die erste Normalform (1NF) verlangt atomare Attributwerte. Für unsere Anwendung bedeutet das: In einem Feld steht nicht eine ganze Liste von unabhängig zu verwaltenden Werten.

Problembeispiel:

Kunde	Telefonnummern
K01	0170-111111; 0761-222222

Besser:

Kunde	Telefonnummer
K01	0170-111111
K01	0761-222222

Die Telefonnummern können in einer eigenen Tabelle stehen, zum Beispiel mit dem zusammengesetzten Schlüssel aus Kunde und Telefonnummer, sofern dieselbe Nummer je Kunde nur einmal erfasst wird.

Abbildung: Fremdes Beispiel einer Tabelle mit nicht atomaren Daten.

Merksatz: Die 1NF beseitigt Listen innerhalb einzelner Tabellenfelder. Sie beseitigt noch nicht alle Redundanzen.

Die Ausgangstabelle von RadWerk erfüllt in unserem vereinfachten Beispiel bereits die 1NF: Jede Zeile beschreibt eine Position, und jedes Feld enthält einen einzelnen Wert.

Selbsttest: Ist das Feld Artikel = "Kette, Bremse" geeignet, wenn die einzelnen Artikel getrennt verarbeitet werden müssen?

Feedback: Nein. Zwei eigenständige Artikel sind in einem Feld zusammengefasst. Getrennte Positionszeilen ermöglichen unterschiedliche Mengen, Preise und Auswertungen.

Lerneinheit 3: Zweite Normalform – vom ganzen Schlüssel abhängig

Dauer: 8 Minuten

Die zweite Normalform (2NF) baut auf der 1NF auf. Ein Nichtschlüsselattribut darf nicht nur von einem echten Teil eines zusammengesetzten Schlüsselkandidaten abhängen.

In unserer Ausgangstabelle bildet folgende Kombination den Primärschlüssel:

(Auftrag-ID, Artikel-ID)

Funktionale Abhängigkeiten:

Auftrag-ID                → Datum
Auftrag-ID                → Kunde-ID
Artikel-ID                → Artikelname
Artikel-ID                → Listenpreis
(Auftrag-ID, Artikel-ID)  → Menge

Der Fehler: Das Auftragsdatum hängt nur von der Auftrag-ID ab. Der Artikelname hängt nur von der Artikel-ID ab. Beides sind partielle funktionale Abhängigkeiten vom zusammengesetzten Schlüssel.

Lösung: Auf drei Tabellen aufteilen

AUFTRAG_2NF
  Auftrag-ID [PK]
  Datum
  Kunde-ID
  Kundenname

ARTIKEL
  Artikel-ID [PK]
  Artikelname
  Listenpreis

POSITION
  Auftrag-ID [PK, FK]
  Artikel-ID [PK, FK]
  Menge

Tabelle	Bestimmt durch
Auftrag_2NF	Auftrag-ID
Artikel	Artikel-ID
Position	Auftrag-ID und Artikel-ID gemeinsam

Ergebnis: Artikelbezeichnungen und Auftragsdaten müssen nicht mehr in jeder Position mitgespeichert werden.

Allerdings steht der Kundenname noch bei jedem Auftrag. Hier ist eine weitere Verbesserung möglich.

Mini-Aufgabe: Warum gehört die Menge nicht ausschließlich in die Tabelle Artikel?

Feedback: Weil ein Artikel in verschiedenen Aufträgen unterschiedlich oft bestellt werden kann. Erst Auftrag-ID und Artikel-ID gemeinsam bestimmen die Menge.

Lerneinheit 4: Dritte Normalform – indirekte Abhängigkeiten entfernen

Dauer: 8 Minuten

Die dritte Normalform (3NF) baut auf der 2NF auf.

Für diesen Ausbildungsfall gilt die vereinfachte Regel: Nichtschlüsselattribute sollen nicht über ein anderes Nichtschlüsselattribut indirekt vom Schlüssel abhängen.

Noch problematisch:

Auftrag-ID → Kunde-ID → Kundenname

Der Kundenname hängt über die Kunde-ID nur indirekt von der Auftrag-ID ab. Das ist eine transitive Abhängigkeit.

Lösung: Lege eine eigene Kundentabelle an.

Das normalisierte Datenmodell

KUNDE
  Kunde-ID [PK]
  Name

AUFTRAG
  Auftrag-ID [PK]
  Datum
  Kunde-ID [FK → Kunde]

ARTIKEL
  Artikel-ID [PK]
  Bezeichnung
  Listenpreis

POSITION
  Auftrag-ID [PK, FK → Auftrag]
  Artikel-ID [PK, FK → Artikel]
  Menge
  PreisBeiAuftrag

Beziehungen:

KUNDE    1 ───── n AUFTRAG

AUFTRAG  1 ───── n POSITION

ARTIKEL  1 ───── n POSITION

Abbildung: Beispiel eines Entity-Relationship-Modells aus einem anderen Anwendungsbereich.

PK bedeutet Primärschlüssel. FK bedeutet Fremdschlüssel.

Visualisierung der normalisierten Daten

Kunde

Kunde-ID	Name
K01	Mia Beck
K02	Ben Ali

Auftrag

Auftrag-ID	Datum	Kunde-ID
R1001	01.10.2026	K01
R1002	02.10.2026	K02
R1003	03.10.2026	K01

Artikel

Artikel-ID	Bezeichnung	Listenpreis in €
A10	Kette	20
A20	Bremse	35
A30	Licht	15

Position

Auftrag-ID	Artikel-ID	Menge	PreisBeiAuftrag in €
R1001	A10	2	20
R1001	A20	1	35
R1002	A10	1	20
R1003	A30	1	15

Wichtige betriebliche Ausnahme: Der vereinbarte Preis bei Auftragserteilung wird zusätzlich in der Position gespeichert. Dieser historische Positionspreis ist fachlich etwas anderes als der aktuelle Listenpreis des Artikels.

Wenn sich der Listenpreis später von 20 € auf 25 € ändert, muss der ursprüngliche Auftrag weiterhin mit 20 € pro Stück nachvollziehbar bleiben.

Das ist keine unnötige Redundanz: Die beiden Werte beschreiben unterschiedliche Sachverhalte.

Ergebnis: Die Stammdaten sind voneinander getrennt. Über Fremdschlüssel können sie wieder zusammengeführt werden.

Lerneinheit 5: Lokales SQL-Labor A – Redundanz sichtbar machen

Dauer: 10 Minuten

Ziel: Erzeuge in einer isolierten Testdatenbank absichtlich eine Änderungsanomalie.

Voraussetzung: Lokal installiertes Python 3 mit dem Standardmodul sqlite3. Kein Datenbankserver, kein zusätzliches Python-Paket und kein Netzwerkzugriff erforderlich.

Speichere den folgenden Code in einer lokalen Datei namens labor_a.py. Starte sie mit python3 labor_a.py, unter Windows gegebenenfalls mit py labor_a.py.

import sqlite3

# Isolierte Datenbank nur im Arbeitsspeicher
db = sqlite3.connect(":memory:")

db.executescript("""
CREATE TABLE Roh (
  auftrag TEXT NOT NULL,
  datum TEXT,
  kunde TEXT,
  kundenname TEXT,
  artikel TEXT NOT NULL,
  artikelname TEXT,
  listenpreis INTEGER,
  menge INTEGER,
  PRIMARY KEY (auftrag, artikel)
);

INSERT INTO Roh VALUES
('R1001','2026-10-01','K01','Mia Beck',
 'A10','Kette',20,2),
('R1001','2026-10-01','K01','Mia Beck',
 'A20','Bremse',35,1),
('R1002','2026-10-02','K02','Ben Ali',
 'A10','Kette',20,1),
('R1003','2026-10-03','K01','Mia Beck',
 'A30','Licht',15,1);
""")

# Absichtlich nur eine der zwei A10-Zeilen ändern
db.execute("""
UPDATE Roh
SET artikelname = 'Fahrradkette'
WHERE auftrag = 'R1001' AND artikel = 'A10'
""")

namen = sorted({
    zeile[0]
    for zeile in db.execute(
        "SELECT artikelname FROM Roh WHERE artikel='A10'"
    )
})

print("Artikel A10 hat jetzt diese Namen:", namen)

assert namen == ["Fahrradkette", "Kette"]
print("TEST OK: Änderungsanomalie nachgewiesen.")

db.close()

Erwartete Ausgabe:

Artikel A10 hat jetzt diese Namen:
['Fahrradkette', 'Kette']
TEST OK: Änderungsanomalie nachgewiesen.

Interpretation: Derselbe Artikel besitzt zwei unterschiedliche Bezeichnungen. Das Problem liegt in der redundanten Speicherung.

Experimentiere selbst

Ändere die WHERE-Bedingung so, dass alle Zeilen zum Artikel A10 aktualisiert werden. Beobachte anschließend die Ausgabe.

Tipp: Nach Deiner Änderung muss auch die erwartete assert-Bedingung angepasst werden.

Feedback: Ein vollständiges Aktualisieren aller betroffenen Zeilen vermeidet in diesem kleinen Versuch den Widerspruch. Das Datenmodell bleibt jedoch fehleranfällig, weil dieselbe Sachinformation weiterhin mehrfach gespeichert wird.

Lerneinheit 6: Lokales SQL-Labor B – die normalisierte Lösung testen

Dauer: 12 Minuten

Ziel: Erstelle vier Tabellen, verwende SQL-Fremdschlüssel und teste eine JOIN-Abfrage.

Dieses zweite Labor verwendet eine neue und vollständig getrennte SQLite-Datenbank im Arbeitsspeicher.

Speichere das folgende vollständige Programm unter labor_b.py und starte es lokal.

import sqlite3

db = sqlite3.connect(":memory:")
db.execute("PRAGMA foreign_keys = ON")

assert db.execute(
    "PRAGMA foreign_keys"
).fetchone()[0] == 1

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

CREATE TABLE Artikel (
  id TEXT PRIMARY KEY NOT NULL,
  bezeichnung TEXT NOT NULL,
  listenpreis INTEGER NOT NULL
    CHECK (listenpreis >= 0)
);

CREATE TABLE Auftrag (
  id TEXT PRIMARY KEY NOT NULL,
  datum TEXT NOT NULL,
  kunde_id TEXT NOT NULL REFERENCES Kunde(id)
);

CREATE TABLE Position (
  auftrag_id TEXT NOT NULL REFERENCES Auftrag(id),
  artikel_id TEXT NOT NULL REFERENCES Artikel(id),
  menge INTEGER NOT NULL CHECK (menge > 0),
  preis_bei_auftrag INTEGER NOT NULL
    CHECK (preis_bei_auftrag >= 0),
  PRIMARY KEY (auftrag_id, artikel_id)
);

INSERT INTO Kunde VALUES
('K01','Mia Beck'),
('K02','Ben Ali');

INSERT INTO Artikel VALUES
('A10','Kette',20),
('A20','Bremse',35),
('A30','Licht',15);

INSERT INTO Auftrag VALUES
('R1001','2026-10-01','K01'),
('R1002','2026-10-02','K02'),
('R1003','2026-10-03','K01');

INSERT INTO Position VALUES
('R1001','A10',2,20),
('R1001','A20',1,35),
('R1002','A10',1,20),
('R1003','A30',1,15);
""")

# Artikel nur an einer zentralen Stelle ändern
db.execute("""
UPDATE Artikel
SET bezeichnung='Fahrradkette', listenpreis=25
WHERE id='A10'
""")

# Daten wieder zusammenführen
ergebnis = db.execute("""
SELECT a.id, k.name, art.bezeichnung,
       p.menge, p.preis_bei_auftrag
FROM Auftrag AS a
JOIN Kunde AS k ON k.id = a.kunde_id
JOIN Position AS p ON p.auftrag_id = a.id
JOIN Artikel AS art ON art.id = p.artikel_id
ORDER BY a.id, p.artikel_id
""").fetchall()

print("Auftragspositionen:")
for zeile in ergebnis:
    print(zeile)

# Automatische Tests
assert len(ergebnis) == 4
assert sum(
    menge * preis
    for auftrag, kunde, artikel, menge, preis in ergebnis
    if auftrag == "R1001"
) == 75

assert db.execute("""
SELECT bezeichnung FROM Artikel WHERE id='A10'
""").fetchone()[0] == "Fahrradkette"

print("TEST OK: JOIN und Auftragssumme 75 Euro.")

# Prüfen, ob ungültige Fremdschlüssel verhindert werden
try:
    db.execute("""
    INSERT INTO Position
    VALUES ('R9999','A10',1,25)
    """)
except sqlite3.IntegrityError:
    print("TEST OK: Ungültiger Auftrag wurde abgewiesen.")
else:
    raise AssertionError("Fremdschlüsselprüfung fehlt!")

# Interaktive lokale Testumgebung
while True:
    wahl = input(
        "Test: 1=Auftragssumme, 2=Artikel, Enter=Ende: "
    ).strip()

    if wahl == "":
        break

    if wahl == "1":
        print(db.execute("""
        SELECT SUM(menge * preis_bei_auftrag)
        FROM Position
        WHERE auftrag_id='R1001'
        """).fetchone()[0], "Euro")

    elif wahl == "2":
        print(db.execute("""
        SELECT id, bezeichnung, listenpreis
        FROM Artikel ORDER BY id
        """).fetchall())

    else:
        print("Bitte 1, 2 oder Enter wählen.")

db.close()
print("Lokale Testumgebung beendet.")

Erwartete Ergebnisse:

Test	Erwartung	Begründung
JOIN	Vier Positionen	Alle ursprünglichen Positionen sind rekonstruierbar.
Artikel A10	Fahrradkette	Eine Änderung des Artikelstamms reicht aus.
Neuer Listenpreis	25 €	Der aktuelle Stammpreis wurde geändert.
Auftrag R1001	75 €	Zweimal 20 € plus einmal 35 € bleiben historisch korrekt.
Ungültige Auftrag-ID R9999	Wird abgewiesen	Der aktivierte Fremdschlüssel schützt die Zuordnung.

Wichtig: Die Tests beweisen bestimmte Eigenschaften dieser Beispieldatenbank. Sie ersetzen keine vollständige formale Normalisierungsprüfung. Dafür müssen weiterhin die fachlichen Abhängigkeiten und Geschäftsregeln untersucht werden.

Drei Experimente im lokalen Labor

JOIN: Ergänze die Ausgabe um das Auftragsdatum. Feedback: Eine zusätzliche Spalte aus der bereits verknüpften Tabelle Auftrag ist ausreichend.
Fremdschlüssel: Versuche eine Position mit einer nicht vorhandenen Artikel-ID anzulegen. Feedback: SQLite muss den Datensatz wegen der aktivierten Fremdschlüsselprüfung ablehnen.
Historisierung: Ändere den aktuellen Artikelpreis erneut und überprüfe die Auftragssumme. Feedback: Die Auftragssumme bleibt 75 €, solange die gespeicherten historischen Positionspreise nicht geändert werden.

Gestufte Hilfen

Bearbeite zunächst jede Aufgabe ohne Hilfen. Verwende bei Bedarf die nächste Stufe.

Stufe	Hilfe	Beispiel
Erster Hinweis	Suche wiederholte fachliche Informationen.	Wo steht derselbe Artikelname mehrfach?
Zweiter Hinweis	Prüfe, welcher Schlüssel eine Information bestimmt.	Bestimmt die Artikel-ID den Namen?
Dritter Hinweis	Ordne die Daten dem passenden Sachverhalt zu.	Artikelname in Artikel; Menge in Position; Kundenname in Kunde.

Kontrollfrage: Kann ein Datenmodell trotz weniger Tabellen besser sein als eines mit vielen Tabellen?

Feedback: Die Tabellenanzahl allein ist kein Qualitätsmaß. Entscheidend sind fachlich korrekte Abhängigkeiten, sinnvolle Schlüssel, Datenintegrität und die Anforderungen der Anwendung.

Interaktive Aufgaben

Quiz: Teste Dein Wissen

Was bedeutet Redundanz in einem Datenmodell? (Dieselbe Sachinformation wird unnötig mehrfach gespeichert) (!Jeder Datensatz besitzt eine eindeutige Nummer) (!Eine SQL-Abfrage verknüpft zwei Tabellen) (!Ein Feld enthält einen fehlenden Wert)

Welche Anomalie entsteht, wenn derselbe Artikel in verschiedenen Zeilen unterschiedliche Namen besitzt? (Änderungsanomalie) (!Einfügeanomalie) (!Löschanomalie) (!Verbindungsfehler)

Was ist eine zentrale Anforderung der ersten Normalform? (Atomare Werte in den Tabellenfeldern) (!Jede Datenbank besitzt genau eine Tabelle) (!Alle Tabellen haben gleich viele Spalten) (!Jeder Artikel besitzt genau einen Auftrag)

Welcher Primärschlüssel identifiziert im vereinfachten Ausgangsmodell eine Auftragsposition? (Auftrag-ID und Artikel-ID gemeinsam) (!Nur der Artikelname) (!Nur der Kundenname) (!Nur das Auftragsdatum)

Welche funktionale Abhängigkeit zeigt im Ausgangsmodell eine Teilabhängigkeit? (Auftrag-ID bestimmt das Auftragsdatum) (!Auftrag-ID und Artikel-ID bestimmen gemeinsam die Menge) (!Ein Fremdschlüssel verweist auf eine andere Tabelle) (!Ein JOIN rekonstruiert Auftragsinformationen)

Welche Maßnahme führt das RadWerk-Ausgangsmodell näher an die zweite Normalform? (Auftragsdaten und Artikeldaten von den Positionen trennen) (!Alle Daten in eine einzige Textspalte schreiben) (!Den Kundennamen in jeder Position vervielfachen) (!Sämtliche Schlüssel aus den Tabellen entfernen)

Welche Abhängigkeit wird im Beispiel beim Übergang zur dritten Normalform aufgelöst? (Auftrag-ID bestimmt Kunde-ID und diese bestimmt den Kundennamen) (!Auftrag-ID und Artikel-ID bestimmen die Positionsmenge) (!Artikel-ID bestimmt die Artikelbezeichnung in der Artikeltabelle) (!Kunde-ID bestimmt den Kundennamen in der Kundentabelle)

In welche Tabelle gehört der Kundenname im normalisierten RadWerk-Modell? (In die Tabelle Kunde) (!In jede Auftragsposition) (!In die Tabelle Artikel) (!In jede Preisberechnung)

Welche Spalte verbindet einen Auftrag mit seinem Kunden? (Die Kunde-ID als Fremdschlüssel) (!Die Menge der bestellten Artikel) (!Der aktuelle Artikelpreis) (!Die Artikelbezeichnung)

Warum wird der Preis bei Auftragserteilung in der Position gespeichert? (Damit der damals vereinbarte Preis nachvollziehbar bleibt) (!Damit die Artikel-ID überflüssig wird) (!Damit alle Preise jederzeit identisch sind) (!Damit keine Tabellenverknüpfung mehr erforderlich ist)

Begründetes Feedback zum Quiz

Frage	Warum die richtige Antwort stimmt
A	Redundanz bedeutet unnötige Mehrfachspeicherung derselben Sachinformation.
B	Ein unvollständiges Update kann widersprüchliche Artikelbezeichnungen erzeugen.
C	Atomare Felder verhindern unabhängig zu verwaltende Wertelisten in einer Zelle.
D	Im Modell wird eine Position durch die gemeinsame Kombination beider IDs identifiziert.
E	Das Datum hängt nur von einem Teil des zusammengesetzten Schlüssels ab.
F	Die 2NF entfernt die problematischen Teilabhängigkeiten.
G	Kunde-ID bestimmt Kundenname; das erzeugt in Auftrag_2NF eine transitive Abhängigkeit.
H	Der Kundenname ist ein Attribut des Kunden, nicht einer einzelnen Position.
I	Die Kunde-ID in Auftrag verweist auf den zugehörigen Kundendatensatz.
J	Ein historischer Auftragswert darf durch spätere Listenpreisänderungen nicht überschrieben werden.

Memory

Finde die passenden Begriffspaare.

Redundanz	Unnötige Mehrfachspeicherung
Änderungsanomalie	Widersprüchliche Aktualisierung
Einfügeanomalie	Neues Objekt nicht unabhängig erfassbar
Löschanomalie	Unbeabsichtigter Informationsverlust
Primärschlüssel	Eindeutige Datensatzidentifikation
Fremdschlüssel	Verweis auf einen anderen Datensatz
Transitive Abhängigkeit	Indirekte Bestimmung über ein Zwischenattribut

Drag and Drop

Ordne die Datenfelder den passenden Bereichen des normalisierten Datenmodells zu.

Ordne die richtigen Begriffe zu.	Thema
Kundenname	Kundenstammdaten
Auftragsdatum	Auftragskopf
Artikelbezeichnung	Artikelstammdaten
Bestellte Menge	Auftragsposition
Auftrag-ID und Artikel-ID	Zusammengesetzter Positionsschlüssel

Feedback: Die richtige Zuordnung ergibt sich daraus, welcher fachliche Schlüssel das jeweilige Attribut bestimmt. Die Kombination aus Auftrag-ID und Artikel-ID identifiziert in diesem vereinfachten Modell genau eine Position.

Kreuzworträtsel

Redundanz	Wie nennt man die unnötige mehrfache Speicherung derselben Sachinformation?
Primaerschluessel	Wie heißt der ausgewählte Schlüssel zur eindeutigen Identifikation einer Tabellenzeile? Schreibe ae und ue.
Fremdschluessel	Wie heißt ein Attribut, das auf einen Schlüssel einer anderen Tabelle verweist? Schreibe ue.
Anomalie	Wie nennt man eine unerwünschte Unregelmäßigkeit beim Ändern, Einfügen oder Löschen?
Atomar	Wie nennt man einen für die Anwendung einzelnen, nicht als Liste gespeicherten Wert?
Normalisierung	Wie heißt das Prüfen und Überführen von Datenbankschemata in Normalformen?

LearningApps

Optionale externe Lernangebote: Verwende dort ausschließlich selbst erfundene Daten. Für die lokalen SQL-Labore ist keine Internetverbindung notwendig.

Lückentext

Die unnötige Mehrfachspeicherung derselben Sachinformation heißt

.

Ein unvollständiges Aktualisieren wiederholter Informationen kann eine

verursachen.

Die erste Normalform fordert für unsere Anwendung

Feldwerte.

Eine Zeile wird durch ihren

eindeutig identifiziert.

Das Auftragsdatum wird im Beispiel durch die

bestimmt.

Der Artikelname wird durch die

bestimmt.

Abhängigkeiten nur von Teilen eines zusammengesetzten Schlüssels heißen

.

Die zweite Normalform beseitigt solche

.

Der Kundenname hängt in Auftrag_2NF über die Kunde-ID nur

von der Auftrag-ID ab.

Die dritte Normalform beseitigt in unserem Beispiel diese

Abhängigkeit.

Ein Verweis auf den Schlüssel einer anderen Tabelle heißt

.

Das Zusammenführen zusammengehöriger Daten geschieht in SQL häufig mit einem

.

Der historische Verkaufspreis wird im Beispiel in der Tabelle

gespeichert.

Eine SQLite-Datenbank mit der speziellen Angabe memory liegt nur im

.

Offene Aufgaben

Die folgenden zwölf Aufgaben führen von Basiswissen über die praktische Anwendung bis zum Transfer. Nutze bei Schwierigkeiten die gestuften Hilfen.

Leicht: Basisaufgaben

Redundanz: Markiere in der ursprünglichen RadWerk-Tabelle mindestens zwei mehrfach gespeicherte Sachinformationen. Feedback: Besonders geeignet sind der Kundenname und der Artikelname, weil dieselbe fachliche Information in mehreren Zeilen steht.
Änderungsanomalie: Zeichne eine kleine Tabelle, in der derselbe Artikel zwei widersprüchliche Bezeichnungen besitzt. Feedback: Die Anomalie ist korrekt dargestellt, wenn beide Zeilen dieselbe Artikel-ID, aber unterschiedliche Namen enthalten.
Primärschlüssel: Erkläre, warum im vereinfachten Positionsmodell zwei IDs den gemeinsamen Primärschlüssel bilden. Feedback: Erst die Kombination identifiziert die einzelne Position; ein Artikel kann in mehreren Aufträgen vorkommen.
Erste Normalform: Entwirf eine geeignete Speicherung für einen Kunden mit drei Telefonnummern. Feedback: Richtig ist eine Struktur, in der Telefonnummern als einzelne Werte verwaltet werden können.

Standard: Anwendungsaufgaben

Funktionale Abhängigkeit: Notiere mindestens vier fachlich gültige Abhängigkeiten aus dem RadWerk-Modell. Feedback: Dazu gehören Auftrag-ID zu Datum, Artikel-ID zu Bezeichnung, Kunde-ID zu Name und die Kombination aus Auftrag-ID und Artikel-ID zur Menge.
Zweite Normalform: Zerlege die Rohdatentabelle zunächst in Auftrag_2NF, Artikel und Position. Feedback: Richtig ist die Zerlegung, wenn weder Auftragsdatum noch Artikelname in Position wiederholt werden müssen.
Dritte Normalform: Verbessere das 2NF-Modell durch eine eigene Kundentabelle. Feedback: Die Auftragstabelle speichert danach die Kunde-ID als Verweis, aber nicht mehr den Kundennamen.
SQL: Führe Labor B aus, ergänze die JOIN-Abfrage um das Datum und dokumentiere die Ergebnisse. Feedback: Die Daten lassen sich vollständig rekonstruieren, weil die Schlüsselbeziehungen erhalten bleiben.

Schwer: Transferaufgaben

Historisierung: Begründe, weshalb der historische Verkaufspreis in der Position gespeichert werden darf, obwohl der Artikel einen aktuellen Listenpreis besitzt. Feedback: Entscheidend ist der unterschiedliche fachliche und zeitliche Bedeutungsinhalt der beiden Preise.
Referentielle Integrität: Entwickle zwei zusätzliche lokale Tests für ungültige Fremdschlüssel oder Mengen. Feedback: Ein guter Test erwartet bei nicht vorhandenen Verweisen oder einer nicht positiven Menge einen Integritätsfehler.
Datenbankentwurf: Erweitere das Modell so, dass derselbe Artikel mehrfach als getrennte Position im selben Auftrag vorkommen kann. Feedback: Ein eigenständiger Positionsschlüssel oder eine Positionsnummer ermöglicht mehrere Zeilen mit derselben Artikel-ID; die bisherigen Geschäftsregeln müssen entsprechend angepasst werden.
Datenschutz: Entwirf einen sicheren Testplan für eine betriebliche Datenbankumstellung. Feedback: Der Plan sollte isolierte Systeme, fiktive Testdaten, dokumentierte Berechtigungen, Rückfallmöglichkeiten und das Verbot ungefragter Produktivzugriffe enthalten.

Lernkontrolle

Bearbeite die folgenden Aufgaben ohne vorgegebene Antwortmöglichkeiten. Begründe Deine Entscheidungen anhand fachlicher Abhängigkeiten und Geschäftsregeln.

Datenmodell: Eine Werkstatt speichert Mitarbeiter-ID, Mitarbeitername, Auftrag-ID und Arbeitszeit in einer Tabelle. Untersuche mögliche Redundanzen und entwirf eine bessere Struktur.
Normalisierung: Ein Versandunternehmen speichert Kundennummer, Kundenname, Bestellnummer, Produktnummer und Stückzahl in einer Tabelle. Entwickle die nötige Zerlegung bis zur dritten Normalform und kennzeichne die Schlüssel.
Datenintegrität: Nach dem Löschen eines Auftrags verschwindet auch der letzte gespeicherte Datensatz eines selten verwendeten Artikels. Erkläre die Ursache und zeige, welche Tabellenstruktur das verhindern kann.
Datenbankmigration: Ein Unternehmen möchte von einer redundanten Tabelle auf ein normalisiertes Modell wechseln. Entwirf eine Vorgehensweise, die die Vollständigkeit der Daten und die Rekonstruierbarkeit der ursprünglichen Auftragsinformationen überprüft.
Datenbankdesign: Vergleiche ein normalisiertes Modell mit einer bewusst denormalisierten Berichtstabelle. Erkläre, unter welchen Bedingungen eine kontrollierte Mehrfachspeicherung sinnvoll sein könnte und welche zusätzlichen Konsistenzmaßnahmen erforderlich wären.

Beurteilungskriterien:

Kriterium	Erfolgreiche Leistung
Fachliche Analyse	Relevante Abhängigkeiten und mögliche Anomalien sind nachvollziehbar erklärt.
Modellqualität	Tabellen, Primärschlüssel und Fremdschlüssel entsprechen den Geschäftsregeln.
Transfer	Die vorgeschlagene Lösung funktioniert auch mit neuen, nicht nur den gezeigten Beispieldaten.
Nachweis	Ergebnisse werden durch nachvollziehbare Beispiele, SQL-Abfragen oder Tests belegt.
Sicherheit	Nur lokale oder ausdrücklich genehmigte isolierte Testumgebungen mit fiktiven Daten werden verwendet.

Lernnachweis

Für einen erfolgreichen Lernnachweis sollst Du folgende Ergebnisse vorlegen können:

Eine markierte Beispieltabelle, in der unnötige Redundanzen erkennbar sind.
Eine begründete Erklärung der Änderungs-, Einfüge- und Löschanomalie.
Eine dokumentierte Überführung des Ausbildungsfalls in die erste, zweite und dritte Normalform.
Ein relationales Datenmodell mit korrekt ausgewiesenen Primär- und Fremdschlüsseln.
Zwei lokal ausführbare SQL-Labore einschließlich ihrer Testergebnisse.
Eine nachvollziehbare JOIN-Abfrage, die alle vier ursprünglichen Auftragspositionen rekonstruiert.
Eine Erklärung des Unterschieds zwischen aktuellem Listenpreis und historischem Positionspreis.
Eine Reflexion über sichere Testdaten, Datenintegrität und den Nutzen der Normalisierung.

Mindestanforderung: Deine Lösung muss fachlich begründet und anhand eigener Beispiele überprüfbar sein. Ein richtiges SQL-Ergebnis allein reicht ohne Erklärung des zugrunde liegenden Datenmodells nicht aus.

OERs zum Thema

Wikipedia

Der folgende Artikel erläutert die Normalformen, funktionale Abhängigkeiten sowie die Vermeidung von Redundanzen und Anomalien.

Fachlich geprüfte Grundlagen

Wikipedia: Normalisierung von Datenbanken – Grundlagen, Normalformen und Anomalien.
Wikipedia: Funktionale Abhängigkeit – Schlüsselabhängigkeiten und formale Hintergründe.
Tino Hempel: Normalisierung von Datenbanken – Unterrichtsbezogene Darstellung eines Normalisierungsprozesses.
Python-Dokumentation: sqlite3 – Lokale Datenbankverbindungen und SQL-Anwendung.
SQLite-Dokumentation: In-Memory Databases – Offizielle Beschreibung von :memory:.
SQLite-Dokumentation: Foreign Keys – Fremdschlüssel und referentielle Integrität.

Geprüfte Wikimedia-Commons-Medien

Die folgenden Bilddateien wurden anhand ihrer Wikimedia-Commons-Beschreibungsseiten und Lizenzinformationen ausgewählt. Sie sind dort als gemeinfrei ausgewiesen.

Medium	Urheberangabe	Lizenzangabe	Lernzweck
Redundante Beziehung	Fishpi	Public Domain	Unnötige Beziehungen erkennen
Update anomaly	Nabav; Bearbeitung Razorbliss	Public Domain	Änderungsanomalie
Insertion anomaly	Nabav und Stannered	Public Domain	Einfügeanomalie
Deletion anomaly	Nabav und Stannered	Public Domain	Löschanomalie
Nicht normalisierte Kundentabelle	Fishpi	Public Domain	Erste Normalform
Entity-Relationship-Modell	Fleshgrinder	Public Domain	Beziehungen im Datenmodell

Medienhinweis: Die externen Bilder illustrieren teilweise andere Datensätze als unser eigens erstelltes Ausbildungsbeispiel. Die RadWerk-Tabellen, Datensätze, Modelle und Codebeispiele wurden für diesen Kurs neu formuliert.

Ergänzende Lernvideos

Datenbanken – Normalisierung – Übungsaufgabe: Nutze dieses Video für einen zusätzlichen Übungsdurchlauf.

Weitere bereits im Kurs eingebettete Videos:

Rechtehinweis: Für die YouTube-Videos wird keine freie OER-Lizenz behauptet. Die Verlinkung beziehungsweise Einbettung ersetzt keine Genehmigung zur Weiterverbreitung oder Bearbeitung der Videodateien. Beachte die Rechte der jeweiligen Urheber und die Bedingungen der Plattform. Verfügbarkeit und Einbettbarkeit können sich ändern.

Datenschutzhinweis: YouTube, LearningApps und Wikipedia sind externe Informationsangebote und können beim Laden Netzwerkverbindungen auslösen. Ihre Nutzung ist für die lokalen Übungen nicht erforderlich. Übertrage keine betrieblichen Daten oder Zugangsdaten an solche Dienste.

Verknüpfte Lernbereiche

Datenbanken

Zusammenfassung:

Eine sorgfältige Normalisierung reduziert unnötige Mehrfachspeicherungen und das Risiko von Datenanomalien. Die erste Normalform verlangt atomare Feldwerte. Die zweite Normalform entfernt problematische Teilabhängigkeiten von zusammengesetzten Schlüsseln. Die dritte Normalform beseitigt im vereinfachten Ausbildungsfall transitive Abhängigkeiten zwischen Nichtschlüsselattributen.

Primärschlüssel identifizieren Datensätze. Fremdschlüssel verbinden Tabellen. Mit SQL lassen sich die getrennten Informationen wieder zusammenführen.

Die Qualität eines betrieblichen Datenmodells hängt nicht allein von der Tabellenanzahl ab, sondern davon, ob die fachlichen Zusammenhänge korrekt, eindeutig, nachvollziehbar und sicher abgebildet werden.