Discussion :

[vraifredo]

Bonjour,

Je suis actuellement en formation à distance où je dois réaliser plusieurs projets professionnalisants et je rencontre une difficulté sur une modélisation merise (MCD).

Le projet en cours consiste à réaliser un site web pour une chaîne de barbiers implantée dans plusieurs villes où j'interviens en tant que chef de projet.
Je dois contrôler et faire des recommandations sur les premières productions des équipes.

Mon problème concerne les recommandations sur la base de donnée sur la gestion des rendez-vous.

Contexte :
- plusieurs salons ;
- les salons proposent des prestations(coupe homme, femme, soins barbes, ...), pas forcément identiques (certains proposent des tatouages par exemple).

La base de données fournie par le développeur ne comprend qu'une table "client" avec tout dedans. Il est clair que cela ne va pas, et identifier les problèmes ... n'est pas un problème.
Il n'est pas imposé d'utiliser merise, mais je trouve que c'est la meilleur solution pour expliquer/justifier les recommandations.

J'utilise Looping pour se faire. Très pratique et en plus me permet de fournir DC UML, MLD et script de création de tables pour aider le développeur.

Après moult lectures, j'ai réussi à réaliser le modèle suivant, qui me semble bien correspondre à ce qu'il faut mais je bloque sur comment modéliser le fait que l'on ne peut prendre rendez-vous pour une prestation QUE si le salon la propose. Contrainte ? CIF ? Règle ?






Question subsidiaire : Le DC UML affiche des "?" dans les relations, comment l'expliquer ?



Merci d'avance pour votre aide

[escartefigue]

Bonjour,

Vous avez choisi Looping pour modéliser, excellent choix

Par contre, tel que vous avez modélisé votre association, un rendez vous ne peut concerner qu'une seule prestation.

Pour votre besoin il faut utiliser une contrainte d'inclusion.
Le script correspondant à la contrainte doit être saisi avec l'outil règle.
Voici un exemple :

Pièce jointe 593261

Si le tarif de la prestation dépend du salon, il faut déplacer l'attribut dans l'association SR_proposer

voici le script correspondant (généré ici pour SQL server) :

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
CREATE TABLE SA_salon(
   SA_ident INT IDENTITY,
   SA_enseigne VARCHAR(128) NOT NULL,
   SA_SIREN CHAR(9) NOT NULL,
   SA_NIC CHAR(5) NOT NULL,
   PRIMARY KEY(SA_ident)
);
 
CREATE TABLE PR_prestation(
   PR_ident INT IDENTITY,
   PR_code CHAR(4) NOT NULL,
   PR_libelle VARCHAR(128) NOT NULL,
   PR_tarif DECIMAL(5,2) NOT NULL,
   PRIMARY KEY(PR_ident),
   UNIQUE(PR_code)
);
 
CREATE TABLE CL_client(
   CL_ident INT IDENTITY,
   CL_nom VARCHAR(50) NOT NULL,
   CL_prenom VARCHAR(50) NOT NULL,
   CL_ddn DATE NOT NULL,
   PRIMARY KEY(CL_ident)
);
 
CREATE TABLE RV_rendez_vous(
   SA_ident INT,
   RV_ident INT IDENTITY,
   RV_dtenr DATE NOT NULL, --date d'enregistrement du rendez-vous
   RV_dtprest VARCHAR(50), --date de la prestation
   CL_ident INT NOT NULL,
   PRIMARY KEY(SA_ident, RV_ident),
   FOREIGN KEY(SA_ident) REFERENCES SA_salon(SA_ident),
   FOREIGN KEY(CL_ident) REFERENCES CL_client(CL_ident)
);
 
CREATE TABLE SR_proposer(
   SA_ident INT,
   PR_ident INT,
   PRIMARY KEY(SA_ident, PR_ident),
   FOREIGN KEY(SA_ident) REFERENCES SA_salon(SA_ident),
   FOREIGN KEY(PR_ident) REFERENCES PR_prestation(PR_ident)
);
 
CREATE TABLE RP_concerner(
   PR_ident INT,
   SA_ident INT,
   RV_ident INT,
   PRIMARY KEY(PR_ident, SA_ident, RV_ident),
   FOREIGN KEY(PR_ident) REFERENCES PR_prestation(PR_ident),
   FOREIGN KEY(SA_ident, RV_ident) REFERENCES RV_rendez_vous(SA_ident, RV_ident)
);
 
alter table RP_concerner
add constraint RP_CIF1
foreign key (SA_ident, PR_ident) 
references SR_proposer(SA_ident, PR_ident);

[escartefigue]

Et voici un petit script de création d'un jeu d'essais.
Dans la dernière requête insert, si j'essaye de violer la contrainte d'inclusion, le SGBD pousse des hauts cris et refuse la transaction
(cf. ligne en commentaire dans l'insert de RP_concerner en bas du script)

Il y a des rendez-vous sans prestation (à compléter donc

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
 
insert into SA_salon
      (SA_enseigne, SA_SIREN, SA_NIC) 
values ('on rase gratis ', '123456789', '00001')
     , ('la boule à zéro', '987654321', '00001')
     , ('partis tifs    ', '999999999', '00002')
;
insert into PR_prestation
    (PR_code, PR_libelle, PR_tarif)
values ('C001', 'coupe aux ciseaux', 12.50)
     , ('C002', 'coupe tondeuse   ', 11.00)
     , ('P001', 'permanente std   ', 38.20)
     , ('SH00', 'shampoing std    ', 04.00)
     , ('SH01', 'shampoing spécial', 05.00)
;
insert into CL_client (CL_nom, CL_prenom, CL_ddn)
values ('Martin', 'Hélène', '2005-04-20')
     , ('Dupuis', 'Benoit', '1984-12-21')
     , ('Lesage', 'Mireille', '1982-07-16')
;
insert into RV_rendez_vous (SA_ident, RV_dtenr, RV_dtprest, CL_ident)
values (1, '2021-02-16', '2021-03-09', 3)
     , (1, '2021-02-17', '2021-03-14', 1)
     , (2, '2021-02-17', '2021-03-23', 2)
     , (3, '2021-02-11', '2021-02-27', 1)
;
insert into SR_proposer(SA_ident, PR_ident)
values (1, 1)
     , (1, 2)
     , (1, 3)
     , (1, 4)
     , (1, 5)
     , (2, 1)
     , (2, 2)
     , (2, 4)
     , (2, 5)
     , (3, 3)
     , (3, 4)
     , (3, 5)
;
insert into RP_concerner (PR_ident, SA_ident, RV_ident)
values (1, 1, 1)
     , (5, 1, 1)
     , (4, 1, 2)
     , (3, 1, 2)
     , (2, 2, 3)
--     , (3, 2, 4)  -- KO : CIF d'inclusion
;

Et une requête pour visualiser les rendez-vous et les prestations demandées par les client(e)s :

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
select SA.SA_ident
     , SA.SA_enseigne
     , RV.RV_ident
     , RV.RV_dtprest
     , CL.CL_nom
     , CL.CL_prenom
     , PR.PR_code
     , PR.PR_libelle
from RV_rendez_vous RV
inner join SA_salon SA
   on SA.SA_ident=RV.SA_ident
inner join CL_client CL
   on CL.CL_ident=RV.CL_ident
inner join RP_concerner RP
   on RP.RV_ident=RV.RV_ident
inner join PR_prestation PR
   on PR.PR_ident=RP.PR_ident
order by SA.SA_ident
       , RV.RV_ident
;

Ce qui donne :

SA_ident	SA_enseigne	RV_ident	RV_dtprest	CL_nom	CL_prenom	PR_code	PR_libelle
1	on rase gratis	1	2021-03-09	Lesage	Mireille	C001	coupe aux ciseaux
1	on rase gratis	1	2021-03-09	Lesage	Mireille	SH01	shampoing spécial
1	on rase gratis	2	2021-03-14	Martin	Hélène	P001	permanente std
1	on rase gratis	2	2021-03-14	Martin	Hélène	SH00	shampoing std
2	la boule à zéro	3	2021-03-23	Dupuis	Benoit	C002	coupe tondeuse

[vraifredo]

Super, merci bien pour cette réponse on ne peut plus complète. J'ai pris le temps de la digérer car cela fait de nombreuses années que j'avais cessé mon activité (j'ai d'ailleurs modifié mon profil du coup).

Il m'est demandé de ne pas aller trop trop loin dans mes livrables, c'est un "sprint" et l'équipe est "charrette". J'en fait déjà un peu plus qu'exigé mais cela me parait être un minimum.

Je me pose une question sur l'exemple : Quel est l'intérêt d'avoir un identifiant ET un code pour la prestation, n'est-ce pas redondant ?

La base de données utilisée est MySQL, d'après mes recherches cela fonctionne comme Sql_server pour "Add constraint de la Foreign Key". Si j'ai bien compris cet ajout fait un contrôle d'intégrité par sécurité, mais c'est l'applicatif qui doit gérer le bon affichage des choix possibles en fonction du salon et ne pas provoquer d'erreur de validation ... normalement.

Je viens de tester sur mon association "Prendre rendez-vous", cela fonctionne bien.



Je ne suis pas sûr que ce soit dans les règles de l'art sur une association ne donnant pas suite à une table.
J'améliorerai si vous estimez préférable de passer par une association "concerne" entre les entités "rendez-vous" et "Prestation". Le soucis n'est pas de pouvoir avoir plusieurs prestations, cela ce résout facilement (avec des forfaits coupe+shampoing, ...) pour mon sujet.

C'est tout pour ce soir, je verrai demain.

Encore merci pour cet exemple et les éléments fournis

[Paprick]

Bonsoir,

Votre quadri-pattes est un peu embarrassante, d'autant plus qu'elle comporte une patte 1,1...
Concrètement, dans ce cas-là, le MCD correspondant pourrait être celui-ci (qui donnera un DC UML correct et un MLD équivalent au vôtre) :

La question est : vu sous cet angle, cela correspond-il à votre système d'information ?

[escartefigue]

@Paprick

Ce modèle lui aussi ne propose qu'une prestation par rendez-vous, est-ce réaliste ?
Si une même personne veut une coupe de cheveux et une taille de barbe, faut il considérer qu'il s'agit de deux rendez-vous distincts ?
À confirmer par vraifredo
Ma proposition consistait en un seul rendez-vous dans ce cas.

[escartefigue]

Bonjour Vraifredo

Il m'est demandé de ne pas aller trop trop loin dans mes livrables, c'est un "sprint" et l'équipe est "charrette". J'en fait déjà un peu plus qu'exigé mais cela me parait être un minimum.

Attention, même en période "charrette" il ne faut surtout pas sacrifier le modèle de données, car s'il est bancal, les développements seront peu performants, peu fiables et le plus souvent, il faudra recommencer la modélisation (et du coup mettre à la poubelle les développements déjà réalisés)

Je me pose une question sur l'exemple : quel est l'intérêt d'avoir un identifiant ET un code pour la prestation, n'est-ce pas redondant ?

L'identifiant primaire est un attribut ayant pour rôle de déterminer de façon certaine une occurrence unique d'un type d'entité (et donc de la table résultante).
De ce point de vue, le code est tout à fait légitime.
Mais, l'identifiant primaire a ceci de particulier qu'il se propage dans les tables issues d'autres types d'entité ou d'association pour garantir l'intégrité des données de la base (les fameuses "foreign keys" avec contrainte "reference").
C'est la raison pour laquelle l'identifiant primaire doit être stable : si sa valeur devait être modifiée pour une raison quelconque, alors une cascade de mises à jour dues aux contraintes d'intégrité serait déclenchée. Cette cascade peut concerner des millions de lignes (vécu dans un contexte bancaire lors de fusions bancaires où le code banque avait été choisi comme PK )
C'est pourquoi il est fortement recommandé de choisir un identifiant primaire technique, attribué par le SGBD et dépourvu de sens, c'est ce qui garantit sa stabilité.
Un code lui peut changer, quelques exemples :

• le code département "20" pour la corse devenu "2A et 2B" dans les années 80 ;
• les nombreux codes pays qui ont changé soit parce que le pays a changé de nom (ex : Haute Volta devenue Burkina Faso) soit parce que le pays a été divisé (Yougoslavie, Tchecoslovaquie...)
• les communes qui changent de code INSEE à l'occasion de fusions (il s'en produit presque à chaque élection municipale)

Ici j'ai proposé un code à titre didactique, il n'est pas forcément utile.

La base de données utilisée est MySQL, d'après mes recherches cela fonctionne comme Sql_server pour "Add constraint de la Foreign Key".

Oui sous réserve de bien choisir le moteur INNODB, car le moteur MYISAM accepte les contraintes dans le script, mais ne les utilise pas

Si j'ai bien compris cet ajout fait un contrôle d'intégrité par sécurité, mais c'est l'applicatif qui doit gérer le bon affichage des choix possibles en fonction du salon et ne pas provoquer d'erreur de validation ... normalement.

Jamais une application aussi rigoureuse soit-elle ne peut garantir l'intégrité des données dans la base. Pour une raison simple : elle ne sait pas qui d'autre, à un instant "t" utilise les données dans la base. Seul le moteur du SGBD est conçu pour gérer les accès concurrents, c'est même l'une de ses principales fonctions. De plus, même dans un contexte mono-utilisateur, il arrive que le moteur du SGBD choisisse d'utiliser plusieurs connexions en parallèle pour optimiser les requêtes.

Bonjour,

j'ai trouvé tout seul, comme un grand, que l'ordre des attributs dépendait de l'ordre dans laquelle on créait les associations

En effet ! Mais bientôt, la version 3.1 qui se prépare permettra de choisir l'ordre des attributs pour les clés composées .

Ca c'est top

[vraifredo]

Bonjour,

Merci pour ce complément. Clair, net et précis.

J'ai bien saisi le pourquoi de l'utilisation d'un identifiant unique technique et comment justifier son utilisation suivant le cas.

J'avais bien relevé la nécessité du moteur INNODB et, bien qu'il soit par défaut, prévu d'y prêter attention dans les recommandations.

Effectivement, en cas de loupé, la contrainte d'intégrité va garantir de ne pas insérer d'incohérences dans la base de données. Quand bien même l'applicatif fait son boulot, la contrainte est nécessaire et doit tout de même être implémentée.

Pour la qualité du modèle, je vous rejoins à 100%. Je vais apporter quelques précisions supplémentaires sur le contexte :

• Je ne suis pas sensé apporter une expertise, la compétence à valider pour ce point est "participer à la modélisation d'une base de données" ;
• Pour la soutenance de mes livrables de ce projet (dont celui-ci sur la base de données), l'évaluateur a le rôle d'un collègue expérimenté qui est consulté pour avis.

Je joue ce jeu "d'imperfection" volontairement (même si cela me fait un peu mal). Loin de moi l'idée de passer outre les conseils et estimer que mon modèle est très bien comme cela.
Ce qui fait que lors de la soutenance le "collègue expérimenté" donnera son avis sur les points à améliorer/corriger, on échange sur ces points et j'en prendrai note.
Par exemple la table "Rendezvous" sera débattu. Il me paraît évident que mettre les prestations associées à part est ce qu'il convient de faire, même si cela fait gérer une table en plus ... On pourrait faire un comparatif avec la gestion des commandes avec les tables "commande" et "ligne de commande" par exemple, on ne fait pas 1 seule table avec toutes les lignes de commandes dedans.

En fait, je me rend compte que ce fil ressemble un peu à ce que devrait être la soutenance

Par contre, le mentor qui me suis m'indiquera : si j'en fait trop, pas assez si tu le fais évites ces erreurs ou c'est bien il y a des erreurs mais tu n'es pas expert et tu t'investis... J'ajusterai alors mon livrable (donc le modèle) en conséquence.

Sachant qu'il y a aussi d'autres points qui ne vont pas et qui font parti de ce livrable. Mais comme ce n'est pas le sujet de la modélisation je ne m'étale pas dessus.

Encore un grand merci à vous deux pour votre investissement qui m'a été d'une aide précieuse .

Une dédicace particulière à Paprick pour son outil Looping que je trouve redoutable de simplicité et d'efficacité Vivement la 3.1

Cordialement