Discussion :

[escartefigue]

J'espère que ce coup ci, c'est le bon

Pièce jointe 592309

La contrainte X entre QN et CR mentionne qu'une session est soit issue d'une séquence (programme global) soit créée par l'utilisateur

Du coup tout entrainement (WO) est lié à une et une seule session et un et un seul user

Avec Looping, j'ai coché la case "générer une table de correspondance dans le MLD" pour l'association "CR_creer".
Ce faisant une table associative est créée pour les lien US_ident<=>SN_ident, évitant ainsi d'avoir une colonne US_ident "nullable" dans SN_session
Ce choix est facultatif (mais ça fera plaisir aux puristes )

Le MLD correspondant

Pièce jointe 592310

Et le script, pour SQLite cette fois-ci

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
CREATE TABLE SQ_sequence(
   SQ_ident INTEGER,
   PRIMARY KEY(SQ_ident)
);
 
CREATE TABLE SN_session(
   SN_ident INTEGER,
   PRIMARY KEY(SN_ident)
);
 
CREATE TABLE US_user(
   US_ident INTEGER,
   US_nom TEXT NOT NULL,
   US_prenom TEXT NOT NULL,
   PRIMARY KEY(US_ident)
);
 
CREATE TABLE WO_workout(
   WO_ident INTEGER,
   WO_date NUMERIC NOT NULL,
   WO_heure NUMERIC NOT NULL,
   US_ident INTEGER NOT NULL,
   SN_ident INTEGER 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 INTEGER,
   MS_ident INTEGER,
   PRIMARY KEY(WO_ident, MS_ident),
   FOREIGN KEY(WO_ident) REFERENCES WO_workout(WO_ident)
);
 
CREATE TABLE QN_composer(
   SQ_ident INTEGER,
   SN_ident INTEGER,
   QN_order INTEGER 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)
);
 
CREATE TABLE CR_creer(
   SN_ident INTEGER,
   US_ident INTEGER NOT NULL,
   PRIMARY KEY(SN_ident),
   FOREIGN KEY(SN_ident) REFERENCES SN_session(SN_ident),
   FOREIGN KEY(US_ident) REFERENCES US_user(US_ident)
);

[ZuZu]

Bonjour escartefigue

C'est peut-être dû à l'heure matinale à laquelle j'ai regardé ce schéma mais je n'ai pas passé plus d'une demi-heure à le comprendre comme l'autre hier soir

Petit question de néophyte, comment se traduit la contrainte dans le MLD ?

Il faut juste un N côté session sur l'association CE_creer pour qu'un utilisateur puisse utiliser des sessions déjà créées qui lui correspondent, mais je sens que je vais me faire gronder ... C'était le sens de ma dernière phrase dans l'exemple précédent

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.

J'ai pris 17 dans cet exemple qui correspond à une session intégrée à une séquence mais ça pourrait être n'importe quelle session (une indépendante créée pour un autre utilisateur).

Et je réitère ma question, Vous n'avez pas représenté l'association entre [Sequence] et [User] c'est volontaire ?

Je referai tout le schéma avec Looping (dès que mon écran de pc sera réparé

[escartefigue]

Re

Petit question de néophyte, comment se traduit la contrainte dans le MLD ?

On aurait pu créer un TRIGGER, mais je me rends compte qu'il y a bien plus simple : une contrainte UNIQUE sur la combinaison d'attributs d'une session permettra de vérifier qu'on ne fait pas de doublon fonctionnel lors de la création d'une session.

Il faut juste un N côté session sur l'association CR_creer pour qu'un utilisateur puisse utiliser des sessions déjà créées qui lui correspondent

Heu non, cette association c'est la création de la session hors séquence. Cette création est bien le fait d'au plus un user, d'où le (zéro,un)
Ca n'empêche pas d'autres users d'utiliser (via l'association US_WO) cette session lors d'un entrainement
L'utilisation sera donc matérialisée par la présence d'une occurrence de WO ayant pour FK le SN_ident de cette session créée par un tiers.

Et je réitère ma question, Vous n'avez pas représenté l'association entre [Sequence] et [User] c'est volontaire ?

Je ne m'étais pas intéressé à cette association jusqu'ici.
De ce que je comprends, le terme "exécuter" est inadapté, l'utilisateur ne fait que s'inscrire à une séquence et il ne l'aura exécutée que quand il aura fait les entrainements (WO) de toutes les sessions (SN) attachées à cette séquence (SQ). C'est bien ça ?
En complément, les sessions faites hors séquence ne doivent pas être prises en considération pour considérer qu'une séquence est terminée ou pas.
On est d'accord ?


Voici une version sans la contrainte X (il faudra déterminer quelle combinaison d'attributs doit être unique dans SN_session) et dans laquelle j'ai ajouté l'association entre US_user et SQ_sequence. Asso nommée "inscrire" plutôt que "exécuter" vu ce que j'ai compris du rôle de cette asso


Pièce jointe 592336

Je referai tout le schéma avec Looping (dès que mon écran de pc sera réparé

Le MCD est trop gros pour être communiqué directement, le voici donc zipé

[ZuZu]

Bonsoir

On aurait pu créer un TRIGGER, mais je me rends compte qu'il y a bien plus simple : une contrainte UNIQUE sur la combinaison d'attributs d'une session permettra de vérifier qu'on ne fait pas de doublon fonctionnel lors de la création d'une session.

Il n'y a pas critère d'unicité dans l'entité [Session], au mieux ce serait la totalité des attributs des étapes [Step] qui la composent mais quand bien même il y aurait un doublon parfait ça n'a pas d'importance.

Heu non, cette association c'est la création de la session hors séquence.

C'est l'attribution plutôt d'une [Session] à un utilisateur. Cas typique un coach créé une session d'échauffement standard par exemple et l'attribut à plusieurs utilisateurs.
On a une incompréhension sur ce point, c'est pour ça qu'il faut pouvoir associer une session à plusieurs utilisateurs mais comme je ne cerne pas bien le problème de mon mcd précédent à ce propos je n'arrive peut être pas bien à m'expliquer.

Ca n'empêche pas d'autres users d'utiliser (via l'association US_WO) cette session lors d'un entrainement
L'utilisation sera donc matérialisée par la présence d'une occurrence de WO ayant pour FK le SN_ident de cette session créée par un tiers.

L'entité [Workout] est la liste des sessions effectuées, s'il y a une association directe avec [User] c'est parce qu'on ne retrouve pas celui ci du fait des cardinalités 0 côté [Session] des associations avec [Sequence] et [User].
Cette entité [Workout] n'est qu'une table d'historique.

Je ne m'étais pas intéressé à cette association jusqu'ici.

Pas de souci c'était juste pour savoir si c'était délibéré

De ce que je comprends, le terme "exécuter" est inadapté,

absolument 😁

l'utilisateur ne fait que s'inscrire à une séquence et il ne l'aura exécutée que quand il aura fait les entrainements (WO) de toutes les sessions (SN) attachées à cette séquence (SQ). C'est bien ça ?

Quand il aura effectué toutes les [Session] qui composent cette [Sequence] plutôt (dont on trouvera la trace dans l'entité [Workout])

En complément, les sessions faites hors séquence ne doivent pas être prises en considération pour considérer qu'une séquence est terminée ou pas.
On est d'accord ?

Absolument, c'est la liste de [Session] composant chaque [Sequence] qui se trouve dans la table créée par l'association entre les deux qui définit cette composition.

[escartefigue]

Bonsoir ZuZu

Bonsoir
Il n'y a pas critère d'unicité dans l'entité [Session], au mieux ce serait la totalité des attributs des étapes [Step] qui la composent mais quand bien même il y aurait un doublon parfait ça n'a pas d'importance.

Surtout pas ! Les doublons fonctionnels sont interdits. On ne créera une nouvelle occurrence de session que si cette occurrence, fonctionnellement, n'existe pas.
Si un user ne trouve pas son bonheur dans le panel des sessions existantes, (rattachées ou pas à une séquence) alors on en crée une. Si la session existe déjà, il se l'affecte, peu importe que cette session soit ou non rattachée à une séquence.

C'est l'attribution plutôt d'une [Session] à un utilisateur. Cas typique un coach créé une session d'échauffement standard par exemple et l'attribut à plusieurs utilisateurs.
On a une incompréhension sur ce point, c'est pour ça qu'il faut pouvoir associer une session à plusieurs utilisateurs mais comme je ne cerne pas bien le problème de mon mcd précédent à ce propos je n'arrive peut être pas bien à m'expliquer.

je pensais qu'il fallait mémoriser la création de cette session par un utilisateur, c'est ce que j'ai voulu représenter. Non c'est bien la notion d'affectation que vous voulez mémoriser, même s'il n'y a pas encore eu de workout.
Je vais donc reprendre le travail sur ce point.
J'avais déjà été dans cette voie avec ma réponse n° 17 (j'avais créé une entité-type "selection" plutôt que "affectation") mais nos échanges qui ont suivi m'ont fait penser que ce n'était pas la bonne voie.

Je n'aurai pas le courage de m'y remettre ce soir, mais je ne vous abandonne pas

[ZuZu]

Je ne comprends pas ce qui est si genant d'avoir un doublon au niveau de l'entité session, d'ailleurs ça va nécessairement être les cas beaucoup plus fréquemment que ce que je pensais. On peut imaginer plusieurs [Session] identiques mais dont les attributs des étapes [Step] sont différents.

je pensais qu'il fallait mémoriser la création de cette session par un utilisateur

Ah non pardon, on se fiche de savoir qui créé quoi.

même s'il n'y a pas encore eu de workout.

Tout à fait

J'avais déjà été dans cette voie avec ma réponse n° 17 (j'avais créé une entité-type "selection" plutôt que "affectation")

Pourquoi est ce que la simple association 1-N entre [Session] et [User] (si on force la création d'une table) que j'avais faite à cet effet pose problème ? Vous m'aviez indiqué qu'il pouvait y avoir des affectations d'un Workout à plusieurs User mais ce ne sera jamais le cas puisque un et un seul utilisateur effectuera une session à un instant t et dans la table Workout on trouvera cet utilisateur et cet id de session donc impossible d'avoir un autre workout d'un autre utilisateur avec le même id.

[escartefigue]

Je ne comprends pas ce qui est si genant d'avoir un doublon au niveau de l'entité session, d'ailleurs ça va nécessairement être les cas beaucoup plus fréquemment que ce que je pensais. On peut imaginer plusieurs [Session] identiques mais dont les attributs des étapes [Step] sont différents.

C'est ce qui fait toute la différence entre un journal ou un tableur et une base de données
Dans un journal, on enregistre tous les éléments autant de fois qu'ils se produisent sans se préoccuper des redondances
Par exemple, si plusieurs sessions identiques ont des étapes différentes, on enregistre autant des fois les caractéristiques de la session et de l'étape que nécessaire alors que dans une base de données, on enregistre une seule fois les attributs de la session et on les met autant de fois que nécessaire en relation avec les attributs des différentes étapes.

Quand vous allez chez votre médecin pour une grippe et que vous y retournez pour une verrue plantaire, votre médecin ne crée pas deux fiches patient à votre nom, il conserve bien la même, mais avec deux consultations, c'est ce qui lui permet de connaitre votre historique médical.

Donc, dans une base de données, plusieurs sessions identiques non, une même session utilisée plusieurs fois avec des étapes différentes oui

Pourquoi est ce que la simple association 1-N entre [Session] et [User] (si on force la création d'une table) que j'avais faite à cet effet pose problème ? Vous m'aviez indiqué qu'il pouvait y avoir des affectations d'un Workout à plusieurs User mais ce ne sera jamais le cas puisque un et un seul utilisateur effectuera une session à un instant t et dans la table Workout on trouvera cet utilisateur et cet id de session donc impossible d'avoir un autre workout d'un autre utilisateur avec le même id.

J'y reviendrai après avoir reconsidéré la notion d'affectation

[ZuZu]

Bonjour
Oui je suis évidemment bien d'accord sur les doublons, alors disons que l'attribut unique sera au moins le nom. Je voulais dire que le plus gros des changements qui constituent la session sont ses différentes étapes.

[escartefigue]

Bonjour Zuzu

Voici ma proposition qui se base sur le type d'entité [SELECTION]

À partir du moment où un USER s'attribue une SEQUENCE toutes les SESSIONS de cette SEQUENCE sont ajoutées automatiquement à sa SELECTION (autant d'occurrences que nécessaire sont ajoutées dans le type d'entité [SELECTION])
De la même façon, à partir du moment où un USER crée une SESSION de toutes pièces, cette SESSION est ajoutée automatiquement à sa SELECTION.
Ces automatismes peuvent être faits par exemple grâce à des triggers ou des procédures stockées.

Le lien entre le WORKOUT et la SESSION est résolu par la présence de l'identifiant de SESSION dans la SELECTION
De la même façon, l'unicité du USER pour un WORKOUT est garantie par la présence de l'identifiant USER dans la SELECTION.
Pour une même SELECTION il peut y avoir zéro à plusieurs WORKOUT

Ce qui donne :

Pièce jointe 592728

Et le script SQLITE correspondant :

Code SQL :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
CREATE TABLE SQ_sequence(
   SQ_ident INTEGER,
   PRIMARY KEY(SQ_ident)
);
 
CREATE TABLE SN_session(
   SN_ident INTEGER,
   PRIMARY KEY(SN_ident)
);
 
CREATE TABLE US_user(
   US_ident INTEGER,
   US_nom TEXT NOT NULL,
   US_prenom TEXT NOT NULL,
   PRIMARY KEY(US_ident)
);
 
CREATE TABLE SE_selection(
   SN_ident INTEGER,
   US_ident INTEGER,
   SE_ident INTEGER,
   SE_date NUMERIC NOT NULL,
   PRIMARY KEY(SN_ident, US_ident, SE_ident),
   FOREIGN KEY(SN_ident) REFERENCES SN_session(SN_ident),
   FOREIGN KEY(US_ident) REFERENCES US_user(US_ident)
);
 
CREATE TABLE WO_workout(
   WO_ident INTEGER,
   WO_date NUMERIC NOT NULL,
   WO_heure NUMERIC NOT NULL,
   SN_ident INTEGER NOT NULL,
   US_ident INTEGER NOT NULL,
   SE_ident INTEGER NOT NULL,
   PRIMARY KEY(WO_ident),
   FOREIGN KEY(SN_ident, US_ident, SE_ident) REFERENCES SE_selection(SN_ident, US_ident, SE_ident)
);
 
CREATE TABLE MS_measure(
   WO_ident INTEGER,
   MS_ident INTEGER,
   PRIMARY KEY(WO_ident, MS_ident),
   FOREIGN KEY(WO_ident) REFERENCES WO_workout(WO_ident)
);
 
CREATE TABLE QN_compose(
   SQ_ident INTEGER,
   SN_ident INTEGER,
   QN_order INTEGER 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)
);
 
CREATE TABLE UQ_attribuer(
   SQ_ident INTEGER,
   US_ident INTEGER,
   UQ_date NUMERIC NOT NULL,
   PRIMARY KEY(SQ_ident, US_ident),
   FOREIGN KEY(SQ_ident) REFERENCES SQ_sequence(SQ_ident),
   FOREIGN KEY(US_ident) REFERENCES US_user(US_ident)
);

[ZuZu]

Bonjour escartefigue

À partir du moment où un USER s'attribue une SEQUENCE toutes les SESSIONS de cette SEQUENCE sont ajoutées automatiquement à sa SELECTION

Ah oui mais non, ce n'est pas une demande, seules les sessions qu'il a décidé (ou le coach) de s'attribuer doivent lui être. Ca ne ferait pas tellement sens et il y en a beaucoup trop dans une séquence.

Ok pour le reste, sauf un détail qui me chiffonne on n'a pas besoin de l'identifiant de SELECTION dans la table WORKOUT mais uniquement de l'utilisateur, d'ailleurs cette sélection peut ne plus exister à l'avenir si l'utilisateur supprime cette session de SELECTION parce qu'il n'en a plus l'usage, ce n'est pas grave l'essentiel sont les identifiants de USER et SESSION mais ça me parait être une information inutile.

Du coup je propose juste de rajouter une association entre SESSION et WORKOUT.

[escartefigue]

Bonsoir Zuzu

Ah oui mais non, ce n'est pas une demande, seules les sessions qu'il a décidé (ou le coach) de s'attribuer doivent lui être. Ca ne ferait pas tellement sens et il y en a beaucoup trop dans une séquence.

OK, oublions l'automatisme, il faudra un traitement qui permet de créer les SELECTION pertinentes, mais j'avais déduis ce besoin de votre règle de gestion R19

R19 : Un utilisateur (User) pratique aucune ou plusieurs séquences (Sequence)

En ce cas, quelle est la nature de l'association entre USER et SEQUENCE, cette association existe-t-elle vraiment ?

Ok pour le reste, sauf un détail qui me chiffonne on n'a pas besoin de l'identifiant de SELECTION dans la table WORKOUT mais uniquement de l'utilisateur, d'ailleurs cette sélection peut ne plus exister à l'avenir si l'utilisateur supprime cette session de SELECTION parce qu'il n'en a plus l'usage, ce n'est pas grave l'essentiel sont les identifiants de USER et SESSION mais ça me parait être une information inutile.

L'identifiant de la SELECTION est hérité automatiquement à cause de la cardinalité maxi 1 de WO_workout vers l'association SE_WO.
Et on en a besoin pour retrouver la sélection qui permet de trouver d'un coté la session et de l'autre le user.

Du coup je propose juste de rajouter une association entre SESSION et WORKOUT.

Surtout pas, car on retombe dans la faille permettant à un même WORKOUT de pointer vers plusieurs USER (à cause du maxi n de SN_session vers SE_SN).
Seule la base de données permet de garantir l'intégrité référentielle, il est donc fondamental que cet unicité du USER pour un WORKOUT soit assurée par la modélisation des données.
De plus, votre modèle conserve également l'identifiant de SELECTION dans la table WORKOUT, puisque la aussi la cardinalité maxi est 1 de WO_workout vers l'association SE_WO

[ZuZu]

En ce cas, quelle est la nature de l'association entre USER et SEQUENCE, cette association existe-t-elle vraiment ?

Oui, cette association permet de connaitre quelles séquences ont été effectuées par l'utilisateur et donc où il en est, au niveau des sessions dans une séquence également pour lui proposer la bonne session à effectuer la prochaine fois.

Et on en a besoin pour retrouver la sélection qui permet de trouver d'un coté la session et de l'autre le user.

Oui mais ce sont bien de SESSION et USER dont on a uniquement besoin au final ?

Surtout pas, car on retombe dans la faille permettant à un même WORKOUT de pointer vers plusieurs USER (à cause du maxi n de SN_session vers SE_SN).
Seule la base de données permet de garantir l'intégrité référentielle, il est donc fondamental que cet unicité du USER pour un WORKOUT soit assurée par la modélisation des données.

De toute façon je me rends compte que ça n'allait pas car ça ne permet pas d'établir un lien entre USER et SESSION sans passer par SELECTION.
J'en reviens donc à l'idée dune simple association n-n entre USER et SESSION (cf message n°6), en ne comprenant toujours pas le problème que vous ré-évoquez ici.
C'est bien normal qu'une SESSION puisse être exécutée par plusieurs USER, pour autant puisqu'un WORKOUT ne peut avoir été réalisé que par un et un seul USER, on a l'identifiant de USER dans la table WORKOUT donc je ne vois pas comment associer plusieurs USER à un WORKOUT. Je suis vraiment navré de passer à coté de ce problème, pouvez-vous me donner un petit exemple pour illustrer le risque ? Je remets le bout de mcd que j'avais initialement

De plus, votre modèle conserve également l'identifiant de SELECTION dans la table WORKOUT, puisque la aussi la cardinalité maxi est 1 de WO_workout vers l'association SE_WO

Oui ça je ne sais pas comment s'en passer mais ce n'est qu'un dommage collatéral, je me dis que ce n'est pas une information qui sera utilisée dans WORKOUT mais dont sa présence ne pose pas de problème.

[escartefigue]

Oui, cette association permet de connaitre quelles séquences ont été effectuées par l'utilisateur et donc où il en est, au niveau des sessions dans une séquence également pour lui proposer la bonne session à effectuer la prochaine fois.

Absolument pas : seul les WORKOUT permettent d'identifier ce qui a été effectué, ces WORKOUT permettent de retrouver les SESSION en passant par les SELECTION. Et enfin, de ces SESSION, on peut retrouver les SEQUENCE incluant ces SESSION. Mais comme une même SESSION peut être incluse dans plusieurs SEQUENCE on ne sait pas laquelle est concernée. C'est là l'intérêt éventuel de cette association.

Oui mais ce sont bien de SESSION et USER dont on a uniquement besoin au final ?

peut importe le trajet pourvu qu'on arrive à destination

De toute façon je me rends compte que ça n'allait pas car ça ne permet pas d'établir un lien entre USER et SESSION sans passer par SELECTION.

Même réponse que ci-dessus, ce qui compte c'est d'arriver à faire le lien entre USER et SESSION, peu importe qu'il faille passer par SELECTION.

J'en reviens donc à l'idée dune simple association n-n entre USER et SESSION (cf message n°6), en ne comprenant toujours pas le problème que vous ré-évoquez ici.
C'est bien normal qu'une SESSION puisse être exécutée par plusieurs USER, pour autant puisqu'un WORKOUT ne peut avoir été réalisé que par un et un seul USER, on a l'identifiant de USER dans la table WORKOUT donc je ne vois pas comment associer plusieurs USER à un WORKOUT. Je suis vraiment navré de passer à coté de ce problème, pouvez-vous me donner un petit exemple pour illustrer le risque ?

Le souci c'est qu'avec ce schéma on peut créer
US1 en lien avec SN1
US2 en lien avec SN2
WO1 en lien avec US1 et indifféremment SN1 (ce qui est correct) mais aussi avec SN2 (ce qui ne va pas) car rien ne l'interdit
WO2 en lien avec US2 et indifféremment SN2 (ce qui est correct) mais aussi avec SN1 (ce qui ne va pas) idem
Mais il suffit d'ajouter une contrainte d'inclusion comme suit pour éviter ce souci (j'avais vraiment la tête ailleurs pour ne pas vous l'avoir proposé plus tôt )
Pièce jointe 592797
Et dans le script de la table WO ajouter la contrainte que j'ai appelée FK1 :

Code SQL :

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

1
2
3
4
5
6
7
8
9
10
11
12
 
CREATE TABLE WO_workout(
   WO_ident INT IDENTITY,
   WO_date DATE NOT NULL,
   SN_ident INT NOT NULL,
   US_ident INT NOT NULL,
   PRIMARY KEY(WO_ident),
   FOREIGN KEY(SN_ident) REFERENCES SN_session(SN_ident),
   FOREIGN KEY(US_ident) REFERENCES US_user(US_ident) ,
   constraint FK1
         FOREIGN KEY (US_ident, SN_ident) 
         REFERENCES US_SN(US_ident, SN_ident)

Oui ça je ne sais pas comment s'en passer mais ce n'est qu'un dommage collatéral, je me dis que ce n'est pas une information qui sera utilisée dans WORKOUT mais dont sa présence ne pose pas de problème.

Ce n'est pas un "dommage collatéral" c'est un élément indispensable à l'intégrité de la base de données. C'est le principe même de fonctionnement des base de données relationnelles que de propager les Foreign Keys dans les tables coté cardinalité maxi 1.

[Paprick]

Bonsoir Capitaine,

Est-ce que le MCD ci-dessous n'est pas équivalent à ce que tu proposes avec l'inclusion ?

Code :

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

1
2
3
4
5
6
7
8
CREATE TABLE WO_workout(
   WO_ident INT IDENTITY,
   WO_date DATE NOT NULL,
   SN_ident INT NOT NULL,
   US_ident INT NOT NULL,
   PRIMARY KEY(WO_ident),
   FOREIGN KEY(SN_ident, US_ident) REFERENCES US_SN(SN_ident, US_ident)
);

[escartefigue]

Bonjour Paprick

Aussi, ce qui compte c'est de ne pas croiser USER et SESSION sans restriction.

[ZuZu]

Absolument pas : seul les WORKOUT permettent d'identifier ce qui a été effectué, ces WORKOUT permettent de retrouver les SESSION en passant par les SELECTION. Et enfin, de ces SESSION, on peut retrouver les SEQUENCE incluant ces SESSION. Mais comme une même SESSION peut être incluse dans plusieurs SEQUENCE on ne sait pas laquelle est concernée. C'est là l'intérêt éventuel de cette association.

Euh ... pardon si je suis têtu mais je dirais si pour deux raisons. Une séquence peut être abandonnée pour x raisons et recommencée du début (donc on ne va pas rechercher dans l'historique pour forcer l'exécution d'une séquence "en cours" ou d'une session. Et c'est également parce qu'une séquence peut être suivie plusieurs fois qu'il est plus commode de conserver l'information de l'état d'avancement en cours plutôt qu'aller chercher dans l'historique (un coach pourrait peut-être indiquer à un utilisateur de refaire une séquence ou session)

Le souci c'est qu'avec ce schéma on peut créer
US1 en lien avec SN1
US2 en lien avec SN2
WO1 en lien avec US1 et indifféremment SN1 (ce qui est correct) mais aussi avec SN2 (ce qui ne va pas) car rien ne l'interdit
WO2 en lien avec US2 et indifféremment SN2 (ce qui est correct) mais aussi avec SN1 (ce qui ne va pas) idem
Mais il suffit d'ajouter une contrainte d'inclusion comme suit pour éviter ce souci (j'avais vraiment la tête ailleurs pour ne pas vous l'avoir proposé plus tôt )

Ok, mais là où je bloquais c'est que le cas incorrect pour moi ne pourra jamais arriver du fait du fonctionnement du logiciel exploitant la base de donnée, mais je comprends que ça doit être verrouillé au sein de la base.
De la même façon on aurait pû s'en assurer par une procédure stockée ? (ne maîtrisant pas les contraintes c'est ce que j'aurais fait mais c'est inutilement plus lourd)

Alléluia !! Merci infiniment pour ces échanges qui par détours m'ont fait voir d'autres aspects.
Par contre lorsque je mets la contrainte dans looping elle n’apparaît pas dans le script sql, comment je dois faire ?

[ZuZu]

Alors pour moi la proposition de Patrick n'est pas équivalente car elle empêche d'utiliser une session hors "sélection", hors cette sélection est une courte liste de sessions "favorites" pour l'utilisateur. On ne doit pas forcer cette sélection (attribution dans ses "favoris"), il y a bien deux usages distincts possibles, sequence-session->workout (session non attribuée à la liste de "favoris" de l'utilisateur qu'est l'entité SELECTION) et user-session->workout il exécute une session de sa liste de "favoris" hors séquence.

[escartefigue]

Bonjour ZuZu

Ok, mais là où je bloquais c'est que le cas incorrect pour moi ne pourra jamais arriver du fait du fonctionnement du logiciel exploitant la base de donnée, mais je comprends que ça doit être verrouillé au sein de la base.

Tout à fait, aucune application ne peut gérer les accès concurrents, seul le SGBD en a la capacité, d'où la nécessité de le laisser gérer l'intégrité

De la même façon on aurait pu s'en assurer par une procédure stockée ? (ne maîtrisant pas les contraintes c'est ce que j'aurais fait mais c'est inutilement plus lourd)

Les contraintes sont la pour ça, autant les utiliser, d'autant plus que certains SGBD sont capables d'optimiser leur stratégie d'accès en fonction des contraintes (je ne sais pas si c'est le cas de SQLITE). Et surtout, une procédure on n'est pas obligé de l'appeler, alors qu'une contrainte, tant qu'elle est active, elle est incontournable

Alléluia !! Merci infiniment pour ces échanges qui par détours m'ont fait voir d'autres aspects.
Par contre lorsque je mets la contrainte dans looping elle n’apparaît pas dans le script sql, comment je dois faire ?

Le script lié aux contraintes doit être ajouté avec l'outil règle

Alors pour moi la proposition de Patrick n'est pas équivalente car elle empêche d'utiliser une session hors "sélection", hors cette sélection est une courte liste de sessions "favorites" pour l'utilisateur. On ne doit pas forcer cette sélection (attribution dans ses "favoris"), il y a bien deux usages distincts possibles, sequence-session->workout (session non attribuée à la liste de "favoris" de l'utilisateur qu'est l'entité SELECTION) et user-session->workout il exécute une session de sa liste de "favoris" hors séquence.

Paprick n'a repris que le sous-ensemble du MCD que j'avais modélisé dans ma réponse n°33

[ZuZu]

Le script lié aux contraintes doit être ajouté avec l'outil règle

Ok, c'est dommage que ce ne soit pas intégré.
Merci

[escartefigue]

Je fais appel au géniteur pour m'assurer de n'avoir pas loupé un épisode :

Le script lié aux contraintes doit être ajouté avec l'outil règle

Paprick, tu confirmes ?
Il y a eu des échanges sur ce sujet, mais je ne sais plus dans quel fil de discussion