MERISE

est-ce que quelqu'un aurait une idée ?

Salut,

Eh, un utilisateur de Merise.  
Si au début, c'est un peu chiant, sache que cette méthodologie est une des meilleures pour concevoir une base de données. Quand tu seras habitué, tu l'appliqueras sans t'en rendre compte  

Evite de nous présenter ton problème à l'extérieur du forum. Si le lien vient à se perdre, les solutions proposées ici n'auront plus de questions auxquelles elles répondent.

------------------

Or donc. Pour commencer, je ne vois pas le dictionnaire de données. Tu passes directement au MCD. Vas-y pas-à-pas.

- Ok, c'est vrai qu'à la base je suis pas un pro des BDD mais bon ^^

- J'ai séparé pour être plus clair, mais le résultat final je pourrais le mettre dans un unique message il n'y a pas de soucis.

- En fait je n'ai eu qu'un cours sur Merise, et le reste j'ai regardé sur internet. Mais je en vois pas ce que tu veux me dire par dictionnaire de données. Il faut "lister" les Entités et liaison c'est ça ?

Ce qu'il m'a été demandé de faire, c'est un schémas comme j'ai commencé à le faire.
Pour m'aidé, à la main, j'ai simplement souligné els mots dans le texte pour repéré les entités.
http://ben.blog.free.fr/ccm/index2.php

Qu'est-ce que tu en penserais de ça ? S'il y a des choses à changer, rajouter... ?

au vue de ton lien avec le shema cela me semble claire !
peu tu nous dire ta dificulter !

Pour me facilité la vie avec Merise j'ai utilisé une série de question basic (tres basic) : afin de passé du texte au shema (dont tu dispose déjà)


Qui fait quoi ?
Quand cela est fait ?
Pourquoi (but) ?
Avec quoi ?


Si tu prend ton shema tu voie que la "Facture" est l'élément central du shéma !

Tu auras une base Client (car la facture est bien destiner a "x" dans le but de se faire remuner un bien ou/et service)

cela te determine ton type de lien (entre la facture et le client)
=>le type de lien entre la table Client et l'élément facture.

Avant de concevoir les entités, et les liaisons, tu dois recenser toutes les champs dont tu as besoin. Répartir ces champs entre entités et liaisons, c'est seulement la seconde étape.

Ok zeb.

chonos : Comme c'est la première fois que j'ai à en faire, je ne suis pas sûr du tout ^^
Au niveau des entités ça me semble correct, bien que je ne suis pas certain de qui va être raccroché où.

C'est surtout au niveau des liaisons. Et des "mots clés" comme "temps variable" ou "quantité" que je ne sais pas où placer, et s'il y en a d'autre à mettre.
("quantité" est au bon endrois, c'est le seul truc que j'ai réussit à savoir que c'était bon =) )

Donc en fait je voulais simplement savoir, si il y a une personne qui s'y connait, qui pourrait me dire si il trouve cela bon, ou si il l'aurait fait autrement, ou si il y a juste quelques petites modif...

Merci pour votre intérêt  

Zeb a raison j'ai griller une étape !


il faut que tu balaie tous les éléments que tu auras besoin !
mais parfois pour comprdre les chose il faut se planter un peu, car quand on se plante et qu'il faut faire des modif pour rectifier c'est pas toujours simple et cela fait parfois pas mal de boulot en plus !!

exemple : un champs : nom&prénom ou société n'est pas conseiller !
il faut mieu un champs : "Nom" un autre pour "Prénom" ; un autre pour "Société"

Si tu est claire dans tes choix il te sera plus facil de faire une requette dans la quel le tu trouveras la réponse a ta demande

pour compredre se que je te dit :

une Ste avec un nom comme "SIMMON" dont le fondateur a donner son nom de famille a son entreprise donc "SIMMON"

Si tu as a titre personnel M. Simmon comme client et ne faut pas le confondre avec "Simmon" l'entreprise (au niveau de la facturation c'est pas la même chose)

voilà

Ok, merci pour tes précisions.

J'ai fais ce que vous m'aviez dis, en listant les entités et liaisons. Je n'ai rien trouvé à modifier...


Je me suis attaqué aux cardinalités, c'est pas encore el plus simple x)
J'y ai compris le principe, il faut mettre deux chiffre, le minimum,maximum mais je n'arrive pas à bien comprendre le fonctionnement.
Pour mon entité Client, je ne sais pas si la cardinalité dit "il y a cmb de clients pour une facture" ou "un client peut aller dans combien de facture"
Il y a des petites nuances que je saisi pas trop.

Vous auriez des petits "trucs" pour vérifier simplement ?
Voilà ce que j'ai "trouvé" : http://ben.blog.free.fr/ccm/index2.php

Pour le Client : (je dirais qu'il a besoin des champs  

ID client :
Nom :
Prénom :
Société (raison social): EDF
Adresse (du demandeur) : 0, rue de l'électicité
CP : 75000
Ville : Paris
Pays : France

Adresse de Facturation : 45, de la facture
CP : 94000
ville : Les ulis
Pays : France

Adresse de (livraison /travaux/service a éffectué) : 3, Rue de la mer
CP : 29200
Ville : Brest

Pourquoi me diras tu y coller une ID ? et bien si la raison social change et qu'il est toujours client cela ne te pauseras pas problème tu conserveras le même ID et l'historique qui le conserne !

j'ai mis 3 type d'adresses car avec certains type de client (les moyens et gros tructure (plus d'un site) tu as souvent une repartition des services !

Ok marche, je note cela  
(sur mon brouillon informatique je vais laisser le minimum)


Est-ce que tu pourrais me dire quelques mots sur les cardinaux stp ?

Merci  

Spitulo, il faut avant tout faire une liste de tous les champs dont tu as besoin.
C'est à partir de cette liste que l'on construira les entités.

Que tu penses ne rien avoir oublier par rapport à ton MCD final est exactement ce qu'il ne faut pas faire ! Et si tu en étais sûr, tu ne viendrais pas nous demander de l'aide.

Si Merise s'appelle une méthodologie, c'est pour qu'elle soit respectée.

1) Dictionnaire (1ère forme normale)
2) Entités, relations (2ème forme normale)
3) Cardinalités (3ème forme normale)

Il sera ensuite temps d'en faire un MPD.

Ok, mais je l'ai refait depuis le début, en faisant le dictionnaire.

Et j'arrive au même point (je n'ai pas noté l'ensemble des champs de chacunes des entités sur le brouillon : http://ben.blog.free.fr/ccm/index2.php )

Donc je me suis pas plus attardé dessus...

J'essaye là de voir les cardinalités pour terminer.

LES INFORMATIONS DOIVENT ETRE DONNEES SUR LE FORUM !

 
Tu me refous un n-ième lien vers ton site, je te bannis à vie.
Et arrête de faire des trucs sur ton brouillon, montre-nous ce que tu fais.
Comment veux-tu qu'on t'aide ?

Quelques liens  



http://www.commentcamarche.net/contents/merise/concintr...

http://eli.j.free.fr/boulot/coursbts1/ch2_Ref_Merise.pd...

http://www.infoberk.net/downloads.html (utilise Cours et pratique)

http://www.cmi.univ-mrs.fr/NTI/documents/Merise-Support...

Si je sépare mon "énoncé" et mon gros graphique qui me sert de brouillon c'est pour ne pas inonder ce forum et également pour modifier plus facilement le brouillon avec l'aide que vous pouvez m'apporter.

Sincèrement, je ne vois pas en quoi cela gène la visibilité. De plus, comme je l'ai dis, je mettrais à la fin l'image, ou une représentation de mon travail, sans liens etc.

C'est pas de la pub pour mon site, j'ai fais cette page exprès pour y mettre cela.

"Et arrête de faire des trucs sur ton brouillon, montre-nous ce que tu fais."
C'est justement ce que je fais ^^



chonos : merci pour les liens, je vais regarder ça  

spitulo,

Si Zeb te dit quelque chose merci de le prendre en compte

Le Forum a une méthode de fonctionnement elle n'est peut-etre pas la meilleur mais il faut bien en avoir une ! Elle n'est pas celle dont tu est le plus fane, mais c'est comme cela !

pour ma part cela ne me dérange pas ta façon de te faire aider avec ta page web, et j'avoie tres volontier que je ok avec toi mais il y a des règles que les modo sont les gardiens et qu'il faut du mieux que possible les respecter !

voilà a+  

(Eh ben !   )

Bin je vais me montrer discipliné, voilà le recopiage de ce que j'ai fais jusqu'à présent :

Enoncé du travail : Une entreprise BTP (Bâtiments et Travaux Publics) veut informatiser son système de gestion des factures.
Chaque facture prend en compte le prix des matières premières utilisées et leurs quantités ainsi que la prestation. Chaque matière première appartient à une catégorie. Chaque prestation peut nécessiter plusieurs engins, pour un temps variable. Il arrive que l'entreprise retourne chez un même client pour faire d'autres interventions.

Liste d'entités : Facture, Matière première, Prestation, Catégorie, Engins, Client.

Liste de données à utiliser : Prix(MP), Quantité(MP), Temps.


Schémas :


Voilà où j'en suis. Je stagne sur les cardinalités que je ne suis pas sûr. Je ne refuserais pas une validation de votre part (maintenant que j'ai assimilés les règles du forum  ).

Ah, c'est mieux.

(N'empêche que le fait d'utiliser une seule image qui évolue ne permet pas de voir la progression. Ce que tu sembles ne pas comprendre, c'est l'intérêt du forum. Nous t'aidons, à la condition que le fruit de notre collaboration reste publique, de manière à ce que tout un chacun puisse en profiter.)

Bon, t'es borné comme un âne, tu ne veux pas me faire ma liste. Mais tu sembles avoir fait un gros effort, alors je vais te montrer.

As-tu entendu parlé des 3 formes normales ?
Non. Alors zou, un peu de lecture : http://fr.wikipedia.org/wiki/Forme_normale_%28bases_de_...

facture

montants de matières premières

quantité de matières premières

prix de prestation

temps de prestation

catégorie

engins

temps d'engins

client

Bon. Je suis un peu habitué à faire des audits dans une entreprise. On te balance des infos évidentes, mais on en oublie la moitié.
Il me semble que ce qui caractérise une facture, c'est le client (ça c'est vu) la date (oubliée) et par son montant, non ?

Le prix d'une matière première, ça n'existe pas. Les prix, ça existe. C'est une information qui fluctue dans le temps (cf. 1ère forme normale). Pareil pour tous les prix, donc.

Un engin, ça se caractérise par son nom, et par son coût horaire.

Un client, ce qui le caractérise, c'est son nom (de famille pour un particulier, sa raison sociale pour une entreprise) et son adresse (pour y retourner   ).

Donc j'ajoute :

date de facture

montant de facture

montants de matières premières

coût unitaire de matières premières

date du coût de matières premières

nom de l'engin

montant de l'engin

coût horaire de l'engin

date du coût horaire de l'engin

montant de prestation

coût horaire de la prestation

date du coût de prestation

nom du client

adresse du client

nom de la catégorie

nom de matières premières

Et on vite facture, engin client et catégorie qui ne sont pas des champs.

Ca nous donne :

adresse du client

coût horaire de l'engin

coût horaire de la prestation

coût unitaire de matières premières

date de facture

date du coût de matières premières

date du coût de prestation

date du coût horaire de l'engin

montant de facture

montant de l'engin

montant de prestation

montants de matières premières

nom de l'engin

nom de la catégorie

nom de matières premières

nom du client

prix de matières premières

prix de prestation

quantité de matières premières

temps d'engins

temps de prestation


Ceci est notre dictionnaire de données.

Il faut maintenant isoler les entités en fonction de ces champs.
Dire de quoi chacun dépend, et l'on identifie ce qui est calculé :

adresse du client --> client

coût horaire de l'engin --> marché de l'engin

coût horaire de la prestation --> marché de la prestation

coût unitaire de matières premières --> marché des mp

date de facture --> facture

date du coût de matières premières --> marché des mp

date du coût de prestation --> marché de la prestation

date du coût horaire de l'engin --> marché de l'engin

montant de facture --> somme des prix (calculé)

montant de l'engin --> temps * coût d'engin (calculé)

montant de prestation --> temps * coût de la prestation (calculé)

montants de matières premières --> quantité * coût de mp (calculé)

nom de la catégorie --> catégorie

nom de l'engin --> engin

nom de matières premières --> matières premières

nom du client --> client

prix de prestation --> temps * coût de prestation (calculé)

quantité de matières premières --> facture, matières premières

temps d'engin --> prestation, engin

temps de prestation --> prestation

On trie par dépendance et on retire ce qui est calculé :

catégorie --> nom de la catégorie

client --> adresse du client

client --> nom du client

engin --> nom de l'engin

facture --> date de facture

facture, engin --> temps d'engin

facture, matières premières --> quantité de matières premières

marché de l'engin --> coût horaire de l'engin

marché de l'engin --> date du coût horaire de l'engin

marché de la prestation --> coût horaire de la prestation

marché de la prestation --> date du coût de prestation

marché des mp --> coût unitaire de matières premières

marché des mp --> date du coût de matières premières

matières premières --> nom de matières premières

prestation --> temps de prestation


On assemble par entité :

catégorie(nom)

client(adresse, nom)

engin(nom)

facture(date)

marché de l'engin(coût, date)

marché de la prestation(coût, date)

marché des mp(coût, date)

matières premières(nom)

prestation(temps)

Il reste deux relations :

prestation, engin --> temps d'engin

facture, matières premières --> quantité de matières premières

Pour les entités, on ajoute un identifiant. Pour les relation, on invente un nom, et on ajouter les clefs étrangères.

catégorie(id_cat, nom)

client(id_cli, adresse, nom)

engin(id_eng, nom)

facture(id_fac, date)

marché de l'engin(id_m_eng, coût, date)

marché de la prestation(id_m_pre, coût, date)

marché des mp(id_m_mpr, coût, date)

matières_premières(id_mpr, nom)

prestation(id_pre, temps)

prestation_engin(#id_fac, #id_eng, temps d'engin)

facture_mpr(#id_fac, #id_mpr, quantité de matières premières)

Maintenant les liaisons.

catégorie [1,1]--->[0,n] matières premières
On peut en effet définir une catégorie, sans pour autant avoir de ces matières premières.
Par contre, telle matière première n'appartient qu'à une seule catégorie.

matières premières [0,n]<---[1,1] marché des mp

prestation [0,n]<---[1,1] marché de la prestation

engin [0,n]<---[1,1] marché de l'engins
Même réflexion.

client [0,n]<---[1,1] facture
Et si le client est dans la base de données parce qu'on a fait un devit, mais pas encore une facture ?
Une facture ne vise qu'un client.

facture [1,1]<--->[1,1] prestation
Ah, une liaison 1,1<-->1,1.
C'est un cas particulier. Il faut pour respecter la 2ème forme normale les confondre !
Il s'agit den fait d'une seule et même entitié.

Et voilà le travail.

Observe que j'ai ajouté une référence pour la facture.
J'ai aussi dénormalisé les tables "marché" pour n'en faire qu'une. C'est une violation des formes normales, mais ça diminue le nombre de tables en clarifiant les choses. C'estun grand classique. Puisque c'est un exercice scolaire, il faut que tu présentes la version précédente où que tu justifies celle-ci.

Je vais pas revenir sur le fait que je suis borné etc, je pense être - au fond- dans la même philosophie que toi et que le forum en général, simplement j'utilise des méthodes inabituelles pour ici. Mais sur d'autres forum ils refusent d'inonder des sujets avec des tonnes d'images par exemple, enfin bref ça dépend de chacun.
Moi personnellement, je m'en fiche, je veux bien mettre tout ici, cela ne me pose pas de problèmes. Bien que me comparer à un âne me va aussi parfaitement   (pas physiquement non plus mais bon).
_________________________________________________________________________________

Merci beaucoup pour ton explication très détaillée. J'ai vu plus concrètement ce que tu me recommandais, et je vais m'en resservir pour mes autres travaux  

Je n'ai pas tellement de questions sur ce que tu m'indique, ça me parait logique et j'ai bien saisi la façon de procéder.
Notamment pour les cardinalités.
Quoique, je pourrais te demander une chose à ce propos : Est-ce que c'est systématique de rassembler deux entités qui ont des cardinalités [1,1]...[1,1] ?


Et sinon, ma seule interrogation porterait sur trois entités que tu a ajouté (par rapport à ce que j'avais fait précédemment) qui sont "marché engin" "marché prestation" et "marché mat. prem.".
Et comme tu le signifie, c'est un travail scolaire, censé donc être simple. Or, je ne sais pas s'il est utile de décortiquer autant de ce côté ?

Et si il vaut mieux le faire comme cela, je n'ai pas bien compris pourquoi tu ajoute celles-ci dans ton raisonnement, ne pourrait-on pas se servir des entités "prestation" "mat. prem." et "engin" directement ?


Pour terminé : "temps" et "quantité" que tu inscris dans leur bulles jaunes, sont bien deux variables qui agissent entre leures deux entités respectives ?


Merci encore.
(je ne vais pas actualiser l'image de mon ancien post, mon travail final, je vais le mettre à la fin, bien que ce que tu as fait est déjà bien avancé ^^ )

Salut Stipulo,

Il y a la Loi : ce sont les formes normales. La norme quoi.
Alors oui, il faut rassembler les entités [1,1]<-->[1,1].

Et puis, il y a la pratique. Quand celle-ci viole la norme, on parle de dénormalisation. Et c'est tout à faire légitime. Je t'en donne un exemple avec la fusion des tables "marché".

Je reviens sur les entités [1,1]<-->[1,1].
Dessiné sur un MCD, ça ne pose pas de problème. Mais comment vas-tu faire ton MPD ? La clef étrangère de l'un dans l'autre ? Mais comment retrouver l'un quand on n'a l'autre ? La clef étrangère de l'un dans l'autre et vice versa ? Mais comment garantir l'intégrité référentielle ? Une table de liaisons ? Euh, non. Je ne pense pas que ce soit une bonne idée. Bref, à moins d'une excellente raison fonctionnelle, il n'y a aucune raison technique pour ne pas fusionner deux entités [1,1]<-->[1,1].

C'est d'ailleurs ton boulot d'informaticien : parler toutes les langues de l'entreprise. Un système d'information central touche tous les métiers. Le patron, le comptable, le gérant du stock. Tous ont une idée de ce qu'il faudrait mettre dedans. Et il faut tous les auditer. Et souvent, ils parleront d'une même entité avec des mots différents, issus de leur jargon respectif. Ce sera à toi de constater sur ton papier, que ces entités ne doivent devenir qu'une seule table.

Ok, c'est noté, je procèderai comme cela.

Pourrais tu revenir sur les entités "marchés" s'il te plait ?

Tout ce qui s'achète est soumis aux dures lois du marché. Les prix fluctuent. C'est un fait.

Par ailleurs, voici l'énoncé de la première forme normale, d'après Wikipédia :

Il me semble que le dernier point correspond bien à notre problème.

Il me semble donc évident qu'on ne peut pas stocker le prix dans la table matières premières, puisqu'il n'y en a pas qu'un, mais plusieurs, dépendant d'une date.

Zeb,

Une question,

Pourquoi ne tiens tu pas compte des différentes adresse possible du client (adresse de facturation /livraison-travaux/siège...) ?

Parce que ce n'est pas dans l'énoncé.
Et qu'une adresse, c'est fixe. Même si on peut déménager, il n'y a pas de raison de garder l'ancienne adresse. Au contraire.

Mais il est fort possible de faire une entité types d'adresses, et une entité adresse. Avec une relation Client [1,1]-->[1,n] Adresse bien sûr.

Bonjour,
Désolé pour cette réponse un peu tardive, mais je viens juste de récupérer la correction du travail.

Donc j'ai repris en gros ce que tu as fais Zeb, sauf les entités marché que je n'ai absolument pas compris, et qu'apparemment il n'était pas nécessaire de mettre.
Comme je ne suis qu'au début de l'apprentissage de Merise, il ne m'est sans doute pas dans l'obligation de rentrer dans les détails.

Voilà donc ce que j'ai fini par faire, avec les corrections ajoutés :
http://img186.imageshack.us/img186/4874/brouillono.png


J'ai indiqué par des éoiles rouges mes erreurs.


Merci encore à vous pour votre aide.
Avec ça, j'ai quand même mieux compris le principe, j'espère que le suivant, j'y arriverais plus facilement