Database
 sql >> Base de Dados >  >> RDS >> Database

Um modelo de banco de dados para uma pesquisa online. Parte 4


Neste artigo final de uma série de quatro partes, concluo o design de um banco de dados de pesquisa on-line para fornecer flexibilidade para várias pesquisas, reutilização de perguntas, respostas de múltipla escolha, ordenação de perguntas, saltos condicionais na pesquisa com base nas respostas e controle sobre o acesso dos usuários a pesquisas por meio de grupos de proprietários de pesquisas.

Introdução


Na conclusão da Parte 3 desta série de artigos, mencionei que adicionaria recursos mais avançados neste artigo. Esses recursos avançados são:
  • administração das pesquisas
  • relatórios e análise

Como lembrete, aqui estava o modelo após a Parte 3:


Administração


Meu objetivo na administração de pesquisas é permitir que uma pesquisa e suas informações correspondentes sejam gerenciadas por um grupo. Assim, permitirei que um usuário administrativo defina grupos de usuários que podem manter conjuntamente uma pesquisa online e suas perguntas. O dono do grupo pode definir quais funções os outros usuários do grupo podem realizar; por exemplo, Jeff pode alterar e excluir pesquisas e perguntas, mas Joe só pode visualizar pesquisas e perguntas, mas não pode alterá-las ou excluí-las.

Uma coisa que você pode notar é que os usuários são separados dos respondentes da pesquisa. É claro que um usuário também pode responder a uma pesquisa, mas gostaria de mantê-los separados para poder exigir menos informações de um entrevistado do que de um usuário (por exemplo, removi o campo de senha de um entrevistado para que ele é mais fácil para as pessoas responderem à pesquisa sem criar um login/conta).

Basicamente, para esta administração, criarei tabelas para grupos e usuários, e as funções e permissões ou ações correspondentes que são permitidas. Isso permite flexibilidade em vez de um link codificado entre as funções e as ações que são permitidas por cada função. Obviamente, o aplicativo correspondente deve ser construído para entender qual funcionalidade é permitida por cada permissão e deve ser adaptada quando uma nova funcionalidade é adicionada, mas o design do banco de dados não precisará ser alterado quando a funcionalidade for adicionada – novas linhas serão adicionadas ao tabela vinculando funções a permissões.

Você também pode notar que usei um comprimento ímpar para o email coluna no user e respondent tabelas e um valor ímpar para o ip_address coluna para o respondent; 254 é o tamanho máximo que um endereço de e-mail pode ter de acordo com as definições RFC, enquanto 45 é o tamanho máximo que um endereço IPv6 (com encapsulamento IPv4) pode ter.




Além disso, adicionarei um link do group tabela para a survey tabela da qual os links vão para todas as tabelas associadas (question_order , survey_response , conditional_order , question_type , response_choice ). Dessa forma, quando o grupo estiver sendo excluído, posso avisar o proprietário do grupo que todas as informações correspondentes serão excluídas.

Eu prefiro essa abordagem de vincular os dados da tabela a algo diferente do usuário específico em vez de não vincular os dados a nada. Se não vincularmos os dados a nada (nem grupo nem usuário), como parecia ter feito nas partes anteriores desta série de artigos, teremos o desafio de “limpar” dados obsoletos quando um usuário for excluído da pesquisa on-line inscrição. Ao vinculá-lo ao conceito mais abstrato de “grupo”, torna-se possível ao proprietário reatribuir a propriedade do grupo e todos os dados correspondentes (pesquisas, perguntas, respostas etc.) a outro membro do grupo, se necessário.

Design formal


Em seguida, estendemos o ERD que foi criado nas outras partes desta série de artigos.




Eu colori as tabelas que foram criadas no artigo da Parte 1 em amarelo, colori as tabelas adicionadas na Parte 2 em laranja, colori as tabelas adicionadas na Parte 3 em verde e as tabelas recém-adicionadas em azul claro para que seja mais fácil veja os acréscimos. A cor não foi adicionada às colunas e chaves estrangeiras que foram adicionadas neste artigo final, então você teria que comparar o modelo atual com o anterior da Parte 3 para ver as diferenças.

Relatórios e análises


Temos informações suficientes que podem ser extraídas das tabelas para produzir vários relatórios.

Por exemplo, quais perguntas foram respondidas de uma maneira específica (“na pesquisa 7, quantas vezes os entrevistados responderam ‘Sim’ à pergunta 10?”). Esse nível de informação provavelmente é adequado para relatórios básicos sobre respostas de pesquisas.

Também podemos extrair quanto tempo os entrevistados levaram para responder a uma pesquisa específica (“na pesquisa 5, o tempo médio gasto na pesquisa foi de 13 minutos”); novamente, isso pode ser uma informação útil para que os proprietários de uma pesquisa possam ajustar as perguntas da pesquisa para que não exijam mais tempo do que um entrevistado típico está disposto a gastar ou o que o pesquisador “prometeu” aos respondentes (por exemplo, “esta pesquisa deve demorar entre 5 e 10 minutos”). Eu sei que quando alguém me diz que devo terminar em menos de 10 minutos e ainda estou respondendo às perguntas 15 minutos depois, fico com raiva e geralmente não estou disposto a responder a outra pesquisa deles.

Com base nos endereços IP dos entrevistados, poderíamos fazer uma pesquisa inversa para ter uma ideia aproximada de onde os entrevistados são ou, pelo menos, de onde seu endereço IP parece ser quando responderam. Esteja ciente de que essas informações não são totalmente confiáveis, pois as pessoas podem se conectar por meio de VPNs ou outros mecanismos que dissociam seu endereço IP de sua localização física.

Podemos até extrair como as perguntas são respondidas pelos primeiros respondentes versus como foi respondida pelos últimos respondentes. Isso pode apresentar um ângulo interessante em sua pesquisa – por exemplo, as pessoas ansiosas que responderam à pesquisa primeiro responderam de maneira diferente das pessoas que não estavam tão ansiosas e responderam à pesquisa mais tarde?

Nesta fase, acho que esses relatórios serão suficientes e que análises mais avançadas não são necessárias, pois a informação mais importante é obviamente o relatório básico de quais respostas foram dadas a cada pergunta em uma pesquisa. Se você precisar de análises mais avançadas, considere quais são seus requisitos e como os dados existentes ou as novas estruturas podem oferecer suporte a essas análises.

Conclusão


E aí está. Não vou afirmar que este é o design para o banco de dados de pesquisa on-line ideal, mas isso atenderá às minhas necessidades em termos de flexibilidade:várias pesquisas, reutilização de perguntas, respostas de múltipla escolha, ordenação de perguntas, saltos condicionais na pesquisa com base em respostas e controle sobre o acesso dos usuários a pesquisas por meio de grupos de proprietários de pesquisas.

Como fiz em cada parte anterior desta série de artigos, vou apontar que você pode ter outros requisitos. Identifique seus requisitos e implemente ou adapte o que você precisa. Acredito fortemente na reutilização e não na reinvenção da roda.


Se você quiser que redesenhemos ou expandamos este modelo de acordo com as necessidades de sua aplicação, informe-nos. Podemos ajudá-lo.

Um modelo de banco de dados para uma pesquisa online –– toda a série

Parte 1 Parte 2 Parte 3 Parte 4