Discussion :

[Julioun]

Bonjour,

Je suis entrain d'essayer de modéliser une nouvelle problématique que je rencontre actuellement.

J'ai une table de fait qui permet de gérer des commandes, quand les commandes sont passées le client effectue une ou plusieurs déclarations :

• Question : Ma commande est bleue / Réponse : OUI
• Question : Ma commande est neuve / Réponse : OUI

Avant de valider la commande, on vérifie cette déclaration

• Question : Ma commande est bleue / Contrôlée : OUI
• Question : Ma commande est neuve / Contrôle : NON

On constate donc sur cette commande un écart sur la question "Ma commande est neuve".

Dans un premier temps, j'ai fusionner les deux tables de questions et de réponses dans une seule dimension.

Maintenant je dois intégrer l'analyse des résultat sur ma table de fait. Le problème est que l'on peut avoir plusieurs questions en fonction du type de commandes et que les questions peuvent évoluer rapidement.

J'avais donc imaginé ajouter des clés sur ma table de fait pour l'ensemble des questions :

• ma_commande_neuve_déclaré_id
• ma_commande_est_bleue_déclaré_id
• ma_commande_neuve_vérification_id
• ma_commande_est_bleue_vérification_id

Cette solution me semble pas super car elle va multiplier le nombre de colonnes sur ma table de fait. De plus, comment gérer automatiquement l'ajout d'une nouvelle question ?

j'avais également penser à faire une dimension qui va regrouper l'ensemble des valeurs questions / réponses possibles :

id / test 1 / valeur / test 2 / valeur / test 3 / valeur / etc

Le problème reste en cas de changement, il faudra recalculer l'ensemble des valeurs possibles.

Pour moi, la solution la plus simple serait de pouvoir avoir toutes les déclarations dans une dimension (questions_déclarés_id sur la table de fait et questions_vérification_id) voir de créer une autre table de fait qui regroupe les résultats des tests ?

Quelque chose du genre :
Table de fait (clé groupe de contrôlé) -> Table passerelle (Clé commande / Clé test_déclaré / Clé test_contrôlé / Date Début / Date Fin / Actif (si jamais une autre vérification remplace la première) -> Dimension avec les valeurs de tests / résultats

Si cette solution est la plus viable, cela ne pose pas de problème faire une jointure sur la table de fait principale et la table passerelle pour obtenir les résultats ?

L'objectif final est de pouvoir voir pour chaque commande les questions qui comportent le plus d'erreur tout en gérant une problématique d'évolution des questions fréquente.

Si vous avez des idées la dessus, je vous en remercie grandement.

Merci

[doc malkovich]

Bonjour,

Pour moi au vu de l'exemple donné je simplifierai le modéle avec :

• une dimension question -- clé qid
• une table de faits réponses -- clé client, qid, date et valeurs réponse, contrôle

Les valeurs étant OUI ou NON.

-> Dimension avec les valeurs de tests / résultats

Les résultats ne devraient-ils pas être dans la table de faits ?

[Julioun]

Merci, cette solution me semble bien également.
Dans la dimension se trouve les questions et les réponses possibles.
Id : 1
Question : Couleur bleue
Réponse : oui

Id : 2
Question : Couleur bleue
Réponse : non

Et dans table de fait je met l'identifiant correspondant au choix du client. C'est peut-être mieux de faire une dimension avec les questions et une dimension avec les réponses?

Par contre, je me pose toujours la question niveau requête (une requête sql toute bête dans un premier temps) si je fais deux requêtes distinctes ou si je fais une jointure entre les deux tables de faits?

[doc malkovich]

Tu as plusieurs types de réponses possibles, autres que OUI et NON ?
Pour ma part je ferais une dimension sur les questions.

si je fais deux requêtes distinctes ou si je fais une jointure entre les deux tables de faits?

Pourquoi tu parles de deux tables de fait ? Tu peux n'en faire qu'une.

[Julioun]

Pour les réponses, tu peux avoir autres choses que OUI et NON mais généralement pas plus de 4 réponses par questions. J'avais fusionné pour éviter de passer en flocon de neige.

En existant, j'ai une table de fait commandes qui pour chaque commande regroupe plusieurs dimensions (client, vendeur, etc.) et différents indicateurs.

Sur cette existant, je dois intégrer la gestion des questions.

La finalité est de pouvoir sortir pour chaque commande les indicateurs actuels + la / les réponses aux questions.

Donc, je pensais garder la table de fait existante + ajouter une table de fait sur les réponses. Ou alors, tu voudrais que je créé 3 lignes de commandes (pour 3 questions) avec une réponse à chaque questions ?

Merci pour ton aide.

[doc malkovich]

Je suis d'accord avec toi pour isoler les questions dans une table de faits.

Quelque chose du genre :
Table de fait (clé groupe de contrôlé) -> Table passerelle (Clé commande / Clé test_déclaré / Clé test_contrôlé / Date Début / Date Fin / Actif (si jamais une autre vérification remplace la première) -> Dimension avec les valeurs de tests / résultats

Je voyais plutôt :
Table de dimension question ( clé question)
Table de dimension réponse ( clé réponse )
-> table de dimension question réponse ( clé question, clé réponse )
---> table de fait ( Clé commande / Clé question / Clé réponse / Clé contrôlé / Date Début / Date Fin / Actif (si jamais une autre vérification remplace la première)

En gros c'est la même question pour la réponse que le contrôle, pourquoi un avoir une clé déclaré et une clé controlé qui peuvent semer le doute ?

[Julioun]

Oui c'est la même question, on peut seulement avoir une clé question, clé déclaration, clé réponse.

J'ai donc bien une table de fait avec les commandes (celle d'origine si on peut dire) + une table de fait ou j'isole les questions / réponses ?

Si c'est bien ça, niveau requête SQL pour obtenir l'ensemble des informations de la commande + les questions, est-ce que je peux faire une jointure sur la clé commande entre les deux tables pour obtenir l'ensemble des infos ?

J'ai cru voir qu'il était pas conseillé de faire des jointures entre les tables de faits ?

Merci beaucoup pour ton aide !

[doc malkovich]

En fait tu devrais avoir une table de dimension commande avec peu d'informations. Mais comme les commandes bougent pas mal il est plus judicieux de faire une table de faits uniquement.

Je ne sais plus le nom qu'on donne à ce type de table mais ça se fait. De toute manière si tu veux faire autrement et juste faire une table tu risques de faire une usine à gaz.

[Julioun]

OK ça marche ! Merci pour ton aide