ERM & Relationenschreibweise#

Das ERM (Entity-Relationship-Modell) beschreibt Entitäten, Attribute und Beziehungen eines Datenbestands, bevor daraus per Relationenschreibweise die eigentlichen Datenbanktabellen abgeleitet werden.

Entity-Relationship-Modell (ERM) nach Chen#

Das ERM modelliert die Datenstruktur eines Systems vor der Datenbankimplementierung.

Notation (Chen-Notation)#

[Rechteck]        = Entität (Objekt/Ding der realen Welt)
(Oval)            = Attribut (Eigenschaft einer Entität)
<Raute>           = Beziehung (Relation zwischen Entitäten)
──────            = Verbindungslinie
(Oval, doppelt)   = Mehrwertiges Attribut
[Rechteck, doppelt] = Schwache Entität

Kardinalitäten#

Kardinalität	Bedeutung	Beispiel
1:1	Genau eine Entität A gehört zu genau einer Entität B	Person – Personalausweis
1:n	Eine Entität A gehört zu mehreren Entitäten B	Kunde – Bestellungen
n:m	Mehrere Entitäten A gehören zu mehreren Entitäten B	Schüler – Kurse

ERM-Beispiel: Bestellsystem#

(KundenNr)  (Name)  (E-Mail)
     │          │       │
     └──────[Kunde]─────┘
                │
                │  1
                │
             <bestellt>
                │
                │  n
                │
           [Bestellung]──── (BestellNr)
                │                │
                │                └── (Datum)
                │  n
                │
            <enthält>
                │
                │  m
                │
            [Produkt]──── (ProduktNr)
                               │
                               └── (Bezeichnung)
                               │
                               └── (Preis)

n:m-Beziehungen auflösen#

Eine n:m-Beziehung kann nicht direkt in eine Tabelle überführt werden → Auflösung durch Zwischentabelle:

VORHER (n:m – nicht implementierbar):
[Schüler] ──── n:m ──── [Kurs]

NACHHER (aufgelöst):
[Schüler] ──── 1:n ──── [Schüler_Kurs] ──── n:1 ──── [Kurs]
                              │
                         enthält PKs beider
                         Elterntabellen als FK

Relationenschreibweise#

Nach dem ERM wird jede Entität/Beziehung in Relationenschreibweise überführt:

Syntax: Tabellenname(PK, Attribut1, Attribut2, FK → Zieltabelle)

PK = Primary Key (Primärschlüssel, eindeutig, kein NULL) → unterstrichen
FK = Foreign Key (Fremdschlüssel, Verweis auf anderen PK) → kursiv oder mit →

Beispiel: Bestellsystem#

Kunde(<u>KundenNr</u>, Name, Email, Telefon)

Bestellung(<u>BestellNr</u>, Datum, Gesamtbetrag, KundenNr → Kunde)

Produkt(<u>ProduktNr</u>, Bezeichnung, Preis, Kategorie)

Bestellung_Produkt(<u>BestellNr → Bestellung</u>, <u>ProduktNr → Produkt</u>, Menge)

Die Zwischentabelle Bestellung_Produkt löst die n:m-Beziehung auf. Ihr zusammengesetzter PK besteht aus beiden Fremdschlüsseln.

Prüfungsbeispiel#

„Modelliere eine Bibliothek: Bücher können von mehreren Mitgliedern ausgeliehen werden, ein Mitglied kann mehrere Bücher ausleihen."

ERM: [Mitglied] ──n:m──< ausleiht >──n:m──[Buch]

Auflösung:

Mitglied(<u>MitgliedNr</u>, Name, Email)

Buch(<u>ISBN</u>, Titel, Autor, Erscheinungsjahr)

Ausleihe(<u>MitgliedNr → Mitglied</u>, <u>ISBN → Buch</u>, Ausleihdatum, Rückgabedatum)

Normalisierung (1NF, 2NF, 3NF)#

Die Normalisierung entfernt Redundanzen und Anomalien (Update-, Einfüge-, Löschanomalien) aus einem Relationenschema, indem sie es schrittweise in Normalformen überführt. Jede Normalform baut auf der vorherigen auf.

Normalform	Bedingung	Behebt
1NF	Jedes Attribut ist atomar (nicht weiter zerlegbar), keine Wiederholungsgruppen	Mehrfachwerte in einer Zelle
2NF	1NF und jedes Nicht-Schlüsselattribut hängt von allen Teilen des (zusammengesetzten) PK ab	Partielle Abhängigkeiten
3NF	2NF und kein Nicht-Schlüsselattribut hängt von einem anderen Nicht-Schlüsselattribut ab	Transitive Abhängigkeiten

Beispiel: Bestellungen (unnormalisiert → 3NF)#

Ausgangstabelle (verletzt 1NF — Mehrfachwerte):

Bestellung(BestellNr, KundenName, Produkte)
1001, "Meier", "Maus, Tastatur"

Nach 1NF (atomar, aber noch Redundanz):

Bestellposition(BestellNr, KundenName, ProduktNr, ProduktName, Preis)
1001, Meier, P1, Maus, 15€
1001, Meier, P2, Tastatur, 40€

Problem (2NF-Verletzung): PK ist (BestellNr, ProduktNr), aber KundenName hängt nur von BestellNr ab (partielle Abhängigkeit), und ProduktName/Preis hängen nur von ProduktNr ab.

Nach 2NF (aufgeteilt nach Abhängigkeit):

Bestellung(BestellNr, KundenName)
Produkt(ProduktNr, ProduktName, Preis)
Bestellposition(BestellNr → Bestellung, ProduktNr → Produkt, Menge)

Problem (3NF-Verletzung, falls vorhanden): Würde Bestellung z. B. auch KundenNr und KundenStadt enthalten, hinge KundenStadt transitiv über KundenNr von BestellNr ab, nicht direkt vom PK.

Nach 3NF (transitive Abhängigkeit aufgelöst):

Kunde(KundenNr, KundenName, KundenStadt)
Bestellung(BestellNr, KundenNr → Kunde)
Produkt(ProduktNr, ProduktName, Preis)
Bestellposition(BestellNr → Bestellung, ProduktNr → Produkt, Menge)

In der Praxis reicht meist die Prüfung auf 3NF. Merksatz: “Jedes Attribut hängt vom Schlüssel ab, vom ganzen Schlüssel und von nichts als dem Schlüssel.”

Selbsttest#

❓ Wie wird eine n:m-Beziehung zwischen zwei Entitäten in Tabellen umgesetzt?

❓ Welche Bedingung muss zusätzlich zur 1NF erfüllt sein, damit ein Relationenschema in der 2. Normalform (2NF) ist?

❓ Welche Symbole stehen in der Chen-Notation für eine Entität bzw. eine Beziehung?

❓ Welche Anomalie behebt die 3. Normalform (3NF)?

Siehe auch#

sql — SQL-DDL zur Umsetzung des Relationenschemas in echte Datenbanktabellen
softwaredokumentation — Das ERM ist Bestandteil der technischen Systemdokumentation
uml — UML-Klassendiagramme als Alternative zur ERM-Notation
dsgvo — DSGVO-Anforderungen bei der Modellierung personenbezogener Daten

Ressourcen#

Wikipedia: Entity-Relationship-Modell
Wikipedia: Relationales Datenbankmodell
Studyflix: ERM Entity Relationship Modell einfach erklärt
SimpleClub: Datenbank ERM Kardinalität auf YouTube suchen