[JAVA] hibernate Inheritance strategie

[TukkerTweaker]

De Hibernate documentatie over de te kiezen inheritance strategie laat mij een beetje in het duister tasten.

Het volgende is de sitatie.
Ik heb een super klasse Person en 2 subklassen Employer en Customer. 1 Person kan zowel Employer als Customer zijn maar ik wil de gegevens natuurlijk niet redundant opslaan. Welke strategie moet in hiervoor kiezen?
Voorwaarde is dat de klassen Person, Employer en Customer moet elk in een aparte tabel opgeslagen worden.
Op dit moment gebruik ik joined-subclass maar daarmee voorkom ik niet de dubbele opslag van Person. Wat doe ik fout?

[Alarmnummer]

TukkerTweaker schreef op woensdag 13 april 2005 @ 10:06:
De Hibernate documentatie over de te kiezen inheritance strategie laat mij een beetje in het duister tasten.

Het volgende is de sitatie.
Ik heb een super klasse Person en 2 subklassen Employer en Customer. 1 Person kan zowel Employer als Customer zijn maar ik wil de gegevens natuurlijk niet redundant opslaan.

Als een persoon zowel Employer als Customer kan zijn kan je sowieso niet werken met subclasses. Ik zou rollen aanmaken en die aan Persoon toekennen. Als je per 'rol' ook speciale attributen nodig bent, kan je deze ook aan de rol koppelen.

code:

CustomerRole extends Role{
     private int _korting;
     private Date _lastSale;
}

[ Voor 13% gewijzigd door Alarmnummer op 13-04-2005 10:10 ]

[TukkerTweaker]

Alarmnummer schreef op woensdag 13 april 2005 @ 10:08:
[...]

Als een persoon zowel Employer als Customer kan zijn kan je sowieso niet werken met subclasses. Ik zou rollen aanmaken en die aan Persoon toekennen.

Dat zou het bestaande relationele model (te veel) overhoop gooien. Maar wat ik wil kan dus niet?
Dan lijkt me dat ik het oplos met many-to one relatie definitie.

[ Voor 9% gewijzigd door TukkerTweaker op 13-04-2005 10:13 ]

[Alarmnummer]

TukkerTweaker schreef op woensdag 13 april 2005 @ 10:11:
[...]


Dat zou het bestaande relationele model (te veel) overhoop gooien. Maar wat ik wil kan dus niet?
Dan lijkt me dat ik het oplos met many-to one relatie definitie.

Vanuit oo oogpunt gaat het alleen al wat complexer worden aangezien je nu met multiple inheritance in aanraking komt. In java is dit wel mogelijk door verschillende interfaces te implementeren (maar je zult er maar een vieze class implementatie aan overhouden aangezien je nooit meer dan 1 class als parent kan hebben). Maar ik weet niet hoe goed Hibernate dit zou kunnen vertalen.

[ Voor 12% gewijzigd door Alarmnummer op 13-04-2005 10:17 ]

[EfBe]

TukkerTweaker schreef op woensdag 13 april 2005 @ 10:06:
De Hibernate documentatie over de te kiezen inheritance strategie laat mij een beetje in het duister tasten.

Het volgende is de sitatie.
Ik heb een super klasse Person en 2 subklassen Employer en Customer. 1 Person kan zowel Employer als Customer zijn maar ik wil de gegevens natuurlijk niet redundant opslaan. Welke strategie moet in hiervoor kiezen?
Voorwaarde is dat de klassen Person, Employer en Customer moet elk in een aparte tabel opgeslagen worden.

Die voorwaarde kan niet, want je wilt de data niet redundant opslaan. Je loopt nu tegen de discrepantie aan die bestaat tussen semantische inheritance in databases en type inheritance in code en verder verwar je entity en entity definitie.

In theorie kun je doen:
insert row P in person, insert row C in customer met FK naar P en insert row E in employee met FK naar P.

Echter, op dat moment sharen de entities C en E dezelfde data elements, nl. die in P. En dat kan niet, want een entity is een unieke verzameling data elements. Voor de types Customer en Employee maakt dit niet uit, echter voor de entities (de data!) wel.

Op dit moment gebruik ik joined-subclass maar daarmee voorkom ik niet de dubbele opslag van Person. Wat doe ik fout?

Wat je fout doet is voorwaarden stellen en dan de consequenties daarvan als oplosbaar probleem beschouwen met die restrictie dat de voorwaarden die als bron van de consequenties gelden als onaantastbaar te definieren. Dit houdt dus in dat het niet oplosbaar is.

Zodra je in je model tegenkomt dat een instance van subtype S1 van supertype Su semantisch ook van het type S2 kan zijn, is inheritance onmogelijk, tenminste in Java/.NET etc. want zoals je in deze zin ziet heb je multiple inheritance nodig: een SS1 type, dat erft van zowel employee als customer, want de entity die jij wilt creeeren moet beide typen hebben.

Doe dus zoals Alarmnummer zegt: creeer roles. En geloof me: de voorwaarden die jij stelt slaan echt nergens op: ze creeeren juist je probleem. Ze dan als absolute voorwaarde te positioneren zorg je er alleen maar voor dat een oplossing niet mogelijk is. Wie verzint zo'n model en die voorwaarden?

[TukkerTweaker]

EfBe schreef op woensdag 13 april 2005 @ 12:15:
[...]

Die voorwaarde kan niet, want je wilt de data niet redundant opslaan. Je loopt nu tegen de discrepantie aan die bestaat tussen semantische inheritance in databases en type inheritance in code en verder verwar je entity en entity definitie.

In theorie kun je doen:
insert row P in person, insert row C in customer met FK naar P en insert row E in employee met FK naar P.

Echter, op dat moment sharen de entities C en E dezelfde data elements, nl. die in P. En dat kan niet, want een entity is een unieke verzameling data elements. Voor de types Customer en Employee maakt dit niet uit, echter voor de entities (de data!) wel.


[...]

Wat je fout doet is voorwaarden stellen en dan de consequenties daarvan als oplosbaar probleem beschouwen met die restrictie dat de voorwaarden die als bron van de consequenties gelden als onaantastbaar te definieren. Dit houdt dus in dat het niet oplosbaar is.

Zodra je in je model tegenkomt dat een instance van subtype S1 van supertype Su semantisch ook van het type S2 kan zijn, is inheritance onmogelijk, tenminste in Java/.NET etc. want zoals je in deze zin ziet heb je multiple inheritance nodig: een SS1 type, dat erft van zowel employee als customer, want de entity die jij wilt creeeren moet beide typen hebben.

Doe dus zoals Alarmnummer zegt: creeer roles. En geloof me: de voorwaarden die jij stelt slaan echt nergens op: ze creeeren juist je probleem. Ze dan als absolute voorwaarde te positioneren zorg je er alleen maar voor dat een oplossing niet mogelijk is. Wie verzint zo'n model en die voorwaarden?

De voorwaarden (het relationele model) staan zo goed als vast, de implementatie is flexibel. Ik zocht in eerste instantie naar een super-subclass oplossing, misschien door gebrek aan OO of hibernate kennis van mijn kant.

[Eric Oud Ammerveld]

Ik zou gewoon gebruik maken van een aparte tabel EMPLOYEES.
Daarin kan je dan direct de nodige rechten toekennen en nog wat meer informatie opslaan.
Je kan uiteraard een relatie leggen naar een klantentabel zodat je ziet onder welke naam de medewerker als klant geregistreerd staat.

Ook zou ik klanten in groepen opdelen (aparte tabel KLANTTYPE) om kortingen te kunnen berekenen en om bijvoorbeeld EX btw facturen te maken.

Redundantie is een punt vandaar dat ik als ik jou was zou zorgen dat mijn medewerkers tabel verwijst naar de klanten tabel om daar de naw gegevens e.d. uit te vissen.

[Gert]

Je kan toch ook een Employer interface en een Customer interface maken en dan een Employer implementatie, een Customer implementatie en een CustomerEmployer implementatie. Of is dat erg fout?
Natuurlijk als je dan table-per-subclass gebruikt krijg je wel een boel heen en weer gekopieer zodra iemand van rol verandert.

[ Voor 25% gewijzigd door Gert op 14-04-2005 12:18 ]

[TukkerTweaker]

Gert schreef op donderdag 14 april 2005 @ 12:16:
Je kan toch ook een Employer interface en een Customer interface maken en dan een Employer implementatie, een Customer implementatie en een CustomerEmployer implementatie. Of is dat erg fout?

En wat dit lost op?

Natuurlijk als je dan table-per-subclass gebruikt krijg je wel een boel heen en weer gekopieer zodra iemand van rol verandert.

Dat doe ik nu dus al maar voorkomt niet de redundatie

[TukkerTweaker]

AADNOLL schreef op donderdag 14 april 2005 @ 12:14:
Ik zou gewoon gebruik maken van een aparte tabel EMPLOYEES.
Daarin kan je dan direct de nodige rechten toekennen en nog wat meer informatie opslaan.
Je kan uiteraard een relatie leggen naar een klantentabel zodat je ziet onder welke naam de medewerker als klant geregistreerd staat.

Ook zou ik klanten in groepen opdelen (aparte tabel KLANTTYPE) om kortingen te kunnen berekenen en om bijvoorbeeld EX btw facturen te maken.

Redundantie is een punt vandaar dat ik als ik jou was zou zorgen dat mijn medewerkers tabel verwijst naar de klanten tabel om daar de naw gegevens e.d. uit te vissen.

Zoals ik al vermeld had ben ik niet van plan (veel) te sleutelen aan het relationele model.

[Alarmnummer]

Tja.. ik denk als je niet van plan bent om iets aan je (slechte) model te veranderen, dat je maar op de blaren moet zien en accepteren dat er niets goeds uit voorkomt. Aan jou de keuze.

[TukkerTweaker]

Alarmnummer schreef op donderdag 14 april 2005 @ 12:49:
Tja.. ik denk als je niet van plan bent om iets aan je (slechte) model te veranderen, dat je maar op de blaren moet zien en accepteren dat er niets goeds uit voorkomt. Aan jou de keuze.

Het ontwerp van het model is op zicht niet slecht en ook niet aan mij om hier iets veel verandereningen in toe te passen. Op de blaren zitten doe ik ook niet, ik kies de beste implementatie voor het bestaande model waarmee ik prima uit de voeten kan.

[ Voor 4% gewijzigd door TukkerTweaker op 14-04-2005 13:06 ]

[Alarmnummer]

TukkerTweaker schreef op donderdag 14 april 2005 @ 13:05:
[...]
Het ontwerp van het model is op zicht niet slecht

*stilte*

en ook niet aan mij om hier iets veel verandereningen in toe te passen.

Tja...

Op de blaren zitten doe ik ook niet

Ik zou niet weten hoe hibernate dit zou kunnen mappen. Tenminste.. niet iets dat lekker werkt.

, ik kies de beste implementatie voor het bestaande model waarmee ik prima uit de voeten kan.

Tja... als je er prima mee uit de voeten kan dan had je dit topic ook niet hoeven openen. En verder zie ik dat jij een stuk multiple inheritance gebruikt en dat is in de meeste gevallen een indicatie dat er stront aan de knikker is.

[edit]
*Gaat ook niet meer in dit topic reageren*

[ Voor 5% gewijzigd door Alarmnummer op 14-04-2005 13:55 ]

[ravenger]

Aangenomen dat je het over inheritance in je datamodel hebt. Het doel van inheritance is namelijk dat je aangeeft in de subtabel dat de persoon die rol heeft die de subtabel beschrijft. De relatie tussen een sub en supertabel is 1op1. Wanneer je niet redundant wil zijn, sla je in je subtabel alleen de identifier van je persoon op en de specifieke attributen van het type die de subtabel beschrijft. Als dit niet is wat je bedoelt, dan is idd je model fout, en moet je toch roles toepassen.

(Correct me if im wrong tho )

[EfBe]

Alarmnummer schreef op donderdag 14 april 2005 @ 12:49:
Tja.. ik denk als je niet van plan bent om iets aan je (slechte) model te veranderen, dat je maar op de blaren moet zien en accepteren dat er niets goeds uit voorkomt. Aan jou de keuze.

Lol

Maar gelijk heb je. Ik erger me ook een beetje aan dit ge-emmer. WEL vragen om een oplossing, maar die dan niet accepteren want dat strookt niet met de zelf gestelde randvoorwaarden. Tja, dan houdt het wel een beetje op.

[EfBe]

ravenger schreef op donderdag 14 april 2005 @ 15:02:
Aangenomen dat je het over inheritance in je datamodel hebt. Het doel van inheritance is namelijk dat je aangeeft in de subtabel dat de persoon die rol heeft die de subtabel beschrijft. De relatie tussen een sub en supertabel is 1op1. Wanneer je niet redundant wil zijn, sla je in je subtabel alleen de identifier van je persoon op en de specifieke attributen van het type die de subtabel beschrijft. Als dit niet is wat je bedoelt, dan is idd je model fout, en moet je toch roles toepassen.

(Correct me if im wrong tho )

NEE dat kan niet! Je maakt dezelfde fout als de topicstarter . Lees aub mn eerste posting in deze thread maar. (en voor diegene die het niet snapt: voeg eens beide toe en dan daarna een van beide deleten... ooooooppsss )

[ Voor 7% gewijzigd door EfBe op 14-04-2005 18:09 ]

[momania]

De inherintence waarbij een instantie van een superclass beide implementaties kan zijn van een subclass is idd gewoon niet mogenlijk.

Zoals EfBe in zijn verhaal al prima uitlegde. Je kan het alleen maar zo scheiden als een class maar 1 van beide subclasses kan zijn.

Het datamodel klopt op deze manier dus van geen kant en er is dan dus ook geen mooie OO mapping in hibernate van te maken.