Bonjour,  
 
Je dois mettre au point une base de données gérant les stages d'étudiants en utilisant MySQL.
 
En gros le sujet dit:
un étudiant est encadré par un maitre de stage (en entreprise)  et par un tuteur qui est une enseignant.
A la fin du stage, l'étudiant passe une soutenance devant un jury composé du tuteur, du mds, et d'une troisième personne (un enseignant) faisant le candide.
Une semaine est consacrée à l'organisation des soutenances.
Le mds en accord avec le tuteur fixe la date de la soutenance de l'étudiant qu'ils encadrent.
 
règles:
-un étu a un mds et un tuteur
-un mds peut encadrer plusieurs etu
-idem tuteur
-un enseignant doit être candide autant de fois le nb de stagiaires qu'il encadre.
 
J'ai fait pour l'instant ce mcd:
 

 
Le pb c'est qu'en faisant le modèle relationnel la table soutenance n'est pas 3NF car "etu" implique "tut" et "mds" et je n'arrive pas à trouver une autre relation concernant etudiant et soutenance avec les cardinalités amenant une CIF dans le sens etudiant vers soutenance.
 
J'avais sinon pensé à mettre tout dans la table étudiant.
Mais la prof veut qu'on pose des contraintes d'intégrité référentielle:  
aucun problème concernant le mds et l'enseignant-tuteur,
mais problème pour le candide et la date de soutenance encore inconnus lorsqu'on rempli la base la première fois.
 
A ce propos j'aimerai savoir si l'on est obligé de mettre des CIR sur toute relation.
 
D'avance merci pour vos réponses, qui je l'espère pourront m'aider.

moi, ce que je vois, c'est que tu veux décrire des stages, mais ils n'apparaissent pas clairement. pourquoi pas de table stage ?
en clés étrangères (éventuellement clé primaire): étudiant, mds, tuteur
 
en attribut, une référence à soutenance
 
 
non?

C'est ce que j'avais fait au tout début mais en relisant mon cours plus un boukin sur Merise que j'ai ht today, il est dit que chaque entité concrète ou abstraite doit avoir une existence propre.
 
Or on peut considérer que le stage est justement le regroupement d'un étudiant, d'un mds, d'un tuteur, bref de toutes les autres entités, elle n'a pas d'existence à proprement parler (enfin je pense).

J'opterai personnellement pour la solution de arghbis. Tu dis par exemple que tu dois gérer les stages. Ton MCD ne mentionne en aucun cas les dates de stages des étudiants. Pourtant je pense que ces dates peuvent etre utile. C'est déjà une bonne raison pour passer par une entité stage.
 
Bon laissons à part l'entité stage. G quelques doutes sur ton association fixe. Quelle est son rôle?
 
Ce que je te propose:
-une table stage avec une DF vers ETUDIANT MDS et ENSEIGNANT. -Egalement une DF vers une entité SOUTENANCE que tu auras crée.
-Une DF entre ENSEIGNANT et SOUTENANCE pour l'histoire du candide.
 
Voilà vu que c'est vite dit e sais pas si c'est viable. Teste qui sait ça te conviendra peut-être. Et puis en général n'hésite pas à créer des entités si t'en as besoin puisque de toutes façons au niveau nombre de tables de ta BDD ça ne changera pas grands choses.
 
Voilà.

G fait ça finalement:
 

 
Mon problème pour les CIR est résolu avec utilisation des cardinalités 0,1 que l'on peut convertir en tables associatives dans ce cas.
 

s'pas bon tout ça.
Ton association soutien contient des données portées alors que c une DF. Ton prof va hurler si il voit ça

Les mettre dans date ?

non plus.
T'as qqch contre une nouvelle entité?

pour qu'elle soir porteurse de propriété faut avoir 1,n des 2 côtées, il suffit de changer les cardinalités si possible

Non non du tout
 
Je viens de lire le boukin et apparamment pas de pb.
Regarde,
 
Quoted du boukin ("l'essentiel sur merise"-d.dionisi Ed.Eyrolles)
 

 
Donc apparemment ça ne pose pas de pb.

voila mon chtit MCD il manque date/heure mais c'est déjà plus beau

 
Albator c pas mal, mais pas 3nf, car redondance d'info concernant le jury que l'on retrouve déjà par étudiant par les relations "encadre".

La relation soutient n'est pas bonne il faut en effet avoir x,N de chaque côté pour soutenir des attributs dans ta relation car au niveau physique elle va être matérialisée par une table.
 
Dans le cas que tu montres, ta relation soutient sera matérialisée par l'insertion de la clé primaire de date en tant que clé étrangère dans étudiant.  
Dans ce cas (qui est le tien) avoir des attributs dans soutient est donc faux.
 
CHaiCA

 
c'est pour moi ou pour Albator?
 

 
Tout à fait d'accord. C'est comme g dit mais en mieux

Sans vouloir vous offenser aucunement , il est clairement dit que s'il y a des propriétés dans la relation avec cardinalités 1,1-1,n, elles glissent vers 1,1 (règle 2). Regarder la citation issue du bouquin dans un de mes posts précédents.
Et selon la règle 3, s'il y a une cardinalité 0,1-1,n (mon cas) la relation se transforme en une table (comme dans une x,n-x,n).
 
Je sais plus ke croire

 
bah je vois bien ce qui est écrit mais en tt cas on m'a toujours formellement interdit (pendant mes 2 ans d'analyse) de mettre une donnée portée dans une association (1,n)-(1,1) . Je voudrai pas voir la tête de mon prof si je lui ramene qqch comme ça.
Et puis en plus pour moi c pas trés clair ce qui est dit dans ton livre  . G beau lire et relire j'ai du mal à comprendre. J'dois etre trop fatigué   .
Allez vais dodo moi

moi on m'as dis quand on a (1,n) (1,n) la relation est obligatoirement de proprité mais on m'a pas interdit de foutre une propriété sur une relation (1,n) (1,1) si le bouquin le dis et que el mec qui l'a écris est un spécialiste alors