« Jusqu’ici je n’ai pour ma part examiné que la partie « Enseignants ». Voici quelques remarques concernant les élèves en relation avec les classes.
Les règles de gestion que vous fournissez sont les suivantes (cf. votre message
#8) :
— Un élève s’inscrit dans une seule classe pour une année scolaire donnée.
— une classe voit s'inscrire plusieurs élèves pour une année scolaire donnée et une année scolaire voit l'inscription de plusieurs élèves dans plusieurs classes.
Au stade MCD :
La flèche rouge exprime une CIF selon laquelle au cours d’une année scolaire donnée un élève n’est inscrit que dans une seule classe :
ELEVE X ANNEE -> CLASSE
Selon cette représentation, au niveau logique la structure de table INSCRIRE qui en est inférée est la suivante :
1 2
| INSCRIRE {IdEleve, IdAnneeScolaire, IdClasse}
KEY {IdEleve, IdAnneeScolaire} ; |
En l’occurrence, on montre qu’on ne peut pas utiliser le « catalogue » CLASSE_ANNEE (alias AnneeScolaire_Classe). Dans votre message #25 (entre autres), vous vous appuyez sur ce catalogue :
[ELEVE]----1,N----(INSCRIRE)----1,N----[AnneeScolaire_Classe]----1,1----(ComprendreClasse)----1,N----[Classe]
Au niveau logique la structure de table INSCRIRE qui en est inférée est la suivante :
1 2
| INSCRIRE {IdEleve, IdAnneeScolaire, IdClasse}
KEY {IdEleve, IdAnneeScolaire, IdClasse} ; |
Cette structure est la même que j’ai fournie ci-dessus mais, élément important, la clé inférée de votre association-type INSCRIRE n’est pas la bonne puisque cette fois-ci un élève peut être inscrit la même année dans plusieurs classes...
Si vous tenez à la représentation :
[ELEVE]----1,N----(INSCRIRE)----1,N----[AnneeScolaire_Classe]----1,1----(ComprendreClasse)----1,N----[Classe]
Alors au niveau MLD, il vous faudra veiller à éliminer l’attribut IdClasse parasitant la clé de la table INSCRIRE, clé qui je le rappelle est {IdEleve, IdAnneeScolaire}.
![Citation](https://forum.developpez.be/images/misc/quote_icon.png)
Envoyé par
Richard_35
Liste des classes par année
- un élève s’inscrit dans une seule classe à une année scolaire donnée.
- une classe voit s'inscrire plusieurs élèves à une année scolaire donnée et une année scolaire voit l'inscription de plusieurs élèves dans plusieurs classes.
![](http://www.developpez.net/forums/attachment.php?attachmentid=105173&stc=1&d=1352282627)
D’accord pour les règles de gestion, mais selon votre représentation, au niveau logique la structure de table ELEVE qui en est inférée est la suivante :
1 2
| ELEVE {IdEleve, IdAnneeScolaire, IdClasse}
KEY {IdEleve} ; |
C'est-à-dire qu’un élève ne peut s’inscrire que dans une seule classe au cours de sa scolarité, ce qui est quand même peu...
Note concernant l’entité-type AnneeScolaire_Classe :
diengkals, vous avez mis en œuvre un attribut identifiant nommé Id pour cette entité-type (faible, car déguisement d’une association-type). Cet attribut doit disparaître, car — par le mécanisme de l’identification relative — AnneeScolaire_Classe hérite déjà des attributs identifiants des entités-types CLASSE et AnneeScolaire. Cet attribut est mal venu car il provoque un affaiblissement sémantique, et en plus il peut inhiber les contrôles que l’on a à effectuer en relation avec les entités-types et associations-types telles que ENSEIGNER. Bref, au niveau logique, la table AnneeScolaire_Classe (alias CLASSE_ANNEE) doit avoir la structure suivante (au nom près des attributs) :
1 2
| AnneeScolaire_Classe {ClasseId, Annee}
KEY {ClasseId, Annee} ; |
Concernant l’occupation des salles
En ajoutant à l’association-type ENSEIGNER une patte la connectant à l’entité-type SALLE, non seulement vous changez le sens de l’association-type (enseigner le français ne se situe pas a priori dans l’espace), mais en plus vous inférez des règles de gestion de type quantique. En effet, au niveau logique la table dérivée de l’association-type a pour structure :
1 2
| ENSEIGNER {ClasseId, Annee, MatiereId, EnseignantId, SalleId, Horaire}
KEY {ClasseId, Annee, MatiereId, SalleId} ; |
On pourrait avoir la situation suivante (en supposant qu’un horaire correspondant à une tranche horaire pour un jour dans la semaine) :
1 2 3 4 5 6 7 8 9 10
|
ANNEE CLASSE MATIERE SALLE PROFESSEUR HORAIRE
----- ------ ------- ----- ---------- ------------
2012 5eA CHIMIE 117 ALBERT LUNDI 9h-10h
2012 5eA CHIMIE 003 ALBERT LUNDI 9h-10h
2012 5eA CHIMIE 045 ALBERT LUNDI 9h-10h
2012 5eA MATHS 003 ALBERT LUNDI 9h-10h
2012 4eB MATHS 003 ALBERT LUNDI 9h-10h
2012 4eB ESPAGNOL 003 ALBERT LUNDI 9h-10h
2012 5eA ANGLAIS 003 BERNARD LUNDI 9h-10h |
Autrement dit, un professeur peut donner au même moment un cours de chimie dans des salles différentes, et différents professeurs peuvent donner leurs cours au même moment dans la même salle, etc. : bizarre, comme c’est bizarre...
Bref...
Pour reprendre le MCD que j’ai précédemment proposé :
Il faut établir une association entre l’association-type Enseigner et l’entité-type SALLE. Évidemment comme en général les outils refusent ce genre d’association, on doit se résigner à transformer Enseigner en entité-type pour pouvoir se brancher sur SALLE :
D’où le MLD (incomplet) qui en est dérivé :
Pour ne pas rester au stade quantique, certaines contraintes sont à mettre en évidence.
Si une classe est un tout, non sujette à scissiparité, on peut mettre en évidence les règles suivantes :
R314 : Au cours de l’année scolaire A, il est prévu que la classe C à l’heure H apprenne la matière M ;
R315 : Au cours de l’année scolaire A, il est prévu que la classe C à l’heure H occupe la salle S.
De la même façon, toujours pour éviter des effets quantiques :
R316 : Au cours de l’année scolaire A, il est prévu qu’à l’heure H et dans la salle S soit enseignée la matière M ;
R317 : Au cours de l’année scolaire A, il est prévu qu’à l’heure H la salle S soit occupée par la classe C.
De ces règles on infère les dépendances fonctionnelles (au sens de la théorie relationnelle) associées à l’en-tête de la table LOCALISER :
DF314 : {Annee, ClasseId, Horaire} -> {MatiereId}
DF315 : {Annee, ClasseId, Horaire} -> {SalleId}
DF316 : {Annee, SalleId, Horaire} -> {MatiereId}
DF317 : {Annee, SalleId, Horaire} -> {ClasseId}
C'est-à-dire qu’on a mis en évidence les clés candidates supplémentaires suivantes pour la table LOCALISER :
AK1 = {Annee, ClasseId, Horaire}
AK2 = {Annee, SalleId, Horaire}
Ce que l’on répercute au niveau du MLD :
Où l’on est donc intervenu manuellement pour empêcher les bizarreries, en définissant les clés alternatives qui vont bien. On aurait pu agir au niveau du MCD, mais au prix de transformations et contorsions n’en valant guère la peine, ayant pour conséquence la mise en place d’une usine à gaz. On passerait carrément d’une représentation acceptable du point de vue des arts plastiques, à un machin qui relèverait plutôt de l’art new-yorkais,
horresco referens ! Mais si le cœur vous en dit...
A suivre... »
_______________________
Partager