Discussion :

[escartefigue]

"Chef de projet" appartient toujours à collaborateur dans cette règle, et n'est pas une entité ? Je suis du coup ce qui est dit plus haut "Un chef de projet n’appartient pas à COLLABORATEUR, un chef de projet est un collaborateu", mais il est vrai qu'instinctivement, en lisant cette regle de gestion, j'ai fais l'erreur de penser ça tel que trois entités qui devaient être associées (chef de projet > associe collaborateur > etape du projet).

Les chefs de projets, comme les autres acteurs intervenant sur les projets (analystes, développeurs...) sont des COLLABORATEURS.
Ils partagent des attributs en commun tels que nom, prénom, date d'embauche...

Si les chefs de projets avaient eu des attributs spécifiques en plus des attributs communs alors il aura fallu utiliser l'héritage : un sous-type d'entité est défini en ce cas pour les attributs propres aux chefs de projets
Rien de tel n'est mentionné dans votre énoncé, il est donc inutile de compliquer le MCD

(C'est moi où démarrer par Merise n'est pas des plus simple !?)

Qui dit Méthode dit rigueur d'esprit et démarche par étape, la méthode Merise n’échappe pas à la règle

Vous êtes attentif aux conseils avisés de Fsmrel (c'est un très bon professeur, vous avez de la chance ) et vous semblez être persévérant.
C'est donc une très bonne base pour progresser, l'expérience s’acquière avec le temps

[CinePhil]

C'est moi où démarrer par Merise n'est pas des plus simple !?

Le MCD Merisien est, à mon avis, le meilleur outil pour modéliser correctement une base de données relationnelle. C'est justement perse qu'il est rigoureux que c'est le meilleur.

[Geff's]

Du coup responsable d'études, responsable commercial, service technique,... Sont tous des collaborateurs aussi ?

j'aurais tendance à dire que non, déjà en regardant le schéma page 9, qui différencie collaborateurs et responsable d'étude, par exemple.
De facto, une règle de gestion comme :
"A chaque projet on peut associer des références à des documents. Les références à ces documents sont associées au projet par le secrétariat technique sur demande du CP."

On peut modéliser cela par quelque chose comme :



ou secrétariat technique n'a pas de raison d'être modélisé ?

Idem pour "pour les différentes étapes du processus, les charges réelles de production et de validation sont enregistrées par le secrétariat technique à partir des fiches d’activités remplies par les différents collaborateurs, lorsque l’étape a été terminée et validée par le chef de projet." que je n'ai pas trop saisi comment modéliser encore.

Ensuite, le chef de projet étant collaborateur, comment résoudre des règles comme :

"le reponsable d'étude associe le chef de projet et le client concerné."
"Pour chaque projet, le CP enregistrera les informations techniques du projet"
Il ne faut pas de moyen pour différencier, dans l'association, un chef de projet et un collaborateur "autre" ?

Et je reviens en arrière, sur la figure 6, n'est-il pas possible que les association exercer et intervenir ne fasse qu'une, c'est a dire que collaborateur / date / fonction / Etape soient liées par exercer ?

[escartefigue]

Du coup responsable d'études, responsable commercial, service technique,... Sont tous des collaborateurs aussi ?
j'aurais tendance à dire que non, déjà en regardant le schéma page 9, qui différencie collaborateurs et responsable d'étude, par exemple.

Le schéma met en évidence des différences dans les actions de chaque acteur, pas dans les attributs de ces acteurs
Encore une fois, les chefs de projet, responsables des études, collaborateurs, secrétaires etc... partagent les attributs nom, prénom, date d'embauche, n° de salarié etc...
Il faut donc une entité-type unique pour toutes ces personnes, et leur attribuer une fonction, à date bien sur.

De facto, une règle de gestion comme :
"A chaque projet on peut associer des références à des documents. Les références à ces documents sont associées au projet par le secrétariat technique sur demande du CP."

On peut modéliser cela par quelque chose comme :

Non, il ne faut pas confondre données et traitement

Au niveau des données, l'énoncé propose une relation entre projet et référence documentaire, l'énoncé est d'ailleurs incomplet car il n'indique pas si un même document peut être référencé par plusieurs projets. Mais peu importe, admettons que un document ne concerne qu'un et un seul projet, auquel cas on peut modéliser comme suit

PROJET 0,n --- référencer --- 1,1 DOCUMENT

Ensuite, l'énoncé précise que c'est le secrétariat technique qui mettra en place cette relation, là, on est au niveau du traitement : qui crée une occurrence dans les relation "référencer" ? le secrétariat technique.

ou secrétariat technique n'a pas de raison d'être modélisé ?

L'énoncé cite plusieurs types de secrétariat (technique, administratif) et indique que des personnes y sont rattachées
Deux solutions :

Soit vous modélisez les secrétariat en associant un type de secrétariat
SECRETARIAT 1,1 --- typer --- 0,n TYPE_SECRETARIAT

Soit vous élargissez à la notion de service, quitte à mettre en œuvre ensuite la spécialisation par héritage si les secrétariat ont des attributs spécifiques
SERVICE 1,1 --- typer --- 0,n TYPE_SERVICE

Ensuite, le chef de projet étant collaborateur, comment résoudre des règles comme :

"le reponsable d'étude associe le chef de projet et le client concerné."
"Pour chaque projet, le CP enregistrera les informations techniques du projet"

Il ne faut pas de moyen pour différencier, dans l'association, un chef de projet et un collaborateur "autre" ?

On va mettre en œuvre des Contraintes d'Intégrité Fonctionnelles après avoir défini le rôle de chaque collaborateur dans chaque projet
Il me semble que FsmRel vous a donné la solution dans les réponses qui précèdent sur ce point précis.
Malheureusement je ne peux pas visualiser ses schémas depuis ce poste pour m'en assurer

[Geff's]

On va mettre en œuvre des Contraintes d'Intégrité Fonctionnelles après avoir défini le rôle de chaque collaborateur dans chaque projet

Aaaah... ! *illumination*

J'ai compris le fonctionnement de la CIF pour garantir qu’à une date donnée, un collaborateur n’exerce qu’une seule fonction. Du coup ( a moins que je ne me trompe, on avait (enfin, FsmRel avait ) associé "intervenir" à "fonction" pour signifier que un collaborateur intervient sur une étape par rapport à une fonction.
Ce qui veut dire qu'on va faire une flèche rouge, représentant un CIF (encore une fois à fonction?), pour définir qu'un collaborateur associé au client EST un chef de projet... C'est ça ?

[fsmrel]

"A chaque projet on peut associer des références à des documents. Les références à ces documents sont associées au projet par le secrétariat technique sur demande du CP."

Dans le document de référence, il y a une rubrique « Sous Système : gestion des collaborateurs » où l’on trouve la liste des fonctions des collaborateurs : parmi celles-ci, il y a la fonction « secrétaire », que vous pouvez affiner en « secrétaire du service technique », même chose pour les autres secrétariats. Mais à la lecture rien ne justifie la mise en oeuvre d’une entité-type SECRETARIAT TECHNIQUE, dont les attributs restent par ailleurs à inventer.

Maintenant, si on veut savoir si M. Dupond fait bien partie du secrétariat technique, c’est l’association entre COLLABORATEUR et FONCTION qui fournira la réponse.

Deux solutions :

Soit vous modélisez les secrétariat en associant un type de secrétariat
SECRETARIAT 1,1 --- typer --- 0,n TYPE_SECRETARIAT

Soit vous élargissez à la notion de service, quitte à mettre en œuvre ensuite la spécialisation par héritage si les secrétariat ont des attributs spécifiques
SERVICE 1,1 --- typer --- 0,n TYPE_SERVICE

Le jeu en vaut-il la chandelle ? Sous réserve d’une lecture approfondie du document de référence qui pourrair montrer le contraire, on peut faire l’économie de ces entités-types. Comme disait le nominaliste Guillaume d’Ockham, « évitons de multiplier inutilement les entités »... Ton avis Capitaine ?

Je dois m’absenter et reviendrai plus tard sur les autres points.

[escartefigue]

Le jeu en vaut-il la chandelle ? Sous réserve d’une lecture approfondie du document de référence qui pourrair montrer le contraire, on peut faire l’économie de ces entités-types. Comme disait le nominaliste Guillaume d’Ockham, « évitons de multiplier inutilement les entités »... Ton avis Capitaine ?

Je dois m’absenter et reviendrai plus tard sur les autres points.

Plutôt d'accord, si les secrétariats sont mentionnés page 8, chapitre 3 dans la liste des acteurs, ils ne semblent plus utilisés dans la suite du document
Le document est lacunaire sur bien des points (à commencer par les règles de gestion comme indiqué à plusieurs reprises) donc le doute subsiste.

Si inutilisé, on vire et sans scrupule !

[fsmrel]

Du coup ( a moins que je ne me trompe, on avait (enfin, FsmRel avait ) associé "intervenir" à "fonction" pour signifier que un collaborateur intervient sur une étape par rapport à une fonction.
Ce qui veut dire qu'on va faire une flèche rouge, représentant un CIF (encore une fois à fonction?), pour définir qu'un collaborateur associé au client EST un chef de projet... C'est ça ?

Hum... Dans la figure 6, quand un collaborateur intervient dans une étape, il s’agit de signifier qu’il n’y exerce qu’une seule fonction, d’où la flèche rouge (CIF) ciblant FONCTION. Cette CIF ne dit rien d’autre. Le client n’a rien à voir dans cette affaire.


Quant au chef de projet, toujours dans la figure 6, c’est uniquement l’association DIRIGER qui dit que tel collaborateur dirige tel projet. Au-delà, si une règle de gestion des données disait que « un collaborateur ne peut diriger un projet, qu’à la condition d’exercer la fonction de chef de projet », alors il faudrait mettre en oeuvre une contrainte d’inclusion entre les associations DIRIGER et EXERCER :

Avec un éventuel problème de date d’exercice de fonction à prendre en compte (règle de gestion des données à définir ou préciser...)

Maintenant, quand vous écrivez « un collaborateur associé au client EST un chef de projet », je suis désolé, mais il n’y a pas de lien direct entre le collaborateur (désigné comme chef de projet) et le client : le lien est transitif, comme le montre la figure 15 ci-dessous.

En effet, on lit au paragraphe 3.6 :

« Un projet est toujours associé à un client »

La partie correspondante du MCD devient donc :

Au paragraphe 3.3, il est écrit :

« L’initialisation du projet, par le responsable des études [...] Il associe également le chef de projet et le client concerné. »

Ce qui doit être interprété ainsi :

a) Le responsable des études détermine quel collaborateur dirige le projet.

b) Le responsable des études détermine quel client a passé commande du projet.

Alors qu’on pourrait de façon erronée interpréter les choses ainsi :

c) Quel client est concerné par quel chef de projet...

Paragraphe 3.4 :

« Le service commercial a besoin d’informations sur les sociétés clientes ; Ainsi de la même façon que les managers gèrent leurs collaborateurs »

Ont peut supposer que l’adjectif possessif « leurs » désigne les collaborateurs de ACTIVE BRETAGNE INFORMATIQUE et non pas les collaborateurs des clients...

Etc.

[fsmrel]

Si inutilisé, on vire et sans scrupule !

Dans toute organisation, les règles de gestion des données sont susceptibles d’évoluer. Si un beau jour le chef décide de gérer les services, on fera évoluer le MCD sur la base de ce que tu as évoqué :

SECRETARIAT 1,1 --- typer --- 0,n TYPE_SECRETARIAT

SERVICE 1,1 --- typer --- 0,n TYPE_SERVICE

Sans oublier d’établir au besoin les liens qui vont bien avec COLLABORATEUR (qui c’est le chef de service, etc.)

Qu’en penses-tu ?

[escartefigue]

Qu’en penses-tu ?

C'est éclectique et "je suis très pour l'éclectisme" (c) les inconnus, all rights reserved

[Geff's]

Qu’en penses-tu ?

Maintenant que je vois la figure 15, elle me paraît évidente. Comme tu le dis c'est une question d'interpretation. Quand je lis tes derniers messages, je me rends compte que je réagis en voulant rentrer toutes les informations que je vois dans les données, alors qu'il n'y a pas lieu de le faire.

Pour le secrétariat c'est plus clair, merci d'avoir précisé.

a) Le responsable des études détermine quel collaborateur dirige le projet.

b) Le responsable des études détermine quel client a passé commande du projet.

Donc... C'est une règle d'organisation c'est ça, et ça n'à aucune raison d'être modélisé ?

[escartefigue]

Donc... C'est une règle d'organisation c'est ça, et ça n'à aucune raison d'être modélisé ?

Si vous n'avez pas besoin des informations relatives au(x) secrétariat(s) mais seulement besoin de savoir qu'une personne exerce une fonction de secrétaire, ne modélisez pas cette partie
Si vous avez besoin des informations des informations relatives au(x) secrétariat(s) et uniquement de ce type de services, modélisez les secrétariats et les types de secrétariat
Si vous ave besoin de tous les services (secrétariat, comptabilité, moyens généraux....) modélisez des services et des types de services

Vu l'énoncé, il semble que vous n'ayez pas besoin d'autre chose qu'un simple lien du collaborateur vers sa fonction, vous ferez évoluer le modèle quand ce sera nécessaire
En cas de doute, n'hésitez pas à poser des question à votre formateur, c'est le fonctionnement normal et nécessaire

[fsmrel]

a) Le responsable des études détermine quel collaborateur dirige le projet.

b) Le responsable des études détermine quel client a passé commande du projet.

Donc... C'est une règle d'organisation c'est ça, et ça n'à aucune raison d'être modélisé ?

Si M. Fernand est le directeur des études, il n’en est pas moins collaborateur chez ACTIVE BRETAGNE INFORMATIQUE, et il fait l’objet d’une instance de l’entité-type COLLABORATEUR, instance en relation avec l’instance "responsable des études" de l’entité-type FONCTION, via l’association EXERCER_FONCTION (cf. figure 8).

Si donc on veut savoir qui a décidé que M. Raoul a dirigé ou dirigera le projet « La péniche », on a donc automatiquement la réponse.

Seul bémol : il faudra garantir dans la base de données qu’il ne peut y avoir plus d’un responsable des études. Ainsi, en relationnel pur (avec un langage de type D), on mettra en oeuvre une contrainte du genre (en supposant que fonctionId = 5 correspond à la fonction "responsable des études") :

 
CONSTRAINT COLLABORATEUR_FONCT_CX
    COUNT (COLLABORATEUR {fonctionId = 5}) = 1 ;

En SQL normalisé :

 
CREATE ASSERTION COLLABORATEUR_FONCT_CX
    CHECK 
        (UNIQUE (SELECT fonctionId FROM COLLABORATEUR WHERE fonctionId = 5)) ;

Inutile évidemment de définir une entité-type RESPONSABLE_ETUDES, qui ne serait qu’une redondance parasite ; à nouveau suivons la recommandation de Guillaume d’Ockham...

[Geff's]

Bonjour,

Du coup en effet aucune raison de modéliser les types de secrétariat.
Idem pour les charges, que j'avais mis au départ. Il y a quelques semaines, on m'avait écrit de différencier le "QUOI" et le "COMMENT". Du coup, les charges estimées / réelles sont liées aux personnes qui les saisissent, pas au projet en lui même, ça n'a aucune raison d'être une entité comme je l'avais fait précédemment n'est ce pas ?

C'est bien plus épuré que précédemment, diantre !

[escartefigue]

Bonjour,

Du coup en effet aucune raison de modéliser les types de secrétariat.
Idem pour les charges, que j'avais mis au départ. Il y a quelques semaines, on m'avait écrit de différencier le "QUOI" et le "COMMENT". Du coup, les charges estimées / réelles sont liées aux personnes qui les saisissent, pas au projet en lui même, ça n'a aucune raison d'être une entité comme je l'avais fait précédemment n'est ce pas ?

Les charges ne sont pas liées aux personnes qui les saisissent, elles sont liées aux étapes

Extrait de votre cahier des charges au § 3.3 :

les charges du projet (en heure) :
- La charge globale estimée initialement par étapes du processus est enregistrée par le chef de projet.
- pour les différentes étapes du processus, les charges réelles de production et de validation sont enregistrées par le secrétariat technique à partir des fiches d’activités remplies par les différents collaborateurs, lorsque l’étape a été terminée et validée par le chef de projet

Il ne faut donc pas stocker les charges au niveau projet, mais au niveau étape. Les stocker au niveau projet serait une redondance et donc un risque d'incohérence.
C'est par requête (somme des étapes) que vous connaitrez les charges de chaque type d'un projet.
Le fait que ce soit le secrétariat technique ou tout autre intervenant qui saisit les charges dans le S.I. n'a aucune importance au niveau MCD.

Autre remarque, dans le cahier des charges sont décrites des "fiches" (fiche projet, activité, collaborateur ...) il faut voir ces fiches comme des formulaires, c'est à dire une liste d'attributs nécessaire pour gérer un projet, une activité, un collaborateur...
Pour autant, il ne faut pas en déduire une modélisation à plat, vous devez architecturer vos types d'entité en respectant les formes normales
Par exemple, tout attribut doit dépendre de son identifiant. Dans la fiche "collaborateur", l'adresse et le téléphone ne sont pas en dépendance fonctionnelle de l'identifiant collaborateur.
Connaitre le n° de collaborateur permet d'en déduire son nom, son prénom, sa date d'embauche, ça OK
Mais ça ne permet pas de connaitre son téléphone ou son adresse (il peut avoir plusieurs téléphones et/ou plusieurs adresses)

Il faut donc modéliser pour les média (téléphone, fax, courriel etc...)
COLLABORATEUR 1,n --- posseder --- 1,1 MEDIA 1,1 --- typerM --- 0,n TYPE_MEDIA

Et pour les adresses
COLLABORATEUR 1,n --- resider--- 1,1 ADRESSE 1,1 --- typerA --- 0,n TYPE_ADRESSE

[Geff's]

Il ne faut donc pas stocker les charges au niveau projet, mais au niveau étape.

Oups, erreur de ma part, j'avais noté que c'était dans étapes, mais j'ai omis de l'ajouter dans le MCD. Je corrige !

Mais ça ne permet pas de connaitre son téléphone ou son adresse

Jusqu'ici dans les corrigés je n'avais pas eu ce cas, enfin c'était des choses classiques (un client à un nom, une adresse, un téléphone particulier, un téléphone professionnel... par exemple) et tout était attribut, et je comprenais ça tel que si on récupérait le code client, on obtenait du coup ces attributs cités.
Du coup c'est parce qu'il est indiqué qu'il y a plusieurs adresse ou téléphones que l'on doit les modéliser en entité ?

[fsmrel]

Geff’s, Il y a chez vous une certaine confusion ans l’interprétation du QUOI et du COMMENT. Si le QUOI correspond bien aux charges estimées elles-mêmes, le COMMENT revient à déterminer « par qui est effectuée la saisie des charges estimées ». Or c'est le QUOI seul qui concerne la base de données.

Je confirme ce que dit escartefigue, qui m'a devancé dans la réponse. voilà ce que j’ai écrit :

Les charges estimées devront être présentes dans la base de données et sont donc à modéliser. Une charge est bien la propriété d’un projet, et le fait que le secrétariat technique en effectue la saisie n’a pas à figurer dans la base ! Maintenant, il s’agit de vérifier à quel niveau on a besoin de modéliser une charge estimée : projet ou étape. Pour mémoire, les charges réelles sont obtenues à partir du contenu des fiches d’activité, mais que ce soit le secrétariat technique (ou un scanner) qui effectue la saisie à partir des fiches, voilà qui n’a pas à figurer dans la base de données, ça ne vous a pas été demandé.

[escartefigue]

Jusqu'ici dans les corrigés je n'avais pas eu ce cas, enfin c'était des choses classiques (un client à un nom, une adresse, un téléphone particulier, un téléphone professionnel... par exemple) et tout était attribut, et je comprenais ça tel que si on récupérait le code client, on obtenait du coup ces attributs cités.
Du coup c'est parce qu'il est indiqué qu'il y a plusieurs adresse ou téléphones que l'on doit les modéliser en entité ?

Rien ne le précise dans l'énoncé, mais si l'on veut à la fois être rigoureux en respectant les formes normales et proposer un modèle évolutif, il est nettement préférable d'externaliser téléphones et adresses.

Aujourd'hui vous n'avez peut être besoin que d'un seul téléphone, un modèle à plat tel que vous l'avez produit le permet
Demain si vous avez besoin d'un autre téléphone, avec un modèle à plat, il faut modifier la table pour ajouter la colonne et les traitements pour l'utiliser, au risque d'avoir des lignes avec cette colonne marquée à "nul" pour les collaborateurs non concernés.
Même raisonnement pour les adresses bien sur.

[fsmrel]

c'est parce qu'il est indiqué qu'il y a plusieurs adresse ou téléphones que l'on doit les modéliser en entité ?

En fait, votre question revient à ceci : faut-il mettre en oeuvre soit un vecteur, soit une table des téléphones ? (La vectorisation revenant prosaïquement à définir N colonnes : Tel₁, Tel₂, ..., Tel_n).

Avec PostgreSQL il suffirait d'écrire, en appelant un chat un chat :

Code SQL :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
CREATE TABLE COLLABORATEUR
(
        collaborateurId          INTEGER        NOT NULL 
       , collaborateurMatricule  TEXT           NOT NULL
      , collaborateurNom         TEXT           NOT NULL
        ...                      ...            ...
      , collaborateurTel         TEXT [ ]      NOT NULL 
    , CONSTRAINT COL_PK PRIMARY KEY (collaborateurId)
) ;

Puis :

Code SQL :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
INSERT INTO COLLABORATEUR (collaborateurId, collaborateurMatricule, collaborateurNom, ..., collaborateurTel)
    VALUES (1, 'col01', 'Volfoni', ..., ARRAY ['0123456789', '0654321097', ..., '0654001088']) ;

Il est quand même écrit dans la documentation de PostgreSQL que c’est une mauvaise idée :

« Chercher des éléments particuliers dans un tableau peut être le signe d'une mauvaise conception de la base de données. Étudiez la mise en place d'une table séparée dont chaque ligne soit affectée à chaque élément du tableau. La recherche sera plus simple. »

Et j’ajoute quant à la simplicité : Bel euphémisme...

« Verticalisons » donc les téléphones :

Code SQL :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
CREATE TABLE COLLABORATEUR 
(
        collaborateurId          INTEGER        NOT NULL
      , collaborateurMatricule   TEXT           NOT NULL
      , collaborateurNom         TEXT           NOT NULL
        ...                      ...            ...
    , CONSTRAINT COL_PK PRIMARY KEY (collaborateurId)
    , CONSTRAINT COL_AK UNIQUE (collaborateurMatricule)
) ;

CREATE TABLE TELEPHONE
(
        collaborateurId          INTEGER        NOT NULL
      , TelNo                    TEXT           NOT NULL
    , CONSTRAINT TEL_PK PRIMARY KEY (collaborateurId, TelNo)
    , CONSTRAINT TEL_FK FOREIGN KEY (collaborateurId) REFERENCES COLLABORATEUR (collaborateurId)
          ON DELETE CASCADE
) ;

Ça me rappelle l’histoire d’un de mes collègues qui avait prévu 7 colonnes dans ses stats réseau (une colonne par jour de la semaine) et à qui un beau jour on a demandé de passer à une colonne par jour de l’année : il a compris qu’il aurait mieux valu verticaliser tout ça. Ça me rappelle aussi un tableau au cœur d’un système d’exploitation chez IBM (années soixante), prévue pour qu’un ordinateur gère au maximum 256 périphériques (on occupait à peine 10% de la table) : manque de chance, au début des années soixante-dix, il a fallu passer à 64000 (arrivée des écrans (passifs))...

[Geff's]

Je pense que ce sera plus clair une fois que j'aurais fait du SQL, parce que pour le moment ce n'est pas du tout le cas. On démarre par Merise, puis ce sera le SQL, du coup peut être qu'une fois qu'on aura avancé je pourrais me "projeter" et que ce sera plus clair.

Mais j'ai compris l'idée générale du coup !