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

Version imprimable

Voir 40 message(s) de cette discussion en une page

1 pièce(s) jointe(s)

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

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)
Pièce jointe 637459

et voici le sql généré:

Code:

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.

18/04/2023, 13h58
fsmrel

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.

Citation:

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...
18/04/2023, 14h34
escartefigue

Bonjour alexis_c et bienvenue dans ce forum :P

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

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...).

1 pièce(s) jointe(s)

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

MDL:
Pièce jointe 637467

REGLE:

Code:

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:

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?

18/04/2023, 16h37
fsmrel

Citation:

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.

Citation:

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.

https://www.fsmwarden.com/developpez...lisateurs).png

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.
18/04/2023, 17h41
fsmrel

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 ...

2 pièce(s) jointe(s)

À ce propos :

Citation:

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 :

Pièce jointe 637488

Pièce jointe 637489

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

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

2 pièce(s) jointe(s)

Nouvelle version:

Pièce jointe 637492

Code:

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
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 2 : Une machine est situer dans une localisation
Règle M 3 : Une machine peut posseder des paramètres
Règle M 4 : 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 P 5 : Les paramètres peuvent être de 3 types differents: BOOL, ANA, STR

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

Règle U 1 : Les utilisateurs peuvent être de deux type: ADMIN ou LAMBDA
Règle U 2 : Les admins peuvent modifier les parametres
Règle U 3 : Tous les utilisateurs peuvent acquiter les défauts

Citation:

Envoyé par fsmrel

Veuillez donner une définition des attributs MEM_PARA et NEW_PARA

Le but était d'obtenir un enregistrement de l'état du parametre avant et après modification.
J'ai modifié, après tout l'état du paramêtre avant modification correspond à la valeur de l'enregistrement précèdant.
Mais je me demande comment représenté qu'il faut enregistré de quel parametre il sagit?

J'ai essayé de reproduire l'heritage concernant les utilisateurs avec les parametres et la possibilité de les séparés par type

19/04/2023, 12h23
fsmrel
Bonjour,

Citation:

Envoyé par alexis_c

Règle P 5 : Les paramètres peuvent être de 3 types différents: BOOL, ANA, STR

Selon votre MCD, Un paramètre a une valeur. D’après la règle P 5, cette valeur peut être du type BOOL ou ANA ou STR.

A priori le type du paramètre fait l’objet d’un attribut TypeParametre de l’entité-type PARA, en compagnie de l’attribut VAL. Le contrôle de ces trois valeurs sera assuré dans la soute par une contrainte SQL :
```
ALTER TABLE PARA 
    ADD CONSTRAINT PARA_TYPE 
        CHECK  (TypeParametre IN (BOOL, ANA, STR)) ; 
```
Cette instruction ALTER TABLE peut être déclarée avec Looping.

Le fait d’avoir mi en oeuvre les sous-types PARA_BOOL, PARA_ANA et PARA_STR signifie que chacun d’eux sera doté d’attributs que n’auront pas les autres. Prenons par exemple le cas de l’entité-type PERSONNE (dotée des attributs NOM, ADRESSE) : elle a pour sous-types PERSONNE_PHYSIQUE et PERSONNE_MORALE (entreprise) car les personnes physiques ont un NIR(numéro de sécurité sociale) tandis que les entreprises on un numéro de SIREN (SIRET). Ainsi, on factorise les attributs communs et on spécialise les attributs spécifiques.

Je vous parlerai de l’association MODIFIER.
19/04/2023, 13h32
alexis_c

j'ais essayé de séparé la définition d'un paramètre, qui est décrit par le type de machine et est fixé, de la valeur du paramètre, qui lui est modifiable et est différent pour chaque machine.
Avec cette logique, la définition du type de parametre ne doit-elle pas appartenir a la définition du paramètre. Sinon il faudra renseigné le type du paramètre a chaque modification du paramètre? L'argument TYPE de l'élement PARA_DEF est censé permètre la discrimination.
19/04/2023, 13h49
alexis_c

1 pièce(s) jointe(s)

Pièce jointe 637518
19/04/2023, 17h04
fsmrel
Intéressons-nous un moment aux modifications effectuées par les administrateurs.

Dans votre MCD, l’association MODIFIER est porteuse de deux attributs : NEW_PARA et DATE_MODIF :

https://www.fsmwarden.com//developpe...dmin-para).png

Votre entité-type PARA n’a pas d’attribut identifiant. Définissons-en un, par exemple PARA_KEY prenant les valeurs p1, p2, etc.. Dans ces conditions, on a la représentation suivante, dans laquelle l’administrateur u1 modifie le paramètre p1, à la date d1, pour valoriser le nouveau paramètre à n1 (je souligne les identifiants) :
```
MODIFIER ( U_KEY    PARA_KEY    DATE_MODIF    NEW_PARA )
           u1       p1          d1            n1
```
Première remarque : si l’administrateur u1 veut par la suite modifier le paramètre p1 à la date d2 et lui affecter la valeur n2, on est obligé de remplacer la ligne ci-dessus par celle-ci :
```
MODIFIER ( U_KEY    PARA_KEY    DATE_MODIF    NEW_PARA )
           u1       p1          d2            n2
```
On a donc perdu la trace de la 1re modification... En effet, pour une valeur donnée d’identifiant (U_KEY, PARA_KEY), on n’a droit qu’à une seule valeur pour les autres attributs (DATE_MODIF et NEW_PARA). C’est une règle de base de la modélisation E/R...
Je vous engage à étudier l’art de construire un MCD, avec l’ouvrage de Dominique Nanci (RIP) Ingénierie des systèmes d'information : Merise deuxième génération (4e édition, 2001), au chapitre 7 dédié au MCD (c’est gratuit !)

Si vous voulez conserver l’historique des interventions, la date doit faire partie de l’identifiant :
```
Modifier ( U_KEY    PARA_KEY    DATE_MODIF    NEW_PARA )
           u1       p1          d1            n1     
           u1       p1          d2            n2
```
Conséquence : on doit définir une entité-type DATE (ou plutôt un nom du genre CALENDRIER car DATE est un mot réservé) :

https://www.fsmwarden.com//developpe...para-date).png

Deuxième remarque :

Selon votre MCD du post #11, l’entité-type PARA est identifiée relativement à l’entité-type MACHINE, ce qui n’était pas le cas dans le post #8 qui m’a servi pour ce que je viens d’écrire. Prenez l’habitude de faire systématiquement figurer les identifiants dans les rectangles symbolisant les entités-types. Prenons par exemple l’attribut MAC_ID pour identifier l’entité-type MACHINE. Je dois donc faire évoluer l’association MODIFIER ainsi :
```
MODIFIER ( U_KEY    MAC_ID    PARA_KEY    DATE_MODIF    NEW_PARA )
           u1       m1        p1          d1            n1     
           u1       m1        p1          d2            n2
```
Je rappelle en passant que l’entité-type PARA est dit faible par rapport à l’entité-type MACHINE, ce qui veut dire que la suppression d’une machine, en principe, entraîne automatiquement celle de ses paramètres.

Cela dit, l’attribut NEW_PARA est suspect, car vous avez écrit (post #8) :

« Le but était d'obtenir un enregistrement de l'état du paramètre avant et après modification.
J'ai modifié, après tout l'état du paramètre avant modification correspond à la valeur de l'enregistrement précèdent. »

Autrement dit la situation devrait être la suivante, après modification du paramètre p1, dont la valeur passe de v1 à v2 à la date d2 :
```
MACHINE ( MAC_ID    ... )
          m1

PARA ( MAC_ID    PARA_KEY    DATE_MODIF    VAL    U_KEY)
       m1        p1          d1            v1     u1
       m1        p1          d2            v2     u1
```
Ce qui se lit :

à la date d1, le paramètre p1 de la machine m1 a pour valeur v1, et il a été créé par l’administrateur u1 ;
à la date d2, le paramètre p1 de la machine m1 a pour valeur v2, et il a été créé par l’administrateur u1.

Si cela correspond à ce que vous attendez, le MCD est à faire évoluer ainsi :
https://www.fsmwarden.com//developpe...ra-date)v2.png

Sinon précisez la règle du jeu.

1 pièce(s) jointe(s)

Citation:

Envoyé par fsmrel

Votre entité-type PARA n’a pas d’attribut identifiant.

Pour moi l'identifiant de PARA était: TM_KEY L_KEY P_KEY par identifiant relatif.

Nouvel version:
Pièce jointe 637551

Code:

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
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 2 : Une machine est situer dans une localisation
Règle M 3 : Une machine peut posseder des paramètres
Règle M 4 : 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 P 5 : Les paramètres peuvent être de 3 types differents: BOOL, ANA, STR
Règle P 6 : La modification d'un paramètre est enregistré dans l'historique

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

Règle U 1 : Les utilisateurs peuvent être de deux type: ADMIN ou LAMBDA
Règle U 2 : Les admins peuvent modifier les parametres
Règle U 3 : Tous les utilisateurs peuvent acquiter les défauts

Règle H 1 : L'historique enregistre la modification de chaque paramètre

En espèrant avoir bien saisi vos consigne.

20/04/2023, 18h11
fsmrel

Bonsoir alexis_c,

Citation:

Envoyé par alexis_c

Citation:

Envoyé par fsmrel

Votre entité-type PARA n’a pas d’attribut identifiant.

Pour moi l'identifiant de PARA était: TM_KEY L_KEY P_KEY par identifiant relatif.

Un rappel

Règle générale : Au niveau conceptuel, à chaque entité-type on affecte un attribut particulier (synonymes : rubrique, propriété...), l’identifiant, dont l’objet est de distinguer des jumeaux parfaits.

Une vue sur votre MCD :

https://www.fsmwarden.com//developpe...c(idrel)v2.png

L’entité-type TYPE_MACHINE est dotée de l’attribut identifiant TM_KEY : la règle générale est respectée, on ne pourra jamais avoir deux types de machines ayant la même valeur pour l’attribut TM_KEY.

A son tour, l’entité-type LOCALISATION est dotée de l’attribut identifiant L_KEY : la règle générale est respectée, on ne pourra jamais avoir deux localisations ayant la même valeur pour l’attribut L_KEY.

Passons à l’entité-type MACHINE : vous l’avez dotée de deux attributs formant une paire, {TM_KEY, L_KEY}, et vous avez souligné ces deux attributs : ils constituent donc l’identifiant de MACHINE. La règle générale de l’identifiant mono-attribut a été étendue : ceci est parfaitement légal.

Vous avez défini une association DECRIRE_MACH entre les entités-types TYPE_MACHINE et MACHINE, où la patte d’association connectant MACHINE et DECRIRE_MACH est porteuse d’une cardinalité 1(R).

Intéressons-nous pour le moment au chiffre 1 figurant dans 1(R). Ce chiffre 1 signifie qu’une machine fait référence à au moins et au plus un type de machine. Lors du passage au MLD (modèle logique des données) puis au code SQL, les entités-types TYPE_MACHINE et MACHINE deviennent des tables. La règle est que l’attribut TM_KEY de la table TYPE_MACHINE fasse partie des attributs (colonnes si vous préférez) de l’en-tête de la table MACHINE. L’en-tête est un ensemble, en l’occurrence l’ensemble des noms des attributs de la table. L’en-tête de la table MACHINE est donc le suivant (pour simplifier, je fais abstraction de l’entité-type LOCALISATION, mais son tour viendra) :

{TM_KEY, L_KEY, ETQ, DOC, TM_KEY1}

Les attributs TM_KEY, L_KEY, ETQ et DOC proviennent de l’entité-type MACHINE, tandis que l’attribut TM_KEY1 provient de l’entité-type TYPE_MACHINE, dont le nom TM_KEY a été suffixé par le chiffre 1 car le nom TM_KEY ne peut pas figurer deux fois dans l’en-tête, qui rappelons-le est un ensemble (au sens de la théorie des ensembles). Concernant TM_KEY1, peu importe ce nom, il pourrait être renommé en XYZT.

Dans ce contexte, l’identifiant de l’entité-type MACHINE devient ce qu’on appelle la clé primaire de la table MACHINE. Comme dans le cas de l’identifiant de l’entité-type MACHINE, la clé primaire de la table MACHINE est composée des attributs TM_KEY et L_KEY. Pour sa part, TM_KEY1 permet d’établir un lien avec la table TYPE_MACHINE : chaque valeur de l’attribut TM_KEY1 doit être une valeur de l’attribut TM_KEY de la table TYPE_MACHINE. L’ensemble singleton {TM_KEY1} est par définition une clé étrangère (foreign key) imposant que chaque valeur de TM_KEY1 existe d’abord en tant que valeur de la clé primaire {TM_KEY} dans la table TYPE_MACHINE : on a établi ce qu’on appelle une contrainte d’intégrité référentielle.

Jusqu’ici, on ne s’est intéressé qu’au chiffre 1 (cardinalité minimale ou minimum ou mini, ...) de la patte d’association connectant MACHINE et DECRIRE_MACH. Or cette patte est porteuse du fameux et mystérieux symbole « 1(R) ». « (R) » est là pour signifier que l’identification est relative, c’est-à-dire que l’attribut TM_KEY1 participe nécessairement à l’identification de MACHINE, donc que la clé primaire de la table MACHINE n’est plus la paire {TM_KEY, L_KEY}, mais bien le triplet {TM_KEY, L_KEY, TM_KEY1}. La structure de la table MACHINE reste la même, mais je souligne la clé primaire pour marquer la différence et je mets en italiques l’attribut appartenant à la clé étrangère :

Structure précédente (pas d’identification relative) :

{TM_KEY, L_KEY, ETQ, DOC, TM_KEY1}

Structure avec identification relative :

{TM_KEY, L_KEY, ETQ, DOC, TM_KEY1}

Force est de reconnaître qu’il y a redondance et que des deux attributs TM_KEY et TM_KEY1 l’un est de trop. On ne peut pas se dispenser de l’attribut TM_KEY1, car on perdrait le lien entre les tables TYPE_MACHINE et MACHINE (autrement dit on supprimerait l’association DECRIRE_MACH dans le MCD !), donc on supprime l’attribut TM_KEY.

Structure (épurée) avec identification relative :

{TM_KEY1, L_KEY, ETQ, DO}

Bien sûr, rien n’empêche de renommer TM_KEY1 en TM_KEY :

{TM_KEY, L_KEY, ETQ, DO}

A-t-on -perdu de l’information ? Non, car l’attribut TM_KEY appartient à la clé primaire {TM_KEY, L_KEY} de la table MACHINE et aussi à la clé étrangère {TM_KEY} garantissant l’intégrité référentielle en relation avec la table TYPE_MACHINE. On garantit le principe dit d’essentialité.

Qu’en est-il de l’entité-type LOCALISATION ?

Ce qui vaut dans les relations entre les tables TYPE_MACHINE et MACHINE vaut évidemment dans les relations entre les tables LOCALISATION et MACHINE, d’où la structure de la table MACHINE :

{TM_KEY, L_KEY, ETQ, DO}

Voilà pour un premier lot de remarques. En espérant que vous aurez bien compris ce que je viens d’écrire, dans mon prochain message je compléterai et reviendrai sur vos états d’âme à propos de l’entité-type PARA.
21/04/2023, 11h21
escartefigue

@alexis_c : pensez à voter pour les réponses qui vous ont aidées (pouce vert en bas à droite).
Fsmrel fait preuve, comme à l'accoutumée, d'un esprit didactique et de précision dans ses réponses, qui méritent des encouragements :ccool:
21/04/2023, 11h38
Malick

Salut à tous,

Je vous suis de loin et vraiment les explications d'escartefigue et fsmrel :hola: sont top. +1 à tous. :king:

:merci:
21/04/2023, 13h21
fsmrel

Bonjour,

alexis_c, je ne vous oublie pas, mais je suis indisponible jusqu’à ce soir.

On est dans le coeur du coeur... J’aurai pas mal de choses à dire, courage et à bientôt quand même !

François
21/04/2023, 16h22
alexis_c

Citation:

Envoyé par Malick et Escartefigue

L'implication de fsmrel

Oui effectivement fsmrel est en train de me donnée un véritable cours particulier, et je le remercie grandement pour le temps qu'il m'accorde et la transmission de connaissance.
(pouce vert en bas à droite) Je vais le trouver...

Citation:

Envoyé par fsmrel

et à bientôt quand même !

Oui bien sur je ne lâche pas l'affaire. Hélas je n'est pas pu travailler sur le sujet ce vendredi.
J'ai juste parcouru votre message. Pour l'instant j'ai quelques doutes sur ma compréhension de certain élément. Il vas falloir que je prenne le temps d'appréhender toute les informations que vous me donné.
Je pense retravaillé sur le sujet lundi.

Un grand merci a vous.
Pouce vert...
24/04/2023, 03h14
fsmrel
Bonjour,

Suite du feuilleton, finalité de l’identification relative.

L’identification relative permet de mieux préciser la nature des relations entre entités-types (classes d’entités).

Avant de traiter de cela, il y a quand même des prérequis à connaître concernant l’identification des entités-types en général. Aussi je reviens sur ce que j’ai écrit dans le post #14 :

Citation:

Envoyé par fsmrel

A chaque entité-type on affecte un attribut particulier (synonymes : rubrique, propriété...), l’identifiant, dont l’objet est de distinguer des jumeaux parfaits.

De façon plus précise, je fais référence à l’excellentissime Yves Tabourier, qui a écrit ceci en 1986 (De l’autre côté de MERISE, page 80), et c’est une règle d’or qui reste hélas ! encore trop souvent méconnue :

« ... la fonction d’une propriété est de décrire les objets (et les rencontres), alors que l’identifiant ne décrit rien. Son rôle fondamental est d’être sûr de distinguer deux jumeaux parfaits, malgré des descriptions identiques.
L’expérience montre d’ailleurs que l’usage des “identifiants significatifs” (ou “codes significatifs”) a pu provoquer des dégâts tellement coûteux que la sagesse est d’éviter avec le plus grand soin de construire des identifiants décrivant les objets ou, pis encore, leurs liens avec d’autres objets... »

Prenons l’exemple des entreprises clientes qui passent des commandes.

Un MCD :

https://www.fsmwarden.com/developpez...mmandes)v1.png
Figure 1

Je ferai observer que l’attribut identifiant NoSiren de l’entité-type Client viole la règle d’or établie par Tabourier. En effet le numéro Siren des entreprises peut changer (c’est effectivement le cas pour 10% d’entre elles). Autrement dit, dans la base de données en production les modifications porteront non seulement sur la clé primaire {NoSIREN} de la table Client, mais aussi sur la clé étrangère {NoSIREN} présente dans la table Commande, ce qui devient peccamineux. Ainsi donc, l’identifiant de l’entité-type Client doit être rendu invariant donc non significatif. En général on sous-traite l’affectation des valeurs de l’identifiant au SGBD. Pour cela, avec Looping on utilise le type COMPTEUR pour l’attribut identifiant, et c’est le SGBD cible qu’on aura choisi qui se chargera du type SQL pertinent (INTEGER dans le cas de SQLite).

La règle d’or vaut pour l’identification de l’ensemble des entités-types, et l’identifiant de l’entité-type Commande n’y échappe pas.

Le MCD évolue ainsi :

https://www.fsmwarden.com/developpez...mmandes)v2.png

Figure 2

Pour que le numéro Siren conserve sa propriété d’unicité, on en fait ce qu’on appelle une clé alternative. Pour cela, avec Looping, pour l’attribut NoSiren, au lieu de cocher la case IDENTIFIANT, on coche les cases NOT NULL et UNIQUE. Même principe pour l’attribut CommandeNo. On en profite pour en faire autant avec l’attribut ClientAdresseCourriel.
https://www.fsmwarden.com/developpez...mandes_ak).png

Code SQL de création des tables (SQL Server) :
```
CREATE TABLE Client
(
   ClientId INT IDENTITY,
   NoSiren CHAR(9) NOT NULL,
   ClientNom VARCHAR(50) NOT NULL,
   ClientAdresse VARCHAR(50) NOT NULL,
   ClientAdresseCourriel VARCHAR(50) NOT NULL,
   CONSTRAINT Client_PK PRIMARY KEY(ClientId),
   CONSTRAINT Client_AK UNIQUE(NoSiren)
);

CREATE TABLE Commande
(
   CommandeId INT IDENTITY,
   CommandeNo VARCHAR(24) NOT NULL,
   CommandeDate DATE NOT NULL,
   ClientId INT NOT NULL,
   CONSTRAINT Commande_PK PRIMARY KEY(CommandeId),
   CONSTRAINT Commande_AK UNIQUE(CommandeNo),
   CONSTRAINT Commande_Client_FK FOREIGN KEY(ClientId) 
       REFERENCES Client(ClientId)
); 
```
Quelques lignes :
```
INSERT INTO Client VALUES
   ('987654321', 'Naudin', '1, rue en pente - Montauban', 'naudin@naudin.com')
 , ('314159265', 'pi et cie.', '3, rue Fermat - Castres', 'pi@archimede.com')
 , ('271828182', 'e et cie.', '3, rue Fermat - Castres', 'e@neper.com')
;

SELECT * FROM Client ;
```
Au résultat :
```
ClientId    NoSiren    ClientNom    ClientAdresse             ClientAdresseCourriel
1           987654321  Naudin       1, rue en pente - Montauban   naudin@naudin.com
2           314159265  pi et cie.   3, rue Fermat - Castre       pi@archimede.com
3           271828182  e et cie.    3, rue Fermat - Castre       e@neper.com 
```
```
INSERT INTO Commande VALUES
   ('12345', '2023-04-22', 1)
 , ('12365', '2023-04-22', 1)
 , ('22360', '2023-04-22', 2)
;
SELECT * FROM Commande ;
```
Au résultat :
```
CommandeId    CommandeNo    CommandeDate    ClientId
1             12345         2023-04-22      1
2             12365         2023-04-22      1
3             22360         2023-04-22      2 
```
Ainsi, pour retrouver les commandes de l’entreprise cliente dont le numéro Siren est égal à '987654321' :
```
SELECT NoSiren, ClientNom, CommandeNo, CommandeDate 
FROM  Client JOIN Commande ON Client.ClientId = Commande.ClientId
WHERE NoSiren = '314159265' ;
```
Au résultat :
```
NoSiren      ClientNom     CommandeNo    CommandeDate
987654321    Naudin        12345         2023-04-22
987654321    Naudin        12365         2023-04-22 
```
---------------------------------------

Passons enfin à l’identification relative.

Pour cela, intéressons-nous aux lignes de commande.

Une commande est composée de lignes de commandes et une ligne de commande est un élément d’une seule commande. La ligne fait aussi de faire référence à un produit. Le MCD ci-dessous permet de bien visualiser les choses.

https://www.fsmwarden.com/developpez...es_lignes).png

   Figure 3

Examinons la situation d’un point de vue existentiel, ontologique et métabolique. Je m’explique. Supposons que l’on veuille supprimer un produit : si jamais il existe au moins une ligne de commande y faisant référence, la demande suppression du produit doit être refusée, la ligne de commande n’est pas la propriété d’un produit. Par contre, une ligne de commande est viscéralement un élément d’une commande.
On dit qu’une ligne de commande est une entité faible (weak entity). Autrement dit, les lignes d’une commande ne peuvent pas s’opposer à la destruction de la commande. Les lignes de commande sont l’objet d’une propriété multivaluée de la commande, ce qui conceptuellement peut se représenter ainsi :

https://www.fsmwarden.com/developpez...ignes_rva).png
               Figure 4

Dans le cadre de la théorie relationnelle, l’attribut CommandeLignes est un attribut multivalué (RVA). Toutefois ceci n’a pas été prévu dans le contexte E/R (merisien). En tout cas cela montre bien que la ligne de commande n’a pas d’existence propre, elle n’a aucune autonomie.

On peut quand même exprimer symboliquement la chose au moyen de l’identification relative, représentée avec le mickey « 1,1(R) » dans le MCD, faisant que dans le MLD et le code SQL, la clé étrangère fait aussi partie de la clé primaire de la table LigneCommande.

https://www.fsmwarden.com/developpez...nes_idrel).png

   Figure 5

Code SQL :
```
CREATE TABLE Client
(
   ClientId INT IDENTITY,
   NoSiren CHAR(9) NOT NULL,
   ClientNom VARCHAR(50) NOT NULL,
   ClientAdresse VARCHAR(50) NOT NULL,
   ClientAdresseCourriel VARCHAR(50) NOT NULL,
   CONSTRAINT Client_PK PRIMARY KEY(ClientId),
   CONSTRAINT Client_AK UNIQUE(NoSiren),
   CONSTRAINT Client_1_AK UNIQUE(ClientAdresseCourriel)
);

CREATE TABLE Commande
(
   CommandeId INT,
   CommandeNo VARCHAR(24) NOT NULL,
   CommandeDate DATE NOT NULL,
   ClientId INT NOT NULL,
   CONSTRAINT Commande_PK PRIMARY KEY(CommandeId),
   CONSTRAINT Commande_AK UNIQUE(CommandeNo),
   CONSTRAINT Commande_Client_FK FOREIGN KEY(ClientId) 
       REFERENCES Client(ClientId)
);

CREATE TABLE Article
(
   ArticleId INT IDENTITY,
   ArticleReference VARCHAR(12) NOT NULL,
   ArticleNom VARCHAR(50) NOT NULL,
   PrixHT DECIMAL(5,2) NOT NULL,
   CONSTRAINT Article_PK PRIMARY KEY(ArticleId),
   CONSTRAINT Article_AK UNIQUE(ArticleReference)
);

CREATE TABLE LigneCommande
(
   CommandeId INT,
   LigneId INT IDENTITY,
   Quantite INT NOT NULL,
   ArticleId INT NOT NULL,
   CONSTRAINT LigneCommande_PK PRIMARY KEY(CommandeId, LigneId),
   CONSTRAINT LigneCommande_Commande_FK FOREIGN KEY(CommandeId) 
       REFERENCES Commande(CommandeId) ON DELETE CASCADE,
   CONSTRAINT LigneCommande_Article_FK FOREIGN KEY(ArticleId) 
       REFERENCES Article(ArticleId)
) ;
```
Comment valoriser l’attribut LigneId de la table LigneCommande ?

Si on est un peu feignant, comme dans le cas de l’entité-type Commande, on peut sous-traiter au SGBD la valorisation de l’attribut LigneId (élément de la clé primaire en SQL). Je rappelle qu’avec Looping, il faut choisir le type COMPTEUR. D’accord, LigneId ne contiendra jamais de doublons et pourrait faire l’objet d’une clé alternative, mais tout ça c’es sous le capot et on se gardera bien de toucher à quoi que soit.

Pour compléter le code SQL (toujours avec SQL Server) :
```
INSERT INTO Article VALUES
   ('ref001', 'gaufrettes Tartempion', 100.50)
 , ('ref002', 'chocolat Truc', 120)
;
```
Au résultat :
```
ArticleId    ArticleReference    ArticleNom              PrixHT
1            ref001             gaufrettes Tartempion    100.50
2            ref002             chocolat Truc            120.00 
```
Quelques lignes de commande :
```
INSERT INTO LigneCommande VALUES
   (1, 1, 25)
 , (1, 2, 40) 
 , (2, 2, 30)
;
```
Au résultat :
```
CommandeId    LigneId    ArticleId    Quantite
1             1          1            25
1             2          2            40
2             3          2            30 
```
Si le SGBD ne veut pas fournir lui-même les valeurs pour l’attribut LigneId (cas de SQLite ?), on le fera à la main. Exemple :
```
INSERT INTO LigneCommande VALUES
   (1, 1, 1, 25)
 , (1, 2, 2, 40) 
 , (2, 1, 2, 30)
;
```
Remarque :

Comme je l’ai précisé ci-dessus, alors que la demande de suppression d’un produit doit être refusée, les lignes d’une commande ne peuvent pas s’opposer à la destruction de la commande, laquelle les entraîne dans leur destruction. A cet effet, la contrainte LigneCommande_Commande_FK (cf. l’instruction CREATE TABLE LigneCommande) comporte la clause « ON DELETE CASCADE ».

La suite au prochain numéro. ;)
24/04/2023, 03h45
fsmrel
Pour en revenir à votre MCD :

https://www.fsmwarden.com//developpe...c(idrel)v2.png

L’entité-type MACHINE est-elle une entité-type faible par rapport à l’entité-type TYPE MACHINE ?

Si oui, la suppression d’un type de machine doit entraîner la suppression des machines qui s’y rattachent (cf. l’exemple des lignes de commande).
Si non, l’entité-type MACHINE est « forte » et elle n’a pas besoin que l’attribut TM_KEY participe à son identification.

Il en va de même dans la relation qu’entretiennent les entités-types LOCALISATION et MACHINE.

Autrement dit, le MCD doit devenir le suivant :
https://www.fsmwarden.com//developpe...d_machine).png

MCD dans lequel l’attribut M_KEY est l’identifiant de MACHINE.

CODE SQL :
```
CREATE TABLE TYPE_MACHINE
(
   TM_KEY INT,
   ETQ VARCHAR(12) NOT NULL,
   DOC VARCHAR(50) NOT NULL,
   CONSTRAINT TYPE_MACHINE_PK PRIMARY KEY(TM_KEY),
   CONSTRAINT TYPE_MACHINE_AK UNIQUE(ETQ)
) ;

CREATE TABLE LOCALISATION
(
   L_KEY INT,
   ETQ VARCHAR(12) NOT NULL,
   DOC VARCHAR(50) NOT NULL,
   CONSTRAINT LOCALISATION_PK PRIMARY KEY(L_KEY),
   CONSTRAINT LOCALISATION_AK UNIQUE(ETQ)
) ;

CREATE TABLE MACHINE
(
   M_KEY INT,
   ETQ VARCHAR(12) NOT NULL,
   DOC VARCHAR(50) NOT NULL,
   TM_KEY INT NOT NULL,
   L_KEY INT NOT NULL,
   CONSTRAINT MACHINE_PK PRIMARY 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)
) ;
```
La table MACHINE est dotée des colonnes TM_KEY et L_KEY, faisant respectivement l’objet de clés étrangères en relation avec les tables TYPE_MACHINE et LOCALISATION.

Vous noterez que dans sa grande bonté, Looping a créé la contrainte MACHINE_AK (clé alternative {L_KEY}) pour la table MACHINE, conséquence de la cardinalité 0,1 portée par la patte d’association connectant LOCALISATION et SITUER, imposant qu'une localisation ne puisse héberger qu’une seule machine.

Où vous situez-vous désormais ? Paracétamol à portée de main ? :koi:

Voir 40 message(s) de cette discussion en une page