Discussion :

[beegees]

Bonjour tout le monde,

J'aimerais créer un MCD Professeurs, cours, étudiants.

Pour ce qui est du cours, j'ai donc une table cours, avec :

- Mnemonic (clé primaire)
- Intitutlé

Je bloques sur le fait que ce cours peut soit être théorique, pratique, ou les deux.

J'ai aussi trois genres de cours :

- Un cours suivi par un étudiant qui est en parcours normal, ça s'est le cas normal.
- Un cours suivi en cours isolé (s'est à dire qu'un étudiant prend de l'avance sur l'année prochaine en suivant des cours de l'année juste après).
- REUS sont des cours de l'année précédente qui doivent encore être passés et réussis par un étudiant, il est néanmoins dans l'année supérieure.

Je ne sais pas comment je peux schématiser ces cas.

Sauriez-vous m'aider svp ?

Je vous en remercie d'avance.

beegees

[fsmrel]

Bonjour Beegees,


Ça fait un moment que je ne vous avais pas vu.

Je bloque sur le fait que ce cours peut soit être théorique, pratique, ou les deux.

Puisqu’il s’agit d’une propriété du cours, vous définissez un attribut supplémentaire de l’entité-type COURS, par exemple CoursType, pouvant prendre les valeurs "théorique", "pratique", "théorique et pratique".

J'ai aussi trois genres de cours :
- Un cours suivi par un étudiant qui est en parcours normal, ça s'est le cas normal.
- Un cours suivi en cours isolé (s'est à dire qu'un étudiant prend de l'avance sur l'année prochaine en suivant des cours de l'année juste après).
- REUS sont des cours de l'année précédente qui doivent encore être passés et réussis par un étudiant, il est néanmoins dans l'année supérieure.

Considérons le schéma suivant :

[COURS]---1,N---(SUIVRE)---1,N---[ETUDIANT]

Vous ajoutez un attribut SuiviType dans l’association-type SUIVRE, et donc pour un étudiant et pour un cours donnés, vous aurez au choix une des trois valeurs : "normal", "isolé", "REUS".

[beegees]

Bonjour Beegees,


Ça fait un moment que je ne vous avais pas vu.


Puisqu’il s’agit d’une propriété du cours, vous définissez un attribut supplémentaire de l’entité-type COURS, par exemple CoursType, pouvant prendre les valeurs "théorique", "pratique", "théorique et pratique".



Considérons le schéma suivant :

[COURS]---1,N---(SUIVRE)---1,N---[ETUDIANT]

Vous ajoutez un attribut SuiviType dans l’association-type SUIVRE, et donc pour un étudiant et pour un cours donnés, vous aurez au choix une des trois valeurs : "normal", "isolé", "REUS".

Bonjour fsmrel,

Un tout grand merci pour votre réponse et pour l'accueil, ça fait toujours plaisir

S'est vrai que je ne suis plus venu depuis un moment car quand je venais sur cette partie du forum (merise) s'était pour mon cours d'analyse de première année.

Je suis maintenant en 3e et dernière année et je dois préparer mon travail de fin d'étude.

Pour cela, je dois utiliser Merise, vous allez donc me revoir assez souvent.

Merci pour votre réponse qui me semble très intéressante, vous me mettez sur une très bonne piste, je vais potasser tout ça et je reviens vous dire quoi (promis).

Encore merci pour tout.

beegees

[beegees]

Bonjour,

Comme promis, me voilà avec mon MCD.

Sauriez-vous y jeter un coup d'oeil svp ?

Voici plus d'info :

Le programme que je veux concevoir va permettre à des Professeurs d'encoder leurs cotes d'examen.

Il est important de savoir qu'un étudiant peut suivre un cours "Isolé", "REUS" ou "Normal".

Seules 0 à 20, abs et D pourront êtres encodés mais je ne pense pas que ça intervient dans le MCD.

J'aurais aussi aimé avoir une propriété qui indique depuis combien d'année l'étudiant à obtenu une certaine cote, je vous explique :

Un étudiant qui rate une année (après la seconde session) conserve les cotes = ou > à 12, on dit alors qu'il a une cote d'une année si il double une première fois, une cote de deux ans si il double deux fois, lors de son 2e essais, il a pu obtenir des 12 ou plus (raté l'année d'avant), ces cotes sont alors des cotes de première année....

Un étudiant ne peut conserver ses cotes que 5 années, après, il perd la cote.

Il y'aura donc une colonne supplémentaire pour indiquer depuis combien d'année une cote est reportée.

Merci d'avance pour votre aide très précieuse et très appréciée.

beegees

[fsmrel]

Bonjour Beegees,

Quelques observations.

Dictionnaire de données :

Votre dictionnaire des données ne fait que recenser les noms des données ; imaginez consulter le Larousse ou le Robert et n’y trouver que l’inventaire des mots de la langue française, sans aucune explication...

Pour chaque terme qu’il comporte, votre dictionnaire doit donc en donner la définition. Ainsi on saurait ce que veut dire Type_cours.

En outre, des exemples de valeurs doivent compléter la définition d’un terme (prenez par exemple le cas du terme Mnemonic_Cours). Ceci peut aider à mieux apprécier la pertinence du MCD.

Faites en sorte d’utiliser les mêmes noms dans le dictionnaire et dans la représentation graphique (on trouve par exemple Mnemonic_Cours dans le dictionnaire et MNEMONIC dans l’entité-type COURS).

Par ailleurs, votre dictionnaire est incomplet. Il manque les termes suivants, utilisés dans la représentation graphique, notamment :

ENCODE_COTE, CATEGORIE_COTE, NOM, AC, ...

Identification des entités-types :

Il est d’usage d’identifier les entités-types au moyen de propriétés artificielles, qui au niveau tabulaire feront l’objet de clés primaires dont les valeurs pourront être affectées par le SGBD (par exemple par incrémentation). Les systèmes externes à l’entreprise et les utilisateurs ne doivent pas être autorisés à changer ces valeurs. Par exemple, l’entité-type COURS doit être identifiée par une propriété artificielle nommée quelque chose comme CousrId ou Id_Cours ou approchant. La propriété MNEMONIC fait alors l’objet d’un identifiant alternatif (clé alternative au niveau tabulaire).

Tout ceci fait, on pourra commencer à commenter le MCD.

[beegees]

Bonjour Beegees,

Bonjour Fsmrel et merci sincèrement pour votre réponse rapide et constructive.

Quelques observations.

Dictionnaire de données :

Votre dictionnaire des données ne fait que recenser les noms des données ; imaginez consulter le Larousse ou le Robert et n’y trouver que l’inventaire des mots de la langue française, sans aucune explication...

Pour chaque terme qu’il comporte, votre dictionnaire doit donc en donner la définition. Ainsi on saurait ce que veut dire Type_cours.

J'ai ajouté une explications pour chaque terme de mon dictionnaire des données.

En outre, des exemples de valeurs doivent compléter la définition d’un terme (prenez par exemple le cas du terme Mnemonic_Cours). Ceci peut aider à mieux apprécier la pertinence du MCD.

Totalement raison, j'ai ajouté un exemple pour chaque terme.

Faites en sorte d’utiliser les mêmes noms dans le dictionnaire et dans la représentation graphique (on trouve par exemple Mnemonic_Cours dans le dictionnaire et MNEMONIC dans l’entité-type COURS).

J'ai corrigé.

Par ailleurs, votre dictionnaire est incomplet. Il manque les termes suivants, utilisés dans la représentation graphique, notamment :

ENCODE_COTE, CATEGORIE_COTE, NOM, AC, ...

Je ne savais pas que les propriétés devaient être reprises dans le DD, c'est maintenant fait. Notez que j'ai remplacé AC par AA (erreur de frappe)

Identification des entités-types :

Il est d’usage d’identifier les entités-types au moyen de propriétés artificielles, qui au niveau tabulaire feront l’objet de clés primaires dont les valeurs pourront être affectées par le SGBD (par exemple par incrémentation). Les systèmes externes à l’entreprise et les utilisateurs ne doivent pas être autorisés à changer ces valeurs. Par exemple, l’entité-type COURS doit être identifiée par une propriété artificielle nommée quelque chose comme CousrId ou Id_Cours ou approchant. La propriété MNEMONIC fait alors l’objet d’un identifiant alternatif (clé alternative au niveau tabulaire).

Je ne comprends pas bien ce que vous voulez dire par ceci.

Tout ceci fait, on pourra commencer à commenter le MCD.

Merci d'avance pour votre très aide très précieuse.

Je mets en attaché le MCD modifié ainsi que certaines explications complémentaires.

Infos complémentaires :

REUS :

REUS signifie Réussite partielle. Il permet à un étudiant qui a réussi au minimum 46 ECTS de cours de repasser le ou les cours qu'il a raté en 2e session tout en passant son année et en allant donc dans l'année supérieure. Lors de la délibération, l'étudiant sera délibéré sur le ou les cours qu'il aura raté dans l'année précédente, deux possibilités sont alors possibles :

1ère possibilité :

L'étudiant à réussi tous les cours qu'il devait repassé dans l'année inférieure (minium 10 sur 20), il peut alors être délibéré pour l'année dans laquelle il est.

2e possibilité :

L'étudiant rate un ou plusieurs cours qu'il devait repasser dans l'année inférieure, il est AUTOMATIQUEMENT ajourné pour l'année inférieure et n'est pas délibéré pour l'année dans laquelle il se trouve actuellement.
Il devra repasser l'examen de l'année inférieure pour être délibéré. Si il rate à nouveau, il est à nouveau ajourné et devra recommencer l'année académique supérieure et les cours qui devaient être repassés lors de l'année académique inférieure.

Si l'étudiant réussit en 2e session, le ou les cours de l'année inférieure, il peut être alors délibéré pour l'année supérieure.

L'exemple ci-dessous devrait être plus clair :

En délibération, les membres du Jury constate que l'étudiant Dupont Charles étant en BA2 a réussit tous les cours excepté le cours de Biochimie et de Chimie lors de son année académique 2006-2007.
Le nombre total d'ECTS réussit est supérieur ou égal à 46, il rentre donc dans les conditions du REUS.
Il va donc pouvoir passer en BA3 (année supérieure) MAIS va devoir repasser les cours de Biochimie et Chimie en BA2 (année inférieure).

Lors de la délibération de première session 2007-2008, le Jury constate que Charles Dupont a réussi le cours de Biochimie mais n'a pas réussi le cours de Chimie, il est donc d'office ajourné pour BA2 ET BA3, cela veut donc dire qu'il ne sera pas délibéré pour les examens passés en BA3.

Lors de la délibération de 2e session 2007-2008, le Jury constate que Dupont Charles a réussi le cours de Chimie, le Jury peut donc délibérer l'étudiant pour ses cours de BA3.

Note Importante :

Il n'y a PAS de REUS entre BA3 et MA1 (3e année de Bachelier et 1ère année de Master)

COURS ISOLES :

Contrairement à l'étudiant qui entre dans les conditions d'accès du REUS (minimum 46 ECTS réussis), l'étudiant BISSEUR qui prend un cours isolé est un étudiant qui à soit raté son année sans avoir réussi au minimum 46 ECTS de cours, soit un étudiant qui en plus des cours de son année actuelle prend un ou des cours de l'année d'après.

Dans le premier cas, l'étudiant doit souvent repasser 3 ou 4 cours, ce qui prend moins de temps. Pour s'avancer, il lui est possible de prendre un
ou plusieurs cours en avance dans l'année supérieure.
Le second cas est peu fréquent car un cursus normal demande beaucoup de temps, d'énergie, de volonté et de concentration.

Tous cours isolés réussi (Minimum 12/20) sont reportable d'année en année pendant MAXIMUM 5 ans.

Résumé :


Ajourné(e) --> 46 ECTS réussis --> REUS --> peut aller dans l'année supérieure mais devra repasser les cours
non réussis dans l'année inférieure
Ajourné(e) --> 46 ECTS non réussis --> Année ratée et à recommencée --> Cours isolés peuvent alors être pris

Merci encore.

beegees

[fsmrel]

Bonsoir Beegees,

Qu’est-ce qu’une côte ? A quoi correspond la tâche d’encoder une cote ? Quelle en est la finalité ?

A-t-on représenté sur le MCD tous les éléments permettant à un professeur d’encoder une cote, si cela est nécessaire ? Quels sont ces éléments ? Leurs relations ?

Si un seul professeur encode une cote, plutôt qu’utiliser un booléen qui pourra prendre plusieurs fois la valeur de vérité VRAI (au lieu d’une seule fois), mieux vaut établir une association-type dédiée entre PROFESSEUR et COURS.



En passant, il est d’usage de ne pas employer le pluriel pour les noms des entités-types, en l’occurrence il vaut mieux écrire PROFESSEUR plutôt que PROFESSEURS. En effet, vous modélisez une entité-type et en logique cela s’interprète comme un prédicat.

Vous évoquez des quantités d’ECTS. Un attribut ECTS ne devrait-il pas figurer sur le MCD (par exemple dans l’association-type SUIT (à moins qu’il n’y ait double emploi avec la cote y figurant ?))

Vous précisez qu’un étudiant peut être inscrit simultanément à des cours de type BAx et BAy. En fait, on a deux chemins pour "aller" de l’entité-type ETUDIANT à l’entité-type ANNEE :

En passant par COURS,
En prenant le chemin direct ETUDIANT - ANNEE.

Quelque part, il y a une redondance incitant à supprimer le chemin direct. Reste cependant à régler le sort de l’attribut AA (transformer l’association-type en propriété multivaluée (agrégat) ou définir un attribut dans l’entité-type représentant une des deux années académiques (la 2e étant égale à celle-ci + une année).

Identification des entités-types :

Il est d’usage d’identifier les entités-types au moyen de propriétés artificielles, qui au niveau tabulaire feront l’objet de clés primaires dont les valeurs pourront être affectées par le SGBD (par exemple par incrémentation). Les systèmes externes à l’entreprise et les utilisateurs ne doivent pas être autorisés à changer ces valeurs. Par exemple, l’entité-type COURS doit être identifiée par une propriété artificielle nommée quelque chose comme CousrId ou Id_Cours ou approchant. La propriété MNEMONIC fait alors l’objet d’un identifiant alternatif (clé alternative au niveau tabulaire).

Je ne comprends pas bien ce que vous voulez dire par ceci.

Pour un tas de raisons, un identifiant ne doit pas être porteur d’information et modifiable par l’utilisateur. Je cite un très grand spécialiste de la question, Yves Tabourier :

Une raison encore plus profonde pour laquelle l’identifiant « a l’aspect d’une propriété, mais n’est pas une propriété » est que la fonction d’une propriété est de décrire les objets (ou les rencontres), alors que l’identifiant ne décrit rien. Son rôle fondamental est d’être sûr de distinguer deux jumeaux parfaits, malgré des descriptions identiques. L’expérience montre d’ailleurs que l’usage des « identifiants significatifs » (ou « codes significatifs ») a pu provoquer des dégâts tellement coûteux que la sagesse est d’éviter avec le plus grand soin de construire des identifiants décrivant les objets... (Yves Tabourier, "De l’autre côté de Merise").

En ce sens, la définition de la table COURS au niveau SQL devrait avoir l’allure suivante (le nouvel identifiant CoursId faisant l’objet de la clé primaire de la table :

Code SQL :

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

1
2
3
4
5
6
7
8
 Create Table COURS (
      IdCours         Integer     
    , Mnemonic_Cours  Char(16)
    , Nom_Cours       Varchar(48) 
    , Type_Cours      Char(8)
   , Primary Key (CoursId)
   , Unique (Mnemonic_Cours)
) ;

Affaire à suivre...

[beegees]

Bonsoir Beegees,

Qu’est-ce qu’une côte ? A quoi correspond la tâche d’encoder une cote ? Quelle en est la finalité ?

Bonjour Fsmrel,

Merci beaucoup pour votre rapide réponse.

En ce qui concerne la définition de cote, A quoi correspond la tâche d'encoder une cote et Quelle en est la finalité, j'y ai répondu dans le nouveau MCD que je mets en copie, les changements sont en bleus, en haut dans le tableau.

A-t-on représenté sur le MCD tous les éléments permettant à un professeur d’encoder une cote, si cela est nécessaire ? Quels sont ces éléments ? Leurs relations ?

Une cote dépend d'un cours, d'une catégorie (théorie, travaux pratique) et d'un étudiant.

Donc Charles Dupont peut obtenir 18/20 pour la théorie du cours "TRAN-J-202".

C'est la théorie, maintenant il faut voir comment implémenter cela.

Sauriez-vous me dire avec quel programme vous avez dessinez cette partie de MCD ?

Si un seul professeur encode une cote, plutôt qu’utiliser un booléen qui pourra prendre plusieurs fois la valeur de vérité VRAI (au lieu d’une seule fois), mieux vaut établir une association-type dédiée entre PROFESSEUR et COURS.

Très bonne idée, merci

Mais quand je dis qu'un Professeur encode une cote, je veux dire qu'il encode les cotes du cours en entier, il encode donc toutes les cotes de PHAR-J-202 et pas la cote de Charles Dupont --> TRUE, Valérie Lemercier --> TRUE, Denis Bregnot --> FALSE...

Donc si un cours comprends trois titulaires :

- Prof. Gismow
- Prof. Spielberg
- Prof. King

Un aura "Encode-Cotes" à true et les deux autres à False

J'ai transformé le MCD, les changements sont en bleus également.

En passant, il est d’usage de ne pas employer le pluriel pour les noms des entités-types, en l’occurrence il vaut mieux écrire PROFESSEUR plutôt que PROFESSEURS. En effet, vous modélisez une entité-type et en logique cela s’interprète comme un prédicat.

Bonn à savoir, merci.

Vous évoquez des quantités d’ECTS. Un attribut ECTS ne devrait-il pas figurer sur le MCD (par exemple dans l’association-type SUIT (à moins qu’il n’y ait double emploi avec la cote y figurant ?))

Je n'utilise pas cette information (ECTS) car elle n'a aucune utilité dans le programme que je vais mettre sur pied.

Le programme permettra aux Professeurs d'encoder leur cotes via internet, la première étape est de créer une base de données avec une bonne analyse (ce que nous faisons actuellement).

Vous précisez qu’un étudiant peut être inscrit simultanément à des cours de type BAx et BAy. En fait, on a deux chemins pour "aller" de l’entité-type ETUDIANT à l’entité-type ANNEE :

En passant par COURS,
En prenant le chemin direct ETUDIANT - ANNEE.

Quelque part, il y a une redondance incitant à supprimer le chemin direct. Reste cependant à régler le sort de l’attribut AA (transformer l’association-type en propriété multivaluée (agrégat) ou définir un attribut dans l’entité-type représentant une des deux années académiques (la 2e étant égale à celle-ci + une année).

Exactement, un étudiant peut soit prendre des cours en avance dans une année supérieure ou terminer un ou plusieurs cours dans une année inférieure.

Vous suggérer donc de retirer la relation entre Etudiant et Annee, je suis pour, je vous fais 100% confiance. Pour ce qui est de AA (Année Académique) on pourrait le mettre comme une propriété, mais elle reviendra alors à chaque fois ?

Pour un tas de raisons, un identifiant ne doit pas être porteur d’information et modifiable par l’utilisateur.

L'ais-je fait quelque part ?

Je cite un très grand spécialiste de la question, Yves Tabourier :

Une raison encore plus profonde pour laquelle l’identifiant « a l’aspect d’une propriété, mais n’est pas une propriété » est que la fonction d’une propriété est de décrire les objets (ou les rencontres), alors que l’identifiant ne décrit rien. Son rôle fondamental est d’être sûr de distinguer deux jumeaux parfaits, malgré des descriptions identiques. L’expérience montre d’ailleurs que l’usage des « identifiants significatifs » (ou « codes significatifs ») a pu provoquer des dégâts tellement coûteux que la sagesse est d’éviter avec le plus grand soin de construire des identifiants décrivant les objets... (Yves Tabourier, "De l’autre côté de Merise").

En ce sens, la définition de la table COURS au niveau SQL devrait avoir l’allure suivante (le nouvel identifiant CoursId faisant l’objet de la clé primaire de la table :

Je présûme que idCours serait du genre 1,2,3... ?

Unique (Mnemonic_Cours) indique qu'il ne peut pas y avoir de doublon ?

Code SQL :

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

1
2
3
4
5
6
7
8
 Create Table COURS (
      IdCours         Integer     
    , Mnemonic_Cours  Char(16)
    , Nom_Cours       Varchar(48) 
    , Type_Cours      Char(8)
   , Primary Key (CoursId)
   , Unique (Mnemonic_Cours)
) ;

Affaire à suivre...

Je vous remercie encore une fois pour votre professionnalisme et pour le temps que vous me consacrez.

Je n'oublierai pas ce que vous avez fait pour moi.

beegees

[fsmrel]

Bonjour Beegees,

Sauriez-vous me dire avec quel programme vous avez dessinez cette partie de MCD ?

Il s’agit du logiciel de modélisation Power AMC. Mais il y a aussi l’excellent Win’Design pour réaliser tous types de modèles.

Je présûme que IdCours serait du genre 1,2,3... ?

Unique (Mnemonic_Cours) indique qu'il ne peut pas y avoir de doublon ?

C’est tout à fait cela. IdCours prend successivement les valeurs 1, 2, 3, etc. au fil de la création des cours. L’utilisateur pour sa part accède aux données d’un cours via Mnemonic_Cours. La clause UNIQUE est présente pour que le système interdise que deux cours distincts aient la même valeur de mnémonique.

quand je dis qu'un Professeur encode une cote, je veux dire qu'il encode les cotes du cours en entier, il encode donc toutes les cotes de PHAR-J-202 et pas la cote de Charles Dupont --> TRUE, Valérie Lemercier --> TRUE, Denis Bregnot --> FALSE...
Donc si un cours comprends trois titulaires :

- Prof. Gismow
- Prof. Spielberg
- Prof. King

Un aura "Encode-Cotes" à true et les deux autres à False

On est tout à fait d’accord qu’un professeur et un seul (disons Prof. King) encode les cotes d’un cours (disons PHAR-J-202). Mais il n’y aura pas d’attribut Encode-Cotes.

En effet, si l’on reprend le bout de MCD :




du fait de la cardinalité 1,1 portée par la patte connectant l’entité-type Cours et l’association-type Encoder, au niveau tabulaire on aura par exemple l’instantané suivant concernant le cours Tran-J-202 :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
Professeur (IdProf, MatriculeProf, NomProf, ...) 
              1       076481       Gismow     
              2       3141A6       Spielberg 
              3       ABC123       King 

Cours (IdCours, MnemonicCours,   IdProfEncodeur, ...) 
         1      Tran-J-202            3

Enseigner (IdCours,  IdProf)
             1          1
             1          2
             1          3

C’est l’attribut IdProfEncodeur de la table Cours qui se substitue au booléen. Et l’on voit bien sur cet instantané qu’il ne peut y avoir personne d’autre que le prof. King ayant pu encoder le cours Tran-J-202.

D'un point de vue booléen :

Le prof. Gismow a-t-il encodé le cours Tran-J-202 ? La réponse est : FAUX.
Le prof. King a-t-il encodé le cours Tran-J-202 ? La réponse est : VRAI.

Par ailleurs si une valeur devait être précisée pour la cote attribuée au cours, l’attribut correspondant figurerait dans l’en-tête (schéma) de l’entité-type Cours.

Vous précisez qu’un étudiant peut être inscrit simultanément à des cours de type BAx et BAy. En fait, on a deux chemins pour "aller" de l’entité-type ETUDIANT à l’entité-type ANNEE :

En passant par COURS,
En prenant le chemin direct ETUDIANT - ANNEE.

Quelque part, il y a une redondance incitant à supprimer le chemin direct. Reste cependant à régler le sort de l’attribut AA (transformer l’association-type en propriété multivaluée (agrégat) ou définir un attribut dans l’entité-type représentant une des deux années académiques (la 2e étant égale à celle-ci + une année).

Exactement, un étudiant peut soit prendre des cours en avance dans une année supérieure ou terminer un ou plusieurs cours dans une année inférieure.

Vous suggérer donc de retirer la relation entre Etudiant et Annee, je suis pour, je vous fais 100% confiance. Pour ce qui est de AA (Année Académique) on pourrait le mettre comme une propriété, mais elle reviendra alors à chaque fois ?

Limitez vous à 80%... Réflexion faite, il est préférable, au moins à ce stade, de conserver l’association-type Se trouve en, car elle si elle est cause de redondance, elle permet néanmoins d’engranger le fait que, par exemple, pour le couple <Léon, BA2>, l’année académique est 2007-2008 et que pour le couple <Léon, BA1>, l’année académique est 2006-2007, ce que l’on ne peut pas déduire avec ce que j’ai proposé. En revanche, du fait de l’association-type Se trouve en, rien n’interdit que Léon suive des cours dont aucun ne correspond à BA2, ce sur quoi j’attirais l’attention. En l’occurrence, pour éviter des anomalies liées à la redondance des chemins, au niveau SQL, il faudra prévoir un trigger pour assurer la cohérence.

Bon courage à vous...

[beegees]

Bonjour Beegees,

Il s’agit du logiciel de modélisation Power AMC. Mais il y a aussi l’excellent Win’Design pour réaliser tous types de modèles.

Bonjour Fsmrel,

Un tout GRAND merci pour votre réponse qui me permet d'avancer dans mon MCD.

Merci aussi pour l'info sur le programme "PowerAMC", j'ai téléchargé une version d'évaluation (11) et je l'ai donc pour 15 jours.

Connaissez-vous le prix d'une licence ? C'est juste pour terminer mes études, je n'en aurai plus besoin après.

C’est tout à fait cela. IdCours prend successivement les valeurs 1, 2, 3, etc. au fil de la création des cours. L’utilisateur pour sa part accède aux données d’un cours via Mnemonic_Cours. La clause UNIQUE est présente pour que le système interdise que deux cours distincts aient la même valeur de mnémonique.

Avec PowerAMC, sauriez-vous me dire quel type de donnée est-ce 1,2,3... est-ce Séquentiel ?

On est tout à fait d’accord qu’un professeur et un seul (disons Prof. King) encode les cotes d’un cours (disons PHAR-J-202). Mais il n’y aura pas d’attribut Encode-Cotes.

En effet, si l’on reprend le bout de MCD :




du fait de la cardinalité 1,1 portée par la patte connectant l’entité-type Cours et l’association-type Encoder, au niveau tabulaire on aura par exemple l’instantané suivant concernant le cours Tran-J-202 :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
Professeur (IdProf, MatriculeProf, NomProf, ...) 
              1       076481       Gismow     
              2       3141A6       Spielberg 
              3       ABC123       King 

Cours (IdCours, MnemonicCours,   IdProfEncodeur, ...) 
         1      Tran-J-202            3

Enseigner (IdCours,  IdProf)
             1          1
             1          2
             1          3

C’est l’attribut IdProfEncodeur de la table Cours qui se substitue au booléen. Et l’on voit bien sur cet instantané qu’il ne peut y avoir personne d’autre que le prof. King ayant pu encoder le cours Tran-J-202.

Intéressant, merci, comment fait-on cela avec PowerAMC ?
D'un point de vue booléen :

Le prof. Gismow a-t-il encodé le cours Tran-J-202 ? La réponse est : FAUX.
Le prof. King a-t-il encodé le cours Tran-J-202 ? La réponse est : VRAI.

Par ailleurs si une valeur devait être précisée pour la cote attribuée au cours, l’attribut correspondant figurerait dans l’en-tête (schéma) de l’entité-type Cours.

Avec POWERAMC 11, j'ai l'association "Encoder_Cote", dois-je y mettre un attribut ? j'avais pensé mettre "Id_Prof" dans l'attribut, est-ce correct ?

Si je fais cela, le programme me donne un avertissement en me disant que Id_Prof est utilisé plusieurs fois.

J'ai ajouté une table "Cote" avec comme attribut "Categorie" qui indique si c'est une cote théorique ou pratique (travaux pratique).

En faisant F4 pour tester le MCD, j'ai ce message d'avertissement :

Circularité formée de liens obligatoires

Limitez vous à 80%... Réflexion faite, il est préférable, au moins à ce stade, de conserver l’association-type Se trouve en, car elle si elle est cause de redondance, elle permet néanmoins d’engranger le fait que, par exemple, pour le couple <Léon, BA2>, l’année académique est 2007-2008 et que pour le couple <Léon, BA1>, l’année académique est 2006-2007, ce que l’on ne peut pas déduire avec ce que j’ai proposé. En revanche, du fait de l’association-type Se trouve en, rien n’interdit que Léon suive des cours dont aucun ne correspond à BA2, ce sur quoi j’attirais l’attention. En l’occurrence, pour éviter des anomalies liées à la redondance des chemins, au niveau SQL, il faudra prévoir un trigger pour assurer la cohérence.

Bon courage à vous...

Encore un tout grand merci pour tout, je vais inclure dans quelques heures le MCD issus du programme PowerAMC 11, il sera bien plus claire.

Bon Dimanche à vous.

beegees

[fsmrel]

Bonsoir Beegees,

Connaissez-vous le prix d'une licence ? C'est juste pour terminer mes études, je n'en aurai plus besoin après.

Uniquement pour le module données (celui qui vous concerne) : pas loin de 3000 euros...
http://www.pc21.fr/marque/promotions_sybase.html

Vous pouvez éventuellement vous rabattre sur un logiciel gratuit, MySQL Workbench, avec lequel on ne fait pas des MCD Merise, mais directement des MLD orientés SQL :
http://dev.mysql.com/downloads/workbench/5.0.html

A titre d’exemple, voilà ce que donne la partie Professeurs - Cours




Selon cette représentation graphique, on ne parle pas d’identifiant mais directement de clés primaires (petit mickey doré à gauche du nom, IdProf par exemple).
Un petit losange bleu à gauche d’un nom d’attribut signifie que celui-ci n’a rien de particulier.
Un petit losange mauve à gauche d’un nom d’attribut signifie que celui-ci participe une clé étrangère.
Le terme Indexes n’a rien à faire ici, car les index sont du niveau physique alors qu’ion est au niveau logique.
Le lien Encoder est en pointillés car IdProfEncodeur participe à la clé étrangère, mais ne participe pas à la clé primaire de Cours.
Les autres liens sont en trait continu parce que les attributs IdProf et IdCours participent aux clés étrangères, mais aussi à la clé primaire de la table Enseigner.

C’est tout à fait cela. IdCours prend successivement les valeurs 1, 2, 3, etc. au fil de la création des cours. L’utilisateur pour sa part accède aux données d’un cours via Mnemonic_Cours. La clause UNIQUE est présente pour que le système interdise que deux cours distincts aient la même valeur de mnémonique.

Avec PowerAMC, sauriez-vous me dire quel type de donnée est-ce 1,2,3... est-ce Séquentiel ?

Vous pouvez déjà parcourir le message :
http://www.developpez.net/forums/d58...o-incrementee/

Intéressant, merci, comment fait-on cela avec PowerAMC ?

Vous parlez de ce qui précède votre question ? De ce qui la suit ?

Avec POWERAMC 11, j'ai l'association "Encoder_Cote", dois-je y mettre un attribut ? j'avais pensé mettre "Id_Prof" dans l'attribut, est-ce correct ?

Si je fais cela, le programme me donne un avertissement en me disant que Id_Prof est utilisé plusieurs fois.

Au niveau conceptuel, hors de question d’ajouter l’attribut Id_Prof en tant qu’attribut dans l’association. Il est là en puissance, et lors de la production du modèle logique, c’est Power AMC qui l’ajoutera dans la table Cours en tant que clé étrangère, à l’image ce que l’on a fait avec Workbench.

En faisant F4 pour tester le MCD, j'ai ce message d'avertissement :


Circularité formée de liens obligatoires

C’est juste un warning, en l’occurrence ça n’est pas grave.

En connaissant le nom de l'étudiant, le cours, sa catégorie (TH OU TP), sa catégorie (REUS, CI, Cours à option, Normal) et l'année académique, on connaît quelle est la cote de l'étudiant. Est-ce correcte ?

Non, car dans votre dernier MCD, où voyez-vous que l’on connaît la catégorie de l’étudiant, etc. ?

Le MCD est à revoir, notamment du côté Etudiant - Cote.

[beegees]

Bonsoir fsmrel,

Désolé de vous déranger à nouveau

Le MCD est à revoir, notamment du côté Etudiant - Cote.
Hier 12h48

Je pense "Categorie" et "Type" devraient être des informations hors de la table cours.

Pour rappel :

Type :

TH ou TP

Catégorie :

REUS
CI
Normal
Cours à options
Mémoire

Mais je me pose une première question :

Quelles cardinalités dois-je utiliser pour ces deux tables ?

1 cours peut être d'un type et un type peut correspondre à plusieurs cours ?

Alors on aurait 1:1--------------------1,N

Il faudrait que cette information soit liée à un étudiant bien précis.

Pour Charlie, le cours TRAN-J-202 TH est un CI par contre pour Nadia c'est un cours normal.

C'est faisable ceci ?

Merci pour tout.

beegees

[beegees]

Rebonjour fsmrel,

Voilà, je viens de refaire mon MCD.

Je n'ai pas touché à ce que nous avons fait ensemble, c'est-à-dire Professeur encode et Professeur enseigne.

J'ai par contre retouché tout ce qui était étudiant et note.

Sauriez-vous svp y jeter un coup d'oeil ?

Vous êtes mon dernier espoir

Je tiens à vous dire encore un grand pour votre aide.

beegees

[fsmrel]

Bonjour Beegees,

Concernant la règle de gestion RG9 :
"Si le cours est enseigné par plusieurs Professeurs, seul l'un d'entre eux pourra encoder les cotes du cours (boolean)"

a) Le type des données n’a pas à figurer dans les règles de gestion : le mot "boolean" doit disparaître.

b) La patte liant L’entité-type COURS et l’association-type ENCODER_COTE est porteuse d’une cardinalité maximale 1. Comme je vous l’ai déjà expliqué — avec au niveau du MLD, le contenu des tables et les requêtes SQL à la clé — on sait qui a encodé un cours, en conséquence de quoi l’attribut Cloturer figurant dans l’association-type ENCODER_COTE ne fera que répéter ce que l’on sait déjà : c’est une redondance et cet attribut doit disparaître.

Concernant l’association-type OBTIENT_NOTE :

La patte liant L’entité-type COURS et l’association-type OBTIENT_NOTE est porteuse d’une cardinalité maximale 1 : N serait plus pertinent, sinon cela veut dire que pour un cours donné, un seul élève peut être noté...

Même remarque concernant la patte liant L’entité-type CATEGORIE_COURS et l’association-type OBTIENT_NOTE.

En supposant que vous ayez procédé à ces ajustements, on peut interpréter cette association. En effet, son prédicat est le suivant :

Pour le cours (ayant pour mnémonique) Mnemonic, dans la catégorie Id_Categorie, l’étudiant (ayant pour matricule) Matricule_Et a obtenu la note Note et a choisi le type de cours Type_Cours.

Exemple de propositions (vraies simultanément) correspondant à ce prédicat :

Pour le cours Tran-J-202, dans la catégorie TH, l’étudiant 007 a obtenu la note 12 et choisi le type de cours Normal
Pour le cours Tran-J-202, dans la catégorie TP, l’étudiant 007 a obtenu la note 14 et choisi le type de cours Normal
Pour le cours Tran-J-202, dans la catégorie TP, l’étudiant 123 a obtenu la note 14 et choisi le type de cours Isolé

Mais votre règle de gestion RG4 donne lieu à un prédicat différent, ce qui est gênant...

Mais vous avez aussi écrit :

Pour Charlie, le cours TRAN-J-202 TH est un CI par contre pour Nadia c'est un cours normal.

Il faudrait donc reformuler la règle de gestion.

J'attends vos corrections du MCD et autres aménagements.

[fsmrel]

Bonsoir Beegees,


Avec vos messages qui fusent de partout, je ne sais plus très bien où nous en sommes. On repart sur la base de mon message du 19/08/2008, 17h53, forum Merise. Évitez les autres forums, car à tout mélanger, avec des MCD et MLD qui ne se correspondent pas, vous me faites tourner en bourrique.


Bon courage.

[beegees]

Bonsoir Beegees,


Avec vos messages qui fusent de partout, je ne sais plus très bien où nous en sommes. On repart sur la base de mon message du 19/08/2008, 17h53, forum Merise. Évitez les autres forums, car à tout mélanger, avec des MCD et MLD qui ne se correspondent pas, vous me faites tourner en bourrique.


Bon courage.

Bonjour Fsmrel,

Merci pour vos réponses.

Vraiment désolé pour la confusion mais c'est surtout la base de données access que je voulais faire vérifier (domaine non repris ici dans la partie Merise).

Je réponds tout de suite au message du 19/08 (dont je n'ai pas reçu de notification de réponse et c'est pourquoi je n'ai pas répondu).

Merci pour votre dévouement sans faille.

beegees

[beegees]

Bonjour Beegees,

Bonjour Fsmrel,

Désolé sincèrement pour le retard de ma réponse, je n'ai pas reçu de notification de réponse, la seule que j'ai reçu, est celle de la réponse d'aujourd'hui à minuit et quelque et merci pour votre réponse.

Concernant la règle de gestion RG9 :
"Si le cours est enseigné par plusieurs Professeurs, seul l'un d'entre eux pourra encoder les cotes du cours (boolean)"

a) Le type des données n’a pas à figurer dans les règles de gestion : le mot "boolean" doit disparaître.

b) La patte liant L’entité-type COURS et l’association-type ENCODER_COTE est porteuse d’une cardinalité maximale 1. Comme je vous l’ai déjà expliqué — avec au niveau du MLD, le contenu des tables et les requêtes SQL à la clé — on sait qui a encodé un cours, en conséquence de quoi l’attribut Cloturer figurant dans l’association-type ENCODER_COTE ne fera que répéter ce que l’on sait déjà : c’est une redondance et cet attribut doit disparaître.

OK j'ai fais ce que vous m'avez conseillé, c'est un très bon conseil, merci.

Concernant l’association-type OBTIENT_NOTE :

La patte liant L’entité-type COURS et l’association-type OBTIENT_NOTE est porteuse d’une cardinalité maximale 1 : N serait plus pertinent, sinon cela veut dire que pour un cours donné, un seul élève peut être noté...

OK j'ai modifié, je vais générer le MPD et je vais le mettre en attaché.

Même remarque concernant la patte liant L’entité-type CATEGORIE_COURS et l’association-type OBTIENT_NOTE.

Là par contre, j'hésite entre deux cardinalité, j'ai changé celle la plus à droite, j'espère que c'est la bonne.

En supposant que vous ayez procédé à ces ajustements, on peut interpréter cette association. En effet, son prédicat est le suivant :

Pour le cours (ayant pour mnémonique) Mnemonic, dans la catégorie Id_Categorie, l’étudiant (ayant pour matricule) Matricule_Et a obtenu la note Note et a choisi le type de cours Type_Cours.

Exemple de propositions (vraies simultanément) correspondant à ce prédicat :

Pour le cours Tran-J-202, dans la catégorie TH, l’étudiant 007 a obtenu la note 12 et choisi le type de cours Normal
Pour le cours Tran-J-202, dans la catégorie TP, l’étudiant 007 a obtenu la note 14 et choisi le type de cours Normal
Pour le cours Tran-J-202, dans la catégorie TP, l’étudiant 123 a obtenu la note 14 et choisi le type de cours Isolé

C'est exactement ce qu'il me faut.

Mais votre règle de gestion RG4 donne lieu à un prédicat différent, ce qui est gênant...

Mais vous avez aussi écrit :

Il faudrait donc reformuler la règle de gestion.

N'en tenez pas compte pour l'instant, dès que j'aurai bien compris mon MCD, j'adapterai mes règles de gestions.

J'attends vos corrections du MCD et autres aménagements.

J'ai fais la majeure partie des changements, mais quelque chose m'inquiète :

Maintenant que j'ai 1,n entre Etudiants et Notes, j'ai une table supplémentaire qui contient :

Id_notes - Categorie

Je me vois mal mettre pour chaque cote quelle est la catégorie (normal, REUS...)

Est-ce une bonne idée d'avoir une entité cote ? ça ne devrais pas être un attribut de l'association "Obtient_Note" ?

Qu'en pensez-vous ?

merci pour TOUT.

beegees

PS: voici le tout nouveau MCD et MPD

[fsmrel]

Bonjour Beegees,

Tant que le MCD ne sera pas stabilisé, ne transmettez plus le MLD, on le regardera plus tard.

Concernant l’association-type OBTIENT_NOTE :

La patte liant L’entité-type COURS et l’association-type OBTIENT_NOTE est porteuse d’une cardinalité maximale 1 : N serait plus pertinent, sinon cela veut dire que pour un cours donné, un seul élève peut être noté...

OK j'ai modifié, je vais générer le MPD et je vais le mettre en attaché.

Bien.

Même remarque concernant la patte liant L’entité-type CATEGORIE_COURS et l’association-type OBTIENT_NOTE.

Là par contre, j'hésite entre deux cardinalité, j'ai changé celle la plus à droite, j'espère que c'est la bonne.

Ce qui est gênant, c’est que vous ne devriez plus hésiter...
Voyez mes commentaires plus loin à ce sujet.

En supposant que vous ayez procédé à ces ajustements, on peut interpréter cette association. En effet, son prédicat est le suivant :

Pour le cours (ayant pour mnémonique) Mnemonic, dans la catégorie Id_Categorie, l’étudiant (ayant pour matricule) Matricule_Et a obtenu la note Note et a choisi le type de cours Type_Cours.

Exemple de propositions (vraies simultanément) correspondant à ce prédicat :

Pour le cours Tran-J-202, dans la catégorie TH, l’étudiant 007 a obtenu la note 12 et choisi le type de cours Normal
Pour le cours Tran-J-202, dans la catégorie TP, l’étudiant 007 a obtenu la note 14 et choisi le type de cours Normal
Pour le cours Tran-J-202, dans la catégorie TP, l’étudiant 123 a obtenu la note 14 et choisi le type de cours Isolé

C'est exactement ce qu'il me faut.

Puisque c’est exactement ce qu’il vous faut, vérifions si votre MCD est en phase.

Le prédicat que j’ai proposé est issu de la représentation suivante :



Je fais observer en passant que l’attribution d’une note est anonyme, en ce sens que l’on ne sait pas quel est le professeur qui a attribué la note à l’étudiant. Est-ce normal ?


Considérons maintenant l’association-type CORRESPOND_A. Elle est le lieu de rencontre des cours et des notes et se lit ainsi :

A un cours peuvent correspondre plusieurs notes
A une note peuvent correspondre plusieurs cours.

Exemple :

Au cours Tran-J-202 peut correspondre la note 0
Au cours Tran-J-202 peut correspondre la note 1
...
Au cours Xyzt-K-303 peut correspondre la note 0
Au cours Xyzt-K-303 peut correspondre la note 1
...
Etc.

=> Je ne vois pas trop l’utilité de cette association-type...


Au tour de l’association-type CAT :

A la catégorie TH peut correspondre la note 0
A la catégorie TH peut correspondre la note 1
...
A la catégorie TP peut correspondre la note 0
A la catégorie TP peut correspondre la note 1
...
Etc.

=> Là encore je ne vois pas trop l’utilité de cette association-type...


Au tour de votre association-type OBTIENT_NOTE :

Tout d’abord, la patte connectant l’entité-type NOTES et l’association-type OBTIENT_NOTE est 1,1 : cela veut dire qu’une note donnée (par exemple 12) ne peut êtres obtenue que par un seul étudiant, c'est-à-dire que si l’étudiant beegees a obtenu la note 12, l’étudiant fsmrel ne pourra pas obtenir cette note 12. Autrement dit, la cardinalité maximale 1 doit être remplacée par N.

Quant à la cardinalité minimale, disons qu’elle est 0 plutôt que 1, sinon vous injectez la règle suivante : toute note doit être obtenue par au moins un étudiant.


Qu’en est-il de la règle RG11 ? vous y parlez de cotes qui ne figurent pas dans votre MCD.

Plus généralement les énoncés des règles sont de moins en moins en phase avec le MCD (cf. par exemple RG4) : il est impératif que la cohérence soit (r)établie. Sinon, cela veut dire que vous n’arrivez pas à réaliser l’adéquation MCD/règles mais il faut à tout prix que vous y arriviez...

Rédigez des exemples comme je l’ai fait, cela vous sera très utile, rien de tel que le concret pour s'assurer de la petinence de ce que l'on modélise. Pour le moment, le compte n'y est pas...

Allez, courage.

[beegees]

Bonjour Fsmrel,

Un tout grand merci pour vos messages qui m'aident beaucoup.

J'ai jamais vue quelqu'un avec une telle patience.

Ce schéma



doit bien être lu de cette façon ? :

Un professeur enseigne un à plusieurs cours
Un cours peut être enseigné par un à plusieurs professeurs

Un Professeur encode 1 à Plusieurs cours
Un cours est encodé par 1 seul Professeur

Je fais observer en passant que l’attribution d’une note est anonyme, en ce sens que l’on ne sait pas quel est le professeur qui a attribué la note à l’étudiant. Est-ce normal ?

Il faudrait que le Professeur qui attribue la cote (qui encode) soit désigné, je pense que dans mon MCD actuel, c'est le cas vue que "Cours" a une association "Enseigner" (qui est indispensable car même si un Prof n'encode pas un cours dont il est co-titulaire, il a le droit d'aller jeter un coup d'oeil sur les cotes encodées).

Votre morceau de MCD m'a tellement plu que j'ai transformé le mien pour qu'il ressemble au vôtre.

La seule petite chose et ça je pense que c'est mieux qui a mélangé les pinceaux :

Type : Th (théorie) TP (Travaux Pratiques)

Catégorie : Régulier (anciennement normal), REUS, CI (Cours isolé), CAO (Cours à option) et Mémoire.

Et en tapant ces lignes, je pense à quelque chose d'important :

Une cote ne pourra pas être numérique car :

- On pourra encoder des cotes de 0 à 20 mais aussi "ABS" ou "OUI" et "NON" pour les stages.

D'ailleurs, en parlant de stage, je devrai ajouter dans "Catégorie" une option stage.

Je penses donc que le type "Texte" sera plus adapté aux cotes, qu'en pensez-vous ?

Voilà, suivant vos conseils, j'ai retravaillé le MCD, il est bien plus "léger" maintenant.

Encore merci pour votre aide très appréciée et ô combien précieuse.

beegees

Edit: Afin de ne pas créer un nouveau message, j'indique la continuité du message ici :

Chèr(e) Fsmrel,

J'ai pris un peu d'avance...

J'ai créé grâce au programme le MPD et la base de données Access afin de voir à quoi ça allait ressembler et... je n'ai jamais eu une base de données aussi bien faite



Bon, ce n'est pas encore tout à fait fini mais nous sommes sur le bon chemin.

La table "Cours" reprend chaque cours UNE seule fois chaque cours, ce qui permet d'être sûr qu'on a bien le professeur qui encode.

C'est donc génial

La première partie du MCD est donc pour moi terminée, je ne sais pas ce que vous en pensez, j'attends en tout cas votre accord pour dire que la première partie du MCD est terminée.

Il y'aura quelque chose dont je devrais parler dans le MCD, les reports.

En fait, après la seconde session, si un étudiant rate son année et qu'il se réinscrit comme étudiant dans l'année qu'il a raté, il garde toutes les notes égales ou supérieures à 12.

Il faut donc que ces cotes apparaissent.

Pour cela, ma première idée serait de "dater" les cotes.

Je m'explique :

- Une cote de zéro année est une cote pour un examen qu'on passe pour la première fois (ou la deuxième fois en 2e session).
- Une cote d'une année est une cote réussie lors de l'année académique précédente, cette cote doit donc apparaitre et l'étudiant ne doit donc plus passer l'examen.

ça, c'est la théorie, maintenant, je vais réfléchir comment mettre cela à jour et je vous dis quoi.

Edit: Il y'a quelques choses d'important que j'ai oublié de prendre en compte, un cours peut être clôturé, c'est-à-dire que lorsque le Professeur a terminé d'encoder ses cotes, il doit avoir la possibilité de clôturer le cours pour imprimer les cotes et les remettre au secrétariat.

J'ai donc pensé à mettre "Clôturé" dans l'association "ENCODER_COTE", le 1:1 va me permettre d'ajouter une colonne "Clôturé" dans la table "Cours". ça sera un boolean, il est soit non clôturé (false) ou clôturé (true). Qu'en pensez-vous. Voir le MCD mise à jour.

Encore un tout grand et sincère pour votre aide.

beegees

[fsmrel]

Bonjour Beegees

Ce schéma




doit bien être lu de cette façon ? :

Un professeur enseigne un à plusieurs cours
Un cours peut être enseigné par un à plusieurs professeurs
Un Professeur encode 1 à Plusieurs cours
Un cours est encodé par 1 seul Professeur

L’association-type Encoder a disparu...

Quand vous écrivez "Un professeur enseigne un à plusieurs cours", vous signifiez qu’un professeur enseigne au moins un cours, ce qui est correct. La cardinalité minimale 1 est conforme à ce que vous avez écrit.

Quand vous écrivez "Un cours peut être enseigné par un à plusieurs professeurs", vous signifiez qu’un cours n’est pas forcément enseigné. De deux choses l’une :

_ De fait, un cours peut ne pas être enseigné, mais alors la cardinalité 1,N (côté Cours) devient 0,N.

_ Ou bien, un cours est enseigné par au moins un professeur, conformément à la cardinalité 1,N que vous avez représentée mais alors la règle de gestion s'énonce : "Un cours est enseigné par au moins un professeur", le "peut être" doit disparaître.

Quand vous écrivez "Un Professeur encode 1 à Plusieurs cours", cela veut dire que chaque professeur encode au moins un cours. Si ce n’est pas le cas de tous les professeurs, écrivez "Un professeur peut encoder des cours" et remplacez la cardinalité 1,N par 0,N.

Je fais observer en passant que l’attribution d’une note est anonyme, en ce sens que l’on ne sait pas quel est le professeur qui a attribué la note à l’étudiant. Est-ce normal ?

Il faudrait que le Professeur qui attribue la cote (qui encode) soit désigné, je pense que dans mon MCD actuel, c'est le cas vue que "Cours" a une association "Enseigner" (qui est indispensable car même si un Prof n'encode pas un cours dont il est co-titulaire, il a le droit d'aller jeter un coup d'oeil sur les cotes encodées).

Je n’ai pas tout saisi. Qu'entendez-vous par "désigné" ?
Peu importe. Sachant que les professeurs King, Gismow et Spielberg enseignent le cours Tran-J-202 et que c’est le professeur King qui a encodé ce cours, je pose la question :
En sa qualité d’encodeur du cours, seul le professeur King est-il habilité à attribuer une note à l’étudiant Tintin pour le cours Tran-J-202 ? Ou bien n'importe lequel des trois est-il habilité à le faire ?

Une cote ne pourra pas être numérique car :
- On pourra encoder des cotes de 0 à 20 mais aussi "ABS" ou "OUI" et "NON" pour les stages.

Que signifient chacune des valeurs "ABS", "OUI", "NON", autrement dit dans quelles conditions ces valeurs se substituent-elles à une cote comprise entre 0 et 20 ?

Il y'aura quelque chose dont je devrais parler dans le MCD, les reports.

On verra cela quand ce qui précède sera d’équerre et que vous aurez reformulé en conséquence chaque règle de gestion. On ne construit que sur des bases saines.


En passant : Félicitations à Tia Hellebaut.