Discussion :

[obiseb]

Bonjour à tous,
Je dois développer une petite application sous Access et je rencontre des difficultés pour construire une partie de mes tables. Il faut dire que mes cours sur Merise sont très très loin et mes connaissances très parcellaires pour le moment.
L’idée générale est la gestion d’élèves ayant obtenu un examen et qui suivent une formation dans une école. A l’issue de cette formation, l’élève choisi un poste ouvert au type d’examen obtenu.
Pour être plus précis :
- Un candidat passe un examen et à l’issu intègre une promotion pour suivre sa scolarité dans une des écoles ouvertes.
- Le candidat peut être amené à redoubler sa formation et intégrer une autre promotion.
- Si c’est le candidat qui choisi d’arrêter, il ne peut pas intégrer une nouvelle promotion sauf s’il réussi à nouveau un examen d’entrer.
-Un candidat ne peut passer qu’un seul examen à la fois.
- Il existe plusieurs examens possibles et ces derniers sont regroupés en deux types d’examens différents :
Ex : L’examen 1, 2 et 4 correspondent au type d’examen A et l’examen 3 et 5 au type d’examen B
- A l’issue de la scolarité, les élèves obtiennent un classement et un nombre de poste à choisir est ouvert.
- Les postes ont un numéro et sont ouverts selon le type d’examen et la promo.
Ex :
3 postes numéro 100 sont ouverts au type d’examen A pour la promo « prom1 »
2 postes numéro 100 sont ouverts au type d’examen B pour la promo « Prom1 »
1 poste numéro 200 est ouverts au type d’examen A pour la promo « Prom1 »
Ce qui me pose un souci majeur, c’est que je n’arrive pas à modéliser le choix du poste par le candidat. Je voudrais qu’il ne puisse choisir que les postes qui sont ouverts au type d’examen qu’il à passé.
J’ai beau me dire que la solution doit être des plus simple, je n’arrive pas à la trouver.
Merci d’avance pour votre aide.

PS : J’ai utilisé JMerise pour réalisé le MCD, mais je ne maitrise pas bien le produit et je n’ai pas réussi à obtenir exactement ce que je voulais. En effet pour moi, dans la relation élève, la clé est obtenu à partir de la paire (IdCandidat, IdPromo), l’idExamen et l’IdEcole ne sont que des clés étrangères. (Mais je me trompe peut être)

[ZenZiTone]

Bonjour,

Personnellement j'ai une préférence pour les relations simples. Ex :

Une école est composée de promotions, qui sont composées d'élèves. Un élève devient un candidat s'il participe à un examen. Un examen à un type. Ce même type d'examen peut déboucher sur un ou plusieurs postes. Un nombre de postes définit pour chaque promotions.

Si ceci est correct, tu devrais pouvoir dessiner un schéma un peu plus simple (je n'ai pas de modélisateur sur mon poste là :/)

[obiseb]

Bonjour ZenZiTone,

Merci pour cette réponse,
J’apporte quelques précisions car la logique n’est pas tout à fait celle-ci,
- Une même promotion peut être dispatchée sur plusieurs écoles.
Un élève ne devient pas un candidat s’il participe à un examen mais c’est parce qu’un candidat à réussi un examen qu’il devient un élève et intègre une école dans une promotion. (C’est un examen d’entrée en école en fait)
Ce que je n’arrive pas à modéliser, ce sont les relations entre les postes offerts (à cette promotion sur ce type d’examen) et les élèves (pour déterminer le poste qu’il à choisi).
Le tout en respectant la contrainte qu’un élève ne puisse pas choisir un poste ouvert à un type d’examen qui ne correspond pas à l’examen d’entrée qu’il a passé.
J’espère que je suis clair dans mes précisions.

PS J’ai bien tenté de simplifier en traitant ELEVE comme une entité et non comme une relation (en ajoutant un Ideleve et une contrainte d’unicité sur le couple IdPromo, IdCandidat) mais sans succès.

[SQLpro]

Vous avez mélangé élevés et candidat. De plus dans une association on indique une action. à moins que que ce soit le verbe "élever"... vous auriez du faire une entité des élevés qui deviennent naturellement candidat par le fait d'être associé à un examen.

A +

[SQLpro]

Un élève ne devient pas un candidat s’il participe à un examen mais c’est parce qu’un candidat à réussi un examen qu’il devient un élève et intègre une école dans une promotion.

Donc, avant d'être candidat, cet objet est une personne physique :
personne physique => candidat => elève

Dans tous les cas c'est à nouveau une spécialisation.
Il existe naturellement comme personne physique
Il devient candidat par le fait qu'il passe l'examen
il devient élève par le fait qu'il a réussi à l'exam.
Vous avez maintenant vos verbe pour les associations.

A +

[obiseb]

Bonjour,

Et merci pour ces conseilles (ainsi que pour les nombreuses contributions sur le site qui sont une vraie mine d'or

J'avais bien au départ considéré ELEVE comme une entité, j'ai donc corrigés et enlevé cette notion de candidat dont je peux me passer.
Voici un MLD qui correspond plus à ce que j'avais fait au départ. (A l'origine, poste offert était aussi une entité, mais je l'avais remplacé par une relation car je pensais qu'elle était candidate pour le devenir comme les cardinalités étaient en 1,1 0,n pour toutes les pattes)
Surtout, il y a en plus, la relation choisir entre POSTEOFFERT et ELEVE qui permet de connaitre le poste choisi par l'élève.
Et c'est surtout la dessus que je ne vois pas comment faire, car rien n’empêche de choisir un poste dont le type d'examen ne correspond pas à celui que l'élève a passé.
ex : L'élève a passé l'examen 2 qui est de type A, mais je peux tout de même choisir pour lui un poste qui est seulement ouvert au type d'examen B.
Bien sur, je pourrai facilement le gérer autrement (du code par exemple) mais je me dis que ça doit bien être possible de le faire uniquement par le biais de la construction de mes tables. Je me trompe?

Encore merci d'avance

[fsmrel]

Bonsoir obiseb,

Le candidat peut être amené à redoubler sa formation et intégrer une autre promotion.
- Si c’est le candidat qui choisi d’arrêter, il ne peut pas intégrer une nouvelle promotion sauf s’il réussi à nouveau un examen d’entrée.
-Un candidat ne peut passer qu’un seul examen à la fois.

Le modèle fait abstraction du redoublement et de la possibilité de passer une nouvelle fois un examen. Que comptez-vous faire à ce propos ?

A l’issue de la scolarité, les élèves obtiennent un classement

Le classement de l’élève est absent du modèle.


A part ces points de détail, votre modélisation est correcte.


Vous avez déguisé l’association OFFRIR de votre 1er MCD en entité-type POSTE_OFFERT, mais c’est pour la bonne cause, puisque l’association CHOISIR ne peut être établie qu’entre entités-types : pas de problème donc. Toutefois, dans le MLD, la table POSTE_OFFERT doit être dotée d’une clé alternative {IdTypeExamen, IdPoste, IdPromo}, sinon on pourrait trouver des redondances mal venues (cette clé alternative reprend en fait la clé primaire de la table OFFRIR de votre 1er MLD). En fait, l’attribut IdPosteOffert est inutile : à l’instar d’OFFRIR, POSTE_OFFERT peut se satisfaire de {IdTypeExamen, IdPoste, IdPromo} comme clé primaire : le déguisement d’OFFRIR en entité-type POSTE_OFFERT dans le MCD ne doit en rien se répercuter sur la structure des tables.

Autre point : dans votre MCD, la patte connectant l’entité-type ELEVE et l’association CHOISIR est porteuse d’une cardinalité 1,1, en conséquence de quoi, dès qu’il fait l’objet d’une ligne dans la table ELEVE, tout élève est affecté à un poste. Si ça ne peut pas être le cas, la cardinalité 1,1, est à remplacer par une cardinalité 0,1. Au stade MLD, la cardinalité 0,1 impose la mise en oeuvre d’une table, appelons-la CHOISIR, sinon vous auriez une clé étrangère hébergeant le bonhomme Null et ça n’est pas recommandé.


MLD

Et c'est surtout la dessus que je ne vois pas comment faire, car rien n’empêche de choisir un poste dont le type d'examen ne correspond pas à celui que l'élève a passé.
ex : L'élève a passé l'examen 2 qui est de type A, mais je peux tout de même choisir pour lui un poste qui est seulement ouvert au type d'examen B.
Bien sur, je pourrai facilement le gérer autrement (du code par exemple) mais je me dis que ça doit bien être possible de le faire uniquement par le biais de la construction de mes tables. Je me trompe?

Il est certain que rien n’empêche que l’élève Raoul qui a passé l’examen 2 qui est de type A soit affecté à un poste ouvert à un examen relevant du type B.

Il faudra donc mettre en œuvre un trigger contrôlant les mises à jour de la table CHOISIR.

Il y a aussi une vieille ruse pour ne pas en passer par là :

— Identifier EXAMEN relativement à TYPE_EXAMEN afin de propager l’attribut IdTypeExamen jusqu’à ELEVE, et définir pour cette table une surclé {IdEleve, IdTypeExamen, IdPromo} ;

— Brancher la table CHOISIR sur la table ELEVE au moyen de la clé étrangère {IdEleve, IdTypeExamen, IdPromo}.

MLD






C’est ça ou des triggers. Les puristes pourraient hurler, mais ça n’est pas grave


En SQL, histoire de fixer les idées :

CREATE TABLE TYPE_EXAMEN 
(
   IdTypeExamen         INT         NOT NULL,
   LibelleTypeExamen    VARCHAR(64) NOT NULL,
   CONSTRAINT TYPE_EXAMEN_PK PRIMARY KEY (IdTypeExamen)
) ;

CREATE TABLE POSTE 
(
   IdPoste              INT         NOT NULL,
   LibellePoste         VARCHAR(64) NOT NULL,
   CONSTRAINT POSTE_PK PRIMARY KEY (IdPoste)
) ;

CREATE TABLE PROMOTION 
(
   IdPromo              INT         NOT NULL,
   CONSTRAINT PROMOTION_PK PRIMARY KEY (IdPromo)
) ;

CREATE TABLE POSTE_OFFERT 
(
   IdTypeExamen         INT         NOT NULL,
   IdPromo              INT         NOT NULL,
   IdPoste              INT         NOT NULL,
   NbrePostes           VARCHAR(64) NOT NULL,
   CONSTRAINT POSTE_OFFERT_PK PRIMARY KEY (IdTypeExamen, IdPoste, IdPromo),
   CONSTRAINT POSTE_OFFERT_TYPE_EXAMEN_FK FOREIGN KEY (IdTypeExamen)
      REFERENCES TYPE_EXAMEN (IdTypeExamen),
   CONSTRAINT POSTE_OFFERT_POSTE_FK FOREIGN KEY (IdPoste)
      REFERENCES POSTE (IdPoste),
   CONSTRAINT POSTE_OFFERT_PROMOTION_FK FOREIGN KEY (IdPromo)
      REFERENCES PROMOTION (IdPromo)
) ;

CREATE TABLE EXAMEN 
(
   IdTypeExamen         INT         NOT NULL,
   IdExamen             INT         NOT NULL,
   LibelleExamen        VARCHAR(64) NOT NULL,
   CONSTRAINT EXAMEN_PK PRIMARY KEY (IdTypeExamen, IdExamen),
   CONSTRAINT EXAMEN_TYPE_EXAMEN_FK FOREIGN KEY (IdTypeExamen)
      REFERENCES TYPE_EXAMEN (IdTypeExamen)
) ;

CREATE TABLE ECOLE 
(
   IdEcole              INT         NOT NULL,
   LibelleEcole         VARCHAR(64) NOT NULL,
   CONSTRAINT ECOLE_PK PRIMARY KEY (IdEcole)
) ;

CREATE TABLE ELEVE 
(
   IdEleve              INT         NOT NULL,
   IdTypeExamen         INT         NOT NULL,
   IdExamen             INT         NOT NULL,
   IdPromo              INT         NOT NULL,
   IdEcole              INT         NOT NULL,
   CONSTRAINT ELEVE_PK PRIMARY KEY (IdEleve),
   CONSTRAINT ELEVE_AK UNIQUE (IdEleve, IdTypeExamen, IdPromo),     -- surclé
   CONSTRAINT ELEVE_EXAMEN_FK FOREIGN KEY (IdTypeExamen, IdExamen)
      REFERENCES EXAMEN (IdTypeExamen, IdExamen),
   CONSTRAINT ELEVE_PROMOTION_FK FOREIGN KEY (IdPromo)
      REFERENCES PROMOTION (IdPromo),
   CONSTRAINT ELEVE_ECOLE_FK FOREIGN KEY (IdEcole)
      REFERENCES ECOLE (IdEcole)
) ;

CREATE TABLE CHOISIR 
(
   IdEleve              INT         NOT NULL,
   IdTypeExamen         INT         NOT NULL,
   IdPromo              INT         NOT NULL,
   IdPoste              INT         NOT NULL,
   CONSTRAINT CHOISIR_PK PRIMARY KEY (IdEleve),
   CONSTRAINT CHOISIR_POSTE_OFFERT_FK FOREIGN KEY (IdTypeExamen, IdPoste, IdPromo)
      REFERENCES POSTE_OFFERT (IdTypeExamen, IdPoste, IdPromo),
   CONSTRAINT CHOISIR_ELEVE_FK FOREIGN KEY (IdEleve, IdTypeExamen, IdPromo)
      REFERENCES ELEVE (IdEleve, IdTypeExamen, IdPromo)
) ;

Si votre SGBD est antique et veut à tout prix que les clés étrangères fassent référence exclusivement à des clés primaires, il faudra permuter les rôles de la surclé et de la clé primaire dans la table ELEVE, mais ça n’est qu’un problème de forme.

[obiseb]

Bonjour Fsmrel,

Et un grand, un énorme , pour avoir consacré du temps à mon problème et surtout pour ces excellents conseils, remarques et solutions.
C’est juste parfait et malgré des difficultés pour mettre ça en place, ca marche du tonnerre maintenant.

Le classement de l’élève est absent du modèle.

Oups ! Oui en effet, je l'ai ajouté à la table ELEVE

Autre point : dans votre MCD, la patte connectant l’entité-type ELEVE et l’association CHOISIR est porteuse d’une cardinalité 1,1, en conséquence de quoi, dès qu’il fait l’objet d’une ligne dans la table ELEVE, tout élève est affecté à un poste. Si ça ne peut pas être le cas, la cardinalité 1,1, est à remplacer par une cardinalité 0,1. Au stade MLD, la cardinalité 0,1 impose la mise en oeuvre d’une table, appelons-la CHOISIR, sinon vous auriez une clé étrangère hébergeant le bonhomme Null et ça n’est pas recommandé.

Effectivement, je me suis trompé sur la cardinalité, il s'agit bien d'une cardinalité 0,1 qui nécessite la table "CHOISIR".

Il y a aussi une vieille ruse pour ne pas en passer par là :
— Identifier EXAMEN relativement à TYPE_EXAMEN afin de propager l’attribut IdTypeExamen jusqu’à ELEVE, et définir pour cette table une surclé {IdEleve, IdTypeExamen, IdPromo} ;
— Brancher la table CHOISIR sur la table ELEVE au moyen de la clé étrangère {IdEleve, IdTypeExamen, IdPromo}.

C'est exactement ce que je cherchais à faire sans succès. Je ne suis pas prêt d'oublier cette vieille ruse de lien relatif, (que l'on note dans le MCD avec des parenthèses autour des cardinalités si j'ai bien compris ?) ni l'usage de la surclé.

Si votre SGBD est antique et veut à tout prix que les clés étrangères fassent référence exclusivement à des clés primaires, il faudra permuter les rôles de la surclé et de la clé primaire dans la table ELEVE, mais ça n’est qu’un problème de forme.

Effectivement, j'utilise Access 2010 (pas le choix pour le moment) et ce dernier refusait catégoriquement de me créer les relations en suivant la construction que vous m'aviez conseillé.
J'ai donc passé la surclé {IdEleve, IdTypeExamen, IdPromo} de la table ELEVE en clé principal (comme suggéré) pour pouvoir créer correctement mes relations. (Mais ça n'a pas été sans mal)

Le modèle fait abstraction du redoublement et de la possibilité de passer une nouvelle fois un examen. Que comptez-vous faire à ce propos ?

J'ai ajouté en plus une contrainte d'unicité sur le couple {IdEleve, IdPromo} de la table ELEVE afin de gérer le redoublement.
De cette manière un élève ne peut pas être présent 2 fois sur une même promotion avec un type d'examen différent mais il peut en revanche être présent sur plusieurs promotions.

J'ai peut être encore commis des erreurs de construction mais tout semble fonctionner parfaitement bien.
Mais vu les difficultés rencontrés, je vais me plonger assidument dans quelques lectures tel que "parlez vous merise" de Michel DIVINE et beaucoup, beaucoup d'exercices.

Encore merci.

PS : J'attends un jour ou deux avant de mettre la discussion comme résolu pour le cas ou vous voudriez apporter une dernière précision.

[fsmrel]

Bonsoir obiseb,

Je ne suis pas prêt d'oublier cette vieille ruse de lien relatif, (que l'on note dans le MCD avec des parenthèses autour des cardinalités si j'ai bien compris ?)

Le symbolisme utilisé pour l’identification relative dépend de l’AGL qu’on utilise.

Avec PowerAMC (payant), on met effectivement entre parenthèses la cardinalité 1,1 :






Avec WinDesign (payant), c’est la lettre « R » qu’on met entre parenthèses :






Avec Open ModelSphere (gratuit, mais singulièrement pénible quand il s’agit de passer au MLD), on souligne la cardinalité 1,1 :






Avec DB-MAIN (gratuit, un peu déroutant au départ, mais sans défaut particulier), l’identifiant est explicité dans le cartouche : « id: REGROUPER.TYPE_EXAMEN, IdExamen » :






Etc. !

Avec ACCESS : le problème ne se pose pas, puisque le niveau MCD n’existant pas, on est directement au niveau MLD :

Effectivement, j'utilise Access 2010 (pas le choix pour le moment) et ce dernier refusait catégoriquement de me créer les relations en suivant la construction que vous m'aviez conseillé.
J'ai donc passé la surclé {IdEleve, IdTypeExamen, IdPromo} de la table ELEVE en clé principal (comme suggéré) pour pouvoir créer correctement mes relations. (Mais ça n'a pas été sans mal).

Ach ! Encore une vieille ruse en vue
Pour ma part, de chaque CREATE TABLE (cf. message #7) j’ai fait une requête ACCESS :






J’ai exécuté ces requêtes dans l’ordre des CREATE TABLE défini dans le message #7, et j’ai donc créé les tables sans problème, sans qu’ACCESS rouspète, elles sont là (dans l’ordre alphabétique) :





Le MLD correspondant est rigolo :






Quoi qu’il en soit, les clés étrangères sont en place et la clé alternative d’origine ELEVE_AK de la table ELEVE est bien là :

J'ai ajouté en plus une contrainte d'unicité sur le couple {IdEleve, IdPromo} de la table ELEVE afin de gérer le redoublement.

Balek ! J’ai écrit :

« Si votre SGBD est antique et veut à tout prix que les clés étrangères fassent référence exclusivement à des clés primaires, il faudra permuter les rôles de la surclé et de la clé primaire dans la table ELEVE »

Certes vous avez rendu le triplet {IdEleve, IdTypeExamen, Id Promo} clé primaire, mais en échange le singleton {EleveId} devient clé alternative, et cela doit être pris en compte. Autrement dit, la paire {IdEleve, IdPromo} est une surclé qui devient strictement inutile. Maintenant, si vous décidez que {EleveId} n’est plus clé candidate, attention, l’élève Raoul pourra choisir plus d’une école (est-ce possible ?), il pourra choisir un poste par promotion... Il va falloir étudier des scénarios du genre : conservation de {EleveId} comme clé candidate et mise en oeuvre d’une 2e association entre ELEVE et PROMOTION. Ne m'en veuillez pas, mais il y a là matière à réfléchir...

C’est juste parfait et malgré des difficultés pour mettre ça en place, ca marche du tonnerre maintenant.

Alors n’hésitez pas à voter pour les réponses qui vous ont aidé et cliquer sur fsmrel, puis « Voir le profil Pro », puis « Confirmer les compétences » si vous estimez que j’ai effectivement quelque compétence. Être reconnu ça fait toujours plaisir...