Abbildung von Entitytypen
Abbildung von Beziehungstypen
1 : 1 - Beziehungen
1 : n - Beziehungen
n : m - Beziehungen
Beispiel
Aufgaben
|
Abbildung von Entitytypen |
|
Abbildung von Beziehungstypen |
|
1 : 1 - Beziehungen |
|
1 : n - Beziehungen |
|
n : m - Beziehungen |
|
Beispiel |
|
Aufgaben
|
Im Relationenmodell werden Entitytypen durch ein Relationenschema (sprich: Tabelle) dargestellt.
Jeder Beziehungstyp wird im Relationenmodell auf ein Relationenschema (sprich: Tabelle) abgebildet. In diesem Relationenschema treten als Eigenschaften auf: die Primärschlüssel der beiden beteiligten Entitytypen, sowie Eigenschaften der Beziehung zwischen den Entities. Beispiel:
Die Relationenschemata für die Entitytypen Projektleiter und Projekt entnehmen wir -leicht modifiziert- folgender Schülerlösung:
Projektleiter(Leiter-Nr, Name, Vorname, Typ)
Projekt(Nr, Thema, Kurztitel, Stufe, Anzahl, Raumbedarf, Schulgeräte)
Unsere Regel sagt nun: nimm in das Relationenschema für den Beziehungstyp bietet_an
die Primärschlüssel der Entitytypen Projektleiter und Projekt auf, also:
bietet_an(Leiter-Nr, Nr)
Hier taucht sofort ein Problem auf: für welchen Primärschlüssel sollen wir uns entscheiden, für die Projektleiter-Nr oder die Projekt-Nr? Lösung: Ein Projekt kann von mehreren Projektleitern angeboten werden, also ist die Projekt-Nr nicht eindeutig. Zu einer Projektleiter-Nr gibt es aber nur eine Projekt-Nr, da in unserer ProWo-Mini-Welt ein Projektleiter nur ein Projekt anbieten muss. Das Relationenschema sieht demnach folgendermaßen aus:
bietet_an(Leiter-Nr, Nr)
Fertig!
Geht man nach der Grundregel
"Jeder Beziehungstyp wird im Relationenmodell auf ein Relationenschema abgebildet"
vor, so erhält man unabhängig von der Komplexität der Beziehung immer drei Tabellen: zwei für die Entitytypen und eine für den Beziehungstyp. Das muss nicht sein, wir können unseren Entwurf optimieren, sprich: wir können Tabellen einsparen! Hierfür ist aber die Komplexität einer Beziehung als Einteilung zu grob. Das Zauberwort lautet "obligatorische Mitgliedschaft" und wird im Datenbank-Reader auf S. 97-99 behandelt. WIR ersparen uns die Details, vereinfachen im folgenden bewußt (didaktische Reduktion!), und ich darf anfügen, dass die folgenden Abschnitte theoretisch (& praktisch!) nicht ganz richtig sind . . .
<<<
sind redundant, also überflüssig! Hier gilt: aus drei mach eins. Statt der zwei Tabellen für die Entitytypen und der dritten Tabelle für den Beziehungstyp reicht ein Relationenschema mit den Eigenschaften der beiden beteiligten Entitytypen.
Beispiel: siehe Seite 100/101!
Ein geschickter Entwurf packt die Information über den Beziehungstyp in die Tabelle auf der n-Seite der Beziehung. Im Beispiel oben:
Projektleiter(Leiter-Nr, Name, Vorname, Typ, Nr)
Nr ist der Primärschlüssel aus dem Projekte-Relationenschema. Hat der Beziehungstyp zusätzliche Eigenschaften, so werden sie einfach in das Relationenschema auf der n-Seite der Beziehung übernommen, im Beispiel also im Relationenschema des Projektleiters hinzugefügt. Da die beiden Tabellen eine gemeinsame Eigenschaft haben (die Projekt-Nr), kann man die beiden Tabellen über einen Join miteinander verbinden!
Beispiel: siehe Seite 100!
Eine n:m-Beziehung wird aufgeteilt in eine 1:n-Beziehung und eine m:1-Beziehung. Unsere ProWo-Datenbank bietet Anschauungsmaterial: jeder Schüler kann zwei Projekte wählen, und jedes Projekt kann von mehreren Schülern gewählt werden. Als Lösung haben wir eine Auflösungstabelle eingeführt, die die Primärschlüssel Projekt-Nr und Schüler-Nr enthält:
sar_wahl(Projekt-Nr, Schüler-Nr)
Will man keinen kombinierten Primärschlüssel (hier: Projekt-Nr und Schüler-Nr), so kann man eine neue Eigenschaft einführen, beispielsweise eine Wahl-Nr, die dann als Primärschlüssel dient:
sar_wahl(Wahl-Nr, Projekt-Nr, Schüler-Nr)
Beachte: Zwischen den Schülern und der Wahl-Tabelle besteht eine 1:n-Beziehung, da jeder Schüler mit genau zwei Einträgen in dieser Tabelle vorkommen sollte. Und zwischen den Projekten und der Wahl-Tabelle besteht eine 1:m-Beziehung, da jedes Projekt mehrfach in der Wahl-Tabelle auftauchen kann, das sind eben gerade diejenigen Schüler, die das Projekt gewählt haben.
Beispiel: siehe Seite 101-103!
Siehe im Datenbanken-Reader S. 106/107 (Abschnitt 3.4.3)
<<<