ヘルスケア アプリケーション用のデータマートを作成しようとしています。データマート内のファクトは、基本的には心臓に関連する測定値と調査結果であり、数百個あります。1000 から始まり、試験の種類ごとに最大 20000 まで可能です。
ファクト テーブルの設計上の選択は次のとおりです。
グレイン: 検査タイプごとに患者ごとに 1 行。
私が考えることができるいくつかの選択肢 -
1) 1000 列以上の大きな幅のファクト テーブル。
2) EAV ベースの設計 - 個別のメジャー ディメンション テーブル。この外部キーはファクト テーブルに入り、メジャー値はファクト テーブルになります。そのため、ファクト テーブルの粒度は、患者ごと、検査タイプごと、測定ごとに 1 行に変更されます。
3) サブグループのようないくつかの他の基準に従って、試験の種類ごとに、より小さな複数のファクト テーブルを作成します。ただし、エンド ユーザーはサブグループ全体でその検査タイプを照会するため、事実と事実の結合は推奨されません。
4) 他のアイデアはありますか?
任意の入力をいただければ幸いです。
1. 1000 列以上の大きな幅のファクト テーブル。
クエリがデータ ウェアハウスで直接実行される場合、1 つの非常に広いファクト テーブルにより、エンド ユーザーは最大限の柔軟性を得ることができます。ただし、プラットフォームによっては制限に達する可能性があるため、いくつかの考慮事項を考慮する必要があります。
SQL Server 2014 の制限は次のとおりです。
行あたりのバイト数 8,060。行オーバーフロー ストレージは解決策になるかもしれませんが、varchar、nvarchar、varbinary、sql_variant など、通常はファクトの性質に関係のない少数の列タイプのみをサポートします。また、インメモリ OLTP ではサポートされていません。https://technet.microsoft.com/en-us/library/ms186981(v=sql.105).aspx
非ワイド テーブルあたりの列数は 1024 です。ワイド テーブルあたりの列数の制限は 30,000 であるため、ワイド テーブルとスパース列はソリューションです。ただし、同じ Bytes per row 制限が適用されます。https://technet.microsoft.com/en-us/library/cc280604(v=sql.120).aspx
SELECT/INSERT/UPDATE ステートメントあたりの列数 4,096
テーブルごとの非クラスター化インデックス 999
https://technet.microsoft.com/en-us/library/ms143432(v=sql.120).aspx
2. EAV ベースの設計 - 個別のメジャー ディメンション テーブル。この外部キーはファクト テーブルに入り、メジャー値はファクト テーブルになります。そのため、ファクト テーブルの粒度は、患者ごと、検査タイプごと、測定ごとに 1 行に変更されます。
Kimball 氏によると、EAV 設計はFact Normalizationと呼ばれています。多数の測定値が非常に長いが、特定のファクトに対してまばらにデータが取り込まれ、ファクト間で計算が行われない場合に、これは理にかなっている可能性があります。
事実は正規化されているため、次のようになります。
拡張性は非常に簡単です。つまり、データ構造を修正する必要なく、新しい測定値を簡単に追加できます。
1 つの検査のすべての測定値を抽出し、測定値を行として画面に表示することをお勧めします。
いくつかの測定 (例: HDL から CHOL への平均比率) の間で計算を抽出/集計/実行し、測定/集計/計算を列として提示することは困難です。つまり、複雑な WHERE/PIVOTING または複数結合が必要です。SQL では、異なる行のファクト間の計算が困難になります。
プライマリ エンド ユーザー プラットフォームが OLAP キューブである場合、ファクトの正規化は理にかなっています。キューブを使用すると、任意の次元にわたって計算を行うことができます。
データ形式がフラット スタイルの CSV の場合、データのインポートが問題になる可能性があります。
この質問については、こちらでも説明しています。EAV モデルを使用する必要がありますか? .
3) サブグループのようないくつかの他の基準に従って、試験の種類ごとに、より小さな複数のファクト テーブルを作成します。ただし、エンド ユーザーはサブグループ全体でその検査タイプを照会するため、事実と事実の結合は推奨されません。
いくつかのシナリオでは、複数の小さなファクト テーブルが完全に理にかなっています。理由の 1 つは、プラットフォームによって設定された物理的な制限 (行あたりのバイト数など) に達した場合です。
ファクトは、測定グループ/サブグループなどのサブジェクト領域ごと、または使用頻度ごとにグループ化できます。I/O を最大化するために、各テーブルを個別のファイル グループとドライブに配置できます。
さらに、異なるファクト テーブル間で測定値を複製して、ファクト テーブル結合の必要性を減らすことができます。つまり、特定の測定サブグループ ファクト テーブルと頻繁に使用される測定ファクト テーブルに 1 つの測定値を配置します。
ただし、データの読み込みに特定の要件がある場合は、いくつかの考慮事項を考慮する必要があります。たとえば、レコードが 1 つのファクト テーブルへの ETL でエラーになった場合、他のファクト テーブルの対応するレコードが削除され、エラー テーブルにステージングされることを確認して、偽の情報で終わらないようにすることができます。 . これは、エンド ユーザーがフロント エンド ツールで独自の計算を行う場合に特に当てはまります。
OLAP キューブを使用すると、実際には複数のファクト テーブルが特定のファクト テーブルに対するメジャー グループのソースになります。
ファクト ツー ファクト結合に関しては、BI アプリケーションは、ファクト テーブルの外部キーを介して 2 つのファクト テーブルを結合する SQL を発行しないでください。代わりに、2 つ以上のファクト テーブルからの回答セットを個別に作成し、結果を共通の行ヘッダー属性値で並べ替えマージして正しい結果を生成する、2 つのファクト テーブルにまたがるドリルの手法を使用する必要があります。
このトピックの詳細: http://www.kimballgroup.com/2003/04/the-soul-of-the-data-warehouse-part-two-drilling-across/
4) 他のアイデアはありますか?
SQL XML またはある種の NoSQL がオプションになる可能性がありますが、同じクエリ/集計/計算/プレゼンテーションの問題が存在します。