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

Мета - зберігати відповіді, надані користувачами (це буде додаток для Android).

У мене є три сутності: користувач, питання та варіант.

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

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

Користувач вибере одну (або більше) з цих опцій.

Моя концептуальна конструкція:

Я не знаю, як пов’язати відповідь з користувачем.

Як я можу представити це відношення?
Чи є в мене інша особа, яка представляє значення опціону?

Ця модель буде зберігати запитання та заздалегідь зроблені відповіді (пропоновані відповіді) та дозволяє повторно використовувати їх у різних опитуваннях.

Я повинен представляти таке питання:

Це питання пов'язане з цим: Дизайн бази даних опитування: перша версія. Чи є помилки?

Потрібно розрізняти можливі відповіді та вибрані відповіді.

У Optionтаблиці повинні бути дві таблиці. OptionТаблиця повинна бути 1: М до Questionі повинна включати в себе можливі відповіді на це питання.

Тоді вам потрібно створити нову сукупність перехрестя, назвати її, Selected_Optionяка сидить між Userі Option.

Якщо ваше запитання дає можливість користувачеві заповнити значення як відповідь (тобто "ІНШЕ: ..."), це значення буде збережене в Selected_Optionтаблиці. Інакше вибране користувачем значення буде значенням, знайденим у Option.

Редагувати:

Виходячи з уточнення вимог ОП: Те, що вам потрібно, не схожа на типову модель анкети наступними способами:

• Усі ваші запитання мають однакові набори відповідей (стовпці)
• Деякі ваші відповіді (стовпці) згруповані разом.
• Блоки питань групуються.

Взявши знімок форми як керівництво, я розділив елементи вашої форми на сутності, які я кольорово кодував:

Це може бути прийнято за допомогою наступного логічного ERD:

Зауважте, що я зашифрував кольори об'єктів у ERD, щоб відповідати знімку вашої вибіркової форми, щоб показати кореляцію.

Одне з припущень цієї моделі полягає в тому, що кожен блок має лише один набір запитантів (тобто один QUESTION_GROUP), який відповідає лівій колонці в блоці. Це трохи спрощує припущення.

Схема бази даних опитування.

Це справжня класика, зроблена тисячами. Вони завжди здаються "досить простими" для початку, але щоб бути хорошим, це насправді досить складно. Для цього в Rails я б використав модель, показану на доданій схемі. Я впевнений, що для деяких це здається складним, але, коли ви створили декілька з них, протягом багатьох років ви усвідомлюєте, що більшість дизайнерських рішень - це дуже класичні зразки, найкраще вирішені динамічною гнучкою структурою даних на початок.
Детальніше нижче:

Деталі таблиці ключових таблиць

відповіді

Таблиця відповідей є критичною, оскільки фіксує фактичні відповіді користувачів. Ви помітите, що відповіді посилаються на питання_опції , а не на запитання . Це навмисно.

input_types

input_types - це типи питань. Кожне запитання може бути лише 1-го типу, наприклад, всі радіотелефони, усі текстові поля тощо. Використовуйте додаткові запитання щодо того, коли є (скажімо) 5 радіо-циферблатів та 1 прапорець "Включити?" варіант або якесь таке поєднання. Позначте два запитання на екрані користувачів, як одне, але всередині є два запитання, одне для радіотехнічного набору, одне для прапорця. У цьому випадку в групі буде 1 група.

option_groups

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

Тоді, наприклад, якщо виникає питання про сусідній вік властивості, тоді опитування захоче «повторно використати» вищезазначені діапазони, щоб ті самі опціони_групи та варіанти звикли.

одиниці_ міри

units_of_measure так , як це звучить. Незалежно від того, чи це дюйми, чашки, пікселі, цегла чи все інше, ви можете визначити це один раз тут.

FYI: Незважаючи на загальну природу, можна створити додаток поверх цього, і ця схема добре підходить до рамки Ruby On Rails з умовами, такими як "id" для первинного ключа для кожної таблиці. Крім того, відносини є простими one_to_many, не вимагаючи багато_to_many чи has_many за допомогою. Я б, мабуть, додав has_many: throughs та / або: делегати, хоча для отримання таких обставин, як ім'я_визначення, з індивідуальної відповіді легко без.multiple.chaining.

Погляньте на цю загальну ідею:

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

Ця модель має такі характеристики:

• Одне питання можна поділити між декількома опитуваннями (і одне опитування, звичайно, може містити кілька запитань). SURVEY_QUESTION - це таблиця "посилання", яка реалізує це відношення M: N.
• Порядок запитань в опитуванні визначається SURVEY_QUESTION.QUESTION_NO. Оскільки {SURVEY_NO, QUESTION_NO} - це (альтернативна) клавіша, позначена на U1наведеній вище схемі, жодне два питання не може займати один і той же «проріз» в одному опитуванні. У різних опитуваннях можуть виникати однакові питання в різному порядку.
• На кожне запитання є ряд можливих відповідей або "варіантів". Візуальний порядок опцій визначається параметром OPTION.OPTION_NO, і оскільки він знаходиться в ПК, жоден два варіанти не можуть займати один і той же «проріз» під одним і тим же питанням.
• Різні користувачі можуть надати різні відповіді на одне і те ж питання (і, звичайно, один користувач може відповісти на кілька запитань). Це співвідношення M: N реалізується через таблицю "посилання" ВІДПОВІДЬ.
• Користувач відповідає на питання, вибираючи принаймні один із його варіантів. Це забезпечується виключенням OPTION_NO з ПК відповіді. Якщо ви хочете дозволити користувачеві вибирати кілька варіантів, включіть OPTION_NO в ПК.

У цій моделі даних немає нічого, що змушує користувача відповідати на всі питання - це те, що вам потрібно зробити на рівні програми. Тим не менш, ця модель повинна стати гарним початком для того, що вам потрібно зробити ...

Вам знадобиться ще одна таблиця, щоб вмістити відповіді користувачів.

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

Якщо ви вирішите, що ви хочете, щоб користувачі могли вибрати опцію "Інше" і заповнити власну цінність, я рекомендую окрему таблицю для цього:

user_alt_answers
----------------
  user_alt_answer_id - ПК
  alt_answer_text - текст, який користувач ввів для параметра "інший".
  user_answeR_id - таблиця від FK до user_answers

[Я поки не можу коментувати, звідси це як відповідь]

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

Будь ласка, перевірте це тут .