Version imprimable
Bonjour,
J'ai un problème, je suis actuellement bloqué pour la gestion de durer du stage (la période sur laquelle il se déroule).
Pour moi, le stage dépend autant de l'élève que de la période, c'est donc pour ca que j'ai mis un CIF, mais je ne suis pas sûr de moi.
J'ai donc essayer une autre façon, mais les deux ne me semble pas concluante.
Serait-il possible d'avoir des conseilles.
Merci d'avance.
Bonjour,
1) Qu'est-ce qui justifie d'avoir la période en dehors de l'entité-type stage ?
2) Quelle est la signification de l'association "appartient" ?
3) Nommer votre entité-type Eleves au singulier : Eleve, tout comme vous avez employé le singulier pour les autres entités-types.
4) Il y a un problème de boucle côté tuteur : Un tuteur de l'entreprise A peut superviser un stage qui se déroule dans l'entreprise B
5) Au passage, plutôt que "Effectuer", nommez plutôt l'association entre Entreprise et Stage "Se dérouler" ou "Avoir lieu" ou "Situer"...
6) Attention aux types de vos données !
- idEleve : Auto-increment
- dateDebutStage et dateFinStage : Date ou Datetime
7) Si tous vos stages commencent le lundi, inutile de prévoir une propriété pour l'heure de début le lundi. Il suffit d'avoir une propriété de type datetime pour dateDebutStage.
8) Dans votre premier schéma, un stage est effectué par un seul élève durant une seule période.
Dans le second, un stage peut être effectué par plusieurs élèves sur plusieurs périodes. :aie:
1°) Si ma période et en dehors de l’entité-type stage, c'est parce que la période ou les périodes sont dépendantes des classes. (Certaines classes ont seulement un seul stage, d'autres plusieurs et chacun a des périodes différentes.
2°) L’entité "période" fait en fait référence a une classe avec comme clé primaire le libeller de la classe. J'utilise le libelle de la classe en clé primaire puisque lors de l'import des élèves, ils ont déjà un champ avec le libelle de leur classe.
3°) Ah oui merci, je n'avais pas fait attention. :ptdr:
4°) En effet, mais alors comment gérer ce problème ?
6°) idEleve est actuellement Varchar ce qui est normale du fait que l'entité élèves et remplie par le biais d'un fichier CSV ou les ID sont déjà donné
7°) L'entité n’est pas complète, je vous ai remis l'entité complète en dessous. Cette entité a pour but de stocker les horaires de chaque stage(matin et après-midi de chacun des jours au cas où il aurait des horaires variant en fonction des jours). Cette façon de gérer les horaires de stage me parais assez "barbare" mais je ne vois pas d'alternative.
8°) J'ai oublié de modifier les cardinalités.
Voilà une version modifiée, mais je ne comprends pas comment relier l'entité stage avec l'entité élève et classe pour faire en sorte qu'un élève puisse avoir plusieurs stages, mais un et un seul sur une même période ( périodes de stage étant défini par ca classe).
Les classes ne sont pas modélisées ! :weird:Citation:
1°) Si ma période et en dehors de l’entité-type stage, c'est parce que la période ou les périodes sont dépendantes des classes. (Certaines classes ont seulement un seul stage, d'autres plusieurs et chacun a des périodes différentes.
Si je comprends bien, vous avez les règles de gestion suivantes :
R1 : Une classe peut avoir plusieurs périodes de stage et une période de stage appartient à une seule classe.
R2 : Un stage se déroule durant une période de stage et une période de stage peut voir se dérouler plusieurs stages.
R3 : Un élève est inscrit dans une seule classe et une classe peut inscrire plusieurs élèves.
R4 : Un élève peut effectuer un stage et un stage est effectué par un élève.
MCD :
Eleve -1,1----inscrire----0,n- Classe -0,n----avoir----1,1- Periode_stage -0,n----se_dérouler----1,1- Stage
|
------------------------------------------0,1--------effectuer---------1,1---------------------------------------------------------|
Il manque sur mon schéma une CIF (difficile à représenter en format texte) pour que le stage qu'effectue l'élève soit bien sur l'une des périodes de stage de sa classe.
1) Sauf que vous venez d'écrire qu'une classe peut avoir plusieurs périodes de stage. Donc la classe et la période sont bel et bien deux entités-types différentes, quoique la période dépende de la classe. On peut alors utiliser l'identification relative (cardinalités entre parenthèses) :Citation:
2°) L’entité "période" fait en fait référence a une classe avec comme clé primaire le libeller de la classe. J'utilise le libelle de la classe en clé primaire puisque lors de l'import des élèves, ils ont déjà un champ avec le libelle de leur classe.
Eleve -1,1----inscrire----0,n- Classe -0,n----avoir----(1,1)- Periode_stage -0,n----se_dérouler----1,1- Stage
|
------------------------------------------0,1--------effectuer---------1,1------------------------------------------------------------|
2) Un libellé comme clé primaire, c'est un mauvais choix ! Il vaut mieux avoir une clé auto-incrémentée.
Par une CIF !Citation:
4°) En effet, mais alors comment gérer ce problème ?Citation:
Envoyé par CinePhil
Alors ajoutez un identifiant auto-incrémenté. Pour une raison ou une autre, un identifiant externe peut changer ; ce n'est donc pas une bonne clé primaire. À plus forte raison si c'est une clé en texte. Voir article référencé ci-dessus.Citation:
6°) idEleve est actuellement Varchar ce qui est normale du fait que l'entité élèves et remplie par le biais d'un fichier CSV ou les ID sont déjà donné
Il semble donc que tous les stages ne durent qu'une semaine.Citation:
7°) L'entité n’est pas complète, je vous ai remis l'entité complète en dessous. Cette entité a pour but de stocker les horaires de chaque stage(matin et après-midi de chacun des jours au cas où il aurait des horaires variant en fonction des jours). Cette façon de gérer les horaires de stage me parais assez "barbare" mais je ne vois pas d'alternative.
Plutôt que de stocker les horaires de chaque jour... qui seront souvent identiques, il vaut mieux enregistrer dans le stage les horaires normaux et dans une table à part les éventuels horaires spéciaux.
Règle de gestion :
R5 : Un stage peut appliquer des horaires spéciaux et un horaire spécial s'applique à un seul stage.
MCD :
Stage -0,n----appliquer----(1,1)- Horaire_special
Tables :
Stage (stg_id, stg_id_classe, stg_numero_periode, stg_id_entreprise, stg_id_eleve, stg_horaire_matin, stg_horaire_apres_midi...)
Horaire_special (hsp_id_stage, hsp_numero, hsp_jour_semaine, hsp_periode_journee, hsp_horaire)
1°) Vos règles de gestion sont bonne ci ce n'est qu'un élève peu faire plusieurs stages. (Par exemple si dans son année scolaire 2 période de stage sont prévu)
Non un stage peu duré plusieurs semaines, mais la durée du stage et donné par l'entité période l'entité stage me sert a référencer les horaires de début et de fin de journee (Un stagiaire peu faire 8h-11h30/13h30-17h30 le lundi et 8h-12h/14h-18h le mardi ainsi de suite. C'est donc pour cette raison que j'ai choisie de mettre une multitude de champs.
Je ne suis pas sur de la clarté de mon explication. :?
J'ai donc changez mon MCD au vu de vos conseils qu'en pensez vous ?
OK. Vous en avez tenu compte.Citation:
1°) Vos règles de gestion sont bonne ci ce n'est qu'un élève peu faire plusieurs stages. (Par exemple si dans son année scolaire 2 période de stage sont prévu)
N'est-il pas alors possible que les horaires soient différents d'une semaine à l'autre ?Citation:
Non un stage peu duré plusieurs semaines
Est-ce que tous les stages se font obligatoirement durant toute la période de stage de la classe ?Citation:
mais la durée du stage et donné par l'entité période
Autrement dit, si une classe a prévu une période de stage du 5 au 21 octobre, est-ce que tous les stages vont réellement se dérouler du 5 au 21 octobre ? À titre d'exemple vécu, mon fils a décalé le début de son stage de fin de DUT parce qu'il n'avait pas encore trouvé d'entreprise d'accueil et il a commencé sa période de stage à l'IUT.
Est-ce indispensable de détailler à ce point, avec des colonnes de type TIME pour chaque début et fin de demie-journée ?Citation:
l'entité stage me sert a référencer les horaires de début et de fin de journee
Est-ce que ce ne serait pas suffisant dans une colonne de type VARCHAR ou TEXT, tel que vous le décrivez : "8h-11h30/13h30-17h30 le lundi et 8h-12h/14h-18h le mardi..." ?
À moins que vous ne vouliez faire des calculs de nombre d'heures de stage prévues ?
Mais je trouve que ça reste lourd. En plus, vous avez prévu des horaires pour le samedi... vos stagiaires travaillent-ils tous 6 jours par semaine ?
1) L'association correspondre n'a pas lieu d'être. C'est la CIF qui doit assurer la cohérence entre la période du stage et celle de la classe de l'élève.Citation:
J'ai donc changez mon MCD au vu de vos conseils qu'en pensez vous ?
Idem pour l'association Composer.
2) N'y a t-il pas d'autres informations relatives au stage à enregistrer ?
- Référence de la convention ;
- Sujet du stage...
3) Il faut externaliser la ville de l'entreprise et, peut-être, sa spécialité.
4) Pourquoi donner un numéro au tuteur en plus de son identifiant ?
Sont-ce des tuteurs qualifiés avec un numéro d'agrément ?
À moins qu'il s'agisse du numéro de téléphone ? Auquel cas il vaut mieux appeler ça "telephoneTuteur".
Non puisque que dans le cadre d'un stage, les horaires sont fixes par des conventions.Citation:
Envoyé par CinePhil
J'ai donc ajouté l'entité "RetardStage" avec les nouvelles dates dû au retard ainsi qu'un "bool" permettant l'utilisation ou non de la fonction retard.Citation:
Envoyé par CinePhil
Je vais réfléchir a ca, mais il est vrai que je n'ai pas de traitement particulier sur les horaires, il me serait donc possible d'utiliser des types varchar.
Citation:
Envoyé par CinePhil
Non mais dans le cas où il ne travaillerait pas le lundi par exemple.
Citation:
Envoyé par CinePhil
Mais un CIF doit forcement être lier à une association comme ceci : https://merise.developpez.com/faq/images/CIF_3.gif
Je n'en n'est pas forcement le besoin.Citation:
2) N'y a t-il pas d'autres informations relatives au stage à enregistrer ?
- Référence de la convention ;
- Sujet du stage...
Je ne comprends pas vraiment pour quelle raison, car lors de l'entre des villes par les utilisateurs, il est possible qu'un même ville sois entre sous plusieurs noms (Les villes avec "Saint..." ou "St..." par exemple) ceci entraînerais des doublons non ?Citation:
3) Il faut externaliser la ville de l'entreprise et, peut-être, sa spécialité.
Dans l'exemple que vous donnez en référence, l'association "compose" est pertinente car elle décrit bien le fait qu'un candidat compose dans une salle pour une matière.Citation:
Mais un CIF doit forcement être lier à une association comme ceci : https://merise.developpez.com/faq/images/CIF_3.gif
Comme indiqué dans la FAQ d'où est extraite cette image, la CIF indique ceci : "- pour une Matière, un Candidat ne compose que dans une Salle (CIF) ".
En effet, sans la CIF, en raison des cardinalités de l'association ternaire, un candidat pourrait composer plusieurs fois pour la même matière dans plusieurs salles ! :aie:
La CIF, telle que dessinée avec une flèche vers SALLE, indique que le couple {CANDIDAT, MATIERE} ne peut être associé qu'une seule fois à une salle.
Regardez aussi les exemples de CIF suivants :
- typage des adresses d'une entreprise ou d'un interlocuteur ;
- fonctions des personnalités dans un film.
Dans votre cas, on pourrait éventuellement établir le MCD suivant :
PeriodeStage -0,n----effectuer----1,1- Stage
Eleve -0,n---------------------|
Mais une association ternaire avec une patte portant des cardinalités 1,1 est sujette à discussion... :weird:
Et je pense qu'il faudrait quand même une CIF (pas facile à représenter en texte) portant sur l'association effectuer (trait pointillé) et qui exprime que c'est le couple {Eleve, Classe} (traits pleins) qui déterminent la PeriodeStage (flèche).
L'association "Effectuer" de votre MCD serait transformée en ternaire et supprimerait l'association "Se passe".
Au niveau des tables...
Classe (idClasse, libClasse)
Eleve (idEleve, idClasse, nomEleve, prenomEleve, dateNaisEleve)
PeriodeStage (idClasse, numPeriode, dateDebutPeriode, dateFinPeriode)
Stage (idStage...)
EleveEffectuerStage (idEleve, idPeriodeStage, idStage) ==> + contrainte d'unicité sur idStage
C'est justement pour ça qu'il faut externaliser la ville ! :mrgreen:Citation:
Je ne comprends pas vraiment pour quelle raison, car lors de l'entre des villes par les utilisateurs, il est possible qu'un même ville sois entre sous plusieurs noms (Les villes avec "Saint..." ou "St..." par exemple) ceci entraînerais des doublons non ?Citation:
Envoyé par CinéPhil
Elle ne sera écrite qu'une seule fois et avec la bonne orthographe dans la table des villes et son identifiant figurera autant de fois que nécessaire en tant que clé étrangère dans la table des entreprises.
L'interface utilisateur proposera la liste des villes de la table des villes et il n'aura qu'à la choisir au lieu de l'écrire, potentiellement mal orthographiée.
D'accord mais dans mon cas actuel un stage appartient bien à un et un seul couple {élève/période} tous comme un stage a un et un seul coulpe {tuteur/entreprise} donc la cardinalité 1,1Citation:
Envoyé par CinePhil
J'ai essaye de un peu modifier mon MCD mais je n'es pas du tout comprit ou vous vouliez en venir :?:?Citation:
Et je pense qu'il faudrait quand même une CIF (pas facile à représenter en texte) portant sur l'association effectuer (trait pointillé) et qui exprime que c'est le couple {Eleve, Classe} (traits pleins) qui déterminent la PeriodeStage (flèche).
L'association "Effectuer" de votre MCD serait transformée en ternaire et supprimerait l'association "Se passe".
Au niveau des tables...
Classe (idClasse, libClasse)
Eleve (idEleve, idClasse, nomEleve, prenomEleve, dateNaisEleve)
PeriodeStage (idClasse, numPeriode, dateDebutPeriode, dateFinPeriode)
Stage (idStage...)
EleveEffectuerStage (idEleve, idPeriodeStage, idStage) ==> + contrainte d'unicité sur idStage
Cette solution m'oblige donc a rentre toutes les villes possible et imaginable car impossible de laisser l'utilisateur remplir cette table "Ville".Citation:
C'est justement pour ça qu'il faut externaliser la ville ! :mrgreen:
Elle ne sera écrite qu'une seule fois et avec la bonne orthographe dans la table des villes et son identifiant figurera autant de fois que nécessaire en tant que clé étrangère dans la table des entreprises.
L'interface utilisateur proposera la liste des villes de la table des villes et il n'aura qu'à la choisir au lieu de l'écrire, potentiellement mal orthographiée.
Merci pour votre aide.
Vous pouvez trouver le référentiel des villes française sur le site de l'INSEE et des scripts ou fichiers tout faits.Citation:
Cette solution m'oblige donc a rentre toutes les villes possible et imaginable car impossible de laisser l'utilisateur remplir cette table "Ville".
Il existe aussi quelque part un référentiel mondial, si votre besoin est aussi grand. Pour ma part, dans l'application que je développe actuellement, j'ai une table des villes qui contient déjà toutes les villes françaises et quelques villes étrangères. L'utilisateur choisit d'abord le pays puis commence à taper le nom de la ville. Un script Ajax lui propose alors les villes du pays qui commencent par ces lettres, en indiquant le département si c'est une ville française (parce que plusieurs villes portent le même nom). Si la ville (étrangère) n'existe pas encore en BDD, elle sera enregistrée à partir de la saisie effectuée.
Cette fois, ça me semble pas mal. :)Citation:
J'ai essaye de un peu modifier mon MCD
Quelques détails, cependant, parfois déjà évoqués plus haut :
1) Nom de l'entité-type à mettre au singulier : Eleve
2) Dates de début et fin de période de stage à mettre au type DATE ou DATETIME.
3) Réfléchir à la pertinence d'avoir toutes ces colonnes de type TIME dans Stage.
4) Externaliser la ville de l'entreprise.
5) Idem pour la spécialité.
6) Qu'est-ce que le "numeroTuteur" ?
Je vais régler les derniers petits points.
Merci beaucoup pour votre aide. :merci::merci:
Bonsoir,
L'entité-type stage, telle que modélisée, implique que tous les stages sont concernés par des horaires sur chaque demi-journée de la semaine, est-ce bien le cas ? sera-ce toujours le cas dans le futur ?
Dans la négative, ou en cas de doute, il est préférable de modéliser comme suit
STAGE (ST_id, ST_lib, ...) 1,n --- posseder 1,1 --- 0,n PERIODE (PE_id, PE_joursem, PE_debut, PE_fin...)
Sinon pour un stage qui par exemple ne se déroule que sur les 3 premiers jours de la semaine, ou qui n'est concerné que par les matins... vous avez toute une série d'attributs de la table stage qui sont inutiles
Le Varchar n'a d'intérêt que quand la longueur effective de l'attribut varie de façon significative selon les différentes occurrence ce cet attribut. Ce n'est probablement pas le cas du numéro d'élève, préférez du char si vous avez besoin de maitriser la valeur de ce numéro, ou supprimez simplement cet attribut et utilisez l'identifiant primaire si la valeur n'a aucune importance fonctionnelle pour vous.
Dans PERIODESTAGE, remplacez les types varchar par des dates ou timestamp selon le besoin : une valeur temporelle doit toujours être stockée dans un attribut de type temporel
Merci pour cette remarque j'ai donc modifier ça :)