Bonsoir vero31700 et binôme,
Envoyé par
vero31700
une réponse s'il vous plaît ?
Curieusement, je n’ai reçu votre message du 06/03 qu’aujourd’hui...
Quant à votre dernier MCD, il est arrivé après que j’ai eu rédigé ce qui suit : je laisse ma prose en l’état et vais ensuite regarder de plus près.
__________________________
Ma prose initiale :
Vos règles de production du MLD à partir du MCD sont partiellement correctes.
Dans votre document Word, vous écrivez :
« Les entités deviennent des relations »
En fait, un type d'entité (aka entité-type) authentique (plutôt qu’une entité qui est une instance d’un type : vous et moi sommes des entités et sommes des instances de l’entité-type PERSONNE) donne le plus souvent lieu à une variable relationnelle (une relation est une valeur prise à un moment donné par une variable relationnelle). Ainsi, chacune des entités-types TYPE_POSTE, EMPLOYE, BUREAU, SITE, SALLE, FORMATION, COMPETENCE, DEMANDE_FORMATION, REFUS donne lieu à une relvar (abréviation de variable relationnelle). Vous me direz « Et CALENDRIER ? » En fait, il s’agit là d’une pseudo entité-type, elle en a le goût, mais en Merise elle est présente pour pallier une faiblesse de cette méthode, quand il faut faire intervenir la date comme vous l’avez fait en temps que participant à l’identification d’une association (pr exemple UTILISER), mais avec un AGL comme DB-MAIN, en E/A la date est attribut de l’association en cause, pouvant participer en temps que tel à l’identifiant de l’association. Bref, suite à dérivation du MCD en MLD, la relvar CALENDRIER ne sert plus (elle serait même fort gênante), elle doit disparaître.
Par ailleurs, la clé d’une relvar n’est pas forcément issue de l’identifiant d’une entité-type. Par exemple, l’entité-type REFUS donne lieu à une relvar, mais elle est identifiée relativement à DEMANDE_FORMATION (c’est une entité-type faible, elle n’est pas autonome, elle n’existe que si DEMANDE_FORMATION existe) : la clé de la relvar REFUS sera héritée de celle de la relvar DEMANDE_FORMATION, c'est-à-dire {NumDemande} :
DEMANDEDE FORMATION (NumDemande, DateDemande, RaisonDemande, StatutDemande)
=>
REFUS {NumDemande, RaisonRefusDemande, DateRefusDemande}
Vous écrivez encore :
« Avec CIF on fusionne »
Ici, vous confondez CIF et association 1,1 – x,N, mais bon (à la limite, précisez que votre CIF traduit une relation binaire de type surjection). E tout cas, le verbe « fusionner » est impropre. Prenons l’exemple :
(OCCUPER) TYPEDEPOSTE fusionne dans EMPLOYE
Ce verbe signifie en l’occurrence que les entités-types TYPE_POSTE et EMPLOYE ne feront plus qu’une au sein d’une relvar, ce qui ne fonctionne évidemment pas si elle ne sont pas en bijection...
En réalité, il est plus sain d’écrie que la clé {CodeTypePoste} de la relvar TYPE_POSTE donne lieu à une clé étrangère {CodeTypePoste} dans l’en-tête de la relvar EMPLOYE, ce que vous avez du reste fait ici :
EMPLOYE (CodeEmp, NomEmp, PrénomEmp, DiplomeEmp, DateNaisEmp, NumAdresEmp, RueAdresEmp, CPAdresEmp, VilleAdresEmp, CodeTypPoste# )
N.B. Ne soulignez pas CodeTypPoste, le soulignement et réservé à la clé primaire : si vous soulignez CodeTypPoste, cela voudrait dire qu’un employé peut occuper plusieurs postes à la fois, ce qui est contradictoire avec ce que dit votre MCD.
Concernant cette affirmation :
(AFFECTER) BUREAU fusionne dans EMPLOYE
Je ne sais pas si on rajoute seulement NumSalle#.
Ou si on doit aussi mentionner CodeSite#.
De deux choses l’une, soit un employé est localisé dans un seul bureau, soit il est localisable dans plus d’un bureau.
(a) S’il est localisé dans un seul bureau, alors l’en-tête de la relvar EMPLOYE devient :
EMPLOYE (CodeEmp, NomEmp, PrénomEmp, DiplomeEmp, DateNaisEmp, NumAdresEmp, RueAdresEmp, CPAdresEmp, VilleAdresEmp, CodeTypPoste#, NumBureau)
(b) S’il est localisable dans plus d’un bureau, la relvar EMPLOYE n’a pas à être dotée d’un attribut NumBureau, c’est l’association AFFECTER qui fait l’objet de la relvar suivante :
AFFECTER {CodeEmp, NumBureau)
La patte connectant BUREAU et SE_TROUVER est porteuse d’une cardinalité 1,1 : la clé {CodeSite} de la table SITE donne lieu à une clé étrangère {CodeSite} pour la table BUREAU :
BUREAU {NumBureau, CodeSite, ...}
Vous écrivez :
(FAIRE) EMPLOYE fusionne dans DEMANDEDE FORMATION
Même problème
La patte qui connecte l’entité-type DEMANDE_FORMATION et l’association FAIRE est porteuse d’une cardinalité 1,1 : la relvar DEMANDE_FORMATION est enrichie d’une clé étrangère {CodeEmp} et c’est tout.
Vous écrivez :
« 3ème règle : Les autres associations deviennent des relations. »
En fait, précisez qu’il s’agit des associations de type plusieurs à plusieurs (x,N – y,N).
En passant, la relvar EXIGER_NIVEAU hérite de l’attribut Niveau d l’association EXIGER_NIVEAU :
EXIGER_NIVEAU {CodeTypPoste#, CodeCompétence#, Niveau}
Envoyé par
vero31700
dans l'énoncé il est indiqué que l'employé note la qualité de la formation sur chaque compétences qu'elle devait améliorer de 1 à 3, est-ce que cela est indiqué sur le schéma E/A ?
En principe non, à moins que l’AGL propose une astuce. A défaut, vous décorez le MCD d’une remarque ad-hoc, manuellement. Quoi qu’il en soit, au niveau SQL, cette contrainte (appelons-la NOTER_FOURCHETTE) devra figurer :
MCD
[ EMPLOYE ]----0,N--------( NOTER (Note) )--------0,N----[ FORMATION ]
=>
1 2 3 4 5 6 7 8 9 10 11
|
CREATE TABLE NOTER
(
CodeEmp INTEGER NOT NULL,
CodeFormation INTEGER NOT NULL,
Note INTEGER NOT NULL
CONSTRAINT NOTER_PK (CodeEmp, CodeFormation),
CONSTRAINT NOTER_EMPLOYE FOREIGN KEY (CodeEmp) REFERENCES EMPLOYE (CodeEmp),
CONSTRAINT NOTER_FORMATION FOREIGN KEY (CodeFormation) REFERENCES FORMATION (CodeFormation),
CONSTRAINT NOTER_FOURCHETTE CHECK (Note BETWEEN 1 AND 3)
) ; |
Attention, contrairement aux principaux SGBD, MySQL ne vérifie pas la contrainte NOTER_FOURCHETTE...
Il est aussi précisé dans votre énoncé que l’évaluation d’une compétence est limitée aux lettre de A à H : prévoir une contrainte du même genre que celle que je vous ai fournie.
J’attends la nouvelle version de votre dérivation du MCD en relvars.
_____________________
Fin de la prose initiale
Je vais regarder votre dernier MCD...
Et dire que je voulais faire une sieste
Partager