Discussion :

[AiDuK]

Bonjour,

Je suis actuellement en train de travailler sur une base de données pour réaliser un programme de gestion de projet.

Pour résumer, un membre peut créer un projet, il passe alors chef de projet.

Le projet, peut par la suite et a tout moment être découpée en taches. Donc a ce moment la, utilisation de l'identification relative.

De même, a tout moment, une tache peut etre séparée en sous tache. Même chose, utilisation de l'identification relative entre table et sous tache.

Par contre, je bloque depuis plusieurs jours sur le point suivant qui fait que le chef de projet peut a l'infini séparer une sous tache en plusieurs sous taches, et la, je ne vois pas du tout comment gerer ca.

C'est pourquoi je vous contacte.
J'espère que vous pourrez m'aider, et me débloquer.

Merci d'avance,


AiDuK


PS : si vous avez besoin d'autres renseignements, je me tiens a votre disposition

[CinePhil]

un membre peut créer un projet

Je dirais plutôt qu'un membre peut créer plusieurs projets un qu'un projet est créé par un seul membre. Non ?
membre -0,n----créer----1,1- projet

Le projet, peut par la suite et à tout moment être découpé en tâches.

projet -0,n----découper----1,1- tache

Donc a ce moment la, utilisation de l'identification relative.

Soit, faisons ça :
projet -0,n----découper----(1,1)- tache

De même, a tout moment, une tache peut etre séparée en sous tache.

tache -0,n----diviser----0,1- tache

Même chose, utilisation de l'identification relative

Soit, faisons ça :
tache -0,n----diviser----(0,1)- tache

A noter qu'avant l'implantation en BDD, vous devriez regarder du côté de la modélisation d'aroborescence.

[AiDuK]

Bonjour,

Tout d'abord, merci d'avoir prit le temps de répondre a mon problème.

Citation:
un membre peut créer un projet
Je dirais plutôt qu'un membre peut créer plusieurs projets un qu'un projet est créé par un seul membre. Non ?
membre -0,n----créer----1,1- projet

Un membre peut créer un ou plusieurs projets, et un projet ne peut être crée que par un et un seul membre. Ça je suis d'accord, mais n'étant pas la base de mon problème, je ne l'avais pas spécifié.

Citation:
De même, a tout moment, une tache peut etre séparée en sous tache.
tache -0,n----diviser----0,1- tache

Citation:
Même chose, utilisation de l'identification relative
Soit, faisons ça :
tache -0,n----diviser----(0,1)- tache

Donc utilisation d'association réflexive et d'identification relative pour la séparation de tache en sous tache ? C'est faisable ca ?

PS : désolé pour les quelques fautes d'orthographe, mais écrivant sur un clavier qwerty, e n'est pas très pratique pour les accents, du coup, je corrige avec le correcteur windows, mais quelques erreurs subsistent.

Merci,


AiDuK

[fsmrel]

Bonjour AiDuK,


L’organisation des tâches en sous-tâches correspond à une hiérarchie (vu le contexte Qwerty, nul ne saurait vous tenir rigueur d’écrire « tache »).

Par ailleurs, vous souhaitez peut-être connecter une tâche (racine) à un projet. Un MCD de ce genre pourrait convenir, dans lequel le terme TACHE désigne aussi bien une tâche (racine) qu’une sous-tâche :



(Cette représentation a été effectuée avec Power AMC).


Bien entendu, seule une tâche (racine) est en relation directe avec un projet.

MLD correspondant :



N'hésitez pas si vous avez des questions.

[AiDuK]

Bonsoir,

J'ai relu plusieurs fois votre réponse, et j'avoue que cela n'est pas encore tout a fait limpide pour moi.

Cela vient du fait que je ne visualise pas correctement les cardinalitées de votre schéma, ainsi que le sens des liaison de l'entité 'hiérarchie'.

Dans le fonctionnement, l'entité 'hiérarchie' permet de retrouver la tache parente d'une tache précise (par tache, j'entends aussi sous-tache).

Mais du coup, si l'on a plusieurs projets différents en cours, l'on ne peut identifier directement par sa clé primaire le projet auquel une tache appartient.

Pardonnez moi si je fais preuve de certaines sottises en la matière, mais mon Merise est un peu rouillé, et j'essaie de faire quelque chose qui dépasse un peu les connaissances que j'avais acquises.

En tout cas, merci beaucoup de vous pencher sur mon problème et de m'apporter vos connaissances en la matière.

Cordialement,



AiDuK

[CinePhil]

Je vais essayer de traduire le schéma entité/relation de fsmrel en MCD Merise plus classique...

Tâche -(1,1)----Affecter----0,n- Projet

et

Tâche -0,n----Composer----(1,1)- Hiérarchie
|------0,1----Etre----------(1,1)------|

[AiDuK]

L'entité hiérarchie me pose toujours problème dans la compréhension.
Don si je comprends bien, c'est une association réflexive.
Mais ses deux branches : être et composer sont encore mystérieuses pour moi dans leur utilisation et dans les migrations des clé.

[fsmrel]

Bonjour,

Je vais essayer de traduire le schéma entité/relation de fsmrel en MCD Merise plus classique...

Tâche -(1,1)----Affecter----0,n- Projet

et

Tâche -0,n----Composer----(1,1)-- Hiérarchie
|------0,1----Etre---------(1,1)-----|

Juste deux petites remarques :

Selon la représentation graphique que j’ai utilisée (E/R), Tâche n’est pas identifiée relativement à Projet (mais ça reste possible).

Hiérarchie n’est pas identifiée relativement à Tâche via l’association-type Composer, mais seulement via l’association-type Etre.

=>

Tâche -1,1----Affecter----0,n- Projet

et

Tâche -0,n----Composer----1,1- Hiérarchie
|------0,1- ---Etre--------(1,1)------|

En dessinant de façon traditionnelle :



Pour en revenir au MLD, celui-ci donne lieu à l’extension suivante :

si l'on a plusieurs projets différents en cours, l'on ne peut identifier directement par sa clé primaire le projet auquel une tache appartient.

Selon la table AFFECTATION, les tâches t1 et t2 relèvent du projet p1, tandis que la tâche t3 relève du projet p2.

[CinePhil]

OK alors on va faire ça avec un exemple de données, à partir du MLD de fsmrel :

Soit le projet suivant dans la table PROJET :
ProjetId / ProjetNom
1 / 'Cours Merise'

Je crée une tâche dans la table TACHE :
TacheId / TacheNom
1 / 'Faire tutoriel'

J'affecte la tâche au projet 'Cours Merise' dans la table AFFECTATION :
TacheId / ProjetId
1 / 1

Je crée une sous-tâche dans la table TACHE :
TacheId / TacheNom
2 / 'Faire exemple MCD'

J'affecte la sous-tâche au projet 'Cours Merise' dans la table AFFECTATION :
TacheId / ProjetId
2 / 1

Je hiérarchise la tâche et la sous-tâche dans la table HIERARCHIE :
TacheId / TacheParenteId
2 / 1
==> La tâche 1 est parente de la tâche 2.

Je constate au passage que mon MCD était légèrement faux par rapport au MLD. La première association serait plutôt celle-ci je pense :
Tâche -(1,n)----Affecter----0,n- Projet

Il est supposé ici qu'une tâche peut être affectée à plusieurs projets. Ainsi, la tâche {1, 'Faire tutoriel'} pourrait aussi être affectée au projet {2, 'Cours PHP'}.

EDIT : Réponse simultanée avec fsmrel.
Ci-dessus, je me référais au premier MLD comportant une table AFFECTATION alors qu'à mon avis le dernier MCD de fsmrel :
TACHE -1,1----AFFECTER----1,n- PROJET

Ne génère pas une table AFFECTATION mais seulement une clé étrangère faisant référence à l'identifiant du projet dans la table TACHE.

[fsmrel]

L'entité hiérarchie me pose toujours problème dans la compréhension.
Don si je comprends bien, c'est une association réflexive.
Mais ses deux branches : être et composer sont encore mystérieuses pour moi dans leur utilisation et dans les migrations des clé.

C’est effectivement une association-type réflexive. J’espère que l’exemple ci-dessus vous aidera dans la compréhension de la représentation.

Le 1er MCD que j’ai proposé peut paraître hermétique, mais par contraste avec le second, plus classique, il offre l’avantage que nous n’ayons pas à retoucher le MLD pour arriver à celui que j’ai proposé dans mon 1er message.

[fsmrel]

Ne génère pas une table AFFECTATION mais seulement une clé étrangère faisant référence à l'identifiant du projet dans la table TACHE.

Ciel ! N’en faites rien !

En effet, soit vous injectez des redondances à contrôler (chaque sous-tâche devra impérativement faire référence elle aussi au projet référencé par sa maman). Ceci correspond à la représentation Merise classique que j’ai proposée en second, que je n’aime pas, et pour laquelle la cardinalité 1,1 portée par la patte connectant TACHE et AFFECTER devrait être remplacée par 0,1 (ce qui serait plus conforme, mais alors vous passez de Charybde à Scylla, car vous demandez alors au bonhomme NULL de se manifester).

Si le 1er MCD que j’ai proposé paraît hermétique (tandis que le 2e donne lieu à un MLD infecté par le bonhomme NULL en relation avec la réflexive), voici une représentation alternative, avec mise en œuvre des entités-types AFFECTATION et HIERARCHIE, quitte à bricoler le MLD résultant pour en éliminer les cycles et retrouver ainsi le MLD initial :



AiDuK, si vous avez besoin de compléments d’explications, n’hésitez pas à poser vos questions.

[AiDuK]

Encore merci de l'aide que vous m'apportez.

En ce qui concerne la table 'affectation', je ne comprends pas bien son utilité puisque normalement, le clé primaire de la table projet devrait migrer en clé primaire - étrangère de la table tache (projet 0,N --comporter-- (1,1) tache).

Pour apporter une clarification, une tache ou sous tache ne peut appartenir qu'a un et un seul projet.

Et dans ton MCD, je ne vois pas trop le fonctionnement de hiérarchie, si c'est une table ou autre.

PS : quel logiciel utilisez vous pour faire vos MCD svp ?

[fsmrel]

quel logiciel utilisez vous pour faire vos MCD svp ?

Comme je l’ai précisé dans mon 1er message, il s’agit de Power AMC.

Pour apporter une clarification, une tache ou sous tache ne peut appartenir qu'a un et un seul projet.

On est bien d’accord, mais si l’on connaît le projet auquel est affectée une tâche, alors par induction, on connaît le projet auquel est affectée une sous-tâche quelconque, sans que celle-ci y fasse explicitement référence.

En ce qui concerne la table 'affectation', je ne comprends pas bien son utilité puisque normalement, le clé primaire de la table projet devrait migrer en clé primaire - étrangère de la table tache (projet 0,N --comporter-- (1,1) tache).

Comme je l’ai expliqué dans mon précédent message, modéliser :

Projet 0,N --comporter-- (1,1) Tache

signifie que non seulement les tâches, mais les sous-tâches feront explicitement elles aussi référence aux projets (rappel : les tâches t1 et t2 font référence au projet p1, tandis que la tâche t3 fait référence au projet p2), engendrant une redondance néfaste :



Et si l’on ne surveille pas la cohérence de ce système, rien n’interdit que, par exemple, la sous-tâche t112 fasse référence au projet p2, ce qui serait une erreur.

Ça c’est pour Charybde. Pour en venir à Scylla, on pourrait modéliser ceci :

Projet 0,N --comporter-- (0,1) Tache

la cardinalité minimale 0 permettant alors au bonhomme NULL de se manifester au niveau logique :



D’où la justification de l’entité-type AFFECTATION, car le bonhomme NULL est interdit de séjour dans la théorie relationnelle (d’aucuns vous diront qu’en SQL il est admis, et tant pis si l’algèbre relationnelle est mise en échec...)

dans ton MCD, je ne vois pas trop le fonctionnement de hiérarchie, si c'est une table ou autre

Au niveau du MLD (modèle logique des données), HIERARCHIE est bien une table, sinon on s’enfoncerait encore un peu plus dans le marécage des NULLs comme ci-dessous :




D’où ma préférence pour un système conforme à la théorie relationnelle :