Discussion :

[Kropernic]

Bonjour,

Mon collègue et moi avons une divergence d'opinion par rapport à la modélisation à adopter et vu que nous sommes tous deux avec assez peu d'expérience, je me tourne vers vous histoire d'avoir un avis plus expert.

Voici le contexte :
Pour un magasin de prêt à porter fonctionnant avec de la démonstration¹, il faut pour chaque code démo (code unique associé à une "famille d'articles"² d'un fournisseur) pouvoir déterminer le rayon, la marque, le fournisseur, le représentant, la société facturante et leurs adresses respectives.

¹C'est a dire que le magasin loue en fait de l'espace pour qu'un fournisseur vienne vendre ses produits. Sur chaque vente effectue dans le magasin, ce dernier prendre prend un pourcentage de la vente effectuée. Le magasin n'a donc aucune gestion d'inventaire à faire. Tout doit être géré par le fournisseur.

²Le terme famille de produit est très vague. Certains fournisseurs vont un code pour leurs pantalons bleus et un autre pour les noirs. D'autres vont avoir un seul code pour les deux. La seule restriction est que la marchandise d'un code démo ne peut pas être à cheval sur plusieurs rayons.

Une chose est certaine, car nous réoccuperons cette information depuis le système SAP, c'est comme les choses s'organisent au niveau des interactions entre fournisseur, rayon et marque. Il y a d'abord le couple (fournisseur;rayon) qui est constitué. Couple qui est ensuite associé à une marque : ((fournisseur;rayon);marque).

Voici la modélisation produite par mon collègue :

Au niveau du code démo, l'objectif est bien rempli. On a bien un moyen de retrouver la marque, le rayon et le fournisseur³ ainsi que leurs adresses respectives (en fait non, ça merde au niveau des adresses... On pourrait avoir une adresse de fournisseur qui n'appartient pas au fournisseur... Faudrait une contrainte CHECK). Par contre, je suis grandement déranger par le fait qu'il n'y aucun moyen direct de connaître les compagnies qui sont fournisseurs. Le seul moyen étant d'aller voir dans la table de jointure FOURN_ADR.

Voici ma modélisation :

Ca merde toujours autant au niveau des adresses. Je suis persuadé qu'il y a un gros travail à ce niveau-là...⁴

⁴Vous vous souvenez de ma question sur le lien entre la propreté d'un schéma et son exactitude? Mes liens se croisent (donc c'est pas propre) et comme par hasard, la modélisation n'est pas bonne...

Par contre, avec l'héritage en plus, on sait directement qui est fournisseur. Pour le couple - triple selon la vision des choses - ((fournisseur;rayon);marque), plus de risque d'erreur possible. Avec la modélisation de mon collègue, il faut encore un check vers la table FOURN_ADR... Deplus, il a eu besoin d'ajouter des tables supplémentaire à son schéma pour aller stocker des infos complémentaire sur les fournisseurs et les sociétés facturantes.

Alors, qu'en pensez-vous ? Je n'ai pas formulé ici les règles de gestion à dessein. Mon collègue faisant tout ça au feeling (il vient du monde des DB fichiers comme Advantage Dabase Server et ses fichier .DBF). Je tente de le former petit à petit mais c'est pas facile.

Les seuls argument que j'arrive à lui trouver c'est qu'on pourrait avoir un couple (fournisseur;rayon);marque) avec un fournisseur qui ne serait pas vraiment un fournisseur. Ce à quoi il me rétorque que ce n'est pas possible vu que nous allons récupérer cela depuis SAP. Et je ne peux pas vraiment lui donner tord. Mais je sens en mon fort intérieur que ce n'est pas correct.

[Kropernic]

Hello,

Apparemment, cette histoire m'a travaillé de la nuit car en me réveillant, j'avais une solution fonctionnelle et claire.

Voici donc le schéma correct (selon moi) :


Une compagnie peut donc toujours être une représentant et/ou un fournisseur et/ou une société facturante. Mais fournisseur et représentant ayant des infos communes, j'ai ajouté un niveau d'héritage pour les regrouper (je dois encore juste trouver un nom pour cette entité).

Chaque type de compagnie possède ses propres adresses.

Dans DEMO, on pointe bien vers une itération du couple ((fournisseur;rayon);marque) ainsi que vers les adresses des fournisseurs/société facturante/représentant. Seul écueil, l'ajout d'une contrainte CHECK pour s'assurer que l'adresse fournisseur appartient bien au fournisseur mentionner dans le couple ((fournisseur;rayon);marque).

Et avec ça, tout le monde est content.

N.B. : Et je remarque encore une fois qu'avec une modélisation correcte, il n'y a aucune ligne qui se croise. Ce qui était impossible avec les modélisations erronées présentées dans mon message précédent.