Même si vous débutez en modélisation de base de données, en écrivant correctement les règles de gestion des données, vous pourrez facilement créer votre MCD (ou votre diagramme de classes si vous préférez UML).
La méthode que je décris ci-après devrait vous aider beaucoup pour apprendre à modéliser correctement.
1) Écrire une règle de gestion
L’exercice consiste à écrire en français (ou dans la langue de votre choix) une phrase décrivant comment sont associés deux concepts.
Par exemple, on vous demande de modéliser les données nécessaires à une gestion de projets et on vous dit, entre autres, qu’il y a toujours une personne qui est nommée chef de projet pour un projet et que plusieurs personnes travaillent sur un projet.
L’extrait en italique de la phrase précédente pourrait suffire à un concepteur habitué à la modélisation des données pour produire un MCD correct et possible mais il manque des informations pour ne pas faire d’erreur :
– est-ce qu’une personne est obligatoirement chef de projet au moins une fois ?
Рest-ce que toute personne enregistr̩e dans le syst̬me travaille sur au moins un projet ?
– est-ce qu’une personne ne peut travailler que sur un seul projet à la fois ?
Muni des réponses à ces questions, vous pouvez écrire vos règles de gestion relatives aux associations entre les personnes et les projets. Par exemple, les réponses peuvent vous amener à écrire à coup sûr ces deux règles de gestion :
1) Un projet est dirigé par une seule personne (nommée « chef de projet » pour ce projet) et une personne peut diriger plusieurs projets (en étant nommée « chef de projet » pour chacun d’eux).
2) Un projet fait travailler de une à plusieurs personnes et une personne peut travailler sur plusieurs projets.
Il faut écrire la phrase en partant d’une personne et décrire son association avec les projets (diriger) et compléter la phrase en partant cette fois du projet et décrire l’association inverse vers les personnes.
2) Le passage au MCD
Des règles de gestion écrites précédemment, il est très facile d’en déduire le MCD :
personne -0,n—-diriger—-1,1- projet
|———0,n—-travailler—-1,n—|
Comment ai-je fait ?
Examinons la première règle de gestion :
1) Un projet est dirigé par une seule personne (nommée « chef de projet » pour ce projet) et une personne peut diriger plusieurs projets (en étant nommée « chef de projet » pour chacun d’eux).
Les termes en gras représentent les entités types du MCD : personne et projet. Ce sont, dans les règles de gestion, généralement des noms communs qui font ou qui subissent une action.
Les termes soulignés représentent l’association : diriger. Ce sont généralement des verbes, le plus souvent conjugués une fois à la forme active ([peut] « diriger », ou bien « dirige ») et une fois à la forme passive (« est dirigé par »). Dans le MCD, on laissera ce verbe à l’infinitif pour pouvoir lire l’association dans les deux sens plus facilement.
Les termes en italique sont un guide pour déterminer les cardinalités de l’association :
– « est dirigé » indique une obligation, donc une cardinalité minimale de 1 ;
– « un seul » indique une cardinalité maximale de 1 ;
– « peut [diriger] » indique une possibilité, donc aussi la possibilité qu’une personne ne dirige aucun projet, soit une cardinalité minimale de 0 ;
– « plusieurs » indique une cardinalité maximale de n.
Examinez la seconde règle de gestion et vous verrez que cela fonctionne de la même manière.
Au bout de quelques exercices de formalisation de règles de gestion de la sorte, vous passerez tellement facilement à la génération du MCD que vous finirez par vous passer de l’écriture des règles de gestion et vous contenterez seulement d’y penser quand vous dessinerez directement le MCD.
3) Petit exercice
Comment modéliseriez-vous le fait qu’un projet est dirigé obligatoirement par une personne ayant le titre de chef de projet et que d’autres personnes peuvent travailler sur le projet ?
Écrivez une ou des règles de gestion possibles puis passez au MCD.
Très bon poste ! Merci
Voici ma réponse à l’exercice que tu as donné. N’hésites pas Merci
Chef de projet ——— 1,1 ————–Diriger ———1,1 ——— Projet
Staff———–0,n—————–Travailler——–0,n—————–Projet
Merci beaucoup Mr Cinéphil pour toutes ces précision.
Voici ma reponse à votre question
Personne—–1,n——diriger——1,1——projet
Personne—–1,n——-travailler—–0,n——projet
Je reste disponible
Où sont tes règles de gestion ?
La lecture d’un autre de mes billets de blog, « Quand faut-il une table associative ? », t’apprendrait que des cardinalités (1,1 – 1,1) sont généralement évitables.
Ton schéma implique qu’un chef de projet ne peut diriger qu’un seul projet. Mon expérience professionnelle me dit que ce n’est que très rarement le cas et que a grande majorité sont amenés à gérer plusieurs projets simultanément, quand même le plus souvent à des phases différentes (un qui se termine, un qui démarre).
Dans mon énoncé d’exercice, je ne parlais que de « personnes », certaines étant « chef de projet ». Je n’ai pas parlé de « staff », terme qui désigne d’ailleurs plutôt une équipe qu’une personne.
La modélisation de données est une activité qui demande de la rigueur !
Moi d’abord ma question est la suivante / pourquoi a ton mis dans la deuxième des cardinalités :
Personne——–0,n—-travailler—-1,n—Projet au lieu de
Personne——–1,n—-travailler—-1,n—Projet
car là on suppose qu’une personne peut ne pas travailler sur aucun projet à vrai ne participe à aucun projet . alors que si on a mis 1 toute persone est forcément lié à un projet au moins donc là c à débattre .
REGLES DE GESTION :
1) un Projet est dirigé obligatoirement par une personne (Chef de projet)
2) Un chef de projet doit travailler seulement sur le projet auquel il est chef
3) d’autres personnes (Ã part le chef ) peuvent travailler sur 1 ou plusieurs projets
Personne ——— 1,1 ————–Diriger ———1,1 ——— Projet
Personne ———–0,n—————–Travailler——–0,n—————–Projet
moi ma question aussi c’est qu’ici on ne doit pas forcément distinguer chef de projet et staff comme dans la première question car çà représente une entité unique qui est Personne
Tout simplement parce que la règle de gestion que j’avais écrite est la suivante :
Et j’ai aussi expliqué ceci :
La possibilité implique aussi la non existence et elle s’applique aussi sur la seconde règle de gestion et la cardinalité minimale est bien 0.
C’est ce que dit la règle de gestion et lorsqu’elle est établie, elle n’est pas discutable !
Vous n’avez pas suivi strictement le modèle de mes règles de gestion. Dans mon modèle, une règle de gestion = l’expression d’une association. La règle de gestion « lit » la future association du MCD dans les deux sens, en partant d’une entité type puis de l’autre.
Ce serait un peu plus compliqué avec une association ternaire (ou d’arité supérieure à 2) mais restons simple avec les associations binaires.
Vos règles de gestion restent ambigües donc incomplètes. À leur lecture, on peut supposer que toute personne peut faire fonction de chef de projet alors que ce n’est pas ce que j’avais spécifié :
Votre deuxième phrase est le fruit de votre interprétation mais ce que vous dîtes n’est pas dans l’énoncé. Cette interprétation entraîne dans votre MCD le fait que toute personne dirige obligatoirement un projet, ce qui est faux !
Et bien justement, mon énoncé contenant ces mots « ayant le titre de chef de projet » implique une spécialisation de certaines personnes en tant que chef de projet. Il y aura donc bien une entité type « chef_projet ». Et comme les chefs de projets sont des personnes, on modélise ici un héritage de données.
Ma solution…
Règles de gestion :
1) Un chef de projet est une personne et une personne peut être un chef de projet.
2) Un chef de projet peut diriger plusieurs projets et un projet est dirigé par un chef de projet.
3) Une personne (autre qu’un chef de projet) peut travailler sur plusieurs projets et un projet peut faire travailler plusieurs personnes (autres que des chefs de projets).
MCD :
chef_projet -(1,1)—-être—-0,1- personne -0,n—-travailler
|—–0,n—-diriger—-1,1- projet -0,n—————–|
Il faudrait même ajouter une contrainte d’exclusion entre les deux associations « travailler » et « diriger » mais c’est difficilement représentable en mode texte. Séparément, je pourrais écrire ceci :
travailler—–X—–diriger
Remarquez les cardinalités entourées de parenthèses qui indiquent une identification relative du chef de projet par rapport à la personne et qui signifient que la table « chef_projet » héritera de l’identifiant de la table « personne » et n’aura pas d’identifiant propre.
personne (prs_id, prs_nom…)
chef_projet (cpj_id_personne…)
Autre question sur les lien on voir les verbes Diriger et travailler et on voit bien que çà peut être différent mais voilà qu’est ce qu’on fait de ces verbes ??,
on les crée une table où ??? c’est pour la compréhension mais on relie directement les tables personnes et projets ici ??
Puisque tu as lu mon autre article « Quand faut-il une table associative ? », tu dois être capable de répondre à la question !
En l’occurrence, dans le dernier schéma avec l’héritage de données, seule l’association « travailler » donnera lieu à la création d’une table associative.
Je reviens en relisant l’article en souhaitant bien connaître et assimilé cette notion en matière de modélisation des BD :
voici ma nouvelle réponse face à l’exercice :
Mes règles :
1) 1 chef de projet ne peut pas travailler sur un autre projet
2) les autres personnes peuvent travailler le projet tout en ayant la possibilité de travaillier dans d’autres .
MCD :
Personne — 1,n—diriger —1,1 projet
Personne — 0,n—travailler —1,n—projet
voilÃ
Encore une fois, tes règles de gestion sont incomplètes et mal formulées.
Ta première règle de gestion parle de chef de projet et on ne retrouve pas cette notion dans ton MCD.
Ton MCD est issu des règles de gestion suivantes :
1) Une personne dirige un à plusieurs projets et un projet est dirigé par une seule personne.
2) Une personne peut travailler sur plusieurs projets et un projet fait travailler de une à plusieurs personnes.
Ce sont presque les mêmes règles de gestion, et donc presque le même MCD, que dans mpon article mais ton MCD impose que toute personne dirige au moins un projet, ce qui n’est pas dans l’énoncé de mon exercice, et pas du tout vrai dans la pratique des entreprises.
Bref, ta nouvelle réponse à l’exercice est fausse !
J’ai donné la solution dans mon message du 17/02/2012 @ 14:13
Voici mon avis par rapport au model demandé:
Personne 0,n est nommée 1,n chef projet
Chef projet 0,n dirige 1,1 projet
personne 0,n peut travailler 1,n projet
Il manque une question à laquelle on n’a pas répondu.
Quand on est chef de projet, fait-on parti de la liste des personnes qui travaillent sur le projet ? Ou encore doit-on travailler sur un projet pour en être le chef de projet ?
Il faudrait faire intervenir une classe « Membre Projet » dire que le projet comporte des « membres » (on peut d’ailleurs mettre des infos comme la date d’arrivée dans le projet, par exemple). Les « Personnes » peuvent jouer le rôle de Membre Projet. On ajoute la classe « Chef de Projet » et là c’est un membre qui peut jouer le rôle de chef de projet.
Les classes Membre Projet et Chef de Projet peuvent être « marquées » comme des « rôle » et on peut alors les utiliser de manière particulière (un peu long à expliquer ici)
J’ai donné ma solution dans le message du 17/02/2012 @ 14:13.
Bonjour,
Tout d’abord merci pour cet article très instructif et clair.
Je travaille sur une notion simple de parrainage et je ne suis pas sûr de la manière de modéliser un certain aspect… cela peut servir d’exercice pour d’autres, voici mes règles de gestion:
Un individu peut parrainer un ou plusieurs autre(s) individu(s)
Un individu ne peut être parrainé que par un seul autre individu
Un individu ne peut se parrainer lui même
Un individu peut ne pas être parrainé
j’ai écrit le MCD suivant:
Individu –0,n– parrainer –0,1– Individu
difficile en mode texte de l’écrire mais c’est bien une relation réflexive…
Ma question : Comment modéliser le fait qu’un individu ne peut se parrainer lui même ? mon MCD autorise ceci je pense…
Merci pour vos remarques et propositions !
Le plus simple est d’écrire une note sur le MCD.
Lors de la réalisation de la base de données, il faudra créer une contrainte CHECK ou un trigger pour formaliser cette impossibilité.
citation
MCD :
chef_projet -(1,1)—-être—-0,1- personne -0,n—-travailler
|—–0,n—-diriger—-1,1- projet -0,n—————–|
les cardinalité (0,n) de chef_projet —–0,n—-diriger—-1,1- projet
ça veut dire que qu’il y a des chef_projet qui peuvent ne pas être liés à la relation même s’il sont dans la table de chefs de projets.
est-ce possible ?
Ça veut dire qu’un chef de projet peut diriger plusieurs projets mais qu’il peut aussi n’en diriger aucun. Il peut par exemple être en formation, en congés, en maladie… et donc temporairement ne diriger aucun projet.
Voici mon avis par rapport au model demandé:
Personne 0,n est nommée 1,n chef projet
Chef projet 0,n dirige 1,1 projet
personne 0,n peut travailler 1,n projet
Ma solution est donnée dans mon commentaire du 17 février 2012 à 14 h 13 min.