Discussion :

[JPhi33]

Bonjour,

1) D'après ce qu'on sait déjà, si le produit P1 a une QuantiteDeCommande de 1728, ça veut dire qu'une palette de P1 contient 1728 boîtes de P1. Donc :
- QuantiteDeCommande dans PRODUIT = 1728
- QuantiteProduit dans EMPLACEMENT = 1728
Si tu reçois 5 palettes de P1 que tu stockes à 5 emplacements, dans chacun de ceux-ci tu auras QuantiteProduit = 1728. 6 fois la même information, c'est 5 redondances à éliminer !
QuantiteDeCommande et QuantiteProduit représentent la même quantité ; inutile de les avoir en double. On peut donc bien supprimer QuantiteProduit de l'entité Emplacement.

2) Pour les picking, le début de l'histoire est le même : je descends ma palette de P1 en picking, j'ai donc 1728 boîtes de P1 dans cet emplacement picking : information redondante. Sauf que la suite du scénario est différente : un magasin me commande 576 boîtes de P1 que je prends dans mon stock picking ; il m'en reste donc 1152. Il me faut bien une donnée pour conserver cette information. Et cette donnée doit être dans l'entité PICKING. Voila pourquoi j'ai dit qu'il faut mettre QuantiteProduit dans PICKING.

En résumé : 1) je supprime la donnée QuantiteProduit de EMPLACEMENT 2) j'ajoute la donnée QuantiteProduit dans PICKING.
C'était un raccourci de ma part de dire qu'il faut déplacer QuantiteProduit de EMPLACEMENT vers PICKING. Maintenant tu as l'explication détaillée des raisons pour lesquelles il faudrait le faire.

Bon, à part ça, gros problème. [...] je ne peux pas ajouter un nouvel emplacement sans lui spécifier quel est le CodeProduit lié alors que tous mes emplacements ne sont pas forcément occupés. Ca agit comme si j'étais obligé de remplir chaque emplacement.

Si tu regardes attentivement le MCD, tu verras :

[ EMPLACEMENT ]--0,1----( Contient )----0,n--[ PRODUIT ]

exprimant le fait qu'un emplacement contient 1 type de produit au maximum et peut ne pas en contenir.
En cochant la case "Appliquer l'intégrité référentielle" tu obliges Access à vérifier que, dans chaque ligne de la table EMPLACEMENT, il y a une valeur de "#CodeProduit" existante dans la table PRODUIT.

Décoche cette case et tu pourras créer des emplacements non liés à un produit.


JPhi33

[jedimaster10]

Ahhhhhhh très bien, je pensais vraiment que l'intégrité référentielle était quasi obligatoire pour une meilleure pertinence. En fait, dans certains cas, elle n'est donc pas appliquable.

Je comprends tout à fait pour le déplacement de la propriété QuantitéProduit. Seulement voilà, cette même propriété devrait également se trouver dans EMPLACEMENT dans les cas où je reçois une commande en plusieurs fois.

Je m'explique. Je commande 1728 P1, j'en reçois 1000 à la 1ère réception puis 728 à la 2ème. Faudra bien que j'indique la quantité stockée dans l'emplacement du coup ou est-ce qu'Access connaitra cette quantité grâce à QuantitéRecue dans la table RECEPTION ? ou autre ?

Je ferai les modifications demain et je te tiendrai au courant rapidement. En attendant, à part cette histoire d'intégrité référentielle, ma base te parait-elle bonne si je me fie à tes indications ? (cf. pièce jointe de mon précédent message)

Merci beaucoup

[jedimaster10]

Je te remets en pièce jointe ma base telle qu'elle est à l'heure actuelle.

Si tu vois des incohérences dans les relations, les tables ou encore les propriétés des champs, ça serait vraiment gentil de me le signaler.

Merci

[JPhi33]

Je comprends tout à fait pour le déplacement de la propriété QuantitéProduit. Seulement voilà, cette même propriété devrait également se trouver dans EMPLACEMENT dans les cas où je reçois une commande en plusieurs fois.

Je m'explique. Je commande 1728 P1, j'en reçois 1000 à la 1ère réception puis 728 à la 2ème. Faudra bien que j'indique la quantité stockée dans l'emplacement du coup ou est-ce qu'Access connaitra cette quantité grâce à QuantitéRecue dans la table RECEPTION ? ou autre ?

J'avais cru comprendre qu'on ne stockait que des palettes entières sur les emplacements (cf. ton tout premier message ci-dessous) :

Je stocke de 2 façons :

_ des palettes homogènes (plusieurs unités d'un seul produit sur la palette) sur les 3 étagères supérieures des racks

Il est vrai que tu dis "palettes homogènes" et non pas "entières". C'est peut-être une mauvaise interprétation de ma part.

Si c'est le cas, il ne faut pas déplacer QuantitéProduit et la laisser dans EMPLACEMENT. Mais il ne faut pas non plus la dupliquer dans PICKING car comme un Picking EST UN Emplacement, il hérite aussi de la propriété QuantitéProduit.

Concrètement, quand tu es sur le Picking "2-07-0-3" il existe une ligne dans la table PICKING correspondant à cet identifiant mais il existe aussi une ligne dans la table EMPLACEMENT correpondant à ce même identifiant. C'est la QuantitéProduit de la table EMPLACEMENT qui sert à représenter la QuantitéProduit de la table PICKING.

A propos de ta base, hormis le point ci-dessus, il me semble correct sauf que tu pourrais l'optimiser en supprimant les tables ALLEE, RACK et ETAGE.


JPi33

[jedimaster10]

C'est bien ce qui me semblait pour la QuantiteProduit. Modification effectuée.

Pour l'optimisation, ça me ferait donc passer à une identification absolue. Je ne pense pas que ce soit un drame donc je suis plutôt pour.

Cependant, si je supprime les 3 tables dont tu parles, mes tables EMPLACEMENT et PICKING vont changer.

Voici l'état de ces 2 tables (en gras, les clés primaires, avec un # les clés externes) :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
EMPLACEMENT
#CodeAllee
#CodeRack
#CodeEtage
CodeEmplacement
#CodeProduit
QuantiteProduit

PICKING
#CodeAllee
#CodeRack
#CodeEtage
#CodeEmplacement

Après suppression des 3 tables dont tu parles, comment seront-elles ?

Sinon, je vais essayer d'ajouter la gestion des anomalies d'entrepot (vol, casse, perter, etc...). Je te montrerai à quoi ça ressemble.

[jedimaster10]

Une idée ?

[JPhi33]

Bonjour,

J'ai été absent quelques temps...

Pour l'optimisation, ça me ferait donc passer à une identification absolue.

Pas du tout, ça reste une identification relative. Seulement, si les tables ALLEE, RACK et ETAGE ne servent à rien, autant les supprimer. Sinon, il faut les garder. A toi de juger.

L'identification relative est un concept, ce n'est pas en supprimant des tables qu'on le remet en cause. Tout au plus, on pourrait risquer de ne pas réussir à le faire fonctionner, auquel cas il faudrait, bien évidemment, conserver ces tables. Dans ton cas, je juge que ce n'est pas utile mais comme c'est à toi de décider, tu as le droit d'avoir un avis contraire au mien et vouloir conserver les tables.

Cependant, si je supprime les 3 tables dont tu parles, mes tables EMPLACEMENT et PICKING vont changer.

Mais non ! Pour quelle raison ? Il n'y a aucune raison pour qu'elles changent. Si, il y a bien une petite modification : dans EMPLACEMENT, CodeAllée, CodeRack et CodeEtage ne pourront plus être des clés étrangères :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
EMPLACEMENT
CodeAllee
CodeRack
CodeEtage
CodeEmplacement
#CodeProduit
QuantiteProduit

PICKING
#CodeAllee
#CodeRack
#CodeEtage
#CodeEmplacement

Sinon, je vais essayer d'ajouter la gestion des anomalies d'entrepot (vol, casse, perter, etc...). Je te montrerai à quoi ça ressemble.

D'accord


JPhi33