Vom ER-Modell zum Datenbankschema

Das ER-Modell ist ein konzeptionelles Werkzeug – es beschreibt, was in der Datenbank stehen soll. Das Datenbankschema hingegen ist die konkrete Implementierung: welche Tabellen, welche Spalten, welche Datentypen, welche Schlüssel. Der Übergang vom einen zum anderen folgt klaren, fast mechanischen Regeln. Wer diese Regeln beherrscht, kann aus jedem ER-Diagramm in wenigen Minuten ein funktionierendes Schema ableiten – und genau das wird in der IHK-Prüfung verlangt.

In dieser Lektion gehen wir den Weg systematisch: Entitäten werden Tabellen, Attribute werden Spalten, Schlüsselattribute werden Primary Keys, und Beziehungen werden – je nach Kardinalität – entweder zu Fremdschlüssel-Spalten oder zu eigenen Verknüpfungstabellen. Am Ende steht fertiges SQL, das du in MySQL oder PostgreSQL ausführen könntest. Den genauen CREATE TABLE-Syntax vertieft der Kurs SQL-Grundlagen.

1) Der Transformator – fünf Schritte in der Animation

Klick durch die fünf Stufen und sieh, wie aus einem ER-Modell Schritt für Schritt ein vollständiges Datenbankschema entsteht. Jede Stufe transformiert ein konkretes ER-Konzept in den entsprechenden SQL-Bestandteil:

2) Die fünf Transformationsregeln auf einen Blick

Die Übersetzung folgt einem Algorithmus aus fünf Regeln. Wer sie verinnerlicht hat, transformiert in der Prüfung ER-Modelle quasi blind:

3) Komplettbeispiel: Schule

Schauen wir uns ein durchgängiges Beispiel an, das alle Regeln anwendet. Eine Schule modelliert: Lehrer unterrichten Kurse (1:N), Schüler belegen Kurse (M:N, mit Note). Aus diesem ER-Modell entsteht ein vierseitiges Schema:

4) Datentypen wählen – die wichtigsten in der IHK-Praxis

Wenn aus Attributen Spalten werden, muss man einen Datentyp festlegen. Falsche Datentypen führen zu Speicherverschwendung, Performance-Problemen oder sogar Datenverlust. Diese Übersicht zeigt die wichtigsten Typen, die du in der IHK-Prüfung kennen solltest:

Wichtiger Tipp: Niemals Geldbeträge in FLOAT oder DOUBLE speichern! Diese sind binäre Fließkommazahlen, die viele Dezimalbeträge nicht exakt darstellen können. DECIMAL hingegen ist exakt – das ist für Buchhaltung und Rechnungen Pflicht. Mehr zu Datentyp-Wahl in CREATE TABLE.

5) Constraints – die Wächter der Datenintegrität

Bei der Transformation entsteht nicht nur die Tabellenstruktur, sondern auch die Regeln, die die Datenqualität sichern. Diese Constraints werden direkt im CREATE TABLE mit angegeben:

• PRIMARY KEY: Eindeutiger, nicht-NULL Schlüssel – pro Tabelle genau einer.
• FOREIGN KEY: Verweis auf eine andere Tabelle – siehe Primary & Foreign Key.
• UNIQUE: Diese Spalte darf nicht doppelt vorkommen (z. B. E-Mail-Adressen).
• NOT NULL: Diese Spalte muss immer einen Wert haben.
• CHECK: Eigene Prüfregel, z. B. CHECK (alter >= 0).
• DEFAULT: Standardwert, falls beim INSERT nichts angegeben wird.
• ON DELETE / ON UPDATE: Verhalten beim Löschen/Ändern der referenzierten Zeile (CASCADE, SET NULL, RESTRICT) – siehe Referenzielle Integrität.

Constraints sind das Sicherheitsnetz der Datenbank. Eine falsche Eingabe scheitert direkt an der Datenbank, statt erst in der Anwendung Schaden anzurichten. Das ist ein Kernkonzept – mehr in Integritätstypen.

6) Namenskonventionen – Profi-Hygiene

Im ER-Modell schreibt man Entitäten gern groß und auf Deutsch („Kunde"). Im SQL-Schema haben sich andere Konventionen durchgesetzt – hier ein Mini-Stilguide, der in den meisten Unternehmen funktioniert:

• Tabellennamen klein, Singular oder Plural (im Team einheitlich): kunde oder kunden. Keine Leerzeichen, keine Umlaute.
• Spaltennamen klein, snake_case: geburtsdatum, kunden_id.
• Primärschlüssel: entweder id oder tabellenname_id (z. B. kunden_id in der Kunden-Tabelle).
• Fremdschlüssel: gleicher Name wie der Primärschlüssel der referenzierten Tabelle – das macht JOINs einfacher.
• Verknüpfungstabellen: Name aus den beiden verbundenen Tabellen, z. B. student_kurs – oder mit Verb, z. B. belegt.
• Keine reservierten SQL-Worte als Namen: order, group, user vermeiden – sonst muss man die in Backticks oder Anführungszeichen setzen.

7) Vom Schema zurück zum ER-Modell?

Geht das auch andersrum? Ja – aber mit Vorsicht. Wenn man ein bestehendes Schema in ein ER-Modell zurückrekonstruiert (Reverse Engineering), kann man die Tabellen-Beziehungen meist anhand der Fremdschlüssel erkennen. Tools wie MySQL Workbench oder DBeaver machen das automatisch. Aber: Was bei der Transformation verloren geht, lässt sich nicht immer rekonstruieren – etwa die genaue Beziehungs-Bezeichnung („tätigt", „besucht"), abgeleitete Attribute oder den ursprünglich vorhandenen 1:1-Charakter (der ohne UNIQUE auch ein 1:N hätte sein können).

In der Praxis ist Reverse Engineering oft Bestandteil von Projektdokumentationen: Ein bestehendes System soll abgelöst werden, also dokumentiert man die alte Datenbank, baut darauf das neue ER-Modell und transformiert es in das neue Schema.

Zusammenfassung

Die Transformation vom ER-Modell zum Datenbankschema folgt fünf klaren Regeln: Regel 1 – jede Entität wird eine Tabelle. Regel 2 – jedes Attribut wird eine Spalte (Schlüssel → PRIMARY KEY, mehrwertige in eigene Tabelle, abgeleitete nicht speichern). Regel 3 – 1:1-Beziehungen werden zu Fremdschlüssel + UNIQUE oder zu einer einzigen Tabelle zusammengelegt. Regel 4 – 1:N-Beziehungen bekommen einen Fremdschlüssel auf der N-Seite. Regel 5 – M:N-Beziehungen werden immer zu einer eigenen Verknüpfungstabelle mit zwei Fremdschlüsseln als zusammengesetztem Primärschlüssel; Beziehungs-Attribute leben hier. Beim Schreiben des Schemas wählt man passende Datentypen (INT, VARCHAR, DECIMAL, DATE …) und ergänzt Constraints (PRIMARY KEY, FOREIGN KEY, NOT NULL, UNIQUE, CHECK, DEFAULT, ON DELETE/UPDATE). Saubere Namenskonventionen (snake_case, Spalten klein, Fremdschlüssel-Name = Primärschlüssel-Name) machen das Schema wartbar. Die Übersetzung ist mechanisch genug, dass Tools wie MySQL Workbench sie automatisieren können – aber wer die Regeln im Kopf hat, transformiert in der IHK-Prüfung in wenigen Minuten.

Verwandte Lektionen: 1. Normalform · CREATE TABLE · Primary & Foreign Key · und mehrWeitere relevante LektionenEntity-Relationship-ModellKardinalitätenKrähenfuß-NotationReferenzielle IntegritätIntegritätstypenSQL-Grundstruktur2. und 3. NormalformJOINs