Discussion :

[Sophie1206]

Bonjour,
Voilà j'ai de gros doute sur la réalisation de mon schéma conceptuel. Vous trouverez en pièces jointes mon schéma et l'énoncé du problème.
J'ai un gros doute sur les comptes rendus et sur la ternaire de "Noter". Merci de m'éclairer si vous le pouvez.

[dde63]

Bonjour Sophie,

J'ai déjà eu l'occasion d'étudier un problème similaire, mais je ne peux donner de réponse précise à votre question : Votre MCD n'est pas lisible (trop pâle à l'affichage).
En attendant je regarde l'énoncé du problème pour me faire une idée plus précise du MCD

[Sophie1206]

Merci de votre réponse. J'ai refait un scan de mon schéma. J'espère que cela ira. Merci encore de votre aide.

[fsmrel]

Bonsoir,


L’attribut Niveau prend la valeur « A » pour la compétence « Savoir s’exprimer en public », mais c’est dans le cas du poste « chef de projet » : pour le poste DSI ça pourrait être une autre valeur. Dans ces conditions l’attribut Niveau n’est pas à sa place.

Selon votre MCD, du fait de la cardinalité 1,N portée par la patte connectant DEMANDE et EFFECTUER, une demande donnée peut être faite par plusieurs employés, alors que cette demande ne doit être faite que par un seul. La cardinalité doit donc être 1,1. C’est du reste l’occasion d’utiliser l’identification relative, pour signifier qu’une demande ne se contente pas de désigner un employé et qu’elle serait à tort autonome, mais qu’elle dépend viscéralement de l’employé. Autrement dit DEMANDE n’est pas une entité-type autonome, c’est une entité-type faible (weak entity-type de Chen).

Selon votre MCD, toute demande pour une formation donnée est accordée, il y a donc incohérence au cas où la demande est refusée : pour parer au plus pressé, vous pouvez remplacer la cardinalité 1,N portée par la patte connectant DEMANDE et ACCORDER par une cardinalité 0,N, mais il serait préférable de « blinder » le MCD en isolant les demandes acceptées de celles qui sont refusées (par spécialisation).

Je suis obligé d’en rester là pour le moment, mais je vous ferai part de mes autres observations.

[dde63]

Bonsoir,

Le sujet est complexe : Nous irons progressivement.
Je retiens que le DRH souhaite suivre l'évolution des compétences et peut-être du type de poste?. Dans l'affirmative la Cardinalité EMPLOYES Avoir est 1/N.
Evaluer : Ayant à suivre plusieurs fois une FORMATION il sera peut-être évalué plusieurs fois pour la même compétence. Soit faire état de l'objet DATE dans l'association, soit si accepté souligner le champ Date pour indiquer qu'il participe à la clé de l'association.
Il y a une confusion possible avec note et noter.
Noter :Les cardinalités EMPLOYES _ COMPETENCE 0/n : les employés n'ont pas tous suivi une formation et inversement.
Attention une contrainte d'implication : on ne peut noter une COMPETENCES que pour une FORMATIONS suivie : voir la solution la plus appropriée (???)

Faire compte-rendu: contrairement à évaluer (acteur anonyme), il est établi par un EMPLOYES pour un EMPLOYES ; sinon même remarque que Noter. Cardinalité 0/n pour les 2 Entités associées.

EMPLOYES affecté à un Bureau

FORMATIONS : Je suis intimement persuadé que c'est un Objet. Et c'est pourquoi il faut trouver une autre clé primaire que le libelle qui sera sans doute identique d'une session à une autre pour le même profil de formation.

DEMANDES : je pense que l'accord/refus n'est pas pas simultané à la demande : il faut une association dès l'apparition d'une demande. Cette entité pourrait-être une association entre EMPLOYES-FORMATIONS. Une autre association pour gérer la réponse. Il faut y réfléchir .

Bonne soirée et à bientôt

[Sophie1206]

Merci de votre aide, c'est sympa. Je fais les modifications et je vous tiens au courant. N'hésitez pas à laisser d'autre observations. Encore merci.

[fsmrel]

Bonsoir,


A propos des demandes de formation

Un employé donné demande à suivre une formation donnée, donc la modélisation naturelle des choses est la suivante :

[EMPLOYE]----0,N--------(DEMANDE)--------0,N----[FORMATION]

Mais comme je l’ai écrit à l’occasion d’un 1er lot de remarques, pour « blinder » le MCD, il faudrait isoler les demandes acceptées de celles qui sont refusées.

A cet effet on peut transformer l’association DEMANDE en entité-type (comme vous l’avez fait du reste), puis par spécialisation on procède à l’isolation (sous-types DEMANDE_REFUSEE et DEMANDE_ACCORDEE) :



On pourrait faire observer que les attributs RefusDate (sous-type DEMANDE_REFUSEE) et AccordDate (sous-type DEMANDE_ACCORDEE) pourraient faire l’objet d’un seul attribut DecisionDate dans l’en-tête de l’entité-type DEMANDE, mais une décision n’étant pas immédiatement connue, on évitera (cela aurait des conséquences funestes au niveau relationnel).


Cas des demandes accordées

On pourrait être tenté d’établir une relation EVALUATION entre les entités-types DEMANDE_ACCORDEE, COMPETENCE_FORMATION et EMPLOYE (dans le rôle de la personne qui évalue l’employé formé), mais il est préférable de s’assurer qu’une évaluation porte sur une formation qui a été effectuée. En ce sens on met en évidence les concepts de demande accordée et de demande formation effectuée :




A noter que le nom de la formation suivie, de la date de celle-ci, etc., sont connus par le canal de l’association CIBLER.


Une proposition pour un MCD aménagé :





Attention !

Dans l’état du modèle, Fernand peut évaluer les compétences de Raoul (par le canal de l’association EVALUATION et de l’entité-type COMPETENCE_FORMATION) pour une formation suivie en fait par Paul (par le canal de l’association EVALUATION et de l’entité-type FORMATION_SUIVIE). On doit donc faire respecter une « contrainte de chemin », sujet déjà ancien (cf. Flory A., Morejon J., Rochfeld A. : « Toward a new generation of design tools : some basic ideas ». First int conf. on TOOLS – Paris – 1989), qu’on résoudra ici au niveau du MLD (représentation PowerAMC) en ne conservant qu’en seul attribut FormationId dans l’en-tête de la table EVALUATION, alors que la dérivation du MCD en MLD en produit deux, l’un appartenant à la clé étrangère référençant la table COMPETENCE_FORMATION et l’autre appartenant à la clé étrangère référençant la table FORMATION_SUIVIE : désormais, c’est un seul et même attribut qui appartient à la fois aux deux clés étrangères :




N.B. Il y a une 2e contrainte de chemin à faire respecter : l’appréciation faite par Raoul au sujet de l’acquisition d’une compétence d’une formation qu’il a suivie ne doit pas être celle qui a été faite par Paul : là encore, le MLD permet de garantir la contrainte.


Flou de l’énoncé

On sait que plusieurs personnes peuvent évaluer une formation F1 suivie par un employé E1, mais on ne sait pas si ces personnes peuvent évaluer une même compétence C1 de la formation F1 suivie par E1 : selon le MCD ci-dessus, on a pris le parti qu’une seule personne suffit pour faire cette évaluation : à cet effet on a ajouté une CIF (symbolisée par une pointe de flèche portée par la patte connectant EVALUATION et EMPLOYE) :




Si vous estimez au contraire que plusieurs personnes peuvent évaluer une même compétence C1 pour une formation F1 suivie par un employé E1, alors vous supprimerez la CIF (gommez la pointe de flèche). Conséquence sur le MLD : l’attribut EvaluateurId participe à la clé de la table EVALUATION :





Cas de la hiérarchie

Dans l’état du MCD, tout le monde peut noter tout le monde, y-compris soi-même, il y a peut-être une hiérarchie à mettre en place.

[Sophie1206]

merci pour ton travail, j'ai une question, la notion de compte rendu. Dois-je en tenir compte ?

[fsmrel]

Renommons...

Dans l’en-tête de l’entité-type EVALUATION du MCD, il faut renommer l’attribut Note en CompteRendu. Pour être cohérent, dans l’en-tête de la table EVALUATION du MLD, il faut aussi renommer l’attribut Evaluation en CompteRendu :



J'ai renommé les attributs dans le MCD et le MLD.

[Sophie1206]

Merci pour toutes ces précisions. Pour la spécialisation des demandes accordées ou refusées, c'est une très bonne idée mais on ne là pas étudié. Alors je me demandé si ma façon de faire était bonne ou pas ? Je voudrais mettre une ternaire dans mon MCD. Est-ce possible ? Merci pour ton aide.

[fsmrel]

Une ternaire entre quelles entités-types ?

[Sophie1206]

une ternaire entre Employé- Formation- Compétences avec une association Noter qui aurait pour attribut Compte rendu et note. C'est faisable ?

[Sophie1206]

bonsoir, je vous renvoi mon travail refait. Pouvez-vous me dire si cela est cohérent est faisable ? Vous m'avez beaucoup aidé, je vous en remercie.

Sophie

[fsmrel]

Bonsoir Sophie,


A propos des demandes de formation


Reprenons votre MCD :



La patte connectant l’entité-type EMPLOYE et l’association EFFECTUER est porteuse d’une cardinalité 0,N, c'est-à-dire qu’un employé peut faire plusieurs demandes de formation, très bien. Par contre la patte connectant l’entité-type DEMANDE et l’association DONNER_LIEU étant porteuse d’une cardinalité 0,N, une demande donnée peut faire référence à plusieurs formations : s’il y a un refus, ça sera pour l’ensemble de ces formations : pour traiter au cas par cas, il faut donc remplacer la cardinalité 0,N par 0,1. Par ailleurs, quelles valeurs affecter aux attributs Refus, DateRefus et Raison tant que la demande est en cours et qu’on attend une réponse ? Prenons le cas de l’attribut Refus : il devra initialement contenir la valeur « en attente de réponse », puis devra impérativement être remplacé soit par la valeur « oui » s’il y a effectivement refus, soit par la valeur « non » si la demande est agréée, auquel cas la date de l’accord sera mise à jour en conséquence (attribut DateAccord de l’association DONNER_LIEU, tout en observant que l’attribut Accord y est inutile). Par ailleurs, le merisien classique (que je ne suis pas !) fera remarquer qu’une association dont une patte est porteuse d’une cardinalité maximale 1 ne doit pas être porteuse d’attribut (c’est un dogme injustifié, on le prouve, mais ça remonte aux origines de Merise...), ce qui fera que vous sentant peccamineuse, vous rapatrierez DateAccord dans DEMANDE, et là vous repasserez par la case Départ et pleurerez à chaudes larmes (si on n'y prend garde, la base de données sera infectée par ce monstre qu'on appelle le bonhomme Null...)


Vous me dites que vous n’avez pas étudié la spécialisation : d’accord, mais rien ne vous empêche de déguiser comme on faisait au début des années quatre-vingts :





Et pour faire bonne mesure, si vous avez étudié les contraintes, vous pouvez représenter la contrainte d’exclusion selon laquelle on a soit un refus ou un accord, mais pas les deux à la fois :






Je regarderai le reste demain, à plus tard donc...

[fsmrel]

Bonjour Sophie,


Prenons l’énoncé traitant des comptes-rendus :





Reformulons sous forme prédicative :

La personne P rend compte du bienfait qu’a retiré l’employé E de la formation F pour la compétence C.

Le prédicat comporte 4 paramètres, par conséquent l’association merisienne résultante doit comporter quatre pattes, or votre association NOTER n’en comporte que trois : elle ne convient pas pour héberger l’attribut Compte-rendu.


Passons aux notes attribuées par les élèves :

Je cite

« Chaque employé note également la qualité de la formation sur chaque compétence qu’elle devait améliorer (note de 1 à 3) »

Sous forme prédicative :

L’employé E note la compétence C de la formation F qu’il a suivie.

L’association NOTER convient, mais avec un gros bémol quand même :

La notation faite par l’élève peut faire référence à une compétence ne faisant pas partie des compétences associées à une formation qu’il a suivie ou non. Pour éviter cela, de mon côté j’ai défini le catalogue des paires légales {formation, compétence} par le truchement d’une entité-type COMPETENCE_FORMATION, et j'ai aussi défini l'entité-type FORMATION_SUIVIE. L'objectif reste bien de blinder la validité de la base de données.


Je vais regarder la suite.

[dde63]

Bonjour,


Tous les Modèles ont leurs contraintes : Merise comme les SGBDR ou tout autre logiciel de gestion de données.

La particularité de Merise est qu'il n'impose pas une connaissance particulière de ces logiciels permettant ainsi une réflexion élargie du problème soumis. Il permet aussi une validation plus aisée auprès de différents demandeurs du projet.

La phase suivante implique d'autorité une adaption (une adéquation) vers le logiciel envisagé.

Ceci étant dit, et c'est à vous Sophie de le confirmer : Les demandes de Formation sont-elles gérées les unes indépendamment des autres? Dans l'affirmative l'entité Demande peut-être vue comme une association Employé-Formation( dans le cas contraire c'est à étudier). Et rien n'empêche de mon point de vue d'enrichir la Demande considérée des éléments de réponse. Cette approche facilite la lecture du MCD.

Noter : information établie par l'employé nécessite en complément de faire le lien entre Compétence Formation . Ici une remarque sur la cardinalité. Formations fait référence à 1 ou 3 Compétences. Mais dans le même temps ou en décalé, une Compétence donnée peut être invoquée plusieurs fois par Formations. La lecture du MCD rend possible cette notation sur Compétence-Formation désignée pour en vérifier le statut : Acceptée refusée.

Compte-rendu : même remarque que Noter. Mais avec un plus une particularité. Elle compte un Employé qui établit le compte-rendu et celui auquel il est destiné (2 pattes entre Employé Compte-rendu.

Enfin Employé est localisé que dans un seul bureau mais celui peut compter de 1 à n employé. Dans l'absolu nous pourrions considérer un Bureau vide, mais aucun intérêt ici.

Bonne journée

Nb : Si vous en ressentez le besoin, vous pouvez consulter le tutoriel "Parlez vous Merise" où sont ébauchées les caractéristiques Entité Objet et Association dans Merise. D'ailleurs François y a fait indirectement allusion dans une de ces réponses concernant la clé primaire de l'entité Demande.

[Sophie1206]

bonjour, merci pour tous ces conseils. J'ai refais encore une fois mon MCD. Je vois que vous êtes des experts en la matière. Ma prof à vu mon MCD ce matin et m'a dit que c'était pas mal mais qu'il y avait peut être quelques petites choses à revoir. Autant dire qu'elle ne m'a rien dit

Je vous renvois mon MCD. J'ai du mal à mettre une association entre Compétences et Formation. Je suis pas sur que cela aurait un intérêt quelconque ?

Merci.

[fsmrel]

Bonsoir,

Ma prof a vu mon MCD ce matin et m'a dit que c'était pas mal mais qu'il y avait peut-être quelques petites choses à revoir

Elle vous dira entre autres choses que votre association « Faire compte rendu » signifie ceci :

L’employé E est capable de faire un compte rendu dans lequel sont impliquées une compétence C et une formation F.

Mais à propos de quel employé ayant suivi cette formation ? Il n'y a aucun moyen de le savoir. Par ailleurs j’ai écrit « est capable », en effet l’association devrait être porteuse d’un attribut CompteRendu, sinon personne ne pourra rendre compte de quoi que ce soit.

En passant je constate que mes dernières remarques ne vous ont guère inspirée...

J'ai du mal à mettre une association entre Compétences et Formation.

Dans l’état de votre MCD, rien n’empêchera ensuite de faire dire à la base de données qu’un employé a suivi une formation « Merise facile » pour y acquérir les compétences « Parler anglais » ou « savoir s’exprimer en public ». L’entité-type COMPETENCE_FORMATION que j’ai modélisée fera l'objet d'une table servant à blinder la base de données, cette table y jouant le rôle de référentiel, de catalogue imposé à l’utilisateur car celui-ci peut être distrait et arriver à associer tout et n’importe quoi (pour avoir audité des wagons de bases de données j’en témoigne…)

Tous les Modèles ont leurs contraintes : Merise comme les SGBDR ou tout autre logiciel de gestion de données.

Merise n’est pas un modèle mais une méthode, l’ouvrage de référence s’intitule du reste La méthode Merise.

Un SGBDR n’est pas un modèle, mais un système de gestion de bases de données relationnelles.

Les demandes de Formation sont-elles gérées les unes indépendamment des autres?

Pourriez-vous préciser votre pensée ?

Dans l'affirmative l'entité Demande peut être vue comme une association Employé-Formation

Indépendamment de la question précédente, c’est l’hypothèse retenue initialement :

Un employé donné demande à suivre une formation donnée, donc la modélisation naturelle des choses est la suivante :

[EMPLOYE]----0,N--------(DEMANDE)--------0,N----[FORMATION]

Et rien n'empêche de mon point de vue d'enrichir la Demande considérée des éléments de réponse.

Merci de préciser lesquels (sous forme de noms d’attributs tant qu’à faire).

Noter : information établie par l'employé nécessite en complément de faire le lien entre Compétence Formation

« Noter » n’est pas une information mais une association (ou relation, c’est comme vous voulez). L'avant-dernier MCD de Sophie comporte le lien entre COMPETENCE d’une part et FORMATION d’autre part. Simplement, comme je le lui ai signalé, il serait préférable que l’association soit faite avec COMPETENCE_ASSOCIATION (cf. le MCD que j’ai proposé), et tant qu’à faire avec l’entité-type FORMATION_SUIVIE.

Compte-rendu : même remarque que Noter. Mais avec un plus une particularité. Elle compte un Employé qui établit le compte-rendu et celui auquel il est destiné (2 pattes entre Employé Compte-rendu.

C’est bien la traduction du prédicat à 4 places précédemment proposé :

La personne P rend compte du bienfait qu’a retiré l’employé E de la formation F pour la compétence C.

Le prédicat comporte 4 paramètres, par conséquent l’association merisienne résultante doit comporter quatre pattes, or votre association NOTER n’en comporte que trois : elle ne convient pas pour héberger l’attribut Compte-rendu.

En fait, le prédicat est porté en puissance par l’association EVALUATION du MCD que j’ai déjà proposé et ce prédicat figure dans l’en-tête de la table EVALUATION qui en a été dérivée par l’AGL (PowerAMC).

Maintenant, deux cas se présentent :


1) Plusieurs personnes peuvent évaluer (faire chacune leur compte-rendu) concernant la formation au cours de laquelle un employé a acquis telle compétence, auquel cas la table EVALUATION a la structure suivante, comme on l’a vu :




2) Une seule personne peut évaluer, auquel cas la structure est identique, sauf que l’attribut EvaluateuriId ne fait plus partie de la clé primaire (mickey <pk>) :





N.B. Une entité-type n'est pas dotée d'une clé primaire (concept SQL), mais d'un identifiant.

[dde63]

Bonjour Sophie,

Dans mes interventions je m'attache à laisser un espace de décision au demandeur, ce qui ne m'interdit pas d'exprimer telle ou telle remarque.

Dans un de mes 1er post j'ai noté la nécessité d'avoir un "Evaluateur" et un "Evalué" pour établir un Compte-rendu. Remarque passée inaperçue mais point important du Modèle sur lequel il fallait revenir : C'est fait sur mon post précédent.

Pour finir sur ce sujet et répondre à votre question.

Tout d'abord les Formations s'étalent dans le temps et même si le même intitulé se retrouve d'une formation à l'autre il est indispensable de les identifier.
D'autre part les Compétences étant abordée (Evaluer) selon un profil (Type de poste), nous pouvons penser que 2 Formations destinées à des profils différents reprendrons la même référence Compétence, mais plus ou moins pointue au niveau de l'intervention. Tout cela pour dire : Une Formation vise de 1 à 3 Compétence (oublié dans votre dernier modèle). Mais à l'inverse les Compétences seront visée, par N formations. Et conclure que pour faire un bilan de compétence le rédacteur (un employé) devra identifier l'employé concerné et sélectionner de façon précise la Compétence faisant l'objet d'une Formation donnée et une seule, étant entendu qu'il faut s'assurer que le-dit employé a bien suivi cette formation.

Je voudrai revenir sur l'entité Demande .

Ce qui dans un Modèle Merise différencie une entité Objet de l'entité Association tient à peu de chose et n'a aucun caractère scientifique sauf l'intime conviction.

Un Objet peut-être considéré hors de son contexte et conserver tout ou partie de sa signification en plus d'avoir un identifiant permettant de sélectionner chaque occurrence : Employé, Compétence, Formation etc..
Une association ne conserve son intégrité et sa signification qu'avec les Objets associés. Dans le MCD couper toutes les ficelles de "Demande de formation" et il n'y aura plus qu'à jeter le bébé avec son bain. Il est des cas où l'association et transformée un Objet : il s'agit de fluidifier la lecture du modèle mais peu d'impact au niveau du MLD. Dans le cas présent on peut supprimer les association Effectuer et Donner lieu. Formation regroupera toutes les informations utiles au bon suivi de la demande.
Qu'est ce qui différencie l'association "Faire un compte rendu" de "Demander une formation" à part ses attributs?

De façon générale après une première étude du projet dans mon MCD outre une désignation aussi précise que possible ne sont notés que les identifiants nécessaires : Le détail pouvant être reporté sur une annexe. J'ai trouvé des Objets impliquant l'établissement d'une liste telle que le MCD devenait illisible.
Pour ce qui concerne les associations impliquant une date, sauf nécessité je ne représente pas l'Objet (totalement artificiel) mais je reprends l'attribut date dans l'association.
Les besoins de traitement de la Demande reste inchangée en reprenant tous les éléments de l'Objet "demande de formation".
Le Nom des attributs ne change rien à l'affaire, ni même leur format, et même leur présence pour certains comme "Raison refus" : à voir plus tard.
Une remarque toute fois : Accord et Refus sont 2 facettes de la même pièce prévoir donc un seul attribut.

Bon Week-end à tous et le plaisir de vous lire

[dde63]

Bonjour,


Bon d'accord j'ai poussé le bouchon un peu loin. Un rien provocateur . Mais une part de vérité.

Cependant suite à ma réponse portant sur l'établissement du compte-rendu j'ai le sentiment que l'on a oublié un point important du MCD pour comprendre le fonctionnement du compte-rendu et le traitement des demandes (acceptation, refus). Les formations ciblent une catégorie(type de postes) d'employés pour chaque mise en place. Il faudrait donc ajouter l'association Formation-Type de postes permettant ainsi de qualifier le niveau de la formation mise en place.

Bon dimanche.