Discussion :

[ZuZu]

Bonjour

Ça fait peut être 20 ans que je n'ai pas fait de schéma alors je me permets de solliciter vos avis sur le schéma suivant, notamment sur les multiples liaisons de l'entité User, je sens que quelque chose ne va pas ...

J'ai fait toutes ces liaisons car :
- un utilisateur peut exécuter une séquence
- il peut exécuter directement une session
- a sa configuration de stimulation propre
- et sans la liaison avec workout (les sessions effectuées) je ne voyais pas comment savoir quel utilisateur avait effectué chaque session

Merci

[escartefigue]

Bonjour Zuzu et bienvenue sur ce forum

Le nombre d'associations pour un type d'entité n'est pas un critère en soi.
Par contre, il faut que chacune de ses associations corresponde à vos règles de gestion. Comme vous n'en avez communiqué aucune, on ne peut pas se prononcer.
Il faudrait aussi quelques explications sur le contexte.

Toutefois, attention à l'intérêt des associations 1,1 de part et d'autre.
Par exemple l'association (Has) entre [User] et [Physiologie] ne se justifie pas : vous pouvez fusionner les deux types d'entité.
D'ailleurs, vous avez utilisé deux fois le même identifiant "user_id".
À vérifier également au sujet de l'association (Stimulate)

Si le contexte est international, ok pour nommer les types d'entité, associations et attributs en anglais, sinon, simplifiez en utilisant le français.
Si l'anglais est maintenu, attention aux noms réservés SQL tels que "user". L'utilisation de noms réservés complique inutilement les requêtes.
L'usage du français limite ce risque mais ne le supprime pas (ex : date)
Pour ma part, j'affecte un préfixe systématique à chaque type d'entité et association (exemple US_user) préfixe que j'utilise également pour chaque attribut de ce type d'entité ou de cette association. Ainsi, plus de risque de percussion avec un mot réservé
Vous pouvez trouver la liste des noms réservés ici : https://sqlpro.developpez.com/cours/motsreserves/

Quel est votre logiciel de modélisation ?
Il en existe un gratuit, simple d'utilisation et performant, Looping, que vous pouvez télécharger ici : https://www.looping-mcd.fr/
Looping permet de créer le MCD et d'en dériver en un clic le MLD et le script en fonction du SGBD que vous avez choisi .

[Paprick]

Bonjour,

Effectivement, je rejoins escartefigue sur la difficulté d'analyser votre MCD sans connaître le contexte précis de votre système d'information...

Sur un plan purement syntaxique, je suis également surpris que votre logiciel de modélisation vous laisse réaliser des associations avec des cardinalités 1,1 de part et d'autre : si vous êtes sûr de ces cardinalités, alors vous pouvez être sûr qu'il s'agit de la même classe d'entités, comme vous le signale escartefigue.
Par ailleurs, vos associations "Contain" et "Stimulate" possèdent des rubriques alors que leurs cardinalités sont 1,1 / 0,N : là encore, votre logiciel aurait dû vous alerter... en effet, si ces cardinalités sont correctes, aucune table d'association ne sera générée dans le MLD, et les rubriques devraient plutôt se trouver dans la classe d'entités côté patte 1,1.

Voilà pour ces premières remarques... d'autres pourront suivre si nous avons plus de détails sur votre SI.

Bonne continuation !

[ZuZu]

Bonjour escartefigue et Paprick et merci pour vos réponses

J'utilise AnalyseSI, pas terrible... J'avais vu looping et je ne sais plus pourquoi je ne l'ai pas utilisé, je vais y réfléchir car je passe par MySQL Workbench pour faire le MPD (d'après un sql généré par AnalyseSI ... )

L'anglais est effectivement pour le développeur.

Concernant les règles de nommage j'ai utilisé ces mots simples dans le mcd pour le présenter à des néophytes mais je renomme pour le mpd avec les vieilles règles de SqlPro justement que j'avais encore en tête.

Pour l'association 1-1 Has c'était pour alléger la table User et différencier les propriétés de chaque utilisateur et ses critères physiques propres au sport. J'avais commencé par faire deux entités, puis j'avais re fusionné, puis j'ai re ... séparé Je me suis finalement dit que c'était mieux de séparer pour limiter le nombre de colonnes... Quelle est la bonne pratique du coup, fusionner si ça n'a pas d'autre intérêt que limiter les colonnes d'une table ?

J'utilise parfois le même identifiant entre différentes entités pour la même donnée, ce n'est pas correct ? Voir le sql ci-dessous

Compris pour les rubriques d'association "Contain" et "Stimulate", c'est corrigé.

Je m'excuse mais qu'est-ce que vous entendez par règles de gestion ?

Voilà plus d'infos sur le projet en espérant que ça réponde à vos attentes.
Il s'agit d'une application mobile sur tablette Android (SQLite) permettant de contrôler des vélos et des rameurs stationnaires (les "ergomètres") avec électro stimulation, à destination de coachs sportifs.

Une session consiste en un entraînement simple (1 étape 30min de pédalage) ou composé de plusieurs étapes (échauffement, travail force, récupération, force, etc...)

Pour chaque étape sont définis les muscles stimulés et les paramètres associés. J'ai une question à ce propos, j'ai ajouté l'information "active" dans l'entité "stimulation" qui paraît en soi inutile car si un muscle n'est pas simulé il n'apparaît pas dans cette entité. L'intérêt est uniquement de conserver les paramètres associés à ce muscle dans le cas où on le désactive temporairement pour permettre de le réactiver sans avoir à ressaisir ses paramètres de stimulation. Est-ce que ça a du sens de le modéliser comme ça ?

Les zones de Coggan servent d'indications à l'utilisateur pour lui demander de fournir un certain effort dans une plage de puissance en fonction de sa puissance maximale "ftp" préalablement renseignée dans son profil (Zone 2 définie pour tel palier donc travailler entre 55% et 75% de puissance, l'utilisateur avec une ftp de 150W verra un message lui indiquant de travailler entre 82W et 112W).
Ces zones de Coggan n'ont d'intérêt qu'en vélo, c'est donc au niveau logiciel qu'il ne sera pas proposé de les définir pour les autres types d'ergomètres. Est ce correct ou y a-t-il une manière de le modéliser ?


Les séquences sont des programmes thématiques à effectuer typiquement sur 3 semaines composées de différentes sessions de travail, elles mêmes inclues dans un programme globale à plus long terme.


J'espère que je ne vous ai pas noyé toutes ces informations

Code :

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
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
DROP TABLE IF EXISTS T_USER_USR ;
CREATE TABLE T_USER_USR (USR_ID INT AUTO_INCREMENT NOT NULL,
GNR_ID INT NOT NULL,
USR_NAME VARCHAR(36)  NOT NULL,
USR_SURNAME VARCHAR(32),
USR_EMAIL VARCHAR(64),
USR_PWD VARCHAR(40),
PRIMARY KEY (USR_ID)) ENGINE=InnoDB;

DROP TABLE IF EXISTS T_PHYSIOLOGY_PHY ;
CREATE TABLE T_PHYSIOLOGY_PHY (USR_ID INT NOT NULL,
PHY_BIRTH_YEAR SMALLINT,
PHY_VO2MAX SMALLINT,
PHY_FTP SMALLINT,
PHY_AMP SMALLINT,
PHY_MAX_HR SMALLINT,
PRIMARY KEY (USR_ID)) ENGINE=InnoDB;

DROP TABLE IF EXISTS T_WORKOUT_WO ;
CREATE TABLE T_WORKOUT_WO (WO_ID INT AUTO_INCREMENT NOT NULL,
SES_ID INT NOT NULL,
USR_ID INT NOT NULL,
WO_DATETIME DATETIME NOT NULL,	-- DEFAULT GETDATE(),
WO_DURATION TIME,
WO_DISTANCE INT,
WO_SPEED_AVG SMALLINT,
WO_FORCE_AVG SMALLINT,
WO_FORCE_PEAK SMALLINT,
PRIMARY KEY (WO_ID)) ENGINE=InnoDB;

DROP TABLE IF EXISTS T_MEASURE_MES ;
CREATE TABLE T_MEASURE_MES (MES_ID INT AUTO_INCREMENT NOT NULL,
WO_ID INT NOT NULL,
MES_TIME TIME NOT NULL,
MES_SPEED SMALLINT NOT NULL,
MES_INTENSITY_PERCENT TINYINT,
MES_FORCE SMALLINT,
MES_HEART_RATE SMALLINT,
PRIMARY KEY (MES_ID)) ENGINE=InnoDB;

DROP TABLE IF EXISTS T_STEP_STP ;
CREATE TABLE T_STEP_STP (STP_ID INT AUTO_INCREMENT NOT NULL,
SES_ID INT NOT NULL,
COG_ID INT,
STP_RANK_ORDER TINYINT NOT NULL,
STP_RESISTANCE SMALLINT NOT NULL,
STP_SPEED SMALLINT NOT NULL,
STP_MESSAGE VARCHAR(200),
PRIMARY KEY (STP_ID)) ENGINE=InnoDB;

DROP TABLE IF EXISTS T_STIMULATION_STM ;
CREATE TABLE T_STIMULATION_STM (STM_ID INT AUTO_INCREMENT NOT NULL,
STP_ID INT NOT NULL,
USR_ID INT NOT NULL,
MSL_ID INT NOT NULL,
STM_ACTIVE BOOL NOT NULL,
STM_MIN_INTENSITY TINYINT NOT NULL DEFAULT 0,
STM_MAX_INTENSITY TINYINT NOT NULL,
STM_FREQUENCY TINYINT NOT NULL,
STM_PULSEWIDTH SMALLINT NOT NULL,
STM_START_ANGLE SMALLINT NOT NULL,
STM_STOP_ANGLE SMALLINT NOT NULL,
STM_RAMP_UP TINYINT NOT NULL,
STM_RAMP_DOWN TINYINT NOT NULL,
STM_MAX_INTENSITY_INC TINYINT NOT NULL,
STM_SESS_MAX_INTENSITY INT,
PRIMARY KEY (STM_ID)) ENGINE=InnoDB;

DROP TABLE IF EXISTS TR_MUSCLE_MSL ;
CREATE TABLE TR_MUSCLE_MSL (MSL_ID INT AUTO_INCREMENT NOT NULL,
MSL_NAME VARCHAR(20),
MSL_CHANNEL TINYINT,
PRIMARY KEY (MSL_ID)) ENGINE=InnoDB;

DROP TABLE IF EXISTS TR_COGGAN_COG ;
CREATE TABLE TR_COGGAN_COG (COG_ID INT AUTO_INCREMENT NOT NULL,
COG_NUMBER INT NOT NULL,
COG_NAME VARCHAR(20),
COG_DESCRIPTION VARCHAR(200),
COG_FTP_PC_MIN TINYINT NOT NULL,
COG_FTP_PC_MAX TINYINT NOT NULL,
COG_HR_PC_MIN TINYINT NOT NULL,
COG_HR_PC_MAX TINYINT NOT NULL,
PRIMARY KEY (COG_ID)) ENGINE=InnoDB;

DROP TABLE IF EXISTS T_SEQUENCE_SEQ ;
CREATE TABLE T_SEQUENCE_SEQ (SEQ_ID INT AUTO_INCREMENT NOT NULL,
WOT_ID INT NOT NULL,
SEQ_NAME VARCHAR(20) NOT NULL,
SEQ_LOCKED_X_SESS_NEXT_SEQ TINYINT,		-- Sequence locked if x sessions of next sequence are done
SEQ_X_SESSIONS_CARRYON TINYINT,			-- Minimum number of sessions to execute to carry on with next sequence
SEQ_RANK_ORDER INT,
PRIMARY KEY (SEQ_ID)) ENGINE=InnoDB;

DROP TABLE IF EXISTS TR_WORKOUT_TYPE_WOT ;
CREATE TABLE TR_WORKOUT_TYPE_WOT (WOT_ID INT AUTO_INCREMENT NOT NULL,
ERG_ID TINYINT NOT NULL,
WOT_NAME VARCHAR(20) NOT NULL,
PRIMARY KEY (WOT_ID)) ENGINE=InnoDB;

DROP TABLE IF EXISTS T_SESSION_SES ;
CREATE TABLE T_SESSION_SES (SES_ID INT AUTO_INCREMENT NOT NULL,
SES_START_MESSAGE VARCHAR(200),
SES_END_MESSAGE VARCHAR(200),
SES_ASSIST_POWER SMALLINT,
SES_MOTOR_SPEED_OFFSET TINYINT,
SES_WARMUP_RAMP TINYINT,
SES_LINKED_TO_PREV BOOL,			-- Defines if the session can be executed alone or if previous sessions must be done to allow this one
PRIMARY KEY (SES_ID)) ENGINE=InnoDB;

DROP TABLE IF EXISTS TR_ERGOMETER_ERG ;
CREATE TABLE TR_ERGOMETER_ERG (ERG_ID TINYINT AUTO_INCREMENT NOT NULL,
ERG_NAME VARCHAR(20) NOT NULL,
PRIMARY KEY (ERG_ID)) ENGINE=InnoDB;

DROP TABLE IF EXISTS TR_GENDER_GNR ;
CREATE TABLE TR_GENDER_GNR (GNR_ID INT AUTO_INCREMENT NOT NULL,
GNR_NAME CHAR(1) NOT NULL,
PRIMARY KEY (GNR_ID)) ENGINE=InnoDB;

DROP TABLE IF EXISTS TJ_USER_SESSION_USS ;
CREATE TABLE TJ_USER_SESSION_USS (USR_ID INT NOT NULL,
SES_ID INT NOT NULL,
USS_DONE BOOL,
PRIMARY KEY (USR_ID,
 SES_ID)) ENGINE=InnoDB;

DROP TABLE IF EXISTS TJ_SEQ_COMPOSITION_SCP ;
CREATE TABLE TJ_SEQ_COMPOSITION_SCP (SEQ_ID INT NOT NULL,
SES_ID INT NOT NULL,
SCP_RANK_ORDER TINYINT NOT NULL,
PRIMARY KEY (SEQ_ID,
 SES_ID)) ENGINE=InnoDB;

DROP TABLE IF EXISTS TJ_PRACTICE_SEQ_PSQ ;
CREATE TABLE TJ_PRACTICE_SEQ_PSQ (SEQ_ID INT NOT NULL,
USR_ID INT NOT NULL,
PSQ_DONE BOOL NOT NULL,
PRIMARY KEY (SEQ_ID,
 USR_ID)) ENGINE=InnoDB;

ALTER TABLE T_USER_USR ADD CONSTRAINT FK_USR_GNR FOREIGN KEY (GNR_ID) REFERENCES TR_GENDER_GNR (GNR_ID);
ALTER TABLE T_PHYSIOLOGY_PHY ADD CONSTRAINT FK_USR_PHY FOREIGN KEY (USR_ID) REFERENCES T_USER_USR (USR_ID);
ALTER TABLE T_WORKOUT_WO ADD CONSTRAINT FK_WO_SES FOREIGN KEY (SES_ID) REFERENCES T_SESSION_SES (SES_ID);
ALTER TABLE T_WORKOUT_WO ADD CONSTRAINT FK_WO_USR FOREIGN KEY (USR_ID) REFERENCES T_USER_USR (USR_ID);
ALTER TABLE T_MEASURE_MES ADD CONSTRAINT FK_MES_WO FOREIGN KEY (WO_ID) REFERENCES T_WORKOUT_WO (WO_ID);
ALTER TABLE T_STEP_STP ADD CONSTRAINT FK_STP_SES FOREIGN KEY (SES_ID) REFERENCES T_SESSION_SES (SES_ID);
ALTER TABLE T_STEP_STP ADD CONSTRAINT FK_STP_COG FOREIGN KEY (COG_ID) REFERENCES TR_COGGAN_COG (COG_ID);
ALTER TABLE T_STIMULATION_STM ADD CONSTRAINT FK_STM_STP FOREIGN KEY (STP_ID) REFERENCES T_STEP_STP (STP_ID);
ALTER TABLE T_STIMULATION_STM ADD CONSTRAINT FK_STM_MSL FOREIGN KEY (MSL_ID) REFERENCES TR_MUSCLE_MSL (MSL_ID);
ALTER TABLE T_STIMULATION_STM ADD CONSTRAINT FK_STM_USR FOREIGN KEY (USR_ID) REFERENCES T_USER_USR (USR_ID);
ALTER TABLE T_SEQUENCE_SEQ ADD CONSTRAINT FK_SEQ_WOT FOREIGN KEY (WOT_ID) REFERENCES TR_WORKOUT_TYPE_WOT (WOT_ID);
ALTER TABLE TR_WORKOUT_TYPE_WOT ADD CONSTRAINT FK_WOT_ERG FOREIGN KEY (ERG_ID) REFERENCES TR_ERGOMETER_ERG (ERG_ID);
ALTER TABLE TJ_USER_SESSION_USS ADD CONSTRAINT FK_USS_USR FOREIGN KEY (USR_ID) REFERENCES T_USER_USR (USR_ID);
ALTER TABLE TJ_USER_SESSION_USS ADD CONSTRAINT FK_USS_SES FOREIGN KEY (SES_ID) REFERENCES T_SESSION_SES (SES_ID);
ALTER TABLE TJ_SEQ_COMPOSITION_SCP ADD CONSTRAINT FK_SCP_SEQ FOREIGN KEY (SEQ_ID) REFERENCES T_SEQUENCE_SEQ (SEQ_ID);
ALTER TABLE TJ_SEQ_COMPOSITION_SCP ADD CONSTRAINT FK_SCP_SES FOREIGN KEY (SES_ID) REFERENCES T_SESSION_SES (SES_ID);
ALTER TABLE TJ_PRACTICE_SEQ_PSQ ADD CONSTRAINT FK_PSQ_SEQ FOREIGN KEY (SEQ_ID) REFERENCES T_SEQUENCE_SEQ (SEQ_ID);
ALTER TABLE TJ_PRACTICE_SEQ_PSQ ADD CONSTRAINT FK_PSQ_USR FOREIGN KEY (USR_ID) REFERENCES T_USER_USR (USR_ID);

[escartefigue]

Bonjour ZuZu,


Avec Looping, vous n'aurez plus besoin de MySQL Worbench pour générer le MPD
Et c'est pas plus mal car WB ne permet pas de démarrer à l'étape MCD, c'est une source d'erreurs, on le constate souvent

Pour l'association 1-1 Has c'était pour alléger la table User et différencier les propriétés de chaque utilisateur et ses critères physiques propres au sport. J'avais commencé par faire deux entités, puis j'avais re fusionné, puis j'ai re ... séparé Je me suis finalement dit que c'était mieux de séparer pour limiter le nombre de colonnes... Quelle est la bonne pratique du coup, fusionner si ça n'a pas d'autre intérêt que limiter les colonnes d'une table ?

Le plus souvent, pour ne pas dire toujours, quand une table possède un grand nombre de colonnes fonctionnelles (au delà d'une vingtaine, on parle de table "obèse"), c'est qu'il y a une erreur de modélisation.
Dans votre cas, est il pertinent d'associer toutes les caractéristiques à la personne ?
Je ne sais pas ce que sont les attributs FTP, VO2MAX, AMP... (mais peut être ne dépendent ils pas de la personne (des explications sur ces attributs permettraient d'y voir plus clair). Un cas pour lequel il est pertinent de créer un type d'entité distinct est celui où l'on a une colonne très encombrante, il est intéressant dans ce cas de séparer l'élément sur une table particulière ayant le même identifiant (grâce au type d'entité distinct).
A noter que la date de naissance n'est pas propre au sport, elle a donc toute sa place dans [user]

J'utilise parfois le même identifiant entre différentes entités pour la même donnée, ce n'est pas correct ? Voir le sql ci-dessous

C'est correct à la marge, voir ci-dessus

Compris pour les rubriques d'association "Contain" et "Stimulate", c'est corrigé.

Je m'excuse mais qu'est-ce que vous entendez par règles de gestion ?

Les règles de gestion sont les règles, sous formes de phrases, exprimées par la métrise d'ouvrage et vérifiées par celles-ci.
Par confort d'utilisation, on leur attribue un numéro.
C'est grâce à ces règles qu'on justifie la validité du MCD.

Ce qui peut donner quelque chose comme :
R001 : un utilisateur pratique zéro à plusieurs sport
R002 : un sport est pratiqué par zéro à plusieurs utilisateurs

Sachant qu'à minima, il faut une règle de gestion pour chaque "patte" d'association
Sachant aussi que si la maîtrise d'ouvrage est francophone, les règles seront en français. Il faudra donc traduire chaque terme pour que le MCD rédigé en anglais puisse être validé.

Pour chaque étape sont définis les muscles stimulés et les paramètres associés. J'ai une question à ce propos, j'ai ajouté l'information "active" dans l'entité "stimulation" qui paraît en soi inutile car si un muscle n'est pas simulé il n'apparaît pas dans cette entité. L'intérêt est uniquement de conserver les paramètres associés à ce muscle dans le cas où on le désactive temporairement pour permettre de le réactiver sans avoir à ressaisir ses paramètres de stimulation. Est-ce que ça a du sens de le modéliser comme ça ?

Donc une étape (STEP ? ==> le changement de langue entre les explications et le MCD ne facilite pas les échanges...) inclut zéro à plusieurs stimulations et chaque stimulation stimule un et un seul muscle ? Du coup, pas besoin d'attribut "active". Il suffit de ne pas associer de stimulation (la cardinalité mini zéro le permet) à l'étape.

Ces zones de Coggan n'ont d'intérêt qu'en vélo, c'est donc au niveau logiciel qu'il ne sera pas proposé de les définir pour les autres types d'ergomètres. Est ce correct ou y a-t-il une manière de le modéliser ?

que sont les ergomètres, je ne les vois pas dans le modèle.



EDIT : Dans le dernier schéma, de [workout] vers [user], on a une relation 1,1, mais en passant par [session], on peut avoir plusieurs [user] pour une même [workout]...

[ZuZu]

Les attributs de l'entité "Physiology" sont intimement liés à l'utilisateur (la ftp (puissance à seuil fonctionnel) est la puissance max sur 1h en vélo uniquement (l'amp (puissance maximale aérobie) est équivalente et se convertit en ftp), les autres sont valables pour n'importe quel sport, la VO²Max est la consommation maximale d'oxygène, HRmax est la fréquence cardiaque maxi). Je vais donc re...fusionner ces deux entités.
Pour la distinction entre vélo et autres activités au sujet de la ftp et zones de Coggan, ça ne me gène pas de le gérer au niveau du logiciel, ai-je tord ?

Comme j'ai essayé de le dire pour l'attribut "active" de l'entité "Stimulation" c'est uniquement pour qu'une fois des paramètres de stimulation renseignés pour un muscle (entité Stimulation), ces valeurs soient conservées même si l'utilisateur n'utilise plus ce muscle par la suite. L'intérêt est qu'en utilisant à nouveau ce muscle à l'avenir les derniers paramètres soient déjà renseignés.


J'ai joint le mpd pour que vous voyiez le nommage, et les tables de référence pour aider à comprendre.

Pour votre dernière remarque en edit c'est pour moi normal, mais peut-être je passe à côté de l'erreur :
User est l'entité des utilisateurs
Session (tout comme Sequence) est une entité de "modèles" d'exercices.
Workout est la liste des Session effectivement réalisées par l'utilisateur.


Voici donc les règles de gestion. Je pensais simplement interpréter le MCD mais en les rédigeant ça m'a fait prendre conscience de quelques erreurs. C'est utile en fait de commencer par le début !!

R01 : Un appareil (Ergometer) est d'un et un seul type (Ergometer type)
R02 : Un type d'appareil (Ergometer type) définit aucun ou plusieurs appareils (Ergometer)
R03 : Un type d'appareil (Ergometer type) utilise aucun ou plusieurs types d'exercice différents (Workout type)
R04 : Un type d'exercice (Workout type) est réalisable sur aucun ou un seul type d'appareil (Ergometer type)
R05 : Un type d'exercice (Workout type) contient une à plusieurs séquences
R06 : Une séquence (Sequence) est incluse dans un et un seul type d'exercice (Workout type)
R07 : Une séquence (Sequence) est composée de une à plusieurs sessions (Session)
R08 : Une session (Session) compose aucune ou plusieurs séquences (Sequence) différentes
R09 : Une session (Session) est composé de une à plusieurs étapes (Step)
R10 : Une étape (Step) compose une et une seule session (Session)
R11 : Une étape (Step) peut cibler aucune ou une zone de Coggan (Coggan area)
R12 : Une zone de Coggan (Coggan area) est utilisée par zéro ou plusieurs étapes (Step)
R13 : Sur un appareil (Ergometer) est effectué aucun ou plusieurs entraînements (Workout)
R14 : Un entraînement (Workout) est effectué sur un et un seul appareil (Ergometer)
R15 : Un type d'appareil (Workout type) peut effectuer aucune ou plusieurs session (Session)
R16 : Une session (Session) est dédiée à un et un seul type d'appareil (Ergometer type)
R17 : Un utilisateur (User) est d'un et un seul genre (Gender)
R18 : Un genre (Gender) définit un ou plusieurs utilisateurs
R19 : Un utilisateur (User) pratique aucune ou plusieurs séquences (Sequence)
R20 : Une séquence (Sequence) est pratiquée par aucun ou plusieurs utilisateurs (User)
R21: Un utilisateur (User) effectue aucune ou plusieurs sessions (Session)
R22 : Une session (Session) peut être effectuée par aucun ou plusieurs utilisateurs (User)
R23 : Un utilisateur (User) a effectué aucun ou plusieurs entraînements (Workout)
R24 : Un entraînement (Workout) a été effectué par un et un seul utilisateur (User)
R25 : Un utilisateur (User) définit aucune ou plusieurs configurations de stimulation (Stimulation)
R26 : Une configuration de stimulation (Stimulation) est définie pour un et un seul utilisateur (User)
R27 : Une session (Session) sert a effectuer aucune ou plusieurs entraînements (Workout)
R28 : Un entraînement (Workout) est effectué sur le modèle d'une et une seule session (Session)
R29 : Un entraînement (Workout) produit des mesures (Measure)
R30 : Une mesure (Measure) est produite lors d'un et un seul entraînement (Workout)
R31 : Une étape (Step) inclut aucune ou plusieurs configurations de stimulation (Stimulation)
R32 : Une configuration de stimulation (Stimulation) est incluse dans une une seule étape (Step)
R33 : Un muscle (Muscle) est utilisé pour aucune ou plusieurs configurations de stimulation (Stimulation)
R34 : Une configuration de stimulation (Stimulation) est définie pour un et un seul muscle (Muscle)



Au final, pour répondre à mon inquiétude initiale au sujet du nombre d'associations entre une entité et d'autres, je comprends que c'est inévitable dès lors qu'on a au moins une association n-n "sur la route" entre ces entités (je suis sûr que ce n'est pas très clair mais je ne sais pas comment dire autrement).
Exemple : C'est l'association n-n entre Sequence et Session qui implique une association entre Ergometer et Workout.
Si l'association Sequence - Session était n-1, l'association Ergometer-Workout disparaitrait.

[escartefigue]

bonjour Zuzu

C'est très bien d'avoir fait la liste des règles, voilà qui facilite le travail et les échanges

l'association "Practice" est conforme aux règles R23 et R24
l'association "Use" est conforme aux règles R21 et R22

Mais, ce faisant, selon le chemin que l'on emprunte, les cardinalités sont différentes (c'est ce sur quoi j'alertais en bas de ma réponse précédente).
Comme un [workout] concerne une [session] et qu'une [session] peut concerner plusieurs [user], on a par transitivité plusieurs [user] pour un [workout]

Les règles de gestion ne sont pas d'accord entre elles, il faut donc revoir ce point.

Je n'ai pas le temps de regarder le reste plus en détail pour l'instant, j'y reviendrai

[ZuZu]

Bonjour escartefigue

Je comprends le problème mais en vérifiant les cardinalités je ne vois pas ce qui coince et ça me paraît même normal ... je bug à voir ce qui cloche.

Un exemple :
User 1 fait Session 1 ce qui génère Workout 1
User 1 fait Session 2 ce qui génère Workout 2
User 2 fait Session 1 ce qui génère Workout 3
User 2 fait Session 1 ce qui génère Workout 4

L'entité Workout est l'historique des Sessions effectuées.


Et je me rends compte qu'il y a (au moins) un oubli
R35 : Un utilisateur (User) peut pratiquer aucun ou plusieurs programmes d'entraînement (Workout type)
R36 : Un programme d'entraînement (Workout type) est suivi par aucun ou plusieurs utilisateurs (User)


Il y a d'autres "règles" (je ne sais pas si elles doivent faire partie de la liste précédente) que je n'ai pas évoqué, par exemple une séquence N+1 n'est débloquée qu'après avec exécuté X sessions de la séquence N en cours, j'ai indiqué l'attribut "x_sess_to_carryon" (x sessions pour poursuivre) dans l'entité Sequence pour gérer cela.
Autre exemple, les séquences N-1 sont verrouillées dès lors que la séquence N a débuté, c'est l'utilité de l'attribut done de l'association entre User et Sequence.
Est ce que ça doit faire parti de règles de modélisation également et éventuellement être géré autrement ?

[escartefigue]

Bonjour ZuZu

Je crois que l'explication est ici :

Session (tout comme Sequence) est une entité de "modèles" d'exercices.
Workout est la liste des Session effectivement réalisées par l'utilisateur.

Du coup, l'utilisateur n'a pas de lien direct avec la session, il effectue un entraînement (workout) qui se base sur un entraînement type (session)
il faut donc retirer l'association entre utilisateur et session
Il serait peut être plus simple de renommer session en workout-type ?

[ZuZu]

Bonjour

Cette liaison est là car l'utilisateur a deux possibilités, soit faire un exercice simple (une Session hors séquence), soit dans le cadre d'un programme d'entraînement global sur plusieurs semaines (Workout type composé de Sequences et Sessions).

Par contre, certains attributs de session n'ont de sens que lors de l'exécution au sein d'une séquence (start_message, end_message et linked_to_previous)
Ça sent l'héritage ?🤔 Mais je ne sais pas comment le modéliser car tous les exercises effectués par l'utilisateur doivent se trouver dans Workout

[escartefigue]

Cette liaison est là car l'utilisateur a deux possibilités, soit faire un exercice simple (une Session hors séquence), soit dans le cadre d'un programme d'entraînement global sur plusieurs semaines (Workout type composé de Sequences et Sessions).

OK mais le problème n'est pas entre session et séquence, le problème c'est qu'un entrainement (workout) via l'association "practice" concerne un et un seul user et via execute->session->use en concerne plusieurs.
Vu que l'entrainement est lié à des mesures individuelles, je comprends qu'il ne peut concerner qu'une seule personne, c'est donc l'association "practice" et les règles R23 et R24 qui me semblent correcte
Je suppose qu'il faut supprimer l'association "use" entre user et session et les règles R21 et R22.
Je suppose aussi qu'un entrainement serait donc facultativement et non plus obligatoirement rattaché à une session

Voici comment je vois les choses pour la partie sequence, session, user, workout et measure

Pièce jointe 592086

N'hésitez pas à donner des exemples de ce qui se passe pour une personne arrivant en salle de sport et pratiquant un entrainement, une session etc.
J'avoue que pour l'instant, je ne suis pas certain de bien comprendre ce que représente chaque type d'entité

Par contre, certains attributs de session n'ont de sens que lors de l'exécution au sein d'une séquence (start_message, end_message et linked_to_previous)
Ça sent l'héritage ?🤔 Mais je ne sais pas comment le modéliser car tous les exercices effectués par l'utilisateur doivent se trouver dans Workout

Laissons ça de coté pour l'instant

[ZuZu]

Alors ce schéma va très bien pour une utilisation dans le cadre d'un entraînement global (Workout type / séquence / session)
J'avais rajouté l'association user/session pour les entraînements indépendants (hors Workout type / séquence), et l'attribut "done" permettrait de savoir quelles sessions étaient déjà réalisées pour poursuivre à la suivante.

Différence entre les deux :
- (global) Paul (user) veut faire du rameur (Ergometer type) et utilise le n° 3 (Ergometer) et poursuit son entraînement remise en forme (Workout type) débuté il y a 2 semaines composé de 5 séquences chacune composée de 3 à 6 sessions. Chaque jour il effectue (Workout) la session suivante.
- (indépendant) Pierre (user) va sur un vélo (Ergometer type), choisit le n°2 (Ergometer) et effectue (Workout) une session qu'il vient de créer.

Pour le deuxième cas, ajouter une session user/session n'est donc pas correct, mais il faut un lien entre User et session pour ce cas là. J'étais parti sur cette association user/session (à tort de toute façon) pour que les mêmes sessions puissent être réalisées indépendamment ou dans le cadre d'un programme global. Or pour des raison de simplicité on m'a confirmé hier que les sessions réalisables hors entraînement global ne doivent pas être les même.
Il faut donc une autre entité qui serve de modèle de "session indépendante" mais dont on retrouve la trace une fois exécutée dans la même entité "workout".
Cette nouvelle catégorie de sessions est tout comme la première composée des mêmes étapes "step" et incluant des configuration de "stimulation". Par contre les zones Coggan n'ont de sens que dans le cadre d'un entraînement global.

Les attributs assist_power, motor_speed_offset et warmup_ramp sont communs aux deux.
Les 3 autres attributs sont propres aux sessions contenues dans des séquences.

Ou une solution peut être moins propre serait d'ajouter un attribut dans session indiquant si elle fait partie d'une séquence afin de discriminer les deux catégories.

[escartefigue]

Bonsoir ZuZu

Alors tout va bien, le modèle que je vous ai proposé fonctionne aussi bien pour Paul que pour Pierre puisque le lien entre [session] et [sequence] est facultatif
Paul aura un lien entre [session] et [sequence] alors que Pierre n'en aura pas. Pierre créera sa [sequence] de toutes pièces puisqu'elle est hors programme.
Il faudra juste remettre la cardinalité 1,1 au lieu de 0,1 de [workout] vers [sequence]

Au sujet de cette remarque

on m'a confirmé hier que les sessions réalisables hors entraînement global ne doivent pas être les mêmes.
Il faut donc une autre entité qui serve de modèle de "session indépendante" mais dont on retrouve la trace une fois exécutée dans la même entité "workout".

C'est l'absence de lien d'association des sessions hors entraînement global vers [sequence] qui permettra de les reconnaître aisément, pas besoin d'entité-type spécifique

[ZuZu]

le modèle que je vous ai proposé fonctionne aussi bien pour Paul que pour Pierre puisque le lien entre [session] et [sequence] est facultatif

Oui, sauf qu'on ne retrouve pas l'attribution de la session à l'utilisateur dans le cas de Paul. Parmi toutes les sessions possibles il faut qu'on puisse ne lui afficher que "les siennes". C'est pour cela que j'avais rajouté la fameuse association "use" entre [user] et [session].

Pierre créera sa [sequence] de toutes pièces puisqu'elle est hors programme.
Il faudra juste remettre la cardinalité 1,1 au lieu de 0,1 de [workout] vers [sequence]

Vous avez utilisé deux fois [sequence] au lieu de [session] ici (enfin j'espère ... &#129315

C'est l'absence de lien d'association des sessions hors entraînement global vers [sequence] qui permettra de les reconnaître aisément, pas besoin d'entité-type spécifique

👍 Je cherchais le complication !

[escartefigue]

Bonsoir ZuZu,

Oui, sauf qu'on ne retrouve pas l'attribution de la session à l'utilisateur dans le cas de Paul. Parmi toutes les sessions possibles il faut qu'on puisse ne lui afficher que "les siennes". C'est pour cela que j'avais rajouté la fameuse association "use" entre [user] et [session].

Si, en rétablissant la cardinalité 1,1 de [workout] vers [session] (et non pas sequence comme je l'ai écrit plus haut par erreur ), on est certain de retrouver la session
cf. le script produit par looping pour l'extrait du MCD et que je communique plus bas.

Vous avez utilisé deux fois [sequence] au lieu de [session] ici (enfin j'espère ... &#129315

Mea culpa, j'ai confondu l'un et l'autre

Voici donc l'extrait du MCD avec de nouveau la cardinalité 1,1 de WO vers SN :

Pièce jointe 592144

Et le script correspondant (j'ai choisi SQL server, mais si ça ne convient pas, il suffit de modifier ce choix).
On y voit bien la FK SN_ident dans la table WO_workout qui permet d'associer l'utilisateur US_ident à la session (US_ident étant également présent comme FK dans la table WO)

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
CREATE TABLE SQ_sequence(
   SQ_ident INT IDENTITY,
   PRIMARY KEY(SQ_ident)
);
 
CREATE TABLE SN_session(
   SN_ident INT IDENTITY,
   PRIMARY KEY(SN_ident)
);
 
CREATE TABLE US_user(
   US_ident INT IDENTITY,
   US_nom VARCHAR(50) NOT NULL,
   US_prenom VARCHAR(50) NOT NULL,
   PRIMARY KEY(US_ident)
);
 
CREATE TABLE WO_workout(
   WO_ident INT IDENTITY,
   WO_date DATE NOT NULL,
   WO_heure TIME NOT NULL,
   US_ident INT NOT NULL,
   SN_ident INT NOT NULL,
   PRIMARY KEY(WO_ident),
   FOREIGN KEY(US_ident) REFERENCES US_user(US_ident),
   FOREIGN KEY(SN_ident) REFERENCES SN_session(SN_ident)
);
 
CREATE TABLE MS_measure(
   WO_ident INT,
   MS_ident INT IDENTITY,
   PRIMARY KEY(WO_ident, MS_ident),
   FOREIGN KEY(WO_ident) REFERENCES WO_workout(WO_ident)
);
 
CREATE TABLE QN_compose(
   SQ_ident INT,
   SN_ident INT,
   QN_order SMALLINT NOT NULL,
   PRIMARY KEY(SQ_ident, SN_ident),
   UNIQUE(QN_order),
   FOREIGN KEY(SQ_ident) REFERENCES SQ_sequence(SQ_ident),
   FOREIGN KEY(SN_ident) REFERENCES SN_session(SN_ident)
);

[ZuZu]

Alors pardon, je vais être pénible mais sans effectuer de session on ne l'a pas. L'entité [workout] est une entité d'historique en fait.

Si l'utilisateur veut effectuer une session, il regarde la liste disponible (éléments de l'entité [session] ne faisant pas partie d'une [séquence]).
Il s'attribue cette [session] pour l'avoir dans sa liste, AVANT de l'avoir éventuellement exécutée.
Imaginons que j'arrive sur un équipement pour la première fois, je veux sélectionner deux ou trois sessions (parmi la liste de toutes celles présentent) pour ne retrouver qu'elles en accès plus rapide.

Au final il faut une table avec le couple US_ident et SN_ident en clé primaire. (Ce que j'avais obtenu avec l'association entre [user] et [session] mais qui pose le problème que vous avez souligné)

[escartefigue]

Bonsoir ZuZu,

OK du coup on doit pouvoir s'en sortir :
La notion de sélection devient un type d'entité en lien avec un et un seul utilisateur, cette sélection concerne une session et fera l'objet de zéro à plusieurs entraînements
L'entraînement est lié soit directement à l'utilisateur, soit directement à une sélection, (contrainte X d'exclusion ci-dessous)
Ainsi, on respecte bien le fait que l'entraînement concerne un et un seul utilisateur.

Est-ce que cette nouvelle proposition vous convient ?

Pièce jointe 592217

Et le script correspondant (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
CREATE TABLE SQ_sequence(
   SQ_ident INT IDENTITY,
   PRIMARY KEY(SQ_ident)
);
 
CREATE TABLE SN_session(
   SN_ident INT IDENTITY,
   PRIMARY KEY(SN_ident)
);
 
CREATE TABLE US_user(
   US_ident INT IDENTITY,
   US_nom VARCHAR(50) NOT NULL,
   US_prenom VARCHAR(50) NOT NULL,
   PRIMARY KEY(US_ident)
);
 
CREATE TABLE SE_selection(
   US_ident INT,
   SE_ident INT IDENTITY,
   SE_date DATE NOT NULL,
   SN_ident INT NOT NULL,
   PRIMARY KEY(US_ident, SE_ident),
   FOREIGN KEY(US_ident) REFERENCES US_user(US_ident),
   FOREIGN KEY(SN_ident) REFERENCES SN_session(SN_ident)
);
 
CREATE TABLE WO_workout(
   WO_ident INT IDENTITY,
   WO_date DATE NOT NULL,
   WO_heure TIME NOT NULL,
   US_ident INT,
   US_ident_1 INT,
   SE_ident INT,
   PRIMARY KEY(WO_ident),
   FOREIGN KEY(US_ident) REFERENCES US_user(US_ident),
   FOREIGN KEY(US_ident_1, SE_ident) REFERENCES SE_selection(US_ident, SE_ident)
);
 
CREATE TABLE MS_measure(
   WO_ident INT,
   MS_ident INT IDENTITY,
   PRIMARY KEY(WO_ident, MS_ident),
   FOREIGN KEY(WO_ident) REFERENCES WO_workout(WO_ident)
);
 
CREATE TABLE QN_compose(
   SQ_ident INT,
   SN_ident INT,
   QN_order SMALLINT NOT NULL,
   PRIMARY KEY(SQ_ident, SN_ident),
   UNIQUE(QN_order),
   FOREIGN KEY(SQ_ident) REFERENCES SQ_sequence(SQ_ident),
   FOREIGN KEY(SN_ident) REFERENCES SN_session(SN_ident)
);

Au fait, quel est le SGBD cible si déjà choisi ?

[ZuZu]

Bonsoir

Alors j'avoue avoir du mal à tout comprendre.

Pourquoi un identifiant SE_ident et non directement le couple SN_ident / US_ident ?
Pourquoi retrouve-t-on deux fois ID_user dans la table Workout ?

J'ai l'impression qu'il faut nécessairement passer par cette entité SE_selection pour faire un exercice même dans le cas où c'est dans le cadre d'un entraînement global (séquences) non ?


Le SGBD sera SQLite (tablette Android)

[escartefigue]

Bonsir ZuZu

Pourquoi un identifiant SE_ident et non directement le couple SN_ident / US_ident ?

Toute entité-type doit avoir son identifiant

Pourquoi retrouve-t-on deux fois ID_user dans la table Workout ?

Parceque celui-ci provient soit de [US_user] soit de [SE_selection] et comme [SE_selection] est identifié relativement à [US_user] (R) sur la patte de l'association, sa PK hérite de l'identifiant de [US_user]

J'ai l'impression qu'il faut nécessairement passer par cette entité SE_selection pour faire un exercice même dans le cas où c'est dans le cadre d'un entraînement global (séquences) non ?

Oui, ça correspond à ce que j'ai compris de votre réponse suivante :

Si l'utilisateur veut effectuer une session, il regarde la liste disponible (éléments de l'entité [session] ne faisant pas partie d'une [séquence]).
Il s'attribue cette [session] pour l'avoir dans sa liste, AVANT de l'avoir éventuellement exécutée.
Imaginons que j'arrive sur un équipement pour la première fois, je veux sélectionner deux ou trois sessions (parmi la liste de toutes celles présentes) pour ne retrouver qu'elles en accès plus rapide.

Ca me semble cohérent : la sélection se fait dans la liste disponible dans ce cas précis ou par création dans le cas d'une sélection hors sequences proposées.

Le SGBD sera SQLite (tablette Android)

OK

[ZuZu]

Ca me semble cohérent : la sélection se fait dans la liste disponible dans ce cas précis ou par création dans le cas d'une sélection hors sequences proposées.

Vous n'avez pas représenté l'association entre [Sequence] et [User] c'est volontaire ?

Je ne sais pas si je comprends bien mais c'est plutôt dans le cas "hors Sequence" que l'utilisateur doit sélectionner une session de sa liste (ou en affecter à cette liste au préalable).

Dans le cas d'un entraînement global, l'utilisateur poursuit sa [Sequence] avec une des [Sessions] disponibles (une déjà faite ou la suivante), il n'a pas à faire d'autre "sélection". Cette entité [Selection] me convient uniquement dans le cas d'exercice libre, mais je comprends que les sessions effectuées lors de son entraînement global apparaîtront donc dans cette sélection, je me trompe ? Or il ne faudrait pas.

Exemple :
Sessions N°1 à 30 -> créées pour la séquence 2, que l'utilisateur est en train d'effectuer
Session 31 -> Créée par l'utilisateur. Il a sélectionné dans sa liste la N°17 également.

Sa sélection est donc composée des sessions 17 et 31 qu'il peut effectuer hors sequence.


Je reviens sur l'association Use entre [User] et [Session] sur laquelle vous m'aviez alerté, et qui permettait d'associer un [Workout] à plusieurs [User]. Ce cas n'arrivera jamais puisque ce n'est pas le fonctionnement logiciel qui est prévu, quel était donc le risque de cette association si de manière logicielle ce n'est pas prévu d'affecter plusieurs [User] à un [Workout] ?