Brauche Hilfe: Vererbung in einer relationalen Datenbank (mySQL)

[derFuxx]

Hallo Leute,

ich hoffe mir kann jemand helfen. Brauche dringend Hilfe bei der Umsetzung eines ER-Entwurfs in meine Datenbank. Zum Problem:

Ich habe 4 Entitites: Person, Benutzer, Gast und Adresse.
Person enthält allgemeine Attribute wie eine ID, den Vornamen, Nachname, Geschlecht usw. Benutzer und Gast erben nun alle diese Attribute und haben noch einige zusätzliche Attribute. Adresse (verfügt über Attribute wie Straße, PLZ etc. Schlüssel: AdressID) steht zu Person in einer 1:N Beziehung. Weiterhin gibt es eine Relation wohnen, in der die Schlüssel der Adresse und Person als FK eingetragen werden.

Meine Frage wäre nun, wie ich die Vererbung am besten relational umsetze. Meine Idee wäre: pro einzelner Java-Klasse Person, Benutzer und Gast eine Tabelle mit den jeweils relevanten Attributen anzulegen und den PK ID von Person als PK und gleichzeitig als FK bei den Subklassen anzulegen (ID ist als Auto-Inkrement definiert).

Das sollte eigentlich so gehen. Mein Problem würde nun darin bestehen, wie ich die Daten aus meinen Java-Klassen in die Tabellen bekomme. Könnte ich eine View anlegen und versuchen die per SQL zu updaten? Geht das weil ich die Tabellen ja für die View vorher joine.

Oder könnte ich das ganze über Hibernate machen? Weiß jemand wie das in dem Fall gehen würde?

Vielen, vielen Dank schonmal im Voraus für eure Hilfe.

 

[ishino]

Die Umsetzung in ein relationales Schema hängt von der Modellierung ab und auch davon, welche Entitäten in der Hierarchie konkrete Ausprägungen haben können oder nicht. Wenn es keine einfache "Person" gibt, sie also nur in der Rolle "Benutzer" bzw. "Gast" auftreten kann, übernimmt man sie nicht mit in das relationale Schema. Im Java-Jargon wäre Person dann eine abstrakte Klasse. Quasi eine Vorlage für die konkreten Personentypen. Wenn eine Person in mehreren Rollen auftreten kann, also Benutzer und Gast sein kann, wäre eine Relation "Person" wieder sinnvoll. Dann wären die gemeinsamen Daten des "Benutzer"s und "Gast"s in einer Tabelle und nur die konkreten Eigenschaften in der jeweiligen Relation, die die Person genauer bestimmt. Vorteil: bei Änderungen an den Personendaten muß nur die "Person" geändert werden. Der "Benutzer" und der "Gast" erben die geänderten Daten automatisch. Das ergibt sich aus der nicht vorhandenen Redundanz, die Du erzeugen würdest, wenn es nur "Benutzer" und "Gast" gibt, eine Person aber in beiden Relationen enthalten ist. Nachteil: man muß die Daten eben erst zusammensammeln.

Ob und wie man diese Daten über eine View aktualisieren kann, hängt vom verwendeten DBMS ab. Die meisten sollten mit einfachen Joins keine Probleme haben. Abgesehen davon, kann man einen auch als Subselect schreiben. Damit fällt das "Killerkriterium keinen Join in der View-Definition zu haben" hinsichtlich der Updatefähigkeit weg.