Estoy haciendo el modelo conceptual para una base de datos de encuestas.

El objetivo es almacenar las respuestas dadas por los usuarios (será una aplicación de Android).

Tengo tres entidades: usuario, pregunta y opción.

Una pregunta tendrá una o más opciones (por ejemplo: ¿Cuántos empleados tiene? 1-40, 40-1000, +1000).

Las opciones tendrán un texto (1-40) y un valor (el valor seleccionado por el usuario).

El usuario seleccionará una (o más) de estas opciones.

Mi diseño conceptual es:

No sé cómo asociar una respuesta con un usuario.

¿Cómo puedo representar esa relación?
¿Tengo otra entidad para representar el valor de la opción?

Este modelo almacenará preguntas y respuestas prefabricadas (respuestas ofrecidas) y les permite ser reutilizadas en diferentes encuestas.

Tengo que representar una pregunta como esta:

Esta pregunta está relacionada con esta: Diseño de la base de datos de encuestas: primera versión. ¿Hay errores?

Debe hacer una distinción entre las posibles respuestas y las respuestas seleccionadas .

La Optiontabla debe ser dos tablas. La Optiontabla debe ser 1: M Questiony debe incluir las posibles respuestas para esa pregunta.

Luego debe hacer una nueva entidad de intersección, llámela Selected_Optionque se encuentra entre Usery Option.

Si su pregunta le da al usuario la oportunidad de completar un valor como respuesta (es decir, "OTRO: ..."), este valor se almacenará en la Selected_Optiontabla. De lo contrario, el valor elegido por el usuario sería el valor encontrado en Option.

EDITAR:

Según la aclaración de requisitos de OP: lo que necesita no es como un modelo de cuestionario típico de las siguientes maneras:

• Todas sus preguntas tienen el mismo conjunto de respuestas (columnas)
• Algunas de sus respuestas (columnas) están agrupadas.
• Los bloques de preguntas se agrupan.

Tomando su instantánea de formulario como guía, he dividido los elementos de su formulario en entidades que he codificado por colores:

Esto podría ser acomodado por el siguiente ERD lógico:

Tenga en cuenta que he codificado por color las entidades en el ERD para que correspondan con la instantánea de su formulario de muestra para mostrar la correlación.

Una de las suposiciones en este modelo es que cada bloque tiene solo un conjunto de preguntas (es decir, una QUESTION_GROUP) que corresponde a la columna de la izquierda en el bloque. Esto es un poco un supuesto simplificador.

Esquema de base de datos de encuestas.

Este es un verdadero clásico, hecho por miles. Para empezar, siempre parecen "bastante simples", pero para ser buenos, en realidad es bastante complejo. Para hacer esto en Rails, usaría el modelo que se muestra en el diagrama adjunto. Estoy seguro de que parece demasiado complicado para algunos, pero una vez que ha creado algunos de estos, a lo largo de los años, se da cuenta de que la mayoría de las decisiones de diseño son patrones muy clásicos, mejor abordados por una estructura de datos dinámica y flexible en el principio.
Más detalles a continuación:

Detalles de tabla para tablas clave

respuestas

La tabla de respuestas es crítica, ya que captura las respuestas reales de los usuarios. Notarás que las respuestas responden a preguntas_opciones , no preguntas . Esto es intencional

input_types

input_types son los tipos de preguntas. Cada pregunta solo puede ser de 1 tipo, por ejemplo, todos los diales de radio, todos los campos de texto, etc. Utilice preguntas adicionales para cuando haya (digamos) 5 diales de radio y 1 casilla de verificación para un "¿incluir?" opción o alguna combinación de este tipo. Etiquete las dos preguntas en la vista de los usuarios como una, pero internamente tiene dos preguntas, una para los diales de radio y otra para la casilla de verificación. La casilla de verificación tendrá un grupo de 1 en este caso.

grupos_opción

option_groups y option_choices le permiten crear grupos 'comunes'. Un ejemplo, en una aplicación de bienes raíces, podría haber la pregunta '¿Cuántos años tiene la propiedad?'. Las respuestas pueden desearse en los rangos: 1-5 6-10 10-25 25-100 100+

Luego, por ejemplo, si hay una pregunta sobre la antigüedad de la propiedad contigua, la encuesta querrá 'reutilizar' los rangos anteriores, de modo que se usen el mismo grupo de opciones y opciones.

unidades de medida

unidades_de_medida es como suena. Ya sea pulgadas, tazas, píxeles, ladrillos o lo que sea, puede definirlo una vez aquí.

FYI: Aunque es de naturaleza genérica, uno puede crear una aplicación además de esto, y este esquema se adapta bien al marco de Ruby On Rails con convenciones como "id" para la clave principal de cada tabla. Además, las relaciones son simples one_to_many's sin necesidad de many_to_many o has_many throughs. Probablemente agregaría has_many: throughs y / o: delegados para obtener cosas como survey_name de una respuesta individual fácilmente sin.multiple.chaining.

Echa un vistazo a esta idea general:

(Por brevedad, solo se incluyen los campos más esenciales en el modelo anterior).

Este modelo tiene las siguientes características:

• Una sola pregunta puede compartirse entre múltiples encuestas (y una sola encuesta, por supuesto, puede contener múltiples preguntas). SURVEY_QUESTION es la tabla de "enlace" que implementa esta relación M: N.
• El orden de las preguntas en la encuesta se determina mediante SURVEY_QUESTION.QUESTION_NO. Dado que {SURVEY_NO, QUESTION_NO} es una tecla (alternativa), indicada U1en el diagrama anterior, no hay dos preguntas que puedan ocupar el mismo "espacio" en la misma encuesta. Diferentes encuestas pueden tener las mismas preguntas en un orden diferente.
• Cada pregunta tiene una serie de posibles respuestas u "opciones". OPTION.OPTION_NO determina el orden visual de las opciones, y dado que está en la PK, no hay dos opciones que puedan ocupar el mismo "espacio" bajo la misma pregunta.
• Diferentes usuarios pueden proporcionar diferentes respuestas a la misma pregunta (y, por supuesto, un usuario puede responder varias preguntas). Esta relación M: N se implementa a través de la tabla "link" RESPUESTA.
• Un usuario responde la pregunta eligiendo como máximo una de sus opciones. Esto se garantiza al excluir el OPTION_NO de la PK de la RESPUESTA. Si desea permitir que el usuario seleccione varias opciones, incluya OPTION_NO en la PK.

No hay nada en este modelo de datos que obligue al usuario a responder todas las preguntas; esto es algo que deberá hacer a nivel de aplicación. Sin embargo, este modelo debería ser un buen comienzo para lo que necesita hacer ...

Necesitará otra tabla para contener las respuestas de los usuarios.

respuestas_usuario
------------
  user_answer_id - clave primaria única
  user_id: tabla de FK a usuario
  chosen_option_id - FK a la tabla de opciones
  question_id - FK a la tabla de preguntas

Si decide que desea que los usuarios puedan seleccionar "Otro" como una opción y completar su propio valor, recomendaría una tabla separada para eso:

user_alt_answers
----------------
  user_alt_answer_id - PK
  alt_answer_text - texto que el usuario ingresó para una opción "otro".
  user_answeR_id - FK a la tabla user_answers

[No puedo comentar todavía, por lo tanto, esto como respuesta]

Para la solución que presentó VansFannel, hice un modelo más completo allí.

Por favor, compruébalo aquí .