Ein Artikel kommt in vielen Bestellungen vor, eine Bestellung enthält viele Artikel. Welche Struktur löst diese n:m-Beziehung auf?

Eine Positionstabelle mit Verweisen auf Bestellung und Artikel

Position hat den Kandidatenschlüssel (bestellung_id, artikel_id). artikelname hängt nur von artikel_id ab. Es gibt keine weiteren Kandidatenschlüssel. Welche Abhängigkeit verhindert die zweite Normalform?

Partielle Abhängigkeit vom Kandidatenschlüssel

In Bestellung(id, kunde_id, kundenname) gilt id → kunde_id und kunde_id → kundenname. kundenname ist der aktuelle Stammdatenname. Welche Aufteilung beseitigt diese transitive Abhängigkeit?

Kunde(id, name) und Bestellung(id, kunde_id)

Eine Bestellposition speichert den bei Kauf vereinbarten Preis; die Artikeltabelle speichert den heutigen Listenpreis. Welche zwei Aussagen sind richtig?

Der historische Positionspreis darf vom heutigen Listenpreis abweichen, Eine spätere Listenpreisänderung darf den vereinbarten Positionspreis nicht automatisch ersetzen

Datenmodellierung · AE und SI

ER-Modell und Normalisierung mit Aufgaben

Leite Tabellen und Beziehungen aus Anforderungen ab. Verstehe Schlüssel, Kardinalitäten und die ersten drei Normalformen anhand einer Bestellverwaltung.

Verantwortlich: Bär Softwareentwicklung UG (haftungsbeschränkt) / Aktualisiert: 07.10.2026

Automatisch bewertetes Thementraining

Wissen direkt in einem kurzen Set prüfen

Bearbeite bis zu 5 zufällig ausgewählte Aufgaben in etwa 5 Minuten. Du erhältst nach jeder Aufgabe Feedback und am Ende eine kompakte Auswertung.

Vom Fachtext zum Datenmodell

Entitäten sind fachliche Objekte wie Kunde, Bestellung und Artikel. Attribute beschreiben deren Eigenschaften. Ein Primärschlüssel identifiziert jeden Datensatz eindeutig; ein Fremdschlüssel verweist auf einen passenden Schlüssel einer anderen Tabelle.

Kardinalitäten ergeben sich aus den Geschäftsregeln: Ein Kunde kann keine oder viele Bestellungen haben, jede Bestellung gehört in unserem Modell genau einem Kunden. Optionalität und Höchstzahl müssen getrennt betrachtet werden.

Kunde 1 — 0..* Bestellung
Bei 1:n steht der Fremdschlüssel gewöhnlich auf der n-Seite
Eine n:m-Beziehung benötigt bei relationaler Umsetzung eine Zwischentabelle

Erste und zweite Normalform

Die erste Normalform verlangt im hier verwendeten Modell einzelne Werte pro Feld und keine Wiederholungsgruppen. Speichere mehrere Artikelpositionen als eigene Zeilen statt als kommagetrennte Liste.

Für die zweite Normalform müssen zusätzlich alle Nichtschlüsselattribute vollständig von jedem Kandidatenschlüssel abhängen. Bei einem zusammengesetzten Schlüssel dürfen sie nicht nur von einem Teil abhängen. Ein Kandidatenschlüssel ist eine minimale Attributkombination, die Datensätze eindeutig identifiziert.

1NF: einzelne Werte statt Artikellisten
2NF: keine partielle Abhängigkeit eines Nichtschlüsselattributs von einem Kandidatenschlüssel
Ein künstlicher ID-Schlüssel beseitigt fachliche Abhängigkeiten nicht automatisch

Dritte Normalform und Änderungsanomalien

Im üblichen Lehrmodell entfernt die dritte Normalform zusätzlich transitive Abhängigkeiten von Nichtschlüsselattributen vom Schlüssel. Hängt der Kundenname von der Kunden-ID ab, gehört er in die Kundentabelle statt wiederholt in jede Bestellung.

So vermeidest du widersprüchliche Änderungen, den Verlust von Stammdaten beim Löschen einer Bestellung und die Notwendigkeit einer Bestellung, nur um einen Kunden anzulegen. Historische Werte wie der vereinbarte Positionspreis können bewusst zusätzlich gespeichert werden.

Stammdaten und Vorgänge trennen
Abhängigkeiten aus Geschäftsregeln ableiten
Historische Preise sind nicht automatisch ein Modellierungsfehler

Durchgerechnetes Beispiel

Eine Bestellung mit mehreren Artikeln

Eine Bestellung enthält mehrere Artikel; derselbe Artikel kann in vielen Bestellungen vorkommen.

01 Modelliere Bestellung und Artikel als eigene Tabellen.
02 Füge Position mit bestellung_id, artikel_id und menge hinzu.
03 Wenn je Bestellung jeder Artikel nur einmal vorkommt, ist (bestellung_id, artikel_id) ein möglicher zusammengesetzter Schlüssel.

Ergebnis / Position löst die n:m-Beziehung auf. Bei mehrfachen Positionen desselben Artikels brauchst du etwa eine Positionsnummer.

Durchgerechnetes Beispiel

Kundennamen aus Bestellungen auslagern

Bestellung(id, kunde_id, kundenname) speichert den aktuellen Namen mehrfach. Jeder Kunde hat genau einen aktuellen Namen.

01 Es gilt id → kunde_id und kunde_id → kundenname.
02 Lege Kunde(id, name) an und speichere jeden Namen einmal.
03 Bestellung(id, kunde_id) verweist mit dem Fremdschlüssel auf Kunde.

Ergebnis / Die transitive Abhängigkeit ist entfernt; eine Namensänderung erfolgt am Kundenstammsatz.

Beispiel verstanden?

Jetzt in etwa 5 Minuten selbst anwenden

Auf einen Blick
Normalform	Leitfrage
1NF	Enthält jedes Feld einen einzelnen Wert?
2NF	Hängt jedes Nichtschlüsselattribut vom ganzen Kandidatenschlüssel ab?
3NF	Gibt es transitive Abhängigkeiten über Nichtschlüsselattribute?

Typische Fehler vermeiden

Kardinalitäten werden aus Anforderungen abgeleitet, nicht aus zufälligen Beispieldaten.
Ein Primärschlüssel muss nicht immer aus genau einer Spalte bestehen.
Normalisierung bedeutet nicht, historische Geschäftswerte nachträglich zu verändern.

Kurz erklärt

Häufige Fragen

Was ist eine Änderungsanomalie?

Derselbe Sachverhalt wird mehrfach gespeichert und nur an einigen Stellen geändert. Dadurch entstehen widersprüchliche Daten.

Braucht jede n:m-Beziehung eine eigene Tabelle?

Bei der üblichen relationalen Umsetzung ja. Die Zwischentabelle enthält die Verweise und gegebenenfalls Beziehungsattribute wie eine Menge.

Fachliche Referenz: Microsoft Learn: Normalisierung von Datenbanken. Die Erklärungen und Aufgaben auf dieser Seite sind eigenständig formuliert.

Weiterlernen

Weitere Prüfungsthemen

Thementraining starten