⚠ Hinweis zur Datenqualität: Die Daten dieser Statistik wurden mithilfe von KI analysiert und ausgewertet. Die Seite selbst wurde größtenteils von KI erstellt. Trotz sorgfältiger Prüfung können einzelne Einträge fehlerhaft oder unvollständig sein. Im Zweifelsfall mit den offiziellen Prüfungsunterlagen überprüfen.
abitur-elite-code/ Wiki/ ER-Überführung

ER-Diagramm → Relationales Modell: Abitur-Regelwerk

Vollständiges Regelwerk zur Überführung von ER-Diagrammen in das relationale Modell und zur Normalisierung bis 3NF — abgeleitet aus den offiziellen Abitur-Lösungen 2023–2025 (Hessen).

ABI 2023 A ABI 2023 B ABI 2023 C ABI 2024 A ABI 2024 B ABI 2025 A ABI 2025 B

0 — Legende & Notation

Schreibweisen, die in diesem Dokument und im Abitur verwendet werden
SymbolBedeutungBeispiel
PK Primärschlüssel — wird im Abitur unterstrichen mID
FK# Fremdschlüssel — wird im Abitur mit # markiert bid#
[1,n] Multiplizität (eckige Klammern — Abitur-Standard) [0,m]–[1,n]
Im Abitur wird der Primärschlüssel immer als erstes Attribut der Relation geschrieben und unterstrichen. Fremdschlüssel stehen am Ende der Attributliste, direkt vor der schließenden Klammer.

1 — Entitäten übernehmen

Jede Entität des ER-Diagramms wird zu einer eigenen Relation
Regel 1.1 — Jede Entität wird zur Relation
Jede Entität aus dem ER-Diagramm wird zu einer eigenen Tabelle (Relation). Der Primärschlüssel der Entität wird zum Primärschlüssel der Relation.
Regel 1.2 — Zusammengesetzte Attribute aufteilen (3NF)
Zusammengesetzte Attribute (z.B. Adresse, Name) werden in der 3NF in ihre atomaren Bestandteile aufgeteilt.

Typische Abitur-Beispiele:
· name → nachname, vorname (ABI 2025 B, 2023 B)
· adresse → strasse, plz, ort (ABI 2024 A)
· vor- und nachname → name, vorname (ABI 2025 A)
⚠ Häufiger Fehler: Das Attribut name nicht aufzuteilen. Im Abitur wird die Aufspaltung in nachname und vorname fast immer erwartet — wird das Namensattribut im ER-Diagramm als zusammengesetzt angedeutet, muss es geteilt werden.

2 — Assoziationen überführen

Die Kardinalität bestimmt, wie jede Assoziation im relationalen Modell umgesetzt wird
KardinalitätBezeichnungUmsetzung
[1,1] – [0,n] oder [1,n] 1:N Beziehung FK der „1"-Seite in die Relation der „N"-Seite eintragen
[0,m] – [0,n] oder ähnlich M:N Beziehung Neue Zwischentabelle mit beiden FKs als kombiniertem PK
[1,1] – [1,1] 1:1 Beziehung FK in die Relation mit größerer Abhängigkeit (seltener Fall im Abitur)

2.1 1:N Beziehung → Fremdschlüssel

Der FK wandert zur „Viele"-Seite
Bei einer 1:N-Beziehung wird der Primärschlüssel der „1"-Seite als Fremdschlüssel in die Relation der „N"-Seite aufgenommen. Keine neue Tabelle nötig.
Kunde ──[1,1]── bucht ──[0,n]── Ticket → Ticket(tid, …, kid#)
-- ABI 2024 B: Kunde bucht Ticket [1:N] Kunde (kid, vorname, name, adresse, telefon, email) Ticket (tid, status, sitzplatz, kid#, fid#)

2.2 M:N Beziehung → Zwischentabelle

Neue Relation mit zusammengesetztem PK aus beiden FKs
Bei einer M:N-Beziehung entsteht eine neue Zwischenrelation. Ihr Primärschlüssel ist die Kombination der beiden Fremdschlüssel. Benennung: entweder ein sprechender Verbname (traegt) oder die Tabellennamen kombiniert (Mitarbeiter_Bestellung).
Nutzer ──[0,n]── likes ──[0,m]── Beitrag → NutzerLikesBeitrag(bN#, bId#)
-- ABI 2023 A: Nutzer likes Beitrag [M:N] NutzerLikesBeitrag (benutzerName#, beitragid#, zeitstempel) -- ABI 2025 A: Mitarbeiter beteiligt Bestellung [M:N] Mitarbeiter_Bestellung (mID#, bID#) -- ABI 2024 A: Teilnahme in Kategorie [M:N, mit Attribut] Teilnahme_Kategorie (tID#, kID#, bewertung)
💡 Attribute an M:N-Beziehungen (z.B. bewertung, zeitstempel) kommen als normale Attribute in die Zwischentabelle — sie sind aber kein Teil des zusammengesetzten PKs.

2.3 Mehrere FKs in einer Relation

Eine Entität kann mehrere 1:N-Beziehungen haben
Wenn eine Relation zu mehreren anderen in einer 1:N-Beziehung steht, bekommt sie entsprechend mehrere Fremdschlüssel.
-- ABI 2025 B: Kauf steht mit Bändchen, Getränkestand und Getränk je in 1:N Kauf (kid, datum, uhrzeit, anzahlGetraenke, bid#, gsid#, gid#)

2.4 Dieselbe Relation als FK zweimal referenzieren

Zwei unterschiedliche Rollen → zwei FK-Attribute mit verschiedenen Namen
Wenn eine Relation zweimal zur gleichen Entität in Beziehung steht (z.B. Auftrag → Adresse als von und nach), werden zwei FKs mit unterschiedlichen, sprechenden Namen vergeben.
-- ABI 2023 B: Auftrag hat zwei Adressen (von / nach) Auftrag (auftragNr, start, ende, eID#, von#, nach#)

3 — Beziehungen mit Attributen

Wenn eine Assoziation selbst Attribute trägt, kommen diese in die Zwischentabelle
Regel 3.1 — Attribute einer Beziehung gehören in die Zwischentabelle
Wenn eine Assoziation selbst Attribute trägt (z.B. von, bis bei trägt), werden diese in die entstehende Zwischentabelle aufgenommen. Bei 1:N trägt die FK-Relation die Beziehungsattribute.
-- ABI 2025 B: trägt(von, bis) → M:N zwischen Person und Bändchen traegt (pid#, bid#, von, bis) -- ABI 2024 A: in(bewertung) → M:N zwischen Teilnahme und Kategorie Teilnahme_Kategorie (tID#, kID#, bewertung) -- ABI 2025 A: entnimmt(datum, anzGenutzt, anzAbgelaufen) → M:N zwischen Lager und Artikel Lager_Artikel (datum, anzGenutzt, anzAbgelaufen, lID#, aID#)
Sonderfall ABI 2025 A (Lager_Artikel): Hier stehen die Beziehungsattribute vor 2 der Primärschlüssel — eine Ausnahme. Im Normalfall stehen die FKs am Ende. Orientiere dich an der offiziellen Musterlösung bzw. an der logischen Bedeutung.

4 — 3. Normalform sicherstellen

Drei Stufen — jede baut auf der vorherigen auf
Regel 4.1 — Erste Normalform (1NF)
Alle Attributwerte müssen atomar sein — nicht weiter zerlegbar, keine Wiederholungsgruppen. → Zusammengesetzte Attribute aufteilen (→ Regel 1.2).
Regel 4.2 — Zweite Normalform (2NF)
Jedes Nicht-Schlüssel-Attribut muss vom gesamten Primärschlüssel abhängen. Relevant bei zusammengesetztem PK (Zwischentabellen): alle Attribute müssen von beiden FKs gemeinsam abhängen, nicht nur von einem.
Regel 4.3 — Dritte Normalform (3NF)
Kein Nicht-Schlüssel-Attribut darf transitiv von einem anderen Nicht-Schlüssel-Attribut abhängen. Klassisches Beispiel: plz → ort — wenn die PLZ den Ort bestimmt, gehört beides in eine eigene Tabelle.

Abitur-Praxis: Transitive Abhängigkeiten innerhalb einer Entität werden manchmal toleriert — die 3NF wird hauptsächlich durch korrekte FK-Verteilung und M:N-Auflösung geprüft.

5 — Spezialfälle aus dem Abitur

Sonderfälle, die in offiziellen Aufgabenvorschlägen vorgekommen sind

5.1 Feste Kardinalität [2,2], [2,3] etc.

Exakt n Entitäten sind beteiligt → n FK-Attribute
Wenn eine Kardinalität genau eine bestimmte Anzahl erzwingt (z.B. ein Team besteht aus exakt 2 Spielern), werden mehrere FK-Attribute mit unterschiedlichen Namen in die Relation aufgenommen.
-- ABI 2023 C: Spieler [2,2] gehört_zu Team → zwei FK-Attribute Team (teamID, bewertMod, sNr1#, sNr2#)

5.2 Assoziation als eigene Entität (Assoziationsklasse)

Die Assoziation hat einen eigenen PK → FK auf beide Partnerentitäten
Wenn die Assoziation im ER-Diagramm selbst eine eigene Entität mit eigenem Schlüssel ist (z.B. Teilnahme), bekommt sie eigene Fremdschlüssel auf beide beteiligten Entitäten.
-- ABI 2024 A: Teilnahme als eigene Entität mit FK auf Chor und Wettbewerb Teilnahme (tID, anzahlPers, ankunft, abfahrt, cID#, wID#)

5.3 Benennung der Zwischentabellen

Beide Benennungsschemata sind im Abitur akzeptiert
· Verb/Aktion: traegt, NimmtTeil, NutzerLikesBeitrag
· Tabellen kombiniert: Mitarbeiter_Bestellung, Bestellung_Lager, Lager_Artikel, Teilnahme_Kategorie

6 — Vollständige Schritt-für-Schritt-Anleitung

Das systematische Vorgehen für jede Aufgabe zur ER-Überführung
  1. Alle Entitäten notieren. Jede Entität wird zur Relation. PK als erstes Attribut (unterstrichen).
  2. Zusammengesetzte Attribute aufteilen — Name → nachname, vorname; Adresse → strasse, plz, ort.
  3. Assoziationen durchgehen — für jede Assoziation die Kardinalität bestimmen und dem richtigen Fall zuordnen.
  4. 1:N → FK setzen. Der PK der „1"-Seite wandert als FK# in die Relation der „N"-Seite. Immer ans Ende der Attributliste.
  5. M:N → Zwischentabelle erstellen. Neue Relation mit zusammengesetztem PK aus beiden FKs.
  6. Beziehungsattribute einbauen. Attribute an Assoziationen kommen in die Zwischentabelle (M:N) oder in die FK-tragende Relation (1:N).
  7. Feste Kardinalitäten [2,2] prüfen — ggf. mehrere FK-Attribute verwenden.
  8. 3NF prüfen: Gibt es transitive Abhängigkeiten? Falls ja, auslagern.

7 — Schnellreferenz-Tabelle

Komprimierte Übersicht aller Regeltypen mit Abitur-Belegen
Situation im ER-DiagrammMaßnahmeAbitur-Beleg
[1,1]–[0,n] oder [1,n] FK der 1-Seite in die N-Relation Ticket erhält kid# (2024 B)
[0,n]–[0,m] oder [1,n]–[0,m] Neue Zwischentabelle Mitarbeiter_Bestellung (2025 A)
Assoziation hat Attribute Attribute in Zwischentabelle traegt(von, bis) → traegt-Relation
Name / Adresse als Attribut Aufteilen in Einzelattribute (1NF) name → nachname, vorname
Kardinalität [2,2] Mehrere FK-Attribute in Relation Team: sNr1#, sNr2# (2023 C)
Doppelte Referenz auf gleiche Entität Zwei FKs mit verschiedenen Namen Auftrag: von#, nach# (2023 B)
Assoziationsklasse mit eigenem PK Entität erhält FK auf beide Partner Teilnahme: cID#, wID# (2024 A)

8 — Vollständiges Beispiel: ABI 2025 A

Komplette Durchführung — von der ER-Beschreibung bis zum normalisierten relationalen Modell (3NF)
Aufgabenstellung (vereinfacht): Gegeben ist ein ER-Diagramm mit den Entitäten Mitarbeiter, Bestellung, Position, Artikel und Lager. Überführe das Diagramm in ein vollständig normalisiertes relationales Modell (3NF).

8.1 ER-Ausgangsbeschreibung

⬤ Entitäten (nicht normalisiert)
Mitarbeiter(mID, vor- und nachname) Bestellung(bID, datum) Position(pID, menge, ablaufdatum) Artikel(aID, bezeichnung, preis) Lager(lID, standort)
⬤ Assoziationen
  • Mitarbeiter [1,n] –beteiligt– [0,m] Bestellung
  • Bestellung [0,m] –füllt_auf– [0,n] Lager
  • Bestellung [1,1] –enthält– [1,n] Position
  • Position [0,n] –bezieht_sich_auf– [1,1] Artikel
  • Lager [0,n] –entnimmt– [0,m] Artikel
Beziehungsattribute:
entnimmt → datum, anzGenutzt, anzAbgelaufen

8.2 PlantUML-Code für das ER-Diagramm

Den folgenden Code kannst du auf plantuml.com oder einem lokalen PlantUML-Tool einfügen, um das ER-Diagramm als SVG/PNG zu exportieren.
Chen-Notation ER-Diagramm — Entitäten, Beziehungen und Attribute aus ABI 2025 A.

8.3 Schritt-für-Schritt Überführung

Schritt 1 Entitäten übernehmen & zusammengesetzte Attribute aufteilen
-- Regel 1.1: Jede Entität → eigene Relation -- Regel 1.2: "vor- und nachname" → zwei atomare Attribute (3NF / 1NF) Mitarbeiter (mID, name, vorname) ← "vor- und nachname" aufgeteilt! Bestellung (bID, datum) Position (pID, menge, ablaufdatum) Artikel (aID, bezeichnung, preis) Lager (lID, standort)
Schritt 2 Assoziation: Mitarbeiter [1,n]–beteiligt–[0,m] Bestellung → M:N
-- Regel 2.2: M:N → neue Zwischentabelle -- [1,n]:[0,m] bedeutet: ein Mitarbeiter ist an 1 oder mehr Bestellungen beteiligt -- eine Bestellung kann 0 oder mehr Mitarbeiter haben Mitarbeiter_Bestellung (mID#, bID#)
Schritt 3 Assoziation: Bestellung [0,m]–füllt_auf–[0,n] Lager → M:N
-- Regel 2.2: M:N → neue Zwischentabelle Bestellung_Lager (bID#, lID#)
Schritt 4 Assoziation: Bestellung [1,1]–enthält–[1,n] Position → 1:N
-- Regel 2.1: 1:N → FK der "1"-Seite in die "N"-Seite -- Bestellung (1,1) ist die "1"-Seite → bID# wandert in Relation Position (pID, menge, ablaufdatum, bID#)
Schritt 5 Assoziation: Position [0,n]–bezieht_sich_auf–[1,1] Artikel → 1:N
-- Regel 2.1: 1:N → FK der "1"-Seite (Artikel) in die "N"-Seite (Position) -- Artikel (1,1) ist die "1"-Seite → aID# wandert in Relation Position (pID, menge, ablaufdatum, aID#, bID#) ← beide FKs jetzt in Position
Schritt 6 Assoziation: Lager [0,n]–entnimmt–[0,m] Artikel → M:N mit Attributen
-- Regel 2.2 + Regel 3.1: M:N mit Beziehungsattributen -- entnimmt(datum, anzGenutzt, anzAbgelaufen) → kommen als Attribute in die Zwischentabelle -- SONDERFALL ABI 2025 A: Attribute stehen VOR den FKs (Ausnahme, folge Musterlösung) Lager_Artikel (datum, anzGenutzt, anzAbgelaufen, lID#, aID#)

8.4 Ergebnis — Normalisiertes relationales Modell (3NF)

✓ Vollständiges relationales Modell (Musterlösung ABI 2025 A)
Mitarbeiter (mID, name, vorname) Bestellung (bID, datum) Mitarbeiter_Bestellung (mID#, bID#) Position (pID, menge, ablaufdatum, aID#, bID#) Artikel (aID, bezeichnung, preis) Lager (lID, standort) Bestellung_Lager (bID#, lID#) Lager_Artikel (datum, anzGenutzt, anzAbgelaufen, lID#, aID#)