Inhaltsverzeichnis
Vom ER-Modell zum Relationenmodell
Das ER-Modell beschreibt eine Datenbank auf konzeptioneller Ebene, wir denken in Entitäten, Attributen und Beziehungen. Ein relationales Datenbanksystem wie PostgreSQL oder SQLite kennt jedoch nur Tabellen. Die Überführung ist deshalb ein systematischer Übersetzungsprozess: Für jede Art von ER-Element gibt es eine feste Regel.
Das Ergebnis ist eine Menge von Relationenschemata, die alle Tabellen mit Spalten, Primärschlüsseln und Fremdschlüsseln vollständig beschreiben. Daraus lässt sich dann direkt die CREATE TABLE-SQL generieren. Die folgenden Schritte werden stets an der Bank-Miniwelt illustriert.
Entitäten werden zu Relationen
Die einfachste Regel: Jede reguläre Entität im ER-Diagramm wird zu einer Relation. Ihre Attribute werden zu Spalten der Tabelle, ihr Primärschlüssel bleibt Primärschlüssel. Beziehungsattribute kommen noch nicht hinzu, sie folgen erst aus den Beziehungsregeln.
Entität E mit Attributen A₁, …, Aₙ und Primärschlüssel K wird zu E(K, A₁, …, Aₙ).
Die fünf Entitäten der Bank-Miniwelt liefern folgende Grundrelationen:
Schreibweise:Relation(PK, 🠙FK, Attr)
Attribut = Primärschlüssel
🠙Attribut = Fremdschlüssel
Attribut = normales Attribut
Kunde(K_ID, Name, Adresse)
Bankkonto(IBAN, Saldo)
Währung(Währungscode, Kurs_zu_Euro)
Mitarbeiter(M_ID, Name, Funktion)
Finanzinstitut(FI_ID, Name, Hauptsitz)
Die Spezialisierungen Girokonto und Anlagekonto werden gesondert behandelt.
Binäre Beziehungen überführen
Entscheidungsregel: Das Maximum entscheidet, wo der Fremdschlüssel landet. Das Minimum entscheidet, ob der FremdschlüsselNULL sein darf.
Bei binären Beziehungen kommt es auf den maximalen Partizipationswert bei der Min-Max-Notation auf beiden Seiten an. Es gibt drei Fälle.
Fall A: Eindeutige Referenz
Wenn eine Entität A mit (0,1) oder (1,1) beteiligt ist, kann jede Instanz von A maximal eine Instanz von B kennen. Der Primärschlüssel von B wird direkt als neue Spalte in A eingebettet, eine eigene Tabelle für die Beziehung ist nicht nötig. Eigene Attribute der Beziehung wandern ebenfalls als Spalten in A.
Das Minimum entscheidet, ob NULL erlaubt ist:
- (1,1): Fremdschlüssel ist
NOT NULL(die Zuordnung ist Pflicht). - (0,1): Fremdschlüssel darf
NULLsein (die Zuordnung ist optional).
Beispiel: Die Beziehung <arbeitet in> wird als Fremdschlüssel in der Relation Mitarbeiter abgebildet. Der Fremdschlüssel darf niemals leer bleiben.
Mitarbeiter(M_ID, Name, Funktion, 🠙FI_ID) (NOT NULL)
Fall B: Mehrfache Referenz
Erlauben beide Seiten mehrere Zuordnungen, scheidet das Einbetten eines Fremdschlüssels aus, eine Spalte kann nicht mehrere Werte halten. Die Beziehung erhält daher eine eigene Relation mit je einem Fremdschlüssel pro Seite. Der Primärschlüssel der neuen Relation bildet sich aus den beiden Fremdschlüsseln.
Beispiel: Die Beziehung <besitzt> muss als eigene Relation besitzt abgebildet werden, welche mehrere Kunden (K_ID) einem Konto (ISBN) oder mehreren Konten einem Kunden zuordnen kann.
besitzt(🠙IBAN, 🠙K_ID)
Fall C: Beidseitige Einzelreferenz
Fall C tritt in der Bank-Miniwelt nicht auf.Haben beide Seiten (1,1) oder (0,1), wird der Fremdschlüssel vorzugsweise in die Seite mit (0,1) eingebettet (darf NULL sein). Bei (1,1)–(1,1) könnten die beiden Entitäten sogar vollständig zu einer einzigen Tabelle zusammengeführt werden.
Beispiel: In der dargestellten Beziehung Schüler <hat> Schülerausweis, wird der Schülerausweis mit seinem ID als Fremdschlüssel in der Relation Schüler abgebildet.
Schüler(Name, 🠙ID)
Rekursive Beziehungen
Eine rekursive Beziehung verbindet eine Entität mit sich selbst. Die Überführungsregel ist dieselbe wie bei binären Beziehungen. Da Fremd- und Primärschlüssel aber in derselben Tabelle landen, muss der Fremdschlüssel einen anderen Spaltennamen erhalten.
Beispiel Die rekursive Beziehung 'Ein Mitarbeiter (Führungskraft) <leitet> einen oder mehrere (0,N) Mitarbeiter.' wird mit einem unbenannten Fremdschlüssel auf die Relation Mitarbeiter abgebildet (M_ID → Mutterinstitut_FI_ID).
Mitarbeiter(M_ID, Name, Funktion, 🠙FI_ID, 🠙Vorgesetzter_M_ID)
Ähnlich wird die rekursive Beziehung Finanzinstitut <besitzt> abgebildet:
Finanzinstitut(FI_ID, Name, Hauptsitz, 🠙Mutterinstitut_FI_ID)
Ternäre Beziehungen
Eine ternäre Beziehung verbindet drei Entitäten gleichzeitig. Da keine der drei Seiten einfach die „aufnehmende" Tabelle sein kann, gibt es nur eine Möglichkeit: eine neue Relation mit den Primärschlüsseln aller drei Entitäten als Fremdschlüsseln. Kann dieselbe Beziehungsinstanz mehrfach auftreten (z. B. mehrere Transaktionen mit den selben Eigenschaften), wird ein künstlicher Schlüssel (z. B. fortlaufende ID) als Primärschlüssel ergänzt.
Beziehung <bucht Transaktion> verbindet Mitarbeiter, Bankkonto und Währung (alle (0,N)) und trägt die Attribute Betrag und Ziel-IBAN.
Dieselbe Konto-Währungs-Kombination kann von einem Mitarbeiter mehrfach gebucht werden, weshalb die drei Fremdschlüssel allein nicht eindeutig sind. Deshalb wird ein künstlicher Schlüssel T_ID eingefügt:
Transaktion(T_ID, 🠙M_ID, 🠙IBAN, 🠙Währungscode, Betrag, Ziel_IBAN)
Spezialisierung und Generalisierung
Ein „is-a"-Dreieck im ER-Modell drückt aus, dass ein Subtyp eine Spezialisierung eines Supertyps ist. Der Supertyp besitzt gemeinsame Attribute. Subtypen ergänzen typspezifische Attribute. Für die Überführung gibt es drei Strategien.
Für den Supertyp und jeden Subtyp wird jeweils eine eigene Tabelle angelegt. Der Subtyp erhält denselben Primärschlüssel wie der Supertyp, dieser fungiert gleichzeitig als Fremdschlüssel auf den Supertyp.
Beispiel Girokonto ergänzt Überziehbar_bis, Anlagekonto ergänzt Laufzeit und Zinssatz.
Bankkonto(IBAN, Saldo)
Girokonto(🠙IBAN, Überziehbar_bis)
Anlagekonto(🠙IBAN, Laufzeit, Zinssatz)
Eine Abfrage aller Girokonto-Daten erfordert einen natürlichen Verbund ⋈ bzw. einen JOIN über IBAN zwischen Girokonto und Bankkonto.
Relationenschema Banktransaktion
Für das ER-Modell Banktransaktion ergibt sich das folgende Relationenschema:
Kunde(K_ID, Name, Adresse)
Währung(Währungscode, Kurs_zu_Euro)
Finanzinstitut(FI_ID, Name, Hauptsitz, 🠙Mutterinstitut_FI_ID)
Mitarbeiter(M_ID, Name, Funktion, 🠙FI_ID, 🠙Vorgesetzter_M_ID)
Bankkonto(IBAN, Saldo)
besitzt(🠙IBAN, 🠙K_ID)
Girokonto(🠙IBAN, Überziehbar_bis)
Anlagekonto(🠙IBAN, Laufzeit, Zinssatz)
Transaktion(T_ID, 🠙M_ID,🠙IBAN, 🠙Währungscode, Betrag, Ziel_IBAN)