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").
