Demande d'aide à la conception d'un MCD de paramétrage de machines

Les explications sont claires et poussées.
Je vais prendre le temps de décortiqué tout ce que vous m'expliquez.
Je ne suis pas sur de pouvoir donné un résultat aujourd'hui.
Je vous donne un résultat dès que possible.

Bonjour Alexis,

Je vous ai bien bombardé, mais prenez tout votre temps, il n’y a pas le feu lac. N’hésitez pas à poser vos questions sur les points qui peuvent vous tracasser, même si ces questions peuvent paraître incongrues.

Bon courage, persévérez !

François

Bonsoir,

Passons aux paramètres.

Une vue sur votre MCD est la suivante (cf. post #13) :

https://www.fsmwarden.com//developpe...s(alexis)).png

Vos règles de gestion correspondantes (cf. post #13) :

Règle TM 1 : Un type de machine décrit zéro une ou plusieurs machines
Règle TM 2 : Un type machine décrit zéro un ou plusieurs définitions de paramètres
Règle M 1 : Une machine est décrite par un type de machine
Règle M 3 : Une machine peut posséder des paramètres

Règle PD 1 : Une définition de paramètre est définie par un type de machine
Règle PD 2 : Une définition de paramètre définit le paramètre pour chaque machine de type type machine

Règle P 1 : Un paramètre est défini par une définition de paramètre
Règle P 2 : Un paramètre possède une valeur par machine

:!: Question en passant : concernant les entités-types PARA_DEF et PARA, quelle est la finalité de l’attribut TYPE ?
 
Je reprends votre MCD, mais en modifiant les noms pour mieux aborder un problèmes qui va se poser. En effet, on observe :
 

(a) qu’un paramètre p1 détermine par exemple un type de paramètre tp1, lequel détermine à son tour un type de machine tm1, donc, par transitivité, le paramètre p1 détermine le type de machine tm1 ;
 
(b) que ce paramètre p1 détermine par exemple une machine m1, laquelle peut déterminer à son tour un type de machine tm2, donc, par transitivité, ce paramètre p1 peut déterminer un type de machine tm2 ;
 
(c) ainsi, du point de vue de la modélisation, tm1 n’est pas nécessairement égal à tm2. On a deux chemins pour aller d’un point à un autre, en l’occurrence d’un paramètre à un type de machine (Conterminous paths dans la littérature relationnelle, contrainte d’égalité dans la littérature merisienne, cf. Ingénierie des systèmes d'information - Merise deuxième génération : Identité d'occurrences d'entités impliquées via des relations distinctes (égalité)).

 
:!: Bien que ce ne soit pas formellement précisé, considérons désormais que les types de machine tm1 et tm2 sont égaux. Si ce choix n’est pas le bon, merci de le signaler !


Dans le MCD ci-dessous, j’ai choisi d’identifier l’entité-type PARAMETRE relativement à l’entité-type TYPE_PARAMETRE, dans la mesure où un paramètre ne peut exister qu’en relation avec le type de paramètre auquel il se rattache. Attention quand même, si on supprime un type de paramètre, ses paramètres seront supprimés, et les machines qui y font référence ne seront plus paramétrées ; s’il faut empêcher cela, il faudra prévoir un trigger au stade SQL (bon courage !)

Le MCD évolue donc du fait de l’identification relative ajoutée :

https://www.fsmwarden.com//developpe...x_chemins).png


Quoi qu’il en soit, du fait de l’identification relative, le type de machine est propagé jusqu’aux paramètres via le type de paramètre (voir la table PARAMETRE ci-dessous) :

Extrait du code SQL (avec SQLite) :

CREATE TABLE LOCALISATION
(
   L_KEY INTEGER,
   ETQ TEXT NOT NULL,
   DOC TEXT NOT NULL,
   CONSTRAINT LOCALISATION_PK PRIMARY KEY(L_KEY),
   CONSTRAINT LOCALISATION_AK UNIQUE(ETQ)
) ;

CREATE TABLE TYPE_MACHINE
(
   TM_KEY INTEGER,
   ETQ TEXT NOT NULL,
   DOC TEXT NOT NULL,
   CONSTRAINT TYPE_MACHINE_PK PRIMARY KEY(TM_KEY),
   CONSTRAINT TYPE_MACHINE_AK UNIQUE(ETQ)
) ;

CREATE TABLE MACHINE
(
   M_KEY INTEGER,
   ETQ TEXT NOT NULL,
   DOC TEXT NOT NULL,
   TM_KEY INTEGER NOT NULL,
   L_KEY INTEGER NOT NULL,
   CONSTRAINT MACHINE_PK PRIMARY KEY(M_KEY),
   CONSTRAINT MACHINE_AK UNIQUE(L_KEY),
   CONSTRAINT MACHINE_AK_1 UNIQUE(ETQ),
   CONSTRAINT MACHINE_TYPE_MACHINE_FK FOREIGN KEY(TM_KEY) 
       REFERENCES TYPE_MACHINE(TM_KEY),
   CONSTRAINT MACHINE_LOCALISATION_FK FOREIGN KEY(L_KEY) 
       REFERENCES LOCALISATION(L_KEY)
) ;

CREATE TABLE TYPE_PARAMETRE
(
   TM_KEY INTEGER,
   TP_KEY INTEGER,
   ETQ TEXT NOT NULL,
   DOC TEXT NOT NULL,
   CONSTRAINT TYPE_PARAMETRE_PK PRIMARY KEY(TM_KEY, TP_KEY),
   CONSTRAINT TYPE_PARAMETRE_AK UNIQUE(ETQ),
   CONSTRAINT TYPE_PARAMETRE_TYPE_MACHINE_FK FOREIGN KEY(TM_KEY) 
       REFERENCES TYPE_MACHINE(TM_KEY)
) ;

CREATE TABLE PARAMETRE
(
   TM_KEY INTEGER,
   TP_KEY INTEGER,
   P_KEY INTEGER,
   VAL TEXT NOT NULL,
   M_KEY INTEGER NOT NULL,
   CONSTRAINT PARAMETRE_PK PRIMARY KEY(TM_KEY, TP_KEY, P_KEY),
   CONSTRAINT PARAMETRE_TYPE_PARAMETRE_FK FOREIGN KEY(TM_KEY, TP_KEY) 
       REFERENCES TYPE_PARAMETRE(TM_KEY, TP_KEY),
   CONSTRAINT PARAMETRE_MACHINE_FK FOREIGN KEY(M_KEY) 
       REFERENCES MACHINE(M_KEY)
) ;

Pour garantir la contrainte d’égalité (tm1 = tm2), il faudra mettre en oeuvre un trigger au stade SQL, mais on peut éviter cela en trichant un tout petit peu, en tout bien tout honneur, c’est-à-dire en identifiant l’entité-type MACHINE relativement à l’entité-type TYPE_MACHINE, car ainsi on peut aussi propager le type de machine jusqu’aux paramètres via les machines :

https://www.fsmwarden.com//developpe...ble_idrel2.png

Dans ces conditions, le type de machine est propagé jusqu’aux paramètres par les deux chemins :

[...]
CREATE TABLE MACHINE
(
   TM_KEY INTEGER,
   M_KEY INTEGER,
   ETQ TEXT NOT NULL,
   DOC TEXT NOT NULL,
   L_KEY INTEGER NOT NULL,
   CONSTRAINT MACHINE_PK PRIMARY KEY(TM_KEY, M_KEY),
   CONSTRAINT MACHINE_AK UNIQUE(L_KEY),
   CONSTRAINT MACHINE_1_AK UNIQUE(ETQ),
   CONSTRAINT MACHINE_TYPE_MACHINE_FK FOREIGN KEY(TM_KEY) 
       REFERENCES TYPE_MACHINE(TM_KEY),
   CONSTRAINT MACHINE_LOCALISATION_FK FOREIGN KEY(L_KEY) 
       REFERENCES LOCALISATION(L_KEY)
) ;
[...]
CREATE TABLE PARAMETRE
(
   TM_KEY INTEGER,
   TP_KEY INTEGER,
   P_KEY INTEGER,
   TM_KEY_1 INTEGER NOT NULL,
   M_KEY INTEGER NOT NULL,
   VAL TEXT NOT NULL,
   CONSTRAINT PARAMETRE_PK PRIMARY KEY(TM_KEY, TP_KEY, P_KEY),
   CONSTRAINT PARAMETRE_TYPE_PARAMETRE_FK FOREIGN KEY(TM_KEY, TP_KEY) 
       REFERENCES TYPE_PARAMETRE(TM_KEY, TP_KEY),
   CONSTRAINT PARAMETRE_MACHINE_FK FOREIGN KEY(TM_KEY_1, M_KEY) 
       REFERENCES MACHINE(TM_KEY, M_KEY)
) ; 

Le type de machine fait l’objet de deux colonnes dans la table PARAMETRE : TM_KEY et TM_KEY_1. Pour garantir la contrainte, il suffit de supprimer l’attribut TM_KEY_1 dans la table et de remplacer cet attribut par TM_KEY dans la clé étrangère (TM_KEY_1, M_KEY) :  

CREATE TABLE PARAMETRE
(
   TM_KEY INTEGER,
   TP_KEY INTEGER,
   P_KEY INTEGER,
   VAL TEXT NOT NULL,
   M_KEY INTEGER NOT NULL,
   CONSTRAINT PARAMETRE_PK PRIMARY KEY(TM_KEY, TP_KEY, P_KEY),
   CONSTRAINT PARAMETRE_TYPE_PARAMETRE_FK FOREIGN KEY(TM_KEY, TP_KEY) 
       REFERENCES TYPE_PARAMETRE(TM_KEY, TP_KEY),
   CONSTRAINT PARAMETRE_MACHINE_1_FK FOREIGN KEY(TM_KEY, M_KEY) 
       REFERENCES MACHINE(TM_KEY, M_KEY)
) ;

A suivre.

Hello alexis_c,

Où en êtes-vous ?

Tenez bon,

François

Modélisation des erreurs.

La modélisation des erreurs est identique à celle des paramètres, mutatis mutandis :

https://www.fsmwarden.com//developpe...ns)erreurs.png

Les observations faites au sujet des paramètres s’appliquent ici.

Bonjour fsmrel,
Mon projet est de long haleine et progresse entre d'autre activité, en ce moment le projet est sur pause car je n'est pas de temps à lui accorder. Mais il seras repris dès que j'aurai plus de temps. Je reviendrais vers vous à ce moment. Et vous tiendrais au courant.
En vous remerciant pour le suivi, je m'assurerai d'en faire autant...