ER-Diagramm.

Ein Entity-Relationship-Diagramm (ER-Diagramm) modelliert welche Daten du speicherst und wie sie zusammenhängen, BEVOR du Tabellen baust. Die zentralen Bausteine sind Entitäten (Dinge wie Student, Vorlesung), Beziehungen (Student belegt Vorlesung) und Attribute (Name, Matrikelnummer).

Was du in der Klausur können musst:

• Entität: ein Ding über das du Daten speicherst, später eine Tabelle
• Beziehung: wie zwei Entitäten verknüpft sind (z.B. "belegt", "lehrt")
• Attribut: Eigenschaft einer Entität, später eine Spalte
• Primärschlüssel: eindeutiger Identifikator, in der Notation unterstrichen
• Kardinalität: 1:1, 1:N, N:M, beschreibt wie viele Entitäten zur Beziehung gehören

In Klausuren ist die Standard-Aufgabe: gegeben ein Sachverhalt in Worten, zeichne das ER-Diagramm. Plus oft die Folge-Aufgabe: übersetze das Diagramm in Tabellen. Bei N:M-Beziehungen brauchst du eine Hilfstabelle mit beiden Fremdschlüsseln, das ist die häufigste Falle.

Das Problem

Bevor du eine Datenbank baust, musst du wissen welche Daten du speicherst und wie sie zusammenhängen.

Beispiel: eine Uni-DB.

• Studierende haben Name, Matrikel-Nr., Geburtsdatum, ...
• Vorlesungen haben Titel, Dozent, ECTS, Semester, ...
• Studierende belegen Vorlesungen, eine zentrale Beziehung

Wie zeichnest du das? Mit dem Entity-Relationship-Modell (ER).

Ein ER-Diagramm ist ein Konzept-Modell deiner Daten, VOR der Implementierung. Es zeigt Entitäten (Dinge) und Beziehungen (zwischen Dingen).

Die drei Bausteine

1. Entität (Entity)

Ein Ding mit Eigenschaften, das du speichern willst. Im Diagramm: Rechteck.

┌──────────────┐
│   Studi      │
└──────────────┘

Beispiele: Studi, Vorlesung, Klausur, Dozent.

2. Attribut

Eine Eigenschaft der Entität. Im Diagramm: Oval (klassisch) oder als Spalten-Liste in der Box (moderne Notation).

Studi
├─ id        (Primärschlüssel)
├─ name
├─ matrikel
└─ geburtsdatum

Spezielle Markierungen:

• Schlüssel-Attribut (Primärschlüssel) → unterstrichen oder mit 🔑
• Mehrwertig (z.B. mehrere Telefonnummern) → doppeltes Oval
• Abgeleitet (z.B. Alter aus Geburtsdatum) → gestricheltes Oval

3. Beziehung (Relationship)

Eine Verbindung zwischen zwei Entitäten. Im Diagramm: Raute in der Mitte einer Linie.

┌──────┐    ◇        ┌────────────┐
│ Studi│────hat──────│ Studienauswei│
└──────┘             └────────────┘

Beziehungen sind oft Verben: "hat", "belegt", "schreibt", "lehrt".

Kardinalitäten, die wichtigste Konzept

Eine Beziehung hat eine Kardinalität: wieviele Entitäten auf jeder Seite mitspielen können.

1:1, eins zu eins

Studi  ─1─◇─1─  Studienausweis

Jeder Studi hat genau einen Ausweis, jeder Ausweis gehört genau einem Studi.

In der DB: zusätzliche Spalte mit FK auf der optionalen/abhängigen Seite, mit UNIQUE-Constraint. NOT NULL ergänzen, wenn jeder Datensatz dieser Seite zwingend einen Partner haben muss.

CREATE TABLE studierende (
    id INT PRIMARY KEY,
    name VARCHAR(50)
);

CREATE TABLE ausweis (
    id INT PRIMARY KEY,
    studi_id INT UNIQUE NOT NULL,  -- 1:1 erzwingt UNIQUE; NOT NULL = jeder Ausweis hat genau einen Studi
    nummer VARCHAR(20),
    FOREIGN KEY (studi_id) REFERENCES studierende(id)
);

Hinweis: UNIQUE garantiert: jeder Studi hat höchstens einen Ausweis. NOT NULL garantiert: jeder Ausweis gehört einem Studi. Echte beidseitige Pflichtteilnahme ("jeder Studi muss einen Ausweis haben") ist mit reinen Foreign-Key-Constraints allein nicht vollständig erzwingbar, das verlangt Trigger oder eine zusammengelegte Tabelle.

Faustregel: 1:1 ist selten in der Praxis, oft kann man die zwei Tabellen zu einer zusammenfassen. Wenn man's trennt, dann meist aus Performance-Gründen oder weil die zweite Entität optional ist.

1:n, eins zu n

Dozent  ─1─◇─n─  Vorlesung

Ein Dozent hält mehrere Vorlesungen, jede Vorlesung hat genau einen Dozenten.

In der DB: FK auf der n-Seite.

CREATE TABLE dozent (
    id INT PRIMARY KEY,
    name VARCHAR(50)
);

CREATE TABLE vorlesung (
    id INT PRIMARY KEY,
    titel VARCHAR(100),
    dozent_id INT,             -- FK auf der n-Seite
    FOREIGN KEY (dozent_id) REFERENCES dozent(id)
);

Häufigster Beziehungstyp in der Praxis. Bestellung → Kunde, Post → Autor, Mitarbeiter → Abteilung, fast immer 1:n.

n:m, viele zu viele

Studi  ─n─◇─m─  Vorlesung

Ein Studi belegt mehrere Vorlesungen, jede Vorlesung wird von mehreren Studis belegt.

Hier wird's kniffelig: relationale DBs können n:m NICHT direkt abbilden. Du brauchst eine Zwischentabelle (Junction Table, Verknüpfungstabelle).

CREATE TABLE studierende (
    id INT PRIMARY KEY,
    name VARCHAR(50)
);

CREATE TABLE vorlesung (
    id INT PRIMARY KEY,
    titel VARCHAR(100)
);

-- Junction Table für die n:m-Beziehung
CREATE TABLE belegung (
    studi_id INT,
    vorlesung_id INT,
    semester VARCHAR(10),       -- ggf. zusätzliche Beziehungs-Attribute
    PRIMARY KEY (studi_id, vorlesung_id),    -- Composite PK (Standardfall)
    FOREIGN KEY (studi_id) REFERENCES studierende(id),
    FOREIGN KEY (vorlesung_id) REFERENCES vorlesung(id)
);
-- Achtung: dieser PK verbietet, dass derselbe Studi dieselbe Vorlesung
-- in mehreren Semestern belegt. Wenn das fachlich möglich sein soll
-- (z.B. zweiter Versuch), den PK auf (studi_id, vorlesung_id, semester)
-- erweitern oder einen Surrogate-Key plus Unique-Constraint nutzen.

Klausur-Klassiker: bei n:m IMMER an die Zwischentabelle denken. PK = beide FKs zusammen (Composite). Optional: zusätzliche Beziehungs-Attribute (z.B. "Note", "Semester").

ER-Diagramm zu Tabellen, die Übersetzungs-Regeln

Klausur-Standard. Aus einem ER-Diagramm leitest du systematisch die Tabellen ab:

Schritt 1, Jede Entität wird eine Tabelle

ER:  ┌──────┐         SQL:  CREATE TABLE studi (
     │ Studi│                   id INT PRIMARY KEY,
     ├──id──┤                   name VARCHAR(50)
     │ name │               );
     └──────┘

Schritt 2, Schlüssel-Attribute werden Primary Keys

Wenn id markiert ist (🔑 oder unterstrichen) → PRIMARY KEY.

Schritt 3, 1:1 und 1:n als Foreign Key

Bei 1:1 und 1:n brauchst du KEINE neue Tabelle.

• 1:1: FK in einer der beiden Tabellen, mit UNIQUE
• 1:n: FK auf der n-Seite

Beziehung: Dozent 1:n Vorlesung
→ ALTER TABLE vorlesung ADD COLUMN dozent_id INT;
→ ALTER TABLE vorlesung ADD FOREIGN KEY (dozent_id) REFERENCES dozent(id);

Schritt 4, n:m als Junction Table

Bei n:m brauchst du eine dritte Tabelle:

ER: Studi n:m Vorlesung
→ CREATE TABLE belegung (
       studi_id INT REFERENCES studierende(id),
       vorlesung_id INT REFERENCES vorlesung(id),
       PRIMARY KEY (studi_id, vorlesung_id)
   );

Schritt 5, Mehrwertige Attribute als eigene Tabelle

ER: Studi hat mehrere Telefonnummern (mehrwertiges Attribut)
→ CREATE TABLE studi_telefon (
       studi_id INT,
       nummer VARCHAR(20),
       PRIMARY KEY (studi_id, nummer),
       FOREIGN KEY (studi_id) REFERENCES studierende(id)
   );

Schwache Entitäten

Manchmal hat eine Entität keine eigene Identität ohne ihre "Eltern"-Entität.

Klausurversuch, gehört einer Klausur, identifiziert über (klausur_id, versuch_nr)

Im Diagramm: doppelter Rahmen. In der DB: Composite Primary Key, ein Teil davon ist FK auf die "starke" Entität.

Klausur-Tricks

Trick 1, Die drei Beziehungs-Arten auswendig:

• 1:1 → FK in einer der zwei Tabellen mit UNIQUE
• 1:n → FK auf der n-Seite
• n:m → Junction Table, Standardfall mit Composite PK aus beiden FKs

Trick 2, Faustregel beim Design: Substantive werden Entitäten, Verben werden Beziehungen.

"Studierende belegen Vorlesungen"
 └Entität─┘   └Beziehung─┘  └Entität─┘

Trick 3, n:m kann Beziehungs-Attribute haben: bei "Studi belegt Vorlesung" könnte die Note ein Attribut der Beziehung sein. In der Junction-Table ergänzen.

Trick 4, Min-Max-Notation: manche Klausuren nutzen (min, max) statt 1:n.

Studi (1,*) ─belegt─ (0,*) Vorlesung

Bedeutet: jeder Studi belegt mind. 1 Vorlesung (Pflicht), Vorlesungen können 0 oder mehr Studis haben.

Trick 5, Crow's Foot Notation: andere Schreibweise mit Krähenfuß-Symbolen am Linien-Ende.

─||──┘<  (= 1, viele), entspricht 1:n

Trick 6, IS-A-Beziehung (Generalisierung/Spezialisierung): wenn eine Entität eine Spezialisierung einer anderen ist.

Person
  ↑
  ├─ Studi (mit matrikel)
  └─ Mitarbeiter (mit gehalt)

Bei IS-A zusätzlich klären: disjunkt (eine Person ist Studi ODER Mitarbeiter) oder überlappend (kann beides sein), und vollständig (jede Person ist Studi oder Mitarbeiter) oder teilweise (es darf reine Personen geben). Drei Umsetzungs-Varianten:

• Class Table Inheritance: gemeinsame Person-Tabelle + spezialisierte Tabellen mit FK auf Person
• Single Table Inheritance: eine Tabelle mit allen Spalten + Type-Discriminator
• Concrete Table Inheritance: nur die spezialisierten Tabellen, keine Person-Basis-Tabelle

Trick 7, n:m mit Zeit-Komponente: bei "Studi belegt Vorlesung" musst du oft wann speichern (Semester). Wird Attribut der Junction-Table.

Trick 8, Composite PK in Junction: PRIMARY KEY (studi_id, vorlesung_id) verhindert dass derselbe Studi dieselbe Vorlesung doppelt belegt.

Trick 9, Ternäre Beziehung: 3-stellig, z.B. "Lieferant LIEFERT Produkt für Kunde". Junction mit 3 FKs.

Trick 10, Null vs. nicht-existent: Optionale Beziehung (0..1 oder 0..n) → FK darf NULL sein. Pflicht-Beziehung (1..1 oder 1..n) → FK NOT NULL.

Wo brauchst du ER-Diagramme?

• DB-Design: vor jeder neuen DB überlegen, wie die Daten strukturiert sind
• Klausuren: praktisch JEDE DBMS-Klausur hat eine Modellierungs-Aufgabe
• Software-Architektur: Domain Modeling in DDD beruht auf ER-Konzepten
• Refactoring: bestehende DBs verstehen und dokumentieren
• API-Design: Resource-Modelle in REST-APIs sind im Kern ER-Diagramme

Faustregel: bevor du CREATE TABLE schreibst, zeichne ein ER-Diagramm. 10 Minuten Diagramm spart 10 Stunden Refactoring.

ER-Diagramm-Lab

Wähle eine Kardinalität (1:1, 1:n, n:m) und sieh:

• Das ER-Diagramm mit zwei Entitäten und der gewählten Beziehung
• Die resultierende Tabellen-Struktur mit Primary Keys (🔑) und Foreign Keys (↗)
• Bei n:m: die Junction-Table wird automatisch hinzugefügt (in accent markiert)

Probier folgendes:

• 1:1 → Studi ↔ Ausweis: 2 Tabellen, FK mit UNIQUE-Constraint
• 1:n → Dozent ↔ Vorlesung: 2 Tabellen, FK auf der n-Seite
• n:m → Studi ↔ Vorlesung: 3 Tabellen mit Junction "belegung", Composite PK aus zwei FKs

Beobachte wie sich die Anzahl der Tabellen ändert, n:m braucht IMMER eine zusätzliche Tabelle.

Faustregel zum Mitnehmen: 1:1 und 1:n bleiben in 2 Tabellen mit FK · n:m braucht 3 Tabellen mit Junction-Table. Composite PK in der Junction verhindert Duplikate.