Discussion :

[fsmrel]

Bonsoir diengkals,


Une question :

Ce diagramme récapitulant la partie Enseignants vous convient-il ?



N.B.
Les entités-types CLASSE et ANNEE figurent deux fois : il n’y a en réalité qu’une seule entité-type CLASSE et une seule entité-type ANNEE. Le dédoublement est une astuce graphique disponible avec PowerAMC, permettant d’éviter d’avoir des liens qui se croisent dans tous les sens (et les yeux par voie de conséquence).

[Richard_35]

Bonjour Fsmrel et Diengkals,

De mon point de vue, il faudrait "éclater" la ternaire Enseignant/Classe/Année en, Classe/Année, d'une part, et Enseignant vers Classe/Année, d'autre part. En effet, il me semble qu'il faut former les couples Année/Classe en premier car des classes peuvent être supprimées d'une année sur l'autre, et d'autres ajoutées.

Il faut, en quelque sorte, créer le catalogue des classes pour une année scolaire. C'est l'objet des différents "éclatements" des n,n sur le MCD proposé.

Diengkals, tu disposes de plusieurs approches : la balle est dans ton camp.

[diengkals]

merci de votre de votre aide:

Richard_35

voici la partie entre eleve ,epreuve , matiere et classe verifiez moi l association concerner entre les entités Matiere , Epreuve et Annee_scolaireClasse est ce que ça colle bien

fsmrel

cette partie me convient mais j arrive a mettre la contrainte de totalité avec Jmerise est ce que quelqu'un c'est comment le faire

ci-joint mon modèle général sans la contrainte de totalité

merci d'avance

[fsmrel]

Bonsoir,

j arrive a mettre la contrainte de totalité avec Jmerise

Je suppose qu’en fait vous n’y arrivez pas. En tout cas, des outils que je connais, seul l’AGL WinDesign permet de mettre en oeuvre une contrainte de ce genre.
=>
Faites comme moi, complétez graphiquement avec PAINT ou bien signalez la contrainte à l’aide d’un commentaire...
De toutes façons, c’est au niveau SQL, en fonction de votre SGBD que vous résoudrez concrètement le problème (cf. ce que j'ai écrit à ce sujet).

De mon point de vue, il faudrait "éclater" la ternaire Enseignant/Classe/Année en, Classe/Année, d'une part, et Enseignant vers Classe/Année, d'autre part. En effet, il me semble qu'il faut former les couples Année/Classe en premier car des classes peuvent être supprimées d'une année sur l'autre, et d'autres ajoutées.
Il faut, en quelque sorte, créer le catalogue des classes pour une année scolaire. C'est l'objet des différents "éclatements" des n,n sur le MCD proposé.

Jusqu’ici je n’avais pas examiné l’ensemble du MCD. En regardant de plus près, je constate la présence d’une entité-type (faible) AnneeScolaire_Classe qui représente l’association des entités-types CLASSE et ANNEE, et sur laquelle sont notamment branchées les entités-types INSTITUTEUR et PROFESSEUR. Cette modélisation correspond manifestement à l’éclatement que vous préconisez et qu’on retrouve dans votre message #13.

Maintenant, au vu du dernier MCD proposé par l’ami diengkals (appelons « MCD 1 » ce MCD) :

1) Pour une occurrence de l’entité-type CLASSE on a au moins une occurrence de l’entité-type AnneeScolaire_Classe ;

2) Pour une occurrence de l’entité-type AnneeScolaire_Classe on a au moins un instituteur enseignant en arabe, au moins un instituteur enseignant en français, au moins un professeur enseignant une matière.

Si donc on veut ajouter une occurrence de l’entité-type CLASSE, simultanément on sera obligé d’ajouter une occurrence de l’entité-type AnneeScolaire_Classe et par contrecoup une occurrence de l’association-type enseigne_arabe (sous réserve qu'en face l’instituteur pertinent existe déjà), une occurrence pour l’association-type enseigne_français, etc.

De la même façon, supprimer une occurrence de l’entité-type CLASSE entraîne la suppression des occurrences correspondantes de l’entité-type Annee_scolaireClasse, donc des occurrences correspondantes de l’association-type enseigne_arabe, etc.

Concernant le MCD que j’ai proposé (appelons-le « MCD 2 ») :

Si on veut ajouter ne occurrence de l’entité-type CLASSE, simultanément on devra ajouter une occurrence de l’entité-type ANNEE (si elle n’existe pas déjà) ainsi qu’une occurrence de l’association-type enseigner_en_arabe, etc. : on est dans une situation analogue à celle qui se présente avec MCD 1.

Supprimer une occurrence de l’entité-type CLASSE entraîne la suppression des occurrences correspondantes de l’association-type enseigner_en_arabe, etc. : là encore, on est dans une situation analogue à celle qui se présente avec MCD 1.

On en conclut que du point de vue des opérations d’ajout/suppression de classes que vous évoquez, l’éclatement de la ternaire n’apporte rien (et au niveau SQL il est même cause de jointures supplémentaires — du moins en théorie).

Cela dit, avec la mise en place d’un catalogue des paires {Classe, Année} préexistant au reste, c'est-à-dire de l’entité-type AnneeScolaire_Classe, MCD 1 est à aménager en ce qui concerne les cardinalités minimales : remplacement de 1 par 0 pour la patte connectant AnneeScolaire_Classe et enseigne_arabe, etc. Ainsi on n’est plus obligé d’insérer une occurrence de l’association-type enseigne_arabe dès qu’on insère une occurrence de l’entité-type CLASSE :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6

[CLASSE]----1,N----(R1)----(1,1)----[AnneeScolaire_Classe]----0,N----(enseigne_arabe)----0,N----[INSTITUTEUR]
                                              |
                                              |
[ANNEE]----0,N----(R2)----(1,1)---------------+

(Noter les cardinalités 1,1 mises entre parenthèses, signifiant que AnneeScolaire_Classe n’est qu’une entité-type faible (déguisement de l'association-type entre CLASSE et ANNEE).)

Mais si l'on s’abstient de mettre en place ce catalogue, c'est-à-dire avec MCD 2, on ne perd rien concernant les opérations, il suffit que la cardinalité minimale portée par la patte connectant l’entité-type CLASSE et l’association-type Enseigner_en_arabe soit égale à 0 :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
  
[CLASSE]----0,N----(enseigner_en_arabe)----0,N----[ANNEE]
                             |
                             |
                            0,N
                             |
                             |
                       [INSTITUTEUR]

Vu des opérations (ajouts/suppressions), stricto sensu la mise en œuvre d’un catalogue n’apporte donc rien, on sait faire sans. Mais on ne peut pas préjuger de l’avenir, et peut-être pourrait-il apporter une certaine souplesse.


Observation supplémentaire :

Si, comme il le fait dans son MCD, diengkals met en oeuvre l’entité-type AnneeScolaire_Classe, alors pour respecter la règle selon laquelle pour une classe et une année données il y a au plus un instituteur enseignant en arabe, etc., la cardinalité maximale portée par la patte connectant l’entité-type AnneeScolaire_Classe et l’association-type enseigne_arabe doit être égale à 1 (en conséquence de quoi la CIF CLASSE X ANNEE -> INSTITUTEUR enseignant en arabe est de facto garantie) :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

[AnneeScolaire_Classe]----0,1----(enseigne_arabe)----0,N----[INSTITUTEUR]

Après tout cela, et pour conclure, je ne vois pas d’objection à la mise en œuvre de l’entité-type AnneeScolaire_Classe, ne serait-ce qu’au vu du dernier point.


@ diengkals

Une dernière remarque quand même concernant la cardinalité 0,1 que je viens d'évoquer :

Je vous invite à lire ce qu’a écrit CinePhil : Quand faut-il une table associative ?


Un MCD dans lequel figure le catalogue suggéré par Richard (entité-type CLASSE_ANNEE) :





Le MLD qui en est dérivé :



P.-S.
Dans votre dernier MCD, vous faites figurer une entité-type SALLE : en l’absence des règles de gestion correspondantes, on ne sait pas formellement quel est son rôle.

Même si ça n'est pas la partie la plus palpitante de votre travail, je rappelle à cette occasion que vous devez constituer le corpus exhaustif des règles de gestion (numérotées tant qu’à faire). A défaut, vous me copierez cent fois : « En l’absence des règles de gestion, le MCD relève seulement des arts plastiques »...

[Richard_35]

Bonjour Fsmrel et Diengkals,

Diengkals, tout est dit par Fsmrel !... notamment, brillamment, sur les arts plastiques...

L'entité SALLE va nous entraîner dans la partie "emploi du temps" évoquée précédemment et devant faire l'objet, de mon point de vue, d'une discussion à part entière (disponibilité des enseignants, des salles, spécialisation des salles, etc...).

L'histoire des "ternaires" à éclater (ou pas) en "binaire" + "simple" me paraît intéressante, d'un point de vue conceptuel ("binaire"=catalogue, "simple"=choix à partir du catalogue). Le piège étant d'établir des triplets sans contrôle des couples possibles. CinePhil, si tu nous lis, ce serait un thème intéressant pour un futur billet (si j'ai un peu de temps je te préparerai une petite bafouille).

[diengkals]

bonjour et merci de votre aide ,

j ai pris note de toutes vos suggestions et je viens de mettre à jour mes règles de gestion. j'ai enlevé la salle pour les emploi-temps en attendant de validé cette partie et pour les contrainte de totalité et CIF j attendrais lors de la génération de la base de données

voici à nouveau mes règles de gestion :

Les règles de gestions :

INSCRIPTION
1. Un élève s’inscrit dans une seule classe à une année scolaire donnée
2. 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
3. Un cycle (primaire, collège ou lycée) contient plusieurs niveaux d’étude (1 année ,2 année …)
4. Un niveau d’étude donné appartient à un seul cycle.
5. Un niveau d’étude peut avoir plusieurs classes.
6. Une classe a un seul niveau d’étude.
PARTIE ENSEIGNANT
7. -Nous avons deux type d’enseignant : des instituteurs pour le cycle primaire et les professeurs pour les cycles collège et lycée
8. Un instituteur est un enseignant et un enseignant peut être un instituteur.
9. Un professeur est un enseignant et un enseignant peut être un professeur.
10. Un enseignant est soit un instituteur ou un professeur il ne peut pas être les deux en même temps.
11. un enseignant du primaire peut enseigner dans plusieurs classes la même année scolaire.
12. un enseignant du secondaire peut enseigner plusieurs matières la même année scolaire.
13. une matière peut être enseignée par plusieurs professeurs dans différentes classes dans la même année scolaire.
14. deux professeurs différents ne peuvent pas enseigner en même temps la même matière à la même classe d’élèves mais un professeur peut enseigner dans une classe de la même année deux matières différentes.
15. pour une classe on peut avoir deux Instituteurs par exemple Un instituteur Arabe qui va enseigne toute les matières enseignées en Arabe et un Instituteur français qui va enseigner toutes les matières enseignées en français.
16. On peut avoir aussi un Instituteur qui est bilingue (arabe et français) donc il va jouer le rôle d'enseignant arabe et français
EVALUATION DES ELEVES
17. Une année scolaire contient 3 trimestres.
18. pour chaque trimestre l’élève aura deux évaluations, une évaluation en mi-trimestre qui compte 25% et une évaluation vers la fin du semestre qui compte 75%.
19. Un élève peut passer une évaluation d’une matière enseignée dans une classe qu’il est inscrit.
20. une épreuve peut concerner plusieurs matières.
Gestion des emploi-temps
21. L’école contient des salles de classe.
22. Pour le cycle de primaire les classes ont des salles fixes pour toute l’année scolaire ; mais pour le cycle secondaire, les classes n’ont pas de salle fixe donc elles varient en fonction des heures d’enseignement de chaque matière pour une classe donnée.
23. Une matière d’une classe est enseignée à une heure donnée dans une classe qui n’est pas occupée.

j'ai' ci-joint a nouveau mon modèle voir si ça répond a mes nouvelles regle de gestion sans la dernière partie des régles gestion (gestion emploi du temps que je viens de commencer la redaction )

merci d'avance

[fsmrel]

Bonsoir diengkals,


Bel effort de rédaction des règles . Je n’ai pas tout lu car il y a des points que je n’ai pas encore examinés. Une question quand même, car je lis :

Règle 14 : [...] un professeur peut enseigner dans une classe de la même année deux matières différentes.

Il s’agit bien de deux matières au maximum ?

Sinon, en survolant le MCD, je constate que vous avez supprimé l’entité-type associative AnneeScolaire_Classe connectant CLASSE et ANNEE_SCOLAIRE : pas de problème.

Je regarderai tout cela de plus près. En attendant, je joins ci-dessous ce que j’ai rédigé avant de lire votre message, donc certains points peuvent être désormais caducs, par exemple ce que je vous raconte à propos du « catalogue » CLASSE_ANNEE (alias AnneeScolaire_Classe).

Avant de mettre à niveau mon MCD en fonction de vos mises à jour, voici ce que j’ai écrit :

« 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 :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

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 :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

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}.

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.

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 :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

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) :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

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 :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

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) :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

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... »

_______________________

Fin de ce que j’ai écrit avant de lire votre dernier message.

[Richard_35]

Bonjour Fsmrel,

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 :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

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...

==> c'est le moins que l'on puisse dire !... merci d'avoir fait passer cette partie du MCD "au rasoir de Fsmrel".

[diengkals]

bonjouet merci de votre aide :

je vais aller doucement avec vos remarques pertinentes et j ai enlevez la partie salle pour trouver une solution convenable de la ou nous somme
pour ce qui de votre question :

Règle 14 : [...] un professeur peut enseigner dans une classe de la même année deux matières différentes.

Il s’agit bien de deux matières au maximum ?

dans mon cas nous avons avoir juste deux matière au maximum mais je pense c'est la même modélisation dans le cas général c'est à dire au plus trois matière.

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...

ici dans ma modelisation j arrive pas a mettre les contraintes CIF et la contrainte de totalité mais je compte les gérée au niveau du developpement ou si y a une solution de le faire au niveau de la base de données je suis preneur.

une question:

pour la partie entitté classe et classe_année est ce que une bonne chose d'enlevé la partie classe_année ou je la laisse ?

et merci d'avance

[fsmrel]

Bonsoir diengkals,

dans mon cas nous avons avoir juste deux matière au maximum mais je pense c'est la même modélisation dans le cas général c'est à dire au plus trois matière.

Dire « au plus trois matières » a quelque chose de ponctuel et d’artificiel ne valant que pour aujourd’hui. Le mieux serait de faire une ouverture et écrire à titre d’extension de la règle 12 :

14. [...] un professeur peut enseigner dans une classe de la même année plusieurs matières différentes.

A la limite, c’est au niveau SQL qu’on pourra éventuellement créer une contrainte fixant le nombre maximum de matières enseignées une année donnée par un professeur à une classe, quitte à modifier ce nombre au besoin (c’est du paramétrage, et imaginez que vous vendiez votre système... )

dans ma modélisation je n’arrive pas à mettre les contraintes CIF et la contrainte de totalité mais je compte les gérée au niveau du développement ou si y a une solution de le faire au niveau de la base de données je suis preneur.

D’une manière générale, il faut traiter les contraintes au niveau de la base de données (à coup de vues, assertions, triggers, etc.) plutôt qu’au sein des programmes.

1) Cas de la CIF

Tous les outils ne permettent pas de modéliser les CIF dans le cas des associations de dimension > 2 (dimension = nombre de pattes). Dans ce cas-là, comme je l’ai déjà signalé, vous pouvez attirer l’attention à l’aide d’un commentaire, ou faire comme ci-dessous, surcharger en couleur l’œuvre graphique à l’aide d’un outil comme PAINT :



Puis au niveau SQL vous retirez ClasseId de la clé de la table INSCRIRE, clé qui est alors réduite à {EleveId, Annee}. C’est quand même plus simple et plus sûr que d’envisager de garantir la contrainte par programme...

Vous pouvez aussi déguiser l’association-type en entité-type, en identifiant INSCRIRE relativement à ELEVE et ANNEE. Dans le style PowerAMC :



Là aussi, au niveau SQL la clé de la table INSCRIRE est composée de la paire {EleveId, Annee}, mais sans qu’on ait besoin cette fois-ci d’intervenir manuellement (du moins avec un outil de modélisation connaissant l’identification relative).


2) Cas de la contrainte de totalité »

Souvenez-vous de ce que j’ai écrit le 13 novembre dernier :

Le moyen de faire respecter la contrainte de totalité — qui veut qu’un instituteur enseigne au moins dans une langue — dépend en fait du type de SGBD, soit relationnel (possibilité d’affectation multiple), soit SQL (pas de possibilité d’affectation multiple). Si le SGBD est SQL, tout dépend de sa position par rapport à la norme (assertions + contrôles différés, possibilité de mettre à jour des vues de jointure). Avec la plupart des SGBD on est en gros contraint d’effectuer les INSERT non pas directement « dans » les tables mais « dans » des vues de jointure : INSTITUTEUR_Enseigner_en_arabe et INSTITUTEUR_Enseigner_en_français, un trigger se chargeant au besoin de ventiler les données dans les tables INSTITUTEUR, Enseigner_en_arabe, Enseigner_en_français (sous réserve encore que le SGBD accepte d’associer un trigger à une vue, voyez MySQL...)

est ce que une bonne chose d'enlever la partie classe_année ou je la laisse ?

Je constate que dans votre MCD l’entité-type CLASSE_ANNEE n’est plus présente : c'est bien comme ça. Etant donné comme on le sait qu’elle n’apporte en fait rien de décisif, inutile de la réintégrer.

[diengkals]

merci bien de votre aide :

pour les contraintes de CIF et de totalité je pense que je vais les gérer au niveau de la création de la base de données.

Maintenant je vais passer pour ma partie gestion des emplois du temps

pour cela j ai redigé une petite regle de gestion :

Gestion des emploi-temps
21. L’école contient des salles de classe.
22. Pour le cycle de primaire les classes ont des salles fixes pour toute l’année scolaire ; mais pour le cycle secondaire, les classes n’ont pas de salle fixe donc elles varient en fonction des heures d’enseignement de chaque matière pour une classe donnée.
23. Une matière d’une classe est enseignée à une heure donnée dans une classe qui n’est pas occupée.


toutes vos gestions pour les régles de gestion sont les bienvenues


merci d'avance

[Richard_35]

Bonjour Fsmrel et Diengkals,

Je constate que dans votre MCD l’entité-type CLASSE_ANNEE n’est plus présente : c'est bien comme ça. Etant donné comme on le sait qu’elle n’apporte en fait rien de décisif, inutile de la réintégrer.

==> eh bien, cela dépend s'il est utile de gérer un "catalogue" des classes pour une année donnée (suppression de classe d'une année sur l'autre, création de classe d'une année sur l'autre, etc...). Les saisies "hors catalogue" seraient alors interdites.

D'autre part, cela permettrait de reconstituer le "catalogue" des classes pour les années passées, sans passer la ternaire par l’entonnoir d'une requête SQL groupée.



Mais, effectivement, peut-être est-ce inutile.

[fsmrel]

Bonsoir,


Avant de repartir sur la modélisation des horaires et des salles :

A propos de la règle 22 : vous parlez de « salles fixes » pour le cycle primaire. Je suppose que l’on doit interpréter cela comme « à usage exclusif », c'est-à-dire qu’une salle affectée à l’usage exclusif d'une classe donnée du cycle primaire ne pourra jamais être « prêtée », même si à tel moment de tel jour de la semaine cette salle est inoccupée (la classe qui l'occupe passant par exemple tel après-midi au stade). C’est bien cela ?

A propos de la règle 23 : on pourrait peut-être aménager la règle ainsi :

Dans le cas du cycle secondaire, une matière d’une classe est enseignée selon un horaire donné dans une salle qui lui est alors réservée exclusivement, le temps du cours.

Il est important de préciser la structure du type HORAIRE, car on aura vraisemblablement à en faire une table du genre :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
HORAIRE {HoraireId, JourSemaine, HeureDebut,HeureFin}
    KEY {HoraireId} ;

Où JourSemaine prend les valeurs « dimanche », « lundi », etc.

Cela vous convient-il ? Sinon quelle est votre perception de la chose ?


A propos des CIF (encore...)

Le fait d’évacuer l’entité-type CLASSE_ANNEE fait que les associations-types Enseigner_en_arabe et Enseigner_en_français sont porteuses de CIF symbolisées ci-dessous par des flèches rouges (cf. le message #40) :






Une fois de plus, si lors de l’étape de production du MLD l’outil produit les tables Enseigner_en_arabe et Enseigner_en_français sans réduire des clés :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
Enseigner_en_arabe {ClasseId, Annee, EnseignantId}
    KEY {ClasseId, Annee, EnseignantId} ;

Enseigner_en_français {ClasseId, Annee, EnseignantId}
    KEY {ClasseId, Annee, EnseignantId} ;

Alors ces clés devront être réduites manuellement (évacuation de l’attribut EnseignantId) :

KEY {ClasseId, Annee}

Je rappelle en passant que le MLD correspondant est le suivant :



Comme dans le cas des élèves qui sont inscrits dans telle classe pour telle année scolaire, et pour ne pas avoir à faire le ménage à la main, vous pouvez préférer transformer les associations-types en entités-types (tout en y rapatriant l’attribut Annee, l’occasion faisant le larron) :




Le MLD correspondant est évidemment le même que ci-dessus.


A suivre.

cela dépend s'il est utile de gérer un "catalogue" des classes

On en a déjà largement débattu, on a vu que ce catalogue n’a pas de valeur ajoutée décisive, et ça été tranché. Diengkals a fait son choix : on ne va pas lui faire faire du yoyo en permanence.

[fsmrel]

@ Richard_35

Notez qu’avec la modification que vous avez apportée à votre MCD, un élève peut être inscrit la même année dans plusieurs classes.



Par ailleurs au niveau MLD, la table AnneeScolaire_Classe comportera deux fois l’attribut IdAnneeScolaire et deux fois l’attribut IdClasse.

[Richard_35]

Notez qu’avec la modification que vous avez apportée à votre MCD, un élève peut être inscrit la même année dans plusieurs classes.

==> non. La table associative résultante de la relation (n,n) "Inscription" devra être la suivante :

Eleve_AnneeScolaire_Classe(#IdEleve, #IdAnneeScolaire, #IdClasse, ...)

et non pas :

Eleve_AnneeScolaire_Classe(#IdEleve, #IdAnneeScolaire, #IdClasse, ...)

[fsmrel]

Notez qu’avec la modification que vous avez apportée à votre MCD, un élève peut être inscrit la même année dans plusieurs classes.

==> non.

Plaît-il ?

Soit K La clé de la table Inscription issue de l’association-type Inscription lors de la dérivation du MCD en MLD.

Tous les ouvrages traitant de Merise enseignent que lors de la dérivation du MCD en MLD, K hérite d’une part de l’identifiant de l’entité-type Eleve et d’autre part de l’identifiant de l’entité-type AnneeScolaire_Classe, parce que les cardinalités maximales sont N de chaque côté de l’association-type. Etant donné que l’identifiant de l’entité-type AnneeScolaire_Classe est composé des attributs IdClasse et IdAnneeScolaire, il s’ensuit que l’attribut IdClasse appartient bien à K.

Exemple avec PowerAMC :

MCD



MLD produit par l’AGL



Pour arriver à K = {ClasseId, Annee}, il faut faire référence à une entité-type CLASSE d’une part et une entité-type ANNEE d’autre part et, par exemple, mettre en œuvre une CIF (flèche rouge ci-dessous).



On ne va quand même pas passer la nuit là-dessus, le cas est traité et entériné depuis que Merise existe.

[Richard_35]

Merci pour la démonstration, brillante, comme d'habitude .

Néanmoins,
Eleve_AnneeScolaire_Classe(#IdEleve, #IdAnneeScolaire, #IdClasse, ...)
me paraît assez "élégant" pour le cas envisagé bien que, sans doute, hors normes .

Mais, c'est vrai, et c'est le plus important :

Diengkals a fait son choix : on ne va pas lui faire faire du yoyo en permanence.

Quant à :

On ne va quand même pas passer la nuit là-dessus, le cas est traité et entériné depuis que Merise existe.

==> cela mériterait un débat à part entière... que nous n'allons pas entamer ici... re-.

[fsmrel]

Néanmoins,
Eleve_AnneeScolaire_Classe(#IdEleve, #IdAnneeScolaire, #IdClasse, ...)
me paraît assez "élégant" pour le cas envisagé bien que, sans doute, hors normes .

Élégant ou pas, normes ou pas, au niveau du MLD c’est la seule solution puisqu’un élève ne peut pas être inscrit la même année dans deux classes distinctes :

Dans le cadre de la théorie relationnelle, la seule dépendance fonctionnelle non triviale qui existe en conséquence pour la relvar (variable relationnelle) Eleve_AnneeScolaire_Classe est la suivante.

{IdEleve, dAnneeScolaire} -> {IdClasse}

Mathématiquement parlant, Eleve_AnneeScolaire_Classe respecte en fait la 6NF et on ne peut pas faire mieux : ça tue le débat.

[diengkals]

bonjour Richard_35 et fsmrel et merci beaucoup de votre aide: pour ce qui est de l'entité classe et classe_année, je suis entrain de revoir vos posts précédents pour mieux comprendre et voir ce qui m arrangerait .

à

fsmrel

je suis bien d'accord avec vous pour cette partie des salles pour le cycle primaire soit fixes et ne pourra pas être prêtées

A propos de la règle 22 : vous parlez de « salles fixes » pour le cycle primaire. Je suppose que l’on doit interpréter cela comme « à usage exclusif », c'est-à-dire qu’une salle affectée à l’usage exclusif d'une classe donnée du cycle primaire ne pourra jamais être « prêtée », même si à tel moment de tel jour de la semaine cette salle est inoccupée (la classe qui l'occupe passant par exemple tel après-midi au stade). C’est bien cela ?

pour les horaires cette partie me convient car pour l'heure d'enseignement d'une matiere on aura besoin de la date (le jour) plus le début et la fin du cours

HORAIRE {HoraireId, JourSemaine, HeureDebut,HeureFin}
KEY {HoraireId} ;

et merci d'avance

[fsmrel]

Bonsoir,


A propos des horaires

Vous avez enrichi votre MCD d’un attribut Horaire figurant dans l’association-type ENSEIGNER :



Au niveau du MLD, la table ENSEIGNER qui en est inférée a la structure suivante :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
ENSEIGNER {Annee, ClasseId, MatiereId, EnseignantId, Horaire} 
    KEY {Annee, ClasseId, MatiereId, EnseignantId} ;

Mais on est bien d’accord qu’on baigne dans un univers quantique « comaque » comme dirait Raoul Volfoni...

En effet, Des situations loufoques comme celles-ci deviennent légales :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
Situation   ANNEE  CLASSE  MATIERE   PROFESSEUR  HORAIRE
            -----  ------  -------   ----------  ------------
    1       2012   5eA     CHIMIE    HARPO       LUNDI 9h-10h
    2       2012   5eA     MATHS     HARPO       LUNDI 9h-10h      
    3       2012   5eA     CHIMIE    GROUCHO     LUNDI 9h-10h      
    4       2012   4eB     MATHS     HARPO       LUNDI 9h-10h      
    5       2012   5eA     MATHS     CHICO       LUNDI 9h-10h      
    6       2012   4eB     HARPE     HARPO       LUNDI 9h-10h      
    7       2012   5eA     PIANO     CHICO       LUNDI 9h-10h

C'est-à-dire que M. Harpo donne en même temps un cours de chimie et un cours de maths aux élèves de 5eA, pendant que M. Groucho leur donne lui aussi un cours de chimie ;
Tant qu’à être quantiquement correct, toujours au même moment, M. Harpo donne par ailleurs un cours de maths et une leçon de harpe aux élèves de 4eB ;
Et pour faire bonne mesure, toujours au même moment, M. Chico donne lui aussi un cours de maths plus une leçon de piano aux élèves de 5eA ;

Etc. Pauvres élèves...

Bon, d’accord, on a déjà vu qu’il y avait une CIF empêchant que deux professeurs donnent le même cours aux élèves d’une même classe (cf. message #41) :


Quoi qu'il en soit, traduisons la CIF sous forme de règle :

Ra - Pour une année scolaire donnée, une classe donnée n’étudie une matière donnée qu’avec seul un professeur.

En observant qu’il existe aussi maintenant la règle :

Rb - Pour une année scolaire donnée, une classe donnée n’étudie une matière donnée que durant un seul horaire.

Mais les horaires viennent ficher la patouille, tout est loin d’être résolu, car seuls sont refusés au motif de la règle Ra les ajouts correspondant aux lignes barrées (on suppose que l’ordre des lignes du tableau ci-dessous reflète le moment auquel ont été effectués les ajouts) :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
Situation   ANNEE  CLASSE  MATIERE   PROFESSEUR  HORAIRE
            -----  ------  -------   ----------  ------------
    1       2012   5eA     CHIMIE    HARPO       LUNDI 9h-10h
    2       2012   5eA     MATHS     HARPO       LUNDI 9h-10h      
    3       2012   5eA     CHIMIE    GROUCHO     LUNDI 9h-10h      
    4       2012   4eB     MATHS     HARPO       LUNDI 9h-10h      
    5       2012   5eA     MATHS     CHICO       LUNDI 9h-10h      
    6       2012   4eB     HARPE     HARPO       LUNDI 9h-10h      
    7       2012   5eA     PIANO     CHICO       LUNDI 9h-10h

Pour interdire les autres situations loufoques, il est impératif de mettre en œuvre des règles supplémentaires, certes intuitivement évidentes, mais devant néanmoins être formulées (comme dit JPhi33 : « Cela va sans dire... mais cela va mieux en le disant ! ») et ayant une incidence forte sur la modélisation :

Rc - Pour une année scolaire donnée, durant un horaire donné, un professeur donné n’enseigne qu’une matière.
Rd - Pour une année scolaire donnée, durant un horaire donné, un professeur donné n’enseigne qu’à une seule classe.
Re - Pour une année scolaire donnée, durant un horaire donné, une classe n’étudie qu’une matière.
Rf - Pour une année scolaire donnée, durant un horaire donné, une classe n’a qu’un seul professeur.

N.B. La règle Rf n’a en fait pas besoin d’être formulée, puisqu’elle est la conséquence logique des règles Ra et Re.
Comme diraient finement Ullman et Fagin : {Ra, Re} ⊨ Rf.

En traduisant les règles sous la forme de dépendances fonctionnelles :

DF1 : {Annee, ClasseId, MatiereId} -> {EnseignantId, Horaire}
DF2 : {Annee, ClasseId, Horaire} -> {EnseignantId, MatiereId}
DF3 : {Annee, EnseignantId, Horaire} -> {ClasseId, MatiereId}

Ces DF ne sont pas triviales, leur déterminant (partie gauche) est irréductible, et par ailleurs l’ensemble des attributs qui en sont éléments représente l’en-tête de la table : chaque déterminant est donc clé.

Au niveau MLD, la structure de la table ENSEIGNER reste la même, mais elle comporte désormais trois clés conformes à la théorie relationnelle :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
ENSEIGNER {Annee, ClasseId, MatiereId, EnseignantId, Horaire} 
    KEY {Annee, ClasseId, MatiereId} 
    KEY {Annee, ClasseId, Horaire} 
    KEY {Annee, EnseignantId, Horaire} ;

=> On est désormais prémuni contre les situations loufoques.

Représentation graphique :

Il est important de préciser la structure du type HORAIRE, car on aura vraisemblablement à en faire une table du genre :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
 HORAIRE {HoraireId, JourSemaine, HeureDebut, HeureFin}
    KEY  {HoraireId} ;

Où JourSemaine prend les valeurs « dimanche », « lundi », etc.
Cela vous convient-il ? Sinon quelle est votre perception de la chose ?

Pour les horaires cette partie me convient car pour l'heure d'enseignement d'une matière on aura besoin de la date (le jour) plus le début et la fin du cours.

D’accord, mais désormais l’horaire est composé des trois éléments : jour de la semaine, heure de début, heure de fin. Pour respecter la 1re forme normale (1NF), on est donc conduit à mettre en œuvre une entité-type HORAIRE, et le MCD évolue :


La représentation de la CIF CLASSE X MATIERE X ANNEE -> PROFESSEUR (c'est-à-dire la règle Ra) s'est compliquée, mais c'est à cause de la présence de la patte connectant l’entité-type HORAIRE et l’association-type ENSEIGNER alors que cette entité-type n’est pas partie prenante dans la CIF.

ENSEIGNER représente la « portée » de la CIF et PROFESSEUR en représente la « cible » (flèche rouge), tandis que les entités-types MATIERE, CLASSE et ANNEE en représentent le « pivot » symbolisé par les traits pleins en rouge branchant ces trois entités-types sur la contrainte (CIFa dans l’exemple). L’arc en pointillés sert à brancher la portée sur la contrainte.

A titre d’exercice (mais je ne le ferai pas tous les jours, c’est plutôt pénible !) traduisons les autres règles elles aussi sous forme de CIF dans le MCD.


Pour traduire la règle Rb :



Pour traduire la règle Rc :



Pour traduire la règle Rd :



Pour traduire la règle Re :



Pour traduire la règle Rf :



Je dirais que l’expression des CIF est quand même tellement plus simple au stade du MLD (mise en œuvre des clés inférées des règles)...

Je suppose que pour votre part vous vous contenterez à juste titre d’agrémenter votre MCD d’un commentaire attaché à ENSEIGNER, signifiant que les contraintes seront traitées au stade MLD, mais n’oubliez quand même pas d’enrichir le corpus des règles de gestion des données...

Quoi qu’il en soit, le but de la manœuvre était de montrer les conséquences de l’ajout que vous avez fait de l’attribut Horaire dans l’association-type ENSEIGNER : on peut dire que ça n’est pas anodin ! Des CIF dans tous les sens au niveau conceptuel, des clés supplémentaires au niveau du MLD, tout cela pour éviter des effets quantiques ou l’asile, au choix...


A propos des salles

Ne va-t-on pas carrément sombrer dans la folie en prenant en compte les salles où les malheureux élèves pourront se demander ce qui va encore leur arriver ?

Pas de panique ! On retrouve en fait au niveau logique le MLD figurant dans le message #47, à ceci près qu’entre-temps l’horaire a fait l’objet d’une entité-type dans le MCD, donc d’une table au stade MLD. La transformation à opérer est simple :



Je vous laisse faire la rétro-conception du MLD en MCD, mais je suppose une fois de plus qu’au lieu de transpirer sur la représentation graphique des CIF, vous vous contenterez d’agrémenter votre MCD d’un commentaire signifiant que les contraintes seront traitées au stade MLD sous forme de clés, mais là encore n’oubliez pas d’enrichir le corpus des règles de gestion des données...