Entity-Relationship-Diagramm (ERD)
Das Entity-Relationship-Diagramm (ERD) ist ein grafisches Modell, das den Aufbau einer Datenbank beschreibt, bevor sie technisch umgesetzt wird.
Es zeigt:
- Welche Objekte (Entitäten) gespeichert werden
- Welche Eigenschaften (Attribute) sie haben
- Und wie diese Objekte zueinander in Beziehung stehen
Ziel des ERD
Das ERD hilft dabei, die logische Struktur einer Datenbank zu planen. Es wird oft vor dem Datenbankdesign erstellt und ist damit Teil der Analyse- und Entwurfsphase.
Beispiel Aufgabe
Hier eine Aufgabe mit Lösung wie sie in der Prüfung vorkommen könnte.
- Zu jedem Mietvorgang gehört ein Auftraggeber, der über eine Kundennummer identifiziert wird. Es können mehrere Mietvorgänge pro Auftraggeber vorliegen.
- Ein Mietvorgang kann sich auf mehrere Fahrzeuge beziehen. Dabei können verschiedene Fahrzeugtypen gemietet werden (z. B. Limousine, Transporter, SUV).
- Jedes Fahrzeug hat eine eindeutige Fahrzeugnummer, eine Beschreibung sowie einen Standard-Mietpreis pro Tag. Je nach Fahrzeugtyp kann es jedoch Sonderpreise geben.
- Jedes Fahrzeug ist einer festen Filiale zugeordnet. Eine Filiale hat eine Filialnummer, eine Adresse sowie eine Telefonnummer.
- Jeder Mietvorgang wird von einem Mitarbeiter bearbeitet. Der Mitarbeiter ist für die gesamte Abwicklung zuständig und wird durch eine Personalnummer identifiziert.
- Zusätzlich gibt es pro Mietvorgang einen weiteren Mitarbeiter, der im Falle von Problemen als Notfallkontakt fungiert.
- Zu jedem Fahrzeug wird ein aktueller Kilometerstand und die Angabe über eine bestehende Vollkaskoversicherung gespeichert.
Bestandteile eines ERD
| Element | Bedeutung | Darstellung |
|---|---|---|
| Entität | Ein „Ding“ oder Objekt, das gespeichert werden soll | Rechteck |
| Attribut | Eigenschaft einer Entität | Oval |
| Primärschlüssel | Eindeutige Identifikation einer Entität | Unterstrichen |
| Beziehung | Verknüpfung zwischen Entitäten | Raute |
| Kardinalität | Gibt an, wie viele Objekte einer Entität mit anderen verknüpft sind | z. B. 1:1, 1:n, m:n |
Kardinalitäten (Beziehungstypen)
| Typ | Bedeutung | Beispiel |
|---|---|---|
| 1:1 | Ein Objekt ist genau einem anderen zugeordnet | Ein Mensch hat genau einen Personalausweis |
| 1:n | Ein Objekt ist mit mehreren verknüpft | Ein Kunde kann mehrere Bestellungen haben |
| m:n | Mehrere sind mit mehreren verknüpft | Ein Schüler besucht mehrere Kurse, ein Kurs hat mehrere Schüler |
m:n-Beziehungen müssen später in der relationalen Datenbank aufgelöst werden – durch eine Zwischentabelle.
1:1-Beziehung – Mensch und Personalausweis
Ein Mensch besitzt genau einen Personalausweis.
Ein Personalausweis gehört genau einem Menschen.
1:n Beziehung – Kunden und Bestellungen
Ein Kunde kann mehrere Bestellungen haben → 1:n
m:n Beziehung – Kurse und Schüler
Für die Beziehung belegung würde in der Datenbank eine Zwischentabelle erstellt werden, um die m:n Beziehung technisch aufzulösen. Die Tabelle enthält zwei Fremdschlüssel die zu einem Primärschlüssel kombiniert werden.
Ein Schüler kann mehrere Kurse belegen und ein Kurs kann von mehreren Schülern belegt werden → m:n
Pflicht- vs. freiwillige Beziehungen
Ist in der Prüfung oft nicht erforderlich, aber manchmal Thema im Theorie-Teil.
Gibt an, ob und wie viele Objekte miteinander verknüpft sein müssen.
- 0..1 (null oder eine Übereinstimmung)
- 1..1 (genau eine Übereinstimmung)
- 0..n (null oder mehr Übereinstimmungen)
- 1..n (mindestens eine Übereinstimmung)
Beispiel:
- Ein Kunde kann null oder mehrere Bestellungen haben → 1 zu 0..n
- Ein Kunde kann aber muss nicht ein Konto besitzen → 1 zu 0..1
Tipps für die Prüfung
- Achte auf korrekte Kardinalitäten (immer an beiden Seiten angeben!)
- Notiere Primärschlüssel immer unterstrichen
- Verwende für m:n-Beziehungen immer eine Zwischentabelle
- Übe das Lesen und das Zeichnen von ERDs
- Du solltest aus einem ERD Tabellen ableiten können – mit Primär- und Fremdschlüsseln
Normalformen in Datenbanken
Eine verständliche Erklärung der ersten drei Normalformen mit anschaulichen Beispielen. Die Normalisierung ist entscheidend für ein sauberes und wartbares Datenbankdesign.
Überblick zu Entwurfsmustern
Diese Seite bietet eine Einführung in Entwurfsmuster, ihre Kategorien und ordnet häufige Muster wie Singleton, Observer, Factory, MVC und Facade ein.