Я делаю концептуальную модель для базы данных опроса.

Цель - хранить ответы пользователей (это будет приложение для Android).

У меня есть три объекта: пользователь, вопрос и вариант.

Вопрос будет иметь один или несколько вариантов (например: Сколько сотрудников у вас есть? 1-40, 40-1000, +1000).

Параметры будут иметь текст (1-40) и значение (значение, выбранное пользователем).

Пользователь выберет один (или несколько) из этих вариантов.

Мой концептуальный дизайн:

Я не знаю, как связать ответ с пользователем.

Как я могу представить это отношение?
У меня есть другой объект для представления значения опции?

Эта модель будет хранить вопросы и заранее сделанные ответы (предлагаемые ответы) и позволяет их повторно использовать в различных опросах.

Я должен представить вопрос, как этот:

Этот вопрос связан с этим: Дизайн базы данных опроса: первая версия. Есть ошибки?

Вам необходимо провести различие между возможными ответами и выбранными ответами.

В Optionтаблице должно быть две таблицы. OptionТаблица должна быть 1: М к Questionи должна включать в себя возможные ответы на этот вопрос.

Затем вам нужно создать новый объект пересечения, вызвать его, Selected_Optionкоторый находится между Userи Option.

Если ваш вопрос дает пользователю возможность ввести значение в качестве ответа (то есть «ДРУГОЕ: ...»), тогда это значение будет сохранено в Selected_Optionтаблице. В противном случае значение, выбранное пользователем, будет значением, найденным в Option.

РЕДАКТИРОВАТЬ:

Основываясь на разъяснении требований OP: То, что вам нужно, не похоже на типичную модель вопросника следующими способами:

• Все ваши вопросы имеют одинаковые наборы ответов (столбцы)
• Некоторые из ваших ответов (столбцы) сгруппированы вместе.
• Блоки вопросов сгруппированы вместе.

Взяв за основу ваш снимок формы, я разделил элементы вашей формы на объекты, которые я выделил цветом:

Это может быть обеспечено следующим логическим ERD:

Обратите внимание, что я обозначил цветом объекты в ERD, чтобы они соответствовали снимку вашей формы, чтобы показать корреляцию.

Одно из предположений в этой модели состоит в том, что каждый блок имеет только один набор квестов (то есть один QUESTION_GROUP), который соответствует левому столбцу в блоке. Это немного упрощающее предположение.

Схема базы данных съемки.

Это настоящая классика, выполненная тысячами. Они всегда кажутся «довольно простыми» для начала, но, чтобы быть хорошими, это на самом деле довольно сложно. Для этого в Rails я бы использовал модель, показанную на прилагаемой диаграмме. Я уверен, что для некоторых это кажется слишком сложным, но после того, как вы построили несколько из них, на протяжении многих лет вы понимаете, что большинство проектных решений - это очень классические шаблоны, которые лучше всего решаются с помощью динамической гибкой структуры данных на боковик.
Более подробная информация ниже:

Детали таблицы для ключевых таблиц

ответы

Таблица ответов имеет решающее значение, поскольку она отражает реальные ответы пользователей. Вы заметите, что ответы ссылаются на question_options , а не на вопросы . Это намеренно.

input_types

input_types - это типы вопросов. Каждый вопрос может быть только одного типа, например, все радиозвонки, все текстовые поля и т. Д. Используйте дополнительные вопросы, если есть, скажем, 5 радиозвонков и 1 флажок для «включить?» вариант или некоторая такая комбинация. Пометьте два вопроса в представлении пользователей как один, но внутренне задайте два вопроса: один для радиодисков, один для флажка. Флажок будет иметь группу 1 в этом случае.

option_groups

option_groups и option_choices позволяют вам создавать «общие» группы. Например, в заявке на недвижимость может возникнуть вопрос «Сколько лет собственности?». Ответы могут быть желательны в диапазонах: 1-5 6-10 10-25 25-100 100+

Затем, например, если возникает вопрос о возрасте смежного свойства, тогда опросу понадобится «повторно» использовать вышеуказанные диапазоны, чтобы использовались те же option_group и options.

единицы измерения

unit_of_measure , как это звучит. Будь то дюймы, чашки, пиксели, кирпичи или что-то еще, вы можете определить это один раз здесь.

К сведению: Несмотря на то, что это универсальный характер, можно создать приложение поверх этого, и эта схема хорошо подходит для среды Ruby On Rails с такими соглашениями, как «id» для первичного ключа для каждой таблицы. Кроме того, все отношения простые one_to_many без необходимости в сквозных связях many_to_many или has_many. Я бы, вероятно, добавил has_many: throughs и / или: делегаты, чтобы легко получить такие вещи, как survey_name из индивидуального ответа без multiple.chaining.

Взгляните на эту общую идею:

(Для краткости в приведенную выше модель включены только самые необходимые поля.)

Эта модель имеет следующие характеристики:

• Один вопрос может быть разделен между несколькими опросами (и один опрос, конечно, может содержать несколько вопросов). SURVEY_QUESTION - это таблица «link», которая реализует это отношение M: N.
• Порядок вопросов в опросе определяется SURVEY_QUESTION.QUESTION_NO. Поскольку {SURVEY_NO, QUESTION_NO} является (альтернативным) ключом, обозначенным U1на диаграмме выше, никакие два вопроса не могут занимать одну и ту же "ячейку" в одном опросе. В разных опросах могут быть одни и те же вопросы в разном порядке.
• Каждый вопрос имеет ряд возможных ответов или «вариантов». Визуальный порядок опций определяется OPTION.OPTION_NO, и, поскольку он находится в PK, никакие две опции не могут занимать один и тот же «слот» под одним и тем же вопросом.
• Разные пользователи могут предоставить разные ответы на один и тот же вопрос (и, конечно, один пользователь может ответить на несколько вопросов). Это отношение M: N реализуется через таблицу «ОТВЕТ» на ссылку.
• Пользователь отвечает на вопрос, выбирая не более одного из его вариантов. Это обеспечивается путем исключения OPTION_NO из PK ОТВЕТА. Если вы хотите разрешить пользователю выбирать несколько опций, включите OPTION_NO в PK.

В этой модели данных нет ничего, что заставляло бы пользователя отвечать на все вопросы - это то, что вам нужно сделать на уровне приложения. Тем не менее, эта модель должна стать хорошим началом для того, что вам нужно сделать ...

Вам понадобится еще одна таблица для хранения ответов пользователей.

user_answers
------------
  user_answer_id - уникальный первичный ключ
  user_id - FK для таблицы пользователя
  selected_option_id - FK для таблицы параметров
  question_id - FK для таблицы вопросов

Если вы решите, что хотите, чтобы пользователи могли выбрать «Другое» в качестве опции и указать свое значение, я бы порекомендовал для этого отдельную таблицу:

user_alt_answers
----------------
  user_alt_answer_id - PK
  alt_answer_text - текст, который пользователь ввел для «другой» опции.
  user_answeR_id - FK в таблицу user_answers

[Я пока не могу комментировать, поэтому это как ответ]

Для решения, представленного VansFannel, я сделал там более полную модель.

Пожалуйста, проверьте это здесь .