ER-Modell: Entitäten und Beziehungen modellieren
Ein Entity-Relationship-Modell, kurz ER-Modell oder ERM, beschreibt die fachlich wichtigen Daten eines abgegrenzten Wirklichkeitsausschnitts: Welche Arten von Dingen gibt es, welche Eigenschaften haben sie und wie hängen sie zusammen? Das zugehörige ER-Diagramm (ERD) macht diese Struktur sichtbar, bevor daraus Datenbanktabellen entstehen.
Auf dieser Seite lernst du, Entitätstypen, Attribute, Schlüssel und Beziehungen zu erkennen, Kardinalitäten sicher zu lesen und ein einfaches ER-Modell in ein relationales Schema zu überführen.
Hake ab, was du schon kannst — und komm am Ende hierher zurück!
Was bildet ein ER-Modell ab?
Stell dir vor, eine Schule plant eine Datenbank. Sie muss nicht die ganze Wirklichkeit erfassen. Sie wählt nur das aus, was für ihren Zweck wichtig ist, zum Beispiel Lernende, Kurse und Belegungen. Diese bewusste Vereinfachung heißt konzeptuelle Modellierung.
Ein ER-Modell beschreibt dabei das fachliche Was. Technische Entscheidungen wie ein bestimmtes Datenbanksystem folgen später. Das Modell hilft deshalb auch Menschen, die keine Datenbank programmieren, Anforderungen zu prüfen.
Entität und Entitätstyp
Eine Entität ist ein einzelnes, identifizierbares Objekt, zum Beispiel die konkrete Studentin Aylin. Ein Entitätstyp fasst gleichartige Entitäten zusammen, zum Beispiel Student.
Attribut und Beziehung
Ein Attribut beschreibt eine Eigenschaft eines Entitätstyps, zum Beispiel Name bei Student. Eine Beziehung verbindet Entitäten, zum Beispiel: Ein Student belegt ein Seminar. Auf der Typebene heißt das Beziehungstyp.
In der Chen-Notation werden Entitätstypen als Rechtecke, Beziehungen als Rauten und Attribute als Ovale dargestellt. Andere Notationen sehen anders aus, beschreiben aber dieselben fachlichen Strukturen.
Wie werden Objekte eindeutig erkannt?
Eine Datenbank muss gleichartige Entitäten unterscheiden können. Dafür braucht jeder Entitätstyp einen Schlüssel.
Primärschlüssel
Ein Primärschlüssel ist ein Attribut oder eine Attributkombination, die jede Entität eindeutig identifiziert. Seine Werte dürfen nicht doppelt und nicht leer sein. Ein Schlüssel kann natürlich vorhanden oder künstlich eingeführt sein, zum Beispiel eine Kundennummer.
Ein starker Entitätstyp lässt sich durch eigene Attribute identifizieren. Gebäude ist stark, wenn jedes Gebäude eine eindeutige GebäudeID besitzt.
Ein schwacher Entitätstyp benötigt zusätzlich den Schlüssel einer verbundenen starken Entität. Eine Raumnummer wie 101 kann in mehreren Gebäuden vorkommen. Ein Raum wird deshalb durch die Kombination (GebäudeID, Raumnummer) eindeutig.
Anforderung: Jedes Gebäude hat eine eindeutige GebäudeID. Innerhalb eines Gebäudes sind die Raumnummern eindeutig, aber dieselbe Raumnummer darf in verschiedenen Gebäuden vorkommen.
Gebäudeist stark. Sein Primärschlüssel istGebäudeID.Raumist schwach.Raumnummerist nur ein partieller Schlüssel, also nur innerhalb eines Gebäudes eindeutig.- Der vollständige Schlüssel von
Raumlautet(GebäudeID, Raumnummer). GebäudeIDverweist beiRaumzugleich auf das zugehörige Gebäude.
So können Gebäude 1, Raum 101 und Gebäude 2, Raum 101 gleichzeitig existieren, ohne verwechselt zu werden.
Ein Attribut ist nicht schon deshalb ein Schlüssel, weil es wichtig klingt. Entscheidend ist, ob sein Wert jede Entität im vorgesehenen Datenbestand eindeutig identifiziert.
Wie viele Entitäten dürfen verbunden sein?
Die Kardinalität beschreibt, wie viele Entitäten der einen Seite mit Entitäten der anderen Seite verbunden sein dürfen. Bei einer binären Beziehung sind drei Grundformen besonders wichtig.
| Form | Bedeutung | Beispiel |
|---|---|---|
| 1:1 | Auf beiden Seiten ist höchstens eine Zuordnung möglich. | Mitarbeiter – Mitarbeiterausweis |
| 1:n | Eine Entität der ersten Seite kann vielen der zweiten zugeordnet sein; jede Entität der zweiten Seite höchstens einer der ersten. | Kunde – Bestellung |
| n:m | Auf beiden Seiten sind mehrere Zuordnungen möglich. | Lieferant – Produkt |
Lies die Namen immer mit: Bei Kunde 1:n Bestellung kann ein Kunde mehrere Bestellungen aufgeben, aber jede Bestellung gehört zu höchstens einem Kunden.
Die Grundformen sagen noch nicht sicher, ob eine Teilnahme verpflichtend ist. Dafür gibt die Min-Max-Notation für eine Instanz ein Paar (Minimum, Maximum) an:
(0,1): optional, höchstens eine Zuordnung;(1,1): genau eine Zuordnung;(0,N): optional, beliebig viele Zuordnungen;(1,N): mindestens eine, möglicherweise viele Zuordnungen.
Kardinalitätsangaben werden je nach Notation an unterschiedlichen Kantenpositionen gelesen. Verlasse dich deshalb nicht nur auf die Stellung einer Zahl. Formuliere beide Richtungen als Satz: „Ein Kunde kann …; jede Bestellung …“
Wie entsteht ein vollständiges ER-Modell?
Beginne nicht mit Symbolen. Kläre zuerst die Bedeutung der Anforderungen. Ein verlässlicher Ablauf besteht aus fünf Schritten:
- Relevante Objekte als Entitätstypen bestimmen.
- Eigenschaften als Attribute ergänzen.
- Primärschlüssel festlegen.
- Beziehungen benennen.
- Kardinalitäten und verpflichtende Teilnahmen in beide Richtungen prüfen.
Anforderung: Ein Kunde kann mehrere Bestellungen aufgeben. Jede Bestellung gehört zu genau einem Kunden. Eine Kundennummer identifiziert jeden Kunden eindeutig.
Schritt 1 – Entitätstypen: Kunde und Bestellung sind eigenständige fachliche Objekttypen.
Schritt 2 – Attribute und Schlüssel: Kundennummer ist Primärschlüssel von Kunde. Auch Bestellung benötigt einen eigenen eindeutigen Bestellschlüssel.
Schritt 3 – Beziehung: Die Beziehung heißt gibt auf.
Schritt 4 – Kardinalität: Von Kunde zu Bestellung gilt 1:n. Eine Bestellung hat genau einen Kunden; ein Kunde kann mehrere Bestellungen haben.
Schritt 5 – Gegenprobe: Das Modell erlaubt mehrere Bestellungen desselben Kunden, aber keine Bestellung mit zwei verschiedenen Kunden. Damit bildet es die Anforderung ab.
Ein Diagramm allein genügt nicht immer. Ergänze Regeln, die sich grafisch nicht eindeutig ausdrücken lassen, als klare Geschäftsregeln. Dazu gehören etwa Mindestzahlen, zeitliche Bedingungen oder Berechnungsregeln.
Wie wird aus dem ER-Modell ein Tabellenschema?
Im relationalen Modell werden Entitätstypen zu Tabellen und Attribute zu Spalten. Schlüssel sichern die Identifikation und die Verknüpfung.
Fremdschlüssel
Ein Fremdschlüssel ist ein Attribut, das auf den Primärschlüssel einer anderen Tabelle verweist. Referenzintegrität bedeutet: Ein Fremdschlüsselwert darf nur auf einen tatsächlich vorhandenen Schlüsselwert zeigen.
Für die Grundfälle gelten diese Abbildungsregeln:
- Starker Entitätstyp: eine eigene Tabelle mit seinem Primärschlüssel.
- Schwacher Entitätstyp: eine eigene Tabelle; ihr Primärschlüssel enthält den Schlüssel der starken Entität und den partiellen Schlüssel.
- 1:1-Beziehung: Meist erhält eine der Tabellen den Fremdschlüssel der anderen. Pflichtteilnahme und mögliche Nullwerte helfen bei der Wahl.
- 1:n-Beziehung: Die Tabelle auf der n-Seite erhält den Fremdschlüssel der 1-Seite.
- n:m-Beziehung: Es entsteht eine eigene Beziehungstabelle mit den Schlüsseln beider Seiten; Beziehungsattribute kommen hinzu.
Aus Kunde 1:n Bestellung wird:
Kunde(Kundennummer, …)
Bestellung(Bestellschlüssel, Kundennummer, …)
Bestellung.Kundennummer ist Fremdschlüssel auf Kunde.Kundennummer. Er steht auf der n-Seite, weil viele Bestellungen dieselbe Kundennummer enthalten dürfen.
Aus der n:m-Beziehung Lieferant liefert Produkt wird dagegen eine eigene Tabelle:
Liefert(Lieferantenschlüssel, Produktschlüssel)
Die Kombination der beiden Fremdschlüssel bildet gewöhnlich den Primärschlüssel, sofern dasselbe Paar nur einmal gespeichert werden soll.
Welche Modellierungsfehler sind typisch?
Ein formal ordentliches Diagramm kann fachlich trotzdem falsch sein. Prüfe deshalb besonders diese Fehlerquellen:
- Eigenschaft und Objekt verwechseln: Ein eigener Entitätstyp ist sinnvoll, wenn etwas selbst Beziehungen, Attribute oder eine eigene Identität besitzt.
- Optionalität vergessen:
nallein sagt nicht, ob auch null Zuordnungen erlaubt sind. - Mehrwertige Angaben vermischen: Zusammengehörende Werte müssen zusammen modelliert werden. Getrennte Listen für Kurszeiten und Räume könnten falsche Zeit-Raum-Kombinationen erzeugen.
- Ternäre Beziehungen blind zerlegen: Der Zusammenhang „Lieferant liefert Bauteil für Produkt“ umfasst alle drei Beteiligten gemeinsam. Zwei oder drei binäre Beziehungen können zusätzliche, nie behauptete Kombinationen entstehen lassen.
- Redundanz übersehen: Werden dieselben Personendaten in mehreren Rollentypen getrennt gespeichert, können widersprüchliche Adressen entstehen.
Gegeben sind die Aussagen:
- Bosch liefert ein Navigationssystem für den Golf.
- Sony liefert ein Navigationssystem für den Auris.
Die ternäre Beziehung speichert jeweils genau das Tripel aus Lieferant, Produkt und Bauteil. Würdest du nur Lieferant–Bauteil und Produkt–Bauteil speichern, könnte eine spätere Verknüpfung fälschlich behaupten, Bosch liefere auch das Navigationssystem für den Auris. Die ursprüngliche Information „wer liefert welches Bauteil für welches Produkt?“ wäre verloren.
Ein gutes ER-Modell ist:
- korrekt: Es erlaubt nur Zusammenhänge der betrachteten Miniwelt.
- vollständig: Es enthält alle für den Zweck nötigen Daten.
- minimal: Es vermeidet unnötige Doppelungen.
- lesbar: Benennungen und Aufbau sind übersichtlich.
- verständlich: Fachkundige Personen können die Bedeutung nachvollziehen.
Zuerst kommt die Semantik, dann die Grafik. Teste dein Modell mit konkreten Beispieldaten und frage: „Welche falschen Zustände erlaubt es? Welche richtigen Zustände verhindert es?“
Karteikasten
Überlege zuerst selbst und drehe die Karte anschließend zum Prüfen um.
Alles auf einen Blick
- ER-Modell
- beschreibt: relevanten Wirklichkeitsausschnitt
- besteht aus: Entitätstypen, Attributen, Beziehungen
- identifiziert durch: Primärschlüssel
- unterscheidet: starke und schwache Entitätstypen
- begrenzt durch: Kardinalität und Partizipation
- wird umgesetzt als: Tabellen, Fremdschlüssel, Beziehungstabellen
- wird geprüft auf: Korrektheit, Vollständigkeit, Minimalität, Lesbarkeit
Abschluss-Check
Prüfe nun, ob du vom Sachverhalt zum Modell und vom Modell zu Tabellen wechseln kannst.
Mit Google fortfahren