MCD de participation OF (Ordre de Fabrication)

Salut

Je trouve un peu de difficulté à modéliser ces règles ci-dessous avec mon GPAO.

Ce sujet est en rapport avec mon ancien poste ici

Règles

Zéro ou plusieurs Employés peut participer à Zéro ou plusieurs OF

Zéro ou plusieurs OF peut être participé par Zéro ou plusieurs Employés

Je sais c’est une relation n,n qui génère une table en MLD jusque là ça va.

Pièce jointe 483903


Problème
Soit OF_Employe(idof#,idemp#, duree) la table générée mais le souci est que : en réalité
Un même employé, peut participer Zéro ou plusieurs fois le ou les mêmes OF
Un OF aussi peut être participé par Zéro ou plusieurs fois les mêmes employés (avec les durées de participation)

Et en regardant cette OF_Employe aucune duplication n’est possible (je ne cherche même pas a le faire même)

Le souhait

Considerons le tableau suivant comme celle des OF

idof	quantite	priorite	statut
1	500	1	1

table Employe

idemp	nom
1	Emp A
2	Emp B
3	Emp C

table OF_Employe

idof	idemp	duree
1	1	2
1	1	5
1	2	1
1	2	3

L'objectif pour moi est de savoir quels employé a participer à quels OF et connaitre son temps global (somme des temps)

Je suis disposé à ré-expliquer si mon explication n'est pas claire.

Maintenant je cherche de bonnes idées des experts de ce site.

Merci

Bonsoir mrfof,

Citation:

---

Envoyé par mrfof

Un même employé, peut participer Zéro ou plusieurs fois le ou les mêmes OF
Un OF aussi peut être participé par Zéro ou plusieurs fois les mêmes employés (avec les durées de participation)

---

Vous pouvez transformer l’association PARTICIPER en entité-type :

Pièce jointe 483907

D’où le MLD

Pièce jointe 483910

Bsonsoir Fsmrel

Merci pour votre intervention

Dans entité-type PARTICIPER je vois un attribut quantite donc je me pose la question c'est duree ou quantite ?

Citation:

---

Envoyé par mrfof

Dans entité-type PARTICIPER je vois un attribut quantite donc je me pose la question c'est duree ou quantite ?

---

Distraction de ma part, bien entendu, c’est duree.


En complément :

Comme JMerise n’est pas bien exact quant à la production du code SQL, voici ce que l’on doit attendre (j’ai mis le mot OF entre crochets car c’est un mot réservé SQL, il faudrait que vous le changiez pour éviter des désagréments) :

CREATE TABLE [OF]                                         
(
        idof       INTEGER       NOT NULL
      , CONSTRAINT OF_PK PRIMARY KEY (idof)
) 
;
CREATE TABLE EMPLOYE
(
        empid       INTEGER       NOT NULL
      , CONSTRAINT EMPLOYE_PK PRIMARY KEY (empid)
)
;
CREATE TABLE PARTICIPER
(
        idof       INTEGER       NOT NULL
      , empid      INTEGER       NOT NULL
      , parid      INTEGER       NOT NULL
      , duree      INTEGER       NOT NULL
   , CONSTRAINT PARTICIPER_PK PRIMARY KEY (idof, empid, parid)
   , CONSTRAINT PARTICIPER_OF_FK FOREIGN KEY (idof) 
        REFERENCES [OF] (idof) 
   , CONSTRAINT PARTICIPER_EMP_FK FOREIGN KEY (empid) 
        REFERENCES EMPLOYE (empid) 
)
;

Merci Fsmrel

Vos explications sont plus que parfait.

Je demande votre avis et celui de tout les autres sur un point que je rencontre très souvent dans mes projets.

Considérons le MCD ci-dessous (MCD de réception des articles)

Pièce jointe 484091

SCENARIO 1

Dans un premier temps, on enregistre les unités : Kg, g, V
Puis on enregistre article A001 : unité = Kg, contrôle = true
Puis on enregistre article A002 : unité = g, contrôle = false

Après plusieurs réceptions article A001 n’est plus disponible en kg mais en g donc je dois modifier son unité.

Problème : Vu que j’ai des anciennes données (réceptions) qui concerne ancienne unité (kg) de A001, si je modifie et que je reviens voir mes anciennes réceptions c’est nouvelle unité que je verrai.

Je cherche des idées pour que même après cette modification, ça ne n'impacte pas sur les anciennes données.
J’ai eu idée de mettre une relation entre entités-type ligne de réception et unité (bien sur en contrôlant les clés avec les conseils de Fsmrel sur l’une de mes anciennes discussions) et je me demande s’il n’existe pas une autre meilleure solution.


SCENARIO 2

Tout les articles contrôlables doivent est contrôler avant d’entrer en stock (tenir compte dans les calculs)

Comme vous pouvez le voir chaque ligne de réception si ça concerne un article contrôlable est contrôlé, et si c’est fait ça apparait dans la table contrôle (trois statut sont possible : 1 = valide, 2= invalide)

Les calculs de stock diffèrent selon le type article c’est-à-dire si c’est contrôlable ou pas

1- Cas d’articles contrôlables : Jointure entre les 3 tables :, article, ligne_reception et contrôle (statut = 1)
2- Cas d’articles non contrôlable : Jointure entre 2 tables : article, ligne_reception

Maintenant imaginez après plusieurs réceptions d’un article contrôlable dans un premier temps, vous vous rendez compte que l’article ne doit plus être contrôler et vous modifiez attribut contrôle à false.

Là dans les calculs de stock, on ignora ses lignes de la table contrôle en se basant uniquement sur celles de la réception.

Ces comportements pour les deux scénarios vous parait normal ?

Merci

Bonsoir mrfof,


Avant d’étudier plus avant votre problème, je pose la question suivante :

A une date donnée, un article peut-il être critérisé selon plusieurs unités ? Une seule unité ?

Bonsoir Fsmrel

Citation:

---

Envoyé par fsmrel

A une date donnée, un article peut-il être critérisé selon plusieurs unités ? Une seule unité ?

---

C'est le pire des cas. Mais c'est pas possible. Donc un article peut pas avoir plusieurs unité a une seule date.

Merci

Si donc à une date donnée un article ne peut être critérisé que par une seule unité, la partie correspondante du MCD devient :

Pièce jointe 484265


MLD

Pièce jointe 484269


SQL

CREATE TABLE UNITE
(
        idUnite          INTEGER        NOT NULL
    , constraint UNITE_PK primary key (idUnite)
)
;
CREATE TABLE ARTICLE
(
        idArticle        INTEGER          NOT NULL
      , idUnite          INTEGER          NOT NULL
      , dateUniteApplicableDepuis   DATE  NOT NULL
    , constraint ARTICLE_PK primary key (idArticle)
    , constraint ARTICLE_UNITE_FK foreign key (idUnite)
          references UNITE
)
;
CREATE TABLE ARTICLE_UNITE_HISTO
(
        idArticle        INTEGER          NOT NULL
      , dateUniteApplicableDebut   DATE   NOT NULL
      , dateUniteApplicableFin     DATE   NOT NULL
      , idUnite          INTEGER          NOT NULL
    , constraint ARTICLE_UNITE_HISTO_PK primary key (idArticle, dateUniteApplicableDebut)
    , constraint ARTICLE_UNITE_HISTO_ARTICLE_FK foreign key (idArticle)
          references ARTICLE on delete cascade
    , constraint ARTICLE_UNITE_HISTO_UNITE_FK foreign key (idUnite)
          references UNITE
)
;

Ainsi, on sait toujours quelle unité est applicable à un article à une date donnée (au moins pour le présent et le passé).

Bonsoir Fsmrel

L'explication est très claire

Vous pensez que je dois faire la même chose avec contrôle ?

Bonsoir à nouveau,

Je ne l’ai pas précisé, mais l’attribut dateUniteApplicableDepuis de l’entité-type ARTICLE permet de savoir quelle unité est en vigueur depuis telle date. Par contraste, les attributs dateUniteApplicableDebut et dateUniteApplicableFin permettent de savoir quelle unité était en vigueur durant telle période du passé.

Si au fil du temps le mode de contrôle d’un article peut changer, cela est aussi à modéliser :


MCD

Pièce jointe 484343

MLD

Pièce jointe 484346

SQL

CREATE TABLE UNITE
(
        idUnite          INTEGER        NOT NULL
    , constraint UNITE_PK primary key (idUnite)
)
;
CREATE TABLE ARTICLE
(
        idArticle        INTEGER             NOT NULL
      , idUnite          INTEGER             NOT NULL
      , dateUniteApplicableDepuis      DATE  NOT NULL
      , dateControleApplicableDepuis   DATE  NOT NULL
    , constraint ARTICLE_PK primary key (idArticle)
    , constraint ARTICLE_UNITE_FK foreign key (idUnite)
          references UNITE
)
;
CREATE TABLE ARTICLE_UNITE_HISTO
(
        idArticle        INTEGER          NOT NULL
      , dateUniteApplicableDebut   DATE   NOT NULL
      , dateUniteApplicableFin     DATE   NOT NULL
      , idUnite          INTEGER          NOT NULL
    , constraint ARTICLE_UNITE_HISTO_PK primary key (idArticle, dateUniteApplicableDebut)
    , constraint ARTICLE_UNITE_HISTO_ARTICLE_FK foreign key (idArticle)
          references ARTICLE on delete cascade
    , constraint ARTICLE_UNITE_HISTO_UNITE_FK foreign key (idUnite)
          references UNITE
)
;
CREATE TABLE ARTICLE_CONTROLE_HISTO
(
        idArticle        INTEGER             NOT NULL
      , dateControleApplicableDebut   DATE   NOT NULL
      , dateControleApplicableFin     DATE   NOT NULL
      , idUnite          INTEGER             NOT NULL
    , constraint ARTICLE_CONTROLE_HISTO_PK primary key (idArticle, dateControleApplicableDebut)
    , constraint ARTICLE_CONTROLE_HISTO_ARTICLE_FK foreign key (idArticle)
          references ARTICLE on delete cascade
)
;

Pour en savoir plus, voyez ici, j’y traite de la dimension temporelle des choses.


Accessoirement, en haut et à gauche de ce message, vous pouvez cliquer sur fsmrel, puis profil pro > compétences.

Bonsoir Fsmrel

Vraiment je n'ai plus de mots a dire. les explication est très claire.

Vous occupez avec vos collègues une place trèèèèèès importante sur la communauté.

Merci

Bonsoir mrfof,

Merci à mon tour !

escartefigue et moi-même faisons de notre mieux pour répondre aux questions posées. Je suis heureux que vous soyez satisfait des solutions apportées. ;)