Discussion :

[omarito15]

Bonsoir
Je suis entrain de developper une application gestion commerciale, au niveau de conception j'ai realisé un mcd qui manque une validation.Donc merci de vous poster vos remarques .

[chewing-gum]

Bonjour,

premier problème concernant les associations "facturer", "livrer" et "passer" entre les entités "CLIENT" et "COMMANDE". Les cardinalités ne me semblent pas correctes.
En effet, une commande est bien passée par un et un seul client.
Mais si tu utilises les cardinalités 1,1 pour la facture et la livraison, cela signifie que le client est livré et facturé au même moment que lorsqu'il passe une commande ! Ce qui est impossible.
En suivant l'ordre chronologique des évènements de gestion, on se rend compte que le client passe d'abord une commande. Puis, la facture est émise par l'entreprise. Enfin, la commande est livrée.

Solution : tu dois changer les cardinalités de l'association "facturer" et "livrer", et mettre 0,1 au lieu de 1,1.

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

Le "type client", qui est actuellement une propriété, devrait être une entité :
TYPE_CLIENT(id_client, libellé_client)
De même pour la propriété "sexe client".

A quoi correspond la propriété "nom société" de l'entité "CLIENT" ?
S'il s'agit de la même propriété "nom société" contenue dans l'entité "Info_Société", alors l'information est redondante.

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

Je ne m'y connais pas vraiment en code barres, mais je dirais que c'est le code barres qui identifie l'article. A une condition : que le code barre soit unique et stable dans le temps.

[omarito15]

Merci monsieur chewing de votre reponse ;

Bonjour,

premier problème concernant les associations "facturer", "livrer" et "passer" entre les entités "CLIENT" et "COMMANDE". Les cardinalités ne me semblent pas correctes.
En effet, une commande est bien passée par un et un seul client.
Mais si tu utilises les cardinalités 1,1 pour la facture et la livraison, cela signifie que le client est livré et facturé au même moment que lorsqu'il passe une commande ! Ce qui est impossible.
En suivant l'ordre chronologique des évènements de gestion, on se rend compte que le client passe d'abord une commande. Puis, la facture est émise par l'entreprise. Enfin, la commande est livrée.

Solution : tu dois changer les cardinalités de l'association "facturer" et "livrer", et mettre 0,1 au lieu de 1,1.

oui vous avez raison que une commande peut être annuler cela conclut que la commande ne peut etre pas livrer ou facturer
------------------

Le "type client", qui est actuellement une propriété, devrait être une entité :
TYPE_CLIENT(id_client, libellé_client)
De même pour la propriété "sexe client".

oui on peut sortir la prorieté sexe et type et les transformer en entité

A quoi correspond la propriété "nom société" de l'entité "CLIENT" ?
S'il s'agit de la même propriété "nom société" contenue dans l'entité "Info_Société", alors l'information est redondante.

infor sociéte concerné les informations de la socité qui utilisera ce system

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

Je ne m'y connais pas vraiment en code barres, mais je dirais que c'est le code barres qui identifie l'article. A une condition : que le code barre soit unique et stable dans le temps.

un article peut se livrer par plusieurs fornisseur, sera implique que le prix d'achat d'un seul article peut se varier selon le fournisseur . donc j ai mit l'entité code bar pour connaitre premièrement le fournisseur de ce article contenant le code bar et deuxièmement si un retour est possible je peut connaitre facilement le prix d'achat de cet article

[seabs]

Bonjour,

Au passage, quelques remarques :

L'entité Fournisseur et l'entité Client sont identiques pour de nombreux attributs. Il serait peut être préférable de faire une entité Identification, puis de procéder par héritage pour distinguer les fournisseurs et les clients. Tu peux t'aider avec cette discussion http://www.developpez.net/forums/d77...n-commerciale/

Votre approche de l'entité Commande suppose qu'une commande est livrée en une seule fois. C'est possible, mais il peut y avoir des exceptions.

L'entité Devis me semble bien seule, il doit pouvoir passer en commande ou devenir sans objet.

Malgré ton explication, je comprends pas très bien l'utilité de l'entité Info_société et sa liaison avec l'entité Compte_bancaire.

En clair, je pense que l'analyse préalable à la construction du MCD est insuffisante. Il faut dans un premier temps fixer les règles de gestion, puis concevoir le MCD. Or, dans votre cas, il existe une approche qui vous conduira vers des difficultés voire des impossibilités pour mettre en œuvre votre base de données.

N'oublies pas de regarder, dans ce forum, les discussions qui ont déjà traité ce sujet qui est récurrent.

En général, pour que nous puissions vous aider, il faut présenter, en appui de votre MCD les règles de gestion.

Ne pas oublier d'indiquer la base de données utilisée, cela permet de mieux comprendre vos choix.

Bon courage pour la suite.

[JPhi33]

Bonjour,

En effet, une commande est bien passée par un et un seul client.
Mais si tu utilises les cardinalités 1,1 pour la facture et la livraison, cela signifie que le client est livré et facturé au même moment que lorsqu'il passe une commande ! Ce qui est impossible.
En suivant l'ordre chronologique des évènements de gestion, on se rend compte que le client passe d'abord une commande. Puis, la facture est émise par l'entreprise. Enfin, la commande est livrée.

Cette réflexion mérite qu'on s'y attarde un peu.

En effet, ces questions de chronologies sont fréquemment sources d'erreurs de modélisation. Il n'y a pas d'ordre chronologique dans un MCD. Une association ne peut pas être chronologiquement antérieure ou postérieure à une autre (sauf dans de rares cas, en relation avec les contraintes sémantiques). La chronologie, c'est l'affaire des modèles dynamiques du S.I. (pour Merise : MCT, MOT, etc.) Le MCD, lui, fait partie des modèles statiques où le temps est un invariant.

Les 3 associations dont il est question sont incorrectes mais pour une autre raison que je développe ci-dessous

Ce qu'on peut dire du MCD de omarito15, c'est qu'une Commande est :
- passée par un Client
- livrée à un Client
- facturée à un Client

A cause de la modélisation des 3 associations, rien n'interdit que ces 3 clients puissent être différents.
Exemple : La commande 1 est passée par le client A, elle est livrée au client B et facturée au client C. Résultat : 3 clients mécontents .

Cette erreur trouve son origine dans la confusion (ou le mélange) que l'on peut faire entre les aspects statique et dynamique du Système d'Information. Merise veut que l'on sépare sans aucune ambiguïté ces deux aspects. Ici, omarito15 est malheureusement "tombé dans le panneau" (qu'il ne m'en veuille pas, il n'est pas le premier).

Si l'on s'en tient aux entité modélisées, les actions "passer", "livrer" et "facturer" sont des états successifs de la commande ; on retrouve ici la chronologie évoquée plus haut. Ces états entrent dans la modélisation dynamique (MCT, MOT, cycle de vie, etc.) mais pas dans les modèles statiques.

Une modélisation correcte serait la suivante :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
                [Date]
                   |
                  1,n
                   |
                   |
[État]--0,n----(Chrono)----1,n--[Commande]--1,1----(CIF)----0,n->[Client]

Légende :
-------------
[ENTITE]
(ASSOCIATION)
( ) = CIF

Une Commande est liée à 1 et 1 seul Client.
La commande passe par plusieurs états au cours de son cycle de vie, dont les états "passée", "livrée", "facturée".

[chewing-gum]

Il n'y a pas d'ordre chronologique dans un MCD.

Je trouve que c'est un peu vite dit.

Regardons votre modèle : différents états de la commande se succèdent à des dates différentes. Parler d'une entité "Date", c'est tout simplement admettre qu'il y a une chronologie, notamment au niveau des états de la commande.

Bien sûr, un modèle conceptuel de données n'est pas spécialement fondé sur "l'ordre chronologique", et je ne remets pas en question le fait que c'est un modèle statique.

[fsmrel]

Bonsoir les amis,


Permettez-moi de participer à la joyeuse ronde...

Une modélisation correcte serait la suivante :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
 
                [Date]
                   |
                  1,n
                   |
                   |
[État]--0,n----(Chrono)----1,n--[Commande]--1,1----(CIF)----0,n->[Client]

Légende :
-------------
[ENTITE]
(ASSOCIATION)
( ) = CIF

Comme nous ne sommes pas dans un univers quantique (si tant est que le temps y ait une signification qui soit la nôtre), je verrais volontiers la mise œuvre d’une CIF de telle sorte qu’au même moment une commande ne puisse pas se trouver dans deux états différents :

COMMANDE X DATE → ETAT

Et tant qu’à faire, une deuxième CIF serait la bienvenue :

COMMANDE X ETAT → DATE

D’où la partie correspondante du MCD (Power AMC + pointes de flèches à la main) :

Et du MLD ("pk" est l'abréviation de primary key, "ak" celle de alternate key et "fk" celle de foreign key) :

J’anticipe, mais sachant par ailleurs que (toujours cette p... d'histoire d’univers non quantique), si les états doivent se succéder selon un ordre précis pour une commande (exemple : "passée" avant "livrée"), il sera prudent, le moment venu, de mettre en œuvre un trigger ad-hoc (évitons de contrôler ce genre de choses dans les applications).

[JPhi33]

Bonjour à tous,

Il n'y a pas d'ordre chronologique dans un MCD.

Je trouve que c'est un peu vite dit.

Effectivement, j'aurais du écrire :

Il n'y a pas d'ordre chronologique entre associations dans un MCD.

Je pensais que ce serait suffisamment clair étant donné que la phrase suivante était

Une association ne peut pas être chronologiquement antérieure ou postérieure à une autre.

Et tant qu’à faire, une deuxième CIF serait la bienvenue :

COMMANDE X ETAT → DATE

Nous ne sommes pas non plus dans un monde idéal
Cette CIF suppose qu'une commande ne passe jamais plus d'une fois par le même état. Or, l'expérience (en tout cas la mienne) montre que ce n'est pas toujours le cas. Les processus de gestion n'étant des vérités scientifiques, les gestionnaires demandent de prévoir qu'un objet de gestion puisse passer par le même état plusieurs fois au cours de son cycle de vie.

Ce qui devrait conduire à cette modélisation :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
                [Etat]
                   ^
                   |
                  0,n
                   |
                 (CIF)
                   |
                  1,1
                   |
[Date]--0,n----(Chrono)----1,n--[Commande]

qui aboutit au même MLD/MR que celui de fsmrel, amputé de la clé alternative {CommandeId, EtatId} (seule la clé disparait, les attributs restent).

[fsmrel]

Bonsoir,

Cette CIF suppose qu'une commande ne passe jamais plus d'une fois par le même état. Or, l'expérience (en tout cas la mienne) montre que ce n'est pas toujours le cas

Nous sommes bien d'accord. Mais dans le cas présent, cette CIF est là pour montrer comment prendre en compte stricto sensu les trois associations-types mettant en relation les entités-types CLIENT et COMMANDE (omarito choisira de respecter ou non ce qu’il a modélisé initialement).


@ omarito

Bien que ce ne soit pas une obligation, vous pouvez vous frotter à la généralisation car les entités-types FOURNISSEUR et CLIENT partagent bien des propriétés communes. A ce sujet, voyez par exemple la discussion avec Heledir (sujet : gestion commerciale, où l’on retrouve du reste une variante simplifiée (pas de chronologie) concernant l’état de la commande...)

Open ModelSphere ne propose pas de représentation ad-hoc pour les MCD merisiens (il ne le fait que pour les diagrammes de classes uéméliens), mais vous pouvez procéder par simulation de l'héritage, comme ici.