Discussion :

[fsmrel]

Pour FormeEntrée et FormeSortie, je les ai mis séparément comme propriétés des associations UTILISER et LIVRER

J’ai des craintes... Pourriez-vous être plus précis ? Vous n’avez quand même pas réintégré FormeEntrée et FormeSortie dans leur emplacement originel ? Vous avez bien conservé l’entité-type FORME que j’ai proposée ?

Proposez votre dernier MCD.

[Kropernic]

Et bien, c'est moi qui ai du retard pour une fois ^^.

Je pense que fsmrel a répondu à tout mais il y a cependant une chose qui m'a fait tiqué.

Vous avez écrit (dans un des derniers messages) :

Un article n'a qu'une seule forme en entrée

Cela me semble assez gros quand même ! Qu'est-ce qui garanti que 2 fournisseurs différents conditionne un produit de la même manière ?

Prenons le cas de l'huile. Peut-être que le fournisseur A livrera des bidons de 50 litres alors que le fournisseur B pourrait livrer des bidons de 75 litres. Et vu que c'est le service d'achat qui choisit le fournisseur, il n'y a aucune garantie à ce niveau là. Cela pourrait même une autre forme que des bidons (barils par exemple).

[fsmrel]

Hello Krop,

Puisque Dubicobit aura donné le coup de tampon qui va bien sur le dossier de conception de RZinaoui, un bidon de 50 litres et un bidon de 75 litres sont donc deux articles distincts... « Scripta manent »...

[Kropernic]

Hello Krop,

Puisque Dubicobit aura donné le coup de tampon qui va bien sur le dossier de conception de RZinaoui, un bidon de 50 litres et un bidon de 75 litres sont donc deux articles distincts... « Scripta manent »...

Certes mais bon... Enfin la question ne se pose probablement pas pour RZinaoui vu qu'il est en stage mais personnellement, quand je développe (comprendre depuis l'analyse jusqu'à la phase finale des tests de l'applicatif en passant par la conception de la DB), j'essaie quand même un minimum de rester logique. Si je détecte une incohérence dans les spécifications que l'on me donne, je creuse, je pose les questions. En général, on retombe quand même dans mon sens.

Au pire, si la MOA n'en démord pas, pour ce sujet-ci, ça ne coûte quand même pas grand chose (du moins il me semble) de concevoir un mcd qui permet à un article d'avoir plusieurs formes en entrée. Parce que après, ça va la galère pour la gestion du stock avec 2 articles "huiles pour moteur" différent mais qui sont quand même identique...

[RZinaoui]

J’ai des craintes... Pourriez-vous être plus précis ? Vous n’avez quand même pas réintégré FormeEntrée et FormeSortie dans leur emplacement originel ? Vous avez bien conservé l’entité-type FORME que j’ai proposée ?

Proposez votre dernier MCD.

Oui je l'ai bien conservé. Pour les propriétés FormeEntrée et FormeSortie, j'ai dit que je les ai mis séparément au début de notre discussion (première page) et non pas dans mon dernier MCD.
"J'avoue que j'ai un problème de communication auquel je dois trouver une solution le plus tôt possible "

[RZinaoui]

Hello Krop,

Puisque Dubicobit aura donné le coup de tampon qui va bien sur le dossier de conception de RZinaoui, un bidon de 50 litres et un bidon de 75 litres sont donc deux articles distincts... « Scripta manent »...

Effectivement, ce sont deux articles distincts

[Kropernic]

C'est une solution de voir qui fonctionne mais elle m'indispose grandement.

Pour moi, l'article, c'est l'huile. Peu importe qu'elle se présente sous la forme de bidons de 15, 20, 30, 40, etc. litres. Ce n'est que la manière dont elle est livrée. Ce qui compte, c'est de savoir combien de litres il y a en stock et non pas combien de bidons.

De plus, vu que l'huile sortira du stock par litre (éventuellement par bidon mais on ne me fera pas croire qu'il n'y aura toujours que des bidons plein dans le stock), cela me donne vraiment l'impression d'un mcd biaisé. Fonctionnel mais biaisé.

Si je trouve du temps, je tacherai de réfléchir sérieusement à la question mais je suis actuellement bien chargé niveau travail.

[RZinaoui]

Oui justement, ce dont vous parlez fait partie de l'optimisation. Normalement c'est ce qu'il faut faire mais le responsable du magasin veut rester en accord avec leur système d'information qui présente cette faille !
Etant un élève ambitieux, j'aime bien leur changer cela mais je n'ai pas les moyens nécessaires pour intervenir.

[fsmrel]

Il est certain que l’article c’est huile, et que tel fournisseur peut livrer des bidons de 50 litres et tel autre des bidons de 75 litres.

Cela dit, même si aucun de nous trois ne partage le point de vue du patron de Dubicobit quant aux règles de gestion décrivant les relations entre les articles et les formes livrées par les fournisseurs (voire celles qui sont utilisées pour les engins), il connaît mieux le fonctionnement de son entreprise que nous... Nous ne pouvons que tenter de le convaincre que son système pourrait bénéficier d’une cure de jouvence bienfaisante, mais quelle que soit sa décision finale il a le devoir de cosigner le dossier de relecture porteur de nos remarques et accompagnant le dossier de conception correspondant à ce qu'il a voulu : dans tout cela il y a quand même un côté contractuel.

En tout cas, la méthode Merise fait observer qu’un système en place peut un jour faire l’objet d’une nouvelle version et que c’est l’occasion de faire le ménage dans ce qui est obsolète, tout en procédant à des améliorations salutaires. Comme un dessin vaut mieux qu’un long discours, on peut méditer à partir de la courbe su soleil présentée par A. Rochfeld dans La Méthode Merise, Tome 3 - Gamme opératoire (voyez aussi ici).




@Krop

Au-delà de tout ça, votre diagramme est le suivant :



La table CON correspond à une nomenclature des formes, soit (voyez à cet égard mon commentaire ici). Cela dit, supposons que l’article livré « huile » fasse référence à la forme F1. Du fait des cardinalités maximales N portées par les liens connectant FOR et CON, pour F1 on peut avoir plusieurs lignes CON : laquelle choisir ? Sur la base de quels critères de sélection ?

[Kropernic]

@Krop

Au-delà de tout ça, votre diagramme est le suivant :



La table CON correspond à une nomenclature des formes, soit (voyez à cet égard mon commentaire ici). Cela dit, supposons que l’article livré « huile » fasse référence à la forme F1. Du fait des cardinalités maximales N portées par les liens connectant FOR et CON, pour F1 on peut avoir plusieurs lignes CON : laquelle choisir ? Sur la base de quels critères de sélection ?

Dans la table ART se trouve une colonne FOR_ID qui correspond à la forme (unitaire ; atomique) de l'article qui est utilisée pour établie le stock (pour l'huile, le litre donc).
Dans la table ARL se trouve une colonne FOR_ID qui correspond à la forme dans laquelle est livrée l'article (pour l'huile, les bidons de X litres).
Dans la table CON, on aurait donc une ligne établissant le fait que le bidon de la forme de livraison se converti en X litres.
Après, dans la table JAU, on peut encore améliorer en ajoutant également une colonne FOR_ID pour le cas où l'article ne serait pas forcément sorti du stock sur sa forme unitaire (par exemple, par petits bidons de 2 litres).

Ai-je répondu à votre question ?

[fsmrel]

Ai-je répondu à votre question ?

Certes, mais vu votre modèle, j’ai comme le sentiment que la table CON comportera inéluctablement des redondances. Pourriez-vous donner des exemples de tuples pour cette table ?

[RZinaoui]

voyez aussi ici).

si seulement si vous m'aviez donné ce lien au début ... j'ai bien aimé la manière avec laquelle on explique : )

[Kropernic]

Certes, mais vu votre modèle, j’ai comme le sentiment que la table CON comportera inéluctablement des redondances. Pourriez-vous donner des exemples de tuples pour cette table ?

Je ne suis pas très imaginatif mais je vais essayer ^^.

Les tuples se présenteront sous la forme

Code :

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

FOR_ID_IN;FOR_ID_OUT;CON_QUANTITY_IN;CON_QUANTITY_OUT

Mais il faut d'abord définir des formes ! (FOR_ID;FOR_UNITE)

Code :

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

1
2
3
4
5
6
7
8
9
1;LITRE
2;METRE
3;BIDON X
4;BIDON Y
5;BIDON Z
6;PAQUET A
7;PAQUET B
8;PIECE

Et maintenant, quelques tuples de CON :

Code :

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

1
2
3
4
5
6
3;1;1;75
4;1;1;50
5;1;1;150
6;8;1;50
7;8;1;200

La colonne CON_QUANTITY_IN pourrait éventuellement disparaître si on est certain que la valeur d'entrée sera toujours 1 mais j'ai préféré être prudent.
Avec ceci, on sait que le bidon X contient 75 litres, que le bidon Y contient 50 litres ou que le paquet B contient 200 pièces (des crayons par exemple).

Je ne vois pas pourquoi il y aurait des redondances.
A part éventuellement à vouloir convertir des litres en entrée vers des bidons X en sortie qui serait redondant au sens mathématique mais pas au sens ligne en double.

[fsmrel]

Code :

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

1
2
3
4
5
6
7
8
9
1;LITRE
2;METRE
3;BIDON X
4;BIDON Y
5;BIDON Z
6;PAQUET A
7;PAQUET B
8;PIECE

Et maintenant, quelques tuples de CON :

Code :

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

1
2
3
4
5
6
3;1;1;75
4;1;1;50
5;1;1;150
6;8;1;50
7;8;1;200

D’accord. Je reformule les choses sous forme tabulaire pour voir plus clair :

Table FOR

 
    ForId    ForUnite
        1    LITRE
        2    METRE
        3    BIDON X
        4    BIDON Y
        5    BIDON Z
        6    PAQUET A
        7    PAQUET B
        8    PIECE 

Table CON

 
    ForIdIn    ForIdOut    ConQteIn    ConQteOut
          3           1           1           75
          4           1           1           50
          5           1           1          150
          6           8           1           50
          7           8           1          200 

Par référence à votre diagramme Workbench, selon le lien connectant ART et FOR, un article détermine exactement une forme. Supposons que l’article soit l’huile : la forme correspondante est le litre, d’où le tuple <1, LITRE> élément de la table FOR. So far, so good.

Toujours par référence à votre diagramme, chaque patte connectant FOR et CON est porteuse d’une cardinalité 1,N : il manque donc au moins un tuple dans la table CON pour lequel ForIdIn = 1 (idem pour ForIdIn = 2) : pour que votre exemple soit conforme à votre diagramme, il faut donc le compléter avec quelques tuples pour lesquels ForIdIn = 1 (idem pour 2). J’amorce la pompe, il vous reste à remplacer les « ? » par des valeurs qui vont bien :

Table CON

 
    ForIdIn    ForIdOut    ConQteIn    ConQteOut
          1           ?           ?            ?
          1           ?           ?            ?
          1           ?           ?            ?
          2           ?           ?            ?
          3           1           1           75
          4           1           1           50
          5           1           1          150
          6           8           1           50
          7           8           1          200 

Je ne vois pas pourquoi il y aurait des redondances.
A part éventuellement à vouloir convertir des litres en entrée vers des bidons X en sortie qui serait redondant au sens mathématique mais pas au sens ligne en double.

La redondance dont je parle ne concerne pas les lignes en double, auquel cas j’aurais parlé de sacs (bags) : pour faire court, un sac est une table sans clé. La redondance dont je traite est plus concernée par le rasoir d’Ockham.

[Kropernic]

On peut compléter la table CON à l'envi. Tout dépend du besoin/de notre imagination.

Si maintenant l'huile est livrée par camion citerne dans une grande cuve et qu'elle reconditionnée en bidons à la demande, on place litre en entrée et bidon en sortie.

Maintenant, comme dit précédemment, s'il s'agit par exemple d'un reconditionnement en bidon X, alors on a déjà la "formule" de conversion avec la première ligne d'exemple que j'avais postée pour la table CON.

Mais j'ai l'impression en rédigeant ces quelques lignes que votre trouble se porte plus sur les cardinalités des relations entre CON et FOR que sur la table en elle-même.

A ce niveau-là, je reconnais fort volontiers que les cardinalité sont peut-être à revoir. Comme déjà signaler dans un précédent message, j'ai fait ce diagramme sur un de mes temps de pause à mon travail. Il s'agissait de donnée une idée de départ à RZinaoui sur laquelle il pourrait se développer*. Mais ce détail ce sera probablement perdu dans la masse de nos messages et vous aura échapper mais il ne peut vous en être tenu rigueur

*Je n'aime pas donner de solution qui aurait l'air prête à l'emploi car n'étant pas immergé dans le domaine traité, il y aura forcément quelque chose qui m'aura échappé et ce sera le drame si ma solution est prise telle quelle.

[fsmrel]

On peut compléter la table CON à l'envi.

Votre réponse n’est pas satisfaisante. Soit, comme je vous l'ai demandé, vous remplacez les « ? » par des valeurs pertinentes, soit vous proposez une révision pour cette partie du modèle.

[Kropernic]

Voici

Je reprends la table FOR et je l'enrichis un peu :

Code :

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

1
2
3
4
5
6
7
8
1;LITRE 2;METRE 3;BIDON X 4;BIDON Y 5;BIDON Z 6;PAQUET A 7;PAQUET B 8;PIECE
9;CONTENANT A
10;CONTENANT B
11;CONTENANT C
12;BOBINE A
13;BOBINE B
14;BOBINE C
15;BOBINE D

Et voici des tuples supplémentaires pour la table CON :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
FOR_ID_IN ; FOR_ID_OUT ; CON_QTE_IN ; CON_QTE_OUT
         1                     9                10                     1           
         1                    10                 5                     1           
         1                    11              2.5                     1           
         2                    14              3.5                     1
         2                    15              1.5                     1
         3                     1                  1                   75           
         4                     1                  1                   50           
         5                     1                  1                  150
         6                     8                  1                    50           
         7                     8                  1                  200
        12                    2                   1                 500
        13                    2                  1                 1000

P.S. : Comment faites-vous pour faire des tableaux si bien alignés ???

[fsmrel]

Reprenons votre diagramme dans lequel j’ai fait figurer les rôles (IN/OUT) comme il est d'usage dans le cas des réflexives afin d’éviter les ambiguïtés) :



Les cardinalité des pattes connectant FOR et CON sont 1,N, donc chaque valeur de forme doit être présente dans la colonne FOR_ID_IN de la table CON : il faut donc y faire figurer les valeurs 8, 9, 10 ,11, 14, 15.
De même, chaque valeur de forme doit être présente dans la colonne FOR_ID_OUT : il faut donc y faire figurer les valeurs 3, 4, 5, 6, 7, 9,10.

Vous me direz « Où va-t-on ? » : qu’à cela ne tienne, pour éviter ça, on va remplacer les cardinalités 1,N par 0,N, mais il y a en l’occurrence un glissement sémantique et logique sévère, on remplace le quantificateur universel par le quantificateur existentiel (« Toutes les formes font l’objet de conversion » remplacé par « Quelques formes font l’objet de conversion »), c’est comme si on remplaçait le célèbre « Tous les hommes sont mortels » par « Quelques hommes sont mortels » : Aristote aurait émis quelques réserves (euphémisme)...

Mais bon...

Supposons maintenant que l’utilisateur ait à gérer des bidons de type Y dont la capacité soit exprimable en gallons (forme = 16) :

FOR_ID_IN    FOR_ID_OUT    CON_QTE_IN    CON_QTE_OUT
        1             9            10              1
        1            10             5              1
        1            11           2.5              1
        2            14           3.5              1
        2            15           1.5              1
        3             1             1             75
        4             1             1             50
        4            16             1             50
        5             1             1            150
        6             8             1             50
        7             8             1            200
       12             2             1            500
       13             2             1           1000

Dans la table CON, on aura donc pour la paire {FOR_ID_IN, FOR_ID_OUT} non plus seulement la valeur <4, 1> signifiant que les capacités des bidons de type Y sont exprimables en litres, mais en plus la valeur <4, 16> signifiant que les capacités des bidons de type Y sont aussi exprimables en gallons. Vous me direz qu’il serait stupide de considérer que la capacité d’un bidon de type Y puisse être exprimée selon deux unités de mesure, n’empêche que votre modèle est taillé pour ça et permet de savoir qu’à l’unité 1 (litre) sont associés les types de contenant A, B, C (cf. votre exemple que je ne fais que suivre).

Mais bon...

On pourrait encore faire évoluer les cardinalités, en remplaçant la 0,N « IN » par une 0,1 :




Mais au bout du compte, une réflexive s’impose-t-elle vraiment ? Votre exemple du post #93 va-t-il dans ce sens ? Dubicobit a-t-il besoin de gérer une nomenclature ?


A suivre...

Comment faites-vous pour faire des tableaux si bien alignés ???

NotePad + Police Courier + barre Espace du clavier + Balise [pre] + un peu de patience...

[Kropernic]

Supposons maintenant que l’utilisateur ait à gérer des bidons de type Y dont la capacité soit exprimable en gallons (forme = 16) :

FOR_ID_IN FOR_ID_OUT CON_QTE_IN CON_QTE_OUT 1 9 10 1 1 10 5 1 1 11 2.5 1 2 14 3.5 1 2 15 1.5 1 3 1 1 75 4 1 1 50 4 16 1 50 5 1 1 150 6 8 1 50 7 8 1 200 12 2 1 500 13 2 1 1000
Dans la table CON, on aura donc pour la paire {FOR_ID_IN, FOR_ID_OUT} non plus seulement la valeur <4, 1> signifiant que les capacités des bidons de type Y sont exprimables en litres, mais en plus la valeur <4, 16> signifiant que les capacités des bidons de type Y sont aussi exprimables en gallons. Vous me direz qu’il serait stupide de considérer que la capacité d’un bidon de type Y puisse être exprimée selon deux unités de mesure, n’empêche que votre modèle est taillé pour ça et permet de savoir qu’à l’unité 1 (litre) sont associés les types de contenant A, B, C (cf. votre exemple que je ne fais que suivre).

Désolé de revenir sur le sujet après tant de temps (enfin ça ne fait jamais que 11 jours finalement) mais j'ai été pas mal pris par le travail.

Bref, l'exemple que vous donnez d'un bidon de type Y dont la capacité est exprimable aussi bien en litre qu'en gallon est exactement ce à quoi je voulais faire face.

1° Le magasin se fait livrer de l'huile (pour continuer avec cet article) sous la forme de bidon du-dit type Y.
2° Pour une utilisation U1, il est requis 2.5 litre d'huile.
3° Pour une utilisation U2, il est requis 3.75 gallons d'huile.

Il est donc nécessaire de pouvoir effectué cette conversion pour pouvoir déterminer si la quantité en stock (qui selon mon diagramme est exprimée sous la forme indiquée dans l'entité-type article) est suffisante pour satisfaire la demande.

Non ?

[fsmrel]

Ave Krop,

1° Le magasin se fait livrer de l'huile (pour continuer avec cet article) sous la forme de bidon du-dit type Y.
2° Pour une utilisation U1, il est requis 2.5 litre d'huile.
3° Pour une utilisation U2, il est requis 3.75 gallons d'huile.

Pour une utilisation U1, la table JAU permet de savoir qu’il est requis de l’huile (table JAU : {UTI_ID} -> {ART_ID}), en quantité 2,5, mais on ne sait pas à ce stade quelle est l’unité correspondante, litre ou gallon.

Selon la table ART, {ART_ID} -> {FOR_ID} : Pour l’article "huile", l’attribut FOR_ID prend la valeur 4.

Selon la table FOR, si l’attribut FOR_ID prend la valeur 4 alors l’attribut FOR_UNITE prend la valeur "Bidon Y" (cf. votre tableau du 31/07).

Maintenant, selon la table CON (cf. mon tableau du 02/08), si l’attribut FOR_ID_IN prend la valeur 4 alors l’attribut FOR_ID_OUT peut prendre la valeur 1 (litre) ou la valeur 16 (gallon).

=> Dans l’état du MLD, on ne sait pas déterminer l’unité pour l’utilisation U1 : litre ou gallon.

Remarque annexe : comment savoir au besoin que le fournisseur livre des bidons Y en litres et/ou en gallons ?