Dans ce dernier article d'une série en quatre parties, je termine la conception d'une base de données d'enquête en ligne afin d'offrir une flexibilité pour plusieurs enquêtes, la réutilisation des questions, les réponses à choix multiples, l'ordre des questions, les sauts conditionnels dans l'enquête en fonction des réponses, et contrôle de l'accès des utilisateurs aux enquêtes via des groupes de propriétaires d'enquêtes.
Présentation
Dans la conclusion de la partie 3 de cette série d'articles, j'ai mentionné que j'ajouterais des fonctionnalités plus avancées dans cet article. Ces fonctionnalités avancées sont :
- administration des sondages
- rapports et analytique
Pour rappel, voici le modèle après la partie 3 :
Administration
Mon objectif dans l'administration des enquêtes est de permettre à une enquête et à ses informations correspondantes d'être gérées par un groupe. Je vais donc permettre à un utilisateur administratif de définir des groupes d'utilisateurs pouvant maintenir conjointement une enquête en ligne et ses questions. Le propriétaire du groupe peut définir les fonctions que les autres utilisateurs du groupe peuvent exécuter ; par exemple, Jeff peut modifier et supprimer des sondages et des questions, mais Joe peut uniquement afficher des sondages et des questions, mais pas les modifier ni les supprimer.
Une chose que vous remarquerez peut-être est que les utilisateurs sont distincts des répondants à l'enquête. Bien entendu, un utilisateur peut également répondre à une enquête, mais j'aimerais les séparer afin de pouvoir exiger moins d'informations d'un répondant que d'un utilisateur (par exemple, j'ai supprimé le champ du mot de passe d'un répondant afin qu'il est plus facile pour les gens de répondre à l'enquête sans créer de connexion/compte).
Fondamentalement, pour cette administration, je vais créer des tableaux pour les groupes et les utilisateurs, ainsi que les rôles et les autorisations ou actions correspondantes autorisées. Cela permet une flexibilité plutôt qu'un lien codé en dur entre les rôles et les actions autorisées par chaque rôle. Bien sûr, l'application correspondante doit être construite pour comprendre quelle fonctionnalité est autorisée par chaque autorisation et doit être adaptée lorsqu'une nouvelle fonctionnalité est ajoutée, mais la conception de la base de données n'aura pas besoin d'être modifiée lorsque la fonctionnalité est ajoutée - de nouvelles lignes seront ajoutées au tableau reliant les rôles aux autorisations.
Vous remarquerez peut-être aussi que j'ai utilisé une longueur impaire pour le email colonne sur l'user et respondent tables et une valeur impaire pour l'ip_address colonne pour le respondent; 254 est la longueur maximale d'une adresse e-mail selon les définitions RFC, tandis que 45 est la longueur maximale d'une adresse IPv6 (avec tunnel IPv4).
De plus, je vais ajouter un lien du group tableau à l'survey table dont les liens vont vers toutes les tables associées (question_order , survey_response , conditional_order , question_type , response_choice ). De cette façon, lorsque le groupe est supprimé, je peux avertir le propriétaire du groupe que toutes les informations correspondantes seront supprimées.
Je préfère cette approche consistant à lier les données de la table à autre chose que l'utilisateur spécifique plutôt que de ne pas lier les données à quoi que ce soit. Si nous n'avons pas lié les données à quoi que ce soit (ni groupe ni utilisateur) comme je semblais le faire dans les parties précédentes de cette série d'articles, alors nous aurons le défi de "nettoyer" les données obsolètes lorsqu'un utilisateur est supprimé de l'enquête en ligne. application. En le liant au concept plus abstrait de « groupe », il devient alors possible pour le propriétaire de réattribuer la propriété du groupe et de toutes les données correspondantes (enquêtes, questions, réponses, etc.) à un autre membre du groupe si nécessaire.
Conception formelle
Ensuite, nous étendons l'ERD qui a été créé dans les autres parties de cette série d'articles.
J'ai coloré les tableaux créés dans l'article de la partie 1 en jaune, coloré les tableaux ajoutés dans la partie 2 en orange, coloré les tableaux ajoutés dans la partie 3 en vert et les tableaux nouvellement ajoutés en bleu clair afin qu'il soit plus facile de voir les compléments. La couleur n'a pas été ajoutée aux colonnes et aux clés étrangères qui ont été ajoutées dans cet article final. Vous devrez donc comparer le modèle actuel au précédent de la partie 3 pour voir les différences.
Rapports et analyses
Nous avons suffisamment d'informations pouvant être extraites des tableaux pour produire plusieurs rapports.
Par exemple, quelles questions ont été répondues d'une manière particulière ("dans l'enquête 7, combien de fois les répondants ont-ils répondu "Oui" à la question 10 ?"). Ce niveau d'information convient probablement aux rapports de base sur les réponses aux enquêtes.
Nous pouvons également extraire le temps qu'il a fallu aux répondants pour répondre à une enquête particulière ("sur l'enquête 5, le temps moyen consacré à l'enquête était de 13 minutes"); encore une fois, cela peut être une information utile pour que les propriétaires d'une enquête puissent ajuster les questions de l'enquête afin qu'elles ne nécessitent pas plus de temps que ce qu'un répondant typique est prêt à dépenser ou ce que l'enquêteur a « promis » aux répondants (par exemple, « cette enquête devrait prendre entre 5 et 10 minutes »). Je sais que lorsque quelqu'un me dit que je devrais avoir terminé en moins de 10 minutes et que je suis encore en train de répondre aux questions 15 minutes plus tard, je me mets en colère et je ne suis généralement pas disposé à répondre à une autre enquête de sa part.
Sur la base des adresses IP des répondants, nous pourrions effectuer une recherche inversée pour avoir une idée approximative d'où viennent les répondants ou du moins d'où leur adresse IP semble provenir lorsqu'ils ont répondu. Sachez que ces informations ne sont pas entièrement fiables car les gens peuvent se connecter via des VPN ou d'autres mécanismes qui dissocient leur adresse IP de leur emplacement physique.
Nous pouvons même extraire comment les questions sont répondues par les premiers répondants par rapport à la façon dont les derniers répondants y ont répondu. Cela pourrait présenter un angle intéressant pour votre enquête - " par exemple, les personnes enthousiastes qui ont d'abord répondu à l'enquête ont-elles répondu différemment des personnes qui n'étaient pas aussi enthousiastes et ont répondu à l'enquête plus tard ?
À ce stade, je pense que ces rapports seront suffisants et que des analyses plus avancées ne sont pas nécessaires, car l'information la plus importante est évidemment le rapport de base des réponses données à chaque question d'une enquête. Si vous avez besoin d'analyses plus avancées, réfléchissez à vos besoins et à la manière dont les données existantes ou les nouvelles structures peuvent prendre en charge ces analyses.
Conclusion
Et voila. Je ne prétendrai pas que c'est le design de la base de sondage en ligne idéale, mais cela répondra à mes besoins en termes de flexibilité :sondages multiples, réutilisation des questions, réponses à choix multiples, ordre des questions, sauts conditionnels dans le sondage en fonction de les réponses et le contrôle de l'accès des utilisateurs aux enquêtes via des groupes de propriétaires d'enquêtes.
Comme je l'ai fait dans chaque partie précédente de cette série d'articles, je soulignerai que vous pourriez avoir d'autres exigences. Identifiez vos besoins et mettez en œuvre ou adaptez ce dont vous avez besoin. Je crois fermement en la réutilisation et non en réinventant la roue.
Si vous souhaitez que nous reconcevions ou développions ce modèle en fonction des besoins de votre application, faites-le nous savoir. Nous pouvons vous aider.
Un modèle de base de données pour une enquête en ligne – € " toute la série
 Partie 1 | Partie 2 |  Partie 3 |  Partie 4 |
