Dans la partie 1 de cette série d'articles, nous avons discuté d'une conception de base pour une enquête en ligne. Dans la conclusion de cet article, j'ai mentionné que la partie 2 couvrirait des fonctionnalités plus avancées pour notre enquête, telles que :
- Différents types de questions telles que les questions à choix multiples
- Ordre conditionnel des questions dans une enquête ou, en d'autres termes, la possibilité d'un chemin conditionnel à travers l'enquête
- Administration des sondages
- Rapports et analytique
Commençons par étendre la fonctionnalité pour prendre en charge différents types de questions.
Types de questions
Dans la partie 1 de cette série d'articles, nous n'utilisions que des questions ouvertes composées d'une question et d'une réponse. Dans cet article, nous définirons différents types de questions telles que les questions polaires (oui-non) et questions à choix multiples . Chaque question sera associée à un type. Pour les questions polaires, nous n'autoriserons que oui/non comme réponse, mais, à l'avenir, nous pourrions autoriser des variations comme vrai/faux. Les questions qui ne sont pas ouvertes auront des réponses possibles parmi lesquelles le répondant pourra choisir.
À l'avenir, nous ajouterons des questions nécessitant une réponse cotée. Par exemple, « A quel point aimez-vous la conception de bases de données ; note entre 1 et 100 (1 indiquant que vous l'aimez très peu et 100 indiquant que vous l'aimez énormément) ? »
Entités et relations
Pour les différents types de questions de l'enquête, j'étendrai la zone "questions" avec des types et des choix de réponses.
Idéalement, je voudrais créer une clé étrangère entre les réponses réelles et les réponses possibles pour les questions à choix multiples (response_choice) pour assurer l'intégrité des données. Cela fonctionnerait si toutes les questions avaient des choix de réponse et si les questions ouvertes n'étaient pas autorisées. Comme j'ai besoin de prendre en charge les questions ouvertes, je devrai assurer l'intégrité des réponses dans le code de l'application.
Conception formelle
Nous devons étendre l'ERD qui a été créé dans la partie 1 de cette série d'articles. Comme précédemment, j'utiliserai Vertabelo, un modélisateur de base de données en ligne. Si vous n'avez pas encore de compte Vertabelo, vous pouvez vous inscrire pour un essai gratuit ici.
Je ferai un commentaire; vous constaterez que j'utilise généralement des nombres ronds comme 100 ou 1000 pour définir la longueur des champs varchar; Je ne suggère pas que ce sont nécessairement la taille appropriée, mais j'utilise plutôt cela comme un raccourci au lieu de laisser la longueur indéfinie. Lorsque vous utilisez ce modèle, veuillez ajuster les longueurs en fonction de vos besoins particuliers. Par exemple, autoriserez-vous un répondant à saisir une réponse très, très longue à une question ouverte – ou les limiterez-vous à, disons, 1 000 caractères ? Cela peut dépendre de l'application que vous construisez pour utiliser la base de données, car elle peut avoir des limites sur la longueur des champs.
J'ajoute une table question_type liée à la question :celles-ci pourraient avoir un nom "ouvert", "oui-non", "choix multiples" et, à l'avenir, "évaluation". Pour les questions à choix multiples, chaque question aurait des choix de réponse parmi lesquels choisir.
Vous pouvez même l'utiliser pour mettre en œuvre des questions polaires, mais je pense que c'est exagéré. Une autre solution serait de lier response_choice à question_type, de sorte que la ligne question_type "yes-no" soit liée aux lignes response_choice "Oui" et "Non", mais encore une fois, je ne pense pas que ce soit nécessaire - mais vous pourriez si vous voulez des possibilités multilingues. Vous incluez alors un champ pour la langue du répondant dans la table response_choice ou gérez l'internationalisation sur l'interface utilisateur.
J'ai colorié les tableaux créés dans la partie 1 en jaune et les tableaux nouvellement ajoutés en orange afin qu'il soit plus facile de voir les ajouts.
Conclusion
Nous avons maintenant commencé à implémenter les améliorations qui ont été discutées dans la partie 1 de cette série d'articles.
Dans le prochain article, j'ajouterai plus de support pour les fonctionnalités suivantes :
- Ordre conditionnel des questions dans une enquête
- Administration des sondages
- Rapports et analyses
