[MCD] precision sur l'heritage

[Richard_35]

Bonjour Fsmrel et Diengkals,

Diengkals va être perturbé par la réapparition de l'héritage...

Remarques :

Envoyé par Diengkals

je vois pas comment je vais faire pour dire que tel type enseignant (professeur ) enseigne tel matière ou un instituteur enseigne tel classe

==> Fsmrel, ces règles de gestion parlent de la notion "d'enseigner" et non pas "de savoir enseigner" (ta relation). Cela ne veut pas dire que c'est une mauvaise idée de le prévoir, au contraire, mais ce n'est pas la règle de gestion.

Un enseignant "professeur" pourrait très bien "devoir enseigner" les mathématiques uniquement, et "savoir enseigner", également, la physique. Et cela, pour une année scolaire particulière ainsi que pour une classe particulière.

L'association ternaire {instituteur, classe, année} est correcte et est représentée dans le schéma JMerise précédent.

Par contre, effectivement, les associations "Enseigner (si instituteur)" et "Enseigner (si professeur)" ne sont, sans doute, pas très propres, du point de vue Merise... mais cela peut constituer une base de travail à améliorer.

[diengkals]

merci

Richard_35

et

fsmrel

de votre aide, c'est vrai que je suis un peu perturber mais ça m apprend beaucoup de chose, comme je vous ai dit au début c'est un projet d'innovation donc y'a pas une règle de gestion bien définie je cherche toujours la meilleurs règle de gestion. donc vos suggestions sont les bien venues

Code :

1
2
3
fsmrel
Question : Est-ce que deux professeurs différents peuvent enseigner en même temps la même matière à la même classe d’élèves ?

deux professeurs différents ne peuvent pas enseigné en même temps la même matière a la même classe d’élevés mais un professeur peut enseigné dans une classe de la même année deux matière différentes.

La flèche rouge symbolise une CIF (contrainte d’intégrité fonctionnelle), signifiant qu’une classe donnée n’a qu’un instituteur au cours d’une année (je ne préjuge pas des changements d’enseignants en cours d’année).

ici 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 toute les matières enseignées en français

Richard_35

pour ce qui de enseignant , professeur et Instituteur
j aurai du mal a comprendre cette gestion "Enseigner (si instituteur)" enseigne la classe et "Enseigner (si professeur)" enseigne Matiere
Comment MCD pour gérer ces conditions ou comment le représenté?

merci d'avance

[Richard_35]

Envoyé par Diengkals

pour ce qui de enseignant , professeur et Instituteur
j aurai du mal a comprendre cette gestion "Enseigner (si instituteur)" enseigne la classe et "Enseigner (si professeur)" enseigne Matiere
Comment MCD pour gérer ces conditions ou comment le représenté?

==> ce serait l'application qui, au moment des affectations, proposerait :

• si l'enseignant est un professeur : la liste des couples {classes, matières} pour l'année scolaire concernée ;
• si l'enseignant est un instituteur : la liste des classes pour l'année scolaire concernée.

En résumé, je ne pense pas que le MCD puisse tout régler.

[CinePhil]

Je n'ai pas lu la discussion mais ne pas oublier qu'on peut aussi créer un héritage de données simplement parce qu'une entité fille a une ou des associations spécifiques.

Voici un schéma simplifié réalisé avec JMerise (l'occasion pour moi de l'essayer) :

[diengkals]

bonjour, après avoir lu votre aide et suggestion j ai retenu ce modèle ci joint :
vous suggestion et remarque sont les bienvenues:
et si je voudrais gérer en plus les emplois du temps de chaque de chaque classe comment je vais modéliser ça

à

Richard_35

pouvez vous m expliquez les relation associer_eleve_trimestre , associer_trimestre et les tables eleve_trimestre et trimestre .

merci encore d'avance

[Richard_35]

Envoyé par Diengkals

pouvez vous m expliquez les relation associer_eleve_trimestre , associer_trimestre et les tables eleve_trimestre et trimestre .

==> suite à tes règles de gestion :

Envoyé par Diengkals

- pour chaque trimestre l’élève aura un contrôle et un examen

donne

Envoyé par Diengkals

- un élève peut passer un contrôle et un examen d’une matière enseigné dans une classe qu’ il est inscrit

==> cette règle de gestion non intégrée : je te laisse t'y coller .

[fsmrel]

Bonsoir,

Envoyé par diengkals

Le type enseignant Instituteur enseigne le cycle primaire donc il va enseigner une classe entière.

Et d'après ce qui suit, un instituteur n'enseigne pas forcément toutes les matières :

Envoyé par diengkals

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 toute les matières enseignées en français

D’accord, vous apportez des précisions importantes. Mais il faudrait tenir à jour le corpus des règles de gestion définies ici et implicitement enrichi des règles supplémentaires apparaissant au fil des messages.

On peut penser qu'il n'y a que deux cas de figures. Il faudrait quand même que vous précisiez s’il y en a d’autres ou non.

Conséquences sur la modélisation, en supposant qu’il n’y a que deux cas :



Selon ce diagramme, un instituteur peut enseigner en arabe et/ou en français. La règle de gestion doit le confirmer, sinon si un instituteur n’enseigne que dans une langue (disons indépendamment des années scolaires), le diagramme devient :



Je rappelle que XT symbolise une contrainte de partitionnement (X pour exclusion, T pour totalité (un instituteur doit enseigner)). La portée de la contrainte est constituée des deux associations-types. Le pivot est constitué de l’entité-type INSTITUTEUR.


Par ailleurs, je me suis exprimé dans mon message précédent en écrivant :

Envoyé par fsmrel

Ce MCD est à aménager en fonction des règles de gestion des données, auxquelles j’ai jeté un coup d’œil.

A cette occasion, j’attendais la réponse à ma question et à laquelle diengkals a répondu :

Envoyé par diengkals

Deux professeurs différents ne peuvent pas enseigner en même temps la même matière a la même classe

Cette règle fait donc l’objet d’une CIF, symbolisée ci-dessous par la flèche ciblant l’entité-type PROFESSEUR :



C'est-à-dire MATIERE X CLASSE X ANNEE -> PROFESSEUR

Envoyé par Richard_35

ces règles de gestion parlent de la notion "d'enseigner" et non pas "de savoir enseigner" (ta relation).

On est bien d’accord, mais pour enseigner une matière, encore faut-il avoir la compétence. On a affaire à un cas d’école (sic !), que l’on retrouve notamment dans la référence « Journée Afcet, 15 novembre 1990 », quand il s’agit d’illustrer le concept de contrainte d’inclusion :



Pour en revenir à notre cas de figure et tenir compte de la contrainte, on peut compléter le diagramme ainsi :



L’association-type Enseigner représente la portée de la contrainte et Savoir Enseigner la cible.
La paire {MATIERE, PROFESSEUR} représente le pivot de la contrainte, explicité par les traits en pointillés.

[Richard_35]

Bonjour Fsmrel,

Envoyé par Fsmrel

On est bien d’accord, mais pour enseigner une matière, encore faut-il avoir la compétence. On a affaire à un cas d’école (sic !) .../...

==> certes !... et c'est pour cela que c'est une bonne idée que Diengkals y pense.

Attention, toutefois, aux conséquences. Si les "compétences" et les "attributions" sont gérées, alors, effectivement, il ne faut "attribuer" une matière qu'à des professeurs qui en ont la "compétence". Clair !... mais c'est, de mon point de vue, un autre sujet sur lequel Diengkals pourrait se pencher.

Cela voudrait dire que, l'ensemble des "attributions" d'un professeur doit être inclus dans l'ensemble de ses "compétences" : nombre de "compétences" >= nombre "d'attributions".

Si, en final, dans la base de données, nombre de "compétences" = nombre "d'attributions", alors il y aura une gestion parallèle et la conséquence pourrait être que l'application refuse "d'attribuer" une matière à un professeur qui ne la possède pas dans ses "compétences", bien que l'utilisateur ne veuille pas, réellement, gérer les "compétences".

Nous tomberons, alors, dans la validation forcée d'une "compétence" pour effectuer une "attribution" (et, en final, nombre de "compétences" = nombre "d'attributions").

Mais, encore une fois, c'est, en soi, une bonne idée.

[diengkals]

bonjour, merci beaucoup de votre aide

Richard_35

j ai bien noté vos remarques et merci pour votre réponse et précision.
pour cette regle de gestion:

- un élève peut passer un contrôle et un examen d’une matière enseigné dans une classe qu’ il est inscrit

je suis entrain de la modélisé je vous montrais tout de suite ma modélisation:

fsmrel

merci beaucoup de vos réponse pertinente :
pour ce qui de cette regle de gestion :

Le type enseignant Instituteur enseigne le cycle primaire donc il va enseigner une classe entière.
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 toute les matières enseignées en français

dans mon cas j'ai que que ces deux cas : Instituteur arabe et français :

Selon ce diagramme, un instituteur peut enseigner en arabe et/ou en français. La règle de gestion doit le confirmer, sinon si un instituteur n’enseigne que dans une langue (disons indépendamment des années scolaires), le diagramme devient :

dans mon ici je peux avoir un Instituteur qui est bilingue(arabe et français) donc il va jouer le rôle d'enseignant arabe et français

On est bien d’accord, mais pour enseigner une matière, encore faut-il avoir la compétence. On a affaire à un cas d’école (sic !), que l’on retrouve notamment dans la référence « Journée Afcet, 15 novembre 1990 », quand il s’agit d’illustrer le concept de contrainte d’inclusion :

ici pour ne pas trop alourdir mon application je dirais que ici on dit un professeur enseigne une matière c'est qu'il a des compétences dans cette matière mais je tiendrais en considération vos suggestion au cas je voudrais amélioré l'application

[Richard_35]

Envoyé par Diengkals

et si je voudrais gérer en plus les emplois du temps de chaque de chaque classe comment je vais modéliser ça

==> désolé, je n'ai pas trop le temps d'étudier cette extension. Je te suggère de statuer, d'abord, sur la partie qui nous occupe actuellement.

Ensuite, ouvres une nouvelle discussion concernant la partie "emploi du temps" en établissant une première ébauche "déconnectée" du MCD global actuel (sauf les entités principales concernées) sinon, cela va vitre être le foutoir...

[diengkals]

merci

Richard_35

voici ci-joint pour cette règle de gestion :

un élève peut passer un contrôle et un examen d’une matière enseigné dans une classe qu’ il est inscrit

[Richard_35]

Envoyé par Diengkals

un élève peut passer un contrôle et un examen d’une matière enseigné dans une classe qu’ il est inscrit

==> les règles de gestion (RG) sont incomplètes, sur cette dernière phrase :

• quels sont les attributs d'un contrôle ?
• quels sont les attributs d'un examen ?
• RG entre contrôle et matière (dans les deux sens) ?
• RG entre examen et matière (dans les deux sens) ?

[diengkals]

pour les attribues j aurai:
controle(id,libele_contorle, date_cotrole) par exemple controle (1,numero 1, 13/11/2012)

même chose l'examen


pour la RG entre contrôle et matière je voulais mettre un lien entre l entité matiere passer_controle et controle : ca va être:

controle 1,n -- passer_controle -- 1,n matière

la même chose entre examen et matière

[Richard_35]

Quelle est la différence entre contrôle et examen ?

[diengkals]

pour controle et examen y aura pas une grande différence par exemple pour le premier trimestre l élève aura un contrôle en novembre et et un examen en décembre la seule différence est que le contrôle compte 25% et l’examen 75% .

merci d'avance

[Richard_35]

Suggestions :
1 seule table :

Epreuve(IdEpreuve, Libelle, DateEpreuve, Pourcentage, ...)==> Pourcentage = 25, 75, ...

ou 2 tables :

TypeEpreuve(IdTypeEpreuve, Libelle, Pourcentage, ...)==> Libelle=Contrôle, Examen, ... ; Pourcentage = 25, 75, ...
Epreuve(IdEpreuve, #IdTypeEpreuve, LibelleEpreuve, ...)

Qu'en penses-tu ?

[diengkals]

merci bien je pense au deuxième.

dans ce cas comment je vais lié épreuve, matière et la classe que l'eleve est inscrit merci d'avance

[fsmrel]

Envoyé par Richard_35

Cela voudrait dire que, l'ensemble des "attributions" d'un professeur doit être inclus dans l'ensemble de ses "compétences".

Si « Attribution » a le sens de « Enseigner », on retrouve la contrainte d’inclusion.

Soit la contrainte est prise en considération dans les règles de gestion des données, soit elle ne l’est pas.

1) Si la contrainte n’est pas prise en considération, on en reste à la représentation (cf. mon message précédent) :

Qui donne lieu au MLD :



Concernant l’entité-type ANNEE du MCD :

Bien que l’année corresponde non pas à un véritable objet de gestion mais à un type (domaine), on est forcé de mettre en œuvre une pseudo entité-type ANNEE, afin que l'année participe à l’identification des associations-types.

On a jugé ici qu’au stade MLD (en fait SQL) une table ANNEE serait un boulet plus qu’autre chose : on a demandé à l’AGL de ne pas générer de table ANNEE lors de la production du MLD.

Conséquence des CIF MATIERE X CLASSE X ANNEE -> PROFESSEUR :

La clé de la table Enseigner est composée du triplet {ClasseId, MatiereId, Annee}.

2) Si la contrainte est prise en considération, on part sur la représentation (cf. mon message précédent) :


Alors le MLD correspondant est le suivant (une table en plus par rapport à l'autre) :

Envoyé par Richard_35

Si, en final, dans la base de données, nombre de "compétences" = nombre "d'attributions"

Bizarre. Ceci correspond non pas à une contrainte d’inclusion, mais à une contrainte d’égalité, chose dont la mise en œuvre n’a jamais été évoquée.

Quoi qu'il en soit, pour ma part je ne fais que des suggestions diverses et variées de modélisation, histoire de sortir du train-train ; diengkals a toute latitude pour définir le corpus des règles de gestion qu'il juge pertinentes et modéliser en conséquence.

Envoyé par diengkals

Pour ne pas trop alourdir mon application je dirais que ici on dit un professeur enseigne une matière c'est qu'il a des compétences dans cette matière mais je tiendrais en considération vos suggestion au cas je voudrais amélioré l'application.

Aucun problème, ça tient la route !

[Richard_35]

D'après ce que j'ai compris, une épreuve peut concerner plusieurs matières : ce schéma est-il correct ?

[fsmrel]

Envoyé par diengkals

dans mon cas j'ai que ces deux cas : Instituteur arabe et français :

je peux avoir un Instituteur qui est bilingue (arabe et français) donc il va jouer le rôle d'enseignant arabe et français.

D’accord. La contrainte de partitionnement se transforme don en contrainte de totalité (pas d’exclusive) :



MLD correspondant :



Observations

1) Cas de l’année :

Comme dans le cas des professeurs (cf. mon message précédent), on a jugé ici qu’au stade MLD une table ANNEE serait un boulet plus qu’autre chose : on a demandé à l’AGL de ne pas générer de table ANNEE lors de la production du MLD.

2) Conséquence des CIF CLASSE X ANNEE -> INSTITUTEUR :

La clé des tables Enseigner_en_arabe et Enseigner_en_français est seulement composée de la paire {ClasseId, Annee}.

3) Cas de la contrainte de totalité du MCD :

Au vu du MLD, un instituteur peut ne rien enseigner. 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...)