Bonjour Mrfof,
Envoyé par
Mrfof
C'est la solution que je cherchais pour avoir mes bon de commandes, bon de réception et après il y'auras bon de contrôle pour chaque réception avant son entrée en stock.
Par contre j'ai pas compris ta dernière phrase
Envoyé par
fsmrel
Arriverez-vous à commettre une infraction, faire en sorte qu’une ligne de réception faisant référence à la commande {1} (via la réception {1, 1}) fasse référence à la commande {2} via LIGNE_CDE ?
Votre sujet comporte en fait une règle de gestion non écrite et implicite :
RGx - Une ligne de réception ne peut pas appartenir à la fois à deux commandes distinctes.
Malheureusement, avec votre MCD initial (et le MLD qui en est dérivé, ainsi que le code SQL qui s’ensuit), cette règle peut être violée sans problème.
Exemple de code SQL inféré de votre MCD :
CREATE TABLE COMMANDE
(
cdeId INT NOT NULL,
cdeReference VARCHAR(48) NOT NULL,
cdeDate DATE NOT NULL,
CONSTRAINT COMMANDE_PK PRIMARY KEY (cdeId),
CONSTRAINT COMMANDE_AK UNIQUE (cdeReference)
) ;
CREATE TABLE LIGNE_CDE
(
cdeId INT NOT NULL,
ligneCdeId INT NOT NULL,
CONSTRAINT LIGNE_CDE_PK PRIMARY KEY (ligneCdeId),
CONSTRAINT LIGNE_CDE_COMMANDE_FK FOREIGN KEY (cdeId)
REFERENCES COMMANDE
) ;
CREATE TABLE RECEPTION
(
cdeId INT NOT NULL,
receptionId INT NOT NULL,
CONSTRAINT RECEPTION_PK PRIMARY KEY (receptionId),
CONSTRAINT RECEPTION_COMMANDE_FK FOREIGN KEY (cdeId)
REFERENCES COMMANDE
) ;
CREATE TABLE LIGNE_RECEPTION
(
receptionId INT NOT NULL,
ligneReceptionId INT NOT NULL,
ligneCdeId INT NOT NULL,
CONSTRAINT LIGNE_RECEPTION_PK PRIMARY KEY (ligneReceptionId),
CONSTRAINT LIGNE_RECEPTION_RECEPTION_FK FOREIGN KEY (receptionId)
REFERENCES RECEPTION,
CONSTRAINT LIGNE_RECEPTION_LIGNE_CDE_FK FOREIGN KEY (ligneCdeId)
REFERENCES LIGNE_CDE
) ;
insert into COMMANDE (cdeId, cdeReference, cdeDate) values (1, 'ref01', '2019-05-28')
insert into COMMANDE (cdeId, cdeReference, cdeDate) values (2, 'ref02', '2019-05-28')
select * from COMMANDE
insert into LIGNE_CDE (cdeId, ligneCdeId) values (1, 11)
insert into LIGNE_CDE (cdeId, ligneCdeId) values (1, 12)
insert into LIGNE_CDE (cdeId, ligneCdeId) values (2, 13)
insert into LIGNE_CDE (cdeId, ligneCdeId) values (2, 14)
select * from LIGNE_CDE
insert into RECEPTION (cdeId, receptionId) values (1, 21)
insert into RECEPTION (cdeId, receptionId) values (1, 22)
insert into RECEPTION (cdeId, receptionId) values (2, 23)
insert into RECEPTION (cdeId, receptionId) values (2, 24)
select * from RECEPTION
insert into LIGNE_RECEPTION (receptionId, ligneReceptionId, ligneCdeId) values (21, 211, 11)
insert into LIGNE_RECEPTION (receptionId, ligneReceptionId, ligneCdeId) values (23, 231, 13)
select * from LIGNE_RECEPTION
select distinct y.cdeId as via_reception, z.cdeId as via_ligne_commande
from LIGNE_RECEPTION as x
join RECEPTION as y on x.receptionId = y.receptionId
join LIGNE_CDE as z on x.ligneCdeId = z.ligneCdeId
where ligneReceptionId = 211
;
via_reception via_ligne_commande
2 1
Par contre, avec les tables que je vous ai proposées, la règle RGx est inviolable. En effet, la ligne de réception {1, 1, 1, 1} fait référence à la commande 1, et pour qu’elle fasse référence à la commande 2, il faudrait remplacer la valeur {1, 1, 1, 1} par la valeur {2, 1, 1, 1}, mais alors il ne s’agit plus de la même ligne de réception. Par ailleurs, quand pour une ligne de réception donnée on propose la valeur {x, y, z, t}, alors on fait référence à la seule commande x, quelles que soient les valeurs affectant y, z, t.
Relation en entité commande et réception
Répondre avec citation
Partager