ERM nach DBMS: is-a-Beziehung / Generalisierung/Spezialisierung

cocoon

Erfahrenes Mitglied
Hallo,

ich habe eine Frage zu der is-a-Beziehung (Generalisierung/Spezialisierung/Vererbung) in einem ER-Modell, nämlich wie ich diese letztlich in einem Datenbanksystem (hier: mySQL) umsetze. Über die Suche habe ich zu entsprechenden Begriffen leider nichts gefunden. Zum besseren Verständnis habe ich einen Ausschnitt des ERMs angehangen.

Über google habe ich gefunden, dass eine is-a-Beziehung wie folgt abgebildet wird:

Die vererbende Entität wird samt ihrer Attribute in einer eigenen Tabelle umgesetzt. Ebenso werden alle erbenden Entitäten in eigenen Tabellen umgesetzt und erhalten (neben den sie spezialisierenden Attributen) als ID den Schlüssel der vererbenden Tabelle.

Auf mein Beispiel bezogen wirft das folgende Fragen auf:

- Wie sieht es aus, wenn eine Entität zwar sinngemäß spezialisiert ist, aber keine weiteren Attribute erhält, die sie von der vererbenden Entität abhebt? In Beispiel: Ein Freundschaftsspiel (friendly) ist ein Spiel (match), ebenso ist es ein Testspiel (test). Sie unterscheiden sich aber durch keine Attribute davon. Macht es Sinn, jetzt Tabellen umzusetzen, die nur eine ID haben?!

- Die Spezialisierung "Verein (club) ist ein Heim/Auswärts-Team (hometeam/awayteam)" und die damit verbundene Beziehung zum Spiel (match) habe ich mit in die Tabelle "match" umgesetzt: so erhält ein "match" zwei Fremdschlüssel von den (Heim/Auswärts)Clubs und ferner die Tore und Halbzeit-Tore. Ist das richtig umgesetzt?!

Okay, ist mal wieder viel Text, hoffe trotzdem, Ihr könnt mir helfen. :) Danke schonmal!
 

Anhänge

  • erm.jpg
    erm.jpg
    84,2 KB · Aufrufe: 1.773
Okay, habe nun doch noch etwas gefunden:
Generalisierung / Spezialisierung Vier Varianten:
1. eine Relation f ¨ur Supertyp und je eine pro Subtyp
Typisch f ¨ur Spezialisierung: Relationen f ¨ur Subtypen
enthalten zus¨ atzlich Prim¨ar-Schl¨ussel des Supertypen.
2. nur eine pro Subtyp
Typisch f ¨ur Generalisierung: Relationen der Subtypen
enthalten zus¨ atzlich die Attribute des Supertypen.
3. nur Supertyp
Relation für Supertyp enthält alle Attribute der Subtypen
und einen Diskriminator. Geeignet, falls die Anzahl der
unterschiedlichen Attribute der Subtypen sehr klein ist
bzw. überlappende Spezialisierung / Generalisierung.
4. nur Supertyp
Relation für Supertyp enthält alle Attribute der Subtypen
und pro Subtyp ein Flag ob entsprechende Attribute
Anwendung finden. Geeignet, falls die Anzahl der unterschiedlichen
Attribute der Subtypen sehr klein ist und
disjunkte Spezialisierung / Generalisierung.
Für mein Problem würden dann wohl 3.) oder 4.) Anwendung finden.

Würde trotzdem Eure Meinung hören, wie Ihr es umsetzen würdet.
 
Zuletzt bearbeitet:

Neue Beiträge

Zurück