Version imprimable
voila j'ai une modélisation a faire mais je ne vois pas comment traduite la redondance des niveaux.
Voila le schema ressemble a sa ( voir la pièe jointe ) et bien évidement le Projet B et C sont divisés en plusieur Sous projet et chaque sous projet a un chef de projet
et sa se decline a l'infinie.
A chaque niveau de chef de projet nous avons du reporting a faire .
Voila c'est sa que je narrive pas a modéliser en MCD vous aurais des idé ?
merci a tous le monde
voila ce a quoi je pensais mais sa m'a lair bien leger pour la complexité qu schema. donnez moi votre avis ??
Bonjour,
Si chaque sous projet (ou projet) a un chef de projet (et non pas plusieurs), la cardinalité 1,n de l'association GERE du côté PROJET devrait être 1,1.Citation:
Envoyé par imsse
Bon, réfléchissons un peu. Le premier projet de la hiérarchie a des sous projets qui eux-même ont des sous projets qui eux-même ont des sous projets, etc. Exemple :Citation:
Envoyé par imsse
A a pour sous projets B et C. Donc A est un projet et B et C sont des sous projets. B a pour sous projets D et E. Donc B est un projet.Code:
2
3
4
5
6A / \ B C / \ /|\ D E F G H
B est-il un projet ou un sous projet ?
Cette question est posée pour B mais on peut la poser pour C, et aussi pour D, si l'on considère que D a des sous projets qui ne sont pas représentés sur l'exemple. Et donc aussi pour E, F, G et H.
Le tort, dans ce genre de problème, est de penser qu'on a des projets et des sous projets, alors qu'en fait, il n'y a que des projets. La notion de sous projet n'est que relative. En effet, si on "zoome" sur un lien particulier (le lien rouge A --> C par exemple) on peut dire que C est sous projet de A, mais c'est une considération locale. Si on regarde l'ensemble de l'arbre hiérarchique, cette notion doit disparaître pour les raisons invoquées ci-dessus à propos du projet B.
La modélisation, pour prendre en compte ces arguments, doit donc répondre à la règle suivante :
Tout projet peut avoir un projet "père" et des projets "fils".
En fait :
- tout projet a un père sauf celui qui est hiérarchiquement le plus haut
- tout projet a un ou plusieurs fils sauf ceux qui sont hiérarchiquement les plus bas (et qui n'en ont pas)
Comment modéliser cela ? Tout simplement en suivant la règle énoncée ci-dessus : un projet a 0 ou 1 projet "père" et 0 à n projets "fils". On a une seule entité PROJET, une assosiation réflexive et les cadinalités 0,1 d'un côté et 0,n de l'autre.
Pièce jointe 20651
JPhi33
Première chose je te remercie de t'être intéressé à mon sujet.
Pour repondre à cela comme tu le disais plus bas B d'un point de vue globale est sous projet de A mais il est lui meme un projet à par entière et est gérer et traiter de la meme manière que A.Citation:
B est-il un projet ou un sous projet ?
Toute ton explication à était tres clair pour moi concernant l'association reflexive mais la question que je me demander c'est comment d'un point de vue modélisation faire la distinction entre les projets qui sont sous projet de projet. C'est a dire comment différencier les niveaux hierachique dans ton schema entre A et B.
Car au final je dois etre capable de dire quel projet est sous projet de A par exemple, alors je me dis que avec l'association reflexive j'aurais une table qui stockera tous les projet + sous projet ( car ceux sont eu meme des projet) donc je ne pourais pas faire la différence.
pourais je par exemple rajouter une table fictive qui aura la meme structure que celle de PROJET ?
Merci pour ton aide et ta reponse.
Une façon d’être certain qu’un projet est aussi un sous-projet est de définir une entité-type associative Composition. Qui plus est, cela vous évitera d’avoir à gérer les valeurs "nulles" au niveau de la base de données, car ce sont de véritables plaies.
Dans Composition ne figurent jamais les éléments "racines", à savoir les projets.
MCD et MLD :
http://img299.imageshack.us/img299/5...emcdmldjo4.jpg
C'est exactement ce que je recherchais pour faire la distinction entre les deux notions de projet et sous projet.
je dois ajouter deux tables chef de projet et reporting c'est pour cela que javais du mal a faire la distinction entre projet et sous projet.
- un projet a un chef de projet et un sous projet a aussi un chef de projet.
- un chef de projet peut gérer a la fois un projet et un sous projet cad un parent et un fils.
- on fait du reporting du projet parent ( cad que lon doit prendre en compte les données des projet fils) et on peur faire du reporting des projet fils seulement
mon MCD traduit bien mes regles de gestion ?
Pas de problème.Citation:
Un projet a un chef de projet et un sous projet a aussi un chef de projet.
Cela ne fait-il pas double emploi avec la règle précédente ? Ou alors s’agit-il d’exprimer la cardinalité 1,N de la patte connectant GERE et CHEF DE PROJET ?Citation:
. un chef de projet peut gérer a la fois un projet et un sous projet cad un parent et un fils.
Pas de problème. A condition bien sûr d’exploiter l’entité-type associative Composition via la relation Compose.Citation:
on fait du reporting du projet parent ( cad que lon doit prendre en compte les données des projet fils)
OK.Citation:
et on peur faire du reporting des projet fils seulement
Observations
1. Il manque sur votre graphique la cardinalité 0,1 de la patte connectant PROJET et Est sous projet de.
2. J’avais utilisé le symbolisme De PowerAMC pour exprimer le fait que Composition est identifiée relativement à PROJET (cardinalité 1,1 mise entre parenthèses). En revanche, votre propre entité-type Composition n’est pas identifiée.
3. La relation Effectue est a priori redondante, puisque, pour un reporting donné, on sait déterminer le chef de projet via les relations Donne lieu et Gère. La relation Effectue ne se justifierait que si le reporting était effectué par un chef de projet qui ne serait pas le "titulaire" du projet concerné. Ceci entraînerait alors la mise en œuvre d’une contrainte d’exclusion entre les relations Effectue et Gère (Celui qui effectue le reporting n’est pas celui qui gère).
Maintenant, certains aiment bien le côté bande dessinée des représentations graphiques, aussi, si celui qui effectue le reporting est nécessairement celui qui gère, alors on peut exprimer cela par une contrainte d’inclusion entre Effectue et GERE. Bien évidemment cela sautera au niveau MLD, puisqu’il faudra alors évacuer les redondances ornementales.
tres bien je vous remercie pour vos remarques, en effet je n'ai pas noté une cardinalité sur mon MCD ( simple oublie) et jenleverais la relation effectue.
Merci a vous deux pour vos reponses tres completes.
