Datenbankschema Entwurf - Hilfe benötigt

[kahlchen]

(Hinweis: die hellgrauen Punkte dienen nur der Formatierung, sonst nichts)

Hallo,
ich stelle im Folgenden mal einen Ausschnitt des Schemas dar:

HardwareGerät---Mobilfunkgerät
......|
......|
......+-----------GerätDasKeineMACsBesitzt
......|
......|
......+-----------GerätDasMACsBesitzt----MACadressen----Ports
.........................................|...................................... ....|
.........................................|...................................... ....|
.........................................+-----------Switch------------+

Erklärung:
In der ersten Ebene ist Vererbung, heißt: "HardwareGerät" kann sein "Mobilfunkgerät" oder "GerätDasKeineMACsBesitzt" oder "GerätDasMACsBesitzt".
"GerätDasMACsBesitzt" besitzt eine oder mehrere (1..*) "MACadressen". Diese "MACadressen" sind an bestimmten "Ports" angebunden (N:M-Beziehung mit Auflösung in extra Entität, hier aber nicht dargestellt).

So und jetzt mein Problem: Ich will noch darstellen, dass ein "Switch" 1..* "Ports" beinhaltet. Wichtig: Ein "Switch" besitzt aber auch eine "MACadresse"! Er ist aber wiederum nicht über eine "MACadresse" an "Ports" abgebunden. Hier weiß ich nicht, wie ich das modellieren soll.

Weiterhin weiß ich nicht, ob ich die Entität "GerätDasKeineMACsBesitzt" überhaupt benötige... in dieser Tabelle würde dann nämlich nur die ID als Primärschlüssel stehen, mehr nicht. Also kann ichs gleich weglassen, oder?

Wenn etwas ungenau oder unzureichend erklärt ist, einfach kurz fragen.
Also vielen Dank schonmal für's Überlegen.

[CrazyIvan]

Hier (http://de.wikipedia.org/wiki/Object-Relational_Mapping#Abbildung_von_Vererbungshierarchien) findest Du erstmal drei grundlegende Arten, Vererbungen in relationalen Datenbanken abzubilden. Wie Du vielleicht erkennst, sind alle drei Methoden nicht das gelbe vom Ei, was aber am sogenannten "relational Gap" liegt - es handelt sich eben um unterschiedliche Paradigmen, die sich nicht so einfach verheiraten lassen.

Ich persönlich würde die erste Variante bevorzugen, da sich aus Sicht der Normalisierungslehre kaum Vorteile durch die beiden anderen ergeben. D.h., alle Klassen und deren Instanzen werden in nur einer Tabelle abgebildet und durch eine Eigenschaft bezüglich ihrer Klassenzugehörigkeit unterschieden.

Ich persönlich würde es folgendermaßen abbilden. Allerdings sei dazu gesagt, dass ich eher aus der DB-Ecke komme und nicht aus der OO-Ecke. Die "Übersetzung" wäre dann in der ORM-Schicht vorzunehmen:

Tabelle Gerät (
ID Primärschlüssel,
Bezeichnung (optional),
hasMAC
KategorieID Fremdschlüssel
)
Tabelle Kategorie_Gerät (
ID Primärschlüssel,
Bezeichnung {Mobilfunk; Switch}
)
Tabelle MacAdressen (
ID Primärschlüssel,
MAC-Adresse (wobei ich das lieber "Bezeichnung" nennen würde),
GerätID Fremdschlüssel
)
Tabelle MacToPorts (
MacID (Teil des Primärschlüssels),
PortID (Teil des Primärschlüssels)
)
Tabelle Ports (
ID Primärschlüssel,
Port bzw. Bezeichnung,
GerätID Fremdschlüssel
)

Anmerkungen:
"hasMAC" ist ein Bit und eigentlich überflüssig. Denn durch Verjoinen mit der Tabelle MacAdressen lässt sich für jedes Gerät herausfinden, ob es eine MAC hat. Hängt aber vom Anwendungsfall ab.
Über den Fremdschlüssel GerätID in Ports lässt sich Dein Sachverhalt des Switches abbilden. Allerdings könnte man theoretisch auch das weglassen, wenn man den Weg über die MAC des Switches ginge.
In Kategorie_Gerät ließe sich noch eine Kategorie "Sonstiges" einfügen. Alternativ einfach das Fremdschlüsselfeld in Gerät auf NULL belassen.
Ist wie gesagt nur ein Vorschlag und könnte für Deinen Anwendungsfall völliger Quatsch sein.

[kahlchen]

Hey,
vielen vielen Dank, dass du dich damit beschäftigt und mir geolfen hast! :)
Dein Vorschlag klingt gut. Allerdings musste ich da erstmal durchsteigen und das Ganze in mein Datenbankschema übersetzen. Ich melde mich nochmal und gebe Bescheid, ob das wirklich alles so klappt.

Allerdings habe ich noch ein Problem. Die Mobilfunkgeräte (sind nur 20 Stück) habe 7 Attribute, die die anderen Geräte (ca. 1000) nicht haben. Nun will ich umgehen, dass ich diese 7 Attribute immer in der "Geräte"-Tabelle mitschleife. Könnte ich dann einfach an dein neues Schema noch eine Tabelle anhängen?


Tabelle Gerät (
ID Primärschlüssel,
Bezeichnung (optional),
hasMAC,
KategorieID Fremdschlüssel,
MobilfunkGerätID Fremdschlüssel
)
Tabelle MobilfunkGerät (
ID Primärschlüssel,
hier kommen die 7 Attribute hin
)


Der Fremdschlüssel "MobilfunkGerätID" in "Gerät" hat eine Beziehung mit dem Primärschlüssel "ID" in "MobilfunkGerät".
Geht das einfach so oder müsste ich es dann generell so machen, dass ich das Gerät quasi vererbe? Wegen mir, einmal nach "Mobilfunkgerät" und einmal nach "AndereGeräte". Und hinter "AndereGeräte" kommen dann quasi die ganzen Beziehungen zu "Port" und "MACadressen".
Ich hoffe das war verständlich.

Nochmals vielen Dank. :)

[CrazyIvan]

Ja, das ist Variante zwei im von mir verlinkten Wiki-Artikel. Das geht grundsätzlich. Allerdings hast Du dann eine 1:1 - Relation zwischen "Gerät" und "Mobilfunkgerät". Das ist meines Erachtens hinsichtlich der Normalisierung kein sonderlich guter Stil, da 1:1 - Relationen in eine gemeinsame Tabelle gehören. Auch verbrauchst Du bei nur einer Tabelle nicht mehr Platz, da die NULL-Werte in den nicht belegten Attributen keinen Speicherplatz verbrauchen. Ist aber IMHO auch Geschmackssache.

[kahlchen]

Alles klar, vielen Dank. Ich muss mich wohl mal näher mit dem Wiki Artikel beschäftigen. ;)
Also nochmal vielen vielen Dank, das hat / du hast mir sehr geholfen. :)

[kahlchen]

Hallo,
ich wollte nur nochmal kurz sagen, dass dein Vorschlag perfekt funktioniert hat und auch ohne Änderungen abgesegnet wurde! :)
Vielen Dank nochmal! :)

[CrazyIvan]

Freut mich zu hören. Wenns mal wieder so klappt ;)

[kahlchen]

Freut mich zu hören. Wenns mal wieder so klappt ;)

Warum denn "mal wieder"? :)