Discussion :

[hed62]

La table entrepot

Une adresse par exemple? Penses au futur, et imagine qu'un 2e entrepot ouvre ses portes, comment gérer ca facilement ?

Par contre, pour en revenir aux DateLigneCommande, si jamais ne je ne reçois pas toute la quantité commandée de la ligne de commande (avant contrôle et acceptation), comment je peux faire pour avoir une 2ème réception voire une 3ème réception pour une même ligne de commande ?

Ce n'est pas la date de commande de la ligne mais la date de réception qui va jouer à ce niveau

Sinon oui, tout n'est pas forcément stocké, il y a ce qu'on appelle aussi du Cross-docking, des marchandises qui arrivent et sont expédiées directement sans stockage car elle réponde à une situation "d'urgence".

Ca répond au 4/

[jedimaster10]

D'accord pour l'entrepot.

Mais pour la date, dans l'état actuel, il n'y a qu'une date de réception possible pour chaque ligne de commande pour le moment alors que si ma ligne de commande je la reçois en 2 fois, je ne peux rien faire.

C'est donc ça que j'aimerais corriger.

[hed62]

Il te faut donc une table Réception qui soit liée avec la commande et les produits, en précisant une quantité et une date.

[jedimaster10]

Dans ce cas, faudrait plutôt une table LIGNE DE COMMANDE liée juste au produit et où on entre une quantité et conserver la table DETAILS COMMANDE où chaque enregistrement correspond à une réception d'un produit qu'on lie à une ligne de commande via une clé étrangère.

C'est clair ou pas ?

[JPhi33]

Bonjour à tous,

Je réponds aux interrogations sur les commandes livrées en plusieurs fois. Si j'ai dit ça :

Si la commande est livrée en plusieurs fois, il y a plusieurs lignes de cette table concernant la même COMMANDE FOURNISSEUR et le même PRODUIT avec des DateReception différentes, mais la date de commande reste la même.

C'est parce que ce cas de gestion m'est venu à cause de la présence de la date de réception dans les données de la table DETAIL COMMANDE.
Mais ce modèle n'est effectivement pas prévu pour gérer correctement une commande livrée en plusieurs fois. Mais il peut quand même gérer ce cas (donc incorrectement).

Exemple de lignes de la table DETAILS COMMANDE FOURNISSEUR
On commande 2 produits au même fournisseur dans une même commande :
- AA en quantité 3 (il sera livré en 2 fois, quantité 2 puis 1)
- BB en quantité 2 (il sera livré en 1 fois)

A la commande :

Code :

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

1
2
3
4
5
6
7
CodeDetailCommande  D1         D2
QuantiteCommandee   3          2
QuantiteReçue       null       null
DateReception       null       null
CodeProduit         AA         BB
CodeCommande        C1         C1

A la 1ère livraison :

Code :

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

1
2
3
4
5
6
7
CodeDetailCommande  D1         D2
QuantiteCommandee   3          2
QuantiteReçue       2          2
DateReception       12/12/2007 12/12/2007
CodeProduit         AA         BB
CodeCommande        C1         C1

A la 2e livraison :

Code :

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

1
2
3
4
5
6
7
CodeDetailCommande  D1         D2         D3
QuantiteCommandee   3          2          3
QuantiteReçue       2          2          1
DateReception       12/12/2007 12/12/2007 14/12/2007
CodeProduit         AA         BB         AA
CodeCommande        C1         C1         C1

Pourquoi cette gestion est-elle incorrecte ? Parce qu'il y a redondance d'information pour la quantité commandée. Parce que les dates de réception sont à NULL (à éviter le plus possible)
Pourquoi est-on tenté d'effectuer ce type de gestion ? Parce que le modèle le permet.
Pourquoi le MLD le permet-il ? Parce qu'il n'y a pas eu de MCD.

Le MCD aurait pu être :


Dans lequel la ligne de commande est une association entre la commande et le produit et comporte la quantité commandée.
L'entité Réception est un peu plus compliquée. Il s'agit d'une entité faible identifiée de manière relative par rapport à la ligne de commande. On différentie les entités faibles des autres entités en remplaçant les traits pleins habituels par des tirets. La CIF vers l'entité par rapport à laquelle elle est identifiée comporte le symbole mathématique d'appartenance. Ici, c'est encore plus inhabituel car l'entité faible est identifiée relativement à une association.

L'identifiant réel de Reception est consitué de CodeCommande, CodeProduit et NumeroReception comme on peut le constater dans le MLD ci-dessous (les clés primaires sont soulignées, les clés étrangères sont précédées de #).


Pour chaque ligne de commande, on peut avoir plusieurs réceptions. On ne peut pas avoir plusieurs lignes de commandes dans la même commande pour le même produit, ce qui me semble logique, alors que c'est possible avec le MLD de jedimaster10.

Vous avez vu juste tous les deux en arrivant à la conclusion qu'il faut une table Reception. Mais c'est mieux de le prévoir dès le départ. Et ça, ça se fait plus facilement en élaborant un MCD car on perçoit mieux les concepts.


JPhi33

[jedimaster10]

Merci beaucoup JPhi33, tu m'as vraiment ouvert les yeux sur les faiblesses de mon modèle. J'avais pas eu à l'idée d'utiliser une association en tant que table (LIGNE COMMANDE) alors que ça tombe sous le sens maintenant que tu l'as expliqué.

Une chose toutefois. Dans la table RECEPTION, tu ne fais pas référence à la quantité à stocker. C'est volontaire ou juste un oubli ?

Si c'est volontaire, tu penserais donc plutôt à gérer la quantité stockée dans une autre table ? Perso, je pense que ça serait inutile mais si tu arrives à me convaincre du contraire alors je suis prêt à t'écouter

Il ne me restera plus qu'ensuite à intégrer les emplacements ce qui sera la dernière partie du casse-tête.

Ah aussi. J'imagine que par rapport à ton MCD, il s'applique de la même manière en aval pour les commandes clients (lié à la table produits pour les LIGNE COMMANDE CLIENT avec une table LIVRAISON au lieu de RECEPTION) ?

Merci beaucoup sincèrement pour toute l'aide que vous m'apportez JPhi33 et hed62

[hed62]

Il ne me restera plus qu'ensuite à intégrer les emplacements ce qui sera la dernière partie du casse-tête.

Ca ne devrait pas être insurmontable

Mais, pour aller plus loin dans la remarque de JPhi33 : il faut faire le MCD avant le MLD, mais as tu pensé à simplement faire le graphe des dépendances fonctionnelles ? (qui te permet de gagner un peu de temps quand même)

[jedimaster10]

C'est le graphe avec les 1 dans les cases c'est ça ?

[hed62]

Ca c'est la matrice de données. Le graphe des dépenaances fonctionnelles, ou GDF, est un graphe avec en sommets les données, et en arcs les dépendances entre elles (A->B signifie que la donnée B est directement obtenue avec la donnée A)

[jedimaster10]

Arf, désolé je ne connais absolument pas ça

Ca va m'apporter vraiment un plus ?

Si oui, tu peux me montrer un exemple de GDF s'il te plait ?

[JPhi33]

Merci beaucoup JPhi33, tu m'as vraiment ouvert les yeux sur les faiblesses de mon modèle. J'avais pas eu à l'idée d'utiliser une association en tant que table (LIGNE COMMANDE) alors que ça tombe sous le sens maintenant que tu l'as expliqué.

C'est un grand classique de la gestion des commandes. A noter quand même que ta modélisation COMMANDE - DETAIL COMMANDE - PRODUIT n'est pas incorrecte mais elle amène des contraintes et vérifications supplémentaires à l'utilisation ; il faut faire plus attention dans les traitements.

Une chose toutefois. Dans la table RECEPTION, tu ne fais pas référence à la quantité à stocker. C'est volontaire ou juste un oubli ?
Si c'est volontaire, tu penserais donc plutôt à gérer la quantité stockée dans une autre table ? Perso, je pense que ça serait inutile mais si tu arrives à me convaincre du contraire alors je suis prêt à t'écouter

C'est volontaire mais c'était juste pour ne pas surcharger le modèle. Ce qui m'importait c'était de te montrer le principe de modélisation d'un tel cas. Par contre j'ai corrigé une petite erreur dans l'exemple : j'avais valorisé la quantité reçue dès la commande, ce qui est évidemment faux.

Ah aussi. J'imagine que par rapport à ton MCD, il s'applique de la même manière en aval pour les commandes clients (lié à la table produits pour les LIGNE COMMANDE CLIENT avec une table LIVRAISON au lieu de RECEPTION) ?

Je n'ai pas vraiment réfléchi à cette partie du modèle, mais ça me semble correct effectivement. Tu peux être amené à livrer les magasins en plusieurs fois toi aussi, ce qui fait que la modélisation semble similaire. Dailleurs hed62 avait parlé de "miroir".


JPhi33

[jedimaster10]

Me revoilà

Alors, j'ai modélisé ce que vous m'avez conseillé sous Access (sauf les emplacements) et quand je souhaite faire les relations, j'ai un message d'erreur "Index unique introuvable pour le champ référencé d'une table principale" lorsque je souhaite relier les entités faibles (RECEPTION côté fournisseur et LIVRAISON côté magasin) aux 2 tables de LIGNE DE COMMANDE. (voir pièce jointe)

Déjà je ne sais pas trop quel champ relier à quel champ entre les 2 tables ? Dans l'ignorance, j'ai tenté de relier CodeReception à QuantiteCommandeeFournisseur. C'est bon ?

Aussi, ça marche si je ne coche pas "Appliquer l'intégrité référentielle". C'est la subtilité qu'il faut mettre en oeuvre ?

Avec la pièce jointe vous pouvez aussi voir le contenu de toutes mes tables.

Pour la table EMPLACEMENT, je devrais la lier à quel endroit ? J'ai bien compris ce qu'il faut faire en amont avec les tables ENTREPOT et ALLEE mais en aval, je lie EMPLACEMENT à quoi ? RECEPTION ? si oui à quel champ ? si non à quelle autre table ?

Joyeux Noël à tous en tout cas et merci pour l'aide que vous m'apportez

[JPhi33]

Bonjour,

C'est normal que tu aies cette erreur. La quantité commandée est un attribut pas une clé !
Il y a peut-être une petite incompréhension de la modélisation. Une RECEPTION se rapporte à 1 et une seule LIGNECOMMANDE. Il faut donc que la clé de LIGNECOMMANDE soit liée à la partie de la clé de RECEPTION correspondant à une commande.
Plus précisément, tu dois lier :
- CodeCommandeFournisseur de LIGNECOMMANDE à CodeCommandeFournisseur de RECEPTION
- CodeProduit de LIGNECOMMANDE à CodeProduit de RECEPTION

Par exemple :

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
19
LIGNE COMMANDE :
CodeCommande CodeProduit
------------ -----------
C1           P1
C1           P2
C2           P1
C2           P3

RECEPTION :
CodeCommande CodeProduit CodeReception
------------ ----------- -------------
C1           P1          1
C1           P2          1
C1           P2          2
C2           P1          1
C2           P1          2
C2           P1          3
C2           P3          1

Dans cet exemple, tu as reçu :
- le produit P1 de la commande C1 en totalité à la première réception
- le produit P2 de la commande C1 en 2 fois
- le produit P1 de la commande C2 en 3 fois
- le produit P3 de la commande C2 en totalité à la première réception

Et voilà !


JPhi33

[jedimaster10]

Je viens de tenter de faire ces 2 relations (ces 4 relations en réalité même) mais en appliquant l'intégrité référentielle, j'ai la même erreur

Je t'ai mis en pièce jointe la base pour que tu puisses voir les éventuelles anomalies

[JPhi33]

C'est parce que tu as des réceptions mais pas les lignes commande fournisseur correspondantes ==> pb d'intégrité référentielle. Avant de créer/modifier une relation, Access vérifie sa compatibilité avec les données présentes (s'il y en a).

Soit tu supprimes les lignes de la table réception (c'est ce que j'ai choisi), soit tu insères les lignes commandes fournisseur manquantes ensuite Access t'autorisera à créer la relation avec l'option "Appliquer l'intégrité référentielle" cochée.



Bon courage.


JPhi33

[jedimaster10]

J'ai d'abord supprimé les enregistrements de la table RECEPTION mais ça marchait pas

Du coup j'ai supprimé tous les enregistrements de RECEPTION, LIGNE COMMANDE et COMMANDE, toujours sans résultat

Toujours ce foutu message d'erreur.

EDIT : ma base, avec les enregistrements supprimés en pièce jointe

[jedimaster10]

Ce qui est chiant avec Access, c'est que ce genre de problème empêche beaucoup de choses. Du coup je suis bloqué pour faire des tests :'(

[JPhi33]

Il y a une manière particulière de créer une relation avec Access. Regarde bien la fenêtre "Modifier une relation" :
- à gauche tu as "Table/Requête" ---> table principale
- à droite tu as "Table/Requête liée" ---> table secondaire

La table principale doit être LIGNE COMMANDE et la table secondaire RECEPTION (c'est normal : pour 1 ligne de commande tu peux avoir n réceptions).

Pour créer la relation, tu dois cliquer sur #CodeCommandeFournisseur de LIGNE COMMANDE et tirer ce champ vers #CodeCommandeFournisseur de RECEPTION : de la table principale vers la table secondaire (il faut toujours faire comme ça quand tu as une relation de type : Table principale de clé [a, b] - Table secondaire de clé [a, b, c]).

Tu verras qu'en bas de la fenêtre "Modifier une relation" tu obtiens "Type de relation : Non définie". Sur la 2e ligne de champs, choisis #CodeProduit à gauche et à droite. Tu obtiens "Type de relation : Un-à-plusieurs".
Coche "Appliquer l'intégrité référentielle" puis clique sur [Créer] et ça doit marcher.

Je te renvoie ta base avec cette relation définie.
Essaie de faire la même chose avec LIGNE COMMANDE MAGASIN et LIVRAISON.


JPhi33

[jedimaster10]

Super JPhi33 ! Ca marche

Je ne connaissais pas du tout cette méthode. Ca vient du fait qu'il s'agit d'une entité faible ?

Merci beaucoup

Au fait pour ma table EMPLACEMENT que je vais bientôt créée, faudrait que le la lie à la fois à RECEPTION et à LIVRAISON logiquement non ?

[jedimaster10]

JPhi33, ça m'a vraiment bien débloqué cette histoire d'entité faible. Les associations fonctionnent parfaitement en tout cas

Par contre, je n'arrive toujours pas à trouver à quelle table lier la table EMPLACEMENTS.

Sachant qu'à chaque stockage de produit (champ QuantiteStockee dans RECEPTION), la totalité doit être affecté à un ou plusieurs emplacements sachant que chaque emplacement a une capacité de stockage définie dans la table EMPLACEMENT.

Enfin, je souhaite intégrer les retours de produits qui sortent de mon entrepot mais qui sont refusés par le magasin. J'ai pensé à une table RETOUR dans laquelle serait référencé le produit livré refusé et la quantité refusée. Pour le reste des champs de la table je vois rien d'exceptionnel (si tu as une idée...). Par contre là pareil, à quoi lier cette table ? A moins que la solution nouvelle table soit mauvaise, auquel cas si tu as une idée

Merci