web-dev-qa-db-ja.com

科学的データの設計。数百の列を持つデータテーブル、または汎用値の列と数百の行（EAV）を持つデータテーブル？

私が最近働き始めた生物医学研究室のデータストレージを改善しようとしています。既存のワークフローはひどいもので、さまざまな形式の多数のExcelシートが含まれており、それらはすべてコピーと貼り付けとバグのあるマクロのプロセスを通じて集約されます。

私の目的は、実験のすべてのデータをSQLiteデータベースに集約し、必要なCSV/XLSX出力を生成する簡単なpythonスクリプトを作成することです。

私の問題は、私たちの実験の1回の試行で、約10の異なる時点で記録された約100の変数で終わることです。私の最初の衝動は、valueおよびvariableテーブルを作成することでした：

CREATE TABLE value (val_id INTEGER PRIMARY KEY, 
                    value TEXT, 
                    var_id INTEGER,
                    event_id INTEGER,
                    exp_id INTEGER,
                    FOREIGN KEY (var_id) REFERENCES variable(var_id),
                    FOREIGN KEY (event_id) REFERENCES event(event_id),
                    FOREIGN KEY (exp_id) REFERENCES experiemnt(exp_id)
);

CREATE TABLE variable (var_id INTEGER PRIMARY KEY,
                      var_name TEXT,
                       var_type TEXT
);

value:
val_id | value | var_id | ...
0      | 10    | 0
1      | "ROSC"| 5

variable:
var_id | var_name | var_type
0      | Pressure | DECIMAL
...
5      | Outcome  | TEXT

しかし、これは間違っていると感じ、これを行う「適切な」方法には、variableテーブルに記述されている何百もの列を持つ単一のデータテーブルを用意するのが簡単です。型チェックを行うには（はい、SQLiteはこれを行わないことを知っていますが、原則として）。

これに対処する方法についての洞察は非常に高く評価されます。

database-designschemaeav
5
mrestko

あなたが説明しているのは、ほとんどのデータベースプロフェッショナルが1マイル実行するEAV（エンティティ属性値）モデルです。それは皮肉なことにOTLT（One True Lookup Table）とも呼ばれ、古典的な初心者の間違いです。あなたの勘は正しいです！

ここ （および ここ ）は、Joe Celko（SQL標準委員会のメンバーである/のメンバーである退役軍人のSQLプログラマー）の意見です。 「破壊のEAV」というフレーズはあなたに手掛かりを与えるはずです:-)。 Celkoはこれを大規模統合コードキーとも呼びます。

頭字語がMUCKであることは偶然ではありません！ :-)

この方法でデータを保存すると、DRI（宣言参照整合性）、CHECK制約、DEFAULT値など、リレーショナルデータベースの多くの利点が失われます。

100フィールドと10行のテーブルを作成してください-それがデータに必要なものである場合は、それを実行してください。おそらく、実験ID、datetime、experimenter_idを持つ他のいくつかのフィールドも役立つでしょう。そうすれば、特定の期間、さまざまな他の集計-基本的にデータのスライスとダイスallで分析を実行できます。

<個人的な意見>データベースをまだ選択しておらず、F/LOSSを使用することに満足している場合は、PostgreSQLをお勧めします-SQL方言は、オープンソースデータベースの中で最も豊富です（プロジェクトに接続していません）。 。 SQLiteでデータ型を強制する方法については こちら を確認してください。ただし、PostgreSQLはSQLiteよりも多くの機能を備えています。たとえば、マルチユーザーであり、データ型を強制するためにフープを飛び越える必要はありません。

[編集1]

もう1つ注意してください。完全を期すために、EAVモデルを使用する重要なシステムは1つだけあります。それがMagento（ 1 、 2 ）です。その主要なニッチは、EAVモデルがスパーステーブルに適している可能性があるファッション業界です（ファッションアイテムは、無数の色、スタイル、サイズなどで入手できる傾向があります）。それは人気があります（ 1 、 2 ）が、それからMySQLは、PostgreSQL、Firebird、および（マルチユーザー機能は別として）SQLiteよりも多くの点で劣っています。

5
Vérace