Reprise du message précédent :
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?

Et la 2ème est :  
 
liste de tous les vins blanc(code et nom) de la région bourgogne millésime 1996 :
 
SELECT codevin,nomvin FROM vin   WHERE regionvin=bourgogne, millesimevin=1996;
 
Alors celle la est bonne en partant du MCD au dessus avec dans la petite case a gauche l'entité DATE et propriété dateachat

Help il me reste plus qu'a corrigé,m'aidé à faire les requêtes et c'est bon je passes sous ACCESS
 
Help me c'est la dernière question aprèsles requêtes c'est terminée

Selon merise :
-Un identifiant doit etre dénué de toute signification
 
Donc l'identifiant de la table Date ne peut etre la date. Donc quand tu passes en MLD tu dois avoir un int en identifiant date et Date en attribut.
 
Donc ce n'est pas Merisien mais de la bidouille que de faire disparaitre l'entité Date ! Donc elle n'a point raison d'etre. CQFD

 
ouai c ca. Tu fais ta jointure entre les deux tables et pour chaque vin tu aura les tuples vin|cepage associé.
 
Attention, oublie pas que ta relation associant Vin à Millesime est une table en MLD, car y a deux cardinalités multiples ! Et pour etre merisien, elle devrait etre porteuse de propriété.
 
ta table etre de associe identifiant du vin / identifiant du cepage.
 
Ca devra etre une requete style :
 
SELECT vin.*, cepage.* from VIN vin, CEPAGE cepage, ETREDE rel WHERE vin.vinid = rel.vinid AND rel.cepageid = cepage.cepageid;
 
Dans l'esprit c ca.  change les noms pour que cela aille bien et vala.

 
Selon Merise, pour etre en 3° forme normale, tu ne dois pas avoir de redondance d'information. La date est un element autonome, qui ne doit pas son existence à celle de la commande (Si il n'y a pas de commande, il y aura toujours des dates), donc elle soit apparaitre dans le mcd. Ce n'est pas de la "bidouille" de  la supprimer au modele physique : si tu es puriste, tu peux creer une table date dans ton modele physique (il y a meme des cas ou cela serait optimale)

 
Aussi, mais c'est contradictoire  
 
Personellement, la table "Date" me choque énormément. Apres, ca dépend des philosophies surement.
 
Mon assertion est aussi valide niveau merisien que la tienne, a ceci pres qu'elles rentrent en conflit dans ce cas précis... Donc qui a raison/tort
 
Je suis d'avis que on a raison tous les deux. Tant que ca marche !
 
Enfin moi je mettrai pas de table date quand même.

 
Laquelle ?

 
Bon j'ai mis sa :  
 
pour la 1ère requete : SELECT vin,cepage FROM vin,cepage WHERE vin.codevin=cepage.codevin
 
Pour cela j'ai donc changer la cardinalité de cépage et je l'ai mis en 1,1 pour pouvoir faire la requête
 
Voila j'espère que c'est bon.
 
Sinon vous avez regardé la 2ème, vous la trouvée Bonne???

 
voila la 2ème requete alors bonne??

Cardinalité de cépage à 1,1 : Pas bon. Ce n'est plus conforme à l'énoncé. Tu n'as pas le droit de mettre ce qui te chante, il y a des regle a respecter.
Un vin est fait de plusieurs Cepages : Cardinalité 1,n coté Vin
Un Cépage est utilisé pour plusieurs Vins : Cardinalité 1,n coté cépage

Et ou dis tu que c'est le vin BLANC que tu recherches ? (Pour infos , en Bourgogne, ils font aussi voire surtout du rouge)

 
Voila refaite la 2ème requete :  
 
SELECT codevin,nomvin FROM vin WHERE regionvin="bourgogne,couleurvin=Blanc...
 
Donc pour la 1ère requete je suis baisé

 
Ben non, celle que je t'ai donné en exemple marche tres bien, kesske tu racontes !
 
Changer la cardinalité de ton MCD ca se fait pas comme ca "parce que ca va bien pour les requetes" hein.

ouai c'est bon j'ai suivi tes conseil et sa roule.
 
Sinon avant de mettre sous excel j'ai demandé au prof pour la petite case date et il ma dit l'entité Date ne peut avoir que la propriété Date c'était le piège de l'exercice

 
Ben tu lui diras que point de vue merisien c'est du délire dans unc ertain sens ( le mien, une table date n'a aucune raison d'etre dans l'analyse ), et c'est de la bidouille dans l'autre ( elle a pas de raison d'etre mais on prévoit le coup).
 
Pour lui clouer le bec, suffit de lui dire que sa table date sert juste a apporter un identifiant dans sa relation, qui devient ternaire, et permet d'enregistrer l'historique des transactions de facon parfaite du coup ( relis mon message précédent).
 
Ton prof, file lui l'adresse de ce thread, faut qu'on cause

 
C'est ca, au moins il rigolera bien !!!

 
Je maintiens que d'un point de vue merisien, l'entité Date ne remplit pas les condition d'existence d'une entité, et viole toutes les règles d'analyse établies comme éviter les répétitions, avoir un sens concret, plusieurs attributs et compagnie.
 
meme si en pratique ca marche, la théorie est totalement erronée.

On voit ceux qui ont une véritable pratique de MERISE en entreprise...  
L'entité DATE est une entité très couramment utilisée dans les MCD (Modèles Conceptuels des Données) qui disparaît lorsqu'on passe aux MLD/MPD (modèles logiques/physiques des données), après optimisation.
L'entité DATE sert à modéliser les notions d'historique, où le temps sert à différencier 2 événements distincts.  
 
10bouteilles de VIN achetés le 4/11 au viticulteur Jean à 1? pièce , c'est une occurence de la relation ACHETER(VIN, VITICULTEUR,DATE).
10bouteilles de VIN achetés le 5/11 au viticulteur Jean à 1? pièce , c'en est une autre .  
Dans une table (ACCESS ou autre), cela se traduit par 2 lignes différentes de l'historique des ACHATS(ID vin , ID Viticulteur, date d'achat).
De toute façon , l'exercice est très simplifié. Si on avait voulu introduire des COMMANDES, on pourrait également introduire des LIVRAISONS , partielles ou pas, chacune étant des relations avec une "patte" vers DATE... et cela se compliquerait très vite.  
Enfin , en passant et en simplifiant, MERISE ne se réduit pas aux modèles de données (MCD, MLD, MPD), mais comporte aussi une modélisation des traitements (MCT, MOT, MPT) ainsi qu'une décomposition en Etude Préalable, Etude détaillée , Réalisation, etc...  
 

 
Merci, mais apparemment certains ont la science infuse, donc l'expérience est peu de chose finalement.
 
Si il avait connu l?époque ou le prix du stockage était prohibitif et que le calcul des volumes était l?instant crucial dans l?analyse, il comprendrait peut être l?utilité de l?entité date.
 

 
Toi, apprends a lire.
 
j'ai bien compris l'utilité de l'entité date, qui est d'introduire une clé étrangère dans la relation qui deviet ternaire, et qui permet donc de arder un historique des ventes sans ecraser l'entrée dans la relation en cas de deux ventes successives du meme vin avec le même viticulteur. C'est même moi qui ai eliqué ca en première age au monsieur.
 
je dis juste que l'existence de cette table DATE est douteuse d'un point de ue analyse sur le MCD. Elle se justifie en pratique, mais sur la théorie ca me semble oualou.
 
Alors avant de critiquer les gens, apprenez a LIRE EN ENTIER un raisonnement.
 
Quant à ma pratique des BDDs, j'ai bossé la dessus au FBI, donc j'ai quand meme *un peu* de pratique, excuse moi.
 
Merde alors. j'en ai ausé a une amie qui bosse dans les BDDs financières deuis 25 ans mainteant et elle est d'accord, point de vue thérique c'est moyen, même si ca marche en pratique ( je le répète pour la X-ieme fois, histoire que vous ayez lu ue je dis que ca marche en pratique, car oui ca marche en pratique, la, vous avez lu ? ).
 
Et je vous rapelle qu'on est pasen entrerise, et que donc niveau théorique, ou on se truve, la table date ne devrat pas aparaitre sur le MCD pour les raisons citées au dessus.
 
Y a des manières plus élégantes niveau analyse ( numero de commande et propriété de la commande, etc).

 
Voilà, je le remets ce post pour vous montrer. merde alors.

Puisque tu te mets sur terrain de la théorie, je te rappelles qu'il n'y a rien de plus théorique qu'un MCD, et que l'entité DATE représente le temps, qui est ce qu'il y a de plus conceptuel...Non seulement, ça marche, mais ce n'est pas laid (Einstein en a fait une quatrième dimension...)
Il y a pratique du MCD et pratique des MPD. Dans la pratique des MCD, l'entité DATE est omniprésente. (Je rappelle que MERISE est d'abord une méthode de conception de systèmes d'information utilisée dans des grands projets de type bancaire, avant d'être enseignée en classe.) Dans la pratique des MPD, il n'y a jamais de table DATE, à moins qu'on ne gère les calendriers...
A ce stade, je comprends mieux le désarroi de l'élève sebastino29 !
 
 

 
Bon écoute, c'est bien beau, mais mes assertions restent bien merisiennes face aux votres.
 
Donc oui y a conflit je suis le premier à le dire. N'empeche que c'est ambigu, et que même si cette "table" est une solution, je pense pas que la mettre en tant qu'entité soit pertinent.
 
Qu'on la rajoute "a la mano" dans la relation en tant que clé étrangère me semble plus "merisien" dans l'esprit.

 
Je n'aime pas trop faire l'ancien combattant, surtout pour des combats d'arrière garde (car il y a maintenant d'autres méthodes que MERISE) mais des MCD "en vrai", j'en ai fait et vu des centaines, et j'ai fait de la formation MERISE à la SEMA (quand elle s'appelait SEMA), et j'ai participé à d'autres batailles sur les MCD que celles-ci. De toutes façons, les MCD déclenchent toujours des batailles sanglantes qui disparaissent vite quand il s'agit de passer à la réalisation, c'est-à-dire aux tables.
Cela dit, chacun pense ce qu'il veut, tant qu'il n'est pas noté, comme l'auteur initial du post...

 
Je veux bien apprendre à lire, mais toi, apprends à ecrire, parce que la et a cette heure ci j'ai du mal a te comprendre
 
Maintenant, Merise cela fait 15 ans que je l'applique au quotidien, je l'ai enseigné pendant 3 ans, alors excuse moi, mais tes assertions a deux balles, tu te les gardes.

Oh ca sert a rien de s'enerver dans les deux camps.
 
Pour ma part, je donne un avis de simple étudiant ayant suivi des cours de BDD et UML.
 
Moi je pense que le restaurateur s'en fiche des dates durant lesquelles il n'a pas passé commande mais seulement celles où il à commander (cf l'enoncé). Donc dans le principe il faudrait nommer la table : Date de commande. Autrement tu mets une table Commande avec la date en attribut point barre. Je ne vois pas ce qu'il y ait qui puissent faire herisser les poils de cul
 
 

 
T'es donc un ancien combattant
 
Pour le post pas lisible, désolé d'avoir répondu en cours avec un clavier pourri On fait ce qu'on peut avec ce qu'on a.
 
Enfin, je vois que tu as enfin compris que j'avais tilté l'intérêt de cette 'table' dés le début, on avance bien la maintenant Mais bon, comme tu restes fermé sur ta propre vision "y a que la mienne qui est bonne" de cette partie, contrairement a l'autre monsieur, la discussion est close : retourne a tes cours, vieux, et laisse la place aux jeunes qui ont de l'avenir ( )

 
Dans l'énoncé, on ne parle pas de COMMANDE, mais d'ACHAT, ce qui n'est pas pareil. Si on avait voulu introduire la notion de COMMANDE, on aurait parlé de no de commande, ou de date de commande, et de quantité commandée, qui peut être distincte de la quantité achetée: on pourrait commander en plusieurs fois, acheter moins que ce qu'on a commandé, ou plus, etc... Le cas traité est très simple, il n'y a pas à le compliquer en introduisant d'autres notions.
Par ailleurs, si tu parle ENTITE, tu est au niveau MCD. Si tu parles TABLE, tu es au niveau MLD/MPD . Maintenant que les BDD hiérarchiques (type IMS) et CODASYL (type IDMS ou IDS2) sont remplacées par DB2 et ORACLE , on ne parle plus de ces 2 types de SGBD, qui donnnent des MLD/MPD différents.  
Pour ceux que ça intéresse,  les pères de MERISE : Tardieu, Rochfeld, Coletti ont écrit "La Méthode MERISE" aux Editions d'Organisation, qui date de 20 ans environ et qui sont des classiques de tout Merisien... (C'est assez indigeste pour ceux qui n'ont pas à le pratiquer, mais il vaut mieux traiter avec le bon Dieu qu'avec ses saints, ou ses démons.)
Le MCD , c'est comme le jeu d'échecs : ça touche énormément les egos. Parole d'ancien combattant (le 11 novembre approche)!