Alle Tabs der Lerneinheit (Erklärung · Stepper · Praxis-Übung · Klausur-Quiz) als durchgehender Text. Ideal zum Wiederholen vor der Klausur, und für Suchmaschinen wie Google, Bing und KI-Suche (ChatGPT, Perplexity).
Erklärung
Du hast ein ER-Diagramm gezeichnet, wie wird daraus ein konkretes Datenbank-Schema mit Tabellen, Primärschlüsseln und Fremdschlüsseln? Genau diese Transformation ist Klausur-Pflicht in jedem WInf-DB-Modul (12/12 implizit). Sie hat klare Regeln, wenn du sie kennst, bist du in 5 Minuten durch.
Wir gehen die 4 Transformations-Regeln systematisch durch.
Regel 1: Entität → Tabelle
Jede Entität wird eine Tabelle. Attribute werden Spalten, Schlüssel wird Primärschlüssel.
ER:
Studierende(MatrNr, Name, Semester)
Relational:
| Studierende |
|---|
| MatrNr (PK) |
| Name |
| Semester |
Direkt 1:1, kein Trick.
Regel 2: 1:N-Beziehung → Fremdschlüssel auf der N-Seite
Bei 1:N (eine Mutter, viele Kinder): füge der "vielen"-Seite einen Fremdschlüssel auf die "einer"-Seite hinzu. Keine neue Tabelle.
ER:
Abteilung 1 ──── N Mitarbeiter
Relational:
| Abteilung |
|---|
| AbtID (PK) |
| Name |
| Mitarbeiter |
|---|
| MitID (PK) |
| Vorname |
| AbtID (FK → Abteilung.AbtID) |
Mitarbeiter (N-Seite) bekommt den Fremdschlüssel. Würde es umgekehrt gehen? Theoretisch ja, aber jede Abteilung müsste alle ihre Mitarbeiter-IDs speichern, das ist nicht atomar (1NF-Verletzung).
Regel 3: N:M-Beziehung → Junction-Tabelle
Bei N:M (viele zu viele): drei Tabellen. Zwei für die Entitäten, eine Verknüpfungstabelle (Junction-Table / Assoziationstabelle) mit beiden Fremdschlüsseln als zusammengesetztem Primärschlüssel.
ER:
Studierende N ──── Belegungen ──── M Kurse
(mit Note)
Relational:
| Studierende |
|---|
| MatrNr (PK) |
| Name |
| Kurse |
|---|
| KursID (PK) |
| Titel |
| Belegungen |
|---|
| MatrNr (PK, FK → Stud) |
| KursID (PK, FK → Kurs) |
| Note |
Die Junction-Tabelle hat (MatrNr, KursID) als zusammengesetzten PK. Beziehungs-Attribute wie "Note" wandern in diese Tabelle (gehören weder zu Studi noch zu Kurs, sondern zur Belegung).
Regel 4: 1:1-Beziehung → FK auf einer Seite mit UNIQUE
Bei 1:1: wie 1:N, aber der Fremdschlüssel bekommt zusätzlich UNIQUE NOT NULL.
ER:
Person 1 ──── 1 Pass
Relational:
| Person |
|---|
| PersID (PK) |
| Name |
| Pass |
|---|
| PassNr (PK) |
| AusstDatum |
| PersID (FK, UNIQUE NOT NULL → Person.PersID) |
Welche Seite den FK bekommt, ist eine Design-Frage: meist die "schwächere" Entität (existiert nicht ohne die andere, hier der Pass).
Klausur-Klassiker: Beziehungs-Attribute
Attribute, die zu einer Beziehung gehören (nicht zu den Entitäten):
- 1:N: wandern zur N-Seite (in die FK-Tabelle).
- N:M: wandern in die Junction-Tabelle.
Beispiel: "Mitarbeiter arbeitet seit Datum in Abteilung" → seit_Datum ist Attribut der Beziehung, kommt in die Mitarbeiter-Tabelle (1:N) oder eine eigene Junction-Tabelle (wenn N:M).
Visualisierung
Wähle ein ER-Beispiel und sieh die Transformation Schritt für Schritt:
Interaktive Visualisierung
Interaktive Komponente: probiere sie im Topic-Player oben aus.
Klausur-Faustregeln
- 4 Regeln auswendig: Entität→Tabelle, 1:N→FK auf N-Seite, N:M→Junction, 1:1→FK+UNIQUE.
- Beziehungs-Attribute kommen dorthin, wo die Beziehung als Spalte/Tabelle landet.
- Junction-PK ist zusammengesetzt aus beiden FKs (Standardfall).
- Kardinalitäten genau lesen. 1:N und N:M unterscheiden sich nur durch ein Buchstaben, aber das ergibt komplett verschiedene Tabellen.
- Schwache Entitäten: existieren nicht ohne ihre Mutter, bekommen FK + Teil-PK aus der Mutter.
Typische Stolpersteine
1. N:M ohne Junction-Tabelle. Falsch, N:M-Beziehungen brauchen IMMER eine extra Tabelle. Klassiker-Fehler: zwei FKs in eine der Entitäten packen.
2. FK auf der falschen Seite bei 1:N. Der FK muss zur N-Seite (zur "vielen"). Sonst wäre der Spalten-Wert nicht atomar.
3. Beziehungs-Attribute vergessen. "Note" bei Belegung ist kein Studi-Attribut und kein Kurs-Attribut, sie ist ein Belegungs-Attribut und gehört in die Junction.
4. ISA-Hierarchie ignorieren. Wenn das ER eine Vererbungs-Beziehung hat (Person ← Studi, Person ← Mitarbeiter), gibt es 3 Umsetzungs-Varianten: Single Table, Class Table per ISA-Kind, oder Concrete Table. Klausur fragt oft nach der Vergleichs-Tabelle.
Stepper
ER → Relational Lab
Wähle ein ER-Diagramm und sieh die Transformation in 3 Schritten: Entitäten → 1:N-Beziehungen → N:M-Beziehungen.
Interaktive Visualisierung
Interaktive Komponente: probiere sie im Topic-Player oben aus.
Klausur-Tipp: Geh ER-Diagramme in dieser Reihenfolge durch: 1) Alle Entitäten als Tabelle. 2) Alle 1:N → FK auf N-Seite. 3) Alle N:M → Junction-Tabelle. 4) Alle 1:1 → FK+UNIQUE. 5) Beziehungs-Attribute zuordnen.
Praxis-Übung
ER → Relational, Praxis-Übung
6 Aufgaben zu den 4 Transformations-Regeln und typischen Klausur-Fallen.
Klausurfragen mit Lösungen (6)
- F1.Wie wird eine 1:N-Beziehung in Tabellen umgesetzt?
Antwort: Fremdschlüssel auf der N-Seite
Erklärung: Bei 1:N bekommt die N-Seite (die 'vielen') einen Fremdschlüssel auf die 1-Seite. Beispiel: Abteilung 1–N Mitarbeiter → Mitarbeiter-Tabelle bekommt eine Spalte AbtID (FK).
- F2.Wie wird eine N:M-Beziehung umgesetzt?
Antwort: Eine separate Junction-Tabelle mit beiden FKs als zusammengesetztem PK
Erklärung: N:M braucht IMMER eine separate Tabelle. Studi N–M Kurs → Tabelle Belegungen mit (MatrNr, KursID) als zusammengesetzter PK plus FK-Constraints auf beide Entitäten.
- F3.Wo kommt das Beziehungs-Attribut 'Note' (in Studi-belegt-Kurs) hin?
Antwort: In die Junction-Tabelle Belegungen
Erklärung: Note gehört zur Beziehung, nicht zur Entität. Wenn Beziehung als Junction-Tabelle umgesetzt wird (N:M), kommt Note dort hinein. Wäre es 1:N, käme Note auf die N-Seite (zusammen mit dem FK).
- F4.Bei einer 1:1-Beziehung Person–Pass müssen IMMER beide Tabellen einen FK aufeinander haben.
Antwort: Falsch
Erklärung: FALSCH. Ein FK auf einer Seite genügt, meist auf der 'schwächeren' Entität (Pass hängt von Person ab). Zusätzlich UNIQUE NOT NULL macht es zu echter 1:1. Beidseitige FKs erzeugen redundante Constraints.
Typ: Wahr/Falsch
- F5.Ordne den Beziehungstyp dem Transformations-Verfahren zu:
Zuordnungen:
- 1:N → FK auf der N-Seite
- N:M → Junction-Tabelle mit beiden FKs als PK
- 1:1 → FK auf einer Seite mit UNIQUE
- Entität → Eine Tabelle, Attribute als Spalten
Erklärung: Die 4 Standard-Regeln. In der Klausur einfach abarbeiten: erst alle Entitäten, dann pro Beziehung die passende Regel.
Typ: Zuordnung
- F6.Welche Tabelle braucht ein zusammengesetzter Primärschlüssel?
Antwort: Belegungen (Studi N–M Kurs)
Erklärung: Junction-Tabelle Belegungen hat PK = (MatrNr, KursID), zusammengesetzt aus beiden FKs. So wird Mehrfach-Belegung derselben Kombination verhindert (falls fachlich nicht erlaubt).
Klausur-Quiz
Klausurfragen mit Lösungen (6)
- F1.ER: Auto 1–1 Halterperson. Wie viele Tabellen sind nötig?
Antwort: 2 Tabellen
Erklärung: 1:1 → 2 Tabellen. FK auf einer Seite mit UNIQUE NOT NULL. Junction wäre erst bei N:M nötig.
- F2.ER: Kunde N–M Bestellung. Beziehungs-Attribut: Bestellnummer. Wohin?
Antwort: In die Junction-Tabelle Kunde-Bestellung
Erklärung: N:M braucht Junction. Beziehungs-Attribute (hier Bestellnummer) kommen in diese Junction. Wenn Bestellnummer eindeutig pro Bestellung sein soll, würde man sie als zusätzlichen Constraint anlegen.
- F3.Ein FK kann NULL sein, wenn die Beziehung optional ist (z.B. Mitarbeiter kann ohne Abteilung sein).
Antwort: Wahr
Erklärung: Wahr. NULL-FK = 'keine Beziehung'. Klausur-Achtung: NULL kompliziert NOT IN-Subqueries und Outer Joins. Bei Pflicht-Beziehung NOT NULL setzen.
Typ: Wahr/Falsch
- F4.Sortiere die ER → Relational-Transformations-Schritte:
Richtige Reihenfolge:
- Entitäten in Tabellen umwandeln
- 1:N-Beziehungen → FK auf N-Seite
- N:M-Beziehungen → Junction-Tabellen
- 1:1-Beziehungen → FK + UNIQUE
- Beziehungs-Attribute zuordnen
Erklärung: Schritt-für-Schritt-Standard: erst alle Entitäten, dann Beziehungen in der Reihenfolge ihrer Komplexität, am Ende die Beziehungs-Attribute richtig platzieren.
Typ: Reihenfolge
- F5.Bei einer ternären Beziehung Studi-Kurs-Dozent (N:M:N), wie viele Tabellen?
Antwort: 4 Tabellen
Erklärung: 4 Tabellen: 3 für die Entitäten (Studi/Kurs/Dozent) + 1 Junction-Tabelle (mit 3 FKs als zusammengesetzter PK). Generalisierung der N:M-Regel auf 3+ Entitäten.
- F6.Bei 1:N wandert der FK zur {{1}}-Seite. Bei N:M wird eine {{2}}-Tabelle erzeugt mit beiden FKs als {{3}}. Beziehungs-Attribute wandern in die Tabelle, in der die {{4}} dargestellt ist.
Lösungen pro Lücke:
- {{1}}: N / N- / vielen
- {{2}}: Junction / Verknüpfungs / Assoziations
- {{3}}: zusammengesetztem PK / zusammengesetzter PK / Composite PK / kombiniertem Schlüssel
- {{4}}: Beziehung
Erklärung: Pflicht-Klausur-Wissen für jede DB-Klausur: die 4 Standard-Regeln zusammengefasst.
Typ: Lückentext
