Discussion :

[tiboleo]

Bonjour,

J'aurais souhaité votre avis sur un modèle de conception.
Je développe un module d'évaluation (exemple : évaluer des maisons suivant des critères)
Chaque critère possède une "note" pour, au final, pouvoir évaluer la maison (= somme des notes des critères choisis par l'utilisateurs)

J'ai une lise de 200 critères > table CRITERE (ID_CRITERE, LIBELLE_CRITERE, NOTE, ...)

Je pense créer une table EVALUATION pour mémoriser les évaluations des personnes.
Naturellement, j'ai donc aussi une table PERSONNE.

Mon problème : comment, mémoriser les critères choisis par un utilisateur lors d'une évaluation (l'utilisateur doit cocher ou non une case pour chaque critère) ?

Au départ, je pensais rajouter à ma table EVALUATION autant de champs que j'ai de critères mais ça risque d'être un peu lourd.

Faire une table d'association RESULTAT (#ID_EVALUATION, #ID_CRITERE, valeur) ne me plaît pas non plus car 1 seule évaluation produirait déjà 200 lignes dans cette table et je vais me retrouver avec une table trop volumineuse.

Quel est votre avis sur la question ?
Merci beaucoup !

T.

[CinePhil]

Chaque critère possède une "note"

La note n'est-elle pas donnée plutôt lors de l'évaluation ?

J'ai une lise de 200 critères > table CRITERE (ID_CRITERE, LIBELLE_CRITERE, NOTE, ...)

Conformément à ce que j'ai dit ci-dessus, je n'y mettrais pas la note.

Mon problème : comment, mémoriser les critères choisis par un utilisateur lors d'une évaluation (l'utilisateur doit cocher ou non une case pour chaque critère) ?

Au départ, je pensais rajouter à ma table EVALUATION autant de champs que j'ai de critères mais ça risque d'être un peu lourd.

Effectivement, çà risque de devenir trop lourd.
Surtout que les 200 critères en seront peut-être pas évalués à chaque fois donc beaucoup de NULL.

Faire une table d'association RESULTAT (#ID_EVALUATION, #ID_CRITERE, valeur) ne me plaît pas non plus car 1 seule évaluation produirait déjà 200 lignes dans cette table et je vais me retrouver avec une table trop volumineuse.

C'est pourtant la bonne solution !

Mais que contient la table EVALUATION ?

Revenons au MCD, en prenant le cas de l'évaluation d'une maison...

Règle de gestion :
Une personne peut évaluer des maisons et une maison peut être évaluée par plusieurs personnes.

MCD :
Personne -0,n----Evaluer----0,n- Maison

Règle de gestion :
Une évaluation peut contenir des critères et un critère peut être contenu dans une évalutation.

MCD :
On transforme l'association Evaluer du précédent MCD en Entité Evaluation et on se sert de cette nouvelle entité pour l'associer aux critères
Personne -0,n----Effectuer----1,1- Evaluation -1,1----Concerner----0,n- Maison
Critere -0,n----Contenir----0,n-------------|

Les tables :
Personne (p_id, p_nom...)
Maison (m_id, m_adresse...)
Critere (c_id, c_libelle...)
Evaluation (e_id, e_id_personne, e_id_maison, e_date...)
Critere_Evaluation (ce_id_critere, ce_id_evaluation, ce_note)

A noter que si une personne ne peut évaluer qu'une seule fois une maison, il faut une contrainte d'unicité sur le couple (e_id_personne, e_id_maison).

[tiboleo]

Merci de ce retour.

Alors si, je confirme, chaque critère propose sa propre note (ou indice) et la note de l'évaluation est la somme de ces indices.
Pourquoi ? Car chaque critère n'a pas la même importance et il s'agit donc d'une pondération.

Exemple, supposons que l'on évalue la qualité énergétique d'un logement, le critère "double vitrage" aura plus de poids que le critère "cuisine équipée".

Quant à la table EVALUATION, elle devra contenir minimalement :

• la note (stockée et non recalculée à la volée)
• la date d'évaluation
• Un ensemble de critères non évaluables : Pays/ville/Région de l'habitat, etc... > je ne crée pas une table HABITAT
• un commentaire
• FK_PERSONNE > une évaluation est réalisée par 1 personne (peut évaluer plusieurs maisons)

Voila.
Tout mon problème réside dans le stockage de la saisie de l'utilisateur.
La table RESULTAT va être rapidement surchargée.

Alternative : stocker comme on peut être amené à le faire parfois dans un datawarehouse.
Ajouter un champ "texte" dans la table EVALUATION qui aurait comme format :
id_critere_renseigné1;valeur1;id_critere_renseigné2;valeur2;...

En mode "visualisation" de l'évaluation, un travail sur la chaîne permettra de restituer le résultat.

Quel est votre avis ? Et merci encore pour votre aide !!!
T.

[CinePhil]

Alors si, je confirme, chaque critère propose sa propre note (ou indice) et la note de l'évaluation est la somme de ces indices.
Pourquoi ? Car chaque critère n'a pas la même importance et il s'agit donc d'une pondération.

OK. J'avais soupçonné un truc dans le genre coef de pondération du critère.

Quant à la table EVALUATION, elle devra contenir minimalement :

• la note (stockée et non recalculée à la volée)

Je suppose qu'il s'agit ici de la note globale qui résulte de l'évaluation ?

Tout mon problème réside dans le stockage de la saisie de l'utilisateur.
La table RESULTAT va être rapidement surchargée.

Je reprends la structure de la table que j'ai suggérée :

Critere_Evaluation (ce_id_critere, ce_id_evaluation, ce_note)

Ces trois colonnes seront de type entier, donc codé sur 4 octets, voire même moins si des types SMALLINT et TINYINT sont disponibles dans le SGBD.

Pour une évaluation de 200 critères, cela occupera donc 200 x 3 colonnes x 4 octets = 2400 octets.
Dans 1Mo, on peut faire 436 évaluations (sans tenir compte de la place nécessitée par les index mais ce n'est pas énorme non plus. Ce qui fera 436 x 200 lignes = 87 200 lignes dans la table. C'est encore très facilement traitable par tout SGBD digne de ce nom.
Dans 1Go, on peut faire 447 392 évaluations. Ce qui fera 89 478 400 lignes. J'ai travaillé sans problème avec des tables de plus de 60 millions de lignes donc c'est encore faisable.

Alternative : stocker comme on peut être amené à le faire parfois dans un datawarehouse.
Ajouter un champ "texte" dans la table EVALUATION qui aurait comme format :
id_critere_renseigné1;valeur1;id_critere_renseigné2;valeur2;...

Une colonne de type texte ne peut pas être indexée.
La longueur de chaque ligne va être beaucoup plus importante.
Il faudra extraire la ligne puis faire un traitement sur le contenu de la colonne texte avec le langage de programmation (à coup d'explode en PHP par exemple).
C'est beaucoup plus lourd et j'ai constaté que ça peut être beaucoup moins performant.
A l'INRA, je travaillais sur une application qui permettait de faire des études statistiques et d'en représenter les résultats sur la carte de France. Les paramètres de chaque étude (chaque indicateur) étaient stockés dans une colonne concaténée comme celle que tu envisages de faire.
Pour afficher toutes les sources de données utilisées par tous les indicateurs d'un projet, ça prenait plusieurs secondes au premier appel. Après ma renormalisation de la base de données et la modification des programmes en conséquence, l'affichage était quasi instantanné.

Stocker de multiples données concaténées dans une colonne est une mauvaise idée qui dénormalise la BDD et peut nuire gravement aux performances.

D'une manière générale, toujours commencer avec une BDD normalisée, et n'envisager la dénormalisation qu'après un monitoring sérieux et après avoir épuisé toutes les autres solutions d'optimisation (indexage, partitionnement, amélioration des requêtes...)

[tiboleo]

Explications convaincantes.
Pour info, cette application s'appuiera sur SqlServer 2008.
Merci beaucoup,
T.