Discussion :

[avehri]

Bonsoir tout le monde

Soit une école qui offre des formations sur concours une fois par an
Voici pour résumer les règles de gestion où je bloque

RG1 : Un candidat doit dans un premier temps choisir au moins 5 des formations disponibles (préinscription)
RG2 : chaque formation peut être ouverte dans un ou plusieurs modes(en alternance, en cours de soir ou en cours de jour)
RG3 : Après entretient avec les responsables de chacune des formations, il en choisi une (inscription)
RG4 : Le candidat passe obligatoirement un concours dans la spécialité choisie
RG5 : Un candidat qui obtient une note >= 10 sera retenu et devient un étudiant et est affecté à une section
RG6 : Un candidat qui n'obtient pas la note requise pour la formation choisie est soit réorienté vers une autre formation soit carrément renvoyé

Je vaudrais concevoir dans un premier temps une base de données pour gérer les inscription et l'affectation des étudiants aux sections puis la deuxième étape la gestion du cursus de l'étudiant

Je bloque surtout sur le candidat qui devient étudiant s'il obtient une note >= 10.

Je vaudrais avoir votre aide pour concevoir un MCD

Merci tout le monde

[fsmrel]

Bonjour avehri,

Manifestement, les concepts FORMATION, CANDIDAT, RESPONSABLE, SECTION donneront lieu à entités-types.

A priori, ENTRETIEN sent plutôt l'association.

FORMATION et SPECIALITE sont vraisemblablement SYNONYMES. Qu’en est-il ?

Conservez-vous l’historique d’une formation ?

Même si a n'est pas indispensable, êtes-vous doté d’un outil de modélisation ? (Par exemple PowerAMC, DB-MAIN, JMerise, WinDesign).

[avehri]

Bonsoir fsmrel

Merci pour votre la réponse

Effectivement FORMATION et SPECIALITE sont des synonymes
Oui, je désire garder l'historique des formation, j'ai pensé à quelque chose comme session

Voici ce que j'ai pu faire



Il me reste Les RG3 à RG6

[fsmrel]

Bonsoir avehri,


Attention aux associations ternaires, quaternaires et plus. Selon votre MCD, quand un candidat [pré-]choisit une formation, il choisit obligatoirement un mode de formation et une session. Dans le cas de la pré-inscription, le candidat Raoul choisit au moins 5 formations, d’accord. Mais, questions :

(Q1) L’association CHOISIR prend-elle en compte la pré-inscription de Raoul ?

(Q2) : Pour chaque formation que Raoul a choisie, doit-on simultanément avoir connaissance du mode de formation correspondant ? Cela peut-il être déterminé ultérieurement ?

(Q3) : Pour chaque formation que Raoul a choisie, doit-on simultanément avoir connaissance de la session correspondante ? Si l’entité-type SESSION joue un rôle dans l’historisation, cela ne devrait pas être le cas.

Avant de penser historisation, il faudra déjà voir à faire fonctionner le système sans cette notion.

Par ailleurs, je fais observer que selon votre MCD, du fait de la présence de boucles, la formation F1 proposée pour la session S1 (association PROPOSER) peut ressortir au mode de formation M1 alors que la paire <F1, M1> sera absente de l’association AVOIR MODE (disons dans la base de données). A moins que vous ne proposiez une règle de gestion l’infirmant, il manque une contrainte d’inclusion entre les associations PROPOSER et AVOIR MODE. Dans le même sens, il manque une contrainte d’inclusion entre les associations CHOISIR et PROPOSER : à défaut, on pourrait trouver dans CHOISIR le quadruplet <Raoul, F2, M2, S2> tel que le triplet <F2, M2, S2>soit inconnu de PROPOSER, voire la paire <F2, M2> absente de AVOIR MODE...


Une remarque : les identifiants « primaires » doivent être invariants, donc hors de portée de l’utilisateur, voyez mon billet De l’invariance des clés primaires à ce sujet, et méditez ce que dit Yves Tabourier, ce que n’a manifestement pas fait un forumeur commentant ce billet, plus compétent en matière de SIRET que de modélisation des données...

Ci-dessous, les identifiants alternatifs {CandidatNumero} et {Formationcode} ne sont que des points d’entrée dans le système, c’est nécessaire et suffisant.

J’ai fait une tentative avec Open ModelSphere, mais avec énormément de mal, car il plante sans arrêt pour des problèmes liés à Java...

L’identifiant alternatif {CandidatNumero} est repéré par le symbole <1>. Pour l’obtenir, partir de la liste des mickeys de identifiants alternatifs :

Votre défi : éviter les boucles et les associations de degré > 2...

[avehri]

Bonsoir fsmrel

Merci pour ces remarques très pertinentes

R1) Oui, c'est l'association choisir qui prend en compte les préinscriptions

R2) Une même formation peut être proposé dans plusieurs modes de formation dans la même session. Par exemple la formation (DBA10, 'Implémentation et administration de SQL Server 2012') peut entre proposé dans les différents modes de formation à savoir (alternance, cours de soir, cours de jour)

R3) Les formation disponibles diffèrent d'une session à une autre selon des considérations tel que la disponibilité des formateurs, les salles informatiques, etc. Moi j'ai pensé a l'entité-type SESSION surtout pour les information des inscriptions tel que date de début fin des inscriptions, date fin des inscriptions. Si vous avez une autre solution, elle a la bienvenue

Pour les contraintes d'inclusion (contraintes inter-associations) totalement d'accord. je ne les ai pas oublié c'est juste que je ne vois pas comment les réaliser avec Open ModelSphere. sinon je vais utiliser JMerise

[fsmrel]

Bonsoir avehri,

(Q1) Le choix par le candidat Raoul du mode de formation se fait-il au moment de la pré-inscription ? de l’inscription ? Autre ?

(Q2) La pré-inscription et l’inscription donnent l’effet d’être des éléments statiques, représentant essentiellement le QUOI (on ne parle pas encore du QUAND, si ce n’est la date effective de l’inscription), alors qu’avec la session on rentre dans le concret, elle donne l’effet d’un élément plutôt dynamique : le QUAND, la date à laquelle la formation aura lieu, peut-être encore inconnue au moment de l’inscription de Raoul, du fait d’un nombre insuffisant de candidats...), le COMMENT (les ressources que vous évoquez : salles, formateurs...)). S’il en est ainsi, il est important de bien marquer la différence, l’écrire. Quelle est votre position ? Le choix de la session se fait-il au moment de l’inscription ? Plus tard ?

Mes questions peuvent paraître anodines, sinon puériles, mais le départ de la bonne modélisation sera la conséquence de vos réponses...

Comme dit le proverbe chinois, mieux vaut paraître bête pendant quelques instants que rester idiot toute sa vie...

En ce qui concerne les contraintes d’inclusion et autres impedimenta du même tonneau, JMerise vous permettra de les représenter, mais ça n’est pas lui qui fournira le code SQL (ou autre) nécessaire à leur mise en oeuvre.
J’ai sous le coude au moins deux débuts de MCD, où ces contraintes seront, disons, sans objet dans la mesure où les boucles devraient disparaître. La réponse à la question Q1 sera pas mal déterminante.

[avehri]

Bonjour fsmrel

Merci encore une fois pour toutes ces remarque

(Q1) Le choix par le candidat Raoul du mode de formation se fait-il au moment de la pré-inscription ? de l’inscription ? Autre ?

R1) Oui, le choix du mode de formation se fait au moment de la pré-inscription, les formations disponibles dans les différents mode de formation ne sont pas nécessairement les mêmes. Par exemple un candidat qui travaille la journée, opte pour le mode de formation cours de soir et choisi parmi les formations disponibles dans ce mode de formation sachant que la même formation peut être disponible en même temps en cours de jour ou en alternance.
L'inscription consiste à confirmer son choix d'une seule formation (pour passer le concours dans la formation confirmé) parmi les 5 choisi au préalable (à la préinscription).

la date à laquelle la formation aura lieu, peut-être encore inconnue au moment de l’inscription de Raoul, du fait d’un nombre insuffisant de candidats...), le COMMENT (les ressources que vous évoquez : salles, formateurs...)). S’il en est ainsi, il est important de bien marquer la différence, l’écrire.

Q2) Les dates de début des inscription et de fin des inscriptions ainsi que la date de concours et de début de formation sont connue d'avance (les deux dernières date date concours et date début formation, je l'ai retiré volontairement du MCD pour ne pas l'encombrer pour le moment mais je les vois dans l'entité SESSION).
En pratique ça se passe ainsi:
Le chargé des inscriptions (poste de travail) reçoit un plan de formation (ce plan est élaboré lors d'une réunion de travail avec les collaborateurs concerné (responsables, formateurs, etc.) c'est à ce moment qu'on évoque la disponibilité des salle et des formateurs pour décider des formation à ouvrir pour la prochaine SESSION, donc je pense que l'élaboration du plan de formation dépasse le cadre des inscription)
Je revient au chargé des inscription, quant il reçoit le plan de formation tout est décidé, il y trouve .

• La date à laquelle il doit commencer à inscrire les candidat

• La date de fin des inscriptions

• La date de concours

• La date de début de formation

• L'ensemble des formations ouvertes (code et intitulé) pour chaque mode de formation (je rappelle que la même formation peut être disponible dans différent modes de formations comme je peut la trouver que dans un seul mode et ça diffère d'une session à une autre)

• On y trouve même le nombre de places pédagogiques disponibles pour chaque formation dans chaque mode de formation

[fsmrel]

Bonjour avehri,

Voilà une réponse exhaustive, dont devraient s’inspirer bien des forumeurs...

Encore quelques précisions à apporter :

(Q1) Soit F1 une formation et M1 un mode de formation donnés. Logiquement, la paire {F1, M1} peut faire l’objet de plusieurs sessions (surtout les formations qui ont du succès !). En est-il ainsi ?

(Q2) Supposons que la réponse à Q1 soit positive. Soit S1 une telle session. Peut-on affirmer que S1 fait référence à la seule paire {F1, M1}, c'est-à-dire que S1 ne peut pas faire référence aux paires {F1, M2} et {F2, M1} ?

(Q3) En corollaire, outre les 5 formations possibles et leur mode qu’il faut présenter à Raoul lors de sa pré-inscription, doit-on lui présenter le calendrier correspondant, à savoir les dates de la (ou des) prochaine(s) session(s) attachée(s) à la paire {Fx, My}, sachant qu’il ne pourra être inscrit (confirmez-vous ?) qu’à la seule session S1 ?

[avehri]

Bonsoir fmsrel

Merci pour votre patience avec moi

(Q1) Soit F1 une formation et M1 un mode de formation donnés. Logiquement, la paire {F1, M1} peut faire l’objet de plusieurs sessions (surtout les formations qui ont du succès !). En est-il ainsi ?

R1) Oui, je confirme la paire {F1, M1} peut faire l'objet de plusieurs sessions

(Q2) Supposons que la réponse à Q1 soit positive. Soit S1 une telle session. Peut-on affirmer que S1 fait référence à la seule paire {F1, M1}, c'est-à-dire que S1 ne peut pas faire référence aux paires {F1, M2} et {F2, M1} ?

R2) Non au contraire, S1 ne fait pas référence qu'à la seule paire {F1, M1}, mais S1 peut faire référence aux paires {F1, M2} et {F2, M1}

R3)
a) Oui, les date sont connue d'avance, à la pré-inscription on informe le candidat des différentes dates de la session en cours (il n y a qu'une seule session à la fois, par exemple la session de Septembre 2018) la prochaine serait probablement Septembre 2019 les inscriptions seront ouvertes environs 1 mois avant le début des formations

b) Je confirme qu' un candidat ne peut s'inscrire qu'à la seule session en cours S1 (à la période des inscriptions bien entendu), en répondant à cette question je comprend tout de suite qu'on doit détacher du MCD la patte qui lie SESSION à CHOISIR pour la lier au CANDIDAT si je ne me trompe pas bien sur.

[fsmrel]

Bonsoir avehri,

Je confirme qu' un candidat ne peut s'inscrire qu'à la seule session en cours S1 (à la période des inscriptions bien entendu), en répondant à cette question je comprend tout de suite qu'on doit détacher du MCD la patte qui lie SESSION à CHOISIR pour la lier au CANDIDAT si je ne me trompe pas bien sur.

Fonctionnellement, vous ne vous trompez pas, puisque n’ayant pas le don de la bilocation, un candidat ne peut pas au même instant participer à deux sessions ayant lieu dans des salles distinctes. Détacher CHOISIR de SESSION au bénéfice d’un lien entre CANDIDAT et SESSION est techniquement possible, mais se pose alors un nouveau problème de boucle à résoudre par une contrainte d’inclusion : la session retenue pour Raoul doit être compatible avec la formation et le mode de formation choisis par ce candidat...

En attendant, je propose les règles de gestion des données suivantes (à ma sauce), afin de vérifier que nous sommes en phase :

(RG1) Soit F1, F2 des formations quelconques, M1,M2 des modes de formation quelconques, S1,S2 des sessions quelconques. Les combinaisons suivantes sont légales :

{F1, M1, S1}
{F1, M1, S2}
{F1, M2, S1}
{F1, M2, S2}
{F2, M1, S1}
{F2, M1, S2}
{F2, M2, S1}
{F2, M2, S2}
...

Autrement dit, au cours de l’élaboration du plan de formation, il est possible de tricoter a priori n’importe quelle formation avec n’importe quel mode de formation et n’importe quelle session.

(RG2) Tout candidat, par exemple Raoul, se préinscrit à au moins 5 formations.

(RG3) Il n’y a pas d’objection à ce que la préinscription de Raoul porte sur plusieurs modes de formation (sous réserve de compatibilité avec les formations faisant l’objet de cette préinscription).

(RG4) Il n’y a pas d’objection à ce que la pré-inscription de Raoul porte sur plusieurs sessions (sous réserve de compatibilité avec les formations et les modes de formation faisant l’objet de cette préinscription).

(RG5) Par contre, lors de son inscription, Raoul n’a droit qu’à une seule formation, un seul mode de formation et une seule session.

Si on est d’accord sur ces règles, notamment RG5, alors on tient le bon bout, le MCD correspondant est au frigo. Mais c’est surtout le MLD qui devient intéressant.

Pour l’anecdote, tout cela me rappelle le bon temps, quand j’avais donné une formation « Bases de données » à l’INPED (Boumerdès), c’était en juin 1977...

[avehri]

Bonjour fmsrel

Merci beaucoup encore une fois

(RG1) Soit F1, F2 des formations quelconques, M1,M2 des modes de formation quelconques, S1,S2 des sessions quelconques. Les combinaisons suivantes sont légales :

{F1, M1, S1}
{F1, M1, S2}
{F1, M2, S1}
{F1, M2, S2}
{F2, M1, S1}
{F2, M1, S2}
{F2, M2, S1}
{F2, M2, S2}
...

Autrement dit, au cours de l’élaboration du plan de formation, il est possible de tricoter a priori n’importe quelle formation avec n’importe quel mode de formation et n’importe quelle session.

Sauf qu'un plan de formation ne concerne qu'une seule session (S1 et S2 sont indépendante dans le temps et ne peuvent pas exister en même temps), dans une session (ex septembre 2017) plusieurs formations ont été ouvertes, chacune de ces formation a été proposée dans un ou plusieurs modes de formations.
Le plan de formation de septembre 2018 est en cours d'élaboration, les inscription pour cette session ne sont pas encore possible il faut attendre fin août début septembre 2018.
Il faut comprendre une session comme une rentrée (universitaire par exemple, formation professionnelle). donc S1 et S2 sont indépendantes dans le temps.
les dates d'une session (date début inscription, date fin inscription, date concours et date début formation) sont les mêmes pour toutes les formations proposées pour la session (entrée) en cours ou prochaine si vous voulez si on se situe juste avant la rentrée.
pour reprendre votre exemple, on aura
Septembre 2017 (les formations sont déjà en cours depuis fin septembre environ)
{F1, M1, S1}
{F1, M2, S1}
{F2, M1, S1}
{F2, M2, S1}

Septembre 2018 (Les inscriptions ne sont pas encore ouvertes)
{F1, M1, S2}
{F1, M2, S2}
{F2, M1, S2}
{F2, M2, S2}

(RG2) Tout candidat, par exemple Raoul, se préinscrit à au moins 5 formations.

Totalement d'accord

(RG3) Il n’y a pas d’objection à ce que la préinscription de Raoul porte sur plusieurs modes de formation (sous réserve de compatibilité avec les formations faisant l’objet de cette préinscription).

Totalement d'accord

(RG4) Il n’y a pas d’objection à ce que la pré-inscription de Raoul porte sur plusieurs sessions (sous réserve de compatibilité avec les formations et les modes de formation faisant l’objet de cette préinscription).

Comme je vient de l'expliquer à la RG1, un candidat Par exemple Raoul qui suit actuellement (S1 session septembre 2017) une formation de création de site web statiques et dynamique, pourra suivre une autre formation en septembre 2018 (donc S2 session septembre 2018) (a condition qu'il aura terminé la formation en cours). t dans ce cas de figure Raoul sera considéré comme nouveau candidat, un nouveau numéro, une nouvelle préinscription avec au moins 5 formation et un nouveau concours

(RG5) Par contre, lors de son inscription, Raoul n’a droit qu’à une seule formation, un seul mode de formation et une seule session.

Je confirme, sauf pour session (rentrée) il n y a qu'une seule session à la fois

Pour l’anecdote, tout cela me rappelle le bon temps, quand j’avais donné une formation « Bases de données » à l’INPED (Boumerdès), c’était en juin 1977

Je comprend vous avez grandi avec les bases de données

[fsmrel]

Bonsoir avehri,


j’ai pas mal tartiné dans ce post, mais votre sujet est intéressant et permet de mettre en évidence certaines difficultés, voire impossibilités au stade du MCD merisien, faisant qu’il faut se résoudre à agir au stade du MLD pour arriver à respecter les règles de gestion des données.

Pour reprendre votre exemple, on aura
Septembre 2017 (les formations sont déjà en cours depuis fin septembre environ)
{F1, M1, S1}
{F1, M2, S1}
{F2, M1, S1}
{F2, M2, S1}

Septembre 2018 (Les inscriptions ne sont pas encore ouvertes)
{F1, M1, S2}
{F1, M2, S2}
{F2, M1, S2}
{F2, M2, S2}

Cet exemple correspond à votre association PROPOSER, c'est-à-dire que les 8 valeurs seront présentes ensemble, et que les 4 dernières ne viendront pas effacer les 4 premières. En tout cas, c’est ce que j’ai retenu comme hypothèse, sinon cette association disparaît et les triplets sont remplacés par des paires {Fx, My}.

Il faut comprendre une session comme une rentrée (universitaire par exemple, formation professionnelle). donc S1 et S2 sont indépendantes dans le temps.

Je n’avais pas compris les choses ainsi, mais l’ éclairage que vous apportez permet de réorganiser la structure de l’entité-type SESSION de façon intéressante.

Structure initiale :

Figure 1

En passant, par référence à mon billet « De l’invariance des clés primaires », j’attire votre attention sur le fait que l’attribut session doit faire l’objet d’un identifiant alternatif, l’identifiant primaire, invariant, non significatif, caché à l’utilisateur étant un nouvel attribut, appelons-le par exemple SessionId.

Mais le point important est que pour une année donnée, il ne peut y avoir qu’une session, donc l’année peut être considérée comme identifiant candidat de l’entité-type SESSION.

Dans la structure, pour qu’il n’y ait pas d’ambiguïté, je renomme l’attribut session en SessionCode.
Les identifiants de SESSION sont : SessionId, SessionCode, SessionAnnee. Ainsi, les tuples suivants sont légaux :

{1, S000001, 2016}
{2, S000002, 2017}
{3, S000003, 2018}

Mais les tuples suivants seront rejetés du fait de l’existence des précédents :

{4, S000002,2019} : deux sessions ne peuvent pas avoir le même code, en l’occurrence S000002 ;
{5, S000004,2017} : deux sessions ne peuvent pas avoir lieu la même année.

Structure modélisée (PowerAMC) :

Figure 2

Structure dans laquelle j’ai fait figurer le mois, mais à vous de juger de l’opportunité de la chose.

Passons à l’association AVOIR MODE entre FORMATION et MODE_FORMATION.

Structure initiale :

Figure 3

Si vous tenez conserver cette association, il y aura un problème quand il s’agira d’établir une association avec l’entité-type SESSION, car Merise (dans sa version traditionnelle, normalisée) ne permet pas d’établir une association avec une association.

Je passe à PowerAMC car décidemment je plante tant et plus avec Open ModelSphere :

Figure 4

Ce que l’on peut vouloir modéliser :

Figure 5

Mais bien entendu en essayant cela, on se fait jeter...

Aux grands maux, les grands remèdes. En revenant à la figure 4, on déguise l’association AVOIR_MODE en entité-type associative :

Figure 6

Vous noterez que les cardinalités 1,1, son mises entre parenthèses : c’est la convention PowerAMC pour signifier l’identification de l’entité-type AVOIR_MODE relativement à FORMATION d’une part et à MODE_FORMATION d’autre part. Ainsi, AVOIR_MODE a pour identifiant la paire {FormationId, ModeFormationId}, héritage de FORMATION et MODE_FORMATION.

Ceci fait, on peut passer de la figure 4 à la suivante :

Figure 7

Ce qui se rapproche de votre représentation, mais sans la boucle imposant la mise en oeuvre d’une contrainte d’inclusion entre les associations AVOIR_MODE et PROPOSER :

Figure 8

On peut maintenant passer aux préinscriptions.

Le candidat Raoul postule pour intégrer une session Sx et choisit au moins 5 formations. Intuitivement on peut donc être amené à représenter les choses comme ci-dessous, mais a-t-on la garantie que le choix de Raoul est bien compatible avec les formations proposées pour la session Sx ?

Figure 9

La réponse est négative, puisqu’on sait seulement d’une part que Raoul a pré-choisi des formations et d’autre part qu’il postule pour intégrer la formation Sx, ce qui est insuffisant pour répondre positivement. On pourrait chercher à mettre en oeuvre une contrainte telle que ci-dessous, mais celle-ci dit seulement qu’un candidat qui pré-choisit est un candidat qui nécessairement commence par postuler, ce qui nous fait une belle jambe et ne répond pas à notre exigence :

Figure 10

Cela revient à dire que l’association CHOISIR est à brancher sur l’association PROPOSER car celle-ci permet de savoir quelles formations sont associées aux sessions, mais Merise rejetant les associations avec des associations, on commencera par transformer PROPOSER en entité-type :

Figure 11

Suite à quoi, on peut mettre en oeuvre la contrainte d’inclusion selon laquelle le candidat Raoul ne peut choisir que parmi les formations possibles en fonction de la session à laquelle il postule :

Figure12

Mais un ennemi redoutable pour les bases de données est là, à savoir la boucle CANDIDAT > SESSION > PROPOSER > CANDIDAT. Au niveau MCD, l’ennemi est (en principe) défait, c’est bien, mais il faut traduire cette défaite au niveau MLD, et là tout est à refaire, car les AGL ne traduisent pas la contrainte d’inclusion et c’est à nous de construire le mur de défense, dans la soute MLD...

Descendons donc dans la soute et passons au MLD dérivé du MCD par l’AGL. Avant cela, je trouve dommage d’avoir à saisir à nouveau les données propres à un candidat (son nom, son prénom, etc.) dans la mesure où, ayant terminé une formation à l’occasion d’une session Sx, il postule plus tard pour une autre formation proposée avec la session Sy. Je suggère donc que l’entité-type CANDIDAT soit dédoublée en PERSONNE et CANDIDATURE, PERSONNE ne conservant que les données propres à chaque candidat, CANDIDATURE hébergeant les autres : CandidatId et CandidatNumero, c'est-à-dire les données relevant fonctionnellement du système à mettre en place.
Le MCD à dériver en MLD serait donc le suivant (on traitera plus tard des inscriptions proprement dites) :

Figure13

MLD effectivement dérivé par l’AGL :

Figure 14

Je trouve pour ma part plus intéressant de renommer PROPOSER en CATALOGUE et CHOISIR en PRE_INSCRIPTION, mais c’est l’évacuation des ovales des associations et la possibilité d’utiliser des noms plus parlants qui m’incitent à agir ainsi...

Figure 15

Il y a des corrections à apporter, car il y a des contraintes qui auraient dû figurer dans le MCD, mais difficiles, voire impossibles à mettre en oeuvre, alors qu’on pourra y arriver sans difficulté excessive au stade du MLD.

On s’accroche !

Table PRE_INSCRIPTION

En l’état, parmi ses choix, le candidat Raoul peut souhaiter suivre la formation F1 selon le mode M1 mais dans le cadre des sessions S1, S2, etc., ce qui n’est pas légal, puisqu’une candidature est mono-session. Autrement dit, dans un 1er temps, l’attribut SessionId doit être évacué de la clé de la table, clé qui se réduit à {CandidatId, FormationId, ModeFormationId} :

Figure 16

Mais un candidat ne peut postuler que pour une seule session, or à l’occasion d’une préinscription, Raoul a le devoir de choisir plus d’une formation selon un mode de formation, par exemple : {Raoul, F1, M1}, {Raoul, F1, M2}, {Raoul, F2, M2}, etc. Mais à ce stade, on n’a pas mis en place de contrainte quant aux sessions, c’est-à-dire que rien n’empêche que la table PRE_INSCRIPTION puisse contenir les tuples {Raoul, F1, M1, S1}, {Raoul, F1, M2, S2}, {Raoul, F2, M2, S1}, en contradiction avec la règle selon laquelle Raoul peut postuler pour la session S1 ou la session S2, mais pas pour les deux à la fois. Il y a donc une contrainte d’unicité à mettre en place, qu’on appelle en l’occurrence dépendance fonctionnelle (DF) :

{CandidatId} —> {SessionId}

Pour y parvenir sans développer de code (triggers SQL), il va falloir ruser et faire intervenir la table CANDIDATURE où cette dépendance fonctionnelle est respectée. Si l’on sait dire que chaque paire {CandidatId, SessionId} de la table PRE_INSCRIPTION est contrainte à être une paire {CandidatId, SessionId} de la table CANDIDATURE, alors c’est gagné. Mais cela suppose que {CandidatId, SessionId} soit clé (primaire ou alternative) de CANDIDATURE. Alea jacta est! Définissons {CandidatId, SessionId} comme clé alternative de CANDIDATURE (il d’agit en fait d’une surclé) :

Figure 17

Pour l’AGL, les clés de CANDIDATURE sont :

{CandidatId} (clé primaire) ;
{CandidatNumero} (clé alternative (mickey ak1)) ;
{CandidatId, SessionId} (clé alternative, surclé puisqu’incluant la clé primaire (mickey ak2, en rouge)).

Il s’ensuit que dans la table PRE_INSCRIPTION, la paire {CandidatId, SessionId} peut être définie comme clé étrangère par rapport à la clé alternative {CandidatId, SessionId} de la table CANDIDATURE, mais en observant que, de façon parfaitement légitime, l’AGL crée un attribut CAN_SessionId à cet effet : c’est la paire {CandidatId, CAN_SessionId} qui fait référence à la clé {CandidatId, SessionId} de la table CANDIDATURE :

Figure 18

A ce stade, puisque du fait de la clé primaire {CandidatId} de la table CANDIDATURE, la DF {CandidatId} —> {SessionId} y est vérifiée, par héritage (clé étrangère), la DF {CandidatId} —> {CAN_SessionId} est nécessairement vérifiée pour la table PRE_INSCRIPTION. Or, une session est une session, et PRE_INSCRIPTION vérifie l’égalité des singletons {CAN_SessionId} = {SessionId}, en conséquence de quoi ces deux singletons n’en font qu’un, à savoir {CAN_SessionId}, qu’il suffit de renommer en {SessionId}. C’est un peu tordu, mais légal et efficace : Raoul peut toujours se préinscrire pour au moins 5 formations et leurs modes, mais désormais pour une seule session.

Le schéma qui précède devient :

Figure 19

Le MLD devient le suivant :

Figure 20

Notez bien les clés étrangères (contraintes référentielles) de PRE_INSCRIPTION :

— {FormationId, ModeFormationId, SessionId} référençant la clé primaire {FormationId, ModeFormationId, SessionId} de CATALOGUE ;

— {CandidatId, SessionId} référençant la surclé {CandidatId, SessionId} de CANDIDATURE.

Les inscriptions

L’inscription de Raoul concerne une seule formation, un seul mode formation et une seule session. Par ailleurs cette inscription correspond à un choix de préinscription effectué par Raoul, en vertu de quoi le MLD peut être ainsi complété :

Figure 21

L’attribut SessionId n’apparaît pas dans la structure de la table INSCRIPTION. Pour connaître la session à laquelle participe Raoul, il suffit d’effectuer une jointure des tables INSCRIPTION et PRE_INSCRIPTION sur le triplet {CandidatId, FormationId, ModeFormationId}, jointure qui peut être à la base d’une table virtuelle (une vue) ayant pour en-tête le quadruplet {CandidatId, FormationId, ModeFormationId, SessionId}.

Le MCD dont serait dérivé ce MLD précis sans qu’on ait à l’aménager est utopique, car il y a pas mal de contraintes dont un Yves Tabourier viendrait peut-être à bout, mais qui de toute façon ne sont pas dérivables par les AGL.

En tout cas, l’essentiel reste la base de données qui sera en exploitation, et la génération du code SQL de création des tables est réalisée sans aucun problème. Je fournis ce code dans un post un part, pour ne pas surcharger celui-ci, déjà assez copieux...

[fsmrel]

Le script SQL de création des tables (PostgreSQL) :

SET SCHEMA 'fsmrel' ; 

DROP TABLE IF EXISTS INSCRIPTION CASCADE ;
DROP TABLE IF EXISTS PRE_INSCRIPTION CASCADE ;
DROP TABLE IF EXISTS CANDIDATURE CASCADE ;
DROP TABLE IF EXISTS PERSONNE CASCADE ;
DROP TABLE IF EXISTS CATALOGUE CASCADE ;
DROP TABLE IF EXISTS SESSION CASCADE ;
DROP TABLE IF EXISTS AVOIR_MODE CASCADE ;
DROP TABLE IF EXISTS MODE_FORMATION CASCADE ;
DROP TABLE IF EXISTS FORMATION CASCADE ;

CREATE TABLE FORMATION 
(
        FormationId          INT             NOT NULL
      , FormationCode        CHAR(7)         NOT NULL
      , FormationNom         VARCHAR(64)     NOT NULL
    , CONSTRAINT FORMATION_PK PRIMARY KEY (FormationId)
    , CONSTRAINT FORMATION_AK UNIQUE (FormationCode)
) ;

CREATE TABLE MODE_FORMATION 
(
        ModeFormationId      INT             NOT NULL
      , ModeFormationCode    CHAR(2)         NOT NULL
      , ModeFormationNom     VARCHAR(64)     NOT NULL
    , CONSTRAINT MODE_FORMATION_PK PRIMARY KEY (ModeFormationId)
    , CONSTRAINT MODE_FORMATION_AK UNIQUE (ModeFormationCode)
) ;

CREATE TABLE AVOIR_MODE 
(
        FormationId          INT             NOT NULL
      , ModeFormationId      INT             NOT NULL
    , CONSTRAINT AVOIR_MODE_PK PRIMARY KEY (FormationId, ModeFormationId)
    , CONSTRAINT AVOIR_MODE_FORMATION_FK FOREIGN KEY (FormationId)
          REFERENCES FORMATION (FormationId)
    , CONSTRAINT AVOIR_MODE_MODE_FORMATION_FK FOREIGN KEY (ModeFormationId)
          REFERENCES MODE_FORMATION (ModeFormationId)
) ;

CREATE TABLE SESSION 
(
        SessionId            INT             NOT NULL
      , SessionCode          CHAR(7)         NOT NULL
      , SessionAnnee         INT             NOT NULL
      , SessionMois          INT             NOT NULL
    , CONSTRAINT SESSION_PK PRIMARY KEY (SessionId)
    , CONSTRAINT SESSION_CODE_AK UNIQUE (SessionCode)
    , CONSTRAINT SESSION_ANNEE_AK UNIQUE (SessionAnnee)
) ;

CREATE TABLE CATALOGUE 
(
        FormationId          INT             NOT NULL
      , ModeFormationId      INT             NOT NULL
      , SessionId            INT             NOT NULL
    , CONSTRAINT CATALOGUE_PK PRIMARY KEY (FormationId, ModeFormationId, SessionId)
    , CONSTRAINT CATALOGUE_SESSION_FK FOREIGN KEY (SessionId)
          REFERENCES SESSION (SessionId)
    , CONSTRAINT CATALOGUE_AVOIR_MODE_FK FOREIGN KEY (FormationId, ModeFormationId)
          REFERENCES AVOIR_MODE (FormationId, ModeFormationId)
) ;

CREATE TABLE PERSONNE 
(
        PersonneId           INT             NOT NULL
      , PersonneNom          VARCHAR(64)     NOT NULL
      , PersonnePrenom       VARCHAR(64)     NOT NULL
      , Etc                  VARCHAR(64)     NOT NULL
    , CONSTRAINT PERSONNE_PK PRIMARY KEY (PersonneId)
) ;

CREATE TABLE CANDIDATURE 
(
        CandidatId           INT             NOT NULL
      , SessionId            INT             NOT NULL
      , PersonneId           INT             NOT NULL
      , CandidatNumero       INT             NOT NULL
    , CONSTRAINT CANDIDATURE_PK PRIMARY KEY (CandidatId)
    , CONSTRAINT CANDIDATURE_NUMERO_AK UNIQUE (CandidatNumero)
    , CONSTRAINT CANDIDATURE_SESSION_AK UNIQUE (CandidatId, SessionId)
    , CONSTRAINT CANDIDATURE_SESSION_FK FOREIGN KEY (SessionId)
          REFERENCES SESSION (SessionId)
    , CONSTRAINT CANDIDATURE_PERSONNE_FK FOREIGN KEY (PersonneId)
          REFERENCES PERSONNE (PersonneId)
) ;

CREATE TABLE PRE_INSCRIPTION 
(
        CandidatId           INT             NOT NULL
      , FormationId          INT             NOT NULL
      , ModeFormationId      INT             NOT NULL
      , SessionId            INT             NOT NULL
    , CONSTRAINT PRE_INSCRIPTION_PK PRIMARY KEY (CandidatId, FormationId, ModeFormationId)
    , CONSTRAINT PRE_INSCRIPTION_CATALOGUE_FK FOREIGN KEY (FormationId, ModeFormationId, SessionId)
          REFERENCES CATALOGUE (FormationId, ModeFormationId, SessionId)
    , CONSTRAINT PRE_INSCRIPTION_CANDIDATURE_FK FOREIGN KEY (CandidatId, SessionId)
          REFERENCES CANDIDATURE (CandidatId, SessionId)
) ;

CREATE TABLE INSCRIPTION 
(
        CandidatId           INT             NOT NULL
      , FormationId          INT             NOT NULL
      , ModeFormationId      INT             NOT NULL
    , CONSTRAINT INSCRIPTION_PK PRIMARY KEY (CandidatId)
    , CONSTRAINT INSCRIPTION_PRE_INSCRIPTION_FK FOREIGN KEY (CandidatId, FormationId, ModeFormationId)
          REFERENCES PRE_INSCRIPTION (CandidatId, FormationId, ModeFormationId)
) ;

En passant, quel SGBD utilisez-vous ?

[avehri]

Bonjour fmsrel

Chapeau bas, Merci beaucoup, pas seulement pour m'avoir conçu le MCD, mais surtout pour m'avoir données une autre vision du monde réel, une autre façon de voir la conception des bases de données.

Un vrai cours de professionnel qu'on ne trouve pas dans les livres qu'on paie parfois chère.

Vous citez souvent dans vous interventions Yves Tabourier , ça ma donné envie de consulter ses ouvrages mais je ne les trouve pas.

Remarque concernant les contraintes d'inclusion dans MCD en rouge (figure 8, figure 10, figure 12, figure 13) l'orientation de la flèche n'est-t-elle pas dans le sens contraire ? a titre d'exemple dans la figure 13 la formation pour laquelle postule un candidat est inclue dans les formation choisies au préalable. A mon avis l'orientation de la flèche de de POSTULER vers CHOISIR.

au passage j'utilise SQL Server. Le script marche parfaitement

Mille merci pour tous ces conseils sur lesquels je me baserai dorénavant pour bien percevoir le monde réel.

Je suis un peu débordé ces jours-ci mais Je posterai le MCD final une fois terminé, parce que il manque encore beaucoup de détaille à rajouter et à gérer que j'ai voulu donnée au début pour se concentrer à l'essentiel.

[fsmrel]

Bonsoir avehri,


Merci pour le compliment, ça fait toujours plaisir de savoir qu’on a pu aider efficacement et faire progresser celui qui en veut, sur un sujet pas toujours évident.

A propos de l’orientation des contraintes d'inclusion, j’ai supposé que POSTULER précédait fonctionnellement CHOISIR, mais si en réalité c’est l’inverse, alors faisons pivoter les flèches de 180°...

Concernant Yves Tabourier, on trouve encore son ouvrage De l'autre côté de Merise via Amazon, Abebooks, etc. à partir de son titre ou au moyen de son ISBN (2708107623).

J’ai aussi récupéré son article de 1990, édité par la défunte Afcet et portant sur l’extension des contraintes, vous pourrez constater qu’il maîtrise le sujet mieux que quiconque.

J’ai aussi récupéré un glossaire que l’on doit encore aux membres de l’Afcet.

Vous avez par ailleurs la possibilité de décerner des satisfecits...

Bon courage pour la suite !