調査データベースの概念モデルを実行しています。

目標は、ユーザーからの回答を保存することです（Androidアプリになります）。

ユーザー、質問、オプションの3つのエンティティがあります。

質問は（：例えば1つまたは複数のオプションがあります？あなたはどのように多くの従業員が持っていない 1-40、40から1000、+1000）を。

オプションにはテキスト（1〜40）と値（ユーザーが選択した値）があります。

ユーザーはこれらのオプションの1つ（または複数）を選択します。

私の概念設計は次のとおりです。

回答をユーザーに関連付ける方法がわかりません。

その関係をどのように表現できますか？
オプション値を表す別のエンティティはありますか？

このモデルは、質問と事前に作成された回答（提供された回答）を保存し、さまざまな調査で再利用できるようにします。

私はこのような質問を表さなければなりません：

この質問はこれに関連しています：調査データベースの設計：最初のバージョン。エラーはありますか？

可能な答えと選択した答えを区別する必要があります。

Optionテーブルは2つのテーブルである必要があります。OptionM：表は1でなければなりませんQuestionし、その質問に対する可能な答えを含める必要があります。

その後、あなたは、新しい交差エンティティを作成する必要があり、それを呼び出すSelected_Optionの間に位置しているUserとOption。

あなたの質問がユーザーに回答として値を入力する機会を与えた場合（つまり、「その他：...」）、この値はSelected_Optionテーブルに保存されます。そうでない場合、ユーザーが選択した値はで見つかった値になりOptionます。

編集：

OPの要件の明確化に基づく：必要なのは、以下の点で典型的なアンケートモデルとは異なります。

• すべての質問には同じ回答（列）のセットがあります
• 回答（列）の一部はグループ化されています。
• 質問のブロックは一緒にグループ化されます。

フォームのスナップショットをガイドとして使用し、フォームの要素を色分けしたエンティティに分割しました。

これは、次の論理的なERDに対応できます。

サンプルフォームのスナップショットに対応するようにERDのエンティティを色分けして、相関関係を示していることに注意してください。

このモデルの仮定の1つは、各ブロックにはQUESTION_GROUP、ブロックの左側の列に対応する1セットのクエリ（つまり1セット）だけがあるということです。これは少し単純化された仮定です。

調査データベーススキーマ。

これは数千人によって行われた真の古典です。最初は常に「かなりシンプル」に見えますが、実際にはかなり複雑です。Railsでこれを行うには、添付の図に示すモデルを使用します。かなり複雑に思えるかもしれませんが、これらのいくつかを長年にわたって構築すると、ほとんどの設計決定は非常に古典的なパターンであり、最初。
以下の詳細：

キーテーブルのテーブル詳細

答える

答えは、それがユーザーによる実際の応答をキャプチャするように、テーブルは非常に重要です。あなたは質問ではなくquestion_optionsへのリンクに答えていることに気付くでしょう。これは意図的なものです。

input_types

input_typesは質問のタイプです。各質問は1種類のみです。たとえば、すべてのラジオダイヤル、すべてのテキストフィールドなどです。たとえば、5つのラジオダイヤルと「含める？」の1つのチェックボックスがある場合は追加の質問を使用します オプションまたはそのような組み合わせ。ユーザービューの2つの質問に1つのラベルを付けますが、内部的には、ラジオダイヤル用とチェックボックス用の2つの質問があります。この場合、チェックボックスには1のグループがあります。

option_groups

option_groupsおよびoption_choicesを使用すると、「共通」グループを構築できます。一例として、不動産アプリケーションでは、「資産は何歳ですか？」という質問があります。回答は、1-5 6-10 10-25 25-100 100+の範囲で必要になる場合があります

次に、たとえば、隣接するプロパティの年齢について質問がある場合、調査は上記の範囲を「再利用」して、同じoption_groupとoptionsが使用されるようにします。

測定単位

units_of_measureはそのとおりです。インチ、カップ、ピクセル、レンガなど何でも、ここで一度定義できます。

参考までに、本質的に汎用ですが、この上にアプリケーションを作成できます。このスキーマは、各テーブルの主キーに「id」などの規則があるRuby On Railsフレームワークに適しています。また、関係は単純なone_to_manyであり、many_to_manyまたはhas_manyスルーは必要ありません。私はおそらくhas_many：throughsおよび/または：delegatesを追加しますが、個々の回答からsurvey_nameのようなものを.multiple.chainingなしで簡単に取得できます。

この一般的なアイデアを見てください：

（簡潔にするために、最も重要なフィールドのみが上記のモデルに含まれています。）

このモデルには次の特徴があります。

• 1つの質問を複数の調査で共有できます（もちろん、1つの調査に複数の質問を含めることができます）。SURVEY_QUESTIONは、このM：N関係を実装する「リンク」テーブルです。
• 調査における質問の順序は、SURVEY_QUESTION.QUESTION_NOによって決まります。{SURVEY_NO、QUESTION_NO}は（代替）キーであり、U1上の図に示されているように、同じ調査で2つの質問が同じ「スロット」を占めることはできません。異なる調査では、同じ質問を異なる順序で持つことができます。
• 各質問には、一連の可能な回答または「オプション」があります。オプションの視覚的な順序はOPTION.OPTION_NOによって決定され、PK内にあるため、2つのオプションが同じ質問の下で同じ「スロット」を占めることはできません。
• 同じ質問に対して異なるユーザーが異なる回答を提供できます（もちろん、1人のユーザーが複数の質問に回答できます）。このM：N関係は、「リンク」テーブルANSWERを通じて実装されます。
• ユーザーは、オプションの多くても1つを選択して質問に答えます。これは、ANSWERのPKからOPTION_NO を除外することにより保証されます。ユーザーが複数のオプションを選択できるようにする場合は、PKにOPTION_NOを含めます。

このデータモデルには、ユーザーにすべての質問への回答を強制するものは何もありません。これは、アプリケーションレベルで行う必要があることです。それにもかかわらず、このモデルはあなたがする必要があることの良いスタートになるはずです...

ユーザーの回答を保持する別のテーブルが必要になります。

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-user_answersテーブルへのFK

[まだコメントできないので、これは答えとして]

VansFannelが提示したソリューションについては、そこでより完全なモデルを作成しました。

こちらで確認してください。