ER-Modell in Relationales Modell umwandeln: Ein Anfängerleitfaden

Hallo da draußen, zukünftige Datenbank-Zauberer! Heute machen wir uns auf eine aufregende Reise vom Reich der Entitäts-Beziehungs-(ER-)Modelle hin zur Welt der Relationellen Modelle. Keine Sorge, wenn du dich ein bisschen verloren fühlst – wir gehen das Schritt für Schritt durch, und am Ende wirst du ER-Diagramme in relationale Schemata wie ein Profi umwandeln können!

Warum ER in Relational umwandeln?

Bevor wir eintauchen, lassen Sie uns darüber sprechen, warum wir das tun. Stell dir vor, du baust ein Haus. Das ER-Modell ist wie dein Bauplan – es zeigt dir das große Ganze. Aber um das Haus tatsächlich zu bauen, brauchst du detaillierte Pläne. Das ist, wo das relationale Modell hereinkommt. Es gibt uns eine konkrete Möglichkeit, unser Datenbankdesign in realen Datenbankmanagementsystemen (DBMS) zu implementieren.

Nun, lasst uns die Ärmel hochwerren und loslegen!

Abbildung von Entitäten

Was ist eine Entität?

Eine Entität ist wie ein "Ding" in unserer Datenbankwelt. Es könnte eine Person, ein Ort oder ein Objekt sein – alles, was wir informationell speichern möchten.

Wie man eine Entität abbildet

Wenn wir eine Entität in das relationale Modell abbilden, erstellen wir eine Tabelle. Es ist so einfach! Jedes Attribut der Entität wird zu einer Spalte in der Tabelle.

Schauen wir uns ein Beispiel an:

Student
ID (PK)
Name
Alter
Fach
```

Hier haben wir die 'Student'-Entität in eine 'Student'-Tabelle abgebildet. Die 'ID' ist unser Primärschlüssel (PK), der jeden Studenten eindeutig identifiziert.

Ein Wort zu Primärschlüsseln

Stell dir vor, ein Primärschlüssel ist wie die eindeutige ID-Karte eines Studenten. Genau wie keine zwei Studenten die gleiche ID-Karte haben sollten, sollten auch keine zwei Zeilen in unserer Tabelle den gleichen Primärschlüsselwert haben.

Abbildung von Beziehungen

Beziehungen in ER-Modellen zeigen, wie Entitäten miteinander verbunden sind. In der relationalen Welt verwenden wir Fremdschlüssel, um diese Verbindungen darzustellen.

Ein-zu-Viel-Beziehung

Das ist wie ein Lehrer und seine Schüler. Ein Lehrer kann viele Schüler haben, aber jeder Schüler hat nur einen Lehrer (in diesem Kontext).

| Lehrer | | Student | |-------------| |-------------| | LehrerID(PK)| | SchülerID(PK)| | Name | | Name | | Fach | | LehrerID(FK)|

Siehst du die 'LehrerID' in der Schüler-Tabelle? Das ist unser Fremdschlüssel (FK). Er verweist auf die LehrerID in der Lehrer-Tabelle und erstellt die Beziehung.

### Viel-zu-Viel-Beziehung

Denke an Schüler und Kurse. Ein Schüler kann viele Kurse besuchen, und ein Kurs kann vielen Schülern gehören. Dafür benötigen wir eine Junction-Tabelle:


| Schüler      |   | Einschreibung  |   | Kurs          |
|-------------|   |---------------|   |--------------|
| SchülerID(PK)|   | SchülerID(FK)|   | KursID(PK)    |
| Name        |   | KursID(FK)    |   | Kursname      |
|             |   | Note          |   |              |

Die Einschreibungs-Tabelle verbindet Schüler und Kurse und ermöglicht Viel-zu-Viel-Beziehungen.

Abbildung von schwachen Entitätsmengen

Eine schwache Entität ist wie ein Sidekick – sie kann ohne ihren Helden (die starke Entität) nicht existieren. In Datenbankterminologie hat sie keinen eigenen Primärschlüssel.

Nehmen wir an, wir haben 'Raum' als schwache Entität von 'Gebäude':

| Gebäude | | Raum | |-------------| |--------------| | GebäudID(PK)| | Raumnummer | | Gebäudename | | Kapazität | | | | GebäudID(FK) |

Der Primärschlüssel für Raum wäre eine Kombination aus GebäudID und Raumnummer.

## Abbildung von hierarchischen Entitäten

Hierarchische Entitäten sind wie Familiengenerationen in unserer Datenbankwelt. Wir haben einige Möglichkeiten, diese abzubilden:

### 1. Ansatz mit einer Tabelle

Wir packen alles in eine Tabelle:


| Person       |
|-------------|
| PersonID(PK) |
| Name         |
| Typ          |
| MitarbeiterID|
| SchülerID    |

Dies funktioniert, kann aber zu vielen Nullwerten führen.

2. Ansatz mit einer Tabelle pro Typ

Wir erstellen eine Tabelle für den Basistyp und separate Tabellen für jeden Subtyp:

| Person | | Mitarbeiter | | Schüler | |-------------| |--------------| |--------------| | PersonID(PK)| | PersonID(FK) | | PersonID(FK) | | Name | | MitarbeiterID| | SchülerID | | | | Abteilung | | Fach |

Dieser Ansatz ist flexibler, erfordert aber Joins für Abfragen.

### 3. Ansatz mit einer Tabelle pro konkreten Typ

Wir erstellen separate Tabellen für jeden Typ, wiederholen dabei aber gemeinsame Attribute:


| Mitarbeiter |   | Schüler      |
|-------------|   |--------------|
| PersonID(PK)|   | PersonID(PK) |
| Name        |   | Name         |
| MitarbeiterID|  | SchülerID    |
| Abteilung   |   | Fach         |

Dieser Ansatz vermeidet Nullwerte, kann aber zu Datenredundanzen führen.

Schlussfolgerung

Und da habt ihr es, Leute! Wir haben uns von der konzeptionellen Welt der ER-Modelle auf den konkreten Bereich der relationalen Datenbanken begeben. Denkt daran, Übung macht den Meister. Versucht, eigene ER-Diagramme zu erstellen und sie in relationale Modelle umzuwandeln. Bevor ihr es wisst, werdet ihr die Sprache der Datenbanken fließend sprechen!

Weiterlernen, weiterwachsen und vor allem: Spaß an euren Datenbanken haben. Bis下次, fröhliches Coden!

Credits: Image by storyset