Discussion :

[Finol]

Bonjour tout le monde,

voilà mon soucis : dans la gestion de la scolarité d'une école, j'ai les règles de gestion suivantes :

- Une classe peut suivre plusieurs matières;
- Une classe peut avoir plusieurs enseignants;
- Une matière peut être enseignée au profit de plusieurs classes;
- Une matière peut être enseignée par plusieurs enseignants;
- Un enseignant peut enseigner plusieurs classes;
- Un enseignant peut enseigner plusieurs matières;
- Une classe doit avoir Un seul enseignant pour Une matière donnée.

Donc j'ai pensé à une association ternaire, toutefois cette dernière ne va pas respecter la dernière règle de gestion. En plus, dans une association ternaire on ne peut pas mettre des cardinalités minimales (1-1).

Voyez vous comment on peut modéliser cette histoire?

Merci à vous !

[escartefigue]

Bonjour,

Les cardinalités maxi sont bien indiquées, mais il manque les cardinalités mini qui ont leur importance.

Certaines semblent évidentes, mais il vaut mieux les écrire quand même, par exemple on peut supposer que : "une classe suit au moins une matière"
D'autres le sont moins : une matière est enseignée au moins par un enseignant ou pas ?
Si au moins un, ça signifie qu'on ne connait une matière qu'à partir du moment où elle est enseignée, ce qui n'est pas neutre.

Une fois les cardinalités complétées, vous pourrez éventuellement appliquer la règle suivante :

Si une association ternaire présente une cardinalité 1:1, lors du passage du MCD au MLD, les identifiants sont portés par la table coté 1:1.

[escartefigue]

Pour les cardinalités mini, j'ai supposé que
- un enseignant peut être enregistré comme étant compétant pour 1 à n matières, mais sans forcément exercer
- une classe suit à minima une matière
- une classe a au moins un enseignant
- une matière n'est pas obligatoirement enseignée (plus au programme ou pas encore au programme)

On peut donc proposer le schema suivant avec une association ternaire, dans laquelle la contrainte "Une classe doit avoir Un seul enseignant pour Une matière donnée" est symbolisée par la flèche vers l'entité-type enseignant

[Finol]

Bonjour, merci pour votre réponse.

Pour ce qui est du schéma que vous me proposiez, je suis complètement d'accord avec vous.

Je vous demande juste l'explication de la flèche; est ce que ça veut dire que le couple Id_Classe et Id_Matière va migrer comme clé étrangère dans l'entité Enseignant;
et si oui, comment puis-je schématiser ce cas dans Power Amc, pour que ce couple doit migrer dans l'entité Enseignant lors de la génération du MPD.

Merci d'avance et bien cordialement!

[escartefigue]

Je vous demande juste l'explication de la flèche; est ce que ça veut dire que le couple Id_Classe et Id_Matière va migrer comme clé étrangère dans l'entité Enseignant

Non, ce serait contradictoire avec

- Un enseignant peut enseigner plusieurs classes;
- Un enseignant peut enseigner plusieurs matières;

[fsmrel]

Bonsoir,


Ce qu’escartefigue a représenté, fort justement, est une CIF (contrainte d’intégrité fonctionnelle), contrainte selon laquelle pour une classe et une matière donnée il ne peut y avoir qu’un enseignant.


Étrangement, PowerAMC ne nous donne pas les moyens de représenter des CIF dans un MCD, on doit donc agir au niveau MLD, et retirer manuellement l’attribut EnseignantId de la clé primaire de la table ENSEIGNER.


MCD sans CIF :





MLD dérivé (MPD selon PowerAMC) :





MLD corrigé à la main (EnseignantId ne participe plus à la clé de la table ENSEIGNER) :





Sinon, pour éviter d’intervenir manuellement, on peut agir au niveau MCD, en déguisant ENSEIGNER en entité-type et en utilisant l’identification relative (simulant la relation de composition d’UML). L’entité-type ENSEIGNER est identifiée relativement aux entités-types CLASSE et MATIERE, en vertu de quoi, la dérivation en MLD fera que la clé de la table ENSEIGNER sera la paire {ClasseId, MatiereId}, et l’on obtiendra à nouveau le MLD (corrigé) ci-dessus. Avec PowerAMC, l’identification relative dans les MCD est symbolisée par la mise entre parenthèses des cardinalités 1,1 :

[Finol]

Bonsoir tout le monde.
Je vous remercie bien pour vos réponses et vos éclaircissements.
Je pense que je vais opter pour la modification manuelle sur mon MLD.
Bien cordialement.

[fsmrel]

Bonsoir Finol,

Je pense que je vais opter pour la modification manuelle sur mon MLD.

Voilà qui paraît raisonnable.

Bonne route !

[Finol]

Bonjour tout le monde ,
Je voudrais partager avec vous mon MCD, et en discuter s'il y a des erreurs, des corrections ou des améliorations que vous me proposiez.
Voilà un cas de conception de la mise en oeuvre d'un emploi du temps au niveau d'une école. Les règles de gestion sont :
Le premier jour du début des cours (date de la rentrée scolaire) est défini en tant que paramètre à renseigner ;
- Une séance appartient à un ou plusieurs jours, et un jour peut contenir une ou plusieurs séances;
- Une pause peut appartenir à plusieurs jours, et un jour peut contenir plusieurs pauses ;
- Un jour appartient à une ou plusieurs semaines, et une semaine contient un ou plusieurs jours*;
- Une semaine appartient à un ou plusieurs mois, et un mois contient une ou plusieurs semaines ;
- Une semaine appartient à plusieurs séquences, et une séquence contient plusieurs semaines ;
- Un mois appartient à une ou plusieurs années scolaires, et une année scolaire contient un ou plusieurs mois ;
Un jour férié est défini par une date, peut être "Permanent" ou "Ponctuel" :
· Permanent : fixé quelque soit l'année scolaire ;
· Ponctuel : dépend de l'année scolaire.
- Un jour férié appartient à une et une seule année scolaire, et une année scolaire peut avoir plusieurs jours fériés ;
- Une année scolaire peut avoir plusieurs vacances (définit par la date du début et la date de la fin des vacances), et une vacance appartient à une seule année scolaire ;

Ce que j'ai pu sortir avec PowerAmc est :

[escartefigue]

Bonjour,

Votre exposé requiert un peu d'explication de texte, des définitions : que sont fonctionnellement les pauses, les séances et les séquences, que représentent ces 3 entités d'un point de vue métier ?
Les autres entités-types semblent plus faciles à appréhender, mais n'hésitez pas à les clarifier aussi, des erreurs d'interprétation sont toujours possibles

Précisez bien ce que vous voulez faire avec toutes les entités-types temporelles que vous avez modélisé. Je ne serai pas surpris qu'il soit possible de simplifier, peut être en une seule, avec un attribut identifiant "type de période" par exemple pour les distinguer entre elles.
Et si nécessaire une relation réflexive pour les hiérarchiser

[Finol]

Bonsoir,
Merci pour votre réponse.
" Votre exposé requiert un peu d'explication de texte, des définitions : que sont fonctionnellement les pauses, les séances et les séquences, que représentent ces 3 entités d'un point de vue métier ? "

Definitions :

Les pauses : c'est les récréations entre les séances de cours, et aussi les pauses déjeuner.

Les séances : autrement dit " créneau ". un jour contient par exemple 4 créneaux le matin (8h00 à 8h55; 9h00 à 9h55; 10h05 à 11h00 et de 11h05 à 12h00).

Les séquences : une période de temps entre deux dates, un trimestre peut être divisé en 3 séquences par exemple.

Je ne sais pas si je dois encore expliquer autre chose.

En attendant de vous lire, bien cordialement.

[escartefigue]

D'accord, du coup les pauses et séances sont très semblables : il s'agit de périodes de la journée matérialisées par des bornes de début et de fin, ou par une borne de début et une durée, et qui n'ont a priori comme attribut qu'un libellé et les cardinalités sont les mêmes.
Du coup, pourquoi ne pas définir qu'une seule entité-type, "periode" par exemple, en qualifiant le type de période ?
Votre MLD résultant en serait simplifié, et les traitements éventuels de contrôle de période contigüe, chevauchement etc... aussi
Même raisonnement éventuellement pour les vacances et jours fériés, là aussi les relations ne sont pas porteuses d'attributs, les attributs des entités-types semblent pouvoir être harmonisés (il manque juste un libellé coté jours fériés)

Dans l'entité type vacances, si lib_vac_AR est une traduction de lib_vac_FR, alors vous pouvez éventuellement créer une autre entité-type pour autoriser une traduction dans plusieurs langues (il faudra en ce cas modéliser aussi une entité type pour le code langue).

Les entités-type mois et semaine ne comportent que des attributs libellés, elles ne sont peut être pas requises.
Si maintenues, il serait bon de les identifier relativement à l'année

[Finol]

Bonsoir Mr escartefigue et merci beaucoup pour vos réponses instructives .

" D'accord, du coup les pauses et séances sont très semblables : il s'agit de périodes de la journée matérialisées par des bornes de début et de fin, ou par une borne de début et une durée, et qui n'ont a priori comme attribut qu'un libellé et les cardinalités sont les mêmes.
Du coup, pourquoi ne pas définir qu'une seule entité-type, "periode" par exemple, en qualifiant le type de période ?
Votre MLD résultant en serait simplifié, et les traitements éventuels de contrôle de période contigüe, chevauchement etc..."

Vous avez raison, et je pense que je dois fournir encore plus d'informations sur la façon avec laquelle je vois les choses :

Pour établir l'emploi du temps, l'utilisateur dois définir quelques paramètres pour qu'il soit dessiné automatiquement, il va juste définir :

- Jour de début de la semaine ;
- Heure de début des cours ;
- Nombre de séances par jour ;
- Durée de la séance (créneau) ;

Une fois que ces paramètres sont fournis, le tableau (de l'emploi du temps) va être dessiné automatiquement.

Si l’utilisateur par exemple a défini que :
- 1er jour de la semaine : Dimanche ;
Donc les jours ouvrables seront du dimanche au jeudi (05 jours).
- Heure début des cours : 08h00 ;
- Nombre de séances par jour : 04 séances;
- Durée de la séance : 55 Minutes.
Voilà le tableau (emploi du temps) qui sera dessiné pour en effectuer un planning pour chaque classe.




L’utilisateur peut ensuite pour rajouter une pause définir la durée de la pause et le positionnement de cette dernière par rapport à une séance.
Par exemple, ajouter les pauses :
Pause 01 :
- Durée pause : 05 Minutes ;
- Positionnement de la pause : après la (01) première séance.
Pause 02 :
- Durée pause : 10 Minutes ;
- Positionnement de la pause : après la (02) deuxième séance.
Pause 03 :
- Durée pause : 05 Minutes ;
- Positionnement de la pause : après la (03) troisième séance.

Le tableau de l'emploi du temps devient :



Après l’ajout des pauses régulières pour tous les jours et avoir dessiné le tableau de l’emploi du temps, l’utilisateur peut spécifier un après midi libre par exemple le mardi après midi en modifiant les séances en séances non enseignées.

" aussi
Même raisonnement éventuellement pour les vacances et jours fériés, là aussi les relations ne sont pas porteuses d'attributs, les attributs des entités-types semblent pouvoir être harmonisés (il manque juste un libellé coté jours fériés) "

Effectivement il manque l'attribut 'LIB_JOU_FER_FR ET LIB_JOU_FER_AR'.

Pour ce qui est des vacances, je parle là des vacances qui sont définies et déterminées par la direction de l'éducation : vacances d'hiver, vacances du printemps et vacances d'été par exemple. mais il me faut une réflexion par rapport à ce qu vous avez commenté comme étant des relations non porteuses d'attributs.


" Dans l'entité type vacances, si lib_vac_AR est une traduction de lib_vac_FR, alors vous pouvez éventuellement créer une autre entité-type pour autoriser une traduction dans plusieurs langues (il faudra en ce cas modéliser aussi une entité type pour le code langue). "

Là, ce n'est pas vraiment une traduction de la donnée, parce que les données en langues arabes ou en anglais sont à saisir par l'utilisateur et seront extraites directement depuis la base de données, et selon la langue choisie par l'utilisateur seront affichés ces données. C'est vrai qu'il y aura beaucoup plus de nombre de formulaires et de champs à implémenter, mais c'est la seule idée qui me parait faisable, pour ce qui est de l'entité type pour le code langue j'en ai aucune idée.

" Les entités-type mois et semaine ne comportent que des attributs libellés, elles ne sont peut être pas requises.
Si maintenues, il serait bon de les identifier relativement à l'année "

Vous voulez dire par cela que je ne dois utiliser que l'entité calendrier (Jour, mois et année)?

en attendant de vous lire, je vous remercie encore une fois Mr escartefigue .

Bonne nuit !

[escartefigue]

Bonjour,

Dans un premier temps, ne vous laissez pas influencer par l'aspect traitement : l'utilisateur saisira ceci et un tableau de telle forme lui sera présenté, c'est prématuré à ce stade
Concentrez vous sur le quoi (les données) et la façon dont elles s'articulent (les règles de gestion)

[escartefigue]

Là, ce n'est pas vraiment une traduction de la donnée, parce que les données en langues arabes ou en anglais sont à saisir par l'utilisateur et seront extraites directement depuis la base de données, et selon la langue choisie par l'utilisateur seront affichés ces données.

Donc vous avez au moins 3 langues à gérer, même s'il ne s'agit pas de traduction officielle, vous pouvez tout de même modéliser une entité type "langue" et mettre en relation les entités où des libellés sont à traduire avec cette entité-type, de sorte à autoriser la multiplicité des langues. Faute de quoi, quand vous aurez de nouvelles langues à gérer, vous serez contraint de modifier les tables concernées pour ajouter la ou les colonnes de libellés dans les différentes langues.

Vous voulez dire par cela que je ne dois utiliser que l'entité calendrier (Jour, mois et année)?

Concernant les périodes, mois ou semaines, elles n'ont d'intérêt que s'il s'agit de périodes particulières, qui sont à gérer dans la base de données
Le mois de mars en tant que tel, sans référence à une année, ne présente aucun intérêt de gestion.
Par contre, le mois de mars 2016 par exemple, a un intérêt d'un point de vue comptable, paye, échéance de livraison, trimestre scolaire etc...
Du coup, si vous devez modéliser les mois, ou les semaines, il faut qu'ils soient identifiés relativement à l'année
Identifié relativement signifie que l'identifiant unique est composé pour partie d'un identifiant hérité de l'entité-type auquel il fait référence (l'année), et pour une autre partie d'un identifiant propre (le mois)

NB : pour faire référence aux propos des autres contributeurs, vous pouvez utiliser le bouton citer en bas du post, puis copier/coller les balises QUOTE et /QUOTE pour découper le texte si nécessaire