Vom Entity-Relationship-Modell zum Relationenmodell
Wenn das Entity-Relationship-Modell erstellt wurde, existiert ein guter Überblick über die zur Abbildung der Miniaturwelt benötigten Entitäts- und Beziehungstypen und ihrer Attribute und Schlüssel.
Um daraus die benötigten Tabellen abzuleiten, wird in das Relationenmodell umgewandelt, das die Tupelschreibweise nutzt:
Und so wird's gemacht:
Entitätstypen:
Jeder Entitätstyp wird zu einer Tabelle (genannt Relation)
Der Primärschlüssel des Entitätstyps wird als Primärschlüssel der Relation unterstrichen
Beziehungstypen:
Jeder Beziehungstyp wird zu einer Relation
Die Primärschlüssel aller durch den Beziehungs-typ verbundenen Entitätstypen werden zusätz-liche Attribute d. Relation (so gekennzeichnet: î )
Abhängig von der Kardinalität des Beziehungstyps wird ein Schlüssel festgelegt:
Kardinalität
Zum Primärschlüssel wird...
1:1
...einer der Primärschlüssel der verbundenen Entitätstypen
1:n
...der Primärschlüssel des Entitätstyps auf der n-Seite
n:m
beide Primärschlüssel der beteiligten Entitätstypen
Erkundung: Optimierung des Relationenmodells
Die Anleitung für die Umwandlung ergibt stets ebensoviele Tabellen/Relationen wie es vorher Beziehungs- und Entitätstypen im ERM gab. In einigen Fällen können aber, ohne dabei informationen zu verlieren, Relationen eingespart werden.
Zum Vorgehen:
Auf dieser Seite erhalten Sie wichtige Basisinformationen und die Aufgabe, sich über Möglichkeiten zur Zusammenfassung von Relationen Gedanken zu machen. Auf der Folgeseite finden Sie dann allgemein formulierte Regeln.
1:1-Beziehungen
Einer Entität des Typs Schüler ist maximal eine Entität des Typs Spind zugeordnet (und umgekehrt).
Nach der Anleitung ergeben sich die Relationen Schüler (SNummer, Name, Vorname), Spind (Nummer, Standort, Größe) und hat (î SNummer, Nummer).
1:n-Beziehungen
Einer Entität des Typs Schüler ist maximal eine Entität des Typs Spind zugeordnet, einer Entität des Typs Tutor können aber mehrere des Typs Schüler zugeordnet werden.
hat-Relation kann auf der n-Seite integriert werden
n-Seite optional:
hat-Relation kann auf der n-Seite integriert werden, das ist aber nicht immer sinnvoll
n:m-Beziehungen
Regeln: Optimierung des Relationenmodells
Die Anleitung für die Umwandlung ergibt stets ebensoviele Tabellen/Relationen wie es vorher Beziehungs- und Entitätstypen im ERM gab. In einigen Fällen können aber, ohne dabei informationen zu verlieren, Relationen eingespart werden.
Die häufigsten dieser Fälle sind nachfolgend abgebildet.
1:1-Beziehungen
1:1-Beziehungen, die beiderseits obligatorisch sind, lassen sich zu einer einzigen Relation zusammenfassen. Eines der Schlüsselattribute wird das neue Schlüssel-attribut.
Ist die Optionalität nicht muss:muss, so wird verfahren wie bei 1:n-Beziehungen
Schüler_hat_Spind (SNummer, Name, Vorname, Nummer, Größe, Standort)
1:n-Beziehungen
Bei 1:n-Beziehungen und nicht beiderseits obligatorischen 1:1-Beziehungen kann eine Relation eingespart werden, wenn zur Kardinalität 1 die Optionalität muss gehört.
Dazu wird der Entitätstyp mit der Kardinalität n und der Optionalität kann als Relation beibehalten. Die Relationen des Beziehungstyps und des anderen Entitätstyps werden verschmolzen. Als neues Schlüsselattribut wird das Schlüsselattribut des Entitätstyps verwendet.
Lehrer (Kürzel, Name)
Schüler_hat-Tutor (S-ID, Name, Vorname, î Kürzel)
n:m-Beziehungen
Aus n:m-Beziehungstypen entstehende Relationen lassen sich nicht auf diese Weise verschmelzen.
Sonderfälle
n-seitig optionale 1:n-Beziehungen sind unter bestimmten Voraussetzungen optimierbar
-Wenn Generalisierungen/Spezialisierungen als ist_ein
-Beziehungstyp modelliert werden, können sie zu einer Relation optimiert werden
Mehrwertige Attribute (sollten vermieden werden) können durch Einführung einer weiteren Relation aufgelöst werden
