Na parte 1 desta série de artigos, discutimos um projeto básico para uma pesquisa online. Na conclusão desse artigo, mencionei que a parte 2 cobriria recursos mais avançados para nossa pesquisa, como:
- Diferentes tipos de perguntas, como perguntas de múltipla escolha
- Ordem condicional das perguntas em uma pesquisa ou, em outras palavras, a possibilidade de um caminho condicional pela pesquisa
- Administração das pesquisas
- Relatórios e análise
Vamos começar estendendo a funcionalidade para oferecer suporte a diferentes tipos de perguntas.
Tipos de perguntas
Na parte 1 desta série de artigos, estávamos usando apenas perguntas abertas que consistiam em uma pergunta e uma resposta. Neste artigo, definiremos diferentes tipos de perguntas, como perguntas polares (sim-não) e perguntas de múltipla escolha . Cada pergunta será associada a um tipo. Para perguntas polares, permitiremos apenas sim/não como resposta, mas, no futuro, poderemos permitir variações como verdadeiro/falso. As perguntas que não são abertas terão respostas possíveis entre as quais o respondente pode escolher.
No futuro, adicionaremos perguntas que exigem uma resposta classificada. Por exemplo, “O quanto você gosta de design de banco de dados; nota entre 1 e 100 (com 1 indicando que você gosta muito pouco e 100 indicando que você gosta imensamente)?”
Entidades e Relacionamentos
Para os diferentes tipos de perguntas da pesquisa, estenderei a área de “perguntas” com tipos e opções de resposta.
Idealmente, eu gostaria de fazer uma chave estrangeira entre as respostas reais e as respostas possíveis para perguntas de múltipla escolha (response_choice) para garantir a integridade dos dados. Isso funcionaria se todas as perguntas tivessem opções de resposta e perguntas abertas não fossem permitidas. Como preciso dar suporte a perguntas abertas, terei que garantir a integridade das respostas no código do aplicativo.
Design formal
Precisamos estender o ERD que foi criado na parte 1 desta série de artigos. Como antes, usarei o Vertabelo, um modelador de banco de dados online. Se ainda não tem uma conta Vertabelo, pode registar-se para uma avaliação gratuita aqui.
Vou fazer um comentário; você descobrirá que geralmente uso números redondos como 100 ou 1000 para definir o comprimento dos campos varchar; Não estou sugerindo que estes sejam necessariamente o tamanho apropriado, mas uso isso como uma abreviação em vez de deixar o comprimento indefinido. Quando você estiver usando este modelo, ajuste os comprimentos para suas necessidades específicas. Por exemplo, você permitirá que um respondente digite uma resposta muito, muito longa para uma pergunta aberta – ou você os limitará a, digamos, 1.000 caracteres? Isso pode depender do aplicativo que você está construindo para usar o banco de dados, pois pode ter limitações nos comprimentos dos campos.
Eu adiciono uma tabela question_type vinculada à pergunta:elas podem ter um nome “aberto”, “sim-não”, “múltipla escolha” e, no futuro, “classificação”. Para perguntas de múltipla escolha, cada pergunta teria respostas_escolhas a serem escolhidas.
Você pode até usar isso para implementar perguntas polares, mas acho que isso é um exagero. Outra solução seria vincular response_choice a question_type, para que a linha question_type “yes-no” fosse vinculada às linhas response_choice “Yes” e “No”, mas, novamente, não acho que isso seja necessário - mas você poderia se você quer possibilidades multilíngues. Você então incluiria um campo para o idioma do respondente na tabela response_choice ou gerenciaria a internacionalização na interface do usuário.
Eu colori as tabelas criadas na parte 1 em amarelo e as tabelas recém-adicionadas em laranja para que seja mais fácil ver as adições.
Conclusão
Agora começamos a implementar as melhorias discutidas na parte 1 desta série de artigos.
No próximo artigo, adicionarei mais suporte para os seguintes recursos:
- Ordem condicional das perguntas em uma pesquisa
- Administração das pesquisas
- Relatórios e análises
