Bonjour,
Envoyé par
cfried
Le pilote peinture peut être considéré comme l'administrateur des essais de catégorie peinture qui prennent en compte ces données de compatibilité de peintures. Ainsi c'est lui qui est capable de déterminer cette compatibilité.
J'imagine donc un système dans lequel on aurait des enregistrements associant primaire, base et vernis dans la table proc_peinture qui ne seraient pas forcément adéquats et le booléen PP_COMPATIBLE (défini à 0 par défaut) passerait à 1 quand le pilote_peinture valide cette association.
Un tel système s'appelle une association entre Primaire, Base et Vernis. C'est donc l'association Processus. Celle-ci peut comporter le booléen indiquant si la combinaison a été validée par un pilote peinture ainsi que le libellé PP_LIB. Au niveau logique, cette association produit la table (la clé est soulignée) :
Processus (PRIMAIRE_ID, BASE_ID, VERNIS_ID, PP_COMPATIBLE, PP_LIB)
L'avantage de cette modélisation est qu'elle interdit la création de doublons pour le triplet {primaire, base, vernis}. Alors qu'avec la modélisation d'une entité Processus_peinture (identifiée par PP_ID), ces doublons sont permis. On pourrait ainsi se retrouver avec la liste suivante :
1
2
3
4
5
6
7
8
|
Processus Primaire Base Vernis
--------- -------- ---- ------
PP1 P1 B1 V1
PP2 P1 B1 V1
PP3 P1 B1 V1
PP4 P1 B1 V1
... |
c'est-à-dire une infinité de triplets identiques.
L'inconvénient est que la modélisation des associations Produit_peint, Peinture_Usine et Comp_peint est impossible avec un logiciel de modélisation, qu'il s'agisse d'Open ModelSphere ou d'un autre, car ils ne permettent pas les associations entre associations.
La bonne solution est celle donnée par f-leb (dans laquelle je renomme ProcessusCompatible en Processus) :
Envoyé par
f-leb
[...] remplacer l'association "Processus" par une pseudo-entité "Processus":
Processus----1,1----(R1)----0,n---Base
Processus----1,1----(R2)----0,n---Primaire
Processus----1,1----(R3)----0,n---Vernis
le 1,1 souligné marquant l'identification relative [...]
Evidemment, on exclut de cette entité tout identifiant propre (PP_ID doit être supprimé). Cette "entité associative" est donc identifiée par le triplet {PRIMAIRE_ID, BASE_ID, VERNIS_ID}. Au niveau logique, on obtient la table :
Processus (PRIMAIRE_ID, BASE_ID, VERNIS_ID, PP_COMPATIBLE, PP_LIB)
c'est-à-dire exactement la même table que celle obtenue plus haut par transformation de l'association Processus.
Ceci étant fait, revenons sur le booléen PP_COMPATIBLE :
Envoyé par
cfried
[...] on aurait des enregistrements associant primaire, base et vernis dans la table qui ne seraient pas forcément adéquats et le booléen PP_COMPATIBLE (défini à 0 par défaut) passerait à 1 quand le pilote_peinture valide cette association.
On peut se demander à quoi servent des combinaisons non validées. Donc une solution plus simple serait peut-être de se passer du booléen et de ne faire figurer (de n'enregistrer) que les combinaisons validées.
Concrètement, le pilote peinture n'enregistre dans la table que les combinaisons qu'il a validées.
Base de Validation Équipementier
Répondre avec citation
Les 
En cas de résolution, et afin de faciliter la tâche des bénévoles, merci de cliquer sur 
et 
permettent aux forumeurs de cibler leur recherche dans une discussion : n'hésitez pas à voter !
Partager