Bonsoir,
Traitons déjà de la table ENSEIGNER.
Envoyé par
diengkals
j'ai une autre proposition, au lieu de mettre la relation localiser je vais juste laisser la relation enseigner qui sera relié entre tous ces entités, classe, année , matiere, horaire salle et professeur, donc j'aurai dans la table enseigner :
enseigner (idclasse, idmatiere, idhoraire, idsalle, idprofesseur, idannee)
est ce que c'est une bonne idée de le faire ?
A priori ça n’est pas forcément une très bonne idée, mais peut-être qu'après tout on ne pourra pas vous le reprocher...
Je m’explique. Si l’on vous suit, on va repasser par la case Départ et retomber dans les problèmes quantiques, bizarres, que j’ai évoqués et dénoncés ici...
Reprenons la structure que vous proposez :
ENSEIGNER (idclasse, idmatiere, idhoraire, idsalle, idprofesseur, idannee)
Pour pouvoir m’exprimer plus rigoureusement, je vais utiliser dorénavant le vocabulaire de la théorie relationnelle. ENSEIGNER devient une relvar (abréviation de relational variable, en français variable relationnelle). Pour des raisons de facilité de rédaction, je renomme les attributs : idclasse en C, idmatiere en M, idhoraire en H, idsalle en S, idprofesseur en P et idannee en A. La structure de la relvar ENSEIGNER devient donc :
ENSEIGNER {C, M, H, S, P, A}
Notez que j’ai remplacé les parenthèses par des accolades, car l’en-tête — c'est-à-dire {C, M, H, S, P, A} dans notre cas — d’une relvar est un ensemble dont les éléments sont les attributs de la relvar.
J’ai dit que votre idée n’est pas a priori très bonne, parce que la relvar ENSEIGNER viole la BCNF, ce qui se traduit automatiquement par de la redondance des données dont il faudra assurer la cohérence, comme l’a démontré le Dr E. F. Codd depuis 1971. Cela fait donc plus de quarante ans qu’on s’échine à normaliser, en cassant une relvar non normalisée en relvars qui le soient, par la technique dite de projection/jointure : ainsi, votre relvar ENSEIGNER peut être décomposée en deux relvars (LOCALISER et ENSEIGNER « dégraissée ») comme je l’ai déjà fait, rappelez-vous :
lieu_cours_horaire_MLD.png)
Mais en normalisant, je peux perdre en route des règles de gestion, plus précisément celles qui expriment des contraintes d’unicité : c'était bien la peine que je me donne tant de mal à les inventorier... 
Pour prouver ce que je dis, allons-y pour dresser un inventaire exhaustif de ces contraintes. On a déjà vu certaines d’entre elles à l’occasion du message #60, mais cette fois-ci il faut tenir compte de la salle.
Je signale en passant qu’après vérification la règle suivante figurant dans ce message est fausse :
Rb - Pour une année scolaire donnée, une classe donnée n’étudie une matière donnée que durant un seul horaire.
En effet, pour l’année scolaire 2012, la classe de 5eA peut très bien étudier l’anglais le lundi de 11 heures à 12 heures et le mercredi de 14 heures à 15 heures.
Comme quoi on ne se relit jamais assez... Anyway. Allons-y pour énumérer les contraintes d’unicité, que certaines soient inférables d’autres ou non :
Ra - Au cours d’une année scolaire donnée, une classe donnée n’étudie une matière donnée qu’avec seul un professeur.
Rb - Au cours d’une année scolaire donnée, durant un horaire donné, une classe donnée n’étudie qu’une matière.
Rc - Au cours d’une année scolaire donnée, durant un horaire donné, une classe donnée ne se situe que dans une seule salle.
Rd - Au cours d’une année scolaire donnée, durant un horaire donné, une classe donnée n’étudie qu’avec un seul professeur.
Re - Au cours d’une année scolaire donnée, durant un horaire donné, dans une salle donnée n’est enseignée qu’une matière.
Rf - Au cours d’une année scolaire donnée, durant un horaire donné, dans une salle donnée n’est présente qu’une seule classe.
Rg - Au cours d’une année scolaire donnée, durant un horaire donné, dans une salle donnée n’est présent qu’un seul professeur.
Rh - Au cours d’une année scolaire donnée, durant un horaire donné, un professeur donné n’enseigne qu’une seule matière.
Ri - Au cours d’une année scolaire donnée, durant un horaire donné, un professeur donné n’enseigne qu’à une seule classe.
Rj - Au cours d’une année scolaire donnée, durant un horaire donné, un professeur donné n’est présent que dans une seule salle.
Si j’ai omis certaines contraintes, merci de compléter et si je me suis planté dans mes copier/coller, merci de rectifier...
Quoi qu’il en soit, à partir des contraintes que j’ai énumérées, on obtient l’ensemble suivant de dépendances fonctionnelles (au sens de la théorie relationnelle) :
DFa : {A, C, M} -> {P}
DFb : {A, C, H} -> {M}
DFc : {A, C, H} -> {S}
DFd : {A, C, H} -> {P}
DFe : {A, S, H} -> {M}
DFf : {A, S, H} -> {C}
DFg : {A, S, H} -> {P}
DFh : {A, P, H} -> {M}
DFi : {A, P, H} -> {C}
DFj : {A, P, H} -> {S}
Partant de là, on sait montrer que la relvar ENSEIGNER viole la BCNF et qu’il faudrait la décomposer pour que tout rentre dans le rang.
Pour que la relvar respecte la BCNF, le déterminant de chaque dépendance fonctionnelle ci-dessus doit en être une clé candidate, or ça n’est pas le cas de DFa, puisque au cours d’une année scolaire donnée, une classe donnée peut suivre l’enseignement d’une matière donnée plus d’une fois par semaine et pas toujours dans la même salle.
On est face à un dilemme...
— Soit on normalise comme je l’ai fait, mais alors on perd les dépendances fonctionnelles :
DFd : {A, C, H} -> {P}
DFg : {A, S, H} -> {P}
Donc les règles de gestion Rd et Rg. Pour les garantir, on doit par exemple en passer par la mise en oeuvre d'une jointure naturelle de « mes » tables ENSEIGNER et LOCALISER, plus deux assertions (ou des triggers affectés à la vue si votre SGBD SQL ne permet pas de procéder autrement).
— Soit on conserve en l’état votre relvar ENSEIGNER, en violant la BCNF mais il faudra garantir la cohérence des redondances, mettant en œuvre un dispositif garantissant les dépendances fonctionnelles. En l’occurrence, vous vous en sortez pas mal, car le déterminant des dépendances fonctionnelles autres que DFa est clé candidate, ce qu'on assure sans problème au niveau SQL :
1
2
3
4
5
6
7
8
9
10
11
12
| CREATE TABLE ENSEIGNER
(
A INT NOT NULL,
C INT NOT NULL,
M INT NOT NULL,
S INT NOT NULL,
H INT NOT NULL,
P INT NOT NULL,
PRIMARY KEY (A, C, H),
UNIQUE (A, P, H),
UNIQUE (A, S, H)
) ; |
Reste à garantir la dépendance fonctionnelle DFa : {A, C, M} -> {P}, ce qui se fera au moyen d’une assertion, ou de triggers affectés à la table ENSEIGNER si votre SGBD SQL ne permet pas de procéder autrement.
Conclusion : on ne saurait vous blâmer si vous retenez votre solution, sous réserve que vous n'oubliez pas l'assertion (ou les triggers) garantissant le respect des règles de gestion...
Pour le moment j'en suis là. Je regarderai plus attentivement toute cette affaire, histoire de m'assurer que je ne me suis pas planté quelque part. De votre côté ça serait bien que vous procédiez aussi à une vérification de l'inventaire que j'ai dressé des règles de gestion...
En cas de résolution, et afin de faciliter la tâche des bénévoles, merci de cliquer sur 
.
et 
permettent aux forumeurs de cibler leur recherche dans une discussion : n'hésitez pas à voter !
Répondre avec citation
Soit, allons-y pour un coup de yoyo supplémentaire.Inscrire_et_catalogue_MCD.png)
Inscrire_et_catalogue_MLD.png)
inscriptions.png)
!... le post .jpg)
diengkals(enseignants)Inscrire_et_catalogue(CIF)variante_MCD.png)
Partager