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

**alexis_c** · 18/04/2023, 11h48

Bonjour,
Je cherche à concevoir une petite base de données en SQlite pour une application.
Je n'ai pas de connaissances en bdd ou en MCD.

Mon but est de pouvoir enregistrer des paramètres et des erreurs. Pouvez vous m'aider à éclaircir certains points obscurs?

Voici ce que j'ai commencé à faire : (les type sont arbitraires, ils ne correspondent pas à sqlite)
Nom : Screenshot_20230418_111354.png
Affichages : 1085
Taille : 76,8 Ko

Nom : Screenshot_20230418_111354.png
Affichages : 1085
Taille : 76,8 Ko

et voici le sql généré:

Code SQL :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
 
CREATE TABLE TYPE_MACHINE(
   TM_KEY BYTE,
   ETQ CHAR(16) NOT NULL,
   DOC VARCHAR(50),
   PRIMARY KEY(TM_KEY),
   UNIQUE(ETQ)
);
 
CREATE TABLE PARA_DEF(
   TM_KEY BYTE,
   PD_KEY BYTE,
   ETQ CHAR(16),
   DOC VARCHAR(50),
   TYPE BYTE,
   TM_KEY_1 BYTE NOT NULL,
   PRIMARY KEY(TM_KEY, PD_KEY),
   FOREIGN KEY(TM_KEY_1) REFERENCES TYPE_MACHINE(TM_KEY)
);
 
CREATE TABLE LOCALISATION(
   L_KEY BYTE,
   ETQ CHAR(8),
   DOC VARCHAR(50),
   PRIMARY KEY(L_KEY)
);
 
CREATE TABLE ERR_DEF(
   TM_KEY BYTE,
   ED_KEY BYTE,
   ETQ CHAR(16),
   DOC VARCHAR(50),
   TYPE BYTE,
   TM_KEY_1 BYTE NOT NULL,
   PRIMARY KEY(TM_KEY, ED_KEY),
   FOREIGN KEY(TM_KEY_1) REFERENCES TYPE_MACHINE(TM_KEY)
);
 
CREATE TABLE UTILISATEUR(
   U_KEY BYTE,
   NOM VARCHAR(50) NOT NULL,
   ADMIN LOGICAL,
   PRIMARY KEY(U_KEY),
   UNIQUE(NOM)
);
 
CREATE TABLE MACHINE(
   TM_KEY BYTE,
   L_KEY BYTE,
   ETQ CHAR(16),
   DOC CHAR(50),
   L_KEY_1 BYTE NOT NULL,
   TM_KEY_1 BYTE NOT NULL,
   PRIMARY KEY(TM_KEY, L_KEY),
   UNIQUE(L_KEY_1),
   FOREIGN KEY(L_KEY_1) REFERENCES LOCALISATION(L_KEY),
   FOREIGN KEY(TM_KEY_1) REFERENCES TYPE_MACHINE(TM_KEY)
);
 
CREATE TABLE PARA(
   TM_KEY BYTE,
   L_KEY BYTE,
   PD_KEY BYTE,
   VAL VARIABLE,
   TM_KEY_1 BYTE NOT NULL,
   PD_KEY_1 BYTE NOT NULL,
   TM_KEY_2 BYTE NOT NULL,
   L_KEY_1 BYTE NOT NULL,
   PRIMARY KEY(TM_KEY, L_KEY, PD_KEY),
   FOREIGN KEY(TM_KEY_1, PD_KEY_1) REFERENCES PARA_DEF(TM_KEY, PD_KEY),
   FOREIGN KEY(TM_KEY_2, L_KEY_1) REFERENCES MACHINE(TM_KEY, L_KEY)
);
 
CREATE TABLE ERR(
   E_KEY INT,
   TM_KEY BYTE NOT NULL,
   L_KEY BYTE NOT NULL,
   ED_KEY BYTE NOT NULL,
   DEB DATETIME,
   FIN DATETIME,
   TM_KEY_1 BYTE NOT NULL,
   ED_KEY_1 BYTE NOT NULL,
   TM_KEY_2 BYTE NOT NULL,
   L_KEY_1 BYTE NOT NULL,
   PRIMARY KEY(E_KEY),
   FOREIGN KEY(TM_KEY_1, ED_KEY_1) REFERENCES ERR_DEF(TM_KEY, ED_KEY),
   FOREIGN KEY(TM_KEY_2, L_KEY_1) REFERENCES MACHINE(TM_KEY, L_KEY)
);
 
CREATE TABLE MODIFIER(
   TM_KEY_1 BYTE,
   L_KEY_1 BYTE,
   PD_KEY_1 BYTE,
   U_KEY_1 BYTE,
   TM_KEY BYTE NOT NULL,
   PD_KEY BYTE,
   L_KEY BYTE,
   MEM_PARA VARCHAR(50),
   NEW_PARA VARCHAR(50),
   DATE_MODIF DATETIME,
   U_KEY VARCHAR(50),
   PRIMARY KEY(TM_KEY_1, L_KEY_1, PD_KEY_1, U_KEY_1),
   FOREIGN KEY(TM_KEY_1, L_KEY_1, PD_KEY_1) REFERENCES PARA(TM_KEY, L_KEY, PD_KEY),
   FOREIGN KEY(U_KEY_1) REFERENCES UTILISATEUR(U_KEY)
);
 
CREATE TABLE ACQUITER(
   E_KEY_1 INT,
   U_KEY_1 BYTE,
   E_KEY INT NOT NULL,
   DATE_ACQ DATE,
   U_KEY BYTE,
   PRIMARY KEY(E_KEY_1, U_KEY_1),
   FOREIGN KEY(E_KEY_1) REFERENCES ERR(E_KEY),
   FOREIGN KEY(U_KEY_1) REFERENCES UTILISATEUR(U_KEY)
);
 
CREATE TABLE CONSULTER_PARA(
   TM_KEY BYTE,
   L_KEY BYTE,
   PD_KEY BYTE,
   U_KEY BYTE,
   PRIMARY KEY(TM_KEY, L_KEY, PD_KEY, U_KEY),
   FOREIGN KEY(TM_KEY, L_KEY, PD_KEY) REFERENCES PARA(TM_KEY, L_KEY, PD_KEY),
   FOREIGN KEY(U_KEY) REFERENCES UTILISATEUR(U_KEY)
);
 
CREATE TABLE CONSULTER_ERR(
   E_KEY INT,
   U_KEY BYTE,
   PRIMARY KEY(E_KEY, U_KEY),
   FOREIGN KEY(E_KEY) REFERENCES ERR(E_KEY),
   FOREIGN KEY(U_KEY) REFERENCES UTILISATEUR(U_KEY)
);

Je ne comprends pas comment faire pour declarer que, par exemple : la clef de PARA: TM_KEY doit être la même que la clef de PARA_DEF: TM_KEY, visiblement le SQL crée une clef étrangère TM_KEY_1

Je ne comprend pas l'intérêt des tables: CONSULTER_PARA et CONSULTER_ERR, doivent elles être supprimées du MCD

Vous avez surement de nombreux conseils à me donner sur cette première approche...

En vous remerciant par avance pour le temps que vous voulez bien m'accorder.

**fsmrel** · 18/04/2023, 13h58

Bonjour alexis_c,

Pour un débutant en modélisation, vous avez choisi la bonne approche, en présentant un MCD réalisé avec l’excellent Looping.

Premières réflexions.

Considérez l’association Installer. Au vu du MCD, on l’interprète littéralement ainsi :

Un type de machine peut installer de 0 à n machine ;
Une machine est installée par un et un seul type de machine.

=> Le verbe Installer n’est pas pertinent. Comme dirait Paprick, le verbe magique Concerner passerait mieux...

Les règles de gestion :

Inspirez-vous par exemple des règles de gestion produites par aras-vbo (discussion
Modélisation d'un catalogue de produits). escartefigue passe beaucoup de temps à expliquer comment on doit rédiger soigneusement les règles de gestion, mais je n’ai pas sous la main les liens les discussions correspondantes.

Associations et identifiants :

Dans un MCD une association n’a pas d’identifiant en propre, elle hérite de celui des entités-types (classes d’entités) qu’elle met en relation. Prenons par exemple le cas de l’association Acquitter : elle ne doit avoir que l’attribut (synonymes :propriété, rubrique...) DATE_ACQ et doit être débarrassée des attributs E_KEY et U_KEY. Conformément aux règles merisiennes, Looping se chargera de les faire naître dans le MLD et le code SQL, en ajoutant les contraintes d’intégrité référentielle qui vont bien.

Nettoyage des entités-types (classes d’entités) :

Prenons le cas de l’entité-type ERR : là encore, les attributs TM_KEY et L_KEY doivent disparaître, du fait de la cardinalité 1,1 portée par la patte connectant ERR et EMETTRE, Looping générera ces attributs et la clé étrangère qui va bien.

Envoyé par alexis_c

Les type sont arbitraires, il ne correspondent pas à sqlite

Pour ne pas encombrer la lecture du MCD, vous pouvez demander à Looping de ne pas les faire figurer. Elles n’ont d’intérêt qu’en aval du MCD (MLD, code SQL). Qui plus est, le type des attributs ne concerne pas le MCD. Si Looping permet de les définir, c’est simplement en vue de la création automatique de sa part des tables SQL.

Pour les autres points qui vous embêtent, on regardera ça.

Bon courage, affaire à suivre...

**escartefigue** · 18/04/2023, 14h34

Bonjour alexis_c et bienvenue dans ce forum

Effectivement, vous démarrez sur de bonnes bases, bravo

Concernant la formalisation des règles, vous pouvez par exemple voir la réponse n°4 ICI

La démarche est louable, mais il vous sera sans doute difficile de mettre toutes les règles dans le MCD, le schéma sera trop chargé, il est préférable de les stocker à part, dans un document texte. D'autant qu'ici vous n'en avez donné qu'une partie, n'oubliez pas qu'à minima, il faut une règle par "patte" d'association. Et il peut y avoir d'autres règles supplémentaires (contraintes entre associations, définitions de domaines...).

**alexis_c** · 18/04/2023, 16h13

J'ais essayer de suivre vos consigne, pour ce résultat:

MDL:
Nom : Screenshot_20230418_152906.png
Affichages : 685
Taille : 36,3 Ko

REGLE:

Code TXT :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
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 TM 3 : Un type de machine decrit  zéro une ou plusieurs definitions d'erreurs possible

Règle M 1 : Une machine est décrit par un type de machine
Règle M 1 : Une machine est situer dans une localisation
Règle M 2 : Une machine peut posseder des paramètres
Règle M 3 : Une machine peut émettre des erreurs

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

Règle P 1 : Un paramètre est défini par une definition de paramètre
Règle P 2 : Un paramètre possede une valeur par machine
Règle P 3 : Un utilisateur peut consulter des paramètres
Règle P 4 : Un utilisateur administrateur peut modifier des paramètres

Règle ED 1 : Une définition d'erreur est défini par un type de machine
Règle ED 2 : Une définition d'erreur défini l'erreur pour chaque machine de type type machine

Règle E 1 : Une erreur est défini par une définition d'erreur
Règle E 2 : Des erreurs peuvents etre émises par des machines
Règle E 3 : Un utilisateur peut consulter des erreurs
Règle E 4 : Un utilisateur peut acquiter des erreurs

SQL:

Code SQL :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
 
CREATE TABLE TYPE_MACHINE(
   TM_KEY BYTE,
   ETQ CHAR(16) NOT NULL,
   DOC VARCHAR(50),
   PRIMARY KEY(TM_KEY),
   UNIQUE(ETQ)
);
 
CREATE TABLE PARA_DEF(
   TM_KEY BYTE,
   PD_KEY BYTE,
   ETQ CHAR(16),
   DOC VARCHAR(50),
   TYPE BYTE,
   TM_KEY_1 BYTE NOT NULL,
   PRIMARY KEY(TM_KEY, PD_KEY),
   FOREIGN KEY(TM_KEY_1) REFERENCES TYPE_MACHINE(TM_KEY)
);
 
CREATE TABLE LOCALISATION(
   L_KEY BYTE,
   ETQ CHAR(8),
   DOC VARCHAR(50),
   PRIMARY KEY(L_KEY)
);
 
CREATE TABLE ERR_DEF(
   TM_KEY INT,
   ED_KEY BYTE,
   ETQ CHAR(16),
   DOC VARCHAR(50),
   TYPE BYTE,
   TM_KEY_1 BYTE NOT NULL,
   PRIMARY KEY(TM_KEY, ED_KEY),
   FOREIGN KEY(TM_KEY_1) REFERENCES TYPE_MACHINE(TM_KEY)
);
 
CREATE TABLE UTILISATEUR(
   U_KEY BYTE,
   NOM VARCHAR(50) NOT NULL,
   ADMIN LOGICAL,
   PRIMARY KEY(U_KEY),
   UNIQUE(NOM)
);
 
CREATE TABLE MACHINE(
   TM_KEY BYTE,
   L_KEY BYTE,
   ETQ CHAR(16),
   DOC CHAR(50),
   L_KEY_1 BYTE NOT NULL,
   TM_KEY_1 BYTE NOT NULL,
   PRIMARY KEY(TM_KEY, L_KEY),
   UNIQUE(L_KEY_1),
   FOREIGN KEY(L_KEY_1) REFERENCES LOCALISATION(L_KEY),
   FOREIGN KEY(TM_KEY_1) REFERENCES TYPE_MACHINE(TM_KEY)
);
 
CREATE TABLE PARA(
   TM_KEY BYTE,
   PD_KEY BYTE,
   L_KEY BYTE,
   VAL VARIABLE,
   TM_KEY_1 BYTE NOT NULL,
   PD_KEY_1 BYTE NOT NULL,
   TM_KEY_2 BYTE NOT NULL,
   L_KEY_1 BYTE NOT NULL,
   PRIMARY KEY(TM_KEY, PD_KEY, L_KEY),
   FOREIGN KEY(TM_KEY_1, PD_KEY_1) REFERENCES PARA_DEF(TM_KEY, PD_KEY),
   FOREIGN KEY(TM_KEY_2, L_KEY_1) REFERENCES MACHINE(TM_KEY, L_KEY)
);
 
CREATE TABLE ERR(
   E_KEY INT,
   DEB DATETIME,
   FIN DATETIME,
   TM_KEY INT NOT NULL,
   ED_KEY BYTE NOT NULL,
   TM_KEY_1 BYTE NOT NULL,
   L_KEY BYTE NOT NULL,
   PRIMARY KEY(E_KEY),
   FOREIGN KEY(TM_KEY, ED_KEY) REFERENCES ERR_DEF(TM_KEY, ED_KEY),
   FOREIGN KEY(TM_KEY_1, L_KEY) REFERENCES MACHINE(TM_KEY, L_KEY)
);
 
CREATE TABLE MODIFIER(
   TM_KEY BYTE,
   PD_KEY BYTE,
   L_KEY BYTE,
   U_KEY BYTE,
   MEM_PARA VARCHAR(50),
   NEW_PARA VARCHAR(50),
   DATE_MODIF DATETIME,
   PRIMARY KEY(TM_KEY, PD_KEY, L_KEY, U_KEY),
   FOREIGN KEY(TM_KEY, PD_KEY, L_KEY) REFERENCES PARA(TM_KEY, PD_KEY, L_KEY),
   FOREIGN KEY(U_KEY) REFERENCES UTILISATEUR(U_KEY)
);
 
CREATE TABLE ACQUITER(
   E_KEY INT,
   U_KEY BYTE,
   DATE_ACQ DATE,
   PRIMARY KEY(E_KEY, U_KEY),
   FOREIGN KEY(E_KEY) REFERENCES ERR(E_KEY),
   FOREIGN KEY(U_KEY) REFERENCES UTILISATEUR(U_KEY)
);
 
CREATE TABLE CONSULTER_PARA(
   TM_KEY BYTE,
   PD_KEY BYTE,
   L_KEY BYTE,
   U_KEY BYTE,
   PRIMARY KEY(TM_KEY, PD_KEY, L_KEY, U_KEY),
   FOREIGN KEY(TM_KEY, PD_KEY, L_KEY) REFERENCES PARA(TM_KEY, PD_KEY, L_KEY),
   FOREIGN KEY(U_KEY) REFERENCES UTILISATEUR(U_KEY)
);
 
CREATE TABLE CONSULTER_ERR(
   E_KEY INT,
   U_KEY BYTE,
   PRIMARY KEY(E_KEY, U_KEY),
   FOREIGN KEY(E_KEY) REFERENCES ERR(E_KEY),
   FOREIGN KEY(U_KEY) REFERENCES UTILISATEUR(U_KEY)
);

Pour l'instant je n'ai pas bien saisi si je devai supprimer les clee que j'essaye d'imposé coté 1.1. Si j'essai de le faire cela m'impose la création de clée arbitraire pour obtenir un sql?

**fsmrel** · 18/04/2023, 16h37

Envoyé par alexis_c

Pour l'instant je n'ai pas bien saisi si je devais supprimer les clés que j'essaye d'imposé coté 1.1. Si j'essai de le faire cela m'impose la création de clés arbitraire pour obtenir un sql?

Pas d’inquiétude, on clarifiera tout cela.

En attendant, occupons-nous des utilisateurs.

Voilà ma réflexion avant d’avoir vu votre dernière réponse.

Envoyé par alexis_c

Je ne comprend pas l'intérêt des tables: CONSULTER_PARA et CONSULTER_ERR, doivent elles être supprimées du MCD ?

Considérons vos règles 10, 11 et 12.

Manifestement elles sous-entendent qu’il y a deux types d’utilisateurs : ceux qui sont administrateurs et ceux qui ne le sont pas, disons les lambdas.

Dans le schéma ci-dessous, on spécialise les utilisateurs : l’entité-type UTILISATEUR fait l’objet des sous-types ADMIN et LAMBDA. Ainsi, seuls les administrateurs peuvent modifier les paramètres.

L’identifiant des sous-types est hérité de celui de l’entité-type UTILISATEUR.

Le triangle servant à la spécialisation est fourni dans la liste des icônes de Looping (icône Héritage).

Veuillez donner une définition des attributs MEM_PARA et NEW_PARA (association MODIFIER). En l’état, ces noms sont porteurs d’ambiguïté...

L’association CONSULTER permet simplement de savoir qui a consulté quel paramètre. A vous de savoir si l’existence de cette association répond à un besoin.

**fsmrel** · 18/04/2023, 17h41

alexis_c,

Votre diagramme n’est pas un MDL (modèle de données logique ?) mais un MCD, à savoir un modèle conceptuel des données. Le mot conceptuel est très important, car on fait abstraction des contingences telles que les clés primaires et étrangères, lesquelles sont du niveau MLD (modèle logique des données) et de la plomberie propre au SGBD : on est au plus haut niveau de l’abstraction, où l’on traduit graphiquement les règles de gestion des données. On est sur la dunette, alors que le MLD est à un étage en-dessous et SQL dans la soute...

Entité-type MACHINE :

Comme dans le cas l’entité-type ERR, dans le MCD, conformément aux règles de modélisation, l’identifiant de l’entité-type TYPE_MACHINE (TM_KEY) ne doit pas faire l’objet d’un attribut de l’entité-type MACHINE : c’est donc Looping qui devra se charger d’incorporer cet attribut au sein du MLD et du code SQL (clé étrangère garantissant l’intégrité référentielle, c’est-à-dire l’intégrité des liens inter-tables).

Cette observation vaut pour les autres entités-types (PARA_DEF, PARA, ERR_DEF).

Courage, à un moment donné le déclic se produira, gardez le cap

A suivre ...

**escartefigue** · 19/04/2023, 08h48

À ce propos :

Envoyé par alexis_c

Je ne comprend pas comment faire pour declarer que , par exemple: La clef de PARA: TM_KEY doit être la même que la clef de PARA_DEF: TM_KEY, visiblement le SQL crée une clef étrangère TM_KEY_1

Tout d'abord, comme nous sommes au stade conceptuel (le MCD), nous nous garderons d'utiliser le terme de "clef", impropre à ce stade.
Ici, il s'agit d'identifiants

Si je comprends bien, vous souhaitez, que l'identifiant de l'entité-type [PARA_DEF] inclue l'identifiant de l'entité-type [TYPE_MACHINE]
Ce qui veut dire qu'au niveau SQL, la clef de la table PARA_DEF sera composée de la clef de la table TYPE_MACHINE augmentée d'un numéro pour garantir l'unicité.

Si c'est bien ce qui est souhaité, il faut utiliser l'identification relative.
Dans Looping, elle se met en œuvre de cette façon :

Côté TYPE_MACHINE, l'identifiant (que vous avez appelé TM_KEY) doit être déclaré comme type "compteur" et "identifiant"
Côté PARA_DEF, l'identifiant (que vous avez appelé PD_KEY) doit être déclaré comme type "entier" et "identifiant"
Ensuite, il faut cliquer sur la patte de l'association coté (1,1), puis activer la case "identifiant relatif"
Quand c'est fait, on observe que Looping affiche 1,1(R).

Voici le MCD et son MLD correspondant :

Nom : 01_MCD.png
Affichages : 683
Taille : 27,3 Ko

Nom : 01_MCD.png
Affichages : 683
Taille : 27,3 Ko

Nom : 03_MLD.png
Affichages : 644
Taille : 26,2 Ko

Et le script SQL, ici décliné pour SQLite, puisqu'il semble que ce soit votre SGBD :

Code SQL :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
CREATE TABLE TM_TYPE_MACHINE(
   TM_KEY INTEGER,
   TM_ETQ TEXT NOT NULL,
   TM_DOC TEXT NOT NULL,
   PRIMARY KEY(TM_KEY)
);
 
CREATE TABLE PD_PARA_DEF(
   TM_KEY INTEGER,
   PD_KEY INTEGER,
   PD_ETQ TEXT NOT NULL,
   PD_DOC TEXT NOT NULL,
   PD_TYPE INTEGER,
   PRIMARY KEY(TM_KEY, PD_KEY),
   FOREIGN KEY(TM_KEY) REFERENCES TM_TYPE_MACHINE(TM_KEY)
);

À noter :

il manque encore des règles de gestion, par exemple

Règle TM 1 : un type de machines décrit zéro une ou plusieurs machines
doit être complétée par

Règle TM 1b : une machine est décrite par un et un seul type de machines
ou encore

Règle TM 1b : une machine est décrite par un à plusieurs types de machines
ou encore...
la présence d'attributs de mêmes noms dans PARA_DEF et TYPE_MACHINE est suspecte, à argumenter

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

Schéma

Vue hybride

Discussions similaires

Partager

Partager