Discussion :

[laurentSc]

Bonjour,

même si je travaille sur le MCD longuement abordé dans https://www.developpez.net/forums/d2.../#post11737173, je crée une nouvelle discussion car je pense qu'on peut isoler cette question du reste de la discussion.

Dans mon application, il y a 2 tables : celle des tickets (signalement d'un problème sur une application)(TI_ticket) et celle des licences sur ces applications (LI_license). Les 2 concernent donc des applications (nommées product pour les tickets). Mais comme l'orthographe utilisée pour les 2 est différentes, j'ai prévu de créer 2 tables (AP_application et PR_product). Pour pouvoir associer les 2, j'ai prévu une table de correspondance matching_license_ticket. J'ai donc relié les 2 tables à l'aide d'une association matching_license_ticket à laquelle je pensais mettre des rubriques afin de pouvoir indiquer les 2 orthographes à faire correspondre ; quand j'ai créé cette association, je suis rentré dedans puis j'ai coché le bouton Générer une table de correspondance dans le MLD. Ça m'a rajouté une table matching_license_ticket à laquelle j'ai mis les 2 rubriques permettant d'exprimer les 2 orthographes.

Voici le MCD :


et le DDL de la table de correspondance :

Code sql :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
CREATE TABLE matching_license_ticket(
   PR_ident INT UNSIGNED,
   appli_name VARCHAR(50),
   product_name VARCHAR(50),
   PL_ident INT UNSIGNED NOT NULL,
   AP_ident INT UNSIGNED NOT NULL,
   PRIMARY KEY(PR_ident),
   UNIQUE(PL_ident, AP_ident),
   UNIQUE(appli_name),
   UNIQUE(product_name),
   FOREIGN KEY(PR_ident) REFERENCES PR_product(PR_ident),
   FOREIGN KEY(PL_ident, AP_ident) REFERENCES AP_application(PL_ident, AP_ident)
);

Cela est-il correct ?

[escartefigue]

Bonjour Laurent

Attention à ne pas confondre la modèle conceptuel et le modèle logique

Dans le MCD, il n'y a pas de tables, on y modélise les acteurs ou individus ou objets de gestion (les types d'entité représentés par des rectangles) et leurs interactions (les associations modélisées par les ovales).
Les attributs sont associés aux types d'entités, parfois aux associations, mais un même attribut n'est présent qu'une seule fois.
Or, dans votre modèle, l'entité-type "matching license ticket" reprend des attributs, les noms, de AP_application et de PR_product.
Il y a donc la un mélange de MCD et de MLD, "matching license ticket" n'est pas un type d'entité mais une association.

De plus, avec ce modèle, je peux associer un ticket à une licence L1, qui concerne l'application A1
Lier ce même ticket à un produit P1
Et associer l'application A1 à un produit P2 ou à aucun produit
Donc selon qu'on passe du ticket au produit par le chemin court en bas du schéma ou le plus long en haut, on trouve un produit différent...

La preuve par l'exemple :

MCD réduit, dans lequel j'ai supprimé la pseudo entité-type et ajouté l'association AP_PR pour laquelle j'ai coché la case "générer une table de correspondance"

Pièce jointe 600253


Je crée mes tables :

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
CREATE TABLE AP_appli(
   AP_ident INT AUTO_INCREMENT,
   AP_nom VARCHAR(50) NOT NULL,
   PRIMARY KEY(AP_ident),
   UNIQUE(AP_nom)
);
 
CREATE TABLE PR_product(
   PR_ident INT AUTO_INCREMENT,
   PR_nom VARCHAR(50) NOT NULL,
   PRIMARY KEY(PR_ident)
);
 
CREATE TABLE LI_license(
   LI_ident INT AUTO_INCREMENT,
   AP_ident INT NOT NULL,
   PRIMARY KEY(LI_ident),
   FOREIGN KEY(AP_ident) REFERENCES AP_appli(AP_ident)
);
 
CREATE TABLE TI_ticket(
   TI_ident INT AUTO_INCREMENT,
   TI_date DATE,
   PR_ident INT NOT NULL,
   LI_ident INT NOT NULL,
   PRIMARY KEY(TI_ident),
   FOREIGN KEY(PR_ident) REFERENCES PR_product(PR_ident),
   FOREIGN KEY(LI_ident) REFERENCES LI_license(LI_ident)
);
 
CREATE TABLE AP_PR(
   AP_ident INT,
   PR_ident INT NOT NULL,
   PRIMARY KEY(AP_ident),
   UNIQUE(PR_ident),
   FOREIGN KEY(AP_ident) REFERENCES AP_appli(AP_ident),
   FOREIGN KEY(PR_ident) REFERENCES PR_product(PR_ident)
);

J'y insère un petit jeu de données avec 3 applications et 3 produits, j'associe dans la table associative AP_PR l'application A1 au produit P1, A2 à P2 et A3 à P3

Code SQL :

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

1
2
3
4
5
6
7
8
9
10
11
12
insert into AP_appli (AP_nom)
values ('appli 1'), ('appli 2'), ('appli 3')
;
insert into PR_product (PR_nom)
values ('produit 1'), ('produit 2'), ('produit 3')
;
insert into AP_PR (AP_ident, PR_ident)
values (1,1), (2,2), (3,3)
;
insert into LI_license (AP_ident)
values (1), (2), (1), (3), (2)
;

Puis je crée quelques tickets :

Code SQL :

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

1
2
3
4
5
6
insert into TI_ticket(TI_date, PR_ident, LI_ident)
values ('2021-04-15', 1, 1)
     , ('2021-04-18', 1, 2)
     , ('2021-04-18', 2, 1)
     , ('2021-04-23', 3, 1)
;

Et c'est le drame, j'ai associé des tickets à des applications (à travers les licences) et des produits qui sont incohérents .

Requête d'extraction :

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
select TI.TI_ident as num_ticket
     , TI.TI_date  as date_ticket
     , TI.PR_ident as num_produit
     , PR.PR_nom   as produit
     , TI.LI_ident as num_licence
     , LI.AP_ident as num_appli
     , AP.AP_nom   as appli
from TI_ticket TI
inner join PR_product PR
   on PR.PR_ident = TI.PR_ident
inner join LI_license LI
   on LI.LI_ident = TI.LI_ident
inner join AP_appli AP   
   on AP.AP_ident = LI.AP_ident
;

Résultat, selon les tickets, le produit 1 est associé à l'appli 1 ou l'appli 2 et l'appli 1 est associée aux trois produits :

num_ticket	date_ticket	num_produit	produit	num_licence	num_appli	appli
1	2021-04-15	1	produit 1	1	1	appli 1
2	2021-04-18	1	produit 1	2	2	appli 2
3	2021-04-18	2	produit 2	1	1	appli 1
4	2021-04-23	3	produit 3	1	1	appli 1

[laurentSc]

Il y a donc la un mélange de MCD et de MLD, "matching license ticket" n'est pas un type d'entité mais une association.

Donc finalement, c'est mieux comme ça ?

[fsmrel]

Donc finalement, c'est mieux comme ça ?

On a ici une situation analogue à celle des tickets et des licences, évoquée dans l’autre discussion (posts #124 à #129 : soit un ticket fait référence à un produit, soit il fait référence à une application via une licence. En conséquence, la patte d’association connectant l’entité-type TI_ticket et l’association CONCERNS doit être porteuse d’une cardinalité 0,1, même chose pour la patte d’association connectant l’entité-type TI_ticket et l’association CONCERNS_t. Comme expliqué dans le post #129 dont je viens de faire mention, vous pouvez faire « parler » le MCD au moyen d’une contrainte d’exclusion. Au stade SQL la table TI_ticket doit impérativement être porteuse d’une contrainte CHECK garantissant cette contrainte (cf. à nouveau le post #129, instruction CREATE TABLE).

[laurentSc]

Bonsoir,

je reprends dans cette discussion une remarque faite par escartefigue dans une autre discussion, mais ce débat a toute sa place ici.

C'est la conséquence directe de la cardinalité minimale zéro du produit vers l'application

La cardinalité 0,1 se justifie par le fait qu'un produit n'est pas forcément présent dans la liste des applications et si c'est le cas, le produit ne correspond effectivement à aucune application, ce qui valide cette règle de gestion :

R025 : un produit peut correspondre à zéro ou une application

De ce fait, la cardinalité 0,1 est-elle bien justifiée ?