Discussion :

[prosciuto]

Bonjour, tout d'abord, je ne suis pas sur d'être au bon endroit donc je remercie par avance l'admin qui pourra placer mon sujet ou il faut.

La problématique:
Créer le site web d'une université multi-site qui pourra gérer:
-les personnes : les directeurs, les profs, les intervenants extérieurs et les éleves
-les plannings d'une personne(cité ci-dessus), d'une sale, d'un site, de l'université entière
-les notes par matière d'une personne
-les droits des personnes (par exemple, un élève ne pourra pas modifier un planning alors que les directeurs si.

Mon MLD


Les problèmes
Deux problèmes se posent...
1-Les personnes : nous avons définie que dans ce problème, les personnes sont obligatoirements définie par une matières, en effet à partir du moment ou une personne est accepté à l'université, elle est inscrite dans une promotions (ensemble de matière)
un étudiant est inscrit à une promotions, donc se retrouve lié a une matière
un prof n'est pas lié à une promotion, cependant il est forcément assigné a une matière (sinon il n'est pas prof)
un intervenant extérieur suit le même procédé
c'est pourquoi j'ai une liaison n/n entre matière et personne
Cependant, un directeur n'a pas de promotion, ou matière, ou autre, il a juste un site, ou un cursus suivant sont rang.
J'ai donc créer une deuxième relation entre personne et site, est-ce correct ?
N'y a-t-il pas d'autre moyen plus simple de concevoir ceci?

2-Les Plannings : les plannings sont applicable à n'importe quelle entité (ou presque) de mon MLD, c'est pourquoi j'ai utilisé la table "évènements": elle est reliée à tout, et un planning est un ensemble d'évènement.
Est-ce correct là aussi ? Si je suis ce principe, la création d'un planning sera faite directement par les requêtes SQL, aucunes table ne conserve les plannings. est-ce correct ?

Enfin, les auriez vous des termes plus adéquats pour mes tables, je trouve que matière n'est pas très représentatif d'un ensemble de personne par exemple.

Merci par avance

Prosciuto

Définitions des entités de mon MCD:
L'université :

Regroupe plusieurs sites.
Elle à un directeur, une direction

Les sites :

Ensemble de cursus
A un ou plusieurs directeurs local

Les cursus :

Ensemble de promotions
Durée de cursus
Exemple : filière mathématique en 2 ans

Les promotions :

Ensemble de matières
Ensemble d'étudiants
Exemple : 1ère année Fac de Lettre

Matières :

Ensemble de personnes : prof ou intervenant extérieur et élèves

Personnes :

Tous les utilisateurs du sites, et toutes entitées sensé y être représentés : directeurs / profs / intervenants extérieurs / maitre de meeting / élèves / ...

Roles :

Roles des personnes : Directeurs, Élève ect..

Droits :

Droits des utilisateurs en fonction de chaque roles
Exemple : le président du cursus peut éditer un emploi du temps alors que les élèves n'ont pas le droit.

Salles :

Pièce ou se déroule les cours, les réunions, les meetings (peut éventuellement être le couloir)

Évènements :

c'est un cours, un rassemblement ect. , un évènement, il est définie par les personnes qui l'organise, les personnes invitées/conviées la date à laquelle il se déroule, son lieu (la salle)

Planning :

Emploi du temps d'une personne, d'une promotion, d'un cursus, d'un site, de l'universitée, d'une salle

[olivier.demey]

Salut prosciuto

Voici quelques idées d'amélioration...

- Je changerais le terme "site" en "département"; le mot "site" a (à mon sens) une connotation trop géographique
- je ne relierais pas la "salle" au "site", sauf si la salle dépends exclusivement d'un site. si la salle est le lieu d'un cours, j'imagine que les différents départements de l'unif pourront également y donner cours; donc laisse ton modèle ouvert à ce niveau-là
- je suis d'accord pour le planning : il ne fait que représenter des évenements (des cours, des occupations de salle, etc...)
- pour moi, les "notes" d'un étudiant, doivent être rattachées à l'association entre "personne" (qui joue un rôle "étudiant") et une "matière" (en UML, une classe associative)
- je ferais un lien entre "personne" et "promotion" :un étudiant fait partie d'une promotion
- un lien entre "promotion" et "cursus" : une promotion peut suivre différents cursus
- l'étudiant qui fait partie d'une promotion doit choisir un cursus
- le cursus est composé de plusieurs matières
- je pense que tu dois gérer les périodes de validité ou d'application des concepts : par exemple une matière est donnée pendant une période (année 2010, premier quadrimestre 2012, ...) :
- attention à la multiplicité de "étudiant" et "cursus" (ou "matière", dans ton cas) : si tu forces un étudiant à être inscrit à un cursus, alors il ne pourra jamais y avoir, dans ton système d'information, d'étudiant qui n'est pas inscrit ! Quid lorsque tu encodes quelqu'un avant son choix ? Quid lorsqu'un étudiant ne fait plus partie de la fac ? Il vaut mieux gérer des règles qui seront appliquées lors de l'encodage d'une nouvelle personne, et laisser les associations "ouvertes". Par exemple : SI une personne est encodée, qu'elle porte le rôle d'étudiant, alors elle DOIT choisir un cursus qui est proposé pour une promotion (par exemple....), mais en aucun cas cette règle ne doit être appliquée pour une "personne", sinon tu vas effectivement te retrouver bloquer pour les profs

bon travail

[prosciuto]

Salut, et tout d'abord, merci pour ta réponse.
J'ai pris note de l'ensemble de tes conseils

L'énoncé finalement nous demande de centrer notre application sur les plannings. les notes par exemples ne sont pas prises en compte.

J'ai modifié en même temps mon MLD ci dessous:

cependant :

Je changerais le terme "site" en "département"; le mot "site" a (à mon sens) une connotation trop géographique

Mon site est bien un emplacement géographique je l'ai appelé campus pour éviter les confusions.

- je ne relierais pas la "salle" au "site", sauf si la salle dépends exclusivement d'un site. si la salle est le lieu d'un cours, j'imagine que les différents départements de l'unif pourront également y donner cours; donc laisse ton modèle ouvert à ce niveau-là

La salle pour moi est par exemple : Amphi 1/Salle 203
sachant que chaque campus peut avoir un "Amphi 1" ou une salle 203
Donc pour moi elle est bien ratachée. A la limite, on peut changer le nom en "LIEU" puisqu'en fait, ma "salle" est le lieu ou se déroule un évènement.
Mais si je détache "LIEU" du campus, je vais devoir marquer "Salle 203 Orléans" pour chaque salle par exemple ce qui est lourd.
Je pense qu'il est préférable de laisser le LIEU rattaché à un site mais le rendre facultatif. Un évènement qui se déroulerait sur la pelouse du stade de France pourrais alors être créé.

- je ferais un lien entre "personne" et "promotion" :un étudiant fait partie d'une promotion

Je suis arrivé à la même réflexion, du coup j'ai englober ma promotion dans une période d'étude, sachant qu'une période d'étude peut être "master 1 premier semestre".

- attention à la multiplicité de "étudiant" et "cursus" (ou "matière", dans ton cas) : si tu forces un étudiant à être inscrit à un cursus, alors il ne pourra jamais y avoir, dans ton système d'information, d'étudiant qui n'est pas inscrit ! Quid lorsque tu encodes quelqu'un avant son choix ? Quid lorsqu'un étudiant ne fait plus partie de la fac ? Il vaut mieux gérer des règles qui seront appliquées lors de l'encodage d'une nouvelle personne, et laisser les associations "ouvertes". Par exemple : SI une personne est encodée, qu'elle porte le rôle d'étudiant, alors elle DOIT choisir un cursus qui est proposé pour une promotion (par exemple....), mais en aucun cas cette règle ne doit être appliquée pour une "personne", sinon tu vas effectivement te retrouver bloquer pour les profs

J'ai changé ça, maintenant un étudiant est rattaché à un campus, bien qu'il puisse en avoir plusieurs (si il change en cours d'année par exemple ou pour les profs qui peuvent donner cours sur plusieurs sites)
ils sont aussi rattachés à une période d'études, comme je l'ai dit plus haut j'ai englober ma promotion dans une période, du coup tous les étudiants devront être inscrits dans une période pour suivre les cours, et ils peuvent avoir plusieurs période d'étude ou ils sont inscrits.
J'ai géré l'inscription d'un étudiant à l'université avec le bool "inscrit" dans la table personne. pour moi cependant, un étudiant reste attaché à un campus :
Par exemple, un élève étant inscrit sur Paris resteras inscrit sur Paris même dans les archives, il pourra être noté "désinscrit" mais il restera affecté sur ce campus.
Cependant il faudrait peut-être créer un champs "inscrit" sur la table "campus_direction_etudiant".
Est-ce que ce raisonnement te semble logique ? ou peut être séparerais tu personnes en deux ou trois tables étudiants, directions, profs et intervenants
Dans ce cas, comment les lierais tu ?

Reste une dernière chose : pour les plannings, je dois pouvoir afficher des évènements de n'importe quel type, et suivant le niveau à un ensemble de personne.
Si c'est un cours, je pense que c'est bon, je peux obtenir la matière, l'heure, la salle, au final l'évènement.
Si c'est un meeting de l'université par contre, je ne suis pas certain, j'ai créé ma table "Type évènement", qui peut éventuellement contenir un nom, ou d'autre propriété.
Pour le moment ma logique est: "si le type évènement est "cours", je vais chercher les infos nécessaires dans la table "matières"
Sinon, j'utilise la table évènement comme base pour tous les types d'évènements différents.
Est-ce logique et surtout pratique? Au niveau du code il va peut-être être difficile de créer cette logique sur une table centrale de l'application.

Je ne suis pas sur par ailleurs que mes tables matière et type d'évènement devraient être reliées.La liaison devrait peut-être être directement entre matière et évènement, le type d'évènement n'étant qu'un label, pas une donnée essentielle.

bon travail

Merci ^^ et merci encore pour tes réponses

[DotNeteur_junior]

Bonjour, j'aimerai bien que tu m'éxplique un peu ta modélisation ! parce que je travail sur le meme projet et faut dire que question tables c'est un peu compliké !