Discussion :

[Bisûnûrs]

Salut,

J'ai une association ternaire qui ressemble à ça :



Donc pour un membre, une thématique et un critère, j'obtiens une valeur. Jusque là, pas de problème particulier.

Cependant, un critère peut aussi être multi-thématique. A ce problème, plusieurs réflexions (souvent mauvaises et toujours venant d'une approche BDD et non MCD) peuvent submerger :

- Mettre la liste des thématiques séparées par une virgule dans un champ (à bannir)
- Mettre l'id thématique à 0 dans la table résultant de l'association pour signifier que l'enregistrement ne fait pas partie d'une thématique particulière (à bannir)
- Mettre autant d'enregistrements qu'il y a de thématiques pour chaque critère multi-thématique (on s'approche de la vérité mais lourd en maintenance et en update)
- Rajouter une association entre MEMBRE et CRITERE (idéal en MCD) comme suit :



Dans ce dernier cas, les requêtes vont être assez chiante à créer. Comment savoir sur quelle table lier pour avoir la valeur de mon critère ?

Qu'en pensez-vous ? Suis-je dans le vrai ? Ai-je loupé quelque chose ?

Merci !

[CinePhil]

Quelle signification donnes-tu à l'association "est composé" ?

Je doute qu'un membre soit composé d'un thème et d'un critère ou qu'un critère soit composé d'un membre et d'un thème.

Je suppose donc que c'est le thème qui est composé d'un membre et d'un critère mais j'ai quand même du mal à comprendre de quoi on parle !

Qu'est-ce qu'un membre ? Un bras, une jambe ? Un adhérent d'une association ? Un inscrit à un groupe de forum ? Un affluent d'un fleuve ?

Ces réflexions m'amènent à penser que les règles de gestion qui conduisent à ton modèle ne sont pas claires où qu'elles ont été mal modélisées.

Reviens donc à l'expression des règles de gestion et recommence la modélisation à partir d'elles.

[Bisûnûrs]

Dans ce contexte, un membre est un utilisateur. Un critère est tout ce qui peut décrire un membre. Sa couleur de cheveux, de ses yeux, sa profession, sa pointure, ou tout ce qu'on veut bien imaginer se référant au membre. On lui offre la possibilité d'évoluer dans une ou plusieurs thématiques. Et la valeur du critère peut être différente selon les thématiques, ou non.

Ex : La couleur des yeux sera multi-thématique. Mais on peut lui laisser le soin de choisir un pseudo différent selon la thématique dans laquelle il va évoluer. Le pseudo devient un critère du membre qui sera unique par thématique.

[CinePhil]

Un critère est tout ce qui peut décrire un membre.

critere -0,n----décrire----0,n- membre

On lui offre la possibilité d'évoluer dans une ou plusieurs thématiques.

membre -0,n----évoluer----0,n- thématique

Et la valeur du critère peut être différente selon les thématiques, ou non.

Ex : La couleur des yeux sera multi-thématique. Mais on peut lui laisser le soin de choisir un pseudo différent selon la thématique dans laquelle il va évoluer. Le pseudo devient un critère du membre qui sera unique par thématique.

Là par contre, je ne comprends plus le rapport avec le schmilblick !

Un exemple peut-être ?

[Bisûnûrs]

Un pseudo par exemple peut être différent selon la thématique.

Code :

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

1
2
3
id_membre | id_critere | id_thematique | valeur
1           1            1               titi
1           1            2               tata

Mais un membre a forcément des critères qui resteront invariants, quelle que soit la thématique. Comme la couleur de ses yeux, ses préférences musicales, etc.

[CinePhil]

Tu as donc d'une part des critères qui décrivent des utilisateurs et d'autre part des critères qui dépendent de thèmes.
critere -0,n----décrire----0,n- membre
|----------0,n----dépendre----0,n- thème

Pour associer un membre à un critère qui dépend d'un thème, afin d'affecter une valeur à cette association, il convient de transformer l'association "dépendre" en entité type associative :
critère -0,n----dépendre----(1,1)- dependance_theme -(1,1)----concerner----0,n- theme
membre -0,n----valoriser----0,n--------------|

Tables qui résultent de tout ça :
membre (mbr_id, [colonnes communes à tous les membres])
critere (crt_id, crt_nom...)
theme (thm_id, thm_nom...)
crt_decrire_mbr (cdm_id_critere, cdm_id_membre, cdm_valeur)
dependance_theme (dth_id_critere, dth_id_theme)
mbr_valoriser_dth (mvd_id_membre, mvd_id_critere, mvd_id_theme, mvd_valeur)

[Bisûnûrs]

Merci ! Mais du coup, la table dependance_theme n'a plus lieu d'être étant totalement englobée dans mbr_valoriser_dth non ?

[CinePhil]

Si tu supprimes dependance_theme, un membre peut valoriser un critere C pour n'importe quel thème, même si ce thème ne comprend pas le critère C.
En la laissant, il ne pourra valoriser que les couples {mvd_id_critere, mvd_id_theme} possibles car c'est ce couple qui sera clé étrangère dans la table et non pas chacune de ces colonnes individuellement.

[Bisûnûrs]

Hum, c'est là où je me suis peut-être mal exprimé. Les critères ne dépendent pas des thèmes. On va partir du postulat que tous les critères se retrouvent dans chaque thème. Ce n'est que la valeur donnée par un membre à un critère qui diffère selon le thème.

[CinePhil]

Donc ça veut dire qu'un même critère peut être valorisé plusieurs fois par un même membre mais pour des thèmes différents ?

Donc la ternaire simple du début convient pour cette valorisation :
membre -0,n----valoriser----0,n- critere
theme -0,n------------|

Mais rien n'empêche d'avoir aussi l'association binaire "décrire" si tu as des critères qui décrivent les membres en dehors de tout thème.

À toi de voir ensuite si les critères de définition sont obligatoirement différents des critères à valoriser et de placer éventuellement une exclusion entre les deux associations qu'il faudra contrôler par un trigger en BDD.

[Bisûnûrs]

Donc ça veut dire qu'un même critère peut être valorisé plusieurs fois par un même membre mais pour des thèmes différents ?

Exactement !

Mais rien n'empêche d'avoir aussi l'association binaire "décrire" si tu as des critères qui décrivent les membres en dehors de tout thème.

C'est ce que je montrais sur ma 2e image en fait (je n'ai jamais réussi à trouver les bons verbes ). On est donc d'accord, c'est la solution idéale au niveau MCD.

Mais au niveau BDD, ça implique de connaitre tous les critères (savoir celui qui est en dehors de tout thème et celui qui ne l'est pas) pour savoir quelle jointure faire.
On me dira que je peux aussi faire une vue, mais on perd énormément en performances ...

[CinePhil]

On me dira que je peux aussi faire une vue, mais on perd énormément en performances ...

Bof ! Ça ne requête que des identifiants donc des entiers indexés et il ne doit pas y avoir des millions de critères et de thèmes quand même !

[Bisûnûrs]

Une dizaine de thèmes pour environ 300 critères ?

La dernière fois que j'avais testé les performances des vues, c'était avec la version 5.1 de MySQL, il y a deux ou trois ans (mais c'était effectivement su des tables avec plusieurs millions d'enregistrement), peut-être que ça s'est amélioré avec la 5.5.

Merci en tout cas pour m'avoir éclairé.

[Richard_35]

Bonjour Bisûnûrs et Philippe,

Je me permets de m'immiscer, Philippe, sur ce sujet très intéressant qui revient souvent qui mériterait, de mon point de vue, un billet quelque part (si j'ai bien tout compris).

Tout d'abord, une petite correction sur ton post initial, Bisûnûrs :

Cependant, un critère peut aussi être multi-thématique.../...

donc, il faudrait basculer l'association entourée de rouge à droite, non ?

Mais bon, c'est un détail.


Sinon, sur le fond, c'est une problématique qui revient souvent dans les association ternaires. En fait, la solution est "d'éclater" l'association en entité. Donc, passer de :

à

De ce fait, les couples Theme_Critere doivent être créés avant, pour être disponibles dans l'association avec Membre.

Toujours, si j'ai bien tout compris...

[CinePhil]

Bel effort et jolis schéma Richard mais tu as un métro de retard !
J'avais proposé le même genre de solution mais Bisunurs a fini par dire ceci :

Hum, c'est là où je me suis peut-être mal exprimé. Les critères ne dépendent pas des thèmes. On va partir du postulat que tous les critères se retrouvent dans chaque thème. Ce n'est que la valeur donnée par un membre à un critère qui diffère selon le thème.

[Bisûnûrs]

Tout d'abord, une petite correction sur ton post initial, Bisûnûrs :
donc, il faudrait basculer l'association entourée de rouge à droite, non ?

Bonjour et merci d'avoir pris le temps d'étudier mon problème !

Effectivement, je me suis mal exprimé depuis le premier post. Au lieu d'utiliser le terme "multi-thématique", j'aurais plutôt dû dire qu'"un critère doit pouvoir s'affranchir l'association d'une thématique".

Même si dans la finalité les termes sont des synonymes (plutôt éloignés), la compréhension conceptuelle en est toute inversée ...

Il parait évident que si un critère était lié à une ou plusieurs thématiques, l'association entre les deux entités était manquante.

[Richard_35]

Bel effort et jolis schéma Richard .../...

==> il faut remercier, RabDev pour JMerise qui est très intuitif (JMerise, pas RabDev...).

.../... mais tu as un métro de retard !

==> ah... ... tu sais, en province...

Hum, c'est là où je me suis peut-être mal exprimé. Les critères ne dépendent pas des thèmes. On va partir du postulat que tous les critères se retrouvent dans chaque thème. Ce n'est que la valeur donnée par un membre à un critère qui diffère selon le thème.

==> hum... un membre donne une valeur (ou pas, donc NULL possible) à un couple {thème, critère}, ce qui est représenté dans le second schéma, non ?



Quoiqu'il en soit, ce sujet est intéressant et l'on a souvent besoin d'éclater une relation ternaire en, un relation binaire, dans un premier temps, puis, dans un second temps, de créer une relation binaire avec la relation binaire ainsi créée (je ne sais pas si je suis bien clair, sur ce coup là...).

[CinePhil]

On va partir du postulat que tous les critères se retrouvent dans chaque thème.

Donc une association binaire entre critère et thème est inutile car on aurait le produit cartésien des critères et des thèmes, ce qui n'apporterait aucune valeur ajoutée.

Je vais aller faire un tour du côté processus pour donner ma compréhension du problème...
Le membre choisit un thème puis la page du thème lui propose d'ajouter des critères pour se définir dans le thème en précisant une valeur pour chaque critère dans ce thème.
Par exemple, complètement fictif, je choisis le thème "Cinéma" et dans ce thème, je souhaite que le critère "pseudo" soit "CinéPhil".
=> Le système ajoute une ligne dans la table résultant de l'association ternaire entre membre, thème et critère portant la donnée "valeur".

Si par contre, comme je l'avais supposé au début, chaque thème ne pouvait proposer au membre qu'une liste précise de critères, il aurait bien fallu établir ces listes dans ce que j'appelle une entité associative pour préciser tous les couples {critère, thème} que le membre peut valoriser, ce qui revient, si j'ai bien compris, à ton schéma ou à celui moins beau que j'avais proposé.

[Bisûnûrs]

un membre donne une valeur (ou pas, donc NULL possible) à un couple {thème, critère}, ce qui est représenté dans le second schéma, non ?

Plus exactement :

Un membre donne une valeur (ou pas, donc absence d'enregistrement) à un couple {thème, critère} ou à un critère seul. Ce qui est représenté dans le second schéma.

on a souvent besoin d'éclater une relation ternaire en, un relation binaire, dans un premier temps, puis, dans un second temps, de créer une relation binaire avec la relation binaire ainsi créée.

Si j'en crois ton schéma et ta phrase, y a déjà eu du raisonnement MLD (MPD) là, avec des clefs primaires, étrangères, donc au delà de l'aspect "entités" du MCD (ou peut-être un mélange des deux).

@CinePhil : Voilà, c'est exactement ça !

[Richard_35]

Hop, hop, hop !...

Un membre donne une valeur (ou pas, donc absence d'enregistrement) à un couple {thème, critère} .../...

==> OK.

.../... ou à un critère seul .../...

==> c'est nouveau dans l'histoire, non ?
Peux-tu donner la valeur des trois champs de la table finale, dans ce cas ?