Modélisation Objet de Table et Relation (BDD)

Bonsoir à tous,

Actuellement face à un dilemme, je me tourne vers vous pour trouver réponse à mes questions. Je travaille actuellement sur la mise en base des configurations utilisateurs
d'une application.
Pour cela j'ai mis en place le schéma en pièce-jointe. L'objectif étant que chaque Utilisateur puisse avoir X Config et que chaque Config puisse être utilisé par X Utilisateurs. Et bien sur, qu'une Config soit dissociée de son utilisation.

J'ai écrit les objets métiers Utilisateur et Config tel qu'ils sont représentés dans la base de données (champs).
Mon objet Utilisateur doit contenir l'ensemble des configurations qui lui sont associées, et c'est la que j'ai besoin de vous car je ne trouve pas de méthode qui me convienne.
Mon problème, c'est que je ne peux pas utiliser un ensemble d'objet Configuration, car ce dernier ne contient pas les champs contenus dans ma relation représentée par la table ConfigUtilisateurs.

Je vois donc deux possibilités:
- Créer un objet ConfigUtilisateur qui contient les champs de la relation + un objet Config. Mon objet Utilisateur contiendrait alors un ensemble de ConfigUtilisateur.
- Créer un objet ConfigUtilisateur héritant de Config et enrichissant la classe mère des champs de la relation.

Je suppose qu'il existe bien d'autres méthodes, pourriez vous me faire connaître les votres ? Que me conseillez vous ?

Merci d'avance

Si j'ai bien compris, le schéma passé en pièce jointe est ton modèle de BD.

Tu peux tout à fait écrire un DAO qui va charger les données depuis la base et remplir un modèle ressemblant à celui-ci :

Utilisateur
- infos de l'utilisateur
- liste de Config

Config
- infos de configuration


Dans ce cas, ta base de données contient les trois tables Utilisateur, Config et ConfigUtilisateur, mais ton DAO 'mappe' ca vers un modèle plus 'agréable' à deux classes.

Vu que ta table qui fait le lien entre Utilisateur et Configuration possède des colonnes (Droits notamment), la modélisation UML de tout ceci est assez similaire à ce que tu as fais au niveau base de données.

Utilisateur 0..*_____________ 0..* Config
|
|
ConfigUtilisateur

ConfigUtilisateur est dite "classe d'association" (on parle de table d'association côté base de données)

NB : les 2 traits verticaux, s'ils sortent mal une fois la réponse publiée sont à imaginer au milieu de l'association entre Utilisateur et Config (pas au niveau de Utilisateur)

Au niveau de ta classe Utilisateur, dans le code, tu auras une "List<ConfigUtilisateur>"; cette liste comportant autant de ConfigUtilisateur que l'Utilisateur a de Config. Dans ConfigUtilisateur, tu as une référence vers la Config que cette ConfigUtilisateur caractérise.

Comme l'a dit hed62, une couche d'accès à ta base de données te permettra de créer les bons objets à partir de tes tables.

Merci à vous deux pour avoir confirmé mon idée de départ.
Je suis passé à l'implémentation Java hier.

J'ai donc 3 objets :
Config -> la config
UserConfig -> champs de la table + objet Config
User -> avec sa List<UserConfig>

ça correspond bien à ce que Ego vient de me donner ce matin, me voilà donc serein.

Encore merci.