Hallo zusammen,

ich versuche derzeit, eine Objekt (Instrument) auf verschiedene Tabellen in der Datanbank zu mappen, abhängig vom einem Feld Typ (z.B. Aktie, Anleihe, Optionsschein).

Das generische Objekt Instrument enthält dabei eine Übermenge aller Felder in den verschiedenen Tabellen (z.B. Zinssatz, obwohl es den nur bei Anleihen gibt).

Ist so etwas möglich (und wenn ja wie)?

Viele Grüße und vielen Dank im voraus,
Karsten Schmid

ich hoffe ich erzähle jetzt keinen Unsinn ...

aber Du kannst es mal mit einem "Discriminator" versuchen...

gtx
curio

Hi curio,

funktioniert dies auch, wenn man nur eine Klasse (ohne Ableitungen) hat?

Im Normalfall hat man eine (abstrakte) Klasse und von dem leitet man andere Klassen ab. Nun können diese abgeleiteten Klassen mit discriminator in verschiedenen Tabelle geschrieben werden.

Was, wenn man die Klasse NICHT ableitet und die Instanzen einer einzigen Klasse ja nach dem Wert einer Attribute in verschiedene Tabellen schreiben will (so eine Art dispathcing)?

Grüße
Reza

Du versuchst Vererbung aus etwas zu machen was eigentlich Delegation sein sollte. Bester Hinweis: Einige deiner "Unterklassen" haben nicht alle Attribute der "Ueberklasse". Was du tatsaechlich willst ist ganz normale Klassen die jeweils Komponenten haben. Die Komponenten-Klassen sind wiederverwendbar, und/oder koennen kombiniert werden um fuer die Referenz-Entitaet zusaetzliche Attribute zur Verfuegung zu stellen.

Oder du willst eine andere Vererbungshierarchie, mit einer Ebene dazwischen. Auf keinen Fall willst Du aber anfangen schon im Entwurf Tricks anzuwenden um irgendwas moeglichst komisch abzubilden.

Hallo Christian,

wir haben derzeit ein Datenmodell, bei dem für jeden Typ von Finanzinstrument eine eigene Tabelle zur Verfügung steht. Diese sind je nach Typ zu ca. 60-80% identisch.

In einem zukünftigen Release sollen diese Tabellen zu einer zusammengefasst werden. Diese generische Tabelle Tabelle wird dann ein Superset der der Felder der einzelnen Tabellen erhalten, d.h. je nach Eintrag werden einige Felder leer bleiben.

Wir würde jetzt gerne in unserer Persistenzschicht diese Schritt vorziehen, also bereits im Domain Model eine JavaBean "Generisches Instrument" definieren, die abhängig von einer Property "Typ" steuert, in welcher Tabelle der Datensatz abgelegt wird.

Datenmodell ist in beiden Faellen sehr fragwuerdig, ersteres ist wahrscheinlich nicht in 3NF, zweites sowieso nicht. Gleich aufraeumen und richtig Super/Sub-Tabellen draus machen (falls das kein Begriff ist: Fabian Pascal, "Practical Issues in Database Management"). Dann mit "Table per subclass" Mapping drauf. Bitte nicht jetzt noch mehr kaputt machen.

Hi Christian,

es geht nicht darum, auf welche andere Art und Weisen man es machen kann, sonder ehe darum, ob hibernate die Möglichkeit hergibt.

Wir können (und wollen) unser Datenmodell ändern.

Grüße
Reza

Klar gehts irgendwie, ich weiss aber im Moment nicht wie ich es machen wuerde. (Sehe auch keinen Grund Leuten beim Kaputtmachen zu helfen.) Vielleicht hat sonst jemand Zeit.

Hallo Christian,

um Deinen Horizont was Datenmodellierung über die von Dir gelesenen Bücher hinaus etwas zu erweitern:

Seit den letzten Jahren hat eine Bewegung in den Finanzmärkten statt, bei denen "klassische" Finanzionstrumente wie Aktien, Anleihen und Terminkontrakte in immer neuen Kombinationen und mit neuen Attributen aufgelegt werden.

Die meisten Legacy-Systeme haben demzufolge ein Datenmodell mit einer oder mehreren Tabellen pro Finanzinstrument (eine Aktie, eine Anleihe und ein Forward haben halt wenig gemeinsam). Dies entspricht übrigens sehr wohl der 3NF, diese schreibt nämlich nicht vor, das ähnliche Daten in irgendeiner Form generalisiert werden müssen.

Dieser Ansatz führt jedoch heute zu redundantem Programmcode. Nach kurzer Analyse stellt man fest, daß es so etwas wie "Charaktere" gibt. z.B. einen Zinscharakter, einen Dividendencharakter oder einen Optionscharakter. Da in Java jedoch keine Mehrfachvererbung möglich ist, sehr wohl aber mehrere Charaktere vorhanden sein können, lässt sich dies weder über Generalisierung (Charakter als abstrakte Oberklassen) noch über Spezialisierung (Charaktere erben allgemeinen Teil) abbilden. Die einzige Lösung ist es also, die Daten in einem generischen Instrument abzulegen, bei dem dann halt in bestimmten Ausprägungen einzelne Attribute unbelegt sind.

Da es jedoch noch ein grosses Legacy-System gibt, untersuchen wir in einer Evaluierungsphase zur zeit, ob die ausgewählten Tools in der Lage sind, über einen Diskriminator gesteuert entweder eine der Tabellen für das entsprechende alte Produkt oder die neue generische Tabelle anzusteuern. Dabei handelt es sich natürlich nur um eine Übergangslösung, diese ist jedoch zwingend notwendig.

Lange Rede, kurzer Sinn, stellt sich mir nun die Frage, ob Hibernate auch in der Lage ist solche komplexe Mappings abzubilden (und sei es in dem die Mappingfunktion über SQL ausformuliert wird) oder ob wir im Fall eines Legacy-Systems zu Alternativen wie iBatis greifen müssen.

Genau das tut aber die Normalisierungsregel fuer die 3NF, naemlich die Aufloesung funktionaler Abhaengigkeiten nach semantischen Bedingungen. Aber hey, ich erweitere gerne meinen Horizont :)

Hallo Christian,

die dritte Normalform ist die Auflösung von transitiven Abhängigkeiten, das heisst das ein Feld C nicht von einem Feld B abhängt, das nicht der wiederum vom Primärschlüssel A abhängig ist.

Allerdings habe ich mehr auf eine Antwort bezüglich Hibernate gehofft statt auf eine Fachsimpelei über Datenbanktheorie.

Ja, und Abhaengigkeiten dieser Art sind nur durch die entsprechende Semantik, d.h. die Bedeutung der Werte, zu erfahren. Sollte es jede Menge Duplikate geben ist die Wahrscheinlichkeit von Abhaengigkeiten doch sehr gross. Aber, du wirst ja schliesslich dafuer bezahlt deinem Kunden was zu empfehlen.

Weisst du was Komposition ist? Genau das willst du, wie schon mehrmals jetzt erklaert. Die richtige Loesung ist auf keinen Fall "da machen wir halt jede Menge NULLs rein".

Aber, nehme gerne iBatis wenn du deinen Hack gern implementieren willst. Angeblich ist das ein recht gutes Tool fuer JDBC.

Wir können Komposition ohne weiteres für unser Objektmodell verwenden. Die emisten der bestehenden Instrumente müssen wir jedoch auf die BESTEHENDE Datenstruktur mappen. Die Frage bliebt also, ob Hibernate auf Basis z.B. eines Diskriminators verschiedene Tabellen ansteuern kann oder nicht.

Ein O/R-Mapping-Tool, das dazu in der Lage ist, bei der Migration zu einem sauberen Objektmodell zu unterstützen würde ich im übrigen nicht als "Hack" bezeichnen. Ansonsten qualifizierst Du Hibernate als Tool, das für Neuentwicklungen zwar hanz hübsch ist, aber in einem realen Umfeld - und damit ist eines gemeint, in dem man nicht alle gewünschten Freiheitsgrade hat - nicht eingesetzt werden kann.

Ich qualifiziere garnix, du machst das schon ganz alleine.