Q2.1 – ER- und Relationenmodell | D-Book

Qualifikationsphase

Q2.1 – ER- und Relationenmodell

Vom fachlichen Modell eines Realitätsausschnitts zur relationalen Tabellenstruktur

Datenbanken speichern nicht die Wirklichkeit selbst, sondern einen geordneten Ausschnitt davon. Das Entity-Relationship-Modell hilft, diesen Ausschnitt fachlich zu strukturieren.

Anschließend wird das Modell in eine relationale Darstellung mit Tabellen überführt. Diese Seite legt damit die Grundlage für das Folgekapitel Q2.2 SQL.

Kerncurriculum kompakt
Einordnung und Lernziele des Themenfelds Q2.1

A) Allgemeine Einordnung

Q2.1 bildet den Einstieg in den Datenbankentwurf und gilt als gemeinsames Fundament für Grund- und Leistungskurs. Lernende strukturieren einen fachlichen Kontext mit dem ER-Modell und überführen ihn in ein relationales Schema.

B) Anforderungen nach Kursniveau

Grundlegendes Niveau

ER-Modell: Entität, Entitätstyp (auch schwacher Entitätstyp), Attribut (auch mehrwertiges Attribut), Beziehungstyp (auch is-a-Beziehungstyp), Kardinalität, Optionalität.
Relationenmodell: Schlüssel, Relationsschema, Datenbanktabellen.

Erhöhtes Niveau (Leistungskurs)

ER-Modell: rekursiver Beziehungstyp, ternärer Beziehungstyp.
Normalisierung: Anomalien sowie erste, zweite und dritte Normalform.

Datenbankentwurf
ER-Modell als Werkzeug zur fachlichen Strukturierung

Ein Datenbanksystem bildet nie die ganze Wirklichkeit ab. Es beschreibt immer einen ausgewählten, geordneten Ausschnitt, der für eine Anwendung relevant ist. Damit das gelingt, braucht man ein gemeinsames Modellierungswerkzeug – in Q2.1 ist das das Entity-Relationship-Modell.

Modelle vereinfachen bewusst: Nicht jede Einzelheit wird übernommen, aber Struktur, Zusammenhänge und Eindeutigkeit werden sichtbar. Genau diese Reduktion macht den Entwurf später technisch umsetzbar.

Für Q2.1 gilt daher ein durchgängiger Arbeitsablauf: Begriffe fachlich klären, im ER-Diagramm-Editor modellieren und anschließend in das Relationenmodell überführen.

Grundelemente des ER-Modells

Die folgenden Bausteine klären die zentralen Fachbegriffe zunächst einzeln. Genau diese Begriffe und Notationen findest du im ER-Diagramm-Editor wieder: Entitätstyp als Rechteck, Beziehungstyp als Raute, Attribut als Oval sowie Kardinalität und Optionalität direkt an der Verbindung.

Entität

Eine Entität ist ein einzelnes konkretes Objekt im modellierten Ausschnitt, also ein bestimmter Fall und kein Sammelbegriff. Im Editor entsteht eine Entität nicht als eigenes Symbol, sondern als Datensatz eines Entitätstyps.

Entitätstyp

Ein Entitätstyp fasst gleichartige Entitäten mit derselben Struktur zusammen und legt damit die Datenform fest. Die Schaltfläche „Entitätstyp hinzufügen“ erzeugt genau diese fachliche Klasse.

Attribut

Ein Attribut beschreibt eine Eigenschaft eines Entitätstyps oder eines Beziehungstyps. Der konkrete Inhalt eines Feldes ist dann der Attributwert (z. B. Titel = „Informatik heute“). Damit werden fachlich relevante Informationen präzise benannt.

Beziehungstyp

Ein Beziehungstyp beschreibt die Art der Verbindung zwischen Entitätstypen und damit auch ihre fachliche Bedeutung (z. B. „löst“, „bewertet“, „gehört zu“). In diesem Kapitel wird bewusst mit „Beziehung/Beziehungstyp“ gearbeitet, um den späteren Begriff „Relation“ im Relationenmodell klar abzugrenzen.

Kardinalität

Die Kardinalität legt fest, wie viele Entitäten an einer Beziehung beteiligt sein können. Für den Unterricht wird hier mit 1:1, 1:n und n:m gearbeitet.

Optionalität

Optionalität beschreibt, ob die Teilnahme an einer Beziehung freiwillig oder verpflichtend ist. In der hessischen Darstellung wird das mit „kann“ beziehungsweise „muss“ unter der Beziehungskante gekennzeichnet, während die Kardinalität darüber angibt, wie viele Entitäten beteiligt sein können.

Für die Modellqualität ist die Unterscheidung zentral: Entitätstyp und Attribut benennen die Struktur, Entität und Attributwert stehen für konkrete Einzelfälle. Außerdem kann ein Entitätstyp stark (normal identifizierbar) oder schwach sein; schwache Entitätstypen sind im Editor als Variante auswählbar. Für Spezialisierungen steht zusätzlich die is-a-Beziehung (Generalisierung) zur Verfügung.

Beziehungstypen werden im Unterricht vor allem als 1:1, 1:n oder n:m modelliert. Im Editor stellst du diese Struktur über die Kardinalität pro Seite ein; zusätzlich legst du über Optionalität fest, ob eine Teilnahme „kann“ oder „muss“. So wird nicht nur die Form einer Beziehung festgelegt, sondern ihre fachliche Aussage.

Beispiel: ER-Diagramm für einen Buchhandel

Für einen kleinen Online-Buchhandel werden die Entitätstypen Buch, Autor, Verlag, Kunde und Bestellung modelliert. Ein Buch hat genau einen Verlag, kann aber mehrere Autorinnen und Autoren haben. Kundinnen und Kunden geben Bestellungen auf, eine Bestellung enthält wiederum mehrere Bücher.

Die Beziehung zwischen Buch und Autor ist damit n:m, zwischen Verlag und Buch 1:n. Zwischen Kunde und Bestellung liegt ebenfalls eine 1:n-Struktur vor: Oben steht also die Kardinalität (wie viele), unten die Optionalität (kann oder muss). Eine Bestellung muss genau einem Kunden zugeordnet sein, ein Kunde kann Bestellungen aufgeben.

Dieses kompakte Beispiel eignet sich zum Einstieg. Für die Arbeit mit realistischeren Modellen wird im ER-Diagramm-Editor zusätzlich das Musterdiagramm „Aufgabentypen“ (Muster: Aufgabensammlung) verwendet.

Komplexes ER-Diagramm Aufgabentypen/Aufgabensammlung mit mehreren Entitätstypen, Beziehungen und Attributen. — Das Diagramm „Aufgabentypen“ zeigt typische Komplexität: mehrere Beziehungstypen mit unterschiedlichen Kardinalitäten, optionalen und verpflichtenden Teilnahmen sowie Attribute an Entitäts- und Beziehungstypen. Damit eignet es sich als zentrales Lernbeispiel zwischen Grundbegriffen und relationaler Transformation. Genau diese Entscheidungen kannst du im Editor über „Verbinden“ und die Bearbeitung von Kardinalität/Optionalität nachvollziehen.

Umsetzung des ER-Modells
Vom fachlichen Entwurf zur relationalen Tabellenstruktur

Ein ER-Modell ist noch keine technische Datenbank. Für den Einsatz in einem DBMS wird es in eine relationale Darstellung überführt. Dabei gilt als Grundregel: Entitätstypen werden zu Tabellen, Attribute zu Spalten, einzelne Entitäten zu Datensätzen. Die Funktion „In Relationen überführen“ im ER-Diagramm-Editor setzt genau diese Regeln schrittweise um.

Dabei werden Primärschlüssel so gewählt, dass jede Zeile eindeutig identifizierbar ist. Fremdschlüssel übernehmen anschließend die Verknüpfung zwischen Tabellen. So wird die Semantik der Beziehungstypen aus dem ER-Modell technisch überprüfbar.

Begriff: 1:1-Beziehung

Bei 1:1 existiert pro Seite höchstens eine Gegeninstanz. Für die relationale Umsetzung genügt deshalb ein Fremdschlüssel in einer der beiden Tabellen; welche Seite ihn trägt, richtet sich nach Fachbedeutung und Optionalität.

Begriff: 1:n-Beziehung

Bei 1:n kann ein Datensatz der 1-Seite viele Datensätze der n-Seite referenzieren. Daher wandert der Primärschlüssel der 1-Seite als Fremdschlüssel in die n-Tabelle – genau dieses Muster zeigt der Editor bei der Überführung.

Begriff: n:m-Beziehung

n:m ist nicht direkt mit zwei Tabellen darstellbar. Die Transformation erzeugt daher eine eigene Zwischentabelle mit beiden Fremdschlüsseln als kombinierter Schlüssel und Platz für mögliche Beziehungsattribute.

Relationale Darstellung lesen: Struktur und Bedeutung der Notation

Die relationale Darstellung zeigt nicht nur welche Tabellen entstehen, sondern auch wie sie fachlich miteinander verknüpft sind. Auf Q2.1 nutzen wir dieselbe Notationslogik wie im SQL-Werkzeug: Relationenschreibweise, Schlüsselmarkierungen und Transformationshinweise sind dort und hier konsistent.

Notation der relationalen Darstellung

Relation(Attribut1, Attribut2, ...) beschreibt ein Relationsschema in Kurzschreibweise.
Unterstrichene Attribute sind Primärschlüssel (eindeutige Identifikation).
↑Attribut kennzeichnet einen Fremdschlüssel (Verweis auf eine andere Relation).
↑Attribut bedeutet: Fremdschlüssel und zugleich Teil des Primärschlüssels.
Mehrere unterstrichene Attribute in einer Relation bilden einen zusammengesetzten Primärschlüssel.

Beispielschema mit erklärbarer Notation (Buchhandel)

Verlag(VerlagID, Name, Ort)
Buch(ISBN, Titel, Preis, ↑VerlagID)
Autor(AutorID, Name)
Kunde(KundenID, Name, EMail)
Bestellung(BestellID, Datum, ↑KundenID)
Buch_Autor(↑ISBN, ↑AutorID, Rolle)
Bestellposition(↑BestellID, ↑ISBN, Menge)
Kunde_Telefon(↑KundenID, Telefonnummer)

Wie diese Notation die ER-Transformation sichtbar macht

1:1 und 1:n: werden durch Fremdschlüssel in der Zielrelation abgebildet (z. B. ↑VerlagID in Buch, ↑KundenID in Bestellung) – keine eigene Beziehungstabelle nötig.
n:m: erscheint als eigene Relation (z. B. Buch_Autor) mit beiden Fremdschlüsseln als gemeinsamem Primärschlüssel.
Beziehungen mit Attributen: bleiben in der Beziehungstabelle erhalten (z. B. Rolle in Buch_Autor, Menge in Bestellposition).
Mehrwertige Attribute: werden ausgelagert (z. B. Kunde_Telefon für mehrere Telefonnummern pro Kunde).

Genau diese Leselogik wird im SQL-Werkzeug bei „Relationale Darstellung“ verwendet: Das ER-Modell liefert die fachliche Struktur, die Überführung zeigt sie als Relationsnotation mit Primär- und Fremdschlüsseln. Dadurch lässt sich direkt prüfen, ob Kardinalitäten, Beziehungen und Integritätsbedingungen technisch korrekt umgesetzt wurden.

Begriff: Integritätsbedingungen

Integritätsbedingungen sorgen dafür, dass Daten konsistent bleiben: Datensätze müssen eindeutig identifizierbar sein, und Beziehungen dürfen nicht ins Leere zeigen.

Vorbereitend dazu werden Primärschlüssel und Fremdschlüssel festgelegt. So kann das DBMS Eindeutigkeit und Referenzen prüfen, noch bevor später mit SQL detailliert gearbeitet wird. Die Optionalität aus dem ER-Modell wirkt dabei weiter: „muss“ führt zu verpflichtenden Referenzen, „kann“ erlaubt fehlende Zuordnungen (z. B. leere Fremdschlüsselfelder).

Sonderfälle im ER-Modell
Erweiterte Notationen für editorrelevante Spezialkonstellationen

Spezialfälle

Diese Fälle ergänzen die Grund-Transformation um typische Erweiterungen. Sie helfen, im ER-Diagramm-Editor auch komplexere Fachregeln konsistent zu modellieren und sauber in Relationen zu überführen.

Schwacher Entitätstyp

Doppellinie am Entitätstyp zeigt: Die Identifikation hängt vom Besitzer ab. Bei der Überführung bleibt diese Abhängigkeit als FK-basierte Identifikation explizit sichtbar.

Mehrwertiges Attribut

Ein Attribut kann mehrere Werte pro Entität tragen. In der relationalen Umsetzung führt das typischerweise zu einer ausgelagerten Nebentabelle.

Beziehung mit Attributen

Nicht nur Entitäten, auch Beziehungen können eigene Attribute tragen. Diese Attribute werden in der entstehenden Beziehungstabelle als reguläre Spalten übernommen.

is-a-Generalisierung

Der Subtyp erbt Eigenschaften vom Supertyp. Im Editor wird diese Hierarchie als eigener Beziehungstyp modelliert und bei der Tabellenstrategie berücksichtigt.

Zusammengesetzter Primärschlüssel

In der ER-Notation ergibt sich dieser Fall aus Strukturentscheidungen (z. B. n:m). Der Editor weist ihn in der relationalen Darstellung als kombinierten PK/FK explizit aus.

Normalisierung
Redundanzen vermeiden und Konsistenz sichern (1NF bis 3NF)

Nach der Überführung vom ER-Modell in Relationen folgt häufig die fachliche Prüfung der Tabellen: Sind die Daten strukturiert, widerspruchsfrei und ohne unnötige Wiederholungen gespeichert? Genau dafür wird normalisiert.

Redundante Daten führen leicht zu Einfüge-, Änderungs- und Löschanomalien: Informationen müssen an mehreren Stellen gepflegt werden, können sich widersprechen und machen die Datenbank inkonsistent. Ziel der Normalisierung ist deshalb eine Tabellenstruktur ohne überflüssige Redundanz, bei der der Informationsgehalt erhalten bleibt.

Eine gute ER-Modellierung reduziert viele Probleme bereits im Vorfeld. Im Werkzeug entspricht eine saubere ER-Modellierung bereits weitgehend einer normalisierten Datenbank. Fehler in der Modellierung führen im relationalen Schema dagegen häufig zu Redundanzen.

Erste Normalform (1NF)

In der 1NF enthält jedes Attribut nur atomare Werte: keine Listen, keine Mehrfachwerte in einer Zelle. Ein typisches Gegenbeispiel ist ein Attribut „Sportgruppen“ mit mehreren Einträgen in einem Feld.

Lösung: Die Liste wird auf mehrere Tupel aufgeteilt, und zusammengesetzte Attribute werden in Einzelfelder zerlegt (z. B. Name in Vorname/Nachname). Mehrfachwerte aus mehrwertigen Attributen werden in der Regel in eine eigene Tabelle ausgelagert.

Zweite Normalform (2NF)

Die 2NF setzt die 1NF voraus. Jetzt geht es um partielle Abhängigkeiten bei zusammengesetzten Schlüsseln: Jedes Nichtschlüsselattribut muss vom gesamten Primärschlüssel abhängen.

Funktionale Abhängigkeit bedeutet: A → B, also A bestimmt B eindeutig. Für die 2NF reicht nicht „ein Teil des Schlüssels bestimmt B“, sondern nur die volle Abhängigkeit vom gesamten Schlüssel. Wenn das nicht gilt, wird die Tabelle in mehrere Tabellen aufgespalten.

Dritte Normalform (3NF)

Die 3NF setzt die 2NF voraus und entfernt transitive Abhängigkeiten. Problemfall: A → B → C. Dann hängt C nur indirekt vom Schlüssel über B ab.

Lösung: Der transitiv abhängige Teil wird in eine eigene Tabelle ausgelagert. So bleiben Änderungen lokal und verursachen keine widersprüchlichen Datenstände.

Normalisierung und ER-Transformation zusammendenken

Normalisierung erklärt, warum bei der Transformation zusätzliche Tabellen entstehen: n:m-Beziehungen werden als eigene Tabellen umgesetzt, Entitäten werden klar getrennt und Schlüsselbezüge sauber modelliert. Damit werden die späteren SQL-Abfragen robuster und Integritätsbedingungen leichter einhaltbar.