Discussion :

[nogaro]

Bonjour à tous,

Voila deux MCD qui ni l'un ni l'autre ne me conviennent reellement. Pourtant chaque amelioration apportée par mes soins ne fait que rendre le modèle moins satisfaisant.

Il s'agit de gerer les stages des etudiants inscrits dans une ecole ou ils restent pendant 5 ans. Cahque etudiant va faire plusieurs stages lors de son cursus.

Les sujets de stages sont proposes par des entreprises, et seuls certains sujets sont retenus et font l'objet d'un stage reel, qui fait l'objet d'une signature de convention (par le directeur de l'entreprise et le responsable d'annee de l'ecole) et d'un encadrement et notation de la part d'un maitre de stage dans l'entreprise et d'un referent dans l'ecole.

Au tout debut je souhaitais separer sujets de stage et stages...mais cela ne m'a pas semble possible car cela cree de la redondance. Je suis donc arrive a ce premier schema (piece appelée SIMPLE). Il me semble juste mais pas tres logique...puisque pour les stages n'ayant pas ete choisis tout un lot de proprietes ne seront pas remplies (notes, date signature etc...).

Je trouvais plus logique que la note soit attribuée a l'etudiant et non pas a l'entité stage...mais comme les etudiants font plusieurs stages....cette note depend ET de l'etudiant ET du stage... on arrive alors a ce schema (piece jointe appelée complexe) peut-etre plus logique mais pas plus juste que le premier qui est quand meme plus simple...

Si l'un d'entre vous a un avis a ce sujet... je lui serais tres reconnaissant de le faire partager. Peut-etre y a t-il un moyen de separer Sujets et Stages....

Merci mille fois,

[JPhi33]

Bonjour,

Au tout debut je souhaitais separer sujets de stage et stages...mais cela ne m'a pas semble possible car cela cree de la redondance. Je suis donc arrive a ce premier schema (piece appelée SIMPLE). Il me semble juste mais pas tres logique...puisque pour les stages n'ayant pas ete choisis tout un lot de proprietes ne seront pas remplies (notes, date signature etc...).

Une solution consiste à séparer les sujets (disons, les offres) de stage et les stages effectivement réalisés par les étudiants :

[ STAGE ]--1,1----( )----0,1->[ OFFRE ]

Dans ce nouveau vocabulaire, un stage est donc obligatoirement réalisé par un étudiant :

[ ETUDIANT ]<-0,n----( Réaliser )----1,1--[ STAGE ]

Cette modélisation a l'avantage de permettre de séparer les données relatives aux offres : sujet, date offre, trouvé par, indemnités, etc., de celles purement liées à la réalisation effective du stage par un étudiant : note rapport, note oral, date signature convention, etc.

Du coup, ça résout ce problème :

Je trouvais plus logique que la note soit attribuée a l'etudiant et non pas a l'entité stage...mais comme les etudiants font plusieurs stages....cette note depend ET de l'etudiant ET du stage...

Autre point : Sauf si les offres bénéficient d'une identification pré-établie dans le monde réel, il serait intéressant de les identifier relativement aux entreprises (cardinalités 1,1 entre parenthèses selon la notation PowerAMC) :

[ OFFRE ]-(1,1)---( Proposer )----0,n->[ ENTREPRISE ]

Une offre est alors identifiée par le couple {code_entreprise, no_offre}. Ainsi, si les entreprises E1 et E2 proposent chacune 3 offres 1, 2 et 3, les identifiants de ces offres sont :
E1, 1
E1, 2
E1, 3
E2, 1
E2, 2
E2, 3


Dernier point : Il y a beaucoup d'acteurs mis en jeu dans ce MCD : maître de stage, référent, étudiant, responsable année, signataire. Il serait intéressant de factoriser leurs propriétés commune (nom, prénom, etc.) dans une entité générale, disons Personne. Les entités de type acteur (citées ci-dessus) seraient alors des spécialisations de Personne. Les propriétés communes n'auraient à être définies qu'une seule fois : dans Personne.

[fsmrel]

Bonsoir,

Caveat : j’ai rédigé mon message avant que JPhi33 ne transmette le sien, donc je tiens compte ci-dessous de ses remarques.

Nogaro, laissons tomber votre deuxième MCD.

Le cœur de l’affaire est l’entité-type STAGE. D’une part un stage S1 peut être simplement à l’état de proposition, auquel cas il n’y a pas d’étudiant qui y soit associé, et d’autre part un étudiant est en train d’effectuer (ou a effectué) un stage S2 qui n’est donc plus à l’état de proposition.
Conclusion, il est nettement préférable de décomposer cette entité-type en STAGE_PROPOSE (stage proposé) et STAGE (sous-entendu effectué) :

[ETUDIANT]---0,N---(Effectuer)---1,1---[STAGE]---1,1---(Concretiser)---0,1---[STAGE_PROPOSE]---1,1---(Proposer)---0,N---[ENTREPRISE]

La proposition de JPhi33 améliore encore les choses en transformant STAGE_PROPOSE (que je renomme OFFRE pour être en phase avec lui) en entité-type faible, donc en l’identifiant relativement à ENTREPRISE :

[ETUDIANT]---0,N---(Effectuer)---1,1---[STAGE]---1,1---(Concretiser)---0,1---[OFFRE]---(1,1)---(Proposer)---0,N--->[ENTREPRISE]

Autant le fait qu’un stage proposé n’ait pas encore trouvé preneur ne me dérange pas (cardinalité 0,1 pour la patte connectant STAGE et OFFRE), bien au contraire, autant le fait qu’un stage qui a trouvé preneur (en la personne d’un étudiant) ne soit pas mis en évidence me gêne (d’où la cardinalité 1,1 que j’ai utilisée pour la patte connectant STAGE et ETUDIANT) : appelons un chat un chat, là encore je rejoins JPhi33.

La cardinalité 0,1 portée par la patte connectant STAGE et SIGNER CONVENTION me gêne à son tour, car pour qu'un stage puisse être effectué par un étudiant, cela implique que la convention a déjà été signée (du moins je l’espère). Votre association-type SIGNER CONVENTION devrait donc elle aussi être décomposée en deux associations-types, une impliquant un collaborateur de l’entreprise (signataire de la convention), avec remplacement de la cardinalité 0,1 par deux cardinalités 1,1 :

[STAGE]---1,1---(Signer convention)---0,N---[COLLABORATEUR]

Et l’autre le responsable de l’année :

[STAGE]---1,1---(Signer convention)---0,N---[RESPONSABLE_ANNEE]

Par ailleurs, le fait que SIGNER CONVENTION soit une relation ternaire n’apporte rien par rapport au deux binaires que je propose. En effet, une convention est signée d’une part par un collaborateur de l’entreprise, d’autre part par un responsable d’année : la ternaire n’est jamais que la jointure des deux binaires.

Même principe concernant le suivi du stage :

[STAGE]---1,1---(Encadrer)---0,N---[COLLABORATEUR]

[STAGE]---1,1---(Suivre)---0,N---[REFERENT]

Celui qui encadre (c'est-à-dire le maître de stage) et le signataire représentant l’entreprise doivent être des collaborateurs de celle-ci :

[ENTREPRISE]---1,N---(Faire partie)---1,1---[ COLLABORATEUR]

Concernant la notation des stages : si un stage est en cours, les attributs tels que NoteRapport et NoteStage ne prennent aucune valeur, ils doivent donc faire l’objet d’une entité-type "appendice" NOTATION faisant référence à STAGE. Une notation fait exactement référence à un stage et un stage est parfois référence par une notation :

[NOTATION]---(1,1)---(Faire l’objet)---0,1---[STAGE]

Voici un 1er jet de MLD (réalisé avec MySQL Workbench (gratuit)) dérivé du MCD :


La clé primaire d’une table est repérée par un mickey, une petite clé jaune à gauche du nom des attributs appartenant à cette clé (cas par exemple de l'attribut EntrepriseId de la table ENTREPRISE).

Une clé étrangère est repérée soit par les petites clés jaunes si cette clé est aussi clé primaire (cas par exemple de l’attribut EntrepriseId de la table OFFRE), soit par un losange rougeâtre si cette clé étrangère n’est pas en même temps clé primaire (cas par exemple de l’attribut EtudiantId de la table STAGE.

Les attributs qui ne participent à aucune clé, qu’elle soit primaire et/ou étrangère sont repérés par des losanges bleuâtres (évidés quand ils peuvent être marqués NULL (ce qui n’est pas le cas ici)).

La lecture des cardinalités ne pose pas de problème, même si le symbolisme n’est pas celui de Merise : un étudiant effectue (ou a effectué) de 0 à N stages et un stage est (ou a été) effectué par exactement un étudiant, etc.
Vous noterez qu’avec ce MLD, un collaborateur d’une entreprise ne peut pas encadrer un stage faisant référence à une entreprise qui n’est pas la sienne. Même principe concernant la signature des conventions.

Maintenant, comme dit JPhi33, il y a un nombre élevé d’acteurs et la mise en œuvre d’une entité-type PERSONNE s’impose, afin de factoriser leurs propriétés communes.

Une esquisse (MLD) :



Workbench ne semble pas gérer les clés alternatives sinon à coup d’index (c'est-à-dire au niveau de la plomberie). Sinon, la table COLLABORATEUR possède deux clés candidates. Même chose vraisemblablement pour les tables ETUDIANT, REFERENT et RESPONSABLE_ANNEE.