sql - 調査データ モデル - EAV と過度の非正規化を回避するには?

Question

私のデータベース スキルはせいぜい平凡で、調査データのデータ モデルを設計する必要があります。私はこれについていくつかの考えを費やしましたが、現在、ある種のEAV モデルと、それぞれが数百の列 (および数千のレコード) を持つ数百のテーブルを含む設計の間で立ち往生していると感じています。これを行うためのより良い方法が必要であり、このフォーラムの賢明な人々が私を助けてくれることを願っています.

私の質問は、RDBMS でアンケートの質問に対する回答をどのようにモデル化すればよいですか? SQL Server の使用は必須です。そのため、代替のデータ ストレージ システムは、この議論から除外する必要があります。(確かに、いくつかは評価されるべきであり、評価されますが、ここでは省略してください。) データ モデル全体のソリューションは必要ありません。今のところ、Answers 部分にのみ関心があります。

すでにさまざまなフォーラムを検索しましたが、実際に解決策を見つけることができませんでした。すでに他の場所で提供されている場合は、すみませんがリンクを提供してください。私はそれを読むことができます.

私が対処しなければならないデータに関するいくつかの仮定：

1. 各アンケートは 1 ～ n 個のアンケートで構成されています
2. 各アンケートは 100 ～ 2,000 の質問で構成されています (2,000 の質問は非常に多くの質問に聞こえることを無視してください...)
3. 質問にはさまざまな種類があります: 選択式、フリーテキスト、数字 (年齢、収入、パーセンテージなど)。
4. 各調査には 10 ～ 200 か国が参加します (これらは回答者ではありません。回答者は実際にはその国の人々です。)
5. アンケートの種類にもよりますが、各アンケートには国ごとに 100 ～ 20,000 人の回答者が回答しています。
6. 国は調査に合わせてアンケートを調整できます。つまり、質問を追加、削除、または編集できます。
7. ある国のデータは、その国の別のデータベースに収集されます。最初からオンライン統合の可能性はありません。
8. すべての国のデータは後で統合する必要があります。これは、たとえば、ある国が質問を削除した場合、そのデータは、すべての国で統一されたデザインを実現するために、送信したものから何らかの方法で取得する必要があることを意味します
9. すべての国のデータを処理する必要がある統合およびクリーニング ソフトウェアを作成する必要があります。
   1. 最後に、データをフラット ファイル (国ごとに 1 つの長方形グリッドとアンケート) にエクスポートする必要があります。

私はすでにこのトピックについてさまざまなバックグラウンドを持つ人々と話し合ってきましたが、まだ良い解決には至っていません. 主に2種類の意見がありました。

1. データ処理と分析のためにフラット ファイル (スプレッドシート スタイル) を使用することに慣れているドメインの専門家は、上で説明したように、多数のテーブルと列を含む非正規化構造に投票します (国ごとに 1 つのテーブルとアンケート)。幅の広いテーブルを避ける必要があることを学んだので、これはひどいことのように思えます。テーブルを操作するときに実際にどの列がテーブルにあるかを判断するのは面倒です。データベースは何百ものテーブルで雑然とします (または、複数のデータベースを設定し、それぞれが類似しているが少し異なる設計になっているなど)。
2. OO プログラマーは、すべての質問に対するすべての回答者からのすべての回答を含む中央テーブルに効果的につながる、強力に「正規化された」設計に投票します。このテーブルには、sql_variant 型の列、または異なる型 (複数選択、フリー テキストなど) の回答を格納するための異なる型の複数の回答列が含まれている必要があります。前者は本質的にEAVモデルになります。私はここで Joe Celko をフォローする傾向があります. 後者は、設計上、適用できない型の null セルが各行に含まれることを意味します。

私が考えることができる別の代替案は、回答の種類ごとに 1 つのテーブルを作成することです。つまり、多肢選択式の質問用に 1 つ、フリーテキストの質問用に 1 つなどです。新しい回答タイプが発明された場合、テーブルを追加する必要があります。

このすべてのテキストで退屈させて申し訳ありません。ご意見をお寄せいただきありがとうございます。

乾杯、アレックス

PS: ここで同じ質問をしました: http://www.eggheadcafe.com/community/aspnet/13/10242616/survey-data-model--how-to-avoid-eav-and-excessive-denormalization.aspx

Answer 1

imgurがダウンしているので、後で写真を投稿します。

これは、リレーショナル モデル内で完全に実行可能だと思います。これを行う方法を示すために CDM を作成しました。

アウトバウンド

国の調査を定義するには、4 つのエンティティが必要です。いくつかの親アンケート、国、および質問のリスト。質問には内部的な関係があるため、ある国が質問を「編集」すると、その国からの質問とその質問の元の質問の両方を追跡できます。他に必要なのは、Possible Answer エンティティ/テーブルです。各質問には、可能な回答のリスト (複数の選択肢や範囲など) が関連付けられている場合があります。これらの 4 つは、この「OUTBOUND」側を完全に定義する必要があります。

インバウンド

「INBOUND」側は、レスポンデントとアンサーの 2 つの新しいエンティティです。回答者は率直です。あなたが知っている場合はその人の人口統計だけです。ここでは、国に戻る関係を含めることができます. 各回答者は、特定の国で調査に回答しました。(その人物が旅行中または二重国籍を持っている場合は、回答者と 1 対 1 の関係にある可能性があります)

答えは基本的なものです。それは、Possible Answers のリストにリストされている選択肢の 1 つであるか、提供されているかのいずれかです。答えが数字や日付などである可能性があるという事実にまだとらわれないでください。FK または文字列のいずれかです。

報告

レポートはこれらすべてを結合したものです...国と調査を選択し、質問と回答のリストを取得します。

答えの複雑さ

計算をどこで行うかによって異なります。ユーザー提供の回答に Varchar2(4000) 列を使用した場合、質問に属性を追加して、回答のデータ型を記述することができます。Q：年齢は？DT: (0 ～ 130) の整数。その後、データベースが検証を強制する代わりに、統合レイヤーが検証を実行できます。または、数値、日付、文字、および CLOB 用に 1 つずつ、合計 4 つの列を持つこともできます。また、統合レイヤーによって、使用する列が決定されます。これらの回答を報告するときは、Coalesce() で 4 つの列すべてを選択するだけです。

「Answer」のデータ型に若干のあいまいさがあるため、これは EAV ですか?

いいえ、ちがいます。

EAV モデルは、エンティティを属性のリストに分解します。そのようです：

Entity     Attribute     Value
  1          Fname         Stephanie
  1          Lname         Page
  1          Age           30

Survey スキーマの Answer 列には、ここでの Value 列のように単語と数字の両方が含まれていることがわかるので、EAV を定義していると思います。そうではありません。このモデルに 3 つのデータ型列を追加した場合と同様に、EAV から変更されません。

私はそれが嫌いです

私がチューニングしているクエリは「できるだけ速く」実行する必要があると人々に言われました。では、10 億ドルと 30 年をください。「待って、10億って何？」「できるだけ」、「できるだけ速く」は要件ではありません。データベースで必要なものは何でも検証できます... 大量の Before トリガーを構築できます。検証が豊富。

年齢列のデータ型は何ですか? それとも生年月日欄？データソースが何であるかによって異なります。一部の古いレコードには、月と年のみ、または年のみ、または「前後」または「年頃」の年が含まれる場合があります。数値列だけで「できるだけ多くの検証」を行うことはできません。NUMBER(2) は、単なる NUMBER よりも優れた検証である可能性があります。これで、NUMBER(1)、NUMBER(2)、NUMBER... を「できるだけ」持つことができます。

つまずいたと思うところ

これは、物理モデルではなく、概念データ モデルと考えてください。それらの用語では、調査はエンティティです。Questionはエンティティか、Survey の単なる属性ですか。1 つのテーブル PERを構築した場合、質問は単なる調査の属性であり、それらを垂直に格納するとこれが EAV になることを明確に示しています。このモデルが示しているのは、Question が実際には別のエンティティであることです。質問の間には関係があります。たとえば、「国は質問を編集[できる]」などです。元の質問と編集された質問がありました。各質問には、可能な回答のコレクションがあります。そして最も重要なことは、それらはすべて質問であるということです. EAV では、fname、lname、bdate、age、major、salary などを呼び出します...すべて非常に異なるものであり、属性だけです。この場合、アンケートを作成した機関の名前、アンケートの発行日、返却期限日などは質問として含めません。

これを別の言い方をしましょう。あなたはフェデックスです。特定のイベントのタイムスタンプを保存したい。パッケージが施設または車両に出入りするたびに。ピックアップトラックに乗っている時間、トラックを降りて最初の施設に入る時間、その施設を出て飛行機に乗る時間など。それらを水平に保管しますか? 事前にホップ数を知るにはどうすればよいですか? それらを垂直に保管すると、自動的に EAV になりますか? もしそうなら、なぜですか。

あなたは気象会社で、全国の観測所から気温を取得しています。センサーは、温度が +/- 1 度変化したときに読み取り値を送信するように設計されているとしましょう。sensor_ID|timestamp|temp を格納する場合、読み取りテーブルは EAV ですか? 各読み取り値はセンサーの属性ではなく、それ自体がコレクション/シリーズに属するエンティティです。

回答の垂直ストレージが EAV と共通していることの 1 つは、分析クエリの実行が難しいことです。質問 5 と 10 に TRUE と答えたが 6 と 11 に FALSE と答えたすべての人のリストが必要な場合、縦方向に行うと非常に困難になります。たぶんそれが、これが EAV だと思われる理由です。それをしたい場合は、別のストレージが必要です。質問と回答のリレーショナル ストレージは、最適なレポート データベースではありません。Fedex の例に戻りましょう。行が縦に並んでいる場合、「通過」時間レポートを作成するのは簡単ではありません。

Answer 2

これは、一般的な問題に取り組んでいるように聞こえます。ハンマーを使用してネジを固定する方法です。

あなたがリストした両方の選択肢は、それぞれ異なる理由で悪いです。しかし、それは、特定のデータモデルをリレーショナルデータベースシステムに詰め込もうとしているためです。良いアプローチは、リレーショナルデータベースを超えて、他のデータベース/ストレージシステムを調べ、いくつか試して、プロジェクトに最適なものを見つけることです。

---

私はEAVモデルを試しましたが、複雑すぎたため諦めました。リレーショナルデータベースシステムでマルチテーブルモデルを試すのが怖いです。リレーショナルデータベースで私が見つけた最も簡単な解決策は、各完全な応答を単一のCLOBとして、JSONまたはYAML（または他の軽量なもの）にシリアル化してresponsesテーブルに格納することです。

create table responses (
  id uuid primary key,
  questionnaire_id uuid references questionnaires.id,
  data text
)

Answer 3

SQL Server を使用していた場合、Express で問題ないので、次のようにします。

• 質問のリスト、タイプのフラグ (ビット)、必要な場合のフラグ (ビット)、存在する場合の正解などを含む表
• 国のリストを含む表
• 国と質問のテーブル リンク (国によっては、一部の質問が得られない場合があります)
• 質問の列を含む回答の表と、追加されたものを含むオプションの質問の xml 列

XML の断片化に慣れていない場合は、すべてのオプションの質問にスパース列を使用してください。テーブル内のスパース列の数の制限を正確には覚えていませんが、30,000 を超えていると思います。SQL Serverはスパース列をXMLとして内部的に保存し、列を選択するとそれを細断処理し、はい、インデックスを作成できます

次の図は、SQL Server で作成された図を示しています。列 AL_A4 は QL_Id = 4 に対する回答を保持し、スパース型です。QuestionList テーブルの QL_Id には、AnswerList の列をスパースにする必要があるというフラグが立てられていません。

国によって質問が追加されるため、QuestionListCustom、QuestiontoCountryCustom、および AnswerListCustom テーブルを作成し、カスタム質問からの情報を追加します。

ストレージを設計する方法は他にもあると思います。これが私が宿題を提出する方法です。これが宿題でない場合は、国連で働いていることになります。

Answer 4

車輪の再発明をしないことを考えたことはありますか? オープンソースの調査アプリケーションが既に構築されています。それらがニーズを満たしていない場合でも、いくつかをダウンロードして、データ モデルを確認してください。