Discussion :

[win_ubuntu]

Bonjour tout le monde.
J'aimerais établir un MCD concernant l'énoncé suivant:
On veut réaliser l’informatisation de l’affectation hebdomadaire des salles d’un collège, et la gestion des absences des élèves.

Le collège est composé de 20 salles de classe, dont 2 équipées de rideaux noirs et de projecteurs vidéo, de 2 salles de laboratoire et d’une salle de sports. D’autres matériels (rétroprojecteurs, écrans, triples tableaux...) sont également affectés à certaines salles.

Les salles ont une capacité variant de 20 à 45 places. La salle de sports a une capacité de 150 places.

Le collège gère 5 classes de 6°, et 4 classes de 5°, 4° et 3°. Chaque classe est numérotée.

Les élèves d’une même classe suivent tous les mêmes cours : il n’y a pas d’options. La liste des élèves de chaque classe est fixée en début d’année (on admet qu’un élève ne change pas de classe, et qu’il n’y a pas d’arrivées en cours d’année). Les cours se répètent à l’identique sur toutes les semaines de l’année scolaire.

Un enseignant peut assurer des cours pour plusieurs classes. Pour affecter un cours à une salle et à un enseignant, on veut pouvoir vérifier que l’enseignant n’a pas de cours simultanément pour une autre classe.

Un cours ne peut pas être assuré par plusieurs enseignants. Les cours sont repérés par le nom de l’enseignant. Certains enseignants assurent plusieurs types de cours (Français, Latin...).

En ce qui concerne l’affectation hebdomadaire des salles, on ne veut pas réaliser un système d’aide à la décision, mais pouvoir obtenir la liste des salles permettant d’accueillir un cours, qui ne sont pas déjà affectées à un autre cours à l’horaire voulu. Il n’y a pas de cours commun à plusieurs classes. Certains cours nécessitent des matériels spécifiques (de la vidéo, un labo ou la salle de sports...). Mais un cours qui n’a pas besoin de vidéo peut néanmoins avoir lieu dans la salle de vidéo. Pour une même classe, on peut avoir un TP de chimie le mardi, nécessitant le labo, et un cours de chimie ne le nécessitant pas. On admet que les affectations sont décidées à l’année : un cours (repéré par un jour, une heure et un enseignant, ex : lundi 10h, Mr Dupont) a lieu dans la même salle et pour la même classe toutes les semaines.

En ce qui concerne la gestion des absences, le traitement manuel actuel est le suivant : une feuille de présence quotidienne, marquée du n° de semaine et du nom du jour, circule d’enseignant à enseignant en cours de journée. Lorsque la “Vie scolaire” est avertie d’une absence d’un élève avant le début des cours, elle reporte la mention “Excusé” sur la ligne de l’élève, pour chaque cours concerné. Chaque enseignant reporte la liste et le nombre d’absences non excusées et constatées à son cours. La feuille de présence retourne à la vie scolaire en fin de journée. Toutes les absences injustifiées font l’objet d’un courrier adressé aux parents, indiquant les jours et heures d’absence de l’élève. Un élève peut être absent à un cours sans être absent sur la journée. Une absence à un cours unique peut être justifiée à l’avance (rendez-vous dentiste...).

voila ma solution:

l'association emplois du temps contient plusieurs CIF: par exemple
salle, horaire -> un seul cours, une seule classe.
si vous avez des remarques à propos de mon essai n'hésiter pas.
merci d'avance

[fsmrel]

Bonsoir win_ubuntu,


Nous avons déjà eu le plaisir de parler des MCD il y a quelque temps.

Je n’ai pas regardé de près celui-ci, mais j’ai noté votre remarque concernant les CIF. Le problème est que vous utilisez AMC, lequel ne connaît pas les CIF et nous oblige donc à nous contorsionner dans tous les sens pour pallier.

Le mieux est en fait de passer à Looping, pétri de qualités et qui a l’avantage (entre autres) de permettre de modéliser les CIF, et qui les traduit automatiquement lors du passage à SQL.

Je pense que le papa de Looping ainsi que le Capitaine Escartefigue ne manqueront pas d’expertiser votre travail.

A noter que Looping est gratuit, on peut donc remercier chaleureusement son très sympathique et désintéressé géniteur, le Professeur Patrick Bergougnoux.

Pour voir comment modéliser une CIF sans perdre de temps, voyez par exemple ici.

A noter encore : il y a désormais un forum Looping.

Voilà...

[Paprick]

Bonjour,

Effectivement, le problème de PowerAMC, c'est qu'il ne règle les contraintes liées au CIF qu'au niveau logique en vous permettant d'exclure, dans le MLD, certaines rubriques de la clé primaire composée des différentes classes d'entités associées... Ce n'est donc pas une bonne solution quand on cherche une solution conceptuelle valable pour un système d'information.
Par ailleurs, comme vous l'avez mentionné, l'association "emplois_du_temps" méritera qu'on s'y attarde... Cette quadri-patte m'inquiète quelque peu et les CIF s'imposeront forcément pour parvenir à un modèle cohérent.

[escartefigue]

Bonsoir win_ubuntu

A chaque fois que vous modélisez des associations à plus de deux pattes, et surtout quatre ou plus comme dans le cas de votre asso "emploi_du_temps", il convient de poser le stylo pour vérifier que tous les acteurs liés interviennent bien dans cette association et se poser la question de ce que représente concrètement cette association.
Quand une asso est légitime, on lui trouve assez facilement un verbe ou un groupe verbal pour la désigner.
"emploi du temps" n'est pas un verbe, ceci combiné à sa quadrupédie plaide en sa défaveur.

Concernant les enseignants et les élèves, on constate que leurs attributs sont communs.
On peut donc utiliser l'héritage : une entité-type commune, par exemple "personne", sera porteuse des attributs partagés (nom, prénom, date de naissance...) et des sous-types seront utilisés pour ce qui est spécifique (matricule employé par exemple). Certaines associations pourront concerner le surtype "personne" d'autre l'un ou l'autre des sous-types.

Au sujet des cardinalités minimales, l'énoncé n'est pas suffisamment détaillé, mais si l'on veut pouvoir connaître des enseignants non affectés à des cours (retraités, en année sabbatique, arrêt de travail...), alors un mimimum de zéro s'impose.

Pour la CIF qui nous intéresse, à savoir "une salle, à un instant t, n'est affectée qu'à un seul cours", voici un exemple de mise en œuvre avec Looping.



Le script correspondant est le suivant :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
CREATE TABLE SA_salle(
   SA_ident INT IDENTITY,
   PRIMARY KEY(SA_ident)
);

CREATE TABLE PE_personne(
   PE_ident INT IDENTITY,
   PE_nom VARCHAR(50) NOT NULL,
   PE_prenom VARCHAR(50) NOT NULL,
   PE_date_nais DATE NOT NULL,
   PRIMARY KEY(PE_ident)
);

CREATE TABLE ES_enseignant(
   PE_ident INT,
   ES_matricule CHAR(6) NOT NULL,
   PRIMARY KEY(PE_ident),
   UNIQUE(ES_matricule),
   FOREIGN KEY(PE_ident) REFERENCES PE_personne(PE_ident)
);

CREATE TABLE EL_eleve(
   PE_ident INT,
   PRIMARY KEY(PE_ident),
   FOREIGN KEY(PE_ident) REFERENCES PE_personne(PE_ident)
);

CREATE TABLE CL_classe(
   CL_ident INT IDENTITY,
   CL_code CHAR(5) NOT NULL,
   PRIMARY KEY(CL_ident),
   UNIQUE(CL_code)
);

CREATE TABLE YM_type_mat(
   YM_ident INT IDENTITY,
   YM_code CHAR(4) NOT NULL,
   YM_libelle VARCHAR(50) NOT NULL,
   PRIMARY KEY(YM_ident),
   UNIQUE(YM_code)
);

CREATE TABLE MA_materiel(
   MA_ident INT IDENTITY,
   MA_date_acq DATE NOT NULL,
   YM_ident INT NOT NULL,
   SA_ident INT NOT NULL,
   PRIMARY KEY(MA_ident),
   FOREIGN KEY(YM_ident) REFERENCES YM_type_mat(YM_ident),
   FOREIGN KEY(SA_ident) REFERENCES SA_salle(SA_ident)
);

CREATE TABLE CO_cours(
   CO_ident INT IDENTITY,
   PE_ident INT NOT NULL,
   PRIMARY KEY(CO_ident),
   FOREIGN KEY(PE_ident) REFERENCES ES_enseignant(PE_ident)
);

CREATE TABLE AF_affecter(
   SA_ident INT,
   CA_date DATETIME2,
   CO_ident INT NOT NULL,
   PRIMARY KEY(SA_ident, CA_date),
   FOREIGN KEY(SA_ident) REFERENCES SA_salle(SA_ident),
   FOREIGN KEY(CO_ident) REFERENCES CO_cours(CO_ident)
);

CREATE TABLE IN_inscrire(
   PE_ident INT,
   CL_ident INT,
   CA_date DATETIME2,
   PRIMARY KEY(PE_ident, CL_ident, CA_date),
   FOREIGN KEY(PE_ident) REFERENCES EL_eleve(PE_ident),
   FOREIGN KEY(CL_ident) REFERENCES CL_classe(CL_ident)
);

CREATE TABLE SU_suivre(
   CO_ident INT,
   CL_ident INT,
   PRIMARY KEY(CO_ident, CL_ident),
   FOREIGN KEY(CO_ident) REFERENCES CO_cours(CO_ident),
   FOREIGN KEY(CL_ident) REFERENCES CL_classe(CL_ident)
);

Grâce à la CIF, Looping a évacué l'identifiant CO_ident de la PK de la table associative AF_affecter. De fait, la CIF est vérifiée

[fsmrel]

Bonsoir,


@win_ubuntu :

J’ai regardé d’un peu plus près votre MCD. Comme dit Paprick, l’association EMPLOI_DU_TEMPS est pour le moins suspicieuse, elle disparaîtra.

Comme dans le contexte AMC, avec Looping, l’entité-type HORAIRE ne mérite pas de donner lieu à une table dans le MLD, donc lors de sa création, il faut cocher la case « Classe d’entités fictive ». Pour mémoire, cette entité-type est dotée du seul attribut jourHeure, de type DATETIME au sens SQL.

Vu ses attributs, votre entité-type COURS permet en fait de décrire les types de cours (français, latin, maths, chimie, etc.) Il y a là une ambiguïté à lever aussi faudrait-il renommer cette entité-type par exemple en TYPE_COURS. Je suppose par ailleurs qu’il y a plus d’un professeur enseignant le français, le latin, etc., autrement dit il faudrait mettre en oeuvre une association, nommons-la A_LA_COMPETENCE permettant de définir les compétences de chaque enseignant. Une entité-type COURS toute neuve voit alors le jour, qui fait référence à l’entité-type TYPE_COURS et qui permet d’associer un enseignant aux cours qu’il assure.

il est écrit dans votre énoncé : « Les cours sont repérés par le nom de l’enseignant », en conséquence de quoi, sémantiquement parlant, il est légitime de dire que la nouvelle entité-type COURS est une entité-type faible, relativement à l’entité-type ENSEIGNANT, ce qui techniquement conduit (avec Looping) à cocher la case « Identifiant relatif » pour la patte d’association connectant l’entité-type COURS et l’association ASSURE. L’identification relative est notée « 1,1(R) », sachant qu’avec AMC, elle est notée « (1,1) ».

A son tour, l’entité-type COURS peut aussi être perçue comme une association entre ENSEIGNANT et CLASSE, il s’ensuit que la patte d’association entre COURS et SUIVRE est porteuse d’une cardinalité 1,1.


Dans ce que je suis en train de proposer, un enseignant a la compétence pour des types de cours et assure certains cours : il va de soi qu’il y une contrainte d’inclusion impliquant les associations ASSURE et A_LA_COMPETENCE : un enseignant ne peut assurer que des cours pour lesquels il est qualifié.

L’affaire se corse avec l’occupation des salles, et les CIF montrent le bout de leur museau.. Ainsi, à une date et une heure données, un cours n'a lieu dans une seule salle : Il existe la dépendance fonctionnelle (DF)  COURS X HORAIRE → SALLE, impliquant la mise en oeuvre d’une association ternaire, nommons-la poétiquement, par exemple, COHS. Ceci fait, on ajoute la CIF traduisant cette DF, mais pour ne pas surcharger le modèle, demandons à Looping de la représenter par une simple pointe de flèche (en cliquant sur la patte d’association connectant COHS et SALLE et en y cochant la case « Entité ciblée par CIF ») :

Comme vous le signalez, il existe d’autres DF, donnant lieu à la modélisation d’autant de CIF (donc d’associations ternaires).

Par exemple :

A un instant donné une salle n’héberge qu’un seul cours ;

A un instant donné un enseignant ne peut être présent que dans une seule salle ;

A un instant donné une classe ne peut être présente que dans une seule salle ;

Etc. !

@Captaine Escartefigue :

Selon ton MCD, un cours donné peut être suivi par plusieurs classes, ton entité-type CO_cours correspondrait alors plutôt à un type de cours (français, latin, maths, etc.) c’est-à-dire à l’entité-type que j’ai nommée de mon côté TYPE_COURS. Mais dans ces conditions la cardinalité 1,1 entre l’entité-type CO_cours et l’association Asso_3 fait qu’un seul enseignant peut assurer un cours d’un type donné : par exemple, seul M. Raoul assurerait les cours de français...

Qui plus est, selon ta CIF, à un instant donné dans une salle donnée on ne peut y donner qu’un cours donné, mais vu ma remarque, il s’agirait là encore d’un type de cours donné, par exemple un cours de français, et les classes où l’on enseigne le français pourraient toutes se retrouver en même temps dans cette salle, qui n’est quand même pas aussi extensible que l’hôtel de Hilbert...

[escartefigue]

@Captaine Escartefigue :

Selon ton MCD, un cours donné peut être suivi par plusieurs classes, ton entité-type CO_cours correspondrait alors plutôt à un type de cours (français, latin, maths, etc.) c’est-à-dire à l’entité-type que j’ai nommée de mon côté TYPE_COURS. Mais dans ces conditions la cardinalité 1,1 entre l’entité-type CO_cours et l’association Asso_3 fait qu’un seul enseignant peut assurer un cours d’un type donné : par exemple, seul M. Raoul assurerait les cours de français....

Effectivement, je n'ai pas mis la bonne cardinalité, c'est bien sûr 1 de [COURS] vers (suivre)


Pour le reste, il s'agit d'un exercice scolaire dont l'énoncé est très simplifié. Si la qualification des enseignants pour telle ou telle matière est pertinente dans la vraie vie, elle n'est pas abordée dans l'énoncé. De même il est bien mentionné que les élèves ne changent jamais de classe en cours d'année, le matériel ne change jamais de salle etc.

[win_ubuntu]

Merci infiniment à tous.
@fsmrel ,@escartefigue
Normalement, un cours est suivi par plusieurs classes de même niveau: nous avons comme exemple 5 classes de 6° (6°N1, 6°N2,...,6N°5).
si le cours math est programmé pour le niveau 6° alors toutes les classes de la 6° (6°N1, 6°N2,...,6N°5) doivent suivre ce cours. c'est pour cela, je vois que la participation de l'entité "classe" à l'association: emploi_du_temps est nécessaire.

[fsmrel]

Bonsoir,


J’ai renommé TYPE_COURS en MATIERE, là encore le nom est un peu plus pertinent.

Identifier un cours à partir du nom de l’enseignant n’est pas recommandé ! Ça fait 35 ans qu’Yves Tabourier l’a expliqué...

Cas de la contrainte d’inclusion entre les associations ASSURE et A_LA_COMPETENCE : concernant la génération du code SQL, Looping ne prend aucune initiative pour ce genre de contrainte (même chose pour les contraintes d’exclusion).

En conséquence la balle est dans notre camp pour assurer. Je propose ceci (contexte SQL Server) :

(1) Suite à la création de la table A_LA_COMPETENCE, création d’une fonction ad-hoc ;

(2) Ajout d’une contrainte pour la table COURS, faisant appel à cette fonction :

-----------------------------------------------
-- Un enseignant ne peut dispenser que des
-- cours pour lesquels il est qualifié.
-- La fonction COURS_COMPETENCE_INCLUSION
-- a pour objet de s'en assurer.
-- En entré de la fonction :
-- l'identifiant de l'enseignant et celui
-- de la matière enseignée.
-- Si cet enseignant n'est pas qualifié,
-- la fonction fournit en sortie la valeur 0. 
-----------------------------------------------
GO
CREATE FUNCTION COURS_COMPETENCE_INCLUSION(@enseignantId INT, @matiereId INT)
RETURNS INT  
AS   
BEGIN  
   DECLARE @n INT  

   SELECT @n = COUNT(*) 
   FROM   A_LA_COMPETENCE 
   WHERE  enseignantId = @enseignantId AND matiereId = @matiereId  
   RETURN @n  
END ;  
GO  

ALTER TABLE COURS  
    ADD CONSTRAINT COURS_COMPETENCE_CHK 
        CHECK (dbo.COURS_COMPETENCE_INCLUSION(enseignantId, matiereId) > 0) ; 

Si ce code est incorporé à une règle, alors à notre demande, Looping l’ajoutera à la suite des CREATE TABLE.

Dans l’énoncé initial, il est écrit :

Un cours ne peut pas être assuré par plusieurs enseignants

La patte d’association entre COURS et ASSURE est 1,1, donc tout va bien. Tordons un peu la règle et énonçons :

Pour une classe et une matière données, il ne peut y avoir qu'un seul enseignant.

win_ubuntu, vous nous direz si cette règle vous semble réaliste. Elle paraît anodine, mais quoi qu’il en soit, il y a là une DF à garantir : MATIERE X CLASSE → ENSEIGNANT.

Qui dit DF, dit CIF, donc association ternaire à laquelle participeraient MATIERE, CLASSE et ENSEIGNANT, mais il suffit en fait de définir la clé candidate {matiereId, classeId} pour la table COURS. Là encore, fendons-nous d’une règle Looping, comportant le code suivant :

ALTER TABLE COURS  
     ADD  CONSTRAINT COURS_AK 
        UNIQUE (matiereId, classeId) ;

Effectivement, je n'ai pas mis la bonne cardinalité, c'est bien sûr 1 de [COURS] vers (suivre)

Le remplacement est bénéfique

Cela dit, passer de 0,1 à 1,1 est à privilégier car sémantiquement, COURS peut être vu comme une association entre ELEVE et MATIERE (anciennement TYPE_COURS).

Je pense que tu seras d’accord que la mise en oeuvre de l’entité-type MATIERE est une bonne chose.

Pour le reste, il s'agit d'un exercice scolaire dont l'énoncé est très simplifié. Si la qualification des enseignants pour telle ou telle matière est pertinente dans la vraie vie, elle n'est pas abordée dans l'énoncé. De même il est bien mentionné que les élèves ne changent jamais de classe en cours d'année, le matériel ne change jamais de salle etc.

Exercice scolaire simplifié certes, mais soulevant quand même quelques problèmes intéressants. En fait, on retrouve ici une variante du schéma relationnel (relational scheme) CTHRSG de Jeffrey Ullman (Universités de Princeton et Stanford), que celui-ci utilise beaucoup dans les chapitres 7 (Design Theory for Relational Databases) et 9 (The Universal Relation As A User Interface) de son ouvrage Principles of Database Systems, Second Edition, paru en 1982, et qui me fut offert en 1987 (j’ai l’impression que c’est hier...). Je l’ai tellement crayonné que j’ai dû faire l’acquisition d’un 2e exemplaire il n’y a pas si longtemps... Je signale qu’en 1988, Ullman a sorti une nouvelle version de son ouvrage, mais en deux volumes (avec une modification du titre, Principles of Database and Knowledge-Base Systems. Le 1er volume est téléchargeable : Principles of Database and Knowledge-Base Systems, Volume I. Le chapitre 7 est toujours à sa place, mais le chapitre 9 a été transféré dans le volume II (où il est devenu le chapitre 17).

si le cours math est programmé pour le niveau 6° alors toutes les classes de la 6° (6°N1, 6°N2,...,6N°5) doivent suivre ce cours. c'est pour cela, je vois que la participation de l'entité "classe" à l'association: emploi_du_temps est nécessaire.

En fait, si l’entité-type CLASSE détermine l’entité-type NIVEAU (association CL_NIV avec cardinalité 1,1), et si vous établissez une association, nommons-la MAT_NIV, entre les entités-types NIVEAU et MATIERE (cf. ci-dessous), alors toutes les classes d’un niveau donné auront de facto à leur programme les matières définies par l’association MAT_NIV. Reste à voir l’impact sur le reste du MCD (cohérence entre COURS et MAT_NIV).

[escartefigue]

Bonjour François

Je pense que tu seras d’accord que la mise en oeuvre de l’entité-type MATIERE est une bonne chose.

Oui, le cours doit se rapporter à une matière ! Sinon ce n'est plus un cours, mais de l'étude surveillée