Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

  1. #1
    Membre du Club
    Correction MCD gestion de transport des marchandises
    Bonjour
    Je sollicite vos avis concernant un projet de gestion de transport des marchandises.

    Voici le résumé du fonctionnement de l’entreprise :
    L’entreprise possède plusieurs bureaux dans deux pays différents (ici j’appelle chaque bureau : compte).
    Chaque client qui vient avec des articles à expédier est enregistré. Après les enregistrements, les articles sont chargés dans un camion pour les expédier vers un autre bureau de l’entreprise dans un autre pays (compte destination).

    Une fois arrivée, deux cas se présentes :
    Certains articles sont directement récupère par leur destinataire ;
    D’autres sont stock dans les magasins avant l’arrivée des propriétaires (destinataire).

    Dans les deux cas, un bon de sortie est fait pour le client c’est avec celui-ci qu’il paie a la caisse.

    NB : Il ma été dit aussi qu’il est possible de transférer certains stock dans d’autres magasins




    Question :

    Je demande des pistes pour permettre la réception de chargement destiné à un compte avec la possibilité de faire des bons de sortie pour les articles récupérer et les paiements.

    Règles de gestion

    Chaque compte peut avoir plusieurs magasins, chaque magasin est lié à un seul compte ;

    Chaque magasin peut avoir plusieurs blocs (pour mieux classer les articles), chaque bloc est lié à un magasin ;

    Un enregistrement à deux comptes (expédition et destination), chaque compte peut avoir plusieurs enregistrements;

    Un enregistrement à deux clients (expéditeur et destinataire), chaque client peut avoir plusieurs enregistrements ;

    Un enregistrement à plusieurs lignes d’enregistrements, chaque ligne d’enregistrement concerne un enregistrement ;

    Chaque ligne d’enregistrements est concernée par un article, un article peut avoir plusieurs lignes d’enregistrements ;

    Chaque ligne d’enregistrements peut concerner un magasin, un magasin peut avoir plusieurs ligne d’enregistrements ;

    Chaque ligne d’enregistrements peut concerner un bloc de magasin, un bloc de magasin peut avoir plusieurs enregistrements ;

    Chaque chargement a des lignes de chargement, chaque ligne de chargement est liée à un seul chargement ;

    Chaque chargement a deux comptes (compte expédition et destination), chaque compte peut avoir plusieurs chargements ;

    Chaque ligne de chargement est liée à une ligne d’enregistrement, chaque ligne d’enregistrement peut avoir plusieurs lignes de chargement.


    Merci

  2. #2
    Expert éminent sénior
    Bonjour mrfof,

    Avant d’aller au fond des choses.

    Citation Envoyé par mrfof Voir le message
    Il ma été dit aussi qu’il est possible de transférer certains stock dans d’autres magasins.


    Votre MCD est porteur d’une contradiction concernant les stocks. En effet, selon l’association Avoir_2, un stock appartient à au moins et au plus un bloc, alors que certains magasins peuvent avoir des stocks (association Avoir_3), tout en étant dépourvus de blocs.

    Une contrainte d’exclusion est à prévoir : les stocks dans un bloc d’une part, les stocks seulement en magasin d’autre part. A cet effet, on peut par exemple spécialiser STOCK en STOCK_EN_BLOC et STOCK_HORS_BLOC. L’entité-type spécialisée STOCK_EN_BLOC est alors à associer ( Avoir_2) à BLOC, tandis que l’entité-type spécialisée STOCK_HORS_BLOC est à associer ( Avoir_3) à MAGASIN.

    Par ailleurs puisqu’un stock peut être transféré dans un autre magasin, il faudrait envisager de modéliser le suivi des transferts.
    Faites simple, mais pas plus simple ! (A. Einstein)
    E=mc², mais si on discute un peu, on peut l’avoir pour beaucoup moins cher... (G. Lacroix, « Les Euphorismes de Grégoire »)
    => La relativité n'existerait donc que relativement aux relativistes (Jean Eisenstaedt, « Einstein et la relativité générale »)

    Je ne réponds pas aux questions techniques par MP. Les forums sont là pout ça.
    __________________________________
    Bases de données relationnelles et normalisation : de la première à la sixième forme normale
    Modéliser les données avec MySQL Workbench

  3. #3
    Membre du Club
    Bonsoir fsmrel

    Merci pour la remarque

    Citation Envoyé par fsmrel Voir le message


    Votre MCD est porteur d’une contradiction concernant les stocks. En effet, selon l’association Avoir_2, un stock appartient à au moins et au plus un bloc, alors que certains magasins peuvent avoir des stocks (association Avoir_3), tout en étant dépourvus de blocs.

    Une contrainte d’exclusion est à prévoir : les stocks dans un bloc d’une part, les stocks seulement en magasin d’autre part. A cet effet, on peut par exemple spécialiser STOCK en STOCK_EN_BLOC et STOCK_HORS_BLOC. L’entité-type spécialisée STOCK_EN_BLOC est alors à associer ( Avoir_2) à BLOC, tandis que l’entité-type spécialisée STOCK_HORS_BLOC est à associer ( Avoir_3) à MAGASIN.
    Voici la nouvelle version avec la modélisation du suivi de transferts



    Transfert (De) : est la source
    Transfert (A) : est la destination

    Merci

  4. #4
    Expert éminent sénior
    Bonjour mrfof,

    Pour le transfert d’un stock, ne faut-il pas prévoir la date de ce transfert ?

    Par ailleurs, le stock S appartient à un magasin M (directement ou via un bloc B). Ce magasin M appartient au compte C. Mais le stock S référence la ligne de chargement LC, laquelle référence le chargement C, lequel référence le compte d’expédition Ce et le compte de destination Cd : C doit-il être égal à Ce ? à Cd ?

    Bonne journée
    Faites simple, mais pas plus simple ! (A. Einstein)
    E=mc², mais si on discute un peu, on peut l’avoir pour beaucoup moins cher... (G. Lacroix, « Les Euphorismes de Grégoire »)
    => La relativité n'existerait donc que relativement aux relativistes (Jean Eisenstaedt, « Einstein et la relativité générale »)

    Je ne réponds pas aux questions techniques par MP. Les forums sont là pout ça.
    __________________________________
    Bases de données relationnelles et normalisation : de la première à la sixième forme normale
    Modéliser les données avec MySQL Workbench

  5. #5
    Membre du Club
    Bonjour fsmrel

    Citation Envoyé par fsmrel Voir le message

    Pour le transfert d’un stock, ne faut-il pas prévoir la date de ce transfert ?
    Oui vous avez raison il est important de mentionner la date du transfert.

    Citation Envoyé par fsmrel Voir le message

    Par ailleurs, le stock S appartient à un magasin M (directement ou via un bloc B). Ce magasin M appartient au compte C. Mais le stock S référence la ligne de chargement LC, laquelle référence le chargement C, lequel référence le compte d’expédition Ce et le compte de destination Cd : C doit-il être égal à Ce ? à Cd ?
    Je pense les deux cas sont possibles.

    1 cas :
    Avant le chargement, le compte expéditeur qui détient les stocks peut décider de transférer certains articles dont le chargement ne va pas se faire tôt dans d’autres magasins.
    Dans ce cas, dans ce cas le compte propriétaire du magasin (C) doit être égal au compte d’expédition (Ce).

    2 cas :
    Puisque le compte de destination peut stocker les chargements reçus, donc à son tour il peut décider de transférer certains stocks (dans ses magasins).
    Dans ce cas le compte propriétaire du magasin (C) doit être égal au compte de destination (Cd).


    Le chargement est là pour dire quels sont les quantités que j’ai expédiées vers un autre compte comme mentionner dans mon premier poste.
    Chargement est comme une expédition.

  6. #6
    Expert éminent sénior
    Bonsoir mrfof,

    STOCK_HORS_BLOC et STOCK_EN_BLOC : ces entités-types n’ont pas à avoir d’identifiant en propre, car elles héritent de l’identifiant de STOCK.

    Citation Envoyé par
    Avant le chargement, le compte expéditeur qui détient les stocks peut décider de transférer certains articles dont le chargement ne va pas se faire tôt dans d’autres magasins.
    Dans ce cas, dans ce cas le compte propriétaire du magasin (C) doit être égal au compte d’expédition (Ce).

    Soit (S) un stock donné. Via ASSO_24 (ou ASSO_25 et AVOIR_5) on sait quel est le magasin (M) qui détient (S). Connaissant (M), on connaît donc (C) (via POSSEDER).

    Maintenant, si je vous suis :

    Avant un 1er chargement, les associations CPTE_EXPEDITION et CPTE_DESTINATION ne sont pas valorisées, auquel cas le compte d’expédition (Ce) est forcément (C).
    Après ce 1er chargement, via CPTE_DESTINATION on sait précisément quel est le compte de destination (Cd). En même temps, l’association CPTE_EXPEDITION fait double emploi, c’est-à-dire qu’il y a une redondance à assurer, (C) = (Ce), ce qui n’est pas sain. Dans le cas général, peut-on dire que via ASSO_24 (ou ASSO_25 et AVOIR_5), le magasin (M) qui détient le stock (S) appartient au compte (C) tel que (C) = (Ce) ? Si oui, l’association CPTE_EXPEDITION peut disparaître. Si non, avez-vous un contre exemple justifiant la conservation dans le MCD de cette association ?
    Faites simple, mais pas plus simple ! (A. Einstein)
    E=mc², mais si on discute un peu, on peut l’avoir pour beaucoup moins cher... (G. Lacroix, « Les Euphorismes de Grégoire »)
    => La relativité n'existerait donc que relativement aux relativistes (Jean Eisenstaedt, « Einstein et la relativité générale »)

    Je ne réponds pas aux questions techniques par MP. Les forums sont là pout ça.
    __________________________________
    Bases de données relationnelles et normalisation : de la première à la sixième forme normale
    Modéliser les données avec MySQL Workbench

  7. #7
    Membre du Club
    Bonsoir fsmrel

    Citation Envoyé par fsmrel Voir le message

    STOCK_HORS_BLOC et STOCK_EN_BLOC : ces entités-types n’ont pas à avoir d’identifiant en propre, car elles héritent de l’identifiant de STOCK.
    D'accord

    Citation Envoyé par fsmrel Voir le message


    Maintenant, si je vous suis :

    Avant un 1er chargement, les associations CPTE_EXPEDITION et CPTE_DESTINATION ne sont pas valorisées, auquel cas le compte d’expédition (Ce) est forcément (C).
    Après ce 1er chargement, via CPTE_DESTINATION on sait précisément quel est le compte de destination (Cd). En même temps, l’association CPTE_EXPEDITION fait double emploi, c’est-à-dire qu’il y a une redondance à assurer, (C) = (Ce), ce qui n’est pas sain. Dans le cas général, peut-on dire que via ASSO_24 (ou ASSO_25 et AVOIR_5), le magasin (M) qui détient le stock (S) appartient au compte (C) tel que (C) = (Ce) ? Si oui, l’association CPTE_EXPEDITION peut disparaître.
    Oui c'est toujours le cas : le compte qui détiens le stock expédie vers un autre compte ça ne change pas.

  8. #8
    Expert éminent sénior
    Bonsoir mrfof,

    Citation Envoyé par mrfof Voir le message
    Oui c'est toujours le cas : le compte qui détiens le stock expédie vers un autre compte ça ne change pas.
    Donc l’association CPTE_EXPEDITION peut disparaître, on sait l'inférer. Au stade SQL il faudra quand même développer un trigger pour s’assurer (via ASSO_24 (ou ASSO_25 et AVOIR_5) et POSSEDER) que tous les stocks d’un chargement font référence à un seul compte d’expédition.

    Peut-on extrapoler à l’association CPTE_EXPEDITION définie entre les entités-types ENREGISTREMENT et COMPTE, c’est-à-dire inférer cette association à partir de STOCK là aussi ?
    Faites simple, mais pas plus simple ! (A. Einstein)
    E=mc², mais si on discute un peu, on peut l’avoir pour beaucoup moins cher... (G. Lacroix, « Les Euphorismes de Grégoire »)
    => La relativité n'existerait donc que relativement aux relativistes (Jean Eisenstaedt, « Einstein et la relativité générale »)

    Je ne réponds pas aux questions techniques par MP. Les forums sont là pout ça.
    __________________________________
    Bases de données relationnelles et normalisation : de la première à la sixième forme normale
    Modéliser les données avec MySQL Workbench

  9. #9
    Membre du Club
    Bonsoir fsmrel

    Citation Envoyé par fsmrel Voir le message

    Peut-on extrapoler à l’association CPTE_EXPEDITION définie entre les entités-types ENREGISTREMENT et COMPTE, c’est-à-dire inférer cette association à partir de STOCK là aussi ?
    J'ai pas compris

  10. #10
    Expert éminent sénior
    Bonsoir mrfof,

    Citation Envoyé par mrfof Voir le message
    J’ai pas compris
    Ma question revient à ceci : si dans le MCD on supprime l’association CPTE_EXPEDITION reliant ENREGISTREMENT et COMPTE, sait-on inférer, déterminer cette association grâce à STOCK, sur la base des liens suivants :

    un stock détermine une ligne d’enregistrement, laquelle détermine un enregistrement


    sachant par ailleurs que ce stock est sensé déterminer le bon compte d’expédition via LIGNE_CHARGEMENT, CHARGEMENT et COMPTE.
    Faites simple, mais pas plus simple ! (A. Einstein)
    E=mc², mais si on discute un peu, on peut l’avoir pour beaucoup moins cher... (G. Lacroix, « Les Euphorismes de Grégoire »)
    => La relativité n'existerait donc que relativement aux relativistes (Jean Eisenstaedt, « Einstein et la relativité générale »)

    Je ne réponds pas aux questions techniques par MP. Les forums sont là pout ça.
    __________________________________
    Bases de données relationnelles et normalisation : de la première à la sixième forme normale
    Modéliser les données avec MySQL Workbench

  11. #11
    Expert éminent sénior
    Bonsoir mrfof,

    Est-ce plus clair ?

    Du point de vue de la modélisation, ces redondances potentielles ne sont quand même pas inintéressantes à étudier.
    Faites simple, mais pas plus simple ! (A. Einstein)
    E=mc², mais si on discute un peu, on peut l’avoir pour beaucoup moins cher... (G. Lacroix, « Les Euphorismes de Grégoire »)
    => La relativité n'existerait donc que relativement aux relativistes (Jean Eisenstaedt, « Einstein et la relativité générale »)

    Je ne réponds pas aux questions techniques par MP. Les forums sont là pout ça.
    __________________________________
    Bases de données relationnelles et normalisation : de la première à la sixième forme normale
    Modéliser les données avec MySQL Workbench

###raw>template_hook.ano_emploi###