Database
 sql >> Base de données >  >> RDS >> Database

Un modèle de base de données pour une enquête en ligne. Partie 3

Dans la conclusion de la partie 2 de cette série d'articles, j'ai mentionné que j'ajouterais des fonctionnalités plus avancées, telles que :

  • Ordre conditionnel des questions dans une enquête ou, en d'autres termes, la possibilité d'un chemin conditionnel à travers l'enquête
  • Administration de l'enquête
  • Rapports et analytique

Dans ce troisième article lié à une enquête en ligne , je vais étendre la fonctionnalité pour prendre en charge le classement conditionnel des questions.

À l'avenir, nous pourrions ajouter des questions nécessitant une réponse cotée. Par exemple :"A quel point aimez-vous la conception de la base de données, notez entre 1 et 100 (1 indiquant que vous l'aimez très peu et 100 indiquant que vous l'aimez énormément) ?"

Chemin conditionnel

Nous souhaitons définir certaines conditions sur les questions présentées à l'utilisateur en fonction des réponses de l'utilisateur. Par exemple, si la réponse à la question 4 est "oui", alors nous posons la question 5 et sautons la question 6 ; tandis que si la réponse à la question 4 est "non", nous sautons la question 5 et posons la question 6).

Nous devons donc définir quelles questions sont conditionnelles et comment "sauter" des questions en fonction de la réponse à une question.

Dans un premier temps, pour garder le chemin conditionnel simple, nous n'autoriserons pas les conditions basées sur des questions à choix multiples, mais uniquement pour les questions polaires (oui ou non). La conception peut être étendue pour prendre en charge les chemins conditionnels basés sur des questions à choix multiples, mais c'est plus complexe et je veux commencer simple.

Il est important que l'application vérifie ce flux pour chaque question, car la réponse à une question précédente peut décider du flux pour la question actuelle (pour ignorer une question basée sur une réponse précédente).

Administration et rapports

Pour l'instant, nous n'ajouterons pas d'administrateurs des sondages en ligne, mais gardez cela pour la prochaine extension.

Il faudra des rapports et des analyses ; cependant, je vais garder cela pour la prochaine version car je veux d'abord stocker certaines informations pour effectuer des analyses plus tard.

Entités et relations

Pour le chemin conditionnel à travers l'enquête, je vais étendre la question_order qui est défini pour chaque enquête et relie l'enquête aux questions. Comme mentionné, pour l'instant, le saut conditionnel ne sera basé que sur des questions polaires, je peux donc définir la prochaine question à afficher en cas de réponse positive et la prochaine question à afficher en cas de réponse négative.

Conception formelle

Étendons l'ERD qui a été créé dans la partie 1 de cette série d'articles.

Je vais ajouter conditional_order lié à question_order; comme je l'ai mentionné plus tôt, je ne soutiendrai que l'ordre conditionnel via l'enquête basée sur des questions polaires. Maintenant, il y a plusieurs façons de mettre cela en œuvre. Mes besoins sont simples, je vais donc choisir une implémentation simple. Si vos besoins sont plus complexes, vous aurez besoin d'une solution plus complexe.

Ce serait bien de simplement définir la "prochaine" question à poser en fonction de la réponse à la question actuelle, mais cela ne nous permettra pas de sauter une question plus tard dans l'enquête, nous avons donc besoin de plus de flexibilité.

Une manière consiste à spécifier le nombre de questions à avancer en cas de réponse positive et le nombre à avancer en cas de réponse négative ; cependant, je dois préciser à quelle question le saut s'applique et la réponse de quelle question à utiliser. Donc, pour étayer mon exemple :si la réponse à la question 4 est "oui", alors nous posons la question 5 et sautons la question 6, tandis que si la réponse à la question 4 est "non", alors nous sautons la question 5 et posons la question 6 -- cela nécessite deux entrées qui vérifient toutes deux la réponse à la question 4, une qui avance d'une question (comme d'habitude) et une qui saute deux questions (pour sauter une question), et l'autre condition à vérifier après avoir répondu à la question 5 qui saute la question 6.

  +-------------------+----------------------+------------------------+------------------------+ 
  | question_order_id | response_to_question | positive_response_jump | negative_response_jump |
  +-------------------+----------------------+------------------------+------------------------+
  | 4                 | 4                    | 1                      | 2                      |
  +-------------------+----------------------+------------------------+------------------------+
  | 5                 | 4                    | 1                      | null                   |
  +-------------------+----------------------+------------------------+------------------------+

Une alternative consiste à spécifier l'identifiant de la question suivante à laquelle l'enquête doit sauter en cas de réponse particulière :question suivante en cas de réponse positive et question suivante en cas de réponse négative réponse. Cette approche a des avantages et des inconvénients. Cela permettrait à des boucles de se produire, qu'un administrateur pourrait ne pas remarquer. Cependant, les boucles peuvent être un effet souhaité afin que vous puissiez demander à la dernière question au répondant s'il a terminé l'enquête et s'il répond « non », puis revenir à la première question. De plus, les questions auxquelles sauter en cas de réponse positive ou négative peuvent être configurées comme des clés étrangères à l'ordre des questions spécifiées pour l'enquête afin que nous sachions avec certitude que la question spécifiée est définie dans l'enquête. Il s'agit d'une belle logique de vérification mise en œuvre via l'intégrité référentielle. Je pense que c'est probablement la meilleure solution, c'est donc ce que vous trouverez dans l'ERD.

Donc, pour étayer mon exemple :si la réponse à la question 4 est "oui", alors nous posons la question 5 et sautons la question 6, tandis que si la réponse à la question 4 est "non", alors nous sautons la question 5 et posons la question 6.

Comme mentionné, nous avons deux lignes :

Survey #1, question #4, response to question #4, positive response: next question order id = 5, negative response: next question order id = 6.

Survey #1, question #5, response to question #4, positive response: next question order id = 7. We will never get to question #5 if the response to question #4 was negative, so we always skip question #6 after asking question #5.

  +--------+----------+----------------------+-------------------------------+-------------------------------+
  | survey | question | response_to_question | positive_response_question_id | negative_response_question_id |
  +--------+----------+----------------------+-------------------------------+-------------------------------+
  | 1      | 4        | 4                    | 5                             | 6                             |
  +--------+----------+----------------------+-------------------------------+-------------------------------+
  |        | 5        | 4                    | 7                             | null                          |
  +--------+----------+----------------------+-------------------------------+-------------------------------+

Lors de la configuration de la condition, nous utiliserons une clé étrangère (non obligatoire) pour nous assurer que la question suivante existe. Une valeur nulle est utilisée pour un chemin qui n'est pas possible ou, si aucune question suivante n'est spécifiée, pour mettre fin conditionnellement à l'enquête.




J'ai colorié les tableaux qui ont été créés dans la Part 1 de la série d'articles en  jaune , les tableaux ajoutés dans la partie 2 en  orange , et le tableau nouvellement ajouté en  vert  afin qu'il soit plus facile de voir les ajouts.

Conclusion

Aucune des solutions décrites pour gérer les étapes conditionnelles via une enquête n'est le système ultime basé sur des règles, mais l'un de mes objectifs est de garder les choses simples et directes. Permettre la flexibilité sans écraser les choses dans la complexité. Et, je vais me répéter, vous pourriez avoir d'autres exigences. Identifiez vos besoins; mettre en œuvre ou adapter ce dont vous avez besoin. Je crois fermement en la réutilisation et non en réinventant la roue.

Nous avons maintenant commencé à mettre en œuvre les améliorations décrites dans les parties 1 et 2 de cette série d'articles.

Dans les prochains articles, j'ajouterai la prise en charge de ces fonctionnalités :

  • Administration des sondages
  • Rapports et analyses