Discussion :

[pasgroumpf]

Salut à tous

Je viens de démarrer un nouveau projet et je bloque sur un truc assez raide.
Il faut que je stocke en base de données des objets Java. Le truc c'est que les objets peuvent contenir des listes (une ou plusieurs) de données dont le type n'est pas fixé (seul point commun, il héritent tous d'une même superclasse, ce qui permet de conserver un typage de données).
Le truc, c'est :

1. Comment faire pour stocker ces données en base en conservant un modèle relationnel propre (visiblement 3 grandes écoles : une table fourre-tout, une table par classe finale, une table par classe effective : http://www.ibm.com/developerworks/li...apping-to-rdb/)
2. Comment garder un lien entre chaque objet qui permette lorsqu'on supprime le parent, de supprimer tous les enfants (comme le type final de données n'est pas connu, les données peuvent se trouver dans différentes tables, donc difficile de créer des FK dans ces conditions....)

Merci d'avance de vos lumières

[ok.Idriss]

Bonjour.

Comment faire pour stocker ces données en base en conservant un modèle relationnel propre

Les collections (ou listes) deviennent des associations 0/1,N --- 0/1,N au niveau conceptuel (on aura donc une table associative au niveau relationnel).
Les attributs uniques qui expriment un lien unique dans une autre classe deviennent des clefs étrangères au niveau relationnel.

Pour être plus claire, un exemple :

• Si tu as une classe livre et une classe auteur qui contient une ArrayList de livre en Java => tu auras une table livre, une table auteur et une table associative avec deux clefs étrangères vers les tables auteur et livre.
• Si tu as un attribut auteur dans la classe livre => tu auras une clef étrangère dans la table livre qui pointe vers la table auteur. Si l'attribut n'est pas toujours renseignés (association 0,1 --- 0/1,n) il sera mieux de créer une table associative.

Comment garder un lien entre chaque objet qui permette lorsqu'on supprime le parent, de supprimer tous les enfants

Avec triggers et des procédures stockées tu peut t'arranger .

Pour le problème de typage, tu peut créer une méthode qui te permet de récupérer les types et faire les INSERT en fonction de ce type retourné. Tu peut aussi gérer l'héritage avec tes tables.

Cordialement,
Idriss

[CinePhil]

Il faut que je stocke en base de données des objets Java.

Dans une base de données, on ne stocke pas des objets Java mais des données qui sont cohérentes du point de vue sémantique.

La bonne démarche consiste à modéliser les données (MCD Merise ou Diagramme de classes UML) puis à implémenter ce schéma en BDD pour assurer la solidité, la cohérence, l'intégrité des données.

Ensuite, une ou plusieurs applications accèdent à ses données selon des critères organisationnels (une commande avec les coordonnées du client). On n'en parle presque jamais mais il existe dans la méthode Merise le modèle organisationnel des données, lequel peut s'implémenter en BDD à l'aide des vues (permettant effectivement de rassembler les données de la table des commandes, de la table des lignes de commande et de la table des clients, voire d'autres tables de références telles que la ville, les taux de TVA, les adresses et autres téléphones...). Et ce sont ces vues qui peuvent coller aux objets Java (ou autre langage de programmation).

À noter qu'on peut très bien faire de l'héritage de tables dans un SGBDR. Là encore, c'est grâce au mécanisme des vues qu'on va rassembler les propriétés (pour parler objet) de la table fille et de la table mère.

Vouloir partir des classes Java pour construire la BDD, comme le suggère par exemple Hibernate, ça fonctionne pour des modèles de données très simples mais c'est très casse gueule dès qu'on a un modèle un peu plus complexe.

[pasgroumpf]

Salut et merci de vos réponse

Juste une précision : je viens de démarrer sur ce projet et en fait le logiciel Java (donc les classes) existe déjà et il faut les stocker en base. Je ne peux donc pas créer un modèle propre et voir comment je l'implémente. Je bosse dans un cadre déjà figé, que je ne peux absolument pas modifier. En fait il faut que je bidouille pour faire au mieux avec la BDD, j'ai pas vraiment le choix :-(
Ah oui, dernière précision : les objets doivent être dé-sérialisés. Impossible au pire (même si c'est moche je sais ) de les stocker de façon sérialisés sous forme de BLOB...

Pour être plus clair, un exemple :

• Si tu as une classe livre et une classe auteur qui contient une ArrayList de livre en Java => tu auras une table livre, une table auteur et une table associative avec deux clefs étrangères vers les tables auteur et livre.
• Si tu as un attribut auteur dans la classe livre => tu auras une clef étrangère dans la table livre qui pointe vers la table auteur. Si l'attribut n'est pas toujours renseignés (association 0,1 --- 0/1,n) il sera mieux de créer une table associative.

Le problème en fait pour reprendre ton exemple, c'est qu'auteur peut avoir une collection d'objets au sens large, qui peuvent être des livres, des CDs, des DVDs, des pommes et des oranges (je sais c'est le bordel ) voir même des auteurs (on peut donc avoir théoriquement des listes infinies). Comme on a une table pour chaque type de classe, impossible pour moi de faire de l'association 1.n classique comme habituellement. Ou alors je crée une classe fourretout avec 500 millions de champs mais c'est crade.

Avec triggers et des procédures stockées tu peut t'arranger .

C'est effectivement ce que je pensais faire, ça me rassure que tu m'en parles ^^

Dans une base de données, on ne stocke pas des objets Java mais des données qui sont cohérentes du point de vue sémantique.

Effectivment, je parlais de stocker les objets pour aller plus vite, mais en fait je stocke les données métier cohérentes et non "recalculables"

[ok.Idriss]

Bonjour.

Le problème en fait pour reprendre ton exemple, c'est qu'auteur peut avoir une collection d'objets au sens large, qui peuvent être des livres, des CDs, des DVDs, des pommes et des oranges (je sais c'est le bordel ) voir même des auteurs

Je me permet de re-citer mon post :

Pour le problème de typage, tu peut créer une méthode qui te permet de récupérer les types et faire les INSERT en fonction de ce type retourné. Tu peut aussi gérer l'héritage avec tes tables.

Il est toujours possible de s'arranger. Il s'agit de quel type d'héritage pour tes tables ? Héritage par partition ? exclusion ? ou couverture ? À priori il s'agit d'un héritage par partition étant donné que tes objets héritent tous d'une super-classe et sont uniques.

Après, au niveau de ta base de donnée, tu gère cet héritage au niveau conceptuel puis au niveau relationnel. Et tu crée dans la classe qui contient la collection, une méthode permettant de retourner le type au format chaîne de caractère avec en paramètre l'indice de l'objet de ta collection. Et en fonction de ce type retourné, tu feras les INSERT.

Cordialement,
Idriss

[CinePhil]

Une modélisation se fait sur du concret.
Tu peux nous en dire un peu plus sur le contenu des "objets" et sur leur structure ?

[pasgroumpf]

Bon finalement ne vous cassez pas la tête : on me demande de voir comment améliorer le merdier et au final, aucune marge de manoeuvre
Donc ça restera en l'état, et merde ^^
Merci quand même les mecs :p