• Vom ERM zum RM - mit Optimierung
  • verybusybeaver
  • 19.05.2022
  • Informatik
  • Qualifikationsphase 2
Um die Lizenzinformationen zu sehen, klicken Sie bitte den gewünschten Inhalt an.

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

1
Warum genügt bei 1:1-Beziehungstypen ein beliebiger Schlüssel der verbundenen Entitäten?
Jede Entität ist in maximal einer Beziehung. Damit identifiziert jeder der Schlüssel auch die Beziehung eindeutig.
2
Warum muss bei 1:n-Beziehungstypen der Schlüssel aus der n-Seite erstellt werden?
Jede Entität dieses Typs kann mit nur einer anderen Entität in Beziehung stehen. Dadurch identifiziert ihr Schlüssel auch die Beziehung eindeutig.
3
Versuchen Sie jetzt, das Relationenmodell zu dem Entity-Relationship-Modell ganz oben zu ermitteln.

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).

muss:muss -> Die drei Relationen lassen sich in einer Relation zusammenfassen. muss:kann -> Die Relation hat kann als Fremdschlüssel in die Relation auf der muss-Seite integriert werden.
4
Bedenken Sie, welche Informationen durch die Relationen abgebildet werden und überlegen Sie dann, welche der Relationen Sie verlustfrei einsparen können. Macht die Optionalität einen Unterschied dabei?

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.

n-Seite obligatorisch: "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
5
Bedenken Sie, welche Informationen durch die Relationen abgebildet werden und überlegen Sie dann, welche der Relationen Sie verlustfrei einsparen können. Macht die Optionalität einen Unterschied dabei?

n:m-Beziehungen

6
Überlegen Sie, warum eine Optimierung von n:m-Beziehungen generell nicht möglich ist.
Jede Entität beider Typen steht potentiell mit mehreren Entitäten des anderen Typs in Beziehung. Daher ist keine einfache Referenzierung möglich.

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

Es ergibt sich (bei muss:muss) die folgende Relation:

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.

Es ergeben sich (wenn Schüler obligatorisch ist) die folgenden Relationen:

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

x