besoin d'aide sur la modélisation d'une relation "pseudo ternaire"

Version imprimable

08/04/2009, 01h39
johan_b

besoin d'aide sur la modélisation d'une relation "pseudo ternaire"

Bonjour à tous,
J'ai un petit souci de modélisation sur un projet perso dont voici les informations:
- un programme peut avoir plusieurs versions
- un programme a été développé par une ou plusieurs personnes
- Les programmeurs peuvent changer d'une version à l'autre
- dans certains cas, la version du programme n'est pas spécifiée (dû à un manque d'informations)

Au début j'ai pensé à faire la relation binaire suivante:
http://img227.imageshack.us/img227/3958/mcd1l.th.png
un programmeur participe à 0 ou n projets, avec une version indiquée pour un même projet. Un projet est réalisé par une ou plusieurs personnes.
Désolé pour le shéma, mais je n'ai pas les outils qu'il faut sosu la main, et je me suis peut être même trompé au niveau cardinalités (MERISE/UML... je mélange toujours :()

Avec la situation suivante ça devient problématique:
Si le développeur D travaille pour le projet A sur les version 1 et 2, mon SGBD va me crier dessus car il trouvera dans la table "participe" un doublon sur les clés primaires (il y aura deux fois le couple A/D pour une valeur du champs version différente).

Si maintenant j'utilise une relation ternaire, dans ma table "participe", j'aurai:
dev_id
prog_id
version
Les trois clés étant primaires. Le seul souci concerne la version:
Si je ne me trompe pas, le fait de déclarer "version" comme clé primaire, signifie qu'elle doit référencer une clé primaire dans une table "version" que je devrais créer.
Ici je ne vois pas l'utilité d'une telle table dans la mesure où les versions ne suivent pas une norme définie (format un peu batard, tout le monde met plus ou moins ce qu'il veut). A la limite, ça pourrait me permettre d'effectuer une sélection selon le critère de la version, mais je n'en ai pas besoin ici. Au final, il faudra juste pour un logiciel donné fournir le listing de toutes les versions et des participants (pas de filtre sur une version donc).
De plus, la version n'étant pas toujours mentionnée, le SGBD n'acceptera pas que je lui fournisse une valeur nulle qui ne correspond à aucune clé dans la table version.

Je suis donc bloqué à ce niveau, et mes souvenirs de modélisations se sont bien estompés (la preuve je n'ai même pas pu employer les bons termes pour décrire mon problème).
Si quelqu'un aurait la gentillesse de guider mes pas.
En vous remerkiant.
08/04/2009, 11h13
CinePhil

Procédons par étape en reprenant ton message...

Citation:

Envoyé par johan_b

- un programme peut avoir plusieurs versions

1) Programme -0,n----Avoir----1,1- Version

Citation:

- un programme a été développé par une ou plusieurs personnes

2) Personne -0,n----Développer----1,n- Programme

Citation:

- Les programmeurs peuvent changer d'une version à l'autre

Donc en fait l'association précédente (2) devient :
3) Personne -0,n----Développer----1,n- Version

Sauf si le fait de savoir qui a travaillé sur quelle version n'est pas important pour la gestion, auquel cas on peut se contenter du schéma 2.

Citation:

- dans certains cas, la version du programme n'est pas spécifiée (dû à un manque d'informations)

La cardinalité 0,n du schéma 1 respecte cette possibilité : un programme peut ne pas avoir de version.

Au début j'ai pensé à faire la relation binaire suivante:
http://img227.imageshack.us/img227/3958/mcd1l.th.png
un programmeur participe à 0 ou n projets, avec une version indiquée pour un même projet. Un projet est réalisé par une ou plusieurs personnes.[/quote]
C'est aussi une possibilité, et tu as perçu les difficultés plus loin.

Citation:

je me suis peut être même trompé au niveau cardinalités (MERISE/UML... je mélange toujours :()

MCD Merise : "on s'arrête à la patate !" comme disait mon prof.
A -x,y----Associer----w,z- B

Combien de fois A peut entrer en jeu dans l'association ? ==> mini = x et maxi = y

Ca se lit :
- 1 A est au minimum x fois et au maximum y fois associé à B
- 1 B est au minimum w fois et au maximum z fois associé à A

UML : On va jusqu'au bout du trait donc c'est inversé par rapport à Merise.
A -w..z-----------x..y- B
Ca se lit :
- 1 A est associé à B au minimum x fois et au maximum y fois
- 1 B est associé à A au minimum w fois et au maximum z fois

Citation:

Avec la situation suivante ça devient problématique:
Si le développeur D travaille pour le projet A sur les version 1 et 2, mon SGBD va me crier dessus car il trouvera dans la table "participe" un doublon sur les clés primaires (il y aura deux fois le couple A/D pour une valeur du champs version différente).

Si maintenant j'utilise une relation ternaire, dans ma table "participe", j'aurai:
dev_id
prog_id
version
Les trois clés étant primaires. Le seul souci concerne la version:
Si je ne me trompe pas, le fait de déclarer "version" comme clé primaire, signifie qu'elle doit référencer une clé primaire dans une table "version" que je devrais créer.

Oui.

Citation:

Ici je ne vois pas l'utilité d'une telle table dans la mesure où les versions ne suivent pas une norme définie (format un peu batard, tout le monde met plus ou moins ce qu'il veut).

Ca c'est pas grave ! La clé primaire sera un entier auto-incrémenté.

Citation:

A la limite, ça pourrait me permettre d'effectuer une sélection selon le critère de la version, mais je n'en ai pas besoin ici. Au final, il faudra juste pour un logiciel donné fournir le listing de toutes les versions et des participants (pas de filtre sur une version donc).

Tu veux dire tous les participants au programme et on se fout de savoir sur quelle version ?
Peut-être qu'un jour tu voudras le savoir et ce sera facile d'interroger la BDD déjà correctement modélisée.
Quoi qu'il en soit, je pense que l'entité Version est importante.

Citation:

De plus, la version n'étant pas toujours mentionnée, le SGBD n'acceptera pas que je lui fournisse une valeur nulle qui ne correspond à aucune clé dans la table version.

Là est la vraie difficulté.
Tu peux déterminer qu'un programme a au moins une version et donner une valeur par défaut à cette version telle que V0.1 par exemple.

Le schéma devient donc :
Programme -1,n----Avoir----1,1- Version -1,n----Développer----0,n- Personne

Ce qui donne les tables :
Personnes(Per_Id, Per_Nom, Per_Prenom, ...)
Programmes(Prg_Id, Prg_Nom, ...)
Versions(V_Id, V_IdProgramme, V_Code, V_Objet, ...)
Avoir(A_IdVersion, A_IdProgramme)
Developper(D_IdPersonne, D_IdVersion)

Citation:

mes souvenirs de modélisations se sont bien estompés

Pas tant que ça !
08/04/2009, 12h12
johan_b

Merci pour la piqure de rappel!

Citation:

Envoyé par CinePhil

Tu veux dire tous les participants au programme et on se fout de savoir sur quelle version ?

Oui et non en fait. On s'en fou dans le sens où le version n'entre pas en compte comme critère de recherche/sélection/filtrage, par contre c'est une valeur qui sert de détail pour préciser (si l'information est disponible) sur quelle version a participé une personne.

Citation:

Envoyé par CinePhil

Peut-être qu'un jour tu voudras le savoir et ce sera facile d'interroger la BDD déjà correctement modélisée.
Quoi qu'il en soit, je pense que l'entité Version est importante.

C'est vrai qu'en terme d'évolution c'est un plus, mais j'avoue que le fait d'avoir un manque de normalisation ou d'information à propos des versions ne me donnait pas vraiment envie de créer une table pour ça.
En ce qui cerne les valeurs nulles, tu me propose de créer une valeur par défaut dans la base pour les gérer? Du genre (version_ID=0,version_libelle="n/a") ?
J'y avais pensé au début, mais ça implique une gestion supplémentaire au niveau du code qui n'est pas très propre, car on doit soit définir l'ID 0 dans le code comme une constante, soit rechercher dans la base l'ID qui correspond à la version "n/a" , du coup on a une forte dépendance entre la base et le code.
J'avais pensé à remplacer le "n/a" par une chaine vide, du coup quand on recherche une version non informée, on recherchera la chaîne vide dans la base qui donnera l'ID 0 (un peu moins de dépendance).
Sinon un trigger sur les requêtes INSERT dans VERSION qui , lorsque version_libelle est vide, recherche la valeur par défaut et retourne l'ID 0 sans insérer la valeur... Mais là j'avoue que je ne suis pas capable de faire une telle chose, et je ne sais même pas si c'est possible ^^.

Citation:

Envoyé par CinePhil

Le schéma devient donc :
Programme -1,n----Avoir----1,1- Version -1,n----Développer----0,n- Personne

Ce qui donne les tables :
Personnes(Per_Id, Per_Nom, Per_Prenom, ...)
Programmes(Prg_Id, Prg_Nom, ...)
Versions(V_Id, V_IdProgramme, V_Code, V_Objet, ...)
Avoir(A_IdVersion, A_IdProgramme)
Developper(D_IdPersonne, D_IdVersion)

J'étais parti sur cette forme au début, mais il y avaient des choses qui me dérangeaient dedans. Au final je ne vois plus vraiment quoi, ça m'a l'air très bien

Citation:

Envoyé par CinePhil

Pas tant que ça !

Merci :)

Solution retenue et adjugée. Merci pour les réponses :D
08/04/2009, 16h45
CinePhil

Citation:

Envoyé par johan_b

En ce qui cerne les valeurs nulles, tu me propose de créer une valeur par défaut dans la base pour les gérer ? Du genre (version_ID=0,version_libelle="n/a") ?
J'y avais pensé au début, mais ça implique une gestion supplémentaire au niveau du code qui n'est pas très propre, car on doit soit définir l'ID 0 dans le code comme une constante, soit rechercher dans la base l'ID qui correspond à la version "n/a" , du coup on a une forte dépendance entre la base et le code.

Je ne pensais pas un un ID 0 mais à une valeur par défaut du code de version. Ca peut tout simplement être une date. Et une valeur par défaut peut être attribuée directement par le SGBD sans que le code n'ait à intervenir.

Oui ! mais oui! Je suis trop bête. en fait j'avais une idée en tête qui voulait pas partir, et là tu m'as éclairé d'un coup soudain. Bon j'avais commencé à écrire une réponse (ci-dessous) qui s'avère être fausse, mais j'ai voulu laisser le raisonnement (ça peut toujours servir derrière).
Merci encore :)
Citation:
C'est un peu plus subtile que ça en fait (ou alors il me manque des billes).
Dans mon code, avant chaque insertion, je vérifie l'existence d'un élément.
ça donnerait rapidement ça:
Code:

1 2 3 4 5 6 7 8 9 10 Si logiciel_libelle existe dans la base alors recuperer id Sinon inserer nouveau logiciel et recuperer l'ID Si version_libelle existe dans la base alors recuperer id Sinon inserer nouvelle version et recuperer l'ID inserer dans avoir(id_programme,id_version)
On va aussi modifier la table version pour mettre la valeur "inconnue" lorsque version_libelle est nul.
Imagine que je rentre un logiciel sans version pour la première fois (une valeur version_libelle à nulle donc). La recherche de version_libelle ne va retourner aucun résultat, et donc mon code va insérer un nouvel enregistrement. Si je n'intervient pas au niveau du code, il va y avoir une insertion de la valeur "inconnue" avec création d'un ID.
Maintenant si je rajoute un nouveau logiciel avec une version nulle, on va encore rechercher version_libelle="". Or ici, aucun résultat ne sera retourné puisque la première insertion vaut "inconnue". Mon code va alors insérer une nouvelle valeur à "inconnue", du coup redondance de valeur au lieu de récupérer l'ID de la première version "inconnue" enregistrée....
Et là je me suis rendu comte de ma bêtise :p
Eh oui, en fait c'est pas plus mal qu'il y ait redondance, car si la table version décrit d'autres informations (comme par exemple le code utilisé comme tu l'avais proposé), on a bien affaire à deux enregistrement différents. Et puis si on retrouve la version du logiciel par la suite, on peut la modifier sans refaire toute une insertion et modifier les ID correspondants.

Je me suis butté sur le fait qu'une version inconnue était la même pour tous, gens une constante par exemple.

08/04/2009, 17h39
CinePhil

Eh oui ! Si tu regardes les cardinalités de mon mini MCD, une version dépend du programme (cardinalité 1,1). La version code 'V1.0' du programme 'Hello World' n'est pas la même que la version 'V1.0' du programme 'Gestion boursière'.