Slt
 
Bon jai un petit probleme pour modeliser un cas.
 
Je vais pas trop detailler a fond mais voila en gros (gestion de materiel) :
 
Un matériel est caracterisé par un num et un type (a , b, c , d)  . Il comporte differents attributs (nom, numéro, marque..) . Il figure sur une facture (numero de facture, date) qui  provient d'un fournisseur (id= numero).
 
Une personne unique est responsable de ce matos. Elle est caract. par un nom+prenom. A une personne est associe un suppleant.
 
On affecte ce matos a un lieu caracterisé par un nom et un num de bureau (ou nom de bureau) à une date precise.
 
 
 
Bon j'ai modelisé ca comme ca (j'ai galeré sous word) mais je ne suis pas sur avec la facture et le fournisseur , donc 2 versions.
 
Voila je sais pas laquelle est la + correcte sachant que yaura une BD access (+asp).  
J'ai du faire des betises donc dsl a l'avance.

T'as des grosses erreurs de modélisations  .
En effet, tu ne peux PAS avoir des données portées dans une association lorsque celle-ci représente une dépendance fonctionnelle.
En clair ça veut dire que lorsque que une association à pour cardinalité 0,1 ou 1,1, tu ne peux pas avoir des données portées à l'intérieur de celle-ci.
Pour ton cas, les associations affecter, contient, fournit ne peuvent avoir des données portées.
Modifie cela en premier car c tt simplement erroné.
 
D'autres remarques:
   - je préfere une solution avec une entité facture.
   - evite les doubles clés primaires dans tes entités (genre Nom et Prénom dans Responsable). Passe par une donnée identifiant par exemple
   - quelle est la signification de la clés Numéro+Type dans l'entité Matériel?
 
Voilà pour s'que g à dire
 
PS:ton MCD est indépendant de tt SGBD donc pas de probleme à utiliser Acess ou un autre si ton MCD est bon  
 

Version 1 (car Facture dans une association, c'est pas terrible)
 
edit: je rectifie mon post au vu du message pertinent de Niala. Je suis un peu rouillé en modélisation et suis passé à coté de certaines choses (à force de voir des modèles physiques on oublie le B.A. BA du conceptuel)
 
Je laisse seulement les points suivants:
- Utilise un identifiant à la place du nom et prénom dans l'entité Responsable (les homonymes existent et même si le nombre des responsables sera faible, c'est plus académique).
- Je changerais aussi les cardinalités 1,n sur les entités Responsable et Fournisseur par 0,n.
- Numéro+Type se doit d'être unique sinon utilise un identifiant.
 
Cordialement

 
Arff c normal j'en bouffe tt les jours moi  
 

 
Tt à fait d'accord   pour une question de signification (mais là les avis peuvent diverger). De tt façon cette remarque ne modifiera en rien le modèle physique obtenu à partir de ton MCD .  
 

 
merci bde vos reponses    
 
- ok pr un identifiant pour le responsable
- sinon pr materiel ben type c'est a, b, c ou d et numero c'est un numero tout bete. La clef sera type+num car un meme num peut se retrouver dans plusieurs types
- On niveau de la bd cela change koi si facture est une association ou une entité ? Ca fait une table de toute facon , non ?
- pour les histoire de dependances fonctionnelles tu fais reference au CIF je pense. Je ne vois pas comment trop changer a moins de tricher un peu sur les cardinalites ! Une facture  contient une quantite de produit et un prix, donc il y a forcement des informations (donnees) a l'interieur.
Une facture contient plusieurs produit mais un produit provient d'une facture    
 
thx

 
- g encore du mal à comprendre tes types (un petit exemple concret serait bienvenue ) mais ça devrait marcher comme ça à moins qu'il s'agisse d'une spécialisation .
 
- Au niv de la bdd c vrai que la facture de tt façon est représentée par une table mais pour ta version 2 (en modifiant la cardinalité de fournit 1,1 par 1,n!! ) le Num_Facture ne se justifie pas. Je te conseillerais de représenter la facture par une entité. Cependant pour résoudre ton problème ("Une facture contient plusieurs produit mais un produit provient d'une facture") c la version 2 qui est à privilégier voir mm tu peux t'orienter sur une ternaire (ce qui te permet de garder une entité facture) entre facture, matériel et fournisseur. Les cardinalités dans ce cas c 0,n ou 1,n partt (pour la ternaire j'entends) et tu mets ta quantité en donnée portée de l'association...
 
Voilà, dsl si c lourd mais j'avais po envie de faire un schéma . La prochaine fois peut etre  .  
 
PS: si tu pouvais ensuite nous montrer le MCD final ce serait sympa  

- un exemple 4212A (num+type), en effet il existe plusieurs numero 4212 , par exemple un pour le type A, un pour le type B. Faire un couple le rend unique.
 
- sinon me faut forcement la trace de la facture (son numero).
Pour les ternaires on nous a vivement deconseillé d'en utiliser (mais j'ai bien compris ce que tu voulais dire ) . Sinon je peux prendre la solution 1 et modifier les cardinalité (je demanderai des precisions au responsable)
 
encore merci de ta precieuse aide ! En effet, c'est le futur schema de ma Bd de mon stage. Je suis parti ex nihilo pour la faire (je suis pas habitué!) et il n'y a personne pour valider le mcd la ou je fais le stage (administration) donc bon j'aimerais eviter les conneries  

 
Bon on va dire que pour l'histoire du num+type c bon vu que tu le sens bien (mm si ça me gene un peu mais g rien d'autres à te proposer pour le moment ).
Pour la solution 1 s'pas possible mm en changeant tes cardinalités: un matériel ne correspondrait plus à une seule facture! (c toi qui l'a dis s'pas moi ). Moi je dis une ternaire c trés bien   et je vois vraiment pas pourquoi on t'as déconseillé de le faire!    
Num_Fournisseur, Num_Facture, Num_Matériel -> Quantité
Comment tu représente cette dépendance sans ternaire?
 
Et pis je dis tt ça mais y'a peut etre des regles de gestions qui viennent tt foutre en l'air aussi   .  
 

 
- pr le couple type+num ben je vois pas ce qui te gene ! tu vas pas mettre en plus un autre id pour le remplacer, ca convient la non ? Mais bon vu que tu masterises sans doute mieux que moi    
- Ben je pensais un peu a ma solution 2 mais c vrai que si facture n'est pas une entité ca fait un peu boiteux je trouve
 
Ben pr les regles de gestions c moi qui les ai reprises donc bon j'espere que j'ai cerné le sujet !
 
Je ferai un autre schema demain

Bon voila la 3eme version puis les differentes remarques que j'en fait:
 
 

 
- Concernant la ternaire, si ce ne pose pas de probleme lors des requetes ok. Ca fera dont une table de la forme suivante :

 
- pour le responsable et pour la table lieu , il est possible de mettre un numero unique a la place du couple nom/prenom et lieu/bureau. Neanmois un numero est il preferable aux couples ? Si j'insere un responsable ou un lieu je devrais faire les tests sur nom et prenom afin de voir si une personne semblable existe deja. Utiliser le couple en clef evite cela , non ?
 
- Pour 'affecter', vu que tu as dit qu'on ne peut pas avoir de donnees dans une cif, ca me pose probleme. En effet un materiel est affecte a un lieu unique alors qu'un lieu contient plusieurs materiels. Cela a une date precise et avec la creation d'une fiche qui sera abandonnée lors de l'informatisation. Donc cardinalite 1-1 , 1-n
Solution possible : faire une ternaire avec une table date mais bof bof
 
 

 
- Comme un matériel est affecté à un lieu unique (donc à une seule date) pourquoi ne pas tt simplement rajouter cette donnée à l'entité matériel;mm chose pour le num fiche. En effet, tu veux exprimer une DF entre num_matériel et date. C'est avec la création d'une CIF, les deux seuls moyens de modéliser le probleme  .  
 
- Pour la ternaire, vi vi c bon  . Remplace juste contient par fournir pour une question de sens mais là c des détails.
 
- Mets un identifiant unique pour la clé de Lieu. Y'aurait un autre moyen de représenter : faire un identifiant relatif mais je  pas si t'en as déjà entendu parler. Sinon laisse comme ça avec un identifiant unique. Un numéro (ou une référence) est donc préférable au couple mais pas nécessaire. De tt façon ça te coute rien alors vaut mieux le faire
 
- Pour l'histoire avec responsable, mets aussi un identifiant unique. Je pense ton probleme de vérifier le nom et prénom à chaque insertion ne se pose pas. Il peut exister des homonymes comme l'a dit Agagax mm si c fort peu probable .  
 
- Conseil: n'essais pas de te passer de données dans ton MCD (identifiant du responsable par exemple) car ensuite ça pose souvent problème lorsqu'on passe à l'application du MCD. Et puis AMHA ça doit faire tache une clé nom, prénom pour le responsable lorsque tu vas présenter ce que t'as fait dans ton stage.
 
Et pi voilà je crois que c tout.
 
Comme d'hab renvoie nous un MCD modifié (je sais c bcp de travail mais t'es là pour ça ). Allez bon courage    
 

dis g l'impression que je suis en train de te faire faire une tite gaffe avec ma ternaire  .
 
il faudrait que tu m'en dise plus sur les règles de gestion et ceux de manière claire. Donc qq petites questions:
 1 - est ce qu'un matériel est fournit par un seul fournisseur?
 2 - un matériel figure t-il sur une seule facture?
 3 - lorsque tu achete une "quantité" de matériel, les différentes occurences de ce matériel sont elles regroupées sous un mm identifiant ou en mettant un identifiant unique à chaque occurrence de ce matériel?
 
Voilà merci de me répondre car en réfléchissant un peu je me demande bien si ma solution coîncide bien avec tes règles de gestion à toi. g comme un gros doute tt à coup   ...
Et pi je crois aussi que g fait une grosse bourde car avec la ternaire un numéro de facture peut correspondre à plusieurs fournisseurs et là on est mal  .  

Bon de retour de long we    
 
En fait j'ai egalement verifié le shema car le responsable est revenu de vacances et il a enfin pu repondre a mes questions..
 
1/ Un materiel est fournit par un seul fournisseur. Donc a un Id numero+type, est associé un seul fournisseur.
 
2/ un materiel figure sur une facture unique
 
3/ Pour chaque occurence , un Id unique (donc on vire l'attribut quantité dans fournit).
 
4/ sur une facture figure une liste de materiels
 
5/ la facture est archivée dans un repertoire . Avec le num de facture on retrouve l'archive.
 
6/ Sinon je pense que plusieurs fournisseurs peuvent emettre le meme id de facture , donc pour identifier avec precision il faut le num de facture et le num de fournisseur.
 
A un materiel correspond une facture et un fournisseur. Donc pour la ternaire la cardinalité de materiel serait 1.1 non ? Dans ce cas la ternaire est elle encore valide    

 
bah voilà c plus clair maintenant    
déjà pas possible de mettre 1,1 ds une ternaire   s'pas bien ça
aprés tu as :
  Num_Matériel -> Num_Facture
  Num_Facture -> Num_Fournisseur
donc plus besoin de ternaire  patapé!  
 

 
ça pourrait etre possible en effet. tu peux simplement penser à un identifiant relatif ... ça revient à ce que tu dis au niveau physique (donc pour identifier avec precision il faut le num de facture et le num de fournisseur.) mais c qd mm mieux que mettre Num_Facture + Num_Fournisseur comme identifiant de Facture d'un point de vue analyse
 

 
hfrfc?? enfin bon...
 
en tt ça moi je dis c bon ça devrait répondre à tes règles de gestion (mais bon des fois faut pas trop se fier à mon avis   )
 
ah vi pour l'identifiant relatif en effet au niveau modele physique c exactement ce que tu dis. Mets juste entre parenthese la cardinalité (1,1) ds l'association "fournit" et c gagné
 
Ps: juste une tite remarque, faut des verbes à l'infinitif ds les associations
 
 
   
 

 
arff ben non dsl mais j'suis juste un étudiant qui vas bientot passer son BTS IG (développeur)    
et pi bah d'aprés ce que je sais du monde de l'entreprise (en fait juste 2 stages de développement) bah on te demande de faire tt ça mais en fait ils le font pas vraiment eux .
Pour le reste faudra voir ec des gens qui savent parce que là j'suis à la rue    
bah pour me remercier un grand merci ça suffit. Arff y'a bien la soluce que tu passe à la Réunion pour me payer un ti coup (et pour prendre un peu de soleil aussi ) mais ça le fait pas trop là
 
et pi c t'es BTS Ig aussi t'inquiete pas tu seras aussi fort que moi à la fin