Discussion :

[waldi084]

Bonjour a tous ;-)

pourriez vous me dire de ce que vous pensez de mon MCD

qui concerne le fonctionnement d'un magasin d'informatique

[Richard_35]

Bonjour Waldi084,

A vue de nez, sans les règles de gestion précises :

• 1 même article peut servir à n réparation, non ?
• vérifier si 1 commande peut être facturée en plusieurs fois

[CinePhil]

1) La ville devrait être externalisée dans une entité de référence pour éviter d'avoir plusieurs fois la même ville sous des orthographes différentes.

2) Pourquoi y a t-il la TVA dans l'entité client ?

3) Selon votre schéma, la commande engendre immédiatement une facture... même si la commande ne peut être honorée ?

4) Selon votre schéma, un article nécessite obligatoirement une réparation. Sont pas de bonne qualité vos articles !

Et une réparation peut être nécessitée par plusieurs articles !

Je pense que les cardinalités sont inversées.

5) Type_reparation pourrait lui aussi être externalisé dans uen entité de référence.

6) Je ne vois aucune notion de prix dans votre schéma !
Tout est gratuit ?

[waldi084]

Merci pour votre aide
je débute en analyse :-(

[waldi084]

1) La ville devrait être externalisée dans une entité de référence pour éviter d'avoir plusieurs fois la même ville sous des orthographes différentes.

2) Pourquoi y a t-il la TVA dans l'entité client ?

3) Selon votre schéma, la commande engendre immédiatement une facture... même si la commande ne peut être honorée ?

4) Selon votre schéma, un article nécessite obligatoirement une réparation. Sont pas de bonne qualité vos articles !

Et une réparation peut être nécessitée par plusieurs articles !

Je pense que les cardinalités sont inversées.

5) Type_reparation pourrait lui aussi être externalisé dans uen entité de référence.

6) Je ne vois aucune notion de prix dans votre schéma !
Tout est gratuit ?

Pour la ville, j'avais pas pensé !!!
2) TVA c'est si le client a un n° de tva
3) la facture devrait se trouver a un autre endroit ???
4) j'ai voulu dire qu'une reparation peut necessité des pieces
5) oui c'est aussi une bonne idée
6) si dans article j'ai prix de vente

Super je vais avancer un tout grand merci

[Gannox]

Petites remarques :

1) Au passage, en ce qui concerne les entités de référence, autant en consacrer une autre à "type article" puis une autre à "type" (entité Commande) si déjà on en consacre une à "type réparation".

2) La plupart des entités comportent un id avec juste en dessous un libellé. Dans l'entité "Commande", on pourrait alors avoir id_commande, libelle_commande, etc... à rajouter si besoin est.

[waldi084]

voila une autre version

ca vous parrait mieux ??

[Gannox]

Je ne comprends pas l'intérêt de l'association "demander" entre les entités "Réparation" et "Commande". Une réparation se fait au niveau d'un article ou alors je renommerais "demander" par "concerne".

Tu n'as pas fais d'entités de référence pour "type_article" et "type_commande" ?

Rajoute une propriété de libellé (ou nom) pour les entités "Commande" et "Article", ainsi que pour les entités "Facture" et "Fournisseur" car ce serait plus logique d'avoir plus d'informations sur ces ensembles qu'un simple identifiant.

[waldi084]

ok merci je vais faire ces changements.

et en plus j'ai cour d'analyse ce soir, je vais travailler dessus
puis je publierai mon travail demain

[waldi084]

Salut a tous ;-)


voila j'ai fait une nouvelle version qu'en pensez vous ?

[Gannox]

Soit je me trompe lourdement, soit il a changé un maximum ton MCD ! Soyons clairs : on est d'accord que client est devenu contact, commande est devenue document ?

Où est passée l'entité Réparation ? Plus besoin d'elle ?

L'entité "Type_document" contient (id_type_commande, libelle_type_commande) donc si tu gardes le nom de "Type_document" au lieu de "Type_commande" : autant écrire directement (id_type_document, libelle_type_document).

Plus d'entité Facture ni d'entité Fournisseur non plus. J'ai loupé un épisode dans lequel tu reprenais en entier ton MCD ? En fait, il faudrait que tu nous éclaircisses sur les modifications que tu as toi-même effectué et sur tes règles de gestion. Difficile de dire en réalité si tu as tout juste ou tout faux tant qu'on a pas un énoncé du problème valide et non modifiable dans le temps.

[CinePhil]

Si j'ai bien compris, tu as voulu rassembler les commandes et les factures dans l'entité générique "Document". Tu es allé un peu vite et fort en besogne !
Une facture n'est pas une commande et vice-versa mais il est vrai que ce sont deux documents qui se ressemblent par leurs propriétés. On pourrait éventuellement faire un héritage de données mais pas sûr que ce soit pertinent.

Comme l'a suggéré Gannox, donne nous tes règles de gestion des données pour qu'on puisse analyser ton MCD plus efficacement.

[waldi084]

Bonjour, et merci pour votre aide ;-)

voila dans contact se trouve (les clients, les employés, les foutnisseurs etc..)
ils sont définis dans l'entité type_contact

ces contacts sont lié a des documents (bon de commande client, bon de commande fournisseur, devis client, facture client, facture fournisseur etc...)
ils sont eux definis dans l'entité type_document

les articles peuvent etre du materiel, des logiciels, des reparations etc....
ils sont définis dans type_article

les articles sont eux dans un stock qui augmente avec par exemple un bon de livraison d'un fournisseur, et qui diminue via un facture client.

je sais pas si je suis très clair.
Et je sais pas si je suis dans le bon, ou si je m'en éloigne ???

merci d'avance pour vos conseils ;-)

[CinePhil]

C'est bien ce que je disais, tu as rassemblé des concepts différents dans une seule entité et c'est dangereux. Ton schéma n'interdit en effet pas que le contact C1 de type Client soit associé avec le document D1 de type facture fournisseur !

Je te recommande de recommencer en détaillant les concepts dans des entités différentes et nous verrons ensuite les généralisations qui peuvent être pratiquées en utilisant l'héritage de données.

Petit exemple...

Règles de gestion :
1) Un fournisseur est un contact et un contact peut être un fournisseur.
2) Un achat est passé à un fournisseur et un fournisseur peut recevoir plusieurs achats.
3) Un achat est un document et un document peut être un achat.

MCD :
contact -0,1----être----(1,1)- fournisseur -0,n----recevoir----1,1- achat -(1,1)----être----0,1- document

Règles de gestion :
4) Un client est un contact et un contact peut être un client.
5) Une commande est passée par un client et un client peut passer plusieurs commandes
6) Une commande est un document et un document peut être une commande.

MCD complété :
contact -0,1----être----(1,1)- fournisseur -0,n----recevoir----1,1- achat -(1,1)----être----0,1- document
|------------0,1----être----(1,1)- client -0,n----passer----1,1- commande -(1,1)----être----0,1-----------|

Il y a bien séparation entre fournisseur et client qui sont pourtant tous deux des contacts et séparation entre commande et achat qui sont pourtant tous deux des documents.

[Gannox]

voila dans contact se trouve (les clients, les employés, les foutnisseurs etc..)
ils sont définis dans l'entité type_contact

ces contacts sont lié a des documents (bon de commande client, bon de commande fournisseur, devis client, facture client, facture fournisseur etc...)
ils sont eux definis dans l'entité type_document

les articles peuvent etre du materiel, des logiciels, des reparations etc....
ils sont définis dans type_article

les articles sont eux dans un stock qui augmente avec par exemple un bon de livraison d'un fournisseur, et qui diminue via un facture client.

Bien bien bien. Alors par où commencer ? Déjà, il nous manque toujours tes fameuses règles de gestion qui sont INDISPENSABLES au bon déroulement de la création de ton MCD. Ce qui m'amène à te poser la question suivante : vois-tu à quoi correspond ce concept de règles de gestion ou pas du tout ?

Si ce n'est pas le cas, pour résumer la chose, il s'agit d'un ensemble de règles strictes élaborées avant la phase de conception du MCD et destinées à garantir de manière logique le bon fonctionnement de ton système d'informations.

Cela correspond à un ensemble de phrases de ce type :

- Un article peut faire l'objet d'aucune réparation comme il peut faire l'objet de plusieurs réparations simultanément
- Un fournisseur fournit au minimum un article à un magasin.
- Un stock contient au minimum un article et peut naturellement en contenir plusieurs
- Une commande, peu importe laquelle, concerne au minimum un article et au maximum plusieurs
- etc...

Ce sont des faits, des affirmations logiques qui permettent de modéliser ton système d'information grossomodo. Si tu as ces informations sur toi, prière de nous les transcrire

Sinon, sincèrement peut-être que je me trompe, mais l'ancien MCD est de bien meilleure qualité que celui que tu viens de nous montrer.
Sur l'ancien, il était justement renseigné de manière claire et précise les différences entre les entités.

Prenons CLIENT et FOURNISSEUR. Un client et un fournisseur sont tout les deux des êtres humains on est d'accord mais ils n'ont pas les mêmes rôles au sein de ton magasin tu comprends ? Un client achète un article et un fournisseur fournit au magasin un article. Il en va de même avec COMMANDE et FACTURE car les deux papiers ne remplissent pas les mêmes rôles.

Au passage, tu dis qu'un "article peut être une réparation". Peux-tu être plus précis ? Pour moi, un article peut être réparé mais pas être une réparation

Enfin, je dois avouer qu'ajouter une gestion de stock des articles est cependant une bonne idée de ta part il faudra juste penser à lier l'entité STOCK aux entités ARTICLE et FOURNISSEUR car un article se trouve dans un stock précis et c'est un fournisseur qui alimente ce stock (supposition).

[waldi084]

merci pour toutes vos explications ;-)

j'ai en fait agis sur les conseils d'un copain en classe, mais
c'est vrai que je trouvais plus clair mon premier mcd

je vais essayer de suivre vos conseils et je reviendrai
vers vous ensuite, j'ai encore cour d'analyse aujourd'hui

[waldi084]

Salut voila en fait j'ai du choisir un thème, sur lequel faire une analyse

j'ai choisi "la gestion d'un magasin d'informatique"

je n'ai pas de contrainte particulière mais faut juste un truc qui tienne la route

c'est pourquoi je n'ai pas de règle de gestion precise.

pourriez vous m'aider tout de meme ?

[CinePhil]

Si on ne t'impose pas de règles de gestion, à toi de les écrire. Ton projet tiendra mieux la route s'il est posé sur un châssis solide (les règles de gestion des données) que sur une caisse en carton (le MLD direct vite fait).

[waldi084]

Ok, c'est vrai je ferais mieux de les faires ces règles
je vais y travailler.

merci de votre aide ;-)

[waldi084]

Bonjour a tous, j'ai fais une nouvelle version
que je pense un peu plus aboutie.

Qu'en pensez-vous ?