Voila je suis en Term STT IG et avant de commencer a créér notre base de donnée, mon prof ma demandé de créer un MCD ...
 
VOila le sujet de l'activité :  
 

 
Bon j'ai donc compléter la Mcd comme stipule la question 1.1 mais il y a truc que je comprend pas et que j'ai mit en rouge  
 

 
Si quelqu'un pouvait m'aider à rectifier mon erreur sa serait cool car si je continues et ben je risques d'avoir tout faux et donc tout a refaire  
 
Merci

En fait, je n'arrive pas du tout a lire ce que tu as écrit sur ta feuille

 
C'est bon j'ai rescanné, normalement tu devrait pouvoir lire

 
Oui on me la déja dit  
 
Sinon je comprend pas qu'est ce qu'elle fout cette casse vide a gauche et puis je penes pas que c'est normal que j'ai du agrandir la case viticulteur  
 
J'ai surment fait une erreur pour completer mon Mcd mais ou je vois pas pourtant dans d'autre exercice je le fesais sans pb mais la    Si quelqu'un peut m'aider

PrixAchat, nbachat et date n'ont rien a faire dans l'entité viticulteur car ils ne caractérisent aucunement un viticulteur mais l'action d'acheter

 
DOnc c'est bien sa je mais PrixAchat, nbachat et date dans la case Vide que je nomme ACHAT.    
 
Sinon les cardinalitées sont bonnes?

Help me please

dans la case vide, je mettrai qqch comme Commande

 
Ah ok dans la case vide l'entité commande avec les propriétés Dateachat, nbachat... en gros je déplace ce que j'avais mis dans la case viticulteur dans la case vide  

Moi je mettrais a l'intérieur de l'association "acheter" : la date, la quantité etc...
 
Par contre la case vide je pensais plutot a mettre genre "Client" avec une cardinalité 1,N a "Client" car il peut acheter plusieurs vin en plusieurs quantités

 
HEin je savais pas quand dessous d'une assocition on pouvait mettre plusieurs propriétés  
 
Sinon ok dans la case vide tu mets comme entités CLIENT mais tu met quoi alors comme propriétés???

Je pensais a un truc :  
 
PEut être mettre rajouter dans l'entité VIN la propriété prixachatviticulteur
 
Dans l'association acheter je rajoute en dessous nbachatviticulteur et dans la case vide je met l'entité DATE et la propriété dateviticulteur
 
JE crois que c'est bon, qu'en pensez vous???
 
Si vous voulez je remet le MCD au propre pour vous montrer la solution que je penses bonne

Bah si on peut mais apparemment votre prof ne vous a pas encore enseigné cela.
Autrement, vas pour l'entité commande avec les attributs que tu as cité.

 
Tu ne peux pas mettre dans Vin un attribut en rapport avec le viticulteur ca serait contredire la structure du diagramme.
 
Date ne joue pas un role assez important pour etre transformé en entité.

 
Je te met mon mcd en propre tu comprendras peut être mieux

edit voila mon nouveau MCD par contre je saispas si il est toujours bon
 

vire ton entité "Date", elle n'a pas de sens.
Tu pourrais mettre bon de commande.
La date et le numéro de commande (qui jouera le role de clé primaire) dans l'entité. Le prix et la quantité de vins dans l'association.
 
Ca fait un baille que je n'ai pas fait de merise alors je ne suis pas sur du tout. Mais dans le principe, representes toi la base de données qui serait construit a partir de ce mcd. Imagines toi une table avec que des dates ce n'est pas très logique.

 
Oaui donc toi dans l'ancienne case vide tu mettrais comme non d'entité BON DE COMMANDE et comme date, datedecommande et et n°decommande  
 
Moi ce que je trouves bizarre c'est que l'ancienne case vide on a l'impression quelle est faite pour mettre uniquement 1 propriétés

miam

 
du bon vin bien sur

ALors le nouveau MCD qui est 5 post au dessus est t'il le bon??

non sebastino. Une entité Date n'a pas de raison de vivre.
 
Une table c'est fait pour désigner une entité et éviter la répétition. Une table a une propriété n'a déjà aucune signification en soi ( la propriété peut etre la clef dans ce cas la, autant la répéter partout).
 
La date est donc une propriété de ta relation Viticulteur / vin, rien de plus.
 
Un viticulteur a acheté tel vin a telle date.
 
 
Ou alors, elle peut avoir mis cette entité "a part" pour que tu mettes la date car elle veut qu'un viticulteur puisse acheter plusieurs fois le meme vin et que cela reste dans l'hsitorique... auquel cas, on ajoute effectivement la date en identifiant de la relation viticulteur/vin, mais ca doit pas apparaître en table séparée dans le MCD.
 
De plus, tes cardinalités sont débiles.
 
On démarre jamais avec des cardinalités "1" en pratique, c'est trop chiant en réel.
 
Ensuite, une relation de type "plusieurs-plusieurs" ( n-n quoi), c'est FORCEMENT porteur de propriété vu que tu vas traduire ca par une table plus tard. Enfin Merise dit ca. En pratique, pas toujours, mais bon, dans l'esprit, respecte ca pour le moment
 
Un vin ca vient d'un seul cépage. Un cépage contient X vins différents. Pose toi ce type de questions a chaque fois.

 
EUh du a du mal comprendre mais le viticulteur vend du vend dans se MCD la  
 
Si je ne comprend pas ton histoire au sujet du cépage car dans le sujet il dise que 1 vin est composé de plusieurs cépage  
 
Voila donc d'après toi mon MCD est tou faux.
 
TU aurais mis quoi toi dans la petite case a gauche

j'avais pas vu l'énoncé en haut.
 
Tes cardinalités sont donc bonnes ( énoncé de mairde a mon avis ), a ceci pres que je mettre 0.n au lieu de 1.n perso.
 
Pour la date, c'est simple, c'est un problème classique qu'il est vital de comprendre en base de donnée :
 
-Quand tu vas passer en physique, ta relation entre VIN et VITICULTEUR se transformera en table, dont l'identifiant sera "la concaténation des identifiants des tables correspondantes". Ici, ce sera id du viticulteur / id du vin.
-Le viticulteur renaud achete du bourgogne. L'identifiant de l'entrée correspondante dans acheter sera "renaud|bourgogne".
-Plus tard, l'année d'apres, renaud rachete du bourgogne, il aime ca. L'entrée dans la table acheter sera donc aussi "renaud|bourgogne" et l'ancienne sera écrasée ( un identifiant est unique ): il y aura perte d'information.
 
Donc il faut introduire une troisième table qui va séparer les deux cas. Faire une table date, c'est un peu débile, même si ca marche. Personellement, si tu veux mettre la date, je la mettrai pas dans la case de gauche mais en propriété de la relation acheter et l'ajouterai artificiellement en identifiant ( pas merisien mais toléré).
 
plus élégant, tu créé une table "commande" avec un numéro de commande et des propriétés, et voilà

Je pense que tu dois relire l'énoncé.
Un vin peut avoir plusieurs cépages bien entendu l'inverse est vrai.  
Concernant la cardinalité, le 1,n n'est pas faux, le fait est par exemple qu'un vin doit avoir au moins un cépage. (ou alors on invente le vin à l'eau).
 

Sinon mets pas les attributs dans l'association mais balance tout ca dans l'entité commande pis voila

 
C'est ce que je ferai

 
oui oui j'avais pas vu l'énoncé, néanmoins mettre une cardinalité à 1 j'ai abandonné depuis le jour ou je l'ai appliqué a une table en réel. Dans son cas, avec une cardinalité des deux cotés en 1/1 :
-Il ne peut créer un vin sans l'associer a un cépage
-Il ne peut créer un cépage sans l'associer a un vin
 
Bilan ? Il peut rien créer du tout : deadlock

 
VOus parlez de quel atribut a mettre dans commande ????
Donc d'après vous je nomme la petite case a gauche COMMANDE et je met comme propriété "N°de commande et datedeommande et prixduvin que je renomme en prixcommande"
 
Sinon si je laisse mon MCD comme sa sa marcherais quand même??
 
Si non tu pourrais pas me faire le MR pour que j'arrive à comprendre ce que tu veux me dire car a partir du MR  c'est plus simple de comprendre le MCD
 
APrès le plus chiant pour moi va de faire les requêtes (question 1.3) car bon leprof nous a fait qu'1exemple et vas y que tu te demmerde car moi je préfère le QBE  (et on est obligé de faire ses requêtes en SQL,ils nous la imposé
 
En tous cas hier j'ai fait le 2ème exercice (2ème partie) et j'ai réussit, du moins je le penses  mais par contre celui la je

 
ben oui, c'est ca pour commande. Comme ca ca marche mais c'est laid et la table date n'a aucune signification en soi, niveau analyse c'est faux.
 
Pour les requête, encore heureux qu'il vous impose du SQL ! Y a que ca d'utilisé actuellement !
 
Tu connais pas sur le bout des doigts le SQL, tu peux tjs aller te brosser pour faire quoique ce sit en BDD !

 
Si je connais quand même(on débute en Sql : 1h de cours dessus) SELECT...FROM...WHERE...AND... et j'en passe.
 
Mais bon le prof nous fait 4 h de QBE et 1h de SQL  
 
Bon donc je fais comme sa j'agrandi la petite case a gauche et je nomme l'entité COMMANDE et comme propriété N°de commande,datecommande,quantitécommandé,prixcommandé comme sa dans l'entité VIN je jarte Prix vin et sousle verbe acheter je jarte quantitéachat et normalement mon MCD devrait être GOOD  
 
Bon se soir ferait l'ai requête et je l'ai mettrai ici pour voir si j'ai bon  
 
Merci de votre aide

comme ca ca marche, surtout que dans ton systeme tu ne pouvais avoir que une seule vente de vin du coup.
 
Pour le QBE, ils voius a fait ca pour votre culture personelle je pense. Fait les en SQL, cai bien plus répandu. Tu te vois arriver sur le marché des fabricants de réservoir à essence alors que toute les bagnoles marchent à la pile a combustible et donc sans essence ? Ben cai pareil

Sinon comprend pas j'ai vu 3 potes aujourd'hui et ils ont fait pareil que moi car il un de notre exercice ressemble étrangement a celui surtout pour la case a gauche avec entité date.
 
Donc je sais pas si je laisse comme au dessus si j'ai bon ou pas

Une entité date en tant que table générera une table date avec le seul champ date en identifiant unique et je trouve ca débile, ce n'est pas merisien, c'est de la bidouille, point.
 
Moi je ferai une entité commande ou le prix du vin est séparé du vin en lui même, la ca évite de la redondance !

 
Ouai je vais lui faire les 2 mcd en lui refilant les 2 et en lui explicant si il me dit que c'est pas bon que c'est beaucoup plus valable que le MCD ci dessus.  
 
Car je le vois venir : eh Seb tu as agrandit une case, on ta dit de compléter pas de fabriquer ton mcd
 
JE vais même faire les requête en double comme sa il pourra pas me    
 
BOn faut que je réfléchisse sur les requetes maintenant car pour moi c'est encore du tout frais

C'est marrant ca me rappelle ma premiere année
 
On en a fait des 10aines et apres on l'a créée sur SQL/mySQL
 
Je savais pas que ca s'appelé un mcd en francais .. j'sais plus comment on appelait ca nous .
 
^ ce post ne sert a rien, je ne fais que passer ^

 
Moi je dis tu fais comme tu le sens

 
Ouai je vais faire les 2  BOn je réfléchit aux requetes SQL et je vous psote sa (questions 1.3 de l'énoncé )

Le mcd tel qu'il est la ne suggere pas une entite commande. Par contre l'entite Date est plus que correcte au niveau du MCD, tu ne la crée pas en passant au modele physique, c'est tout.

Voila la requête :  
 
Pour la 1ère dont l'énoncé est  :  
 
Liste de tous les vins (NOm,millésime... ainsi que le ou les cépages)
 
Moi j'ai mit :  
SELECT Vin FROM vin,cepage WHERE et je sais plus quoi mettre
Jecrois que j'ai mal mettre les cardinalités car je penses que sa aurait dufaire après WHERE vin.codevin=cepage.codevin
 
Alors je me trompe vous auriez mi quoi après WHere?