Version imprimable
Bonjour,
je dois réaliser un schéma entité-relation dont voici l'exercice et le dictionnaire de données.
J'ai déjà réaisé un schéma mais je ne suis pas sur du tout de mon schéma .Est ce que qqn peut me dire les erreurs et me proposer un modèle .
Merci
Quelques remarques rapides :
Vous utilisez le formalisme Merise : vous ne pouvez pas associer des associations (cf. DISPENSER er AFFECTER).
Évitez les ternaires avec des cardinalités 1,1, les associations correspondantes sont généralement décomposables en relations binaires.
Selon votre modélisation, un correspondant peut faire partie de deux sociétés. Il est préférable de parler du correspondant Cx de la société Sy.
Même chose en ce qui concerne le comptable.
Pourquoi avoir mis une relation de dépendance entre les correspondants et les comptables (association AFFECTER_A) ?
Il y a beaucoup d'association de degré 3 qui devraient être décomposées. Assure-toi des cardinalités 1,1. Exemple le 1,1 côté Formateur signifie qu'un formateur n'est associé au'à un seul couple (convocation, stagiaire). Pourtant un formateur doit être en association avec plusieurs stagiaires je suppose.
Bonjour,
C'est vrai les cardinalités sont fausses côté société et formateur.
On m'a dit que je devais utiliser les cardinalités anglo-saxonnes.
Merci pour vos conseils .:P
Je vais décomposer mes ralations ternaires en relation binaire.
Je voulais savoir ce que c'était qu'un modèle Entité Relation étendu .
S"agit il de sous type d'entités ?
Je vois que j'ai encore beaucoup de chose à apprendre concernant MERISE !!:roll:
Bonjour,
J'ai pris en compte vos conseils.Seulement dans le schéma , je ne sais pas si je dois modèliser les calculs de type :
cumul des journées élèves réalisées pour le compte de la société depuis le début de l'année
le nombre de places commandées
le nombre de places demandées
le nombre de personnes à facturer
le nombre maximum de places offertes à un séminaire
le nombre de places restantes à un séminaire.
Estce que je peux mettre ces calculs dans les associations comme par exemple:
Entité demande inscrition association cours avec comme attribut nombre_Places_Offertes associé à lentité cours ?
En théorie, seulement si ces données sont des axiomes et non pas des théorèmes, autrement dit si vous n'êtes pas en mesure de les inférer à partir d'autres données de la base de données.Citation:
J'ai pris en compte vos conseils.Seulement dans le schéma , je ne sais pas si je dois modèliser les calculs de type
Bonjour,
Axiomes et théorèmes je ne vois pas vraiment ...:(
Sinon cela donnera
C'était une sorte de métaphore (quoique...)Citation:
Axiomes et théorèmes je ne vois pas vraiment ...
Je voulais donc dire :
Si par exemple, le cumul des journées élèves réalisées pour le compte de la société depuis le début de l'année ne peut pas être obtenu à partir d'autres données, alors il faut modéliser ce cumul, sinon vous introduisez une redondance, ce qui n'est pas une bonne habitude à prendre.
Même principe pour les autres données de calcul.
J'ai bien compris.
Merci pour tes conseils.
J'ai déjà donné cette réponse précédemment :
http://www.developpez.net/forums/sho...3&postcount=10
Cela entraine une certaine entorse au principe de non-redondance, mais je trouve que cela aide parfois. Mais attention, cela doit rester des cas isolés, bien identifiés, pour lesquels le gain a été clairement justifié.
Merci pour tes conseils.
Mais le "cumul des journées élèves réalisées pour le compte de la société depuis le début de l'année" je ne crois pas qu'il soit calculée à partir des données existantes et le modéliser me semble bien difficile :(.
Bruno
Bonjour à tous,
J'ai une petite remarque sur l'exercice en lui-même.
Si l'auteur de l'exercice a fourni un dictionnaire de données, il se peut que la règle du jeu soit de s'y tenir. Dans ce cas, le MCD de BRUNO.FABIEN est hors sujet et il aura 0/20 (ou pas loin). En effet les propriétés suivantes ne font pas partie du dictionnaire :
- Matricule_Correspondant_Formation
- Matricule_Comptable
- Date_Naissance (stagiaire)
- Numéro_Demande
- Numéro_Commande
- Numéro_Convocation
- Date (PLANNING_TYPE)
Et celles-ci sont présentes dans le dictionnaire mais n'apparaissent pas dans le MCD :
- Année de naissance du stagiaire
- Nombre de places commandées (mais "Nombre_Place_Demandée" apparaît 2 fois : dans les entités INSCRIPTION et COMMANDE)
- Cumul des journée-élèves
- Nombre de séminaires dispensés par le formateur
L'exercice est plus difficile en respectant strictement le dictionnaire de données fourni.
Qu'en est-il exactement BRUNO.FABIEN ; faut-il s'en tenir strictement au dictionnaire ou non ?
JPhi33
Bonjour,
Nous devons avoir les mêmes profs ;-)
Effectivement la consigne que j'ai eu : utiliser le dictionnaire des données à minima et en ajouter si besoin. Vous trouverez ci joint le MCD sur lequel je travaille, avec cardinalités anglo saxonnes. Au delà de la présentation (ok c'est le fouilli!), je suis aussi perplexe sur la façon d'aborder le planning, et sur le fait que certaines infos nécessaires à la gestion du centre ne soient pas reliées directement aux entités, mais à travers d'autres. (j'ai voulu évité les redondances, mais ne suis pas bien sûre du résultat!).
Merci à tous pour vos conseils, et bravo pour votre participation à ce site qui est pour moi un outil d'apprentissage de qualité.
Isabelle
Bonjour,
Moi aussi, je dois avoir le meme prof que vous :lol:, par contre Isabelle, tu as mis des cardinalités 1,1 et 1,1 sur quelques associations, est-ce normal ? de plus, tu stockes des propriétes sur des relations avec 0,1 ou 1,1 d'un coté, est-ce normal aussi ? (normalement, tu peux stocker sur du 0,N et 0,N ?)
Enfin, je ne sais pas, car je n'ai pas encore traduit en Anglo saxon :?
Pour le planning, je galère un peu aussi :lol:
Druide :D
Bonjour à tous,
Je ne comprends pas bien à quoi correspond cet exercice de style imposé par le professeur, si ce n'est à semer la confusion dans l'esprit de ses élèves. Soit on fait du Chen - Entity-Relationship Model, soit on fait du Tardieu (et son équipe) - Modèle Entité-Association.Citation:
Envoyé par Isabelle*D
Exemple : un Stagiaire est employé par 1 Société
Chen :
[ Stagiaire ]---N-----< Employer >-----1---[ Société ]
Tardieu (Merise) :
[ Stagiaire ]--1,1----( Employer )----0,n--[ Société ]
La notion de cardinalité avec son couple de valeurs est propre à Merise. Elle n'existe pas dans le modèle de Chen qui utilise la notion de mapping avec une seule valeur. Il distingue ainsi 3 types de mapping pour les relations binaires : 1:N, M:N et 1:1.
Peut-être le prochain exercice sera-t-il de construire un modèle de Chen avec mapping français, allez savoir !:D
Quelques remarques sur le MCD d'Isabelle :
- Il y a un concept de trop parmi TypeSéminaire, Séminaire et Session ; trouve lequel. L'énoncé étant ambigü sur ce point (les 3 termes sont employés), ce n'est pas facile.
- Relis bien : "c’est toujours le même formateur qui assure le même type de séminaire". Mais rien ne dit qu'un formateur ne peut pas assurer plusieurs types de séminaires. Ceci devrait résoudre les cardinalités de l'association Dispense.
- Le formateur, le stagiaire et le séminaire ont chacun un niveau. Pourquoi modéliser différemment le niveau du séminaire ? Pourquoi associer le niveau du stagiaire et celui du formateur ? Pourquoi créer une entité Niveau ?
- Dans le même esprit, pourquoi créer une entité Groupe ?
J'arrête là. Ca fait déjà pas mal de travail !
JPhi33
Merci pour tes remarques, j'avais revu tout en Merise, ce qui me permet d'être plus cohérente avec le modèle demandé.
Pour les entités en trop, c'est vrai que j'ai du mal à synthétiser par peur d'oublier une notion. Ainsi Groupe peut être un attribut de formateur, mais cette donnée est-elle stable? (n'est-ce pas trop de contrainte si on doit changer cette donnée pour formateur, si on le met en attribut?).
Niveau : Le niveau d'un formateur et d'un stagiaire peut évoluer, de plus il peut être multiple en fonction du séminaire choisi, je ne vois comment gérer cela sans créer une entité Niveau?
Il faut effectivement que je revois mon schéma pour que cela ne soit pas une association entre formateur ET stagiaire.
Pour le niveau d'un séminaire, j'ai pris l'hypothèse qu'il restait toujours le même (débutant, confirmé etc.) je l'ai donc laissé dans l'entité.
Je revois encore une fois mon schéma et le posterais demain, en tout cas merci pour ces conseils!
La modèlisation est un art difficile...
Pour essayer d'en finir avec les problèmes de notation...
Depuis bien longtemps, j'ai dû m’habituer à passer instantanément d’une notation à l’autre, en fonction de mes interlocuteurs : en simultané, au cours d’une même réunion de travail, utiliser la notation Merise et une notation du genre IEF, UML ou autre, ces interlocuteurs n'ayant pas tous les mêmes habitudes ès matière. Pour cela j’utilise un truc et vous pouvez au besoin le reprendre à votre compte.
Exemple Merise. Reprenons les deux entités-types Stagiaire et Société et l’association-type Employer :
[ Stagiaire ]--1,1----( Employer )----0,n--[ Société ]
Je procède ainsi :
En suivant la patte, mon œil part de Stagiaire pour aller à la rencontre du prochain symbole graphique (entité-type ou association-type) qui se présentera et il emmène dans sa besace le couple de cardinalités 1,1.
En l'occurrence, la rencontre est celle d’une association-type, à savoir Employer, et c'est à cette occasion que je traduis les cardinalités : un stagiaire participe une et une seule fois à l’association-type Employer.
Dans un 2e temps, sans m'attarder (mon oeil est légitimement curieux), je traverse le miroir et découvre à cette occasion que l’entité-type Société participe aussi à cette association-type.
Si mon œil part de Société, en compagnie cette fois-ci du couple de cardinalités 0,N, la rencontre avec l’association-type Employer me conduit à traduire les cardinalités ainsi : une société peut participer plusieurs fois à l’association-type Employer.
En gros, rapidement et informellement (en notant bien le rôle du mot "participer"), voilà pour Merise dont la notation est cohérente.
Concernant maintenant la notation de Chen, je laisse tomber, car je n’ai plus eu l’occasion de l’utiliser depuis douze ans et de toutes façons je ne sais pas la justifier (je trouve JPhi33 bien courageux à ce sujet). Avec cette notation, j’ai toujours eu l’impression de rouler avec un volant à droite...
En revanche, la notation IEF, celle d’UML ou encore celle de PowerAMC dans sa version anglo-saxonne, me donnent le sentiment de continuer à rouler avec un volant du bon côté. En effet, considérons le diagramme UML suivant :
[ Stagiaire ]--0,N----------1--[ Société ]
Il se trouve que "Employer" (que je n’ai pas fait figurer) sert à nommer l’association, pour faciliter la compréhension du modèle, mais sans plus. Je ne porte pas de jugement de valeur, je constate.
Pour reprendre le principe de mon œil qui se balade le long du lien, à la recherche du prochain symbole graphique (toujours avec les cardinalités dans la besace), le constat est le suivant :
Partant de Stagiaire, cette-fois-ci l’arrêt est provoqué par la chose-type Société : j’ouvre ma besace et je lui applique ce que j’y trouve, à savoir 1,1 (1, selon la notation UML). Ma lecture est alors la suivante : "Un stagiaire est associé à une et une seule société" et, au verbe "employer" et à la notion de participation près, je retrouve la lecture Merise, selon laquelle un stagiaire est employé par une et une seule société.
Si je pars de Société, j’aboutirai de la même façon à la conclusion qu'une société est associée de 0 à N stagiaires.
A mon sens, Merise, UML, IEF et Power AMC (dans sa notation Merise ou Entité/Relation) sont donc cohérents entre eux sur ce point et je dirai même, les seuls à être rationnels, par opposition aux diagrammes présentés dans les précédents messages.
Utiliser des ovales et des cardinalités Merise en permutant celles-ci n'est pas raisonnable : certes on peut arriver à contrarier le bon sens, comme on arrive à contrarier un gaucher, s’habituer à rouler à gauche, ou marcher sur la tête, mais le mieux est de revenir à la raison. A commencer par les professeurs, s’ils veulent que leurs élèves, une fois devenus opérationnels, arrivent rapidement à dialoguer avec les gens de terrain.
?Citation:
Envoyé par BRUNO.FABIEN
Je suis tt à fait d'accord avec ce qu'on déjà dit fsmrel et JPhi33. Chaque notation possède une grammaire permettant de représenter des concepts précis.
Mélanger des morceaux de Chen dans Merise revient en gros à écrire une partition pour violon en clef de fa. Ca ressemble à de la musique et ça doit faire illusion qques minutes. Mais c'est inutilisable.
La modélisation est 1 exercice qui n'est pas aussi difficile que vous le pensez Isabelle*D et toi, mais qui nécessite de la justesse pour ne pas produire n'importe quoi.
Avant de devenir un DD, une liste des propriétés devrait être valorisée(synonymes, polysèmes, exhaustivité etc...) Toute Relation devant être identifiée, pour moi il y en a au moins 1 des 3 qui manque (voire les 3). La liste fournie n'est pas suffisament complète pour être un DD. Partant de là je dirai que ça laisse toute lattitude pour le modifier.Citation:
Envoyé par JPhi33
C'est le même problème. Si IRL ''Niveau'' a la même signification ds les 3 cas, il ne devrait apparaitre qu'1 fois dans le DD. Et donc on n'en fait qu'une entité.Citation:
Envoyé par Isabelle*D
Autre chose, ce n'est pas parce que c'est une propriété stable d'une entité qu'elle ne ne peut pas faire partie d'une association.
C'est une donnée calculée. A toi de proposer un schéma qui permette de l'obtenir.Citation:
Envoyé par BRUNO.FABIEN
Non. Et de toute façon, surtout pas au niveau conceptuel.Citation:
Envoyé par hed62
Ensuite si on veut anticiper un pb de complexité de calcul qu'on ne veut pas déporter au niveau applicatif, il est possible de faire des vues.
Si on présuppose un pb de perf, on dénormalise mais au niveau physique.
Ds vos 2 modèles vous associez ''convocation'' et ''formateur'' ( d'ailleurs, ds un des 2 modèles le stagiaire n'en a pas et dans l'autre le formateur en reçoit 1 par stagiaire). Ca fait partie des règles de gestion que l'on vous a donné ? Je n'ai pas vu les règles ds les PJ. Un MCD est un modèle sémantique. Il est possible de détecter les erreurs ''techniques''. Mais ce n'est pas possible de valider la justesse de vos modèles sans les règles de gestion qu'ils sont sensés traduire.
Il y avait bien un énoncé mais il a disparu. Le voici : Pièce jointe 22095Citation:
Envoyé par TheLeadingEdge
Pour les niveaux :Citation:
Envoyé par Isabelle*D
Le dictionnaire fait apparaitre 3 propriétés Niveau, pour le stagiaire, le formateur et le séminaire. Ceci remet en cause la modélisation d'Isabelle*D qui fait apparaître une entité NIVEAU qui n'a pas lieu d'exister. Chacune de ces 3 propriétés trouve sa place dans l'entité à laquelle elle se rapporte comme dans le modèle de BRUNO.FABIEN.
JPhi33