Discussion :

[dck21]

Bonjour,

Je travaille sur le developpement d'une application de gestion de stock (première phase) pour une boutique de vêtements.

Cette application doit permettre de gérer les entrées (livraisons) et sorties (ventes) d'articles et d'obtenir un état des stocks.

Chaque article est référencé localement et dispose de plusieurs caractéristiques (taille, couleur...) en fonction de sa famille d'appartenance.

Je voudrais savoir si mon MCD vous semble correct ?

Merci pour vos remarques.

[JPhi33]

Bonjour dck21,

Un modèle est l'abstraction d'une réalité. Sans la description complète de cette réalité, il est difficile de dire si ton modèle est correct. Tu ne donnes que très peu d'indices. Au passage, que signifie "Chaque article est référencé localement" ?

Donc voici quelques remarques sommaires, à la hauteur des "règles de gestion" que tu fournis :

- techniquement le modèle semble correct, il n'y a pas de bourde grossière
- l'entité Clients n'est liée à aucune autre (quel est son intérêt ?)

[dck21]

Bonjour JPhi33 et merci pour tes commentaires.

Quelques précisions :

Le modèle présenté est la représentation d'une gestion de stock de vêtements. Le suivi des entrées (livraisons, retours clients) et des sorties (ventes, retours fournisseur) d'articles permettra au gestionnaire de connaitre l'état du stock à un instant donné ainsi que l'historique des mouvements pour un articles, une famille ou catégorie d'articles.

Un développement futur prendra en compte l'aspect comptabilité et la gestion de la clientèle (clients -> ventes) : l'entité Clients n'est pas encore intégrée au modèle (j'y travaille)!!!

Un article sera enregistré à la livraison et référencé par le gestionnaire en fonction de ces caractéristiques et de la référence fournisseur:

ref_article -> ref_fournisseur; taille, couleur...

Les mouvements d'articles seront enregistrés à chaque livraison et chaque jour pour les ventes.

Mes doutes se situent au niveau de la modélisation de l'entité Articles et de l'entité Mouvements. Ne serait-il pas plus correct de remplacer l'entité Articles par l'entité Mouvements ?

Merci

[JPhi33]

dck21,

Dans le modèle, une référence fournisseur peut correspondre à plusieurs articles. Est-ce la réalité ? J'ai l'impression que non ; je ne vois pas comment ce serait possible (quelques exemple seraient les bienvenus).

Si je pars de l'hypothèse qu'une référence fournisseur ne correspond qu'à un article, alors l'entité Article est superflue car on aurait :

[ Référence ]--1,1----( Composer )----1,1--[ Article ]

Cependant, il peut être gênant, voire dangereux, que ton système d'information dépende d'une identification que tu ne maîtrises pas. C'est ce qui se passera si tu remplaces l'entité Article par l'entité Mouvement sans rien faire de plus. En effet, tu pourrais te retrouver un jour avec la même référence chez 2 fournisseurs différents pour désigner (forcément) 2 articles différents. Dans ce cas, ton SI deviendrait incohérent.

La cohérence d'un SI est conditionnée par la maîtrise de l'identification des concepts.

Pour résoudre ce problème, je vois au moins deux solutions. Mais avant de les exposer, il faudrait confirmer que l'hypothèse que j'ai émis plus haut est correcte.


JPhi33

[dck21]

JPhi33

En effet, chaque fournisseur n'a qu'une référence par article, mais cette contrainte est imposée par le gestionnaire qui souhaite référencer chaque article en fonction de ces caractéristiques

exemples :

Ref_fournisseur : AAA; Taille 38; Couleur : Noir -> Ref_Article : AAA38N
Ref_fournisseur : AAA; Taille 40; Couleur : Blanc -> Ref_Article : AAA40B

Dans ce cas une référence fournisseur va correspondre à plusieurs articles.

De plus je ne vois pas comment gérer les caractéristiques de chaque article sans passer par l'entité Articles, associer directement Références et Caractéristiques et Mouvements ?

[ Références ]--1,n----( Composer )----1,n--[ Caractéristiques ]
......................................|
......................................|
......................................1,1 ?
......................................|
..............................[ Mouvements ]

Je suis un peu perdu!!!

dck21

[thaundeadboss]

salut à tous et désolé déranger votre discussion.
moi aussi je travaille,dans le cadre de mon pfe, sur un site qui permet de faire des commandes en lignes et de gérer le stocke dans l'intranet d'une société de vente de fourniture informatique.
voilà ,mon problème c'est j'ai beaucoup d'ambiguïté sur la relation qui peut exister entre les entités commandes,articles et mouvement,cette dernière qui servira à enregistrer les différentes transactions ,qu'elles soient de types entrée(livraison d'un article par un fournisseur) ou bien sortie(achat d'un article par un client).
merci de bien vouloir m'aider

[dck21]

Bonjour

Ci-joint pour info mon MCD complet

Cordialement.

[JPhi33]

Bonjour,

En effet, chaque fournisseur n'a qu'une référence par article, mais cette contrainte est imposée par le gestionnaire qui souhaite référencer chaque article en fonction de ces caractéristiques

exemples :

Ref_fournisseur : AAA; Taille 38; Couleur : Noir -> Ref_Article : AAA38N
Ref_fournisseur : AAA; Taille 40; Couleur : Blanc -> Ref_Article : AAA40B

Dans ce cas une référence fournisseur va correspondre à plusieurs articles.

De deux choses l'une : soit la référence fournisseur ("AAA" dans ton exemple) est une codification donnée par le fournisseur, soit une codification interne à ton SI. Qu'en est-il ?

Dans le 2e cas, supprime l'entité Référence, elle est inutile.

Sinon, "AAA" est donc une référence provenant du fournisseur. Il pourra alors arriver qu'un autre fournisseur ait la même référence "AAA" pour désigner un autre article.


JPhi33

[dck21]

Bonjour,

En effet la référence est une codification fournie par le fournisseur, d'ou la définition de deux entités : Rérérence et Articles.

Pour ce concerne les risques de doublons, le gestionnaire attribue les références articles selon ses propres critères, mon exemple précédent n'est peut être pas significatif.

Exemples :

Fournisseur : 1 ; Ref_fournisseur : AAA; Taille 38; Couleur : Noir -> Ref_Article : yyy38N
Fournisseur : 2 ;Ref_fournisseur : AAA; Taille 40; Couleur : Blanc -> Ref_Article : xxx40B

Merci

[JPhi33]

Soit.

Quoi qu'il en soit, il n'y a aucun risque de doublon puisque toutes les entités sont identifiées de manière a-significative.

Ton dernier exemple dans le MLD :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
Fournisseurs :
ID_Fournisseur   Nom_Fournisseur
--------------   ---------------
57               Dédé Acoudre
82               Phil & Guille

Référence :
ID_Reference   Ref_Fournisseur   Désignation   #ID_Fournisseur
------------   ---------------   -----------   ---------------
2              AAA               blablabla     57
741            AAA               xyzxyzxyz     82

Articles :
ID_Article   Ref_Article   #ID_Reference
----------   -----------   -------------
5124         xxx38N        2
8473         yyy40B        741

Quelles que soient les valeurs de Ref_Fournisseur et Ref_Article, l'intégrité référentielle est garantie par les ID_xxx (et on peut même se demander pourquoi tu te préoccupes de la qualité des valeurs des Ref_xxx).

Ceci dit, mon avis personnel est que le système d'identification a-significatif n'est une solution à utiliser qu'en dernier recours, lorsqu'on ne peut pas faire autrement. Le modèle Entité-Association n'exprime toute sa puisance qu'avec une identification significative, celle-ci permettant des gains immédiats dans la bases de données en termes d'intégrité référentielle, de cohérence et de performances.

J'attire ton attention sur les dangers de l'identification a-significative dans ton MCD. Rien n'interdirait, par exemple, ceci :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
Référence :
ID_Reference   Ref_Fournisseur   Désignation   #ID_Fournisseur
------------   ---------------   -----------   ---------------
2              AAA               blablabla     57
741            AAA               xyzxyzxyz     82
742            AAA               blablabla     57

Articles :
ID_Article   Ref_Article   #ID_Reference
----------   -----------   -------------
5124         xxx38N        2
8473         yyy40B        741
8474         yyy40B        742

Les références 2 et 742 sont des doublons : même référence chez le même fournisseur.
L'article 8474, lui, est un sorte de mouton à 5 pattes : non seulement il est un doublon de 8473 mais, de plus, il est rattaché à la référence 742 (fournisseur 57) pour laquelle le gestionnaire avait traduit "AAA" en "xxx" et non pas en "yyy".

Voila le genre d'incohérences auxquelles il faut t'attendre puisque ton système référentiel repose uniquement sur la capacité du gestionnaire à ne pas commettre d'erreur (et, comme on le sait, l'erreur est humaine...)

Pour éviter ces doublons et incohérences, il faudra mettre en oeuvre des contrôles portant sur la recherche de l'existence de références non identifiantes (Ref_Fournisseur, Ref_Article).

Exemple pour l'insertion d'une nouvelle référence "BBB" du fournisseur 57 :

Code :

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

1
2
3
4
5
SELECT ID_Reference
  FROM Reference
 WHERE ID_Fournisseur = 57
   AND Ref_Fournisseur = "BBB"

Ces contrôles risquent de pénaliser fortement les performances de l'application même avec des index sur les colonnes concernées.


JPhi33

[dck21]

Bonjour

Merci pour la précision de ta réponse JPhi33, j'ai du mal à saisir la signification du terme a-significative, de plus tu me dis que c'est une solution à n'utiliser qu'en dernier recours, mais quelle autre solution est-il possible d'adopter ?

Merci

[JPhi33]

Bonjour,

j'ai du mal à saisir la signification du terme a-significative

C'est très simple.

Identifications a-significatives :
Article(id_article, ref_article, ...)
Référence(id_reference, ref_fournisseur, désignation, ...)

Identifications significatives :
Article(ref_article, ...)
Référence(ref_fournisseur, désignation, ...)
Fournisseur(id_fournisseur, nom_fournisseur, ...)
Client(id_client, nom_client, ...)

Dans le cas d'une identification a-significative, l'identifiant ne véhicule aucune sémantique, il n'a pas de correspondance dans le monde réel. "id_article", par exemple, n'identifie pas l'article dans le monde réel car c'est le rôle de "ref_article" (idem pour "id_reference").

Par contre, "id_fournisseur" est significatif, même s'il s'agit d'un simple numéro. Par exemple, si on imprime un courrier à l'attention du fournisseur, on ne manquera pas d'y porter ce numéro à la suite d'une mention "nos références" (idem pour le client).

mais quelle autre solution est-il possible d'adopter ?

Pour Article, voir ci-dessus.

Pour Référence, nous avons déjà évoqué les possibilités de doublons. La raison évidente est qu'on ne maîtrise pas les références des fournisseurs. Par contre, il faut admettre que chaque fournisseur identifie ses propres articles de manière unique. Dans ce cas, il faut recourir à l'identification relative : les références des fournisseurs ne sont pas identifiées dans l'absolu mais par rapport à l'id_fournisseur.

Autrement dit, le doublon ci-dessous (clés soulignées)

Code :

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

1
2
3
4
5
6
Table Référence

Ref_Fournisseur   Désignation   #ID_Fournisseur
AAA               blablabla     57
AAA               xyzxyzxyz     82

n'est plus un problème quand on identifie chaque référence par rapport à son fournisseur (clés soulignées) :

Code :

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

1
2
3
4
5
6
Table Référence

ID_Fournisseur   Ref_Fournisseur   Désignation
57               AAA               blablabla
82               AAA               xyzxyzxyz

Dans le MCD Merise, la modélisation est la suivante :

[ Référence ]--(1,1)----( )----0,n--[ Fournisseur ]

Les cardinalités 1,1 entre parenthèses signifient que l'entité Référence est dépendante de (ou est relative à) l'entité Fournisseur. On la qualifie d'entité faible.


JPhi33

[dck21]

Bonjour

Merci pour ton aide JPhi33.

Cordialement, dck21